AWS SAA-C03 — Guia de Estudo

Estrutura do Exame SAA-C03

• 65 questões (50 pontuadas + 15 não pontuadas)
• 130 minutos | Aprovação: 720/1000
• Recomendado: 1 ano de experiência prática com AWS

SAA pressupõe conhecimento do CCP. Revise o guia CCP antes se ainda não o fez — IAM básico, serviços principais e modelo de responsabilidade compartilhada são pré-requisitos assumidos aqui.

1. Design de Arquiteturas Seguras

IAM Avançado

O IAM existe porque na AWS tudo começa negado por padrão. A questão não é “o que eu permito?”, mas “quem pode fazer o quê em qual recurso, em qual condição?” O sistema de avaliação de políticas reflete isso.

Evaluation Logic — como a AWS decide Allow ou Deny:

Quando uma entidade IAM faz uma chamada de API, a AWS avalia todas as políticas aplicáveis em uma ordem estrita. O princípio fundamental é zero-trust: na ausência de permissão explícita, a ação é negada. Um Deny explícito prevalece sobre qualquer Allow porque isso evita o problema de “escalada acidental” — se você puder negar de verdade, não importa quantas políticas liberem o acesso depois, ele está bloqueado.

Ordem de avaliação:
1. Explicit Deny   → NEGA sempre (prevalece sobre tudo, sem exceção)
2. Organization SCP → deve permitir (teto da organização)
3. Permission Boundary → limita permissões máximas do principal
4. Identity Policy → Allow nas políticas associadas ao usuário/role
5. Resource Policy → Allow na política do recurso (cross-account requer ambos)
6. Session Policy → se assumindo role com escopo reduzido (AssumeRole)

Por que Deny explícito prevalece? Imagine uma empresa com 50 contas AWS. O administrador da organização quer garantir que nenhuma conta crie recursos fora das regiões aprovadas. Ele coloca um Deny na SCP para us-west-1 e todas as regiões não autorizadas. Mesmo que um administrador de uma conta tenha AdministratorAccess, o SCP barra a ação. Sem esse mecanismo, um Deny explícito precisaria ser replicado em todas as políticas — impossível de manter.

Tipos de política:

Cenário de prova: Se a questão diz que um usuário com AdministratorAccess ainda não consegue criar EC2 em uma região → SCP da organização está bloqueando. Identity policy não é o problema — o teto (SCP) está ativo.

Cenário de prova: Se a questão fala em “um desenvolvedor que criou uma role com mais permissões do que ele mesmo tem” → Permission Boundary. Ele pode criar roles, mas o boundary impede que a role herde mais do que ele próprio possui.

Roles importantes para a prova:

• Instance Profile → associa Role a EC2 (a aplicação na EC2 usa essa role para chamar APIs AWS sem hardcodar credenciais)
• Service-linked Role → criada automaticamente pelo serviço AWS (ex: ECS cria uma para si mesmo)
• Cross-account Role → permite que uma conta assuma permissões em outra; requer trust policy no lado destino

VPC — Rede Privada Virtual

Uma VPC é uma fatia isolada da rede AWS. Pense como se você tivesse pedido um prédio inteiro em um condomínio: você define as alas (subnets), as regras de acesso (Security Groups e NACLs), e os portões de entrada (Internet Gateway, NAT Gateway). A AWS garante que nenhum vizinho (outra conta) entra na sua rede sem convite explícito.

Por que subnet pública e subnet privada existem?

A divisão existe por princípio de defesa em profundidade. Recursos que precisam ser alcançados pela internet (load balancers, instâncias de bastião) ficam nas subnets públicas. Recursos que só precisam fazer chamadas de saída ou só conversam com outros recursos internos (servidores de aplicação, bancos de dados) ficam nas subnets privadas. Se um banco de dados estiver em subnet pública, basta um erro de Security Group para ele estar exposto — colocá-lo em subnet privada significa que mesmo um erro de configuração não o tornaria diretamente acessível da internet.

Componentes obrigatórios:

Fluxo completo de um pacote saindo de subnet privada para a internet:

EC2 em subnet privada (10.0.2.10)
   ↓ pacote com destino 8.8.8.8
Route Table da subnet privada
   → regra 0.0.0.0/0 aponta para NAT Gateway
   ↓
NAT Gateway (em subnet pública, com Elastic IP 52.x.x.x)
   → faz SNAT: troca IP de origem para o Elastic IP
   ↓
Route Table da subnet pública
   → regra 0.0.0.0/0 aponta para Internet Gateway
   ↓
Internet Gateway
   → envia para 8.8.8.8 na internet pública

Retorno: 8.8.8.8 responde para 52.x.x.x (Elastic IP do NAT GW)
   NAT GW faz DNAT: traduz de volta para 10.0.2.10
   EC2 recebe resposta

O ponto crítico: a EC2 em subnet privada nunca tem Elastic IP, e o Internet Gateway nunca a vê diretamente. Todo o retorno passa pelo NAT Gateway que mantém a tabela de tradução.

Cenário de prova: Se a questão diz que instâncias em subnet privada precisam baixar atualizações de pacotes / fazer chamadas para APIs externas → NAT Gateway. Se diz que precisam ser acessadas de fora (SSH, HTTP público) → subnet pública com IGW + Elastic IP ou ELB.

Security Group vs NACL — Diferença Prática

Esta é uma das confusões mais frequentes na prova. Ambos controlam tráfego de rede, mas em níveis e com comportamentos radicalmente diferentes.

Security Group (SG) opera no nível da instância (ENI — Elastic Network Interface). É stateful: quando você permite uma conexão de entrada, a resposta dessa conexão sai automaticamente, sem nenhuma regra de saída necessária. Ele só tem regras Allow — não existe “bloquear explicitamente”.

NACL (Network Access Control List) opera no nível da subnet. É stateless: cada pacote é avaliado individualmente, sem memória de conexões anteriores. Você precisa de regras explícitas tanto para entrada quanto para saída. Tem regras Allow e Deny, avaliadas em ordem numérica crescente (primeiro match ganha).

Exemplo concreto de tráfego HTTP:

Usuário na internet (IP: 203.0.113.5) → GET /app → porta 80 do servidor (10.0.1.20)

Caminho de ENTRADA:
  1. NACL (subnet do servidor): regra 100 ALLOW TCP 0.0.0.0/0 porta 80 → passa
  2. Security Group do servidor: regra ALLOW TCP 0.0.0.0/0 porta 80 → passa
  → Request chega no servidor

Caminho de SAÍDA (resposta HTTP):
  3. Security Group: STATEFUL → não precisa de regra de saída, libera automaticamente
  4. NACL: STATELESS → precisa de regra explícita de saída
     - NACL precisa de: ALLOW TCP 0.0.0.0/0 portas efêmeras (1024–65535) de saída
     - Se essa regra não existir, a resposta é bloqueada na saída da subnet!

Esse é o erro mais comum com NACL: esquecer de adicionar regras para portas efêmeras no tráfego de saída. Security Group nunca tem esse problema.

Cenário de prova: Security Group não consegue bloquear um IP específico explicitamente (só tem Allow). Se precisa bloquear, use NACL com Deny antes de qualquer Allow.

Cenário de prova: Se a questão menciona “stateless firewall no nível de subnet” → NACL. “Stateful firewall no nível da instância” → Security Group.

VPC Endpoints — diferença que cai na prova:

Gateway Endpoint é gratuito e funciona por route table. Suporta apenas S3 e DynamoDB. Quando você cria um, a route table da subnet recebe uma entrada apontando o prefixo do serviço para o endpoint — tráfego nunca sai da VPC. Não há ENI, não há IP.

Interface Endpoint cria uma ENI com IP privado dentro da sua VPC. Suporta todos os demais serviços AWS (SSM, Secrets Manager, CloudWatch, etc.). Tem custo por hora e por dado processado.

AWS PrivateLink é a tecnologia por trás dos Interface Endpoints. Permite que ISVs e parceiros exponham serviços como se fossem AWS services para seus clientes, sem necessidade de VPC Peering nem IGW. O cliente cria um Interface Endpoint; o tráfego flui via PrivateLink sem exposição pública.

Cenário de prova: EC2 em subnet privada precisa acessar S3 sem sair para a internet → VPC Gateway Endpoint para S3 (gratuito, sem ENI). EC2 precisa acessar Secrets Manager sem sair para a internet → Interface Endpoint (tem custo).

Criptografia

KMS vs CloudHSM: KMS é gerenciado pela AWS — você controla quem usa a chave e quais políticas se aplicam, mas a AWS opera o hardware subjacente. CloudHSM é um HSM dedicado fisicamente onde você controla o material da chave; nem a AWS pode acessar. Use CloudHSM quando regulação exige que nenhum terceiro (nem a AWS) possa acessar as chaves — FIPS 140-2 Level 3.

Secrets Manager vs Parameter Store: Secrets Manager tem rotação automática integrada com RDS, Redshift, DocumentDB e suporte customizado via Lambda. Parameter Store é mais barato (existe tier gratuito) e funciona bem para configurações que não precisam de rotação. Se a questão menciona “rotação automática de credenciais de banco de dados” → Secrets Manager.

Tipos de criptografia S3:

Proteção & Monitoramento

Uma confusão comum é misturar os serviços de segurança. Cada um tem um foco específico:

• GuardDuty analisa logs já existentes (CloudTrail, VPC Flow Logs, DNS) com ML para detectar comportamentos suspeitos (ex: instância EC2 fazendo conexões para IPs conhecidos de C&C de malware, tentativa de mineração de criptomoedas).
• Inspector é sobre vulnerabilidades conhecidas — ele escaneia pacotes instalados no EC2 e imagens no ECR contra CVEs.
• Macie é específico para dados sensíveis no S3 — ele usa ML para encontrar PII, credenciais, dados financeiros em objetos S3.
• Security Hub agrega e normaliza findings de GuardDuty, Inspector, Macie, WAF e terceiros em um painel centralizado com pontuação de conformidade.

Cenário de prova: “Detectar que uma instância EC2 está se comunicando com um servidor de malware conhecido” → GuardDuty. “Encontrar arquivos com CPF e número de cartão de crédito no S3” → Macie. “Verificar se o AMI tem vulnerabilidades CVE antes de usar em produção” → Inspector.

2. Design de Arquiteturas Resilientes

EC2 — Alta Disponibilidade com Auto Scaling

Um Auto Scaling Group (ASG) resolve dois problemas ao mesmo tempo: disponibilidade e economia. Em termos de disponibilidade, ele garante que o número mínimo de instâncias está sempre rodando — se uma instância falha no health check, o ASG a termina e lança uma nova. Em termos de economia, ele expande a capacidade quando a demanda sobe e reduz quando cai, pagando só pelo que usa.

O ASG distribui instâncias entre múltiplas AZs automaticamente. Se você define 3 AZs e mínimo de 6 instâncias, ele tenta manter 2 em cada AZ. Se uma AZ cair, o ASG redistribui nas restantes.

Scaling Policies:

• Target Tracking: “mantenha CPU em 50%” — o ASG calcula quantas instâncias adicionais ou a menos são necessárias. Mais simples, recomendado na maioria dos casos.
• Step Scaling: regras em degraus (“se CPU > 70%, adicione 2; se CPU > 90%, adicione 5”). Mais controle, mais complexidade.
• Scheduled Scaling: “todo dia às 8h adicione 4 instâncias, às 22h remova-as”. Útil para padrões de tráfego previsíveis (horas comerciais, fim de mês).
• Cooldown period (default 300s): após uma ação de scaling, o ASG aguarda este período antes de agir novamente. Evita que métricas momentâneas causem scaling excessivo.

Launch Template vs Launch Configuration:

• Launch Template (recomendado): suporta múltiplos tipos de instância, mix On-Demand + Spot, versioning do template.
• Launch Configuration (legado): tipo único de instância, sem versioning. A AWS não recomenda para novos projetos.

Multi-AZ com ASG:

Route 53 (DNS + health check)
        ↓
    ALB (multi-AZ)
   /         \
  AZ-A       AZ-B       AZ-C
[EC2][EC2]  [EC2][EC2]  [EC2]
  ↘              ↓          ↙
        RDS Multi-AZ
      Primary(AZ-A) / Standby(AZ-B)

Elastic Load Balancer (ELB)

O ELB existe para distribuir tráfego entre múltiplas instâncias — mas cada tipo opera em uma camada diferente da pilha de rede, e essa diferença muda completamente o que ele consegue fazer.

