Amazon SOA-C02: Alta Disponibilidade, Tolerância a Falhas e Recuperação de Desastres — Guia de estudos
Faz parte do AWS SysOps Administrator Associate SOA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.
Este domínio abrange o projeto de sistemas que permanecem disponíveis e recuperáveis quando componentes, serviços ou regiões inteiras falham. Ele engloba estratégias de backup e snapshot, padrões de replicação e failover, e os testes operacionais necessários para atingir as metas de negócio de RTO (Recovery Time Objective) e RPO (Recovery Point Objective). A importância operacional é alta: interrupções e perda de dados impactam diretamente SLAs, receita e conformidade. Projetos eficazes equilibram custo, complexidade e o risco aceitável de perda de dados e tempo de inatividade (downtime).
Estratégias de backup, snapshots e retenção
Os backups devem ser automatizados, consistentes com o estado da aplicação e retidos de acordo com a política. Use o AWS Backup para centralizar planos, retenção e regras de ciclo de vida (lifecycle) (crie um plano de backup com um cofre (vault), atribua ARNs de ID de recurso ou tags). Para volumes EBS, use o Data Lifecycle Manager (DLM) para agendar snapshots (pelo console ou com
undefined
); exemplo de criação de snapshot via CLI:
undefined
. Para o RDS, use snapshots automatizados ou snapshots manuais de banco de dados (DB) (
undefined
). Habilite os backups automatizados do RDS para recuperação point-in-time; habilite o monitoramento aprimorado (enhanced monitoring) e a retenção de snapshots para atender aos SLAs de retenção.
Retenção, imutabilidade e cópias entre regiões são decisões críticas:
- RPO/RTO curtos exigem snapshots frequentes e janelas de exclusão de retenção baixas; isso aumenta o custo.
- Para imutabilidade regulatória, use o AWS Backup Vault Lock ou o S3 Object Lock para retenção legal (legal hold).
- Para durabilidade entre regiões (cross-region), copie snapshots (
undefined
) e habilite o versionamento do S3 antes da replicação entre regiões.
Sempre capture o estado consistente da aplicação: para o EC2, use o AWS Systems Manager Run Command ou scripts para descarregar/bloquear (flush/lock) os sistemas de arquivos antes de criar snapshots; para bancos de dados, prefira snapshots nativos da engine (RDS/Aurora) ou backups lógicos (mysqldump, pg_dump) para validação point-in-time.
Replicação entre regiões e padrões de recuperação de desastres
Estratégias entre regiões (cross-region) reduzem o raio de impacto (blast radius) de uma falha regional. A replicação entre regiões do S3 (Cross-Region Replication - CRR) requer versionamento, uma função (role) de replicação do IAM e uma configuração de replicação (pelo console ou com
undefined
). O RDS suporta réplicas de leitura (read replicas) entre regiões (
undefined
) e o Aurora Global Database para arquiteturas de leitura/escrita entre regiões de baixa latência com failover controlado. As DynamoDB Global Tables replicam dados de forma assíncrona entre regiões e são adequadas para leituras multirregionais com considerações de consistência eventual.
Escolha um padrão de DR com base no RTO/RPO e no custo:
- Pilot Light: replicar dados críticos para uma região secundária (S3, snapshots, réplicas de DB), mas com infraestrutura mínima em execução; escalonamento rápido por meio de templates de IaC.
- Warm Standby: uma pegada (footprint) ativa menor na região secundária com dados replicados continuamente e serviços em escala reduzida que podem ser aumentados automaticamente.
- Multi-Region Active-Active: executar stacks completos em várias regiões com roteamento de tráfego e resolução de conflitos; requer replicação global (DynamoDB global tables, Aurora Global DB, tratamento de conflitos a nível de aplicação).
Considere a consistência da replicação: a replicação síncrona minimiza o RPO, mas aumenta a latência e pode não ser suportada entre regiões; a maioria das opções entre regiões é assíncrona e introduz um atraso (lag) de replicação que define o RPO realista.
Escolhas de arquitetura Multi-AZ e Multi-Region
Multi-AZ é o padrão para alta disponibilidade dentro de uma região; fornece failover automático para muitos serviços gerenciados com RTO mínimo. O RDS Multi-AZ e o Aurora replicam o armazenamento entre AZs — o failover é tipicamente automático e usa uma troca de DNS (DNS switch-over). Para o EC2, posicione instâncias em múltiplas AZs atrás de um Application Load Balancer e grupos de Auto Scaling; use verificações de saúde (health checks) entre AZs para detectar e substituir alvos (targets) não saudáveis.
Multi-Region adiciona resiliência contra falhas em toda a região, mas aumenta a complexidade (replicação de dados, roteamento global, conformidade). Critérios de decisão:
- Use Multi-AZ quando precisar de alta disponibilidade com baixa latência dentro de uma região e desejar failover automático gerenciado a um custo menor.
- Use Multi-Region para recuperação de desastres (disaster recovery) contra a perda de uma região ou para redução de latência em uma arquitetura global active-active.
Considerações de projeto:
- TTLs de DNS: TTLs baixos (ex: 60s) são necessários para um failover rápido baseado em DNS, mas aumentam a carga de consultas DNS.
- Localidade de dados e conformidade: alguns dados devem permanecer em uma região; arquitete a replicação e a criptografia de acordo.
- Custo vs RTO/RPO: Uma arquitetura Multi-Region active-active aumenta o custo, mas minimiza o RTO.
← Monitoramento · Todos os domínios · Implantação →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →