Amazon SAA-C03: Alta Disponibilidade, Tolerância a Falhas e Recuperação de Desastres — Guia de estudos

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Faz parte do AWS SAA-C03 — Guia de estudos completo. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Implantações Multi-AZ e Replicação

Arquiteturas Multi-AZ lidam com a falha de um único data center ou Zona de Disponibilidade — nada mais. Essa distinção é o ponto mais incompreendido no design de alta disponibilidade. Uma implantação Multi-AZ tolera a perda de uma AZ dentro de uma Região; ela não tolera uma interrupção em toda a Região, uma degradação de serviço regional ou a exclusão acidental de um recurso que replica imediatamente a exclusão para a instância de standby. A replicação propaga fielmente dados ruins — corrupção lógica, erros de schema, escritas de ransomware — e é por isso que replicação e backup são complementares, não substitutos.

Para o Amazon RDS, o Multi-AZ provisiona uma réplica de standby síncrona em uma AZ diferente. As escritas são confirmadas em ambas as instâncias antes da confirmação (acknowledgment), resultando em um RPO efetivamente zero e um RTO tipicamente de 60 a 120 segundos durante o failover automático. Na implantação clássica de instância Multi-AZ, a instância de standby não é legível — ela existe puramente para durabilidade e failover. Implantações de cluster Multi-AZ (duas instâncias de standby legíveis) reduzem ainda mais o tempo de failover e fornecem alguma escalabilidade de leitura, mas ainda se limitam a uma única Região.

Para escalabilidade de leitura, adicione read replicas. As read replicas usam replicação assíncrona e existem para descarregar consultas de relatórios, análises e dashboards. Tratar uma read replica como um mecanismo de failover de HA está errado por três motivos: a replicação é assíncrona (perda de dados na promoção), a promoção é manual ou via script (não automática) e o endpoint principal não é preservado. Quando uma carga de trabalho crescente precisa de mais capacidade de leitura sem nova complexidade, adicione uma read replica; quando o requisito é failover automático com perda zero de dados, use Multi-AZ. Quando o RPO/RTO deve sobreviver a uma falha de Região para um motor relacional, o Aurora Global Database fornece latência de replicação entre Regiões (cross-Region) abaixo de um segundo e um RTO de failover gerenciado abaixo de um minuto.

O Amazon ElastiCache segue o mesmo padrão com grupos de replicação. Um grupo de replicação do Redis com Multi-AZ ativado mantém uma instância primária e uma ou mais réplicas entre AZs; se a primária falhar, o ElastiCache promove uma réplica e atualiza o endpoint primário. Para escalabilidade horizontal, o Redis (com modo cluster ativado) particiona os dados em shards, sendo cada shard seu próprio grupo de replicação. O Memcached, por outro lado, não replica — a perda de um nó significa a perda de dados para aquela partição.

O Amazon FSx oferece tipos de implantação Multi-AZ para o FSx for Windows File Server e o FSx for ONTAP, usando replicação síncrona entre um servidor de arquivos preferencial e um de standby. O FSx for Lustre é geralmente single-AZ (scratch ou persistente); a durabilidade para o Lustre vem de associações com repositórios de dados no S3, não da replicação entre AZs.

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

Backups Automatizados do RDS e Recuperação para um Ponto no Tempo (Point-in-Time Recovery)

Os backups automatizados do RDS combinam um snapshot diário com uploads contínuos de logs de transação a cada 5 minutos para o S3, permitindo a recuperação para um ponto no tempo (PITR) para qualquer segundo dentro da janela de retenção de 1 a 35 dias. Se o seu RPO é de 2 horas, os backups nativos do RDS já o atendem — não é necessário agendar snapshots extras, e adicionar o AWS Backup por cima é redundante, a menos que você precise de cópias entre Regiões (cross-Region), isolamento entre contas (cross-account) ou da semântica do Vault Lock além do que a cópia de snapshot do RDS oferece. O backup automatizado padrão é frequentemente a resposta correta mais barata para requisitos de RPO modestos.

AWS Backup como o Plano de Controle Centralizado

O AWS Backup é o plano de controle orientado por políticas para backup em EBS, EC2 (como AMIs), RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway, S3 e mais. Em vez de criar scripts com lógicas de snapshot específicas para cada serviço, você define planos de backup que agrupam regras descrevendo frequência, janela de backup, janelas de início/conclusão, transições de ciclo de vida para armazenamento frio (cold storage), retenção e cofres de destino (destination vaults). Os recursos são incluídos por meio de atribuições de recursos por tag ou ARN, de modo que uma convenção de tags como Backup=Daily se torna o contrato operacional que rege a cobertura. Para frotas de centenas de instâncias EC2, a seleção baseada em tags é a abordagem de menor esforço — aplique a tag e deixe o AWS Backup enumerar os recursos, em vez de criar agendamentos por instância.

Um cofre de backup (backup vault) é o contêiner criptografado com KMS onde os pontos de recuperação residem. O acesso é controlado por políticas de recursos no cofre.

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

Cópias entre Regiões (Cross-Region) e entre Contas (Cross-Account)

O bloco CopyActions é o mecanismo para cópias de DR entre Regiões (cross-Region). O AWS Backup gerencia a cópia do snapshot, recriptografa com uma chave KMS da Região de destino (o cofre de destino deve referenciar uma chave naquela Região) e aplica um ciclo de vida independente. Os snapshots do EBS e do RDS, por padrão, ficam na Região de origem — se toda a Região for afetada, os snapshots também serão. Qualquer requisito regulatório ou de negócio que mencione resiliência regional deve incluir uma etapa explícita de cópia entre Regiões, seja por meio de ações de cópia do AWS Backup, cópia entre Regiões de snapshots automatizados do RDS ou políticas de DLM com destinos entre Regiões.

Para cópias entre contas (cross-account), o AWS Organizations delega uma conta de administrador para o AWS Backup; a política do cofre de origem permite a conta de destino, e o cofre de destino permite cópias da origem. Esta é a maneira de melhor custo-benefício para centralizar o DR: uma conta de gerenciamento armazena os pontos de recuperação de muitas contas de carga de trabalho e pode restaurar em qualquer uma das Regiões. Para o EC2, uma cópia da AMI para uma segunda Região mais o compartilhamento de snapshots permite que você inicie instâncias lá sem uma infraestrutura “warm” (pré-aquecida). Snapshots criptografados exigem o compartilhamento da CMK — a conta ou Região de destino precisa da permissão kms:CreateGrant e de acesso à chave. A falta disso é o motivo pelo qual as restaurações entre contas falham silenciosamente.

Um RPO de 24 horas é atendido de forma barata por um snapshot diário automatizado copiado para outra Região — muito menos custoso do que uma read replica entre Regiões ou um cluster de standby “warm”. Aumente para replicação contínua somente quando o RPO cair abaixo do que a cadência de snapshots pode entregar.

Ciclo de Vida da AMI e Backups do EC2

Dois mecanismos automatizam os backups do EC2: Data Lifecycle Manager (DLM) e AWS Backup. O DLM é anterior ao AWS Backup e cria snapshots de EBS ou AMIs orientados por políticas, de forma agendada, com ações de cópia entre Regiões e entre contas. O AWS Backup engloba essa funcionalidade e adiciona política centralizada, Vault Lock e escopo multisserviço. Prefira o AWS Backup quando você já o utiliza para outros serviços; use o DLM para cenários puramente de EBS/AMI onde você não precisa dos recursos de cofre (vault).

Para camadas web stateless por trás de um Auto Scaling group sem dados locais persistentes, fazer backup de instâncias EC2 em execução é um desperdício. A postura correta é preparar uma AMI “hardened” (reforçada) (via EC2 Image Builder ou um pipeline de CI), referenciá-la no launch template e deixar o ASG cuidar da substituição das instâncias. O esforço de backup se concentra nas camadas stateful, cujos backups nativos automatizados atendem ao RPO.

Imutabilidade: Vault Lock e Object Lock

Um snapshot simples em sua conta pode ser excluído por qualquer pessoa com a permissão IAM correta — snapshots por si só não satisfazem os requisitos de imutabilidade. Regimes regulatórios (SEC 17a-4, FINRA, HIPAA, GDPR) frequentemente exigem retenção WORM (write-once-read-many) que nem mesmo os administradores podem contornar. Dois mecanismos da AWS oferecem isso.

O AWS Backup Vault Lock impõe o WORM em um cofre de backup (backup vault):

No modo de conformidade, uma vez que o período de reflexão termina, nenhum usuário — incluindo a conta root — pode encurtar a retenção, excluir pontos de recuperação antes do vencimento ou remover o próprio bloqueio. Isso impede tanto a exclusão por um agente interno quanto por um operador de ransomware que tenha comprometido totalmente a conta.

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

O S3 Object Lock fornece WORM no nível do objeto no modo Governança (usuários privilegiados com s3:BypassGovernanceRetention podem sobrepor) ou no modo Conformidade (ninguém, incluindo o root, pode excluir ou encurtar a retenção). O Legal Hold é independente dos períodos de retenção. O Object Lock requer o versionamento e deve ser habilitado na criação do bucket para proteção total.

Reservas de Capacidade para a Região de Failover

Um plano de DR que presume que a Região de failover terá capacidade de EC2 disponível no dia de um evento de grande escala não é um plano. Quando uma Região falha, todos fazem o failover simultaneamente, e os tipos de instância — especialmente os grandes, com GPU ou especializados — podem se esgotar. As On-Demand Capacity Reservations (ODCRs) na Região de destino garantem capacidade para um tipo de instância, plataforma e AZ específicos, e são cobradas sendo usadas ou não. Combine com um Savings Plan para compensar o custo. Para compromissos de longo prazo com GPU/ML, aplicam-se os Capacity Blocks; para flexibilidade de família, uma Capacity Reservation Fleet cobre múltiplas famílias de instâncias. O princípio é: se o negócio exige computação garantida na Região de DR, reserve-a — não confie na disponibilidade On-Demand de melhor esforço.

Seleção da Estratégia de DR

A AWS canoniza quatro níveis de DR, cada um com uma relação custo/recuperação distinta:

O nível correto é ditado pelo RPO e RTO do negócio — não pela preferência de arquitetura. Um RPO de 24 horas tolera cópias diárias de snapshots entre Regiões (Backup e Restauração). Um RPO de segundos exige replicação contínua — réplicas de leitura entre Regiões, Aurora Global Database, DynamoDB Global Tables ou S3 Cross-Region Replication. Tentar um RPO de 5 minutos com snapshots noturnos é arquitetonicamente impossível, independentemente do orçamento. Por outro lado, usar ativo-ativo como padrão para toda carga de trabalho é um antipadrão de custo: exige dados globalmente consistentes (DynamoDB Global Tables ou Aurora Global com write-forwarding), computação duplicada em escala total e roteamento de tráfego complexo via Route 53 ou Global Accelerator. Escolha o padrão mais barato que atenda ao RPO/RTO declarado — para um RPO de 2 horas, backup e restauração ou pilot light geralmente são suficientes, e warm standby é excesso de engenharia.

Proteção contra Exclusão e Barreiras de Proteção em Camadas

Resiliência não é apenas “temos backups?” — é “um único ator, erro ou ataque pode apagá-los?”. Controles em camadas evitam a catástrofe de “um clique errado”:

• RDS: habilite DeletionProtection e exija um snapshot final na exclusão.
• EC2: habilite DisableApiTermination e DisableApiStop em instâncias críticas.
• DynamoDB: habilite a proteção contra exclusão e o point-in-time recovery.
• S3: Versionamento + MFA Delete + Object Lock para imutabilidade.
• CloudFormation: DeletionPolicy: Retain em recursos stateful e proteção contra terminação de stack.
• SCPs do IAM: negue backup:DeleteRecoveryPoint, backup:DeleteBackupVault, rds:DeleteDBInstance e ec2:DeleteSnapshot fora de perfis “break-glass” (de emergência).

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

Combinados com o Vault Lock no modo de conformidade, estes produzem uma defesa em profundidade: mesmo uma credencial de administrador comprometida não pode destruir os pontos de recuperação de última linha de defesa.

Armadilhas Comuns

Tratar Multi-AZ como DR. RDS Multi-AZ, ElastiCache Multi-AZ e FSx Multi-AZ residem todos em uma única Região. Uma interrupção da API Regional, uma exclusão acidental de tabela ou uma migração de schema aplicada incorretamente afeta ambos os nós. Qualquer requisito que mencione “outra Região”, “falha regional” ou “RPO entre Regiões” exige replicação ou cópia entre Regiões — o Multi-AZ por si só não atende ao requisito.

Confundir read replicas com HA. As read replicas são assíncronas, promovidas manualmente e mudam de endpoint. Elas resolvem o escalonamento de leitura, não o failover automático.

Presumir que snapshots equivalem a conformidade. Snapshots sem o Vault Lock (modo de conformidade) ou o Object Lock podem ser excluídos por qualquer principal com a permissão IAM correta e pela conta root. A retenção regulatória WORM exige uma configuração explícita de imutabilidade com um período de cooling-off travado e já decorrido.

Snapshots apenas locais para um RPO Regional. Os snapshots do EBS e do RDS, por padrão, ficam na Região de origem. A resiliência regional exige uma ação explícita de cópia entre Regiões.

Backups sem restaurações testadas ou capacidade reservada. Um snapshot que você nunca restaurou é uma hipótese, não um backup. Exercícios de restauração revelam papéis (roles) IAM ausentes, problemas de acesso a chaves KMS na Região e conta de destino e tipos de instância indisponíveis. Sem Capacity Reservations para cargas de trabalho críticas, a Região de DR pode simplesmente não ter a configuração que você precisa quando todos fazem failover simultaneamente — e o RTO se torna ilimitado.

Excesso de engenharia para uma arquitetura ativo-ativo. Computação global duplicada, replicação de dados globalmente consistente e direcionamento de tráfego complexo são caros. Se o RPO/RTO não justificar o custo, uma arquitetura pilot light ou warm standby é a abordagem correta.

Fazer backup de camadas stateless. Fazer snapshot de servidores web efêmeros atrás de um ASG desperdiça dinheiro e complica a recuperação. Crie AMIs, referencie-as em launch templates e concentre o investimento de backup nos dados stateful.

← Gerenciamento · Todos os domínios

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

Navegar Amazon →