Recuperação de desastres

Pontos-chave

• RTO: o atraso máximo aceitável entre a interrupção e a volta do serviço. Quanto tempo podemos ficar fora.
• RPO: o tempo máximo aceitável desde o último ponto de recuperação dos dados. Quantos dados podemos perder.
• Custo: RPO e RTO menores custam mais em recursos e complexidade. Se a recuperação custa mais que a perda, não vale montá-la, a menos que a regulação exija.
• Replicação não é backup: a replicação contínua também copia corrupção e exclusões maliciosas, então mantenha backups pontuais.
• Multi-AZ primeiro: as AZs ficam distantes o bastante para que a maioria dos desastres atinja só uma, então um design Multi-AZ pode já cobrir boa parte do risco.

Pontos-chave

• Backup and restore: faça backup dos dados, das AMIs e da infraestrutura como código e reconstrua tudo na Região de recuperação depois do evento.
• Pilot light: os dados são replicados ao vivo e a infraestrutura central existe, mas os servidores de aplicação ficam desligados e são ligados e escalados no failover.
• Warm standby: uma cópia menor, porém completa, já consegue atender tráfego. O failover só precisa escalar.
• Multi-site active/active: todas as Regiões atendem tráfego. Hot standby é a variante ativo-passivo em escala total.
• Failover pelo data plane: faça o failover com operações de data plane, como health checks do Route 53 ou routing controls do ARC, e não com mudanças de control plane.

Pontos-chave

• Backup plans: agenda, retenção e transição para cold storage, aplicados aos recursos por tags.
• Cópia entre Regiões: regras de cópia mandam cada recovery point para um vault na Região de DR, por agenda ou sob demanda.
• Cópia entre contas: cópias para vaults de outras contas da mesma organização no AWS Organizations protegem contra uma conta comprometida. A restauração ocorre depois da cópia para a conta de destino.
• Vault Lock: proteção WORM. O modo governance pode ser removido com permissões IAM. O modo compliance fica imutável depois de um período de carência de pelo menos 72 horas, até para o usuário root e para a AWS.
• Audit Manager: controles prontos e relatórios diários mostram se os backups seguem a política.

Pontos-chave

• Metas: RPO de segundos e RTO de minutos.
• Área de staging: os dados chegam a uma sub-rede de staging com armazenamento barato e computação mínima. Instâncias em capacidade total só sobem para testes ou recuperação.
• Ponto no tempo: recupere o estado mais recente ou um ponto anterior, por exemplo de antes de um ransomware.
• Failback: depois de corrigir o site principal, replique de volta e faça o failback quando quiser.
• Escopo: aplicações e bancos que rodam em servidores, não serviços gerenciados como o RDS. Segue o padrão pilot light.

Pontos-chave

• Requisitos: versionamento na origem e no destino e uma role IAM que permita ao S3 replicar. Object Lock na origem exige Object Lock no destino.
• Só objetos novos: a replicação ao vivo copia o que for gravado depois da regra. Use S3 Batch Replication para objetos existentes, falhas e réplicas de réplicas.
• Exclusões: delete markers não são replicados por padrão nas regras atuais, e apagar uma versão específica nunca é replicado, o que protege a cópia contra exclusões maliciosas.
• S3 Replication Time Control: replica a maioria dos objetos em segundos com SLA de 15 minutos, mais métricas e eventos para objetos atrasados.
• CRR vs SRR: CRR para distância exigida por compliance, menor latência e DR. SRR para juntar logs, copiar de produção para teste e soberania de dados dentro de uma Região.

Pontos-chave

• Aurora Global Database: 1 Região primária e até 10 Regiões secundárias somente leitura, replicação no nível do storage normalmente abaixo de 1 segundo. Uma secundária assume as escritas em menos de 1 minuto.
• Switchover vs failover: o switchover move a primária sem perda de dados em operações planejadas. O failover recupera de uma queda da Região primária.
• Write forwarding: clusters Aurora secundários podem encaminhar comandos de escrita para o primário.
• DynamoDB global tables: multiativo, toda réplica aceita leitura e escrita. A consistência eventual entre Regiões (padrão) resolve conflitos pela última escrita, e a consistência forte entre Regiões é o outro modo. SLA de 99,999% de disponibilidade.
• Réplicas de leitura do RDS entre Regiões: assíncronas, promovidas manualmente no DR, o que leva alguns minutos e inclui um reboot.

Pontos-chave

• Incremental: só os blocos alterados são salvos. A AWS não faz backup dos volumes sozinha, então agende os snapshots.
• Cópia entre Regiões: copie snapshots concluídos e AMIs para a Região de DR. A primeira cópia para uma Região é completa, as seguintes podem ser incrementais.
• Data Lifecycle Manager: automatiza criação, retenção e exclusão de snapshots e AMIs com EBS, inclusive cópias para outras Regiões ou contas, sem custo adicional.
• Fast snapshot restore: volumes criados a partir do snapshot já nascem totalmente inicializados, sem latência na primeira leitura. Cobrado por snapshot, por AZ, por hora.
• Recycle Bin: recupera snapshots, volumes e AMIs com EBS apagados por engano antes do fim do período de retenção.

Pontos-chave

• Roteamento failover do Route 53: health checks trocam as respostas DNS para a Região de DR automaticamente, uma operação de data plane.
• Routing controls do ARC: chaves liga/desliga apoiadas em health checks do Route 53 para um failover iniciado manualmente e roteirizado.
• Global Accelerator: IPs anycast estáticos na frente de endpoints em várias Regiões. Health checks redirecionam o tráfego sem o atraso do cache de DNS.
• Service quotas na Região standby: aumente com antecedência para que o pilot light ou o warm standby escale até o tamanho de produção.
• Infraestrutura como código: CloudFormation (StackSets entre contas e Regiões) e golden AMIs copiadas para as duas Regiões reconstroem o ambiente de forma consistente. Teste o plano com frequência.