Como hospedar um site estático na AWS sem deixar o bucket S3 aberto ao público

Um projeto hands-on publicado no AWS Builder Center mostra como servir um site estático a partir de um bucket S3 totalmente privado, usando Origin Access Control do CloudFront, WAF e HTTPS obrigatório.

Publicado em 13 de novembro de 2026 no AWS Builder Center, o projeto RegPro, de Sandeepa Wimalasiri, resolve um problema comum: como hospedar um site estático sem depender do endpoint público de website hosting do S3. O repositório completo está disponível no GitHub (Sandeepa-git/Static-Website-Hosting-with-S3-and-CloudFront), e o passo a passo abaixo segue a arquitetura descrita na fonte, com o recorte que importa para quem desenha e opera ambientes AWS em produção: o trade-off entre conveniência e superfície de ataque.

O que você vai construir

A arquitetura separa armazenamento de entrega de conteúdo. O fluxo de requisição é: navegador do visitante → Amazon CloudFront → Origin Access Control (OAC) → bucket S3 privado. Isso significa que o bucket nunca fica acessível diretamente pela internet; só a distribuição CloudFront, usando uma identidade de serviço assinada com AWS Signature Version 4 (SigV4), consegue ler os objetos.

No projeto original, o bucket se chama sandeepa-regpro-website-2026, criado na região Europe (Stockholm, eu-north-1), hospedando um site de múltiplas páginas (index.html, contact.html, css/styles.css, js/main.js). A fonte não detalha adaptação para outras regiões; quem for reproduzir o projeto em outra região da AWS deve avaliar por conta própria eventuais ajustes no endpoint do bucket e nas configurações regionais.

Pré-requisitos

• Conta AWS com permissão para criar recursos em S3, CloudFront, WAF e, opcionalmente, ACM e Route 53.
• Uma política IAM que cubra a criação e configuração desses recursos (bucket S3, distribuição CloudFront, Web ACL do WAF e, se aplicável, certificado ACM); a fonte não detalha as ações IAM específicas, então vale desenhar a política mínima conforme a documentação de cada serviço.
• AWS CLI v2 instalada e configurada (aws configure ou um profile com as credenciais corretas).
• Os arquivos do site estático, mantendo a estrutura de diretórios original (CSS e JS referenciados por caminho relativo nos HTMLs).
• Se for usar domínio próprio: um certificado ACM solicitado na região us-east-1 (CloudFront só aceita certificados dessa região, mesmo que o site seja servido para o Brasil) e uma zona hospedada no Route 53.

Passo a passo

1. Criar o bucket S3 privado. Bucket de propósito geral, com Block all public access habilitado e criptografia padrão ativa. Diferente do site hosting tradicional do S3, este bucket nunca terá uma policy pública.
2. Fazer upload dos arquivos preservando a estrutura de pastas, para que index.html continue referenciando css/styles.css e js/main.js pelo caminho relativo correto.
3. Criar o Origin Access Control. No console do CloudFront, criar um OAC do tipo S3, com signing behavior Sign requests e signing protocol SigV4. É aqui que está a diferença central em relação ao modelo antigo: o CloudFront assina cada requisição à origem, e a origem só precisa confiar nessa assinatura.
4. Apontar a distribuição CloudFront para o endpoint REST do bucket, não para o endpoint de website estático. Essa é uma pegadinha comum: OAC exige o domínio regular do tipo <bucket>.s3.<região>.amazonaws.com, porque o endpoint de website hosting não suporta autenticação SigV4.
5. Configurar o comportamento de cache padrão, conforme a tabela usada no projeto:

