Disaster Recovery na AWS: estratégias e implementação

Disaster Recovery (DR) é o conjunto de políticas, ferramentas e procedimentos que permitem a recuperação de sistemas críticos de TI após um evento disruptivo, como falhas de hardware, ataques cibernéticos ou desastres naturais. Na AWS, as estratégias de DR variam desde backup simples até arquiteturas multi-region ativas/ativas, definidas pelos parâmetros RPO (quanto dado pode ser perdido) e RTO (quanto tempo o sistema pode ficar fora do ar).

Nenhuma empresa está imune a desastres. Falhas de hardware, erros humanos, ataques cibernéticos, desastres naturais ou até mesmo outages de provedores cloud podem tirar sistemas críticos do ar. A diferença entre uma empresa que sobrevive e uma que sofre perdas irreparáveis está no planejamento: um plano de Disaster Recovery (DR) bem estruturado garante que seus sistemas possam ser recuperados rapidamente com perda mínima de dados.

Neste guia, vamos explorar os conceitos fundamentais de DR, as quatro estratégias clássicas na AWS, do backup simples ao multi-site ativo/ativo, e implementações práticas com Terraform e serviços nativos da AWS.

RPO e RTO: os dois números mais importantes

Antes de escolher uma estratégia de DR, você precisa definir dois parâmetros fundamentais com o negócio:

• RPO (Recovery Point Objective): quanto de dados você pode perder? É o intervalo máximo aceitável entre o último backup/replicação e o momento do desastre. Ex: RPO de 1 hora significa que você aceita perder até 1 hora de dados.
• RTO (Recovery Time Objective): quanto tempo o sistema pode ficar fora do ar? É o tempo máximo aceitável para restaurar a operação. Ex: RTO de 30 minutos significa que o sistema deve estar funcional em até 30 minutos após o desastre.

A relação entre RPO/RTO e custo é inversamente proporcional: quanto menor o RPO e RTO desejados, maior o investimento necessário em infraestrutura de DR. A chave é encontrar o equilíbrio entre risco aceitável e custo justificável para cada workload.

As quatro estratégias de DR na AWS

1. Backup & Restore (RPO: horas | RTO: horas)

A estratégia mais simples e econômica. Consiste em manter backups regulares dos dados em outra região e, em caso de desastre, provisionar a infraestrutura do zero e restaurar os dados a partir dos backups.

• Custo: muito baixo (apenas armazenamento de backups)
• RPO: depende da frequência de backup (tipicamente 1-24h)
• RTO: horas (tempo para provisionar infra + restaurar dados)
• Ideal para: ambientes de desenvolvimento, sistemas não críticos

2. Pilot Light (RPO: minutos | RTO: minutos a horas)

Mantém os componentes core (banco de dados) replicados em tempo real na região de DR, mas a infraestrutura de compute (EC2, ECS, Lambda) permanece desligada ou mínima. Em caso de desastre, você "acende" a infraestrutura completa.

• Custo: baixo a moderado (replicação de banco + infra mínima)
• RPO: segundos a minutos (replicação contínua do banco)
• RTO: minutos a horas (tempo para escalar compute)
• Ideal para: aplicações de negócio com tolerância moderada a downtime

3. Warm Standby (RPO: segundos | RTO: minutos)

Uma versão reduzida do ambiente de produção roda continuamente na região de DR. O banco de dados é replicado em tempo real e o compute roda com capacidade mínima. Em caso de desastre, basta escalar o compute para capacidade total.

• Custo: moderado (infra reduzida + replicação contínua)
• RPO: segundos (replicação síncrona ou assíncrona)
• RTO: minutos (scaling de compute já provisionado)
• Ideal para: aplicações críticas de negócio com SLA de disponibilidade

4. Multi-Site Active/Active (RPO: zero | RTO: segundos)

O ambiente de produção roda simultaneamente em duas ou mais regiões, atendendo tráfego real em ambas. Se uma região falha, todo o tráfego é redirecionado para as regiões saudáveis automaticamente.

• Custo: alto (infraestrutura duplicada + replicação síncrona)
• RPO: zero (dados replicados em tempo real)
• RTO: segundos (failover automático via DNS)
• Ideal para: sistemas mission-critical, e-commerce, fintech

