Uma referência rápida dos padrões arquiteturais que o exame SAA-C03 avalia. Leia de cima a baixo ou pule para uma seção.
Projetar Arquiteturas Seguras
Aplicação de três camadas: web, app, DB. O DB deve ser inacessível da internet sob qualquer circunstância.
Sub-redes públicas para a camada web (ALB). Sub-redes privadas para as camadas de aplicação e DB. O security group do DB permite tráfego apenas do security group da camada de aplicação (não de intervalos CIDR).
Por quê: Tabelas de roteamento de sub-redes impõem acessibilidade; referências de security-group-para-security-group codificam o menor privilégio na camada do SG e sobrevivem a mudanças de IP.
IAM role anexada via instance profile. O SDK recupera credenciais temporárias do IMDSv2.
Por quê: Chaves de acesso de longa duração em instâncias são a principal causa de vazamentos de credenciais. Roles são rotacionadas automaticamente, nunca persistidas.
Serviço A na Conta A invoca Lambda na Conta B. Menor privilégio.
Política baseada em recurso na Lambda de destino concedendo `lambda:InvokeFunction` ao principal da role da Conta A. O chamador assume sua própria role e invoca diretamente - não é necessário encadeamento de roles.
Por quê: Políticas de recurso são o padrão de cross-account mais simples para recursos com interface de serviço (Lambda, S3, SNS, SQS, KMS).
Outras contas AWS precisam fazer upload para um bucket S3 central.
Política de bucket concedendo `s3:PutObject` a principals de contas externas. Adicionar requisito de ACL `bucket-owner-full-control` para que o proprietário do bucket retenha o controle dos objetos.
Por quê: Sem `bucket-owner-full-control` (ou `BucketOwnerEnforced` Object Ownership), os objetos carregados são de propriedade da conta que os escreveu.
Desenvolvedores devem criar IAM roles por conta própria, mas não podem conceder permissões além de um conjunto máximo definido.
Limites de permissão (Permission Boundaries) no principal do desenvolvedor. Permissões efetivas = política de identidade ∩ limite.
Por quê: SCPs se aplicam no nível da conta/OU; os limites definem o escopo para principais individuais. Use limites para padrões de administração delegada.
User Pool = registro / login / emissão de JWT para usuários de aplicativos. Identity Pool = troca de tokens por credenciais AWS temporárias. A maioria dos aplicativos usa ambos: User Pool autentica, Identity Pool autoriza acesso AWS.
Precisa de controle total sobre rotação de chaves, exclusão e trilha de auditoria por chave.
Chave KMS gerenciada pelo cliente (CMK). As chaves gerenciadas pela AWS (`aws/<service>`) são mais simples, mas não oferecem controle de política de chave ou visibilidade sobre o uso individual da chave.
Por quê: CMKs permitem que você defina o escopo de acesso por chave no CloudTrail, configure políticas de chave para uso cross-account e desabilite/agende a exclusão.
A Conta B precisa descriptografar objetos S3 criptografados com a CMK da Conta A.
Política de chave na CMK concede `kms:Decrypt` aos principais da Conta B. O IAM da Conta B também precisa de `kms:Decrypt` no ARN da chave. Ambas as partes são necessárias.
Por quê: KMS cross-account exige permissão explícita tanto na política de chave quanto na identidade IAM do chamador (ao contrário da maioria das políticas de recurso).
Criptografar objetos grandes sem que as chamadas de API KMS por objeto dominem o custo.
Envelope encryption. O KMS gera uma chave de dados (uma chamada de API); use a chave de dados para criptografar o payload localmente; armazene a chave de dados criptografada junto com o texto cifrado.
Por quê: O KMS é limitado por taxa e precificado por solicitação. O padrão de envelope é a forma canônica de criptografar dados > alguns KB.
Escolher entre Secrets Manager e SSM Parameter Store SecureString.
Credenciais de DB com rotação automática, compartilhamento cross-account, segredos grandes → Secrets Manager. Flags de configuração, configurações de aplicativo, segredos simples, menor custo → SSM Parameter Store.
Por quê: O Secrets Manager possui Lambdas de rotação integradas para RDS/Aurora/DocumentDB/Redshift; o Parameter Store não possui rotação nativa, mas é gratuito para o nível Standard.
Rotacionar senha do RDS automaticamente a cada 30 dias.
Secrets Manager com rotação gerenciada. O template Lambda integrado lida com a rotação de um único usuário contra o endpoint do RDS. Os aplicativos buscam o segredo no momento da conexão (em cache) - sem necessidade de redeploy do aplicativo.
Mitigar inundação HTTP da Camada 7 sem bloquear picos legítimos.
Regra baseada em taxa do AWS WAF (ex: 2000 solicitações / 5 min por IP) no ALB ou CloudFront. Combinar com grupos de regras gerenciados para IPs conhecidos como maliciosos.
Por quê: Regras de taxa do WAF rastreiam por IP de origem; bloqueiam automaticamente quando o limite é excedido; liberam após a janela.
Aplicativo de missão crítica precisa de proteção de custo contra DDoS e suporte 24×7 da SRT.
AWS Shield Advanced no CloudFront / ALB / NLB / Global Accelerator. Inclui proteção de custo (reembolsos por gastos de escalonamento durante ataque) + acesso à Shield Response Team.
Por quê: O Shield Standard é automático e gratuito; o Advanced adiciona proteções e SLA. O CloudFront é sempre a porta de entrada recomendada.
Stateful, anexar a ENI, apenas permitir → security group (padrão). Stateless, nível de sub-rede, permitir + negar explicitamente → NACL. Use NACLs para regras de negação abrangentes (bloquear intervalos de IP); SGs para todo o resto.
Por quê: NACLs avaliam o tráfego de entrada e saída separadamente. SGs permitem automaticamente o tráfego de retorno.
Conectividade híbrida que precisa de largura de banda previsível, baixa latência e criptografia.
Direct Connect com uma VPN Site-to-Site sobre o DX (MACsec ou IPsec). O DX sozinho é não criptografado; VPN sobre DX é privada + criptografada + baixo jitter.
Por quê: VPN simples pela internet é barata, mas tem latência variável. O DX sozinho é rápido, mas em texto simples na camada de enlace.
Garantir que todos os volumes EBS sejam criptografados; remediar recursos não conformes automaticamente.
Regras do AWS Config (`encrypted-volumes` gerenciadas) + runbook de automação do Systems Manager para remediação, acionado via ação de remediação do Config.
Log de auditoria único e à prova de adulteração em todas as contas da organização.
Trilha de organização com validação de arquivo de log habilitada, gravada em um bucket S3 central com política de bucket negando exclusão.
Por quê: As trilhas da organização são habilitadas automaticamente em todas as contas membros (atuais e futuras). Hashes de validação comprovam que os logs não foram modificados.
Carga de trabalho PCI DSS - isolamento estrito de contas não PCI.
Conta AWS dedicada dentro de uma OU do Organizations com SCPs restringindo o acesso a serviços/regiões. VPC separada, chaves KMS, IAM roles. Network Firewall ou GWLB para inspeção de saída.
Por quê: O limite da conta é o isolamento de raio de explosão mais forte na AWS.
Escolher Aurora vs RDS para uma nova carga de trabalho MySQL/PostgreSQL.
Aurora para maior throughput, failover mais rápido, até 15 read replicas, Global Database, Serverless v2. RDS para engines mais antigos (MariaDB, Oracle, SQL Server) ou implantações mais simples/baratas.
Por quê: O armazenamento do Aurora é compartilhado entre as réplicas (sem atraso de réplica do armazenamento). Failover < 30s é típico.
Banco de dados multi-região ativo-passivo com atraso de replicação < 1s e RTO < 1 min.
Aurora Global Database. Replicação em nível de armazenamento para até 5 Regiões secundárias; promover uma secundária a primária em caso de desastre.
Por quê: A replicação usa infraestrutura dedicada; o atraso entre Regiões é tipicamente < 1s. Read replicas em Regiões remotas para leituras locais de baixa latência.
Redirecionar tráfego para a Região primária; fazer failover para a secundária em caso de falha na verificação de saúde.
Política de roteamento de failover do Route 53. Verificação de saúde ativa no endpoint primário; o registro secundário é servido quando o primário está insalubre.
Por quê: A verificação de saúde da camada de aplicação (caminho HTTP) captura falhas parciais que as sondagens TCP perdem.
No scale-in, drenar o trabalho em andamento e persistir logs antes que a instância seja encerrada.
Hook de ciclo de vida do Auto Scaling em `Terminating:Wait`. O hook publica para SNS/EventBridge; o handler completa o dreno e chama `complete-lifecycle-action`.
Reduzir o custo de computação em uma frota não crítica que tolera interrupção.
ASG com política de instâncias mistas: capacidade base em On-Demand, capacidade adicional em Spot, múltiplos tipos de instância e AZs para diversificação.
Por quê: Diversificar entre tipos de instância reduz o risco de interrupção do Spot em comparação com um único pool.
HTTP/HTTPS, roteamento por caminho/host, integração WAF, autenticação OIDC → ALB. TCP/UDP/TLS em escala extrema, IP estático por AZ, menor latência, preservar IP de origem do cliente → NLB.
Workflow de várias etapas precisa de retry por tarefa com backoff exponencial e tratamento de erro.
Workflow Standard do AWS Step Functions. Bloco `Retry` com `IntervalSeconds`, `MaxAttempts`, `BackoffRate`. Bloco `Catch` roteia erros específicos para um estado de recuperação.
Centralizar backups em EBS, RDS, DynamoDB, EFS, FSx com uma única política de retenção.
AWS Backup com planos de backup + seleção de recursos por tag. Cópia cross-account / cross-Region suportada. Vault Lock para imutabilidade de conformidade.
Proteger objetos S3 contra exclusão acidental e sobrescrita por ransomware.
Habilitar S3 Versioning + MFA Delete + Object Lock (modo governança ou conformidade) em buckets críticos.
Por quê: O versionamento preserva sobrescritas/exclusões; o Object Lock bloqueia a exclusão antes da retenção; o MFA Delete adiciona um segundo fator para remoção permanente.
Aplicativo global precisa de failover RTO zero entre duas Regiões.
Ativo-ativo entre Regiões: Global Accelerator ou roteamento de latência do Route 53 para entrada; DynamoDB Global Tables / Aurora Global Database para dados; replicação cross-Region para armazenamento de objetos.
Acesso frequente → Standard. Padrão de acesso desconhecido → Intelligent-Tiering. Infrequente por mais de 30 dias → Standard-IA. Single-AZ aceitável, infrequente → One Zone-IA. Arquivo, recuperação em ms → Glacier Instant. Arquivo, minutos → Glacier Flexible. Arquivo, horas, mais barato → Glacier Deep Archive.
Bucket de acesso misto com padrões imprevisíveis; otimizar custo automaticamente.
S3 Intelligent-Tiering. Monitora o acesso; move automaticamente objetos entre camadas (Frequent / Infrequent / Archive Instant / Archive / Deep Archive). Sem taxas de recuperação.
Por quê: Pequena taxa de monitoramento por objeto, mas mais barato do que adivinhar errado. Padrão para padrões desconhecidos.
Múltiplas instâncias EC2 devem ler+escrever no mesmo volume de bloco.
EBS Multi-Attach com io2 / io1 (somente instâncias Nitro). Anexação concorrente a até 16 instâncias na mesma AZ.
Por quê: A aplicação deve coordenar as escritas (sistema de arquivos em cluster). EFS é o padrão para acesso a arquivos compartilhados; Multi-Attach é para DBs em cluster que precisam de bloco.
NFS Linux compatível com POSIX, multi-AZ, auto-escalável → EFS. Windows SMB / integrado com AD → FSx for Windows. HPC, Lustre, vinculado ao S3 → FSx for Lustre. Recursos do NetApp ONTAP (snapshots, ferramentas NetApp) → FSx for ONTAP. ZFS → FSx for OpenZFS.
Carga de trabalho variável, escala com o tamanho → Bursting. Alto throughput previsível → Provisioned. Sensível a picos, mas com gasto elástico → Elastic (padrão para novos sistemas de arquivos, escala automaticamente).
Ativos estáticos + respostas de API com usuários globais; reduzir a carga do origin.
CloudFront com política de cache apropriada. TTLs longos para estáticos; cache-key inclui apenas cabeçalhos/query strings essenciais. Use Origin Shield para origins de alta cardinalidade.
Por quê: A taxa de acerto do cache impulsiona tanto o desempenho quanto o custo. Uma cache key errada (ex: incluir todos os cabeçalhos) destrói a taxa de acerto.
Leve, do lado do visualizador, sub-ms (reescritas de cabeçalho, redirecionamentos, A/B) → CloudFront Functions. Mais pesado, Node.js / Python, computação mais longa, acesso à rede → Lambda@Edge.
Lazy loading (cache miss → buscar + popular): simples, apenas armazena em cache o que é solicitado. Write-through (escrever no cache + DB na atualização): cache sempre atualizado, mas escritas extras. TTL: limita a desatualização em ambos os padrões.
Orientado a eventos sub-15min, escala em sub-segundos, sem infra → Lambda. Contêineres de longa execução, sem gerenciamento de nós → Fargate. Kernel personalizado, GPU, estado persistente, mais barato sustentado → EC2.
Carga de pico previsível; cold starts inaceitáveis.
Provisioned Concurrency. Ambientes pré-aquecidos prontos para invocar em qualquer throughput. Combinar com Application Auto Scaling para scale-up agendado.
Por quê: Custa mais que on-demand, mas elimina o cold start. Não é necessário para tráfego constante onde a utilização da provisioned-concurrency permanece alta naturalmente.
Conjunto completo de recursos (validação de solicitação, transformações, chaves de API, planos de uso) → REST API. Menor custo, menor latência, nativo JWT/OIDC, mais simples → HTTP API. Bidirecional em tempo real → WebSocket API.
Escolher entre Kinesis Data Streams vs Firehose vs Managed Service para Apache Flink vs MSK.
Consumidores personalizados, latência em ms, replay, fan-out multi-consumidor → Data Streams. Apenas entregar para S3/Redshift/OpenSearch com bufferização → Firehose. Processamento de stream (janelas, joins) → Managed Service para Apache Flink. Compatível com Kafka → MSK.
Particionar os dados por predicado de consulta (data, região). Converter para formato colunar Parquet/ORC. Usar projeção de partição para evitar round-trips de catálogo.
Por quê: O Athena cobra por TB escaneado. Columnar + particionamento frequentemente reduz o custo em 10-100×.
Cargas de trabalho imprevisíveis / com picos / novas → On-demand. Estável, previsível, "quente" - e sensível ao custo → Provisioned com auto-escalonamento. Trocar modos no máximo uma vez a cada 24 horas.
Consultar DynamoDB por um atributo que não é a chave de partição.
Global Secondary Index (GSI) para consultas em diferentes chaves de partição. Local Secondary Index (LSI) para chave de classificação alternativa na mesma chave de partição (LSI deve ser criado no momento da criação da tabela).
Escolher opção de compra de EC2 para uma frota estável 24×7.
Compute Savings Plan (1 ano ou 3 anos) - 66% de desconto na lista, flexível entre família de instâncias, tamanho, OS, tenancy, Região. RIs apenas quando precisar de reserva de capacidade.
Por quê: Savings Plans dominam RIs para a maioria dos casos de uso apenas de custo (mais flexíveis, mesmo desconto).
Usar Spot para economia de custos em cargas de trabalho tolerantes.
Spot via política de instâncias mistas do ASG com estratégia de alocação otimizada por capacidade + múltiplos tipos de instância. Lidar com aviso de interrupção de 2 minutos via metadados da instância.
Por quê: O otimizado por capacidade seleciona pools menos propensos a serem recuperados. Múltiplos tipos diversificam o risco do pool.
Reduzir o custo de computação sem reescrever a arquitetura.
Migrar para instâncias Graviton (ARM64). ~20% mais barato, ~40% melhor preço-desempenho para muitas cargas de trabalho. Requer imagens de contêiner multi-arquitetura ou binários recompilados.
Definir arquitetura para `arm64` (Graviton). 20% mais barato por ms do que x86, frequentemente mais rápido. Requer dependências nativas compatíveis com a arquitetura.
Custo da Lambda muito alto; runtime limitado pela CPU.
Aumentar a memória (o que escala CPU e rede proporcionalmente). Usar Lambda Power Tuning (ferramenta Step Functions) para encontrar o ponto ideal - frequentemente mais memória é mais rápido E mais barato.
Logs e objetos antigos se acumulam no S3 Standard.
Regras de ciclo de vida do S3: transição para IA após 30d, Glacier Flexible após 90d, Deep Archive após 180d, expirar após retenção. Combinar com Intelligent-Tiering para padrões desconhecidos.
Visualizar gastos do S3 em todas as contas; encontrar candidatos à otimização.
S3 Storage Lens. Painel em toda a organização com uso, atividade, recomendações de economia de custos. Nível de métricas avançadas para detalhamento por prefixo.
Taxas de processamento de dados do NAT Gateway dominam a fatura.
Substituir tráfego de serviço AWS por VPC Endpoints (gateway para S3/DynamoDB; interface para todo o resto). Mover cargas de trabalho que precisam de saída para a internet para sub-redes públicas apenas quando necessário.
Por quê: O NAT Gateway cobra por GB processado, mesmo para tráfego de serviço AWS. Endpoints eliminam esse caminho.
Mesma AZ, mesma VPC = grátis. Cross-AZ = $0.01/GB em cada sentido. Cross-Region = caro. Saída para internet = mais caro, mas grátis via CloudFront para conteúdo cacheável. Sempre sair via CloudFront quando possível.
Definir retenção explícita (o padrão é "Nunca expirar"). Exportar logs antigos para S3 + Glacier. Usar Logs Insights apenas em dados "quentes". Filtrar no agente (não enviar logs de depuração em produção).
Detectar picos de gastos inesperados de forma proativa.
Detecção de Anomalias de Custo da AWS (dentro do Cost Explorer). Monitores baseados em ML por serviço / conta vinculada / categoria de custo. Alertas via SNS / e-mail.
Rateio de custos por equipe ou produto sem contas separadas.
Tags de alocação de custos. Ativar tags definidas pelo usuário no console de Faturamento; exibir no Cost Explorer + CUR. Combinar com `aws:CreatedBy` para atribuição de identidade.
Instâncias EC2 de dev/teste rodando 24×7 - usadas apenas das 9h às 17h.
AWS Instance Scheduler (Lambda implantada via CloudFormation). Marcar instâncias com nomes de agendamento; executa start/stop tipo cron. Ou apenas `aws:autoscaling:scheduledActions` em ASGs de dev.
Por quê: ~70% de redução nos gastos de computação de desenvolvimento com parada fora do horário comercial.
Instância RDS de desenvolvimento ociosa durante noites/fins de semana.
Parar a instância RDS (single-AZ; até 7 dias, depois inicia automaticamente). Ou Aurora Serverless v2 com ACU mínimo = 0.5 (sem parada total, mas custo mínimo quando ocioso).
Utilização estável e alta → ECS em EC2 (com Spot/Savings Plans) - mais barato. Com picos / de curta duração / sem gerenciamento de nós → Fargate. Fargate Spot tem 70% de desconto no Fargate para cargas de trabalho tolerantes.
Usar CloudFront como front-end. Transferência Origin → edge é gratuita; edge → usuário é mais barato do que saída direta de EC2/S3 em escala. Habilitar compressão + TTLs apropriados.
Agente AWS DataSync on-prem; transferência agendada para S3. Criptografado, com verificação de integridade, com limite de taxa. Snowball Edge para 100 TB+ ou baixa largura de banda.
Mover > 1 PB de on-prem para AWS; largura de banda muito lenta para transferência online.
Família AWS Snow. Snowball Edge Storage Optimized (80 TB) para casos típicos; múltiplos dispositivos em paralelo para centenas de TB. Snowmobile foi aposentado - use múltiplos Snowball para escala de petabytes.
RDS / ElastiCache / OpenSearch / Redshift de produção rodando 24×7.
Reserved Instances para bancos de dados gerenciados (sem equivalente a Savings Plan para esses serviços). 1 ano ou 3 anos; pagamento parcial antecipado geralmente tem o melhor VPL.
Ganhos rápidos de custo com pouco esforço em toda a conta.
Verificações de custo do AWS Trusted Advisor: load balancers ociosos, EC2 de baixa utilização, EBS não anexado, RDS subutilizado, Redshift ocioso. Camada gratuita limitada; conjunto completo com Business / Enterprise Support.