Amazon DOP-C02: Alta Disponibilidade, Resiliência e Recuperação de Desastres — Guia de estudos

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Faz parte do AWS DevOps Engineer Professional DOP-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Alta disponibilidade e recuperação de desastres na AWS focam em reduzir o tempo de inatividade (RTO) e a perda de dados (RPO) em caso de falhas de componentes, de Zonas de Disponibilidade (AZ) ou Regionais. Arquiteturas Multi-AZ absorvem falhas de AZ sem perda de dados e com impacto mínimo no serviço; arquiteturas multirregionais lidam com interrupções Regionais e eventos de grande escala. A seleção entre as estratégias ativo/ativo, ativo/passivo (warm standby) e pilot-light é orientada pelas metas de RTO/RPO do negócio, requisitos de consistência e custo. Alcançar esses objetivos exige um design coeso que abranja roteamento DNS, elasticidade da computação, balanceamento de carga, replicação/failover de banco de dados, armazenamento de objetos durável com replicação/versionamento, backup centralizado e verificação contínua da resiliência por meio de injeção de falhas.

Arquiteturas para RTO/RPO e roteamento inteligente

Multi-AZ e multirregional:

Multi-AZ: Posicione instâncias redundantes em pelo menos duas sub-redes em AZs diferentes, atrás de um load balancer. Use bancos de dados gerenciados com replicação síncrona (RDS Multi-AZ, Aurora Multi-AZ/cluster). O RPO é tipicamente zero para armazenamento síncrono; as metas de RTO variam de menos de um minuto (Aurora) a alguns minutos (failover do RDS Single-Instance Multi-AZ).
Multirregional: Escolha ativo/ativo para o menor RTO com isolamento regional e baixa latência, ou warm standby/pilot light para DR otimizado em custo. A replicação de dados deve atender ao RPO: réplicas de banco de dados assíncronas, Aurora Global Database (RPO típico <1 s), tabelas globais do DynamoDB (multirregional, multiativo) e S3 Cross-Region Replication (CRR) com o opcional Replication Time Control (RTC) para replicação com garantia de SLA.

Políticas de roteamento e verificações de saúde do Route 53:

Roteamento de failover: Crie dois registros para o mesmo nome: Primário e Secundário. Associe uma verificação de saúde ao Primário (ou use “Evaluate Target Health” para alias de ALB/NLB). Em caso de falha, o tráfego é desviado para o Secundário. Mantenha o TTL baixo (ex: 60 s) para reduzir o atraso do cache de DNS e monitore o status da verificação de saúde com alarmes do CloudWatch.
Roteamento baseado em latência: Direcione os usuários para a Região com a menor latência medida. Associe verificações de saúde a cada registro para garantir que apenas endpoints saudáveis recebam tráfego. Combine com stacks multirregionais e armazenamentos de dados regionais que suportem consistência eventual/forte, conforme necessário.
Roteamento ponderado: Divida o tráfego por porcentagem para suportar lançamentos canary, testes A/B ou prontidão de DR “a conta-gotas” (por exemplo, 1% para o secundário continuamente). Combine com verificações de saúde para que os pesos não saudáveis sejam excluídos. Use a mudança gradual de pesos para migrar o tráfego durante uma evacuação Regional.
Verificações de saúde: Sonde endpoints HTTP(S)/TCP ou alarmes do CloudWatch. Para aliases de ALB/NLB, habilite “Evaluate Target Health” para herdar a saúde do target group. Projete os endpoints de saúde para refletir a prontidão real (dependências acessíveis, migrações aplicadas). Para aplicações stateful, inclua verificações de dependência (banco de dados, cache) para evitar o roteamento para instâncias parcialmente saudáveis.

Padrões resilientes por objetivo:

RPO baixo, RTO de menos de um minuto globalmente: Ativo/ativo com roteamento baseado em latência e verificações de saúde do Route 53, computação stateless local na região, tabelas globais do DynamoDB ou Aurora Global Database, S3 CRR com RTC para objetos críticos.
RPO moderado (≤15 min), RTO ≤4 horas: Warm standby com secundário em escala reduzida, réplica de banco de dados assíncrona (read replica cross-Region do RDS ou Aurora Global), roteamento de failover do Route 53, runbooks ou automação para escalar e promover no failover.
DR otimizado em custo: Pilot light apenas para os serviços de dados principais, infraestrutura como código para escalar a camada de aplicação sob demanda, RPO determinado pela frequência de replicação, RTO pelo tempo de provisionamento e recuperação de dados.

Engenharia do caos e o AWS Fault Injection Simulator (FIS)

Experimentos de caos validam que os mecanismos de HA (alta disponibilidade) e DR (recuperação de desastres) se comportam conforme o projetado. O AWS FIS orquestra falhas controladas com mecanismos de proteção (guardrails):

Modelos de experimento (experiment templates) definem ações (por exemplo, parar ou reiniciar uma porcentagem de instâncias EC2 em um ASG, injetar estresse de CPU ou memória via SSM, adicionar latência de rede/perda de pacotes em instâncias, eliminar pods do EKS, parar tarefas do ECS, acionar o failover do RDS/Aurora) e alvos (targets), como tags de recursos e ARNs.
Controles de segurança (safety controls): Especifique condições de parada baseadas em alarmes do CloudWatch, limites de tempo, restrições de raio de impacto (blast radius) via tags/filtros e verificações prévias (pre-checks). Execute primeiro em ambientes de não produção e, depois, em produção com mecanismos de proteção rigorosos e aprovação da área de negócios.
Observabilidade: Monitore KPIs (indicadores-chave de desempenho), como taxa de erros, latência de cauda (tail latency), idade da fila (queue age), atraso da réplica (replica lag), e verifique as respostas automatizadas, incluindo reações do Auto Scaling, convergência da saúde do load balancer, failover do Route 53, promoção do banco de dados e comportamento do circuit breaker.
Resiliência contínua: Integre experimentos em pipelines/gamedays para evitar que o desvio de configuração (configuration drift) degrade a resiliência. Use o Parameter Store ou o AppConfig para feature toggles e para coordenar rollouts seguros.

Cenário de Problema Prático

O Expedia Group opera uma API global de busca de viagens que deve fornecer um RTO (Recovery Time Objective) inferior a 60 segundos e um RPO (Recovery Point Objective) próximo de zero para dados críticos de reserva, mantendo baixa latência para usuários na América do Norte e na Europa. A equipe enfrenta quedas de performance parciais (brownouts) na Região e instabilidade induzida por deployments, e os auditores exigem backups imutáveis entre contas (cross-account) e exercícios de DR documentados.

Abordagem passo a passo:

Estabelecer stacks multi-Region, ativo/ativo

Implantar stacks de API stateless em us-east-1 e eu-west-1 em múltiplas AZs, atrás de ALBs. Usar o roteamento baseado em latência do Route 53 com health checks e a opção Evaluate Target Health em registros de alias. Isso proporciona roteamento de baixa latência e desvio automático da Região se um endpoint não estiver saudável.

Datastore global com baixo RPO

Migrar dados de reserva e sessão para o Amazon Aurora Global Database (compatível com MySQL), com us-east-1 como primária e eu-west-1 como secundária. O RPO típico de <1 s e o RTO de <1 min atendem à meta de interrupção. Usar os endpoints de cluster e de leitura (reader) na configuração da aplicação com tentativas de repetição (retry/backoff) para tolerar failovers.

Escalabilidade resiliente e transições suaves (graceful)

Configurar o target tracking do Auto Scaling com base na métrica RequestCountPerTarget do ALB, com capacidade mínima em ambas as Regiões. Adicionar warm pools dimensionados para absorver picos de tráfego de 10x durante grandes eventos e usar lifecycle hooks do tipo Launching:Wait para atrasar o registro da instância até que as verificações de prontidão da aplicação sejam aprovadas. Habilitar o deregistration delay do ALB para 120 segundos para preservar requisições em andamento (in-flight) durante eventos de scale-in e deployments.

DR para objetos duráveis

Habilitar o S3 Versioning e o CRR (Cross-Region Replication) com RTC (Replication Time Control) para documentos de itinerário de us-east-1 para eu-west-1. Usar uma IAM role dedicada para replicação e chaves KMS em ambas as Regiões, concedendo a permissão kms:Decrypt na origem e kms:Encrypt no destino. As métricas e os alertas do RTC fornecem confiança nos SLAs de replicação.

Controles de DNS para canary e failover

Adicionar registros ponderados (weighted) no Route 53 (fluxo constante de 1% para eu-west-1) para exercitar continuamente o caminho secundário. Combinado com health checks, isso garante que o ambiente de standby esteja pronto para produção e detecta desvios de configuração (drift) antes de uma crise.

Backups centralizados e imutáveis

Em uma conta de backup de propriedade da equipe de segurança, criar cofres (vaults) do AWS Backup com Vault Lock e CMKs do KMS. Definir políticas de backup no nível da organização para agendar backups diários e cópias entre contas (cross-account) para RDS, DynamoDB, EFS e EBS. Atribuir recursos pela tag Backup_Frequency. Isso proporciona resistência a ransomware e separação de responsabilidades (separation of duties).

Orquestração de failover automatizada

Implementar uma regra do EventBridge para detectar sinais de falha na primária do Aurora e invocar uma função Lambda que promove a Região secundária e atualiza um endpoint da aplicação armazenado no Parameter Store. As aplicações carregam o endpoint na inicialização e o atualizam em caso de erros de conexão, minimizando etapas manuais.

Validação de caos com o AWS FIS

Criar modelos de experimento do FIS para: terminar 10% das instâncias do ASG, injetar 150 ms de latência e 1% de perda de pacotes em instâncias EC2 via SSM e acionar o failover do Aurora. Proteger com condições de parada baseadas em alarmes do CloudWatch para a latência p95 e a taxa de erros. Executar gamedays mensais para validar a velocidade do failover do Route 53, a recuperação do ASG, a convergência da saúde do ALB e o RTO da promoção do Aurora.

Por que esses serviços:

O roteamento baseado em latência e o roteamento ponderado (weighted) do Route 53 fornecem tanto a latência ideal para o usuário quanto a modelagem de tráfego controlada para a prontidão de DR.
O ALB em conjunto com o ASG, usando warm pools e lifecycle hooks, garante uma escalabilidade rápida e suave (graceful), sem penalidades de inicialização a frio (cold-start) ou interrupção para o usuário.
O Aurora Global Database atende de forma única aos requisitos de RPO próximo de zero e RTO inferior a um minuto entre Regiões, com mínimas alterações na aplicação.
O S3 Versioning e o CRR com RTC entregam uma replicação auditável e com suporte de SLA para artefatos críticos.
O AWS Backup com cofres (vaults) entre contas e o Vault Lock cria backups imutáveis e governados centralmente, alinhados às necessidades de conformidade.
O AWS FIS fornece injeção de falhas segura e automatizada para comprovar continuamente a postura de resiliência e evitar que o desvio de configuração (configuration drift) comprometa o plano de DR.

← Contêineres e Operações Serverless · Todos os domínios · Arquiteturas Orientadas a Eventos e Automação →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →