O que você vai colocar no ar (resultado final)
O objetivo prático deste capítulo é deixar claro o “desenho” do que será hospedado: um site acessível por um domínio (ex.: www.suaempresa.com) com HTTPS (cadeado no navegador), com uma origem de conteúdo (onde os arquivos ou a aplicação vivem) e camadas mínimas de segurança. Pense em um cenário-alvo simples: uma página institucional com poucas seções (Home, Sobre, Contato) e, opcionalmente, um formulário que envia dados para um backend.
O que significa “publicar um site com HTTPS” na AWS
- DNS: um serviço responde “para onde vai” o seu domínio (ex.: Route 53).
- Certificado TLS: permite criptografia HTTPS (ex.: AWS Certificate Manager).
- Destino do tráfego: para onde o navegador se conecta (ex.: CloudFront, ALB, ou diretamente S3/EC2 em cenários simples).
- Origem do conteúdo: onde o conteúdo é servido (ex.: S3 para site estático; EC2 para site dinâmico).
- Segurança básica: bloquear acesso indevido, reduzir superfície de ataque e aplicar o mínimo de privilégio (IAM, políticas de bucket, Security Groups, etc.).
Site estático vs. site dinâmico (decisão rápida)
Site estático (S3 como origem)
Quando usar: páginas institucionais, landing pages, documentação, portfólio. Conteúdo é basicamente HTML/CSS/JS e imagens.
- Origem: um bucket S3 com arquivos do site.
- Como “atualiza”: você envia novos arquivos (upload) e o site muda.
- Vantagens: simples, barato, escalável.
- Limite: não executa código de servidor (ex.: PHP, Node, Python) no S3.
Site dinâmico (EC2 como origem)
Quando usar: precisa de backend rodando (API, login, banco, processamento no servidor).
- Origem: uma instância EC2 rodando um servidor web (Nginx/Apache) e/ou aplicação.
- Como “atualiza”: deploy na instância (ou via pipeline, mais adiante).
- Vantagens: flexível, roda qualquer stack.
- Cuidados: patching, hardening, portas, chaves, custo e escalabilidade.
Mapa dos componentes mínimos (o “kit” do site com HTTPS)
| Componente | Serviço AWS | Função no desenho |
|---|---|---|
| Domínio/DNS | Route 53 | Apontar www e/ou raiz do domínio para o destino correto. |
| Certificado HTTPS | AWS Certificate Manager (ACM) | Emitir e gerenciar certificado TLS para o domínio. |
| Camada de entrega (edge) | CloudFront (opcional, mas comum) | Receber HTTPS, distribuir conteúdo e proteger a origem. |
| Origem do conteúdo | S3 ou EC2 | Servir arquivos estáticos (S3) ou responder requisições com backend (EC2). |
| Segurança de acesso | Bucket policy / Security Group / IAM | Restringir quem acessa o quê (público vs. privado, portas, permissões). |
Como os serviços se conectam (diagrama textual)
[Usuário no navegador] --(1) DNS--> [Route 53] --(2) Resposta: destino--> [CloudFront ou ALB ou S3/EC2] --(3) HTTPS/TLS com certificado ACM--> [Destino] --(4) Busca conteúdo--> [Origem: S3 ou EC2] --(5) Resposta--> [Usuário]Leitura do fluxo:
- (1) DNS: o navegador pergunta “qual o IP/endpoint de
www.suaempresa.com?” - (2) Route 53: responde com o destino (ex.: distribuição CloudFront, ALB ou endpoint configurado).
- (3) HTTPS: o navegador negocia TLS com o destino que tem um certificado válido (ACM).
- (4) Origem: o destino busca o conteúdo na origem (S3 ou EC2).
- (5) Entrega: o conteúdo volta ao usuário, já com HTTPS.
Diagrama lógico (duas opções de hospedagem)
Opção A: Site estático (S3 como origem)
Route 53 (A/AAAA ou Alias) ---> CloudFront (HTTPS + ACM) ---> S3 (bucket com site)- Route 53 aponta o domínio para o CloudFront (com Alias).
- CloudFront termina o HTTPS usando o certificado do ACM e busca os arquivos no S3.
- S3 guarda e serve os arquivos do site (HTML/CSS/JS/imagens).
Opção B: Site dinâmico (EC2 como origem)
Route 53 (A/AAAA ou Alias) ---> (CloudFront opcional) ---> EC2 (servidor web/app)- Route 53 aponta para o destino (pode ser CloudFront ou diretamente para um endpoint público).
- EC2 executa o servidor web e/ou aplicação, respondendo requisições.
- HTTPS pode terminar no CloudFront (com ACM) ou no próprio servidor (dependendo do desenho). Para iniciantes, é comum terminar no CloudFront para simplificar a borda e padronizar HTTPS.
Caminho prático no console (visão de alto nível)
A ideia aqui é você enxergar a ordem lógica de criação, sem entrar em detalhes avançados.
Continue em nosso aplicativo e ...
- Ouça o áudio com a tela desligada
- Ganhe Certificado após a conclusão
- + de 5000 cursos para você explorar!
Baixar o aplicativo
Passo a passo (comum às duas opções)
- Definir o domínio: você terá um domínio (registrado fora ou no Route 53). O importante é conseguir gerenciar o DNS.
- Solicitar certificado no ACM: pedir um certificado para
seu-dominio.come/ouwww.seu-dominio.come validar (geralmente por DNS). - Escolher a origem: decidir entre S3 (estático) ou EC2 (dinâmico).
- Configurar o destino HTTPS: criar o ponto que receberá o tráfego HTTPS usando o certificado do ACM (muito comum: CloudFront).
- Apontar o DNS no Route 53: criar registros (A/AAAA Alias ou CNAME, conforme o destino) para
wwwe, se necessário, para o domínio raiz. - Testar: acessar
https://www.seu-dominio.come verificar cadeado, carregamento e respostas.
Passo a passo específico: origem S3 (estático)
- Criar bucket S3 (nome alinhado ao projeto) e enviar os arquivos do site.
- Definir como o conteúdo será acessado: em boas práticas, o bucket não fica “aberto para o mundo” se você estiver usando CloudFront; o acesso é controlado pela configuração da distribuição e políticas do bucket.
- Criar CloudFront apontando para o bucket como origem e associar o certificado ACM.
- Route 53: criar registro Alias do
wwwpara a distribuição CloudFront.
Passo a passo específico: origem EC2 (dinâmico)
- Criar instância EC2 e instalar/rodar seu servidor web/app (ex.: Nginx servindo uma aplicação).
- Configurar Security Group para permitir apenas o necessário (ex.: 80/443 conforme o desenho; SSH restrito ao seu IP).
- Escolher como expor HTTPS: para iniciantes, uma abordagem comum é colocar CloudFront na frente e manter a origem com regras mais restritas.
- Route 53: apontar o domínio para o destino escolhido (CloudFront ou endpoint público definido).
Checklist do que será criado na conta
- Route 53: hosted zone (se você for gerenciar DNS por lá) e registros (A/AAAA Alias e/ou CNAME).
- ACM: certificado para o(s) domínio(s) do site.
- Origem:
- Opção estática: S3 bucket + objetos (arquivos do site).
- Opção dinâmica: EC2 instance + Security Group + (opcional) Elastic IP, dependendo do desenho.
- Camada HTTPS/entrega (frequente): CloudFront distribution configurada com o domínio e certificado.
- Permissões e segurança: políticas de acesso (bucket policy/IAM), regras de rede (Security Groups) e controle de quem pode alterar recursos.
Permissões necessárias (sem aprofundar)
Para executar o caminho prático no console, o usuário/role na AWS precisa ter permissões para criar e gerenciar os recursos abaixo. Em ambientes corporativos, isso costuma ser feito com uma role de “infra básica” ou permissões delegadas.
- Route 53: criar/editar hosted zones e records (ex.:
route53:CreateHostedZone,route53:ChangeResourceRecordSets,route53:ListHostedZones). - ACM: solicitar e descrever certificados (ex.:
acm:RequestCertificate,acm:DescribeCertificate,acm:ListCertificates). - S3 (se estático): criar bucket, enviar objetos e ajustar políticas (ex.:
s3:CreateBucket,s3:PutObject,s3:GetObject,s3:PutBucketPolicy). - EC2 (se dinâmico): criar instância, Security Group e gerenciar chaves (ex.:
ec2:RunInstances,ec2:CreateSecurityGroup,ec2:AuthorizeSecurityGroupIngress,ec2:DescribeInstances). - CloudFront (se usado): criar distribuição e associar domínio/certificado (ex.:
cloudfront:CreateDistribution,cloudfront:GetDistribution,cloudfront:UpdateDistribution). - IAM: se você precisar criar/ajustar usuários/roles/policies para operar com mínimo privilégio (ex.:
iam:CreateRole,iam:AttachRolePolicy,iam:PassRole).
Dica prática: se você estiver usando uma conta pessoal para aprender, normalmente você terá permissões amplas (administrador). Em contas de equipe, confirme antes quais serviços você pode criar/alterar para não travar no meio do processo.