Implementação prática: S3 Cross-Region Replication

O S3 Cross-Region Replication (CRR) replica objetos automaticamente entre buckets em regiões diferentes. É a base de qualquer estratégia de DR para dados armazenados em S3:

# Bucket primário em São Paulo
resource "aws_s3_bucket" "primary" {
  provider = aws.sa_east_1
  bucket   = "rfx-app-data-primary"
}

resource "aws_s3_bucket_versioning" "primary" {
  provider = aws.sa_east_1
  bucket   = aws_s3_bucket.primary.id
  versioning_configuration {
    status = "Enabled"
  }
}

# Bucket de DR em Virginia
resource "aws_s3_bucket" "dr" {
  provider = aws.us_east_1
  bucket   = "rfx-app-data-dr"
}

resource "aws_s3_bucket_versioning" "dr" {
  provider = aws.us_east_1
  bucket   = aws_s3_bucket.dr.id
  versioning_configuration {
    status = "Enabled"
  }
}

# IAM Role para replicação
resource "aws_iam_role" "replication" {
  name = "s3-cross-region-replication"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "s3.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_role_policy" "replication" {
  name = "s3-replication-policy"
  role = aws_iam_role.replication.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "s3:GetReplicationConfiguration",
          "s3:ListBucket"
        ]
        Resource = aws_s3_bucket.primary.arn
      },
      {
        Effect = "Allow"
        Action = [
          "s3:GetObjectVersionForReplication",
          "s3:GetObjectVersionAcl",
          "s3:GetObjectVersionTagging"
        ]
        Resource = "${aws_s3_bucket.primary.arn}/*"
      },
      {
        Effect = "Allow"
        Action = [
          "s3:ReplicateObject",
          "s3:ReplicateDelete",
          "s3:ReplicateTags"
        ]
        Resource = "${aws_s3_bucket.dr.arn}/*"
      }
    ]
  })
}

# Configuração de replicação
resource "aws_s3_bucket_replication_configuration" "primary" {
  provider = aws.sa_east_1
  bucket   = aws_s3_bucket.primary.id
  role     = aws_iam_role.replication.arn

  rule {
    id     = "replicate-all"
    status = "Enabled"

    destination {
      bucket        = aws_s3_bucket.dr.arn
      storage_class = "STANDARD_IA"
    }
  }

  depends_on = [
    aws_s3_bucket_versioning.primary,
    aws_s3_bucket_versioning.dr
  ]
}

Route 53 Health Checks e Failover

O Amazon Route 53 é peça fundamental em qualquer estratégia de DR multi-region. Com health checks e failover routing, o Route 53 detecta automaticamente quando a região primária está indisponível e redireciona o tráfego para a região de DR:

# Health Check para o endpoint primário
resource "aws_route53_health_check" "primary" {
  fqdn              = "api-primary.rfxtech.com.br"
  port               = 443
  type               = "HTTPS"
  resource_path      = "/health"
  failure_threshold  = 3
  request_interval   = 10

  tags = {
    Name = "primary-health-check"
  }
}

# Record primário (failover primary)
resource "aws_route53_record" "primary" {
  zone_id         = var.hosted_zone_id
  name            = "api.rfxtech.com.br"
  type            = "A"
  set_identifier  = "primary"

  failover_routing_policy {
    type = "PRIMARY"
  }

  alias {
    name                   = var.alb_primary_dns
    zone_id                = var.alb_primary_zone_id
    evaluate_target_health = true
  }

  health_check_id = aws_route53_health_check.primary.id
}

# Record de DR (failover secondary)
resource "aws_route53_record" "dr" {
  zone_id         = var.hosted_zone_id
  name            = "api.rfxtech.com.br"
  type            = "A"
  set_identifier  = "secondary"

  failover_routing_policy {
    type = "SECONDARY"
  }

  alias {
    name                   = var.alb_dr_dns
    zone_id                = var.alb_dr_zone_id
    evaluate_target_health = true
  }
}

Com essa configuração, quando o health check do endpoint primário falha 3 vezes consecutivas (30 segundos), o Route 53 automaticamente redireciona todo o tráfego de api.rfxtech.com.br para o ALB na região de DR. O failback (retorno para a região primária) também é automático quando o health check volta a passar.

RDS Multi-Region: replicação de banco de dados

