A maioria das empresas já é multi-cloud. A questão é se isso foi escolha ou acidente

O relatório State of Cloud Strategy 2024 da HashiCorp mostrou que 81% das empresas já operam em mais de um provedor de nuvem. Mas tem um detalhe que costuma passar batido: boa parte dessas empresas não planejou isso. O que aconteceu foi mais orgânico, um departamento adotou AWS por conta própria, o time de produtividade já estava no Microsoft 365 e puxou workloads para o Azure, e quando o CIO olhou o mapa, tinha dois (ou três) providers rodando sem nenhuma estratégia multi-cloud Azure AWS coordenada.

E aí mora o problema. Multi-cloud acidental não é estratégia. É bagunça com dois boletos.

Este artigo é para quem quer sair desse cenário, ou para quem está avaliando se combinar Azure e AWS de forma deliberada traz ganho real. Spoiler: às vezes traz, às vezes não. E o “às vezes” depende de variáveis que raramente aparecem nos slides bonitos dos vendors.

Quando combinar Azure e AWS faz sentido de verdade

Existem situações em que rodar duas clouds diferentes é uma decisão técnica sólida, não capricho de arquiteto. O ponto é que essas situações precisam ser específicas o suficiente para justificar a complexidade extra.

Aproveitar o que cada provider faz melhor

Não é segredo que Azure e AWS têm especializações diferentes. A AWS saiu na frente em serviços de infraestrutura pura ou compute, storage, Lambda para serverless e construiu um portfólio gigantesco de serviços para desenvolvedores. Se sua empresa roda e-commerce pesado, usa marketplaces ou tem aplicações com picos de demanda imprevisíveis, a AWS tem um histórico difícil de bater.

Já o Azure tem uma integração nativa com o ecossistema Microsoft que ninguém consegue replicar. Se sua empresa vive dentro do Microsoft 365 e a maioria das empresas brasileiras de médio e grande porte vive colocar workloads no Azure simplifica autenticação (Entra ID, antigo Azure AD), compliance, governança e até licenciamento. Muitas licenças Enterprise Agreement da Microsoft já incluem créditos Azure. Deixar isso na mesa é, no mínimo, descuido financeiro.

A combinação faz sentido quando você identifica que uma parte das suas cargas se beneficia claramente de um provider, e outra parte do outro. Não por teoria por teste de carga, por custo medido, por funcionalidade que só existe ali.

Compliance e distribuição geográfica de dados

A LGPD (Lei 13.709/2018) não exige explicitamente que dados fiquem em data centers brasileiros, mas algumas regulações setoriais sim e mesmo quando não exigem, ter dados em território nacional facilita discussões com auditorias e com o jurídico. Tanto Azure quanto AWS têm regiões no Brasil (São Paulo para ambos, com a AWS tendo adicionado capacidade ao longo dos últimos anos), mas dependendo do serviço específico, a disponibilidade varia.

Tem cenários em que uma empresa precisa rodar certos workloads em uma região onde só um provider tem presença adequada. Ou precisa de redundância geográfica real, não dois availability zones no mesmo provider, mas dois providers independentes para um serviço crítico. Bancos e operadoras de saúde lidam com isso com frequência.

Integrações com ecossistemas pré-existentes

Esse talvez seja o motivo mais comum e menos glamoroso. A empresa já usa Microsoft 365 para tudo como e-mail, Teams, SharePoint, Power BI e naturalmente gravita para o Azure em identidade, segurança e parte do backend. Mas o time de desenvolvimento já construiu toda a pipeline de CI/CD na AWS, usa CodePipeline, tem anos de experiência com EC2, RDS e S3.

Forçar tudo para um lado só criaria atrito, retrabalho e, provavelmente, um ou dois pedidos de demissão de devs insatisfeitos. A estratégia multi-cloud aqui não é glamour de arquitetura é pragmatismo.

Outro caso concreto: empresas de varejo que operam marketplaces (Mercado Livre, Amazon Marketplace) e já têm integrações pesadas com serviços AWS. Mover isso para Azure não traz nenhum benefício, mas o backoffice corporativo e a camada de produtividade vivem no mundo Microsoft. Dois providers, cada um fazendo o que faz bem, com fronteiras claras.

Redução de vendor lock-in (com ressalvas)

O argumento de evitar vendor lock-in cloud é válido, mas precisa de uma dose de realismo. Nenhuma empresa vai migrar de AWS para Azure em um fim de semana se o provider “pisar na bola” ou subir preços abruptamente. A portabilidade real exige que as aplicações tenham sido desenhadas para isso, com containers, com abstração de serviços, com infrastructure as code. Se você usou 47 serviços gerenciados proprietários da AWS, trocar de cloud é um projeto de 18 meses, não uma decisão de sexta-feira.

