AWS, Azure ou Google Cloud: como escolher para colocar seu site ou API no ar

Quem esta saindo de um VPS ou comecando um projeto do zero costuma travar na mesma pergunta: AWS, Azure ou Google Cloud? A duvida nao e falta de informacao, e excesso dela. As tres documentacoes oficiais somam milhares de paginas, e nenhuma delas responde diretamente a pergunta que realmente importa: qual eu escolho para o meu caso, agora?

Este guia nao explica o que e cada cloud do zero, isso a documentacao oficial ja faz melhor do que qualquer resumo. O objetivo aqui e outro: dar um framework de decisao pratico, comparar as tres lado a lado nos cenarios mais comuns de uma pequena empresa ou time enxuto, e apontar os erros que custam caro depois.

1. Por que essa decisao trava tanto

As tres clouds resolvem os mesmos problemas de formas diferentes, com nomes diferentes para servicos parecidos. Isso cria duas armadilhas: escolher pela marca mais conhecida sem avaliar o caso real, ou tentar estudar as tres a fundo antes de decidir e nunca sair do papel. Nenhuma das duas funciona. A escolha certa depende de tres fatores, nesta ordem de prioridade: o que a sua equipe ja conhece, o tipo de carga que voce vai rodar (site estatico, API, banco de dados, containers) e o quanto de complexidade operacional voce quer assumir.

2. O que cada cloud e, na pratica (nao na teoria)

• AWS (Amazon Web Services): a mais antiga e com o maior catalogo de servicos das tres. Vantagem pratica: e a que tem mais tutorial, mais resposta no Stack Overflow e mais gente que ja resolveu o mesmo problema que voce. Desvantagem: exatamente por ter mais opcoes, e mais facil se perder escolhendo o servico errado para o caso simples.
• Azure (Microsoft): forte em empresas que ja usam ecossistema Microsoft (Active Directory, Office 365, .NET). Servicos de PaaS (plataforma gerenciada) como o Azure App Service costumam ser mais diretos de configurar para quem quer subir uma API sem lidar com infraestrutura.
• Google Cloud (GCP): historicamente mais forte em dados e IA, mas o Cloud Run (execucao de containers sem servidor) e hoje uma das formas mais simples das tres clouds de colocar uma API no ar sem gerenciar maquina nem cluster.

3. Comparativo direto por cenario

Em vez de descrever cada cloud isoladamente, compare como as tres resolvem o mesmo problema:

Hospedar um site estatico (landing page, documentacao, frontend SPA)

• AWS: S3 (armazenamento) + CloudFront (CDN) + Route 53 (DNS). Combinacao mais documentada do mercado, mas exige configurar 3 servicos separados.
• Azure: Static Web Apps resolve hospedagem, CDN e deploy continuo integrado em um unico servico, com menos peca para configurar manualmente.
• Google Cloud: Cloud Storage + Cloud CDN. Configuracao parecida com a da AWS, com menos exemplos prontos disponiveis.

Rodar uma API sem gerenciar servidor

• AWS: App Runner (mais simples) ou ECS com Fargate (mais controle, mais configuracao). App Runner e mais novo e tem ecossistema de exemplos menor.
• Azure: Azure Container Apps, equivalente direto ao Cloud Run, com escala automatica e cobranca por uso.
• Google Cloud: Cloud Run e hoje a opcao mais direta das tres para subir um container e receber uma URL publica funcionando, com boa relacao entre simplicidade e controle.

Banco de dados gerenciado

• AWS: RDS (bancos relacionais como PostgreSQL e MySQL) ou DynamoDB (NoSQL gerenciado, alta escala).
• Azure: Azure SQL Database ou Cosmos DB (NoSQL multi-modelo).
• Google Cloud: Cloud SQL (relacional) ou Firestore (NoSQL orientado a aplicacoes web e mobile).

Nos tres casos, comecar com banco relacional gerenciado (RDS, Azure SQL ou Cloud SQL) costuma ser a escolha mais segura para quem vem de um modelo relacional tradicional. NoSQL gerenciado (DynamoDB, Cosmos DB, Firestore) so compensa quando ha um motivo tecnico claro, como volume de escrita muito alto ou modelo de dados naturalmente nao relacional.

4. Framework de decisao pratico

