No exame AWS DOP-C02, os dominios de "Design de alta disponibilidade e resiliencia", "Solucoes de escalabilidade" e "Recuperacao automatica e de desastres" juntos representam aproximadamente 35% do total de questoes. O exame avalia principalmente o julgamento arquitetonico, nao a memorizacao, portanto e necessario compreender tanto o funcionamento interno de cada servico quanto os cenarios exatos onde cada um se aplica.
Padroes de design para alta disponibilidade
Health checks profundos no ALB — Isolamento automatico de SPOF
O health check padrao do ALB verifica apenas se uma porta TCP esta aberta. Isso significa que o balanceador de carga continuara roteando trafego para uma instancia que esta ativa mas nao consegue atender solicitacoes porque sua conexao com o banco de dados ou uma dependencia externa falhou. Os usuarios recebem erros 500 ou 503 como resultado.
A solucao e configurar o ALB para usar um health check HTTP contra um endpoint dedicado (tipicamente ) que verifica proativamente as dependencias internas.
Quando o ALB recebe um 503 do health check, ele remove automaticamente a instancia do grupo de destino. Isso requer apenas uma mudanca no codigo da aplicacao — sem modificacoes de infraestrutura — tornando-o a resposta correta para questoes que especificam "minimizar mudancas na infraestrutura existente."
O Route 53 Failover opera no nivel de DNS e nao pode controlar o trafego de instancias individuais com a mesma granularidade. O CloudWatch Alarm combinado com Auto Scaling funciona substituindo instancias nao saudaveis, o que introduz latencia comparado a bloquear o trafego imediatamente no balanceador de carga.
Aurora Global Database — Leituras globais com soberania de dados regional
O Aurora Global Database consiste em uma regiao primaria (leitura e escrita) e ate cinco regioes secundarias (somente leitura). Ele usa uma infraestrutura de replicacao dedicada na camada de armazenamento, atingindo latencia de replicacao inferior a um segundo da regiao primaria para as secundarias.
| Atributo | Aurora Global Database | DynamoDB Global Tables | |----------|------------------------|------------------------| | Modelo de dados | Relacional (MySQL/PostgreSQL) | NoSQL (chave-valor/documento) | | Regioes de escrita | Apenas uma regiao primaria | Todas as regioes simultaneamente | | Mecanismo de replicacao | Camada de replicacao fisica dedicada | Baseado em DynamoDB Streams | | Recuperacao de desastres | Promocao de regiao secundaria em menos de 1 minuto | Failover ativo-ativo automatico |
A funcionalidade Write Forwarding permite que escritas realizadas contra uma regiao secundaria sejam automaticamente encaminhadas para a regiao primaria para processamento. Embora conveniente, os dados sao realmente armazenados na regiao primaria, nao na secundaria. Em ambientes com requisitos de soberania de dados regional, o Write Forwarding viola a conformidade e nao deve ser usado.
DynamoDB Global Tables — Ativo-ativo multirregiao
Quando todas as regioes de um servico global precisam lidar com leituras e escritas simultaneamente, o DynamoDB Global Tables e a escolha correta.
Caracteristicas principais: Todas as replicas em cada regiao aceitam tanto leituras quanto escritas Replicacao assincrona baseada em DynamoDB Streams, tipicamente propagando em menos de um segundo Conflitos de escrita concorrente resolvidos automaticamente usando Last Writer Wins (LWW) Nenhum pipeline de replicacao personalizado necessario
A distincao em relacao ao Aurora Global Database e um topico frequente no exame. A frase "escritas de todas as regioes" aponta para o DynamoDB Global Tables. A frase "manter a estrutura de banco de dados relacional" aponta para o Aurora Global Database.
Route 53 Latency Routing + Health Check
Para obter otimizacao de latencia e failover automatico simultaneamente, associe Health Checks a registros de politica de roteamento por latencia — nao use o tipo de registro Failover.
Roteamento por latencia: direciona cada usuario para a regiao com o tempo de resposta mais rapido Associacao de health check: exclui automaticamente as regioes com falha das respostas DNS
O tipo de registro Failover e uma construcao binaria Primario/Secundario. Durante a operacao normal, ele nao pode distribuir trafego entre multiplas regioes. O roteamento por geolocalizacao serve os usuarios com base em sua localizacao geografica, adequado para conformidade e localizacao de conteudo. Para otimizacao de desempenho, o roteamento por latencia e a escolha correta.
ARC Zonal Shift — Isolamento imediato de zonas de disponibilidade
Quando a infraestrutura falha em uma AZ especifica, o trafego pode continuar fluindo para aquela AZ enquanto o Auto Scaling ainda esta no processo de substituir instancias nao saudaveis. O Zonal Shift do AWS Application Recovery Controller move todo o trafego de ALB ou NLB da AZ afetada para AZs saudaveis com uma unica chamada de API.
Mudanca de trafego imediata sem atrasos de DNS TTL Integra-se com ALB e NLB no nivel do grupo de destino Pode ser acionado automaticamente com base em alarmes do CloudWatch Pode permanecer ativo por ate 72 horas
O failover do Route 53 requer aguardar o vencimento do TTL de DNS antes que a propagacao seja concluida. O Zonal Shift e a resposta correta quando o cenario exige isolamento imediato de trafego por AZ.
Solucoes de escalabilidade — Padroes principais
ASG Lifecycle Hooks + Warm Pool — Resolvendo atrasos de inicializacao
Quando as instancias requerem varios minutos apos a inicializacao para completar a configuracao, registra-las no balanceador de carga antes que a inicializacao termine causa falhas nas solicitacoes dos usuarios.
Como os Lifecycle Hooks funcionam:
O tempo de espera padrao e de uma hora, extensivel ate 48 horas. Enviar um sinal ABANDON encerra a instancia se a inicializacao falhar.
O Warm Pool mantem instancias pre-inicializadas em estado parado ou em execucao. Quando ocorre um evento de scale-out, as instancias do Warm Pool fazem a transicao para InService imediatamente, eliminando atrasos de cold start. Instancias em estado parado incorrem apenas em custos de armazenamento EBS — sem cobranças de instancias EC2 — tornando essa abordagem eficiente em termos de custo.
Estrategia de combinacao de politicas de Auto Scaling
| Politica | Comportamento | Melhor caso de uso | |----------|--------------|-------------------| | Target Tracking | Mantem um valor alvo de metrica, AWS gerencia alarmes automaticamente | Cargas de trabalho gerais | | Step Scaling | Passos de escalamento imediatos em limiares de alarme do CloudWatch | Picos de trafego impresvisiveis | | Scheduled Scaling | Pre-escala em momentos definidos | Padroes de trafego previsiveis | | Predictive Scaling | Baseado em ML, requer 7-14 dias de dados historicos | Padroes ciclicos recorrentes |
Cenarios de exame que pedem para lidar com "picos de trafego imprevisiveis" enquanto "reduzem custos durante noites e fins de semana" — sem adicionar Lambda ou EventBridge — requerem a combinacao Target Tracking + Step Scaling. O Predictive Scaling tem dificuldades com picos de eventos pontuais. O Scheduled Scaling so ajuda quando o padrao e consistente.
Pipeline serverless Kinesis Data Streams + Lambda + DynamoDB
Este e o design padrao de pipeline serverless para processar eventos de alta frequencia de milhares de sensores IoT ou fontes similares em tempo real.
O Kinesis Data Streams escala via shards. Cada shard processa 1 MB/s de escritas e 2 MB/s de leituras. O mapeamento de fonte de eventos do Lambda aciona automaticamente a execucao do Lambda, com concorrencia proporcional ao numero de shards.
Kinesis Data Firehose vs Kinesis Data Streams: Kinesis Data Streams: processamento em tempo real, requer aplicacao consumidora personalizada, latencia em milissegundos Kinesis Data Firehose: totalmente gerenciado, entrega diretamente para S3/Redshift/OpenSearch, pode armazenar em buffer por minutos
Se armazenamento chave-valor e consultas de dashboard em tempo real sao necessarias, use Kinesis Data Streams + Lambda + DynamoDB. Se o objetivo e arquivo de longo prazo e analitica em lote, use Kinesis Data Firehose + S3.
ECS + Fargate — Conteineres serverless
Para eliminar a carga operacional de correcao do sistema operacional, atualizacoes de seguranca e gerenciamento de capacidade em um ambiente de conteineres baseado em EC2, use o AWS Fargate.
Fargate: AWS gerencia completamente o host do conteiner ECS + Fargate: adequado para cargas de trabalho de conteineres simples e equipes pequenas EKS + Fargate: adequado quando funcionalidades do Kubernetes sao necessarias
As integracoes do servico ECS com ALB suportam mapeamento dinamico de portas, permitindo que multiplas tarefas de conteiner sejam registradas em um grupo de destino de ALB simultaneamente.
Quando o ECS Fargate implantado em uma sub-rede privada falha ao extrair imagens do ECR, e as permissoes IAM sao confirmadas como corretas, a causa raiz quase sempre sao VPC endpoints faltando. Endpoints necessarios:
— chamadas para a API do ECR — protocolo de registro Docker (gateway) — as camadas de imagem do ECR sao armazenadas no S3 — CloudWatch Logs (recomendado)
Permissoes IAM corretas combinadas com falha na extracao de imagem e um forte sinal de VPC endpoints faltando.
Comparacao de estrategias de recuperacao de desastres
As quatro estrategias DR
| Estrategia | RTO | RPO | Custo | Descricao | |------------|-----|-----|-------|-----------| | Backup & Restore | Horas | Horas | Mais baixo | Restauracao completa a partir de backup | | Pilot Light | 30-60 min | Minutos-segundos | Baixo | Apenas servicos principais em escala minima | | Warm Standby | 5-15 min | Segundos-minutos | Medio | Stack completo em escala reduzida sempre ativo | | Multi-Site Active-Active | Segundos ou menos | Quase zero | Mais alto | Todas as regioes servindo trafego ao vivo |
Os numeros de RTO e RPO sao os criterios de selecao principais: RTO