ALB (Application Load Balancer) opera na camada 7 — ele lê o conteúdo HTTP da requisição antes de rotear. Isso permite decisões inteligentes: /api/* vai para o Target Group do backend, /static/* vai para servidores de conteúdo, requisições com header X-Version: v2 vão para uma nova versão do serviço. É o load balancer padrão para aplicações web e microserviços. Suporta WebSockets, HTTP/2, gRPC e é obrigatório para ECS com múltiplos containers no mesmo host (port mapping dinâmico).

NLB (Network Load Balancer) opera na camada 4 — ele não lê HTTP, só vê TCP/UDP. Por isso é extremamente rápido (latência de microsegundos) e consegue manter IPs estáticos (Elastic IP por AZ). Use NLB quando precisar de: performance máxima, IP fixo para whitelist por clientes, protocolos não-HTTP (MQTT, gRPC raw, UDP para jogos/IoT), ou quando o cliente precisa ver o IP de origem real.

GLB (Gateway Load Balancer) é especializado para inserir appliances de segurança de terceiros (firewalls, IDPS) no fluxo de tráfego. Pense nele como um “espelho inteligente” que desvia todo tráfego para um appliance antes de deixar passar.

ALB — Roteamento Avançado por Listener Rules:

HTTPS :443 → Listener Rule:
  /api/*          → Target Group A (backend containers, porta 8080)
  /static/*       → Target Group B (servidores de conteúdo, porta 80)
  host: app.*     → Target Group C (aplicação principal)
  host: admin.*   → Target Group D (painel admin, acesso restrito por IP)
  header X-Ver:v2 → Target Group E (canary deployment)
  default         → Target Group A

Connection Draining / Deregistration Delay: quando uma instância vai ser removida do Target Group (scaling down, deploy), o ELB para de enviar requests novos mas aguarda até 300s para os requests em andamento terminarem. Sem isso, usuários com sessões ativas seriam abruptamente desconectados.

Sticky Sessions: ELB envia requests do mesmo cliente sempre para a mesma instância. Útil para aplicações que armazenam sessão localmente (legado), mas gera desequilíbrio de carga. Prefira sessão centralizada (ElastiCache) e elimine a necessidade de sticky sessions.

Cenário de prova: “Aplicação precisa rotear /api para um serviço e /web para outro” → ALB com path-based routing. “Clientes precisam fazer whitelist de IP fixo do load balancer” → NLB com Elastic IP. “Inserir firewall de terceiro no fluxo de tráfego da VPC” → GLB.

Bancos de Dados Resilientes

RDS — Multi-AZ vs Read Replica

Esta é uma das confusões mais frequentes da prova. Ambos criam uma segunda instância de banco de dados, mas os propósitos são completamente diferentes.

Multi-AZ existe para disponibilidade. A AWS mantém uma réplica síncrona em outra AZ. “Síncrona” significa que toda transação só é confirmada para o cliente após ser escrita nas duas instâncias. Se a instância primária falhar (hardware, SO, AZ inteira), a AWS promove o standby automaticamente em cerca de 1–2 minutos, sem intervenção manual e sem perda de dados. O endpoint do RDS permanece o mesmo — a aplicação simplesmente reconecta. O standby não serve tráfego de leitura — está lá só para failover.

Read Replica existe para performance de leitura. A replicação é assíncrona — há um lag entre o que foi escrito no primário e o que aparece na réplica (geralmente milissegundos, mas pode aumentar sob carga pesada). Você aponta consultas de leitura (relatórios, dashboards) para a réplica, aliviando o primário. Pode ter até 15 réplicas. Pode ser em outra região (cross-region Read Replica) — útil tanto para usuários globais quanto para Disaster Recovery.

Multi-AZ (HA):
  Primary (AZ-a) ←→[síncrono]←→ Standby (AZ-b)
  Aplicação escreve e lê do Primary
  Standby é promovido automaticamente se Primary falhar

Read Replica (Performance):
  Primary (AZ-a) --[assíncrono]-→ Replica 1 (AZ-b)
                              --[assíncrono]-→ Replica 2 (us-east-1)
  Aplicação escreve no Primary
  Aplicação lê das Replicas (endpoints separados)

Cenário de prova: “A aplicação está lenta porque a carga de leitura está alta demais no banco” → Read Replica (não Multi-AZ). “O banco precisa de failover automático sem perda de dados” → Multi-AZ (não Read Replica). “Preciso de DR em outra região para o banco de dados” → Cross-Region Read Replica (pode ser promovida manualmente).

Recursos adicionais do RDS:

RDS Proxy — Por Que Lambda + RDS Sem Proxy É Problema

O problema começa com o modelo de execução do Lambda. Cada invocação Lambda é potencialmente um processo separado. Quando você tem 1.000 execuções simultâneas, pode ter até 1.000 processos tentando abrir conexões TCP com o RDS ao mesmo tempo.

O PostgreSQL e o MySQL têm um limite real de conexões simultâneas — tipicamente algumas centenas para instâncias menores. Cada conexão aberta consome memória no servidor de banco de dados, mesmo que esteja idle. Quando Lambda escala de 10 para 500 invocações em poucos segundos durante um pico de tráfego, você tem 500 novas conexões TCP sendo estabelecidas simultaneamente. O RDS frequentemente não aguenta — começa a rejeitar conexões com “too many clients” e suas funções Lambda falham com erro de banco, não de negócio.

RDS Proxy resolve isso com connection pooling: ele mantém um pool de conexões abertas e persistentes com o RDS (ex: 50 conexões), e todas as invocações Lambda compartilham esse pool. Lambda chama o Proxy → o Proxy usa uma conexão existente do pool → resposta volta. O RDS nunca vê mais do que o tamanho do pool.

Sem RDS Proxy:
Lambda x 500 --[500 conexões TCP]-→ RDS (limite: 300)
                                        ↓
                                   "too many clients" ❌

Com RDS Proxy:
Lambda x 500 --[500 reqs]-→ RDS Proxy --[50 conexões]-→ RDS ✅
                              (gerencia pool)

Cenário de prova: “Aplicação serverless com Lambda está recebendo erros de ‘too many connections’ no banco de dados” → RDS Proxy. É a resposta para qualquer cenário que combine Lambda + RDS com problemas de conexão.

Aurora — O Que “6 Cópias em 3 AZs” Significa na Prática

Aurora não é um RDS diferente — é uma reimaginação da camada de storage. O storage do Aurora é distribuído automaticamente em 6 cópias (volumes) em 3 AZs, mas a instância de compute é única e separada do storage.

Como o quórum funciona:

• Para escrita ser confirmada: Aurora precisa de 4 de 6 cópias confirmarem. Se uma AZ inteira cair, ainda temos 4 cópias nas outras duas AZs — escritas continuam sem interrupção.
• Para leitura ser servida: Aurora precisa de 3 de 6 cópias. Tolerância muito maior.

Na prática isso significa: Aurora pode perder 2 cópias de storage (de AZs diferentes) e ainda escrever. Pode perder 3 cópias e ainda ler. Tudo isso acontece silenciosamente — a aplicação não vê. Comparando com RDS Multi-AZ que tem 2 instâncias completas replicadas de forma síncrona, Aurora tem 6 micro-volumes distribuídos que agem como um storage único e virtualmente indestrutível.

Benefício prático: Failover automático no Aurora é muito mais rápido que no RDS Multi-AZ. Aurora promove uma read replica em menos de 30 segundos (vs 1–2 minutos no RDS). Há até 15 read replicas em Aurora vs 5 no RDS MySQL/PostgreSQL.

Outros recursos Aurora:

• Aurora Global Database: réplica cross-region com RPO < 1 segundo e RTO < 1 minuto. Um cluster primário + até 5 secundários em outras regiões. Os secundários têm latência de replicação tipicamente abaixo de 1 segundo. Em caso de desastre na região primária, você promove um secundário manualmente.
• Aurora Serverless v2: escala compute automaticamente por ACU (Aurora Capacity Units) em frações de segundo. Você define mínimo e máximo de ACUs; o Aurora ajusta conforme a carga. Ideal para cargas imprevisíveis ou ambientes de desenvolvimento que ficam inativos por períodos longos.

Cenário de prova: “Banco de dados precisa de failover em menos de 30 segundos” → Aurora (não RDS Multi-AZ). “Replicação cross-region com RPO de segundos” → Aurora Global Database. “Aplicação tem picos imprevisíveis e precisa de banco que escale junto” → Aurora Serverless v2.

DynamoDB

DynamoDB é um banco NoSQL totalmente serverless — você não gerencia servidores, não escolhe instância, não configura rede. Escala automaticamente de zero a praticamente qualquer throughput.

• Global Tables: multi-region, multi-master (ativo-ativo). Escreve na região mais próxima, replica globalmente. Conflitos são resolvidos por last-write-wins.
• DAX (DynamoDB Accelerator): cache in-memory, latência de microsegundos. Transparente para a aplicação (usa o mesmo endpoint). Use para workloads de leitura intensiva que precisam de latência extremamente baixa.
• Streams: captura cada mudança de item (insert, update, delete) e a disponibiliza para Lambda ou KDS. Fundamental para event-driven architecture.
• On-demand vs Provisioned: On-demand cobra por leitura/escrita sem comprometimento — ideal para tráfego imprevisível ou novo. Provisioned é mais barato quando o tráfego é previsível e você pode usar Auto Scaling.

ElastiCache — Redis vs Memcached

Redis é o default na maioria dos cenários de prova. Suporta persistência de dados, replicação, failover Multi-AZ (Replication Group), Pub/Sub, estruturas de dados complexas (sorted sets para leaderboards, streams). Se a questão menciona “cache com alta disponibilidade” ou “sessão de usuário persistente” → Redis.

Memcached é mais simples: multi-thread (aproveita múltiplos CPUs para cache puro), sem persistência, sem replicação. Use quando precisar de cache simples com máxima performance em leitura pura e não precisar de HA.

Padrão Cache-Aside (Lazy Loading): aplicação consulta cache → se miss, busca no DB → popula cache → retorna resultado. O cache cresce com demanda real. Desvantagem: primeiro acesso é sempre um miss.

Outros bancos de dados:

S3 — Durabilidade e Versioning

S3 armazena objetos com 11 noves de durabilidade (99,999999999%). Para entender o que isso significa: se você armazena 10 milhões de objetos, a expectativa estatística é perder 1 objeto a cada 10.000 anos. Isso é possível porque cada objeto é replicado em pelo menos 3 AZs automaticamente.

S3 Storage Classes — Decisão de Lifecycle com Custo Real:

S3 tem diversas classes de armazenamento, cada uma com trade-offs entre custo de armazenamento e custo de recuperação. O princípio é: quanto mais raramente você acessa, mais barato armazenar, mas mais caro recuperar.

Exemplo de Lifecycle Policy para logs de aplicação:

Regra "logs-lifecycle":
  - Após 0–30 dias:   Standard          (logs recentes, debugging ativo)
  - Após 30 dias:     Standard-IA        (economiza ~45% vs Standard)
  - Após 90 dias:     Glacier Flexible   (economiza ~84% vs Standard)
  - Após 365 dias:    Glacier Deep Archive (economiza ~96% vs Standard)
  - Após 2555 dias:   DELETE             (7 anos: obrigação fiscal cumprida)

S3 Intelligent-Tiering movimenta objetos automaticamente entre tiers sem custo de retrieval:

Frequent Access (30 dias de acesso) → Infrequent Access (após 30 dias)
→ Archive Instant (após 90 dias) → Archive (após 180 dias)

Cobra uma taxa de monitoramento por objeto (~$0,0025/1.000 objetos/mês). Vale para repositórios com padrão de acesso imprevisível — evita você criar lifecycle policies manuais.

Cenário de prova: “Backups que precisam ser retidos por 7 anos mas quase nunca são acessados” → Glacier Deep Archive. “Imagens de usuários que são acessadas com frequência no primeiro mês mas raramente depois” → lifecycle para Standard-IA após 30 dias. “Não sei quando os dados serão acessados” → Intelligent-Tiering.

Padrões de Alta Disponibilidade

Active-Active vs Active-Passive:

• Active-Active: dois sites atendem tráfego simultaneamente. Route 53 com Weighted ou Latency policy distribui requisições entre as regiões. RTO próximo de zero — se uma região falha, o DNS para de roteá-la.
• Active-Passive: um site ativo, outro em standby. Route 53 com Failover policy. O secundário entra em ação só quando o health check do primário falha.

RPO e RTO — entender o custo real:

• RPO (Recovery Point Objective): quanto de dados você pode perder. Se RPO = 1 hora, você aceita perder até 1 hora de transações. Backup a cada hora atende esse RPO, mas qualquer transação feita depois do último backup será perdida.
• RTO (Recovery Time Objective): quanto tempo você aceita estar fora do ar. Se RTO = 4 horas, você tem 4 horas para restaurar o serviço após um desastre.

3. Design de Arquiteturas de Alta Performance

Compute

EC2 — Tipos para a prova:

Escolher o tipo correto de instância é mais sobre identificar o gargalo do workload do que memorizar famílias. A questão tipicamente descreve o workload — você deve identificar se ele é CPU-bound, memória-bound, storage-bound ou GPU-bound.

Placement Groups:

Placement Groups afetam onde fisicamente na infraestrutura AWS suas instâncias são colocadas. Isso impacta diretamente a latência de rede entre elas.

Cluster é o único que melhora performance de rede. Spread e Partition são sobre isolar falhas.

Cenário de prova: “Cluster HPC que precisa de máxima velocidade de rede entre instâncias” → Cluster Placement Group. “Banco de dados distribuído que não pode ter dois nós no mesmo hardware” → Spread Placement Group. “Kafka com 3 brokers que precisam estar em racks diferentes mas na mesma AZ pode” → Partition Placement Group.

EBS — Tipos de Volume e Quando io2 Block Express Vale o Custo

EBS provisiona armazenamento em bloco para EC2. O tipo certo de volume pode ser a diferença entre uma aplicação lenta e uma rápida — e entre custo razoável e custo absurdo.

gp3 é o default hoje. Você provisiona IOPS (até 16.000) e throughput (até 1.000 MB/s) independentemente do tamanho do volume — não existe mais a regra antiga do gp2 de 3 IOPS/GB. É mais barato que io2 na maioria dos casos.

io2 Block Express foi criado para workloads enterprise que precisam de SLAs rigorosos de latência e volumes de IOPS que gp3 simplesmente não atinge. Exemplos reais:

• Oracle RAC (Real Application Clusters) exigindo 100.000+ IOPS sustained com latência sub-millisegundo
• SQL Server Enterprise com bancos de dados OLTP de altíssimo volume de transações
• SAP HANA em EC2 que exige IOPS garantidos e latência consistente

Para esses workloads, o custo maior de io2 (~$0,125/GB/mês + $0,065/IOPS/mês) se justifica porque o custo do downtime ou da lentidão é maior. Se um sistema financeiro tem SLA de 99,99% e latência de banco > 1ms causa cascata de timeouts, gp3 não garante — io2 com SLA de 99,999% de durabilidade e latência consistente é a escolha correta.

io1/io2 Multi-Attach: permite que um volume io1/io2 seja anexado a até 16 instâncias EC2 na mesma AZ simultaneamente. Requer que a aplicação gerencie acesso concorrente (ex: cluster com locking distribuído).

• EBS fica na mesma AZ que a instância — não pode cruzar AZ diretamente
• Para mover entre AZs: Snapshot → cria volume na nova AZ
• Para mover entre regiões: Snapshot → copia para outra região → cria volume

EFS vs EBS vs S3:

Cenário de prova: “10 instâncias EC2 precisam compartilhar o mesmo sistema de arquivos” → EFS. “Banco de dados que precisa de disk de baixa latência” → EBS io2. “Backups diários que ficam armazenados por 1 ano” → S3 + lifecycle para Glacier.

FSx:

• FSx for Windows File Server: SMB (NTFS), integração com Active Directory, ideal para ambientes Windows que precisam de file share compartilhado
• FSx for Lustre: sistema de arquivos de alta performance para HPC e ML training. Integra diretamente com S3 como backend — pode tratar um bucket S3 como repositório e processar com Lustre localmente

CloudFront vs Global Accelerator — Comparação Profunda

Esta é uma das comparações mais cobradas no SAA-C03 e gera muita confusão.

CloudFront é uma CDN (Content Delivery Network). Seu mecanismo fundamental é o cache: ele copia conteúdo dos seus servidores de origem para Edge Locations distribuídos pelo mundo. Quando um usuário no Brasil acessa uma imagem hospedada no S3 em us-east-1, na primeira requisição CloudFront vai buscar na origem e cacheia no Edge Location de São Paulo. A partir daí, todos os usuários brasileiros recebem a imagem de São Paulo sem bater no us-east-1 — latência reduzida radicalmente.

CloudFront é HTTP/HTTPS. Ele entende headers, cookies, query strings e usa isso para decidir se serve do cache ou vai à origem. Configurações de TTL, invalidação de cache, comportamentos por path — tudo isso é gerenciamento de cache.

Global Accelerator não faz cache. Ele não armazena nada. Seu mecanismo é o roteamento de rede: em vez do tráfego do usuário percorrer a internet pública (com seus saltos imprevisíveis, congestionamentos e variação de latência), o Global Accelerator intercepta o tráfego nas Edge Locations e redireciona para a rede privada backbone da AWS — uma rede de fibra dedicada que conecta todas as regiões AWS com latência consistente e confiável.

Sem Global Accelerator:
Usuário (SP) → internet pública (10-15 saltos) → servidor (Oregon)
Latência: 180ms ± 40ms (variável)

Com Global Accelerator:
Usuário (SP) → Edge Location SP (1 salto) → backbone AWS → servidor (Oregon)
Latência: 140ms ± 5ms (consistente)

Além disso, Global Accelerator fornece 2 IPs Anycast estáticos globais. O mesmo IP funciona em qualquer lugar do mundo — o roteamento anycast direciona o tráfego para o Edge Location mais próximo automaticamente. Isso é valioso quando clientes corporativos precisam fazer whitelist de IP.

Resumo da decisão:

• CloudFront → conteúdo cacheável (imagens, vídeos, JS, HTML, APIs com respostas repetidas)
• Global Accelerator → aplicações não-cacheáveis que precisam de latência consistente (apps de trading, jogos online, VoIP), protocolos não-HTTP, IP fixo para whitelist, ou failover multi-região instantâneo

Cenário de prova: “Aplicação global com usuários em múltiplos continentes acessa imagens do S3” → CloudFront. “Aplicação de jogos online UDP precisa de baixa latência consistente globalmente” → Global Accelerator. “Aplicação precisa de dois IPs fixos que funcionem globalmente para ser adicionada em whitelist de clientes corporativos” → Global Accelerator.

Route 53 — DNS & Roteamento

Tipos de registro:

CNAME vs Alias: Use Alias para recursos AWS (ALB, CloudFront, S3). É gratuito, suporta o apex do domínio, e o Route 53 resolve o IP atual do recurso automaticamente. CNAME cria cobrança por query e não funciona no apex.

Routing Policies:

Cenário de prova: “Distribuir 10% do tráfego para nova versão da aplicação” → Weighted Routing (90/10). “Usuários europeus devem acessar servidores da Europa por GDPR” → Geolocation Routing. “Redirecionar usuários para o servidor mais rápido de acordo com localização” → Latency-based Routing.

Serverless & Event-Driven

Lambda — Cold Start, Concorrência e Provisioned Concurrency

Lambda é a base de arquiteturas serverless: você envia código, define trigger e memória, e a AWS executa quando necessário. A cobrança é por invocação (praticamente zero para volumes normais) e por duração em GB-segundos.

O que acontece em um cold start:

Quando Lambda precisa de uma nova instância de execução (primeira invocação, concorrência aumentando, novo deploy), há um processo de inicialização:

1. Init Container    → AWS aloca container/microVM (milissegundos)
2. Init Runtime      → carrega runtime (Python/Node/Java) (~50ms para Python/Node, ~500ms+ para Java)
3. Init Handler      → executa código fora do handler (imports, conexões DB, etc.)
4. Invocation        → executa seu handler com o evento

Para Python e Node.js, cold start geralmente é 100–500ms. Para Java e .NET, pode ser 1–2 segundos ou mais — Java carrega JVM, inicializa Spring Boot, estabelece conexões. Para funções que respondem a usuários humanos em real-time, isso é perceptível.

Provisioned Concurrency resolve o cold start mantendo instâncias pré-inicializadas e quentes. Você define quantas instâncias devem estar sempre prontas. A AWS executa os passos 1–3 de antemão; quando um evento chega, só o passo 4 acontece. O custo é proporcional ao número de instâncias provisionadas × tempo em que ficam reservadas — você paga mesmo quando não há invocações.

Quando Provisioned Concurrency vale:

• APIs que servem usuários em tempo real com SLA de latência < 200ms
• Funções Java/Spring Boot onde cold start é > 2 segundos
• Eventos de tráfego previsível (ex: às 9h úteis o sistema recebe pico)

Quando Provisioned Concurrency NÃO vale:

• Processamento assíncrono em background (batch, ETL, eventos S3)
• Cold start < 300ms já é aceitável para o caso de uso
• Tráfego completamente imprevisível (você pagaria instâncias quentes sem usar)

Limites e configurações:

• Máx 15 minutos de execução | Máx 10 GB RAM | Máx 10 GB storage /tmp
• Concurrency padrão: 1.000 execuções simultâneas por conta (soft limit, pode aumentar)
• Reserved Concurrency: garante um número de execuções simultâneas para uma função específica (e limita ao mesmo tempo — uma função não pode consumir toda a concorrência da conta)
• Layers: pacotes zip com dependências compartilháveis entre funções

Cenário de prova: “API Lambda escrita em Java tem latência alta nas primeiras requisições após deploy” → cold start, solução é Provisioned Concurrency. “Lambda de processamento de imagens tem tempo de execução de 20 minutos” → não pode usar Lambda (limite 15 min) → use ECS/Fargate ou Step Functions com Lambda < 15 min por step.

SQS vs SNS vs EventBridge — Quando Usar Cada Um

A confusão aqui é frequente porque todos os três são serviços de mensageria/eventos. A diferença está no padrão de comunicação e na natureza dos eventos.

SQS (Simple Queue Service) é uma fila. Um produtor coloca mensagens, um ou mais consumidores leem e processam. As mensagens ficam na fila até serem processadas (até 14 dias). É comunicação ponto-a-ponto assíncrona — desacopla produtor de consumidor, permite que o consumidor processe no seu ritmo. O caso clássico: um serviço web recebe uploads de vídeo, coloca na fila SQS, e workers de transcodificação consomem na velocidade que conseguem.

SNS (Simple Notification Service) é pub/sub. Um publisher publica em um Topic, e todos os subscribers recebem a mensagem simultaneamente — fan-out. Se você tem um Topic com 5 subscribers (SQS queues, Lambda functions, email endpoints), todos os 5 recebem a mensagem. A mensagem não fica armazenada — se um subscriber está down no momento da publicação, ele perde a mensagem (a menos que seja uma SQS queue, que bufferiza).

Padrão SNS + SQS (fan-out): combine os dois. SNS publica para múltiplas filas SQS. Cada fila serve um consumidor diferente. Os consumidores processam de forma independente, no próprio ritmo, sem perder mensagens.

Evento: upload de imagem
         ↓
       SNS Topic
      /    |    \
     ↓     ↓     ↓
  SQS-A  SQS-B  SQS-C
    ↓      ↓      ↓
 Thumb-  Backup  Moderação
 nails   (S3)   (ML)

EventBridge é um event bus de roteamento inteligente. Recebe eventos de qualquer fonte (serviços AWS, SaaS parceiros como Datadog e Zendesk, ou seu próprio código) e aplica regras de filtragem para rotear para targets específicos. A diferença do SNS: EventBridge filtra por conteúdo do evento — você pode criar uma regra que só dispara quando source = "myapp" E detail.status = "error" E detail.amount > 1000. SNS não faz filtragem tão granular.

Cenário de prova: “Quando uma imagem é enviada ao S3, disparar 3 processos diferentes em paralelo” → SNS + 3 filas SQS (fan-out). “Processar pedidos de forma assíncrona com retry automático” → SQS com DLQ. “Quando o status de um pedido muda para ‘cancelado’ no Salesforce, notificar o sistema de estoque” → EventBridge com parceiro Salesforce.

SQS — Detalhes críticos:

• Visibility Timeout: após receber uma mensagem, ela fica invisível por este período. Se o consumidor não deletar a mensagem antes do timeout expirar, ela reaparece na fila para outro consumidor tentar. Default: 30s. Configure >= tempo de processamento esperado.
• Dead Letter Queue (DLQ): após N falhas (maxReceiveCount), a mensagem vai para a DLQ para análise. Evita que mensagens com defeito fiquem em loop infinito na fila.
• Long Polling: em vez de retornar imediatamente quando a fila está vazia, aguarda até 20s por mensagens. Reduz chamadas vazias e custos.

Amazon MQ — não confunda com SQS/SNS. MQ é para quando você tem uma aplicação legada que já usa ActiveMQ ou RabbitMQ com protocolo AMQP, MQTT ou STOMP. Em vez de reescrever tudo para SQS, você move o broker para Amazon MQ. Lift-and-shift de messaging. Para aplicações novas, SQS/SNS são mais simples e baratos.

Step Functions

Orquestra workflows de microserviços com estados visuais (state machine). Cada estado pode invocar Lambda, chamar APIs AWS, aguardar aprovação humana, rodar em paralelo, ou tratar erros com retry e catch.

• Standard Workflow: long-running (até 1 ano), exatamente-once, auditável (histórico completo de execução). Mais caro por transição de estado.
• Express Workflow: alto volume (100.000+ execuções/segundo), at-least-once, duração máxima 5 minutos. Mais barato.

Use Step Functions quando a lógica de orquestração fica complexa demais para uma Lambda única (múltiplos passos, retry, branching, esperas).

Containers

ECS vs EKS é a decisão mais frequente na prova sobre containers.

ECS (Elastic Container Service) é a solução AWS-native. Mais simples de operar porque o plano de controle é totalmente gerenciado e você não precisa entender Kubernetes. Task Definitions definem containers, CPU/memória, variáveis de ambiente. Services gerenciam a quantidade desejada de tasks rodando. Integra nativamente com ALB (path routing para múltiplos serviços), IAM Task Roles (cada container tem sua própria role), CloudWatch, Secrets Manager.

EKS (Elastic Kubernetes Service) é Kubernetes gerenciado. Use quando: a equipe já conhece K8s, você precisa de portabilidade (pode rodar on-premises ou em outro cloud), ou precisa do ecossistema K8s (Helm charts, Istio, etc.). Mais poder, mais complexidade.

Fargate elimina o gerenciamento de EC2 para ambos ECS e EKS. Você define CPU e memória por container; a AWS aloca infra. Ideal quando você não quer gerenciar cluster de EC2. Ligeiramente mais caro que EC2 puro, mas com muito menos overhead operacional.

Cenário de prova: “Empresa está migrando aplicação containerizada. Quer minimizar overhead operacional e não tem experiência com Kubernetes” → ECS com Fargate. “Empresa tem time DevOps experiente em Kubernetes e quer portabilidade” → EKS. “Precisam de um registry privado para imagens Docker dentro da AWS” → ECR.

4. Design de Arquiteturas Otimizadas para Custo

EC2 — Estratégia de Compra

O modelo de compra de EC2 é um dos tópicos mais cobrados no domínio de custo. A chave é identificar o padrão de uso do workload e escolher o modelo adequado.

On-Demand é o ponto de partida — pague pelo que usar, sem compromisso. O preço mais alto por hora, mas zero risco. Use para: ambientes de desenvolvimento, workloads imprevisíveis, projetos novos antes de entender o padrão de uso, cargas que duram menos de um ano.

Savings Plans são compromissos de gasto mínimo por hora em troca de desconto. Você diz “vou gastar pelo menos $X/hora por 1 ou 3 anos” e a AWS aplica desconto em qualquer recurso coberto. Compute Savings Plans são mais flexíveis (cobrem Lambda e Fargate também, qualquer instância em qualquer região). EC2 Instance Savings Plans são para uma família/região específica e têm desconto ligeiramente maior.

Reserved Instances são compromissos de tipo específico de instância. Standard RI é o mais rígido (família, tamanho, região, SO fixos) e mais barato. Convertible RI permite trocar o tipo, mas com desconto menor. Em geral, Savings Plans substituem Reserved Instances para novos compromissos — são mais flexíveis com desconto similar.

Spot Instances são capacidade ociosa da AWS vendida com até 90% de desconto. A AWS pode recuperar a instância com 2 minutos de aviso quando precisar da capacidade. Por isso, são adequadas apenas para workloads tolerantes a interrupção: processamento em batch, ML training (checkpointing periódico), CI/CD pipelines, rendering.

ASG com Mix On-Demand + Spot na prática:

A combinação mais inteligente é usar ASG com uma base garantida de On-Demand e capacidade adicional com Spot. Se o Spot for interrompido, o ASG lança On-Demand automaticamente para manter a capacidade mínima.

Launch Template com múltiplos tipos de instância:
  m5.large, m5a.large, m4.large, t3.large (todos equivalentes para o workload)

ASG Mixed Instances Policy:
  Base: 2 instâncias On-Demand (garantidas)
  Adicional: até 8 instâncias Spot (economia de ~70%)

Allocation Strategy: capacity-optimized
  → AWS escolhe o pool Spot com maior capacidade disponível
  → reduz chances de interrupção (contraintuitivo: não é o mais barato, é o mais disponível)

Comportamento em interrupção Spot:
  1. AWS envia interrupção notice (2 min antes)
  2. ASG recebe o evento via EventBridge
  3. ASG começa a lançar nova instância (On-Demand ou outro pool Spot)
  4. Instance draining: conexões existentes terminam gracefully
  5. Instância é terminada

Por que capacity-optimized é melhor que lowest-price? Com lowest-price, você escolhe os pools Spot mais baratos — que geralmente são os mais populares e têm maior probabilidade de interrupção. Com capacity-optimized, você escolhe os pools com mais capacidade disponível — menor probabilidade de interrupção, mesmo que seja ligeiramente mais caro. Para workloads críticos, capacity-optimized é mais confiável.

Cenário de prova: “Processamento de batch à noite com custo mínimo” → Spot Instances. “Aplicação web em produção que não pode ficar fora do ar, mas quer economizar nos picos” → ASG com On-Demand base + Spot adicional (capacity-optimized). “Servidor de licença Oracle que cobra por socket físico” → Dedicated Host.

S3 — Otimização de Custo

Já coberto em detalhes na seção de storage. Os pontos adicionais:

S3 Storage Lens: dashboard de visibilidade de uso de S3 com recomendações de custo. Identifica buckets com baixo acesso que poderiam estar em Standard-IA, objetos sem lifecycle policy, uso de replicação desnecessária.

Otimização de requests: S3 cobra por número de requests GET/PUT/LIST além do armazenamento. Para objetos muito pequenos com alto volume de acesso, agrupe em arquivos maiores. Use prefixos para paralelizar (evite hotspot em um único prefixo).

Serverless para Custo

A proposta de valor do serverless é pagar exatamente pelo que usa — zero quando idle.

• Lambda: paga por invocação (~$0,20 por 1 milhão) + duração em GB-segundos. Uma função que fica idle não gera custo algum. Compare com EC2 que corre 24/7.
• SQS: paga por mensagem (primeiros 1 milhão/mês são gratuitos). Praticamente zero para a maioria dos casos.
• DynamoDB On-Demand: paga por unidade de leitura/escrita. Sem provisionamento, sem custo mínimo. Ideal para tráfego imprevisível onde DynamoDB Provisioned com Auto Scaling seria oversized.
• Fargate Spot: containers Spot para ECS/EKS. Até 70% de economia em containers para workloads tolerantes a interrupção.

Data Transfer Costs

Custo de transferência de dados é frequentemente esquecido no design de arquitetura, mas pode ser significativo em sistemas distribuídos.

• Ingress (entrada na AWS): gratuito
• Entre AZs na mesma região: ~$0,01/GB em cada direção (entrada e saída)
• Entre regiões: ~$0,02–$0,09/GB dependendo das regiões
• Saída para internet: ~$0,09/GB para os primeiros 10TB/mês (diminui com volume)
• CloudFront para usuário: ~$0,0085/GB (mais barato que EC2 direto para internet)

Implicação de design: coloque recursos que se comunicam muito na mesma AZ. Se um EC2 está em us-east-1a e chama um RDS em us-east-1b repetidamente, você paga $0,01/GB nos dois sentidos. Para leituras/escritas frequentes de banco de dados, isso acumula.

Cenário de prova: “Reduzir custos de transferência entre EC2 e RDS” → coloque EC2 e RDS na mesma AZ (sacrifica HA, mas reduz custo). Em cenários de HA, aceite o custo cross-AZ como parte do custo de disponibilidade.

Ferramentas de Otimização

5. Serviços Adicionais Cobrados no SAA

Analytics & Big Data

O ecossistema de analytics da AWS tem muitas opções. A chave é entender o padrão de dado: é streaming em tempo real ou batch? É análise ad-hoc ou pipeline recorrente?

Kinesis Data Streams é para ingestão de dados em tempo real com processamento customizado. Você define shards (capacidade), e consumidores (Lambda, aplicações customizadas) processam os dados. Retenção de 1 a 365 dias — você pode reprocessar dados históricos. Use quando precisa de controle total sobre o processamento.

Kinesis Firehose é o ETL de streaming gerenciado. Recebe dados e entrega automaticamente para S3, Redshift, OpenSearch ou Splunk — com transformação opcional via Lambda no meio. Zero management de shards. Use quando o destino é S3/Redshift e você não precisa de processamento customizado complexo.

Athena é query SQL serverless diretamente no S3. Paga por dados escaneados (~$5 por TB). Use Parquet/ORC comprimido para reduzir custo (Parquet escaneia 10x menos que CSV). Ideal para análises ad-hoc, data lake queries, relatórios ocasionais.

Redshift é data warehouse colunar para análises complexas de grandes volumes (petabytes). Mais caro que Athena mas muito mais rápido para queries recorrentes e complexas. RA3 nodes separam compute de storage, permitindo escalar cada um independentemente.

Integração & Migração

Cenário de prova: “Empresa com 100 TB de dados precisa migrar para AWS em 2 semanas. A conexão internet é de 100 Mbps” → Snowball Edge (transferir 100TB por 100Mbps levaria ~100 dias). “Migrar Oracle para Aurora PostgreSQL” → DMS + SCT.

Conectividade Híbrida

VPN Site-to-Site conecta sua rede on-premises à VPC via túnel IPSec sobre a internet pública. Rápido de configurar (horas), barato, mas latência variável e largura de banda compartilhada. Boa para workloads de desenvolvimento ou como backup do Direct Connect.

Direct Connect é um link físico dedicado entre seu data center e a AWS. Latência consistente e baixa, largura de banda garantida (1, 10, 100 Gbps). Demora semanas a meses para implementar (precisa de parceiro de conectividade) e é significativamente mais caro que VPN. Obrigatório para workloads de produção com alto volume de dados ou requisitos de latência.

Direct Connect + VPN: combine os dois para ter criptografia IPSec sobre o link dedicado. Quando compliance exige criptografia em trânsito E você precisa de latência consistente.

Transit Gateway: hub central que conecta múltiplas VPCs e redes on-premises em topologia hub-and-spoke. Sem Transit Gateway, 10 VPCs precisariam de 45 peerings (mesh). Com Transit Gateway, são 10 conexões de cada VPC ao hub.

AWS Outposts: rack físico da AWS instalado no seu data center. Roda serviços AWS (EC2, RDS, EKS, S3) on-premises com a mesma API e console da AWS. Use quando: requisitos de latência ultra-baixa para aplicações que ficam on-premises, ou regulação impede dados em nuvem pública mas você ainda quer o modelo AWS.

Outros Serviços Frequentes

Cognito User Pools vs Identity Pools: User Pools são um provedor de identidade — gerenciam cadastro, login, MFA, retornam JWT. Identity Pools trocam tokens (de User Pool, Google, Facebook, etc.) por credenciais AWS temporárias (AssumeRoleWithWebIdentity). Se a questão fala em “login de usuário na aplicação” → User Pool. Se fala em “usuário precisa acessar S3 ou DynamoDB diretamente do app” → Identity Pool.

6. Padrões de Arquitetura para a Prova

Aplicação Web de 3 Camadas

Este é o padrão mais cobrado. Entenda cada componente e por que está onde está.

Internet
    ↓
Route 53 (DNS + health check multi-region)
    ↓
CloudFront (CDN para assets estáticos + cache de API)
    ↓
ALB (public subnet, multi-AZ)
    ↓
EC2/ECS (private subnet, ASG multi-AZ)
    ↓
RDS Multi-AZ (isolated subnet)
ElastiCache Redis (isolated subnet, para sessão e cache de queries)

Por que cada camada está em subnet separada?

• Public subnet: ALB precisa de acesso da internet
• Private subnet (app tier): EC2/ECS não precisam ser acessados diretamente — só via ALB. Saem para internet via NAT GW para updates.
• Isolated subnet: RDS e ElastiCache não têm rota para internet. Nenhum acesso externo, mesmo que Security Group erroneamente permita.

Serverless API

CloudFront → API Gateway → Lambda → DynamoDB
                  ↓              ↓
             Cognito       SQS (async tasks)
             (auth/JWT)         ↓
                            Lambda worker

Neste padrão, CloudFront cacheia respostas do API Gateway quando possível (ex: catálogos, dados estáticos). API Gateway valida o JWT do Cognito antes de invocar Lambda. Lambda síncrona responde ao usuário; para tarefas longas, coloca na SQS e responde ao usuário imediatamente (202 Accepted).

Event-Driven Processing

Upload de arquivo → S3 Event → SNS Topic
                                   ↓
                         ┌─────────┼─────────┐
                         ↓         ↓         ↓
                       SQS-A     SQS-B     SQS-C
                         ↓         ↓         ↓
                    Lambda-A   Lambda-B  Lambda-C
                   (thumbnail) (backup)  (moderação)
                         ↓
                    DLQ (falhas)

O S3 Event aciona SNS → SNS faz fan-out para 3 filas SQS → cada Lambda consome independentemente. Se Lambda-A falhar, a mensagem vai para o DLQ de SQS-A sem afetar o processamento de Lambda-B e Lambda-C.

Disaster Recovery — Estratégias com RPO/RTO Real

O custo e a complexidade de DR são inversamente proporcionais ao RPO/RTO desejado. Escolher a estratégia correta é equilibrar quanto downtime é aceitável com o budget disponível.

Backup & Restore é o mais simples e barato. Você faz backups periódicos (S3, snapshots RDS) para outra região. Em caso de desastre, você restaura tudo do zero na região secundária. RTO pode ser de horas (tempo para restaurar snapshot de RDS + iniciar EC2 + reconectar DNS). RPO é o tempo desde o último backup.

Pilot Light mantém um conjunto mínimo de recursos sempre rodando na região secundária — tipicamente o banco de dados replicado (RDS Read Replica cross-region) e imagens AMI disponíveis. Em caso de desastre, você escala os recursos (lança EC2, escala RDS, atualiza DNS). RTO de minutos a dezenas de minutos.

Warm Standby tem uma versão reduzida da aplicação rodando continuamente na região secundária (menos instâncias, menor tier de banco). Serve tráfego de teste ou leitura em condições normais. Em caso de desastre, você escala para capacidade total. RTO de minutos.

Multi-Site Active-Active tem capacidade total em duas ou mais regiões, servindo tráfego real simultaneamente. Route 53 distribui usuários entre regiões. Em caso de falha de uma região, Route 53 para de rotear para ela. RTO próximo de zero — usuários são redirecionados imediatamente. Custo dobrado.

Cenário de prova: “Empresa pode tolerar até 4 horas de downtime e 1 hora de perda de dados. Budget é limitado” → Backup & Restore. “Sistema financeiro precisa de RPO < 1 minuto e RTO < 5 minutos” → Warm Standby com Aurora Global Database. “E-commerce global não pode perder nenhuma transação e precisa estar disponível mesmo durante falha de uma região inteira” → Multi-Site Active-Active.

7. Simulados Gratuitos

A melhor estratégia de uso é: estude o material primeiro, depois faça simulados para identificar gaps, então volte ao material nas áreas fracas. Fazer simulados sem base teórica apenas memorizando gabaritos não prepara para as variações da prova real.

8. Checklist para a Prova

Use este checklist nos dias antes da prova para verificar se os conceitos principais estão consolidados.

Redes:

• Security Group (stateful, Allow only, nível instância) vs NACL (stateless, Allow+Deny, nível subnet, ordem importa)
• Subnet pública (route table → IGW) vs privada (route table → NAT GW)
• Fluxo completo de pacote: instância privada → route table → NAT GW → IGW → internet
• VPC Peering (não transitivo, 1:1) vs Transit Gateway (hub central, N:N com roteamento)
• Gateway Endpoint (S3/DynamoDB, gratuito, route table) vs Interface Endpoint (demais serviços, ENI, pago)
• AWS PrivateLink = tecnologia dos Interface Endpoints; exposição de serviço sem peering público
• CloudFront (CDN, cache HTTP) vs Global Accelerator (anycast, backbone AWS, TCP/UDP, IP fixo)
• Network Firewall = stateful + IDS/IPS na VPC (WAF = layer 7 somente para web apps HTTP/HTTPS)

Compute:

• ALB (layer 7, path/host/header routing, containers) vs NLB (layer 4, TCP/UDP, IP estático, latência ultra-baixa)
• Placement Groups: Cluster (HPC, baixa latência, mesmo rack) vs Spread (isolamento, max 7/AZ) vs Partition (Kafka/HDFS)
• Auto Scaling: target tracking vs step scaling vs scheduled
• Spot: interrompível com 2 min aviso; ASG capacity-optimized para menor taxa de interrupção
• Lambda cold start: Init Container → Init Runtime → Init Handler → Invocation; Provisioned Concurrency elimina

Armazenamento:

• EBS: block, mesma AZ, uma instância (exceto io2 Multi-Attach); snapshot para migrar AZ/região
• EFS: NFS, multi-AZ, múltiplas instâncias simultâneas, escala automática
• S3: object storage, 11 noves, global (nome único); classes da Standard ao Glacier Deep Archive
• S3 lifecycle: quando mover para Standard-IA, Glacier Flexible, Glacier Deep Archive
• gp3 vs io2 Block Express: io2 quando IOPS > 16k sustained ou SLA enterprise exige

Banco de Dados:

• RDS Multi-AZ = HA, síncrono, failover automático; standby NÃO serve leitura
• Read Replica = performance de leitura, assíncrono; pode ser cross-region (DR manual)
• RDS Proxy = pool de conexões; obrigatório com Lambda + RDS para evitar “too many connections”
• Aurora: quórum 4/6 para escrita, 3/6 para leitura; failover < 30s; Global DB RPO < 1s
• Aurora Serverless v2: escala compute por ACU; tráfego imprevisível
• DynamoDB: serverless, Global Tables ativo-ativo; DAX = cache exclusivo para DynamoDB
• ElastiCache Redis (persistência, HA, estruturas complexas) vs Memcached (simples, multi-thread, sem HA)
• Amazon MQ = lift-and-shift de messaging legado (ActiveMQ/RabbitMQ); SQS/SNS = cloud-native

Serverless:

• Lambda: máx 15min, cold start, Provisioned Concurrency para latência consistente
• SQS Standard (at-least-once, ilimitado) vs FIFO (exactly-once, 3k/s)
• Visibility Timeout >= tempo de processamento; DLQ para mensagens que falham repetidamente
• SNS + SQS = fan-out pattern; EventBridge = roteamento por conteúdo do evento + integração SaaS
• Step Functions: Standard (long-running, auditável) vs Express (alto volume, < 5 min)

Segurança:

• IAM evaluation: Explicit Deny > SCP > Permission Boundary > Identity Policy > Resource Policy
• KMS (gerenciado AWS, você controla uso) vs CloudHSM (você controla o hardware, FIPS 140-2 L3)
• Secrets Manager (rotação automática) vs Parameter Store (mais barato, sem rotação nativa)
• GuardDuty (ameaças ML) vs Inspector (vulnerabilidades CVE) vs Macie (PII no S3)

Custo:

• Spot (90% off, interrompível) > Savings Plans (66-72%) > Reserved (72%) > On-Demand
• ASG mixed: capacity-optimized allocation strategy reduz interrupções Spot
• Compute Optimizer → recomenda downsize/rightsize com base em uso real
• Data transfer: ingress grátis; cross-AZ $0,01/GB; egress internet ~$0,09/GB primeiros 10TB
• S3: Glacier Deep Archive ~$0,001/GB vs Standard ~$0,023/GB — lifecycle policy economiza muito

Disaster Recovery:

• Backup & Restore (horas RTO/RPO, barato) vs Pilot Light (dezenas de min) vs Warm Standby (minutos) vs Multi-Site (segundos, caro)
• Aurora Global Database: RPO < 1s, RTO < 1 min — melhor opção para DR cross-region de banco relacional