Para bancos de dados, a AWS oferece várias opções de replicação cross-region:

• RDS Read Replicas Cross-Region: replicação assíncrona com promoção manual ou automática. RPO de segundos.
• Aurora Global Database: replicação com latência abaixo de 1 segundo entre regiões. Failover automático em menos de 1 minuto. A melhor opção para bancos relacionais.
• DynamoDB Global Tables: replicação multi-region ativa/ativa nativa. Leituras e escritas em qualquer região com consistência eventual.
• ElastiCache Global Datastore: replicação cross-region para Redis com failover automático.

AWS Backup: centralização de backups

O AWS Backup é um serviço centralizado para gerenciar backups de múltiplos serviços AWS (RDS, DynamoDB, EBS, EFS, S3, EC2) com políticas unificadas. Ele permite criar backup plans com regras de retenção, frequência e cópia cross-region automática.

Principais recursos para DR:

• Cross-Region Copy: cópia automática de backups para a região de DR
• Cross-Account Copy: cópia para outra conta AWS (proteção contra comprometimento de conta)
• Vault Lock: WORM (Write Once Read Many) para proteção contra exclusão de backups
• Restore testing: validação automática de que backups são restauráveis

"Um plano de DR que nunca foi testado é apenas um documento. Realize testes de failover regularmente, pelo menos trimestralmente, para garantir que o plano funciona quando mais importa."

Checklist de Disaster Recovery

• RPO e RTO definidos para cada workload com aprovação do negócio
• Estratégia de DR escolhida e documentada (backup, pilot light, warm standby ou multi-site)
• Backups cross-region configurados e monitorados com AWS Backup
• Replicação de banco de dados cross-region ativa e testada
• Route 53 health checks e failover configurados
• IaC (Terraform) para provisionar infraestrutura de DR rapidamente
• Runbooks de DR documentados com passo a passo detalhado
• Testes de failover realizados trimestralmente
• Métricas e alarmes de monitoramento e observabilidade de DR ativos
• Comunicação de incidentes planejada (quem avisa quem, em quanto tempo)

Erros comuns em DR

1. Não testar o plano

O erro mais grave. Um plano de DR não testado pode falhar no momento mais crítico. Configure práticas de segurança e compliance para garantir que testes regulares sejam parte do processo. Testes revelam gaps de documentação, configurações desatualizadas e dependências não mapeadas.

2. Ignorar dependências externas

Seu sistema depende de APIs externas, serviços SaaS ou integrações que podem não estar disponíveis na região de DR. Mapeie todas as dependências e tenha planos de contingência para cada uma.

3. RPO/RTO irrealistas

Definir RPO zero e RTO de segundos para todos os workloads é financeiramente inviável. Classifique seus workloads por criticidade e defina RPO/RTO adequados para cada nível.

4. Esquecer do DNS TTL

Um TTL alto nos records DNS pode atrasar o failover. Configure TTL baixo (60s) para records de failover e verifique se clientes e CDNs respeitam o TTL configurado.

Comandos e configurações avançadas de DR

Abaixo estão comandos e snippets essenciais para implementar e validar sua estratégia de Disaster Recovery na AWS.

Configurar AWS Backup com vault cross-region

# Criar vault de backup na região principal
aws backup create-backup-vault \
  --backup-vault-name dr-vault-primary \
  --encryption-key-arn arn:aws:kms:sa-east-1:123456789012:key/abcd-1234 \
  --region sa-east-1

# Criar vault na região de DR
aws backup create-backup-vault \
  --backup-vault-name dr-vault-secondary \
  --encryption-key-arn arn:aws:kms:us-east-1:123456789012:key/efgh-5678 \
  --region us-east-1

# Configurar copy rule para replicação cross-region
aws backup create-backup-plan --backup-plan '{
  "BackupPlanName": "dr-plan-production",
  "Rules": [{
    "RuleName": "daily-backup-with-copy",
    "TargetBackupVaultName": "dr-vault-primary",
    "ScheduleExpression": "cron(0 3 * * ? *)",
    "Lifecycle": {"DeleteAfterDays": 35},
    "CopyActions": [{
      "DestinationBackupVaultArn": "arn:aws:backup:us-east-1:123456789012:backup-vault:dr-vault-secondary",
      "Lifecycle": {"DeleteAfterDays": 35}
    }]
  }]
}' --region sa-east-1

Route 53 health check e failover

# Criar health check para o endpoint primário
aws route53 create-health-check --caller-reference "primary-$(date +%s)" \
  --health-check-config '{
    "IPAddress": "203.0.113.10",
    "Port": 443,
    "Type": "HTTPS",
    "ResourcePath": "/health",
    "RequestInterval": 10,
    "FailureThreshold": 2,
    "EnableSNI": true
  }'

# Verificar status de todos os health checks
aws route53 list-health-checks --query 'HealthChecks[*].[Id,HealthCheckConfig.IPAddress,HealthCheckConfig.Type]' --output table

# Listar status de health check específico
aws route53 get-health-check-status --health-check-id "abc123-def456"

Terraform para Route 53 failover

resource "aws_route53_health_check" "primary" {
  fqdn              = "app.exemplo.com.br"
  port               = 443
  type               = "HTTPS"
  resource_path      = "/health"
  failure_threshold  = 2
  request_interval   = 10

  tags = {
    Name = "primary-health-check"
  }
}

resource "aws_route53_record" "primary" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "app.exemplo.com.br"
  type    = "A"

  alias {
    name                   = aws_lb.primary.dns_name
    zone_id                = aws_lb.primary.zone_id
    evaluate_target_health = true
  }

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier  = "primary"
  health_check_id = aws_route53_health_check.primary.id
}

resource "aws_route53_record" "secondary" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "app.exemplo.com.br"
  type    = "A"

  alias {
    name                   = aws_lb.secondary.dns_name
    zone_id                = aws_lb.secondary.zone_id
    evaluate_target_health = true
  }

  failover_routing_policy {
    type = "SECONDARY"
  }

  set_identifier = "secondary"
}

Aurora Global Database para failover de banco

# Verificar status do cluster Aurora Global
aws rds describe-global-clusters \
  --query 'GlobalClusters[*].[GlobalClusterIdentifier,Status,GlobalClusterMembers[*].[DBClusterArn,IsWriter]]' \
  --output table

# Failover manual do Aurora Global Database para a região de DR
aws rds failover-global-cluster \
  --global-cluster-identifier my-global-cluster \
  --target-db-cluster-identifier arn:aws:rds:us-east-1:123456789012:cluster:my-dr-cluster

# Verificar lag de replicação (deve ser inferior ao RPO)
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name AuroraGlobalDBReplicationLag \
  --dimensions Name=DBClusterIdentifier,Value=my-dr-cluster \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 300 --statistics Average \
  --region us-east-1

Gotchas e armadilhas comuns

• S3 Cross-Region Replication não replica objetos existentes: ao ativar CRR em um bucket já populado, os objetos anteriores precisam ser copiados manualmente com aws s3 sync. Apenas novos objetos são replicados automaticamente.
• Limites de serviço na região de DR: se você nunca usou a região de DR, seus service quotas estão no padrão (geralmente baixos). Solicite aumento de limites para EC2, EBS, RDS e ELB na região de DR antes de precisar deles.
• AMIs e snapshots não são cross-region por padrão: você precisa copiar AMIs e snapshots EBS explicitamente para a região de DR. Automatize com AWS Backup ou Lambda.
• Secrets e parâmetros do SSM são regionais: cada region tem seu próprio Secrets Manager e Parameter Store. Replique segredos e parâmetros para a região de DR e mantenha sincronizados.
• Custo de data transfer cross-region: replicação entre regiões gera custo de transferência (aprox. USD 0,02/GB entre sa-east-1 e us-east-1). Para volumes altos de dados, isso pode ser significativo.

Na Prática: e-commerce com DR ativo-passivo

Como a RFX Tecnologia pode ajudar

Na RFX Tecnologia, por meio da nossa consultoria em nuvem, projetamos e implementamos estratégias de Disaster Recovery sob medida para cada negócio. Desde a definição de RPO/RTO com stakeholders até a implementação completa com Terraform, testes de failover e documentação de runbooks.

Nosso DR Assessment avalia seu ambiente atual, identifica gaps de resiliência e entrega um plano de DR priorizado com estimativa de custos. Agende uma consultoria gratuita para proteger seu negócio contra o inesperado.