Dito isso, ter parte dos workloads em cada provider dá poder de negociação. Quando chega a hora de renovar o Enterprise Agreement ou renegociar o Reserved Instances commitment, poder dizer “tenho alternativa” muda o tom da conversa. Todo gestor de TI que já negociou contrato sabe o que é tentar conseguir desconto de um fornecedor que sabe que você não tem para onde ir.

Quando multi-cloud é uma péssima ideia

E aqui é onde a conversa fica menos confortável, porque a maioria dos conteúdos sobre multi-cloud pula essa parte. Mas se você toma decisões de infraestrutura com base só nos argumentos “a favor”, está fazendo metade da análise.

Empresas menores que vão dobrar complexidade sem ganho proporcional

Uma empresa com 200 funcionários, dois ou três sistemas internos e um e-commerce médio provavelmente não precisa de multi-cloud. O que ela precisa é de uma cloud bem configurada, com governança, com FinOps básico, com monitoramento decente. Colocar Azure e AWS juntos nesse contexto significa que o time de TI que muitas vezes tem três ou quatro pessoas pode precisar dominar dois painéis de gerenciamento, dois modelos de precificação, duas formas de configurar rede, duas ferramentas de monitoramento.

O custo operacional escondido é brutal. Não estou falando só de dinheiro, estou falando de atenção dividida, de incidentes que demoram mais para diagnosticar porque o time não sabe se o problema está na ponte entre as duas clouds ou dentro de uma delas.

Equipes sem expertise dupla

Ter gente boa em AWS é difícil. Ter gente boa em Azure é difícil. Ter gente boa nos dois ao mesmo tempo é raro e caro. O mercado brasileiro de profissionais cloud está aquecido (o relatório Flexera 2024 State of the Cloud aponta que falta de profissionais qualificados segue como desafio número um em cloud), e um engenheiro sênior que domina os dois providers com profundidade vai custar caro, se você conseguir contratar.

A alternativa é ter um time para cada cloud, o que infla a folha e cria silos. Ou depender de um parceiro externo que tenha essa capacidade, o que é viável mas precisa ser planejado desde o início.

Custos de transferência de dados entre clouds (egress)

Esse é o elefante na sala. Transferir dados para dentro da cloud é grátis (ou quase). Transferir dados para fora custa dinheiro. E transferir dados entre duas clouds diferentes custa dinheiro dos dois lados.

Se sua arquitetura multi-cloud exige que um serviço na AWS converse frequentemente com um serviço no Azure, trocando grandes volumes de dados, a conta de egress pode tornar a operação inviável financeiramente. Já vi empresa que economizou em compute escolhendo o provider mais barato para cada workload, mas devolveu toda a economia (e um pouco mais) em custos de transferência entre os dois.

Antes de decidir por multi-cloud, faça a conta de egress. Pegue o padrão real de tráfego entre os workloads, estime o volume mensal e calcule. Se o número assustar, reconsidere a distribuição, ou redesenhe para minimizar a comunicação entre clouds.

Se a sua empresa está avaliando essa equação entre custo, complexidade e benefício real da nuvem, vale conversar com quem já ajudou outras empresas a fazer essa conta. A Omega Brasil oferece consultoria em infraestrutura de TI corporativa com foco em decisões que fazem sentido técnico e financeiro, não em vender cloud por vender.

Ferramentas que tornam multi-cloud gerenciável

Se depois de pesar prós e contras a decisão for seguir com Azure e AWS juntos, o próximo passo é garantir que a operação não vire um Frankenstein. Algumas ferramentas ajudam bastante, mas nenhuma delas é mágica.

Terraform para infrastructure as code multi-cloud

O Terraform, da HashiCorp, é provavelmente a ferramenta mais usada para gerenciar infraestrutura em múltiplos providers com uma linguagem declarativa só (HCL). Você define o que quer VMs, redes, storage e o Terraform provisiona tanto na AWS quanto no Azure.

Isso não torna a infraestrutura portável automaticamente (os recursos de cada cloud continuam sendo diferentes), mas padroniza o processo de provisionamento e cria uma fonte única de verdade sobre o que está rodando onde. Para auditoria e governança, isso vale ouro.

Kubernetes para workloads portáveis

Se os workloads rodam em containers, Kubernetes é a camada de abstração que permite mover cargas entre AKS (Azure Kubernetes Service) e EKS (Elastic Kubernetes Service da AWS) com relativa facilidade. “Relativa” porque na prática sempre tem configuração de rede, storage e secrets que é específica de cada provider. Mas o esforço de portabilidade cai de meses para dias quando a base é Kubernetes.

