Fazer deploy em computação em nuvem moderna transcende a simples ação de copiar arquivos para uma máquina remota. Em ambientes de alta escala, disponibilidade e conformidade, o processo de publicação de software é uma disciplina rigorosa de engenharia que envolve orquestração de rede, distribuição global em borda, segregação de ambientes, imutabilidade de artefatos, transição de tráfego sem interrupção de serviço (zero downtime) e proteção ativa contra ameaças cibernéticas.

A AWS (Amazon Web Services) oferece um catálogo vasto de serviços desenhados para acomodar desde pequenos sites institucionais estáticos até complexos ecossistemas bancários distribuídos. No entanto, a diversidade de tipos de front-end (como SPAs puramente estáticas e aplicações com renderização no servidor) e de back-end (como monolitos tradicionais, microsserviços conteinerizados e microsserviços serverless guiados a eventos) exige que o arquiteto de software saiba selecionar a combinação precisa de serviços para cada cenário técnico.

Esta aula ensina como estruturar e executar deploys modernos na AWS para os diferentes padrões de front-end e back-end, detalha as estratégias de publicação em produção e estabelece os pilares inegociáveis de segurança ofensiva e defensiva que você deve implementar para proteger sua esteira e sua infraestrutura contra ataques de invasores.

Mapa da aula

Pré-requisitos recomendados: noções de AWS, redes de computadores, DNS, HTTP e containers Docker.

Parte 1: Fundamentos do deploy em nuvem

1. O fim do deploy artesanal

Nos primórdios do desenvolvimento web, o processo de deploy era uma atividade manual, lenta e vulnerável a erros humanos. O desenvolvedor realizava alterações no código localmente, conectava-se a uma máquina remota via FTP ou SSH, executava um comando de atualização de repositório (git pull) diretamente no diretório do servidor de produção e reiniciava manualmente o serviço web.

Esse modelo artesanal apresentava falhas catastróficas:

• Downtime inevitável: Durante os minutos em que os arquivos estavam sendo sobrescritos ou as dependências instaladas, os usuários recebiam páginas de erro 502 (Bad Gateway) ou quebras de script.
• Inconsistência de ambiente: Uma biblioteca atualizada acidentalmente no servidor criava discrepâncias silenciosas entre a máquina do desenvolvedor e o ambiente de produção.
• Risco severo de segurança: Manter portas SSH abertas na internet e armazenar credenciais com privilégios de superusuário em máquinas locais transformava qualquer invasão a uma estação de trabalho em comprometimento total da infraestrutura da empresa.

O deploy moderno substitui essa fragilidade por três mandamentos: automação total via esteiras de CI/CD, infraestrutura declarativa imutável e desacoplamento estrito entre tráfego e publicação de código.

2. O princípio da infraestrutura imutável

Em uma arquitetura moderna na nuvem, servidores e contêineres de produção nunca devem ser editados diretamente enquanto estão ativos. Se um patch de segurança ou uma nova versão do software precisa subir, não fazemos login na máquina para aplicar a alteração: nós geramos uma nova imagem de contêiner ou uma nova máquina virtual a partir de um modelo base, inicializamos a nova instância, testamos sua integridade e redirecionamos o tráfego da versão antiga para a nova. A infraestrutura antiga é então desligada e destruída.

Esse conceito, conhecido como infraestrutura imutável, garante que cada versão do seu sistema seja idempotente, rastreável e reversível em caso de incidentes.

3. O modelo de responsabilidade compartilhada no deploy

Ao fazer deploy na AWS, a segurança e a estabilidade da aplicação seguem o modelo de responsabilidade compartilhada:

• A AWS é responsável pela segurança DA nuvem: Proteção física dos data centers, isolamento de hardware, manutenção de hipervisores, patches de segurança em serviços gerenciados (como S3, DynamoDB e Lambda) e resiliência de zonas de disponibilidade (Availability Zones).
• Você é responsável pela segurança NA nuvem: Configuração correta de regras de firewall (Security Groups), controle estrito de permissões de acesso (IAM), isolamento de rede em VPCs privadas, criptografia de dados em trânsito e em repouso, sanitização de variáveis de ambiente e segurança do código-fonte compilado.

Parte 2: Deploys de Front-end na AWS

A arquitetura ideal para hospedar e publicar um front-end na AWS varia radicalmente de acordo com a forma como a aplicação gera suas páginas web. Analisaremos as três principais abordagens adotadas pela indústria.

4. Front-end estático (SPA: React, Vue, Angular e Vite)

Uma Single Page Application (SPA) é composta exclusivamente por artefatos estáticos gerados em tempo de compilação: um arquivo index.html, folhas de estilo .css, scripts JavaScript empacotados (.js), imagens, fontes e arquivos de manifesto.