Em vez de comparar feature por feature, responda estas perguntas na ordem:

1. A equipe ja conhece alguma das tres? Se sim, comece por ela. O custo de aprendizado de uma cloud nova raramente compensa para um projeto pequeno.
2. O que voce precisa rodar agora? Site estatico, API stateless ou algo que ja usa Docker Compose muda a resposta (ver comparativo acima).
3. Voce tem alguem dedicado a infraestrutura? Sem isso, prefira sempre a opcao mais gerenciada disponivel (Cloud Run, Azure Container Apps, App Runner) em vez de montar cluster Kubernetes proprio (EKS, AKS, GKE) para um projeto pequeno.
4. Existe alguma exigencia externa? Cliente, parceiro ou politica de compliance que já define a cloud (comum em empresas que vendem para o governo dos EUA, por exemplo, e precisam de AWS GovCloud) elimina a escolha.

Se nenhuma das perguntas acima aponta uma direcao clara, a resposta pratica costuma ser: comece pela AWS, porque e a que tem mais solucao pronta documentada para qualquer problema que aparecer depois. Isso nao significa que ela seja tecnicamente superior, significa que o caminho de menor atrito para quem esta comecando tende a ser esse.

5. Custo: como comparar sem se enganar

Valores de referencia mudam com frequencia. Este artigo nao lista precos fixos porque eles ficam desatualizados rapido — sempre confirme o valor atual na calculadora oficial de precos de cada cloud antes de decidir.

• Nenhuma das tres e sempre mais barata. O resultado depende do servico especifico, da regiao escolhida e do volume de uso.
• O maior vilao de conta inesperada nao e o preco de computacao, e o custo de saida de dados (egress) — transferir dados para fora da cloud costuma ser cobrado, e quem vem de VPS com banda "incluida" se surpreende com isso.
• As tres oferecem algum nivel de camada gratuita (free tier), mas com regras diferentes: parte e limitada a 12 meses, parte e "sempre gratis" ate um limite de uso mensal. Teste o servico real antes de comprometer o projeto inteiro.
• Configure alerta de billing (nas tres clouds existe essa opcao) antes de qualquer teste, mesmo pequeno.

6. Erros comuns ao escolher

• Escolher pela cloud "mais famosa" sem considerar o que a equipe ja sabe.
• Provisionar Kubernetes gerenciado (EKS, AKS, GKE) para um projeto que caberia inteiro em um unico container serverless.
• Ignorar custo de egress ao migrar de um VPS com banda incluida.
• Tentar decidir entre as tres so pelo preco de computacao, sem simular o cenario completo na calculadora oficial.
• Comecar em multi-cloud (AWS + Azure + GCP ao mesmo tempo) para um projeto pequeno, adicionando complexidade operacional sem beneficio real nesse estagio.

7. Checklist antes de escolher

1. Liste o que voce precisa rodar agora: site estatico, API stateless, banco gerenciado ou containers ja existentes.
2. Verifique qual cloud a equipe ja conhece, mesmo que parcialmente.
3. Configure alerta de billing antes de qualquer teste.
4. Teste o servico gerenciado mais simples disponivel (Cloud Run, Container Apps ou App Runner) antes de partir direto para Kubernetes.
5. Simule o custo completo, incluindo egress, na calculadora oficial da cloud candidata.
6. Documente o motivo da escolha, para nao repetir a mesma discussao daqui a alguns meses.

Quem ja usa Docker, VPS e Nginx encontra no hub de cloud os proximos passos praticos para decidir se e quando migrar para uma cloud gerenciada.

Perguntas frequentes

Preciso saber Kubernetes para usar cloud? Nao, na maioria dos casos pequenos. Servicos serverless gerenciados (Cloud Run, Azure Container Apps, App Runner) resolvem sem exigir conhecimento de orquestracao de containers.

Qual cloud e mais barata? Nenhuma e sempre mais barata. O resultado depende do servico, da regiao e do volume de uso — sempre simule o cenario real na calculadora oficial antes de decidir.

Posso trocar de cloud depois? Sim, mas quanto mais voce usa servicos proprietarios especificos de uma cloud (banco de dados exclusivo, filas proprietarias), maior o esforco de migracao depois. Comecar com servicos mais portaveis (containers Docker padrao, banco relacional) reduz esse lock-in.