Para empresas brasileiras de médio porte, o desafio aqui é ter equipe que domine Kubernetes com profundidade. A curva de aprendizado é íngreme, e um cluster mal configurado gera mais problemas do que resolve.

Azure Arc e Google Anthos para gestão unificada

O Azure Arc permite gerenciar recursos que estão fora do Azure (incluindo na AWS ou on-premises) através do portal do Azure. Isso é interessante para empresas que têm mais afinidade com o ecossistema Microsoft e querem um painel único sem abrir mão dos recursos AWS. Na prática, funciona melhor para cenários hybrid cloud, servidores on-premises + cloud, do que para multi-cloud puro, mas está evoluindo.

O Anthos, do Google Cloud, faz proposta semelhante. Permite rodar workloads Kubernetes em qualquer lugar GCP, AWS, Azure, on-premises, com gestão centralizada. É uma boa ferramenta, mas adiciona um terceiro provider na equação, o que pode ou não ser desejável.

A escolha entre essas opções depende de onde o centro de gravidade da sua operação está. Se sua empresa já tem forte presença Microsoft licenciamento Microsoft 365 corporativo, Entra ID, Intune, o Azure Arc é a extensão natural. Se a equipe é mais cloud-agnostic e vive no mundo Kubernetes, Anthos ou soluções open source como Crossplane podem fazer mais sentido.

Multi-cloud no Brasil: o que os números dizem

O relatório Flexera 2024 State of the Cloud Report mostra que 89% das empresas globais adotam alguma forma de multi-cloud. No Brasil, a tendência segue a mesma direção, mas com particularidades importantes.

Primeiro, o mercado brasileiro tem forte influência da Microsoft por causa da penetração do Microsoft 365 e do Windows Server no ambiente corporativo. Isso puxa naturalmente uma parcela significativa dos workloads para o Azure. A AWS, por outro lado, domina entre empresas de tecnologia, startups que cresceram e operações de e-commerce, mercados onde a AWS chegou primeiro e criou raízes profundas.

Segundo, o custo de banda no Brasil ainda é alto comparado com mercados maduros. Isso torna os custos de egress entre clouds proporcionalmente mais dolorosos. Uma arquitetura multi-cloud que funcionaria bem nos EUA pode gerar surpresas desagradáveis na fatura quando replicada aqui sem ajuste.

Terceiro, a disponibilidade de profissionais qualificados em cloud no Brasil está melhorando, mas continua sendo gargalo. Encontrar um arquiteto cloud sênior que conheça bem Azure e AWS, entenda LGPD, saiba negociar contratos e fale a língua do CFO, isso não se resolve postando vaga no LinkedIn.

Azure vs AWS: não é futebol, não precisa torcer para um só

Uma coisa que incomoda nas discussões sobre Azure vs AWS é o tom de rivalidade esportiva. Como se você precisasse declarar lealdade a um provider e defender até o fim. Na prática, são ferramentas. Boas ferramentas, com forças e fraquezas diferentes.

O Azure tem melhor integração com Active Directory, melhor suporte a ambientes Windows Server, licenciamento mais vantajoso para quem já tem contratos Microsoft, e uma suite de compliance (Purview, Defender for Cloud) que conversa nativamente com o M365.

A AWS tem mais serviços disponíveis (mais de 200 na última contagem), uma comunidade de desenvolvedores maior, documentação mais madura para muitos cenários, e geralmente ganha em precificação granular de compute para workloads específicos.

Para um CIO ou gestor de TI brasileiro, a pergunta certa não é “qual é melhor” é “qual é melhor para cada parte do meu ambiente, considerando o que eu já tenho, o que meu time sabe fazer, e quanto eu posso gastar”.

Como começar uma estratégia multi-cloud sem tropeçar

Se a análise até aqui confirmou que multi-cloud faz sentido para sua empresa, aqui vão pontos práticos para não transformar a decisão em dor de cabeça.

1. Mapeie o que você já tem. Antes de qualquer decisão de arquitetura, faça um inventário honesto dos workloads atuais, onde rodam, quanto custam e quais dependências têm. Sem isso, qualquer estratégia é chute.
2. Defina fronteiras claras. Multi-cloud funciona melhor quando cada provider tem um papel bem definido. “Azure para produtividade e identidade, AWS para aplicações e dados de e-commerce” é uma fronteira clara. “Vamos usar os dois para tudo” é receita para confusão.
3. Calcule o custo real, incluindo egress e pessoal. Todo business case de cloud que só olha preço de VM por hora está incompleto. Inclua transferência de dados, custo de ferramentas de gestão, treinamento de equipe e eventual contratação de especialistas.
4. Comece com IaC desde o dia um. Se vai operar em duas clouds, Terraform ou Pulumi são obrigatórios. Provisionar infraestrutura manualmente em dois consoles é pedir para ter drift de configuração e dívida técnica em seis meses.
5. Tenha um parceiro que conheça os dois lados. Não é propaganda, é realidade operacional. A curva de aprendizado de gerenciar duas clouds simultaneamente é íngreme, e erros custam caro. Ter alguém que já fez isso antes encurta o caminho.