1. Escrever a bucket policy que autoriza só a distribuição específica. O ponto crítico é a condição AWS:SourceArn: sem ela, qualquer distribuição CloudFront da conta (ou de outra conta, dependendo da configuração) poderia ler o bucket.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "AllowCloudFrontServicePrincipal",
 "Effect": "Allow",
 "Principal": { "Service": "cloudfront.amazonaws.com" },
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::sandeepa-regpro-website-2026/*",
 "Condition": {
 "StringEquals": {
 "AWS:SourceArn": "arn:aws:cloudfront::972224212800:distribution/E2N274ZOEWOET2"
 }
 }
 }
 ]
}

1. Integrar o AWS WAF à distribuição. Para produção, a fonte recomenda começar pelos AWS Managed Rules (proteção contra exploits web comuns), adicionar regras baseadas em taxa (rate-based rules) contra abuso, habilitar logging do WAF e revisar falsos positivos periodicamente antes de bloquear tráfego de verdade.
2. Automatizar o deploy com AWS CLI. Em vez de subir arquivos manualmente pelo console, sincronizar o diretório local com o bucket:

aws s3 sync . s3://sandeepa-regpro-website-2026 \
 --exclude "*.sh" \
 --exclude "*.md" \
 --exclude ".git/*" \
 --exclude "Screenshots/*"

aws cloudfront create-invalidation \
 --distribution-id E2N274ZOEWOET2 \
 --paths "/*"

O aws s3 sync sozinho não atualiza o que já está em cache nas edge locations; por isso a invalidação do CloudFront é parte obrigatória do fluxo, não um passo opcional.

Por que OAC em vez de OAI

Quem já mexeu com S3 e CloudFront antes de 2022 provavelmente configurou Origin Access Identity (OAI), o modelo anterior. OAC é o sucessor recomendado pela AWS porque, além de assinar requisições com SigV4, suporta objetos criptografados com SSE-KMS e permite restringir o acesso a uma distribuição CloudFront específica via AWS:SourceArn, algo que o OAI não fazia de forma nativa. Para arquitetura nova, não há razão para escolher OAI.

Testando

Após o deploy, a verificação segue uma checklist simples, direto contra o domínio da distribuição (no projeto, https://d1frun5ugmhz7e.cloudfront.net):

• Carregar a homepage (/) e a página de contato (/contact.html) e confirmar que o layout, CSS e JavaScript carregam sem erro 403 ou 404.
• Fazer uma requisição HTTP simples e confirmar o redirect para HTTPS (código 301/302 seguido de conexão TLS).
• Verificar, pelo console do CloudFront ou pelos logs, que as requisições de origem estão sendo assinadas e aceitas pelo S3.

O maior aprendizado foi entender que uma arquitetura segura deve controlar não só quem acessa uma aplicação, mas também como a própria aplicação acessa seus recursos subjacentes.

One of the most important lessons was understanding that a secure architecture should control not only who can access an application, but also how the application accesses its underlying resources.Sandeepa Wimalasiri, autor do projeto RegPro

Limpando os recursos

CloudFront e S3 não geram custo relevante parado, mas distribuições e regras de WAF ativas continuam sendo cobradas. A sequência de limpeza usada no projeto é:

1. Desabilitar a distribuição CloudFront (não dá para deletar uma distribuição ativa direto).
2. Aguardar a propagação da mudança de status (pode levar alguns minutos).
3. Deletar a distribuição CloudFront.
4. Esvaziar o bucket S3 (aws s3 rm s3://sandeepa-regpro-website-2026 --recursive ou equivalente).
5. Deletar o bucket S3.
6. Remover registros do Route 53 e certificados ACM que não serão mais usados, se houver domínio próprio configurado.
7. Revisar e remover Web ACLs do WAF associadas à distribuição, para evitar cobranças de recursos esquecidos.

A fonte não traz valores de preço, mas reforça o ponto que vale para qualquer arquitetura desse tipo: revisar o billing depois de desmontar os recursos, porque Web ACL e regras do WAF esquecidas continuam cobrando mesmo sem a distribuição associada ativa.

Próximos passos

O projeto documenta um blueprint de CI/CD com GitHub Actions para automatizar o deploy a cada push na branch principal, recomendando GitHub Actions OIDC com uma role IAM restrita em vez de guardar chaves de acesso de longa duração no repositório, prática que qualquer time de DevOps deveria tratar como padrão mínimo, não como extra.

Para quem leva essa arquitetura para produção de verdade, os pontos que ficam em aberto na fonte e valem investigação própria são: versionar a infraestrutura com CDK ou Terraform em vez de criar os recursos manualmente pelo console, adicionar CloudFront Functions para normalização de headers de segurança (CSP, HSTS), e avaliar se o caso de uso justifica múltiplas origens (failover entre regiões) em vez de um único bucket S3.

Fonte

1. AWS Builder Center: Building a Secure and Scalable Static Website Hosting Architecture with Amazon S3 and CloudFront OAC

Fonte: AWS Builder Center