Como hospedar um site estatico na nuvem: AWS, Azure e Google Cloud passo a passo

Hospedar um site estatico ou uma SPA (React, Vue, aplicacao gerada por build) e o primeiro passo mais comum de quem esta testando uma cloud pela primeira vez. Parece simples, e cada cloud documenta o proprio caminho em detalhe — mas nenhuma documentacao oficial junta as tres lado a lado, nem avisa sobre as pegadinhas que so aparecem depois do primeiro deploy.

Este guia segue o passo a passo real das tres clouds, com o que costuma dar errado em cada uma. Se voce ainda nao decidiu qual cloud usar, veja primeiro o artigo AWS, Azure ou Google Cloud: como escolher.

1. AWS: S3 + CloudFront + Route 53

A combinacao mais documentada do mercado, em 5 passos:

1. Crie um bucket S3 e faca upload dos arquivos de build (nao configure o bucket como publico — a pratica recomendada hoje e manter o bucket privado e usar CloudFront com Origin Access Control, OAC, para servir o conteudo).
2. Crie uma distribuicao CloudFront apontando para o bucket como origem, com OAC habilitado.
3. Configure o "default root object" como index.html e, para SPA, configure as paginas de erro 403 e 404 para redirecionar para index.html com status 200 — sem isso, recarregar uma rota interna da SPA (ex.: /sobre) retorna erro em vez de carregar a aplicacao.
4. Solicite um certificado no AWS Certificate Manager (sempre na regiao us-east-1, mesmo que o resto da infraestrutura esteja em outra regiao — CloudFront exige isso) e associe o dominio customizado a distribuicao.
5. Aponte o DNS do dominio (Route 53 ou outro provedor, como Cloudflare) para o dominio da distribuicao CloudFront via CNAME ou registro ALIAS.

2. Azure: Static Web Apps

O fluxo mais direto das tres, pensado para menos configuracao manual:

1. Crie um recurso Azure Static Web Apps, normalmente conectando direto a um repositorio Git (GitHub ou Azure DevOps) — o servico ja cria um pipeline de deploy automatico a partir dai.
2. CDN, certificado TLS gerenciado e deploy continuo vem inclusos no mesmo servico, sem precisar configurar pecas separadas.
3. Para SPA, configure o arquivo staticwebapp.config.json na raiz do projeto com uma regra de fallback de rota apontando para index.html, equivalente ao que a AWS exige configurar manualmente no CloudFront.
4. Adicione o dominio customizado direto pelo portal Azure, que gerencia certificado TLS automaticamente para o dominio.

3. Google Cloud: Cloud Storage + Cloud CDN

O caminho tecnicamente mais trabalhoso das tres quando o requisito e dominio customizado com HTTPS:

1. Crie um bucket Cloud Storage e faca upload dos arquivos de build, configurando as paginas de index e erro do bucket.
2. Diferente da AWS e da Azure, servir o bucket com dominio customizado e HTTPS no Google Cloud exige um Load Balancer HTTP(S) externo na frente do bucket — o bucket sozinho nao expõe HTTPS em dominio proprio.
3. Configure o Load Balancer com o bucket como backend, ative o Cloud CDN na configuracao do backend.
4. Solicite um certificado SSL gerenciado pelo Google associado ao Load Balancer e aponte o DNS do dominio (Cloud DNS ou outro provedor) para o IP publico do Load Balancer.
5. Para SPA, configure o comportamento de "not found page" do bucket para retornar index.html — o efeito e equivalente ao fallback de rota das outras duas clouds.

Esse passo extra do Load Balancer e o motivo pratico pelo qual muita gente que testa as tres clouds acha o Google Cloud "mais dificil" para esse caso especifico — nao e falta de documentacao, e uma peca a mais na arquitetura mesmo.

4. Pegadinhas que aparecem depois do primeiro deploy

• Cache desatualizado: a CDN (CloudFront, a CDN embutida do Static Web Apps, ou o Cloud CDN) guarda uma copia do conteudo antigo por padrao. Depois de um novo deploy, se o visitante continuar vendo a versao antiga, o cache precisa ser invalidado manualmente (na AWS, via aws cloudfront create-invalidation; no Google Cloud, via gcloud compute url-maps invalidate-cdn-cache) ou reduzido via cache-control apropriado, especialmente no index.html.
• Rota de SPA quebrada: sem configurar o fallback de rota (item comum aos 3 passo a passo acima), recarregar qualquer rota interna da aplicacao alem da raiz retorna erro 403/404 em vez de carregar a SPA.
• Bucket publico por engano: configurar o bucket S3 ou Cloud Storage como publico diretamente (em vez de servir via CDN com controle de acesso) expõe o conteudo sem controle e e considerado praticas ultrapassada de seguranca hoje em dia.
• Certificado na regiao errada (AWS): esquecer que o certificado do CloudFront precisa estar em us-east-1 e uma das causas mais comuns de dominio customizado nao funcionar na AWS.
• Custo de Load Balancer subestimado (GCP): diferente de um bucket simples, um Load Balancer HTTP(S) tem custo fixo mensal proprio, mesmo com trafego baixo — vale simular esse custo na calculadora oficial antes de assumir que "e so um site estatico".

5. Checklist antes de considerar o deploy pronto

1. Build de producao gerado localmente e testado antes do upload.
2. Upload feito para o bucket/servico correto, sem bucket configurado como publico direto.
3. Fallback de rota configurado para SPA (paginas de erro na AWS, staticwebapp.config.json na Azure, not found page no GCP).
4. Dominio customizado apontado e certificado TLS emitido e validado.
5. Estrategia de invalidacao de cache definida para cada novo deploy.
6. Teste em janela anonima/privada apos o deploy, para confirmar que a CDN esta servindo a versao nova.

Depois de validar a hospedagem estatica, o proximo passo pratico costuma ser decidir entre os servicos de containers e API das tres clouds, ou revisar o hub de DevOps se o projeto ainda depende de VPS.

Perguntas frequentes

Preciso de Load Balancer para hospedar site estatico em qualquer cloud? Nao. Isso e uma exigencia especifica do Google Cloud quando o requisito e dominio customizado com HTTPS. AWS e Azure resolvem isso sem um recurso de Load Balancer separado.

O Azure Static Web Apps e realmente gratuito? Existe um nivel gratuito, mas com limites de uso (banda, numero de dominios customizados) que mudam com frequencia — confirme sempre na pagina de precos oficial atual.

Como evitar que visitantes vejam uma versao antiga do site? Definindo uma estrategia de invalidacao de cache a cada deploy (manual ou automatizada no pipeline) e configurando cache curto para o index.html, mesmo que os demais arquivos tenham cache mais longo.