Hybrid cloud não é a mesma coisa que multi-cloud (e isso importa)

Vale esclarecer uma confusão comum. Hybrid cloud é quando você combina infraestrutura on-premises (seu data center) com cloud pública. Multi-cloud é quando você usa duas ou mais clouds públicas. As duas coisas podem coexistir e frequentemente coexistem mas os desafios são diferentes.

Uma empresa que tem servidores físicos no escritório conectados ao Azure via ExpressRoute está fazendo hybrid cloud. Se ela também roda workloads na AWS, aí é hybrid + multi-cloud. A complexidade se multiplica, não se soma.

Para empresas brasileiras que ainda têm investimento significativo em hardware on-premises, a transição geralmente passa por hybrid cloud antes de chegar em multi-cloud puro. Tentar pular direto para multi-cloud sem resolver a camada híbrida é construir o segundo andar antes de terminar o térreo.

A decisão de multi-cloud é, acima de tudo, uma decisão de negócio

Depois de toda a análise técnica, o que define se multi-cloud é certo para sua empresa não é a tecnologia é o contexto do negócio. Qual é o apetite de risco? Qual é a capacidade real da equipe? Quanto o CFO está disposto a investir em complexidade operacional em troca de flexibilidade futura? Existe pressão regulatória que force distribuição de dados?

Essas perguntas não têm resposta técnica. Têm resposta estratégica. E por isso a decisão de adotar (ou não adotar) uma estratégia cloud agnostic precisa envolver não só a TI, mas finanças, jurídico e a diretoria.

O que não dá é para decidir multi-cloud porque “todo mundo está fazendo” ou porque o slide do fornecedor ficou bonito na apresentação. Cada empresa tem suas restrições, seus legados, seu orçamento, seu time. A estratégia precisa caber nessa realidade, não em uma realidade idealizada.

Perguntas frequentes sobre estratégia multi-cloud

Quanto custa operar em multi-cloud comparado com single cloud?

Não existe um percentual fixo, porque depende muito da arquitetura e do volume de dados transferidos entre providers. O que se pode dizer com segurança é que os custos operacionais (ferramentas de gestão, profissionais especializados, treinamento) são maiores em multi-cloud. O relatório Flexera 2024 aponta que o desperdício médio de gastos em cloud gira em torno de 28% e em ambientes multi-cloud, esse desperdício tende a ser maior pela dificuldade de visibilidade unificada. O ganho precisa vir de negociação de contratos, otimização de workloads por provider e redução de risco. Se esses ganhos não compensam o custo extra, single cloud bem gerenciada é a melhor escolha.

É possível ter uma estratégia multi-cloud sem Kubernetes?

Sim. Kubernetes facilita a portabilidade de workloads, mas não é pré-requisito. Muitas empresas operam multi-cloud com workloads diferentes e independentes em cada provider sem necessidade de mover cargas entre eles. Nesse modelo, cada cloud roda aplicações específicas e a “multi-cloudness” está na distribuição de responsabilidades, não na portabilidade. O Terraform, por exemplo, ajuda a padronizar o provisionamento sem exigir containers.

Conclusão prática

Estratégia multi-cloud com Azure e AWS juntos faz sentido quando há motivos concretos: integração com ecossistemas diferentes, requisitos de compliance, aproveitamento de especializações de cada provider, e poder de negociação com fornecedores. Não faz sentido quando a empresa não tem equipe preparada, quando os workloads não justificam a separação, ou quando os custos de egress consomem qualquer economia.

A decisão precisa ser baseada em dados custo real, padrão de tráfego, capacidade do time, contexto regulatório e não em tendências de mercado. Multi-cloud bem feito é vantagem competitiva. Multi-cloud mal feito é custo duplicado com risco aumentado.

Se você está nesse ponto de decisão, avaliando se mantém tudo em um provider, distribui entre dois, ou precisa primeiro arrumar a casa antes de pensar em multi-cloud. A Omega Brasil ajuda sua empresa a desenhar estratégia cloud baseada em critérios técnicos e financeiros. Com experiência em ambientes Microsoft Azure e AWS, a equipe faz a análise que precisa ser feita antes de qualquer migração ou expansão: o que você tem, o que faz sentido, e quanto vai custar de verdade. Solicite uma consultoria com a Omega Brasil.