Um gestor de TI de uma empresa de logística com 30 funcionários passou seis meses convencido de que precisava de multi-cloud. Ele leu os artigos, assistiu às apresentações dos provedores, montou uma planilha comparativa entre AWS e GCP. Quando sentou para calcular o custo real de operar os dois ambientes ao mesmo tempo, o número que apareceu foi R$ 14.000 por mês em overhead operacional antes de considerar qualquer transferência de dados entre as duas plataformas. A empresa faturava R$ 800 mil por ano.
Multi-cloud é uma estratégia válida. Para determinados casos. E o caso da maioria das PMEs brasileiras não é um deles.
Multi-cloud virou pauta porque grandes empresas fizeram disso um padrão. O que elas não divulgam: o tamanho do time que sustenta isso.
Netflix, Spotify, Nubank: esses nomes aparecem sempre que alguém defende multi-cloud. O que raramente aparece junto: a Netflix tem centenas de engenheiros exclusivamente em infraestrutura. O Nubank, times inteiros só de orquestração de containers. Multi-cloud nesse nível não é uma decisão de tarde.
Não é um projeto de fim de semana. É o resultado de anos de falhas, retrospectivas e contratações específicas: algo que a Netflix documentou em mais de cem postagens de engenharia que a maioria das PMEs nunca vai ter tempo de ler.
O problema é que os provedores de cloud e as consultorias que vendem serviços em múltiplos ambientes têm todo o incentivo do mundo para apresentar essa estratégia como acessível a qualquer empresa. Nenhum deles vai escrever o que você vai ler nos próximos parágrafos.
O argumento do vendor lock-in: o risco existe, mas o remédio certo raramente é dois provedores
O medo do vendor lock-in é legítimo. Ficar preso a um único provedor significa que, se os preços subirem, se o suporte piorar ou se o serviço descontinuar algo crítico para o seu negócio, a migração vai custar caro.
Mas qual é o custo real de migração de uma PME típica? Pela complexidade envolvida, considerando refatoração de código, ajuste de pipelines de CI/CD, reconfiguração de redes e testes de regressão, uma migração de porte médio raramente fica abaixo de três meses. E esse custo acontece uma vez.
O custo de operar dois provedores acontece todo mês.
O lock-in real raramente está no provedor. Está nos serviços proprietários que você escolheu usar dentro dele: banco de dados gerenciado proprietário, sistema de filas, runtime de funções serverless. Se você usa RDS da AWS, o problema não é a AWS. É que você escolheu um banco que não é portável. A solução para isso é usar PostgreSQL diretamente e um orchestrador de containers padrão, não adicionar um segundo provedor.
Quanto custa operar multi-cloud na prática para uma PME sem time dedicado
Vamos colocar número nisso.
Egresso de dados. Na região sa-east-1 (São Paulo), a AWS cobra US$ 0,15 por GB de dados que saem para a internet, a região mais cara de toda a AWS. No câmbio de R$ 5,70 (referência agosto 2025), isso é R$ 0,86 por GB. Se a sua aplicação em AWS precisar se comunicar com serviços em GCP, você paga egresso na saída e ingresso potencial na entrada.
Para uma aplicação que movimenta 500 GB por mês entre os dois ambientes, são R$ 430 só em transferência de dados, fora o custo dos serviços em si.
Ferramentas de monitoramento. Você vai precisar de observabilidade nos dois ambientes. Isso significa ou pagar duas soluções de monitoramento separadas, ou uma solução unificada mais cara que suporte os dois provedores. Datadog cobra por host. Dobrar o número de ambientes monitorados dobra o número de hosts e, portanto, a fatura. Um ambiente de 20 hosts em dois clouds sai na faixa de US$ 600/mês versus US$ 300 em um só provedor.
IaC em dois dialetos. Se você usa Terraform, vai manter dois conjuntos de módulos com lógica diferente. Se usa CDK ou CloudFormation, não tem equivalente nativo em GCP. Isso significa ou manter dois sistemas de infraestrutura como código, ou migrar para uma ferramenta agnóstica que tem sua própria curva de aprendizado.
O custo humano. Engenheiro Cloud Pleno em São Paulo custa em média R$ 10.863 por mês, com faixa chegando a R$ 17.458 segundo dados do Glassdoor (base de 100 salários reportados). Multi-cloud sem um profissional dedicado não é uma estratégia de infraestrutura. É um acidente esperando para acontecer. Com esse profissional no time, é um custo fixo que se justifica só se o benefício concreto superar o salário mais os encargos.
A pesquisa Flexera 2025 mostra que 27% do gasto em cloud é desperdiçado mesmo em ambientes simples. Um ambiente com visibilidade ruim já tem esse problema. Dobrar o número de provedores sem antes resolver a visibilidade é dobrar o desperdício, não dividir o risco.
Os 3 casos onde multi-cloud faz sentido mesmo para empresa pequena
Multi-cloud não é errado por natureza: há três situações onde a conta fecha mesmo para empresa pequena.
1. Você tem requisito regulatório de redundância geográfica entre provedores distintos. Isso acontece em segmentos regulados como saúde e finanças, onde o regulador exige que o dado não fique em infraestrutura de um único operador. Se você está nessa situação, você provavelmente já sabe disso e já tem assessoria jurídica orientando a decisão.
2. Você usa um serviço específico que só existe em um provedor e que não tem equivalente nos outros. Exemplo: você usa o BigQuery do Google para analytics porque o volume e o modelo de cobrança fazem sentido para o seu caso, mas o resto da operação roda em AWS. Isso é multi-cloud por necessidade de funcionalidade, não por estratégia de redundância. É aceitável se o custo do egresso e a complexidade de integração forem menores do que a alternativa.
3. Um cliente exige que você entregue o serviço no ambiente deles, que é de um provedor diferente do seu. Nesse caso, você está operando em dois clouds porque o contrato exige, não por escolha estratégica. A gestão continua complexa, mas a justificativa é clara.
Fora esses três casos, a relação custo-benefício raramente fecha para PME.
O que resolve o lock-in sem precisar de um segundo provedor
Se o vendor lock-in é a preocupação real, há caminhos mais baratos e mais simples do que adicionar um segundo provedor.
Backups em destino diferente do provedor principal. Seus dados críticos em AWS podem ter backup automatizado para um storage fora da AWS, como Cloudflare R2 ou Backblaze B2, a uma fração do custo do egresso para outro cloud grande. Isso resolve o risco de perda de dados sem criar dependência operacional dupla.
Múltiplas zonas de disponibilidade dentro do mesmo provedor. Se o medo é indisponibilidade, a resposta correta é usar as zonas de disponibilidade que todos os grandes provedores oferecem. Um ambiente bem configurado em duas zonas de disponibilidade dentro da mesma região resolve 99% dos cenários de falha que uma PME vai encontrar na prática.
Containers e ferramentas portáveis por padrão. Usar Kubernetes em vez de serviços proprietários de orquestração, PostgreSQL em vez de bancos proprietários, e ferramentas de CI/CD que não são específicas de um provedor, reduz o lock-in real sem operar dois ambientes. A portabilidade vem da escolha de tecnologia, não do número de provedores.
Acordos de nível de serviço negociados. Contratos com SLAs documentados e penalidades por indisponibilidade mudam a equação de poder com o provedor. É menos dramático do que rodar em dois clouds, mas é mais efetivo para a maioria das PMEs.
O HashiCorp Cloud Complexity Report 2025 mapeou que operadores de plataforma cloud conhecem com precisão como apenas 20% da sua infraestrutura é gerenciada. O restante é uma mistura de scripts, tickets e improviso. Adicionar um segundo provedor a um ambiente que já tem esse nível de visibilidade é aumentar o problema, não resolver.
Como avaliar se o seu caso específico justifica a complexidade: critério objetivo em 4 perguntas
Antes de qualquer conversa com provedor ou consultoria, responda essas quatro perguntas. Elas não requerem especialista técnico.
1. Você tem pelo menos um engenheiro com experiência real nos dois ambientes que pretende usar, disponível em tempo integral? Se a resposta é não, pare aqui. Multi-cloud sem esse profissional vai custar mais do que economizar em qualquer horizonte de doze meses.
2. O seu maior risco de lock-in vem do provedor ou da tecnologia que você escolheu usar dentro dele? Se você usa serviços proprietários como Lambda, DynamoDB ou Cloud Run, o problema é a tecnologia, não o provedor. Trocar de tecnologia é mais barato do que adicionar um provedor.
3. Qual é o custo mensal de egresso de dados se você operar os dois ambientes integrados? Pegue o volume de dados que sua aplicação movimenta e multiplique por R$ 0,86/GB (egresso São Paulo na AWS). Se o número for maior do que 5% do seu custo total de cloud, a conta não fecha.
4. Você tem um requisito regulatório, contratual ou de disponibilidade que exige explicitamente dois provedores distintos? Se sim, multi-cloud pode ser a única saída. Se não, você provavelmente está considerando multi-cloud por precaução, não por necessidade.
Se pelo menos uma das quatro perguntas acima não tem resposta clara, o ambiente atual precisa ser revisado antes de qualquer expansão. Adicionar um segundo provedor num ambiente que já tem pontos cegos não reduz risco: redistribui onde o problema vai aparecer.
Se depois dessas quatro perguntas você ainda não tem clareza se o seu ambiente de cloud está dimensionado corretamente para o tamanho e o risco do negócio, a Coffe&Code Labs faz esse diagnóstico. A gente analisa o que você usa hoje, identifica onde você está pagando por complexidade que não gera retorno e entrega um plano direto. Sem a mediação de quem tem interesse em vender mais ambiente. Fale com a gente.