Automatize o Ciclo de Vida Completo do Agente AWS DRS Instalar, Curar e Desligar com SSM

Por que gerenciar o agente DRS manualmente quebra em escala

Olha só isso: se você protege centenas de instâncias EC2 com AWS Elastic Disaster Recovery (DRS), gerenciar o agente de replicação na mão é uma batalha perdida. Agentes travam após mudanças de rede, servidores removidos do escopo continuam replicando e gerando custo, e problemas entre drills passam despercebidos até ser tarde demais.

Este tutorial mostra uma automação testada em produção que cobre o ciclo de vida completo do agente—instalar, curar e desligar—usando documentos AWS Systems Manager (SSM) Automation acionados por EventBridge ou agendamento. Sem funções Lambda para manter. Uma única tag EC2 controla tudo.

A lógica vive em três documentos SSM Automation, e todo o fluxo está no repositório GitHub aws-samples/sample-drs-agent-lifecycle-automation. Para uma visão mais profunda de como a AWS projeta arquiteturas resilientes em escala, confira este insight sobre a arquitetura de storage da Meta.

Implementação: Três documentos, uma tag

A automação usa uma única chave de tag EC2 (padrão: DR) com três valores:

Onboarding: instalação idempotente

O State Manager roda o documento DRS-Agent-Onboard a cada 30 minutos contra instâncias tag:DR=yes. É idempotente—instâncias saudáveis são puladas.

# state-manager-association.yaml (trecho)
MaxConcurrency: 10
MaxErrors: 100%  # uma falha não para a frota inteira

Um lock de concorrência (flock no Linux, mutex nomeado no Windows) evita race conditions quando execuções se sobrepõem. A tag de failback AWSDRS:AllowLaunchingIntoThisInstance só é aplicada quando o agente está confirmado presente.

Healing: recuperação de stall orientada a eventos

Quando o DRS detecta uma replicação travada, emite um evento na região de DR. Uma regra de forwarding do EventBridge filtra pelo estado STALLED e envia cross-Region para a região de origem:

{
  "source": ["aws.drs"],
  "detail-type": ["DRS Source Server Replication Status Changed"],
  "detail": {
    "state": ["STALLED"]
  }
}

O documento de heal reinicia o serviço do agente primeiro (a maioria dos stalls é transitória). Se o restart falhar, re-executa o instalador in-place, preservando o estado do driver para evitar rescan completo do disco. Stalls que não são do agente (throttling de banda, problemas de disco de staging) escalam para operadores via SNS.

Offboarding: status de billing honesto

Quando você seta DR=no ou deleta a tag, o EventBridge dispara um evento Tag Change on Resource. O documento de offboarding aplica safeguards:

1. Guard de instância terminada — terminação EC2 remove tags; não delete o recovery point.
2. Re-check da tag — se a tag foi restaurada, sai.
3. Gate de aprovação — se AutoOffboardEnabled=false, notifica e para.
4. Registro de estado — captura estado de replicação, lag, último snapshot.
5. Check de recovery-instance — sinaliza instâncias de recovery ativas (billing EC2 separado).

Após o teardown, o outcome reflete o que realmente funcionou:

Comandos de tagging

# Proteger uma instância
aws ec2 create-tags --resources i-0123456789abcdef0 \
  --tags Key=DR,Value=yes --region us-west-1

# Remover do escopo (dispara offboarding)
aws ec2 create-tags --resources i-0123456789abcdef0 \
  --tags Key=DR,Value=no --region us-west-1

# Ou remover a tag completamente (também dispara offboarding)
aws ec2 delete-tags --resources i-0123456789abcdef0 \
  --tags Key=DR --region us-west-1

Guards de segurança e limitações

A automação inclui nove guards de segurança, mas você precisa entender os trade-offs:

• Latência de detecção de stall conta contra seu RPO. O RPO de 15 minutos é uma meta configurada pelo cliente, não uma garantia da AWS. A camada 2 (heal via EventBridge) depende do DRS detectar o stall primeiro—o lag precisa acumular antes do servidor ser marcado como stalled.
• Reinstall pode disparar rescan block-level cuja duração escala com o tamanho do disco. Em volumes grandes, isso pode exceder temporariamente a janela de RPO.
• A camada 3 (backstop do State Manager) roda a cada 30 minutos, o que excede um RPO de 15 minutos. É uma rede de segurança, não a defesa primária.
• Pause durante eventos de DR. Use a flag de stand-down para evitar que a automação aja durante failover/failback:

aws ssm put-parameter --name /drs/control/event-in-progress \
  --value true --overwrite --region us-west-1

• Cleanup não para a replicação. Remover a automação deixa instâncias DR=yes replicando. Você precisa parar a replicação pelo console DRS ou API.

Próximos passos

1. Clone o repo e faça deploy em modo audit (auto_install_enabled: false).
2. Tagueie algumas instâncias DR=yes e deixe o onboarding rodar por um dia.
3. Revise os relatórios de auditoria no S3—eles mostram o que seria instalado sem mudar nada.
4. Ligue a instalação, depois teste offboarding em uma instância.
5. Para tendências mais amplas de frontend, confira este guia do CSS border-shape.

Conclusão

Você agora tem uma automação completa e orientada a eventos para o ciclo de vida do agente AWS DRS: instalar, curar e desligar—tudo controlado por uma única tag EC2. A arquitetura usa documentos SSM Automation, forwarding cross-Region do EventBridge e relatório honesto de billing para você nunca ficar na dúvida se os custos de replicação realmente pararam.

Comece em modo audit, escale gradualmente, e use a flag de stand-down durante eventos de DR declarados. O código completo está no repositório aws-samples/sample-drs-agent-lifecycle-automation—abra uma issue se encontrar edge cases.

Fonte: AWS Architecture Blog