🏠Início 📚Certificações 📱Aplicativos Móveis

🎓Informações do exame

✍️Blog 📊Progresso 📅Calendário 💬Suporte

Política de Privacidade Termos de Uso Fale Conosco Política de Cookies Aviso Legal Acessibilidade DMCA / Direitos Autorais

Pular para o conteúdo

SAA-C03Guia

Guia

AWS Certified Solutions Architect Associate

Última revisão: maio de 2026

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.

Seções

Projetar Arquiteturas Seguras34 entradas
Projetar Arquiteturas Resilientes28 entradas
Projetar Arquiteturas de Alto Desempenho26 entradas
Projetar Arquiteturas Otimizadas para Custo24 entradas

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.

Instância EC2 precisa acessar S3. Evitar credenciais embutidas.

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.

Bloquear ataques SSRF que tentam ler metadados de instância EC2.

Impor IMDSv2 (`HttpTokens=required`) no lançamento da instância. Rejeitar solicitações não autenticadas do IMDSv1.

Por quê: O IMDSv2 exige um token de sessão via PUT antes que o endpoint de metadados responda; ataques SSRF que apenas fazem GETs são bloqueados.

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.

Evitar que qualquer bucket S3 na organização se torne público.

Ativar S3 Block Public Access no nível da conta (e em toda a organização via SCPs). Sobrescreve ACLs e políticas no nível do bucket.

Por quê: A configuração no nível da conta prevalece sobre as configurações por bucket — defesa contra configuração incorreta acidental.

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.

Restringir uma OU a Regiões específicas para conformidade de residência de dados.

Service Control Policy em Organizations negando qualquer ação onde `aws:RequestedRegion` não esteja na lista permitida.

Por quê: SCPs são o único mecanismo que pode negar ações que a própria conta permite. O IAM não pode negar o que um root da conta poderia conceder.

Single sign-on para a força de trabalho em várias contas AWS; integrar com IdP corporativo.

AWS IAM Identity Center (antigo AWS SSO) com federação SAML/OIDC para o IdP corporativo. Conjuntos de permissões mapeiam para roles em contas membros.

Por quê: O Identity Center é a identidade canônica de força de trabalho multi-conta. Cognito é para usuários finais de aplicativos, não funcionários.

Escolher entre Cognito User Pool e Identity Pool.

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.

Adicionar etapa de validação personalizada ao login do Cognito (ex: allowlist de domínio de e-mail).

Triggers Lambda: Pré-cadastro, Pré-autenticação, Definir/Criar/Verificar Desafio de Autenticação. Validar ou rejeitar na Lambda.

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 dados em `us-east-1`; descriptografar em `us-west-2` após a replicação, sem recriptografar.

Chave KMS multi-região. Principal em uma Região, réplica em outra, ambas com o mesmo material de chave e ID.

Por quê: Evita a etapa de re-empacotamento do texto cifrado para failover cross-Region ou DR.

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.

Escolher entre security group e NACL.

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.

EC2 em sub-rede privada deve alcançar S3/DynamoDB sem custo de saída de NAT.

VPC gateway endpoint para S3 e DynamoDB. Gratuito, entrada na tabela de rotas, sem NAT.

Por quê: Os gateway endpoints são apenas para S3/DynamoDB. Economiza custos de processamento de dados do NAT e mantém o tráfego na backbone da AWS.

Sub-rede privada deve alcançar APIs de serviços AWS (KMS, Secrets Manager, ECR, etc.) de forma privada.

VPC interface endpoint (PrivateLink) por serviço. ENI em sua VPC, cobrado por hora + por GB.

Por quê: Interface endpoints funcionam para quase todos os serviços AWS. Use para remover a saída do NAT para chamadas de serviço.

Provedor de SaaS expõe seu serviço na VPC para contas de clientes de forma privada, sem VPC peering ou manutenção de roteamento do cliente.

Serviço de endpoint AWS PrivateLink suportado por um NLB. Clientes criam interface endpoints para consumir.

Por quê: Sem preocupações com sobreposição de CIDR, sem malha de peering, exposição unidirecional (o provedor não vê tráfego do cliente).

Conectar mais de 30 VPCs entre contas e on-premises em uma topologia hub-and-spoke.