Não há necessidade de manter um servidor computacional ativo (como Node.js ou Nginx em EC2) rodando 24 horas por dia para servir arquivos estáticos. Fazer isso adiciona custo de infraestrutura desnecessário, sobrecarga de gerenciamento de patches do sistema operacional e gargalos de escalabilidade.

A arquitetura canônica: Amazon S3 e Amazon CloudFront

O padrão ouro estabelecido pela AWS para SPAs baseia-se em quatro componentes integrados:

1. Amazon S3 (Simple Storage Service): Atua como o repositório de armazenamento durável e de baixo custo para todos os arquivos da build. O bucket deve ser configurado como estritamente privado, com a funcionalidade de acesso público desativada.
2. Amazon CloudFront: Uma rede de entrega de conteúdo (CDN) distribuída globalmente em mais de 600 pontos de presença (Edge Locations). O CloudFront armazena os arquivos em cache perto de onde os usuários estão no mundo, reduzindo a latência de carregamento para frações de milissegundos.
3. AWS Certificate Manager (ACM): Provedor gerenciado que emite certificados digitais SSL/TLS gratuitos e com renovação automática para viabilizar conexões HTTPS seguras.
4. Amazon Route 53: Serviço de DNS altamente resiliente que aponta o domínio customizado da sua empresa para a distribuição do CloudFront via registros de alias (Alias Records).

O diagrama detalha a jornada completa. O usuário faz a requisição DNS via Route 53, que encaminha a conexão HTTPS para o CloudFront. A CDN verifica se os arquivos requisitados estão no cache da borda. Se estiverem (Cache Hit), responde imediatamente. Se não estiverem (Cache Miss), busca os dados na origem protegida do S3 através de um canal criptografado e autenticado via Origin Access Control (OAC). Do lado da automação, a esteira do GitHub Actions realiza o build e sincroniza os artefatos com o bucket, disparando uma invalidação de cache.

Configurações vitais para SPAs no CloudFront

Ao configurar uma SPA no CloudFront, duas parametrizações técnicas são obrigatórias:

• Origin Access Control (OAC): Antigamente utilizava-se Origin Access Identity (OAI), hoje substituído pelo OAC. O OAC assina criptograficamente as requisições do CloudFront para o S3 via Signature Version 4 (SigV4). Isso impede que invasores acessem os arquivos diretamente pela URL do bucket S3, forçando todo o tráfego a passar pelas regras de inspeção da CDN.
• Tratamento de rotas do lado do cliente (Client-Side Routing): Em frameworks como React (com React Router) e Vue, URLs como meusite.com/dashboard/relatorios não existem fisicamente como pastas dentro do S3. Quando o usuário digita essa URL diretamente ou atualiza a página (F5), o S3 tenta encontrar um arquivo com esse caminho, não encontra e devolve um código de erro HTTP 403 (Access Denied) ou 404 (Not Found). Para resolver isso, você deve criar regras de resposta de erro customizadas (Custom Error Responses) no CloudFront: qualquer status 403 ou 404 retornado pela origem deve ser interceptado pelo CloudFront e respondido com o arquivo /index.html acompanhado do status HTTP 200 (OK). O JavaScript da sua SPA é então carregado no navegador do usuário e assume o controle da renderização da rota interna correta.

5. Front-end com Server-Side Rendering (SSR e Fullstack: Next.js e Remix)

Aplicações fullstack modernas como Next e Remix realizam Server-Side Rendering (SSR) e Server Actions. Isso significa que, para atender a uma requisição, o sistema não pode apenas entregar arquivos estáticos: ele precisa executar código JavaScript em tempo real no servidor para consultar bancos de dados, validar sessões de usuário e compor o HTML final antes de entregá-lo ao navegador.

A divisão de tráfego por comportamentos de cache (Cache Behaviors)

Manter um servidor Node.js servindo tanto as páginas dinâmicas quanto os milhares de arquivos estáticos da aplicação (imagens, fontes, bundles com hash imutável) satura os recursos de CPU e memória do servidor sem necessidade.

A arquitetura recomendada na AWS utiliza o CloudFront como roteador de tráfego inteligente na borda através de múltiplos comportamentos de cache:

1. Rota de assets imutáveis (/_next/static/* ou /assets/*): Direcionada diretamente para um bucket do Amazon S3. O CloudFront aplica uma política de cache agressiva com cabeçalho Cache-Control: public, max-age=31536000, immutable (cache de um ano). Como esses arquivos recebem um hash de conteúdo em seu nome a cada novo build, eles nunca mudam.
2. Rota dinâmica padrão (/*): Direcionada para a camada de computação (como um Application Load Balancer que distribui para contêineres ECS Fargate ou instâncias Lambda). O CloudFront é configurado para repassar cookies, cabeçalhos de autorização e query strings, sem reter cache de páginas dinâmicas de usuários autenticados.

A figura ilustra essa bifurcação eficiente. O usuário acessa a mesma URL base. O CloudFront inspeciona o caminho da requisição: assets estáticos são servidos instantaneamente pelo S3 com custo insignificante de transferência, enquanto páginas dinâmicas e rotas de mutação são encaminhadas para os contêineres Node.js no ECS Fargate.

6. Micro Front-ends e roteamento multi-aplicação

Em grandes organizações de tecnologia, múltiplos times independentes frequentemente gerenciam partes distintas do mesmo domínio. Por exemplo:

• O time de marketing gerencia a landing page e o blog corporativo em Next.js.
• O time de produto gerencia a área autenticada do usuário (/app/*) em React puro.
• O time financeiro gerencia o fluxo de checkout (/checkout/*) em uma aplicação isolada.

O deploy de micro front-ends na AWS pode ser unificado sob uma única distribuição do CloudFront, mapeando cada aplicação para uma origem diferente:

• Padrão de caminho /checkout/* encaminha para a origem do time de pagamentos.
• Padrão de caminho /blog/* encaminha para o CMS corporativo.
• Padrão de caminho default (/*) encaminha para a aplicação principal.

Essa estratégia permite que cada equipe possua seu próprio repositório Git, seu próprio pipeline de CI/CD e realize deploys independentes sem o perigo de que uma falha no código de marketing derrube o sistema de pagamentos da empresa.

Parte 3: Deploys de Back-end na AWS

Assim como no front-end, a escolha da infraestrutura de deploy para o back-end depende da natureza do serviço: seu volume de tráfego, necessidade de persistência em memória, latência tolerada e arquitetura de concorrência.

7. Monolitos em máquinas virtuais (Amazon EC2 e Auto Scaling)

O modelo tradicional de deploy em máquinas virtuais EC2 consiste em provisionar servidores virtuais Linux ou Windows que executam o binário ou interpretador do seu back-end (como uma aplicação Java Spring Boot, Go, Ruby on Rails ou C# .NET).

Para atingir alta disponibilidade e tolerância a falhas nesse modelo, a aplicação nunca deve rodar em uma única instância EC2 isolada:

• Application Load Balancer (ALB): Fica posicionado na camada pública da rede, recebe o tráfego HTTPS dos clientes, distribui as requisições entre as máquinas saudáveis e realiza verificações periódicas de integridade (Health Checks).
• Auto Scaling Group (ASG): Monitora o consumo de recursos (como uso médio de CPU ou quantidade de requisições por segundo) e adiciona ou remove máquinas automaticamente em múltiplas zonas de disponibilidade (Multi-AZ).
• Golden Images (AMIs imutáveis): Em vez de rodar scripts de instalação pesados toda vez que uma nova máquina EC2 é criada pela escala automática, a esteira de CI/CD utiliza ferramentas como HashiCorp Packer para criar uma Amazon Machine Image (AMI) pré-compilada contendo o sistema operacional, o runtime otimizado e a versão específica do binário da aplicação.

8. Microsserviços conteinerizados em ECS Fargate

O padrão predominante na indústria moderna para microsserviços é a conteinerização com Docker orquestrada pelo Amazon ECS (Elastic Container Service) em conjunto com o motor AWS Fargate.

O grande diferencial do AWS Fargate é ser um modelo serverless para contêineres: você não precisa criar, atualizar nem gerenciar as máquinas virtuais subjacentes do cluster. Você apenas define a quantidade de memória RAM e núcleos de CPU que seu contêiner necessita (por exemplo, 0.5 vCPU e 1 GB de RAM), e a AWS se encarrega de provisionar e isolar a execução em hardware dedicado de forma transparente.

O fluxo de arquitetura exibido no diagrama representa um ambiente corporativo resiliente:

1. O Application Load Balancer recebe a requisição externa na porta 443 (HTTPS) e faz o descarregamento do certificado SSL/TLS.
2. O ALB encaminha a chamada HTTP pela rede interna para o Target Group composto por réplicas de Tasks do ECS Fargate, que rodam dentro de Subnets Privadas sem nenhum IP público associado.
3. As Tasks executam o código compilado da API (em Go, Node.js ou Java), realizam consultas ao banco de dados relacional (Amazon Aurora Multi-AZ) e publicam mensagens de tarefas em filas do Amazon SQS.
4. Um conjunto secundário de contêineres do ECS Fargate (os Workers) consome continuamente as mensagens da fila SQS para processar tarefas assíncronas pesadas (como envio de e-mails, geração de PDFs ou processamento de imagens) sem onerar a latência da API síncrona.

9. Back-end Serverless e Event-Driven (API Gateway e AWS Lambda)

Para sistemas cuja demanda varia drasticamente ou que seguem uma arquitetura estritamente orientada a eventos (Event-Driven Architecture), o modelo serverless com Amazon API Gateway e AWS Lambda oferece uma proposta econômica e operacional formidável: custo zero quando não há requisições e escalabilidade instantânea em picos repentinos.

Componentes da pilha serverless:

• Amazon API Gateway (HTTP APIs): Atua como o ponto de entrada gerenciado para as rotas da sua API REST. Oferece validação automática de tokens JWT de autorização, limitação de taxa de requisições (Throttling) e roteamento de rotas HTTP diretamente para funções Lambda correspondentes.
• AWS Lambda: Executa pequenos trechos de código em contêineres efêmeros sob demanda. Cada requisição é atendida em sua própria instância isolada de execução. Em linguagens compiladas como Go e Rust rodando sobre processadores AWS Graviton (Arm64), o tempo de inicialização a frio (Cold Start) costuma ser inferior a 30 milissegundos.
• Amazon DynamoDB: Banco de dados NoSQL de altíssimo rendimento, escalável automaticamente e com latência de resposta consistente de um dígito em milissegundos sob qualquer volume de requisições.
• Amazon EventBridge: Barramento de eventos corporativo que permite que serviços publiquem eventos de domínio (como PedidoCriado ou PagamentoConfirmado) e disparem funções consumidoras desacopladas por meio de regras de filtragem declarativas.

Como demonstrado no diagrama, o API Gateway atende o usuário e aciona a função Lambda REST síncrona. A função grava os dados operacionais no DynamoDB e emite um evento no EventBridge. O barramento de eventos encaminha a notificação para uma segunda função Lambda de forma assíncrona, desacoplando o processamento do cliente original.

10. Workers e processamento em segundo plano

Muitas operações de back-end não devem bloquear o cliente HTTP:

• Exportação de relatórios analíticos volumosos.
• Sincronização de catálogos com sistemas externos de terceiros.
• Transcodificação de áudio e vídeo.
• Processamento de faturas em lote.

A estratégia profissional para essas cargas é o padrão Queue-Worker:

1. A API recebe a intenção de processamento, gera um identificador único de rastreamento (job_id), grava a tarefa na fila do Amazon SQS e responde imediatamente com status HTTP 202 (Accepted) ao cliente.
2. As instâncias de Worker (sejam Tasks no ECS Fargate ou Lambdas acionados pelo SQS) consomem as mensagens da fila no seu próprio ritmo.
3. Se um erro transitório ocorrer, o SQS retenta a mensagem automaticamente. Se a falha persistir após um número estipulado de tentativas (por exemplo, 3 vezes), a mensagem é enviada para uma Dead-Letter Queue (DLQ), impedindo a perda de dados e alertando a equipe de engenharia para inspeção de causa raiz.

Parte 4: Estratégias de Rollout em Produção

Ao atualizar a versão do seu sistema em produção, você deve escolher uma estratégia de liberação (Rollout Strategy) que equilibre segurança operacional, custo de infraestrutura e velocidade de reversão em caso de anomalias.

11. Rolling Deployment (Atualização Contínua)

No Rolling Deployment, a versão nova do sistema substitui a versão antiga gradualmente, contêiner por contêiner ou máquina por máquina.

No Amazon ECS, essa estratégia é controlada por dois parâmetros da definição do serviço:

• minimumHealthyPercent (ex: 100%): Garante que a quantidade de tarefas saudáveis atendendo tráfego nunca fique abaixo da capacidade original durante a atualização.
• maximumPercent (ex: 200%): Permite que o ECS dobre temporariamente o número de contêineres ativos durante a transição.

O orquestrador instancia novos contêineres da versão 2. Quando esses novos contêineres passam com sucesso pelos testes de integridade do Application Load Balancer, o orquestrador drena as conexões ativas dos contêineres da versão 1 e os desliga. O processo é econômico (não exige duplicar a infraestrutura permanentemente), mas caso a versão 2 apresente um bug crítico após 50% da atualização, a reversão exige reiniciar uma nova rodada de substituição gradual, o que consome alguns minutos.

12. Blue/Green Deployment (Ambientes Espelhados)

O Blue/Green Deployment é a técnica mais segura para sistemas críticos de missão zero downtime:

• O ambiente Blue (Azul) mantém a versão atual estável recebendo 100% do tráfego dos clientes.
• O pipeline de deploy provisiona um ambiente paralelo idêntico, denominado Green (Verde), executando a nova versão.
• A equipe de engenharia e os testes automatizados de fumaça (Smoke Tests) executam requisições de validação diretamente contra a porta privada do ambiente Green sem afetar os usuários reais.
• Uma vez validado, o Application Load Balancer (gerenciado automaticamente pelo AWS CodeDeploy) chaveia os ouvintes (listeners) instantaneamente, redirecionando todo o tráfego do Blue para o Green em segundos.

A vantagem suprema do Blue/Green é a reversão instantânea: se um pico inesperado de erros 500 for detectado no primeiro minuto após a publicação, o CodeDeploy reverte os apontadores do balanceador de volta para o ambiente Blue em frações de segundo, restaurando a estabilidade do sistema sem necessidade de novo deploy.

13. Canary Releases (Liberação Canário)

Inspirada na histórica prática dos mineradores de levar um canário para as minas de carvão para alertar precocemente sobre gases tóxicos, a estratégia Canary expõe a nova versão inicialmente a uma fração minúscula de usuários reais:

1. No primeiro instante, o sistema de roteamento envia 90% do tráfego para a versão estável e 10% para a versão nova (o canário).
2. O sistema de monitoramento da AWS (Amazon CloudWatch) avalia métricas vitais em tempo real: latência p99, taxa de erros HTTP 5xx e consumo de memória.
3. Se nenhum alarme for disparado durante um intervalo de tempo pré-determinado (por exemplo, 15 minutos), o percentual sobe gradualmente para 25%, 50% e finalmente 100%.
4. Caso a taxa de erro suba acima de uma margem estipulada (ex: mais de 0.5% de requisições com falha), o sistema aborta a liberação e reverte imediatamente para a versão estável sem intervenção humana.

Parte 5: Segurança Rigorosa no Processo de Deploy

A automação de deploy é um dos alvos mais cobiçados por invasores cibernéticos. Um hacker que consiga comprometer a sua esteira de CI/CD ou a identidade com permissões de deploy na AWS ganha acesso irrestrito para injetar código malicioso, sequestrar bancos de dados e minerar criptomoedas utilizando a conta da sua empresa.

Nesta seção, consolidamos as regras inegociáveis de segurança ofensiva e defensiva que você deve seguir.

O diagrama acima resume o princípio de Defesa em Profundidade:

• Na borda externa, o AWS WAF e o AWS Shield interceptam ataques cibernéticos antes que as requisições atinjam sua rede interna.
• Na esteira de automação, a comunicação entre o GitHub Actions e a AWS é protegida por tokens temporários via OIDC, enquanto as imagens de contêiner são auditadas contra vulnerabilidades pelo Amazon Inspector.
• Na camada interna, os servidores residem estritamente em Subnets Privadas sem IP público, consultando segredos corporativos criptografados pelo AWS KMS sob demanda.

14. Eliminação de credenciais estáticas via OIDC (OpenID Connect)

O erro de segurança mais frequente e perigoso cometido por desenvolvedores ao configurar pipelines de CI/CD (como GitHub Actions, GitLab CI ou Bitbucket) é gerar um par permanente de chaves de usuário IAM (AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY) e colá-lo nos segredos do repositório.

Se essa chave vazar (seja por um commit acidental, um log de build exposto ou o comprometimento de uma conta de desenvolvedor), o invasor ganha uma porta de entrada permanente para sua conta na AWS.

A solução profissional: Autenticação sem senha via OIDC

Em vez de chaves estáticas, utilize a federação de identidades via OpenID Connect (OIDC):

1. Você cadastra o GitHub Actions como um Identity Provider confiável no AWS IAM.
2. Cria uma IAM Role com permissões estritas para executar apenas o deploy daquele serviço específico.
3. Configura a política de confiança (Trust Policy) da role para que ela só possa ser assumida se a requisição vier comprovadamente do seu repositório Git e da branch correta (main ou production):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:minha-empresa/meu-projeto:ref:refs/heads/main"
        }
      }
    }
  ]
}

Durante a execução da esteira, o GitHub gera um token assinado temporário (JWT). O serviço AWS STS valida a assinatura desse token e devolve credenciais de acesso provisórias que expiram automaticamente em 1 hora. Não existem senhas nem chaves permanentes armazenadas em nenhum arquivo.

15. Proteção de borda contra ataques de rede e camada 7

Ameaças comuns:

• DDoS (Distributed Denial of Service): Enxurrada massiva de tráfego volumétrico (SYN floods, reflexão UDP) com o objetivo de saturar a banda e derrubar os balanceadores.
• Injeção de código (SQL Injection e Cross-Site Scripting): Tentativas de passar comandos SQL maliciosos em campos de busca ou scripts no corpo de requisições JSON.
• Ataques de força bruta e scrapers agressivos: Robôs que tentam quebrar senhas em formulários de login ou consumir milhares de dados da sua API por segundo.

Contramedidas na AWS:

• AWS Shield Standard: Habilitado automaticamente e sem custo adicional em todos os pontos de presença do CloudFront e nos Application Load Balancers, oferecendo mitigação instantânea contra ataques DDoS nas camadas 3 (rede) e 4 (transporte).
• AWS WAF (Web Application Firewall): Permite criar regras de inspeção na camada 7 (aplicação). Você deve ativar os conjuntos de regras gerenciadas da AWS (AWS Managed Rules):
  • AWSManagedRulesCommonRuleSet: Bloqueia explorações comuns como evasão de path traversal e injeção de comandos.
  • AWSManagedRulesSQLiRuleSet: Inspeciona cabeçalhos, parâmetros de URL e corpo de requisições contra sintaxes suspeitas de SQL Injection.
  • Rate-based rules: Regras de limitação de requisições que bloqueiam automaticamente qualquer endereço IP que envie mais de 500 requisições em um intervalo de 5 minutos, neutralizando ataques de força bruta.

16. Isolamento de rede em VPC e proteção contra movimentação lateral

Uma regra sagrada de arquitetura de nuvem estabelece que nenhum banco de dados ou contêiner de back-end deve possuir um IP público atribuído.

A sua Virtual Private Cloud (VPC) deve ser segmentada em camadas de rede com propósitos distintos:

1. Subnets Públicas: Acomodam exclusivamente os Application Load Balancers e NAT Gateways. São as únicas subnets que possuem uma rota direta para o Internet Gateway.
2. Subnets Privadas: Acomodam os nós de computação (contêineres ECS Fargate, instâncias EC2 e funções Lambda conectadas à VPC). Essas instâncias utilizam IPs privados internos (como 10.0.1.0/24) e acessam a internet apenas de saída (para baixar pacotes ou chamar APIs de pagamento) através do NAT Gateway da subnet pública. Ninguém na internet consegue conectar diretamente a essas instâncias.
3. Subnets Isoladas de Dados: Acomodam clusters de banco de dados (Amazon Aurora, RDS, ElastiCache Redis). Essas subnets não possuem rotas nem para o Internet Gateway nem para o NAT Gateway, tornando o banco de dados fisicamente inacessível a partir de redes externas.

O controle estrito de Security Groups:

Os Security Groups atuam como firewalls virtuais com estado (stateful). O erro comum de iniciantes é abrir portas para a internet inteira (0.0.0.0/0). A configuração correta deve encadear a confiança entre os grupos:

• O Security Group do ALB aceita tráfego das portas 80 e 443 originadas de 0.0.0.0/0.
• O Security Group das APIs (ECS Fargate) aceita conexões na porta da aplicação (ex: porta 8080) única e exclusivamente se a origem for o ID do Security Group do ALB.
• O Security Group do banco de dados (RDS) aceita conexões na porta 5432 (PostgreSQL) única e exclusivamente se a origem for o ID do Security Group das APIs.

Dessa forma, mesmo que um invasor descubra o IP privado do banco de dados, o tráfego será descartado pela infraestrutura de rede da AWS a menos que a conexão tenha nascido legitimamente dentro de um contêiner de API autorizado.

17. Prevenção de ataques de supply chain, SSRF e headers de segurança

Auditoria de imagens Docker (Supply Chain Security):

Imagens de contêiner podem conter bibliotecas desatualizadas com vulnerabilidades conhecidas (CVEs). Ao fazer o push de uma nova imagem para o Amazon ECR:

• Ative a opção Scan on Push no repositório do ECR.
• Integre o Amazon Inspector para realizar escaneamento contínuo de vulnerabilidades na camada do sistema operacional e nas bibliotecas de dependência do seu projeto.
• Construa imagens baseadas em modelos mínimos (como imagens scratch, distroless ou alpine) e nunca execute sua aplicação como o usuário root dentro do contêiner (adicione USER nonroot no Dockerfile).

Prevenção contra roubo de credenciais via SSRF (IMDSv2):

Em ataques de Server-Side Request Forgery (SSRF), um invasor induz o servidor da sua aplicação a realizar uma chamada HTTP para a URL interna de metadados da AWS (http://169.254.169.254/latest/meta-data/) para roubar os tokens temporários da role do IAM da máquina. Para anular essa vulnerabilidade, você deve forçar o uso obrigatório do IMDSv2 (Instance Metadata Service Version 2) em todas as instâncias EC2 e clusters de computação, configurando HttpTokens=required e HttpPutResponseHopLimit=1. O IMDSv2 exige que qualquer requisição aos metadados envie previamente um token de sessão via método PUT, o que não pode ser forjado por ataques simples de SSRF baseados em requisições GET.

Injeção de Headers de Segurança no Front-end:

Para proteger as SPAs contra ataques de Clickjacking, XSS e interceptação de tráfego, configure políticas de cabeçalhos de resposta (Response Headers Policies) no CloudFront para que a CDN injete automaticamente os seguintes cabeçalhos em todas as respostas HTTP entregues ao navegador:

• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload (HSTS: obriga o navegador a usar HTTPS por dois anos).
• X-Frame-Options: DENY (impede que sua página seja embutida dentro de <iframe> maliciosos para roubo de cliques).
• X-Content-Type-Options: nosniff (impede que o navegador adivinhe o MIME type de arquivos carregados).
• Content-Security-Policy: default-src 'self'; script-src 'self' ... (restringe rigorosamente de onde scripts externos podem ser carregados e executados).

Parte 6: Prática e Consolidação

18. Checklist definitivo de deploy em produção

Antes de promover qualquer versão para o ambiente de produção na AWS, verifique os seguintes itens:

Pré-Deploy (Na esteira de CI):

• O pipeline utiliza autenticação via OIDC sem chaves estáticas de IAM gravadas em segredos.
• Os testes unitários, testes de integração e verificações de lint passaram com 100% de sucesso.
• A imagem Docker foi construída sem usuário root e escaneada no ECR contra vulnerabilidades críticas.
• As variáveis de ambiente confidenciais foram cadastradas no AWS Secrets Manager ou SSM Parameter Store com criptografia via KMS, e não expostas em texto puro no repositório.

Durante o Deploy:

• A estratégia de liberação garante zero downtime (Rolling update com limites saudáveis, Blue/Green ou Canary).
• Os health checks do Application Load Balancer estão respondendo com status 200 na rota de verificação (/healthz ou /live).
• Para SPAs estáticas, a invalidação de cache do CloudFront foi acionada apenas para os arquivos alterados (ou /* com cache versionado por hash).

Pós-Deploy:

• As métricas de alarmes do Amazon CloudWatch (latência, taxas de erro 5xx e contagem de reinicializações de tarefas) permanecem estáveis.
• As regras do AWS WAF estão em modo de bloqueio e monitorando requisições suspeitas.
• A capacidade mínima da esteira de autoscaling está configurada em pelo menos duas zonas de disponibilidade (Multi-AZ).

19. Exercícios práticos de arquitetura

Exercício 1: Diagnóstico de erro 403 em SPA após deploy

Cenário: Uma empresa fez o deploy de sua nova aplicação React no Amazon S3 e ativou a distribuição do CloudFront. Ao acessar a página inicial https://app.empresa.com, tudo funciona perfeitamente. Porém, quando um usuário navega até a tela de perfil e pressiona o botão de recarregar a página (F5) na URL https://app.empresa.com/usuario/perfil, o navegador exibe uma tela preta com a mensagem de erro XML: AccessDenied: Access Denied (Code: 403). Explique a causa raiz do problema e qual configuração deve ser ajustada.

Solução comentada: A causa raiz é que a aplicação é uma Single Page Application e o S3 opera puramente como um armazenamento de objetos estáticos. Não existe um arquivo físico chamado /usuario/perfil ou /usuario/perfil/index.html dentro do bucket. Quando o usuário recarrega a página, a requisição pede esse arquivo inexistente ao S3. Como o bucket está privado via Origin Access Control (OAC), o S3 devolve um erro HTTP 403 (ou 404) para não revelar se o objeto existe ou não. Para corrigir isso sem comprometer a segurança, o engenheiro deve acessar as configurações da distribuição do CloudFront, entrar na aba Custom Error Responses e criar duas regras: para erros HTTP 403 e HTTP 404, retornar como página de resposta o caminho /index.html acompanhado do código de status HTTP 200 (OK). Assim, o navegador receberá o código JavaScript da aplicação, que lerá a URL e renderizará a tela de perfil correta.

Exercício 2: Mitigação de vazamento de credenciais em esteira CI/CD

Cenário: Durante uma auditoria interna, a equipe de segurança identificou que a equipe de desenvolvimento estava utilizando as variáveis AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY com permissões de administrador no GitHub Actions para rodar o comando aws s3 sync e atualizar contêineres no ECS. Desenhe o plano de remediação arquitetural para eliminar esse risco mantendo a automação funcional.

Solução comentada: O plano de remediação exige três passos essenciais:

1. Revogação imediata: Desativar e excluir as chaves de acesso estáticas existentes no painel do IAM da AWS e remover os segredos correspondentes das configurações do GitHub.
2. Configuração de OIDC: Criar um provedor de identidade OIDC no IAM apontando para token.actions.githubusercontent.com.
3. Criação de IAM Role de Menor Privilégio: Criar uma IAM Role específica para a esteira contendo uma política de confiança (Trust Policy) restrita estritamente ao identificador do repositório (repo:organizacao/projeto:*). Anexar a essa role apenas as permissões pontuais estritamente necessárias para a esteira (como s3:PutObject, s3:DeleteObject, cloudfront:CreateInvalidation e ecs:UpdateService), aplicando o princípio do menor privilégio (Least Privilege). No workflow do GitHub Actions, utilizar a action oficial aws-actions/configure-aws-credentials configurando o parâmetro role-to-assume, obtendo credenciais temporárias efêmeras sem qualquer senha estática.

Exercício 3: Escolha entre ECS Fargate e AWS Lambda

Cenário: Uma startup de inteligência artificial precisa fazer o deploy de um serviço de processamento de texto que carrega um modelo de machine learning em memória RAM na inicialização. O carregamento do modelo consome cerca de 3 GB de RAM e leva 45 segundos para inicializar. Uma vez carregado, cada predição leva 200 milissegundos para responder. Qual arquitetura de computação na AWS você recomendaria: AWS Lambda ou Amazon ECS Fargate? Justifique tecnicamente.

Solução comentada: A recomendação técnica inequívoca para esse caso é o Amazon ECS Fargate (ou instâncias EC2 otimizadas para IA). O AWS Lambda é inadequado para esse padrão porque opera em contêineres efêmeros sob demanda. Como o modelo demora 45 segundos para ser carregado na memória, qualquer evento de inicialização a frio (Cold Start) geraria uma penalidade inaceitável de quase um minuto de espera para o usuário final, além de correr o risco de estourar limites de timeout de requisições de API Gateway (cujo teto padrão é de 29 segundos). No Amazon ECS Fargate, as tarefas permanecem ativas continuamente (Warm). A inicialização pesada de 45 segundos ocorre apenas uma vez no momento do deploy ou da escala automática (protegida pelo período de tolerância do health check do Application Load Balancer), e todas as requisições subsequentes dos usuários são atendidas em meros 200 milissegundos com o modelo já residente na memória RAM.

20. Glossário técnico

• Deploy: O conjunto de etapas automatizadas que compila, testa, empacota e publica uma nova versão de um software em um ambiente acessível por usuários ou outros sistemas.
• SPA (Single Page Application): Aplicação web cujo front-end é entregue inteiramente como arquivos estáticos (HTML, JS, CSS) e onde a navegação entre telas é controlada internamente pelo navegador do cliente.
• SSR (Server-Side Rendering): Técnica onde o código HTML das páginas web é gerado dinamicamente em tempo de execução por um servidor ativo a cada requisição do usuário.
• Origin Access Control (OAC): Mecanismo de segurança do Amazon CloudFront que assina criptograficamente as requisições enviadas ao S3 via SigV4, garantindo que o bucket só possa ser lido através da CDN.
• Application Load Balancer (ALB): Balanceador de carga gerenciado na camada 7 (HTTP/HTTPS) da AWS que distribui tráfego entre múltiplos destinos (alvos como instâncias EC2, contêineres e Lambdas).
• AWS Fargate: Mecanismo de computação serverless para contêineres que permite rodar tarefas no Amazon ECS ou EKS sem precisar gerenciar servidores ou clusters de máquinas virtuais.
• Blue/Green Deployment: Estratégia de publicação onde dois ambientes idênticos coexistem, permitindo validação isolada da nova versão e chaveamento instantâneo do tráfego pelo balanceador de carga.
• Canary Deployment: Liberação gradual de uma nova versão para uma pequena porcentagem de usuários antes da promoção total, permitindo monitoramento de métricas e reversão automática.
• OIDC (OpenID Connect): Protocolo de autenticação baseado em identidade federada que permite que esteiras de CI/CD assumam credenciais temporárias na AWS sem a necessidade de chaves estáticas.
• AWS WAF: Firewall de camada de aplicação que inspeciona requisições HTTP e bloqueia ataques como SQL Injection, Cross-Site Scripting e requisições maliciosas automatizadas.
• AWS Shield: Serviço gerenciado de proteção contra ataques distribuídos de negação de serviço (DDoS).
• IMDSv2: Versão segura do serviço de metadados de instâncias da AWS que exige tokens autenticados por sessão para impedir ataques de roubo de credenciais via SSRF.

21. Fontes consultadas e referências oficiais

• Documentação Oficial da AWS: “Amazon CloudFront Developer Guide: Using Origin Access Control (OAC)”.
• Documentação Oficial da AWS: “AWS Well-Architected Framework: Reliability and Security Pillars”.
• AWS Security Blog: “Configuring OpenID Connect in Amazon Web Services with GitHub Actions”.
• Guia Oficial do Amazon Elastic Container Service: “Deployment types and rolling updates on AWS Fargate”.
• OWASP Top 10: “A01:2021-Broken Access Control and A10:2021-Server-Side Request Forgery (SSRF)”.
• Amazon Web Services Whitepaper: “Blue/Green Deployments on AWS: Best Practices for Continuous Delivery”.

Relacionados

• AWS
• Amazon CloudFront
• S3
• EC2
• Lambda
• RDS
• Route 53
• Elastic Beanstalk
• IAM