AWS Transit Gateway. Anexação única por VPC; tabelas de rotas segmentam o tráfego.

Por quê: O full-mesh peering requer N×(N-1)/2 conexões. O TGW escala linearmente e suporta cross-account via RAM.

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.

Detecção contínua de ameaças em VPC Flow Logs, DNS, CloudTrail, auditoria EKS, eventos de dados S3.

Amazon GuardDuty. Em toda a organização via administrador delegado do Organizations.

Por quê: Detecção de ameaças gerenciada. Envia descobertas para o Security Hub ou EventBridge para automação de resposta.

Descobrir e classificar PII / PHI em buckets S3.

Amazon Macie. Descoberta de dados sensíveis baseada em ML, com escopo S3, integra-se com Security Hub.

Varredura contínua de CVEs para EC2, imagens ECR, funções Lambda.

Amazon Inspector v2. Auto-descobre recursos via Systems Manager Agent, varre contra CVEs publicadas.

Agregar descobertas de GuardDuty, Inspector, Macie, IAM Access Analyzer em um único painel.

AWS Security Hub. CSPM com AWS Foundational Security Best Practices e padrões CIS.

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.

Múltiplos departamentos precisam de acesso com escopo a diferentes prefixos em um bucket S3 compartilhado.

S3 Access Points — um por departamento, cada um com sua própria política de acesso e (opcionalmente) restrição de VPC.

Por quê: Mais limpo do que uma política de bucket extensa; os access points têm seus próprios ARNs e nomes DNS.

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.

Certificado TLS público para `*.example.com` no ALB e CloudFront. Renovar automaticamente.

Certificado público do AWS Certificate Manager (ACM) com validação DNS no Route 53. Auto-renova 60 dias antes do vencimento.

Por quê: Gratuito para uso com serviços integrados da AWS. A validação por e-mail funciona, mas a validação DNS é preferível para automação.

Projetar Arquiteturas Resilientes

Banco de dados RDS de produção com failover em menos de um minuto.

Implantação Multi-AZ do RDS (ou Multi-AZ DB Cluster). Replicação síncrona para o standby; failover automático via troca de endpoint DNS.

Por quê: Multi-AZ é para HA, não para escalonamento de leitura. Read replicas são para escalonar leituras (e assíncronas; potencial atraso).

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.

Carga de banco de dados variável / imprevisível com períodos de inatividade.

Aurora Serverless v2. Escala em incrementos de 0.5 ACU; eventos de escalonamento em sub-segundos; sem pausa total, mas com mínimo muito baixo.

Por quê: v2 mantém a conexão aberta durante eventos de escalonamento (ao contrário do v1). Paga por ACU-segundo.

Leituras + escritas de um dígito em ms em mais de 3 Regiões, com replicação last-writer-wins.

DynamoDB Global Tables. Replicação multi-ativa com resolução de conflitos last-writer-wins.

Por quê: Ativo-ativo em todas as Regiões; sem líder. Use quando a tolerância a conflitos em nível de aplicação for aceitável.

Recuperar uma tabela DynamoDB para um ponto específico nos últimos 35 dias após exclusão acidental.

Habilitar Point-in-Time Recovery (PITR). A restauração cria uma nova tabela no segundo escolhido.

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.

Enviar cada usuário para a Região saudável de menor latência.

Roteamento baseado em latência do Route 53. Verifica a saúde de cada endpoint; o Route 53 retorna a resposta saudável de menor latência por consulta.

Implantação canary: enviar 10% para v2, 90% para v1.

Roteamento ponderado do Route 53. Dois registros com o mesmo nome, diferentes alvos, pesos 10 e 90.

Instâncias EC2 levam 3 minutos para inicializar; o scale-out é muito lento durante picos de tráfego.

Warm pool do Auto Scaling. Instâncias pré-inicializadas mantidas paradas (mais barato) prontas para iniciar em segundos.

Por quê: O lançamento a frio + bootstrap é o gargalo. O warm pool remove esse trabalho do caminho crítico.

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.

Escolher entre ALB e NLB.

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.

Inserir uma frota de appliances de segurança de terceiros em linha para inspeção de tráfego entre VPCs.

Gateway Load Balancer (GWLB) com frota de appliances como alvos. Tráfego encapsulado via GENEVE; inserção transparente via roteamento.

Mensagens "venenosas" continuam falhando nos handlers e sendo reenfileiradas.

SQS Dead-Letter Queue. Configurar `maxReceiveCount` na fila de origem; mensagens que excedem a contagem são movidas para a DLQ para inspeção.

Ordenação estrita e processamento exatamente uma vez por grupo de mensagens.

Fila SQS FIFO com deduplicação baseada em conteúdo ou `MessageDeduplicationId` explícito. Use `MessageGroupId` para grupos ordenados paralelos.

Por quê: O SQS Standard é "pelo menos uma vez" sem garantia de ordem. O FIFO tem menor throughput, a menos que seja usado o modo de alto throughput.

Lambda assíncrona falha em timeout downstream — capturar eventos falhos para reexecução.

Lambda Destinations: configurar destino de falha como SQS / SNS / EventBridge / outra Lambda. Destinos de sucesso também são suportados.

Por quê: Mais limpo do que DLQ na função: destinos recebem o evento completo + payload da resposta; DLQs recebem apenas o evento de trigger.

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.

Origin do CloudFront (S3 ou ALB) falha — fazer fallback para um origin secundário sem mudanças de DNS.

Grupo de origin do CloudFront com primário + secundário. Configurar critérios de failover (códigos 4xx/5xx). O CloudFront retenta contra o secundário.

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.

Backups resistentes a ransomware: mesmo um administrador não pode excluir antes da retenção.

AWS Backup Vault Lock no modo de conformidade. Aplicação WORM; nem mesmo o root pode encurtar a retenção.

Escolher um padrão de DR por requisito de RPO/RTO.

Backup & Restore: RPO horas, RTO horas, mais barato. Pilot Light: RPO minutos, RTO dezenas de minutos. Warm Standby: RPO segundos, RTO minutos. Multi-Site Ativo-Ativo: RPO ~zero, RTO segundos, mais caro.

Replicar bucket crítico cross-Region para DR com RPO inferior a 15 minutos.

S3 Cross-Region Replication (CRR) com S3 Replication Time Control (RTC). 99.99% dos objetos em 15 min.

Por quê: O CRR padrão é "melhor esforço". O RTC adiciona um SLA + métricas de replicação no CloudWatch.

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.

Tráfego TCP/UDP com baixo jitter para a Região saudável mais próxima; IPs anycast estáticos.

AWS Global Accelerator. Dois IPs anycast; roteia para o endpoint mais próximo através da backbone da AWS.

Por quê: Melhor que a latência do Route 53 para não-HTTP. Failover mais rápido (anycast) + allow-listing de IP estático.

Lambda processa pedidos do SQS — a mensagem pode ser entregue duas vezes.

Idempotência: armazenar hash de solicitação no DynamoDB com TTL; PUT-IfNotExists em cada tentativa. Ou usar fila FIFO com deduplicação.

Expulsões voluntárias de pods (dreno de nó, autoscaler de cluster) derrubam todas as réplicas de uma implantação.

Kubernetes PodDisruptionBudget especificando `minAvailable` ou `maxUnavailable`. O cluster o respeita durante interrupções voluntárias.

Projetar Arquiteturas de Alto Desempenho

Escolher uma classe de armazenamento S3.

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.

Fazer upload de objetos grandes (> 100 MB) de forma confiável e rápida pela internet.

S3 Multipart Upload (partes paralelas) + S3 Transfer Acceleration (ingestão na edge do CloudFront).

Por quê: Partes paralelas saturam a largura de banda; o Transfer Acceleration descarrega o salto WAN para a backbone da AWS.

Escolher tipo de volume EBS.

Propósito geral, padrão → gp3 (3000 IOPS base, 125 MB/s; ajustável). Banco de dados de alta IOPS → io2 Block Express. Throughput sequencial de big-data → st1. Arquivo frio → sc1. Volumes de boot → gp3.

Por quê: gp3 desvinculou IOPS/throughput do tamanho; mais barato que gp2 com desempenho equivalente.

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.

Escolher um sistema de arquivos compartilhado.

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.

EFS — escolher modo de throughput.

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).

Backup on-premises de arquivo/bloco/fita que se integra com S3 / Glacier.

AWS Storage Gateway: File Gateway (NFS/SMB → S3), Volume Gateway (iSCSI → S3 + EBS snapshots), Tape Gateway (VTL → Glacier).

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.

Manipular requisição/resposta na edge.

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.

Escolher ElastiCache Redis vs Memcached.

Replicação, persistência, pub/sub, sorted sets, failover Multi-AZ → Redis. Multi-threaded, simples key/value, apenas sharding horizontal → Memcached.

Redis session store precisa de HA com auto-failover entre AZs.

Grupo de replicação ElastiCache para Redis com Multi-AZ + failover automático habilitado. Primário em uma AZ, réplicas em outras.

Latência de leitura do DynamoDB de microssegundos; cache sem alterações no aplicativo.

DynamoDB Accelerator (DAX). Cache gerenciado na VPC; mesmo SDK do DynamoDB; read-through transparente.

Por quê: ElastiCache exige lógica de cache em nível de aplicativo. DAX é um substituto direto para DynamoDB.

Escolher uma estratégia de cache.

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.

Escolher uma plataforma de computação.

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.

Cold-start de Lambda Java prejudicando a latência p99.

Lambda SnapStart (Java, Python, .NET). Snapshot do runtime inicializado restaurado na invocação; até 10 vezes mais rápido no cold start.

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.

Escolher o tipo de API Gateway.

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.

Aplicativo móvel/web precisa de GraphQL com assinaturas em tempo real apoiadas por DynamoDB / Lambda.

AWS AppSync. GraphQL gerenciado, assinaturas WebSocket, autorização granular via Cognito / IAM / Lambda authorizers.

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.

Consultas Athena escaneiam terabytes; custo/tempo excessivos.

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×.

Consultar dados em S3 a partir do Redshift sem carregá-los.

Redshift Spectrum. Esquema externo sobre Glue Data Catalog; nós do Spectrum escaneiam S3 e transmitem os resultados de volta para o cluster.

Escolher o modo de capacidade do DynamoDB.

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).

A tabela de sessão do DynamoDB cresce sem limites; sessões expiram após 24h.

TTL do DynamoDB em um atributo epoch numérico. O DynamoDB exclui itens expirados assincronamente, sem cobrança de capacidade de escrita.

Carga de trabalho HPC precisa da menor latência possível entre nós.

Cluster placement group: instâncias na mesma AZ no mesmo rack físico. Até 10 Gbps de fluxo único.

Por quê: Spread placement → isolamento máximo (HA); Partition → big-data (Hadoop, Cassandra); Cluster → menor latência.

Projetar Arquiteturas Otimizadas para Custo

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).

Escolher entre Compute Savings Plan, EC2 Instance Savings Plan e SageMaker Savings Plan.

Compute SP: flexibilidade máxima (cobre EC2, Fargate, Lambda) — melhor padrão. EC2 Instance SP: bloqueado por família, desconto maior. SageMaker SP: apenas SageMaker.

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.

Ter Reserved Instances não utilizadas após a migração.

Vender no Reserved Instance Marketplace (somente RIs Standard). Ou converter via RIs Convertible para uma família diferente.

Por quê: As RIs conversíveis trocam um desconto ligeiramente menor pelo direito de trocar.

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.

Funções Lambda onde o runtime suporta ARM.

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.

Reduzir custos de transferência de dados.

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.

Custos do CloudWatch Logs em espiral.

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).

Encontrar candidatos a otimização de tamanho (right-sizing) em EC2, Auto Scaling Groups, EBS, Lambda.

AWS Compute Optimizer. Lê métricas do CloudWatch + ML, recomenda reduzir ou mudar de família. Gratuito para opt-in em toda a organizaçã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.

Parar gastos descontrolados em uma conta sandbox.

AWS Budgets com ação: em 80% do limite, executar uma notificação SNS; em 100%, anexar uma SCP de negação / política IAM via Ação de Budgets.

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).

Otimização de custo de frota de contêineres.

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.

Reduzir a saída de S3 / EC2 para a internet.

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.

Migrar 100 TB de NFS on-prem para S3.

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.