Lab 58 — DR multi-região: as quatro estratégias

# Rode isto contra uma copia de teste do ambiente, NUNCA contra producao viva.
# O numero que sair daqui e a linha de base contra a qual toda estrategia mais
# cara tem de justificar o custo extra.
INICIO=$(date +%s)

# 1. "Descobrir" a ultima copia cross-region (o primeiro passo do runbook real).
ULTIMA=$(aws backup list-recovery-points-by-backup-vault --region us-west-2 \
  --backup-vault-name cadencia-vault-dr \
  --query "sort_by(RecoveryPoints,&CreationDate)[-1].RecoveryPointArn" --output text)

# 2. Restaurar o cluster do zero, numa regiao sem NADA de pe.
aws backup start-restore-job --region us-west-2 \
  --recovery-point-arn "$ULTIMA" --iam-role-arn "$ROLE_RESTORE" \
  --resource-type Aurora
# ... aguarde o job terminar (aws backup describe-restore-job em loop) ...

# 3. So DEPOIS do banco restaurado comeca a construcao de rede e aplicacao —
#    exatamente como o runbook em prosa descreve.
terraform -chdir=infra-dr-minima apply -auto-approve
until curl -sf "https://dr.cadencia.example/health/ready"; do sleep 10; done

FIM=$(date +%s)
echo "RTO medido: $(( (FIM - INICIO) / 3600 )) horas"
# Na Cadencia: pouco mais de 5 horas — acima das "4h" do documento, porque o
# documento nunca contou o tempo de RECONSTRUIR rede e aplicacao do zero, so o
# tempo de restaurar o banco.

{
  "ensaio_id": "dr-2026-08-08-01",
  "estrategia": "warm-standby",
  "marco": "promocao_concluida",
  "instante_utc": "2026-08-08T14:32:11Z",
  "regiao_origem": "us-east-1",
  "regiao_destino": "us-west-2",
  "global_cluster_identifier": "cadencia-global",
  "operacao": "failover_gerenciado",
  "allow_data_loss": true,
  "atraso_replicacao_medido_ms": 2140,
  "rto_parcial_segundos": 187,
  "observacao": "atraso medido no ultimo ponto antes da promocao, via CloudWatch AuroraGlobalDBReplicationLag — numero de EXEMPLO desta conta, nao garantia da AWS"
}

# aurora-global.tf — um cluster global, um primario, um secundario
#
# Duas restricoes que a documentacao da AWS marca como restricao, nao como
# detalhe: (1) failover e switchover so funcionam entre clusters com a
# MESMA versao MAJOR e MINOR de engine — atualizar so o primario quebra
# essa garantia ate o secundario alcancar a mesma versao. (2) a aplicacao
# le a credencial do Secrets Manager por variavel injetada pelo pipeline
# nesta conta; o cluster SECUNDARIO nao tem master_username/master_password
# proprios antes da promocao — ele herda a identidade do primario.

resource "aws_rds_global_cluster" "cadencia" {
  global_cluster_identifier = "cadencia-global"
  engine                    = "aurora-postgresql"
  engine_version             = "16.4"
  database_name               = "cadencia"
  storage_encrypted            = true
}

# ── Regiao primaria (provider default, us-east-1) ────────────────────────────
resource "aws_rds_cluster" "primario" {
  cluster_identifier          = "cadencia-primario"
  engine                        = aws_rds_global_cluster.cadencia.engine
  engine_version                 = aws_rds_global_cluster.cadencia.engine_version
  global_cluster_identifier      = aws_rds_global_cluster.cadencia.id
  master_username                 = "cadencia_admin"
  master_password                  = random_password.mestre.result # entra no Secrets Manager UMA vez, no bootstrap
  db_subnet_group_name              = aws_db_subnet_group.primario.name
  vpc_security_group_ids             = [aws_security_group.banco.id]
  storage_encrypted                   = true
  kms_key_id                           = aws_kms_key.banco.arn
  deletion_protection                   = true
  skip_final_snapshot                    = false
  final_snapshot_identifier               = "cadencia-primario-final"

  serverlessv2_scaling_configuration {
    min_capacity = 1   # herdado do L15; ver justificativa la
    max_capacity = 16
  }
}

resource "aws_rds_cluster_instance" "primario" {
  cluster_identifier = aws_rds_cluster.primario.id
  instance_class       = "db.serverless"
  engine                 = aws_rds_global_cluster.cadencia.engine
  engine_version           = aws_rds_global_cluster.cadencia.engine_version
}

# ── Regiao secundaria (provider alias us-west-2) ──────────────────────────────
resource "aws_rds_cluster" "secundario" {
  provider                    = aws.regiao_dr
  cluster_identifier           = "cadencia-secundario"
  engine                         = aws_rds_global_cluster.cadencia.engine
  engine_version                   = aws_rds_global_cluster.cadencia.engine_version
  global_cluster_identifier        = aws_rds_global_cluster.cadencia.id
  db_subnet_group_name              = aws_db_subnet_group.secundario.name
  vpc_security_group_ids             = [aws_security_group.banco_dr.id]
  storage_encrypted                   = true
  kms_key_id                           = aws_kms_key.banco_dr.arn
  skip_final_snapshot                   = true # secundario nao carrega o dado "de origem"; o primario ja tem final_snapshot

  serverlessv2_scaling_configuration {
    min_capacity = 0.5 # minimo: so precisa aplicar a replicacao, nao servir leitura de producao
    max_capacity = 16  # mesmo teto do primario: no failover, ele PASSA A SER o primario
  }
}

resource "aws_rds_cluster_instance" "secundario" {
  provider            = aws.regiao_dr
  cluster_identifier = aws_rds_cluster.secundario.id
  instance_class       = "db.serverless"
  engine                 = aws_rds_global_cluster.cadencia.engine
  engine_version           = aws_rds_global_cluster.cadencia.engine_version
}

# O alarme que torna o RPO um numero medido, nao um numero do folheto.
# A metrica so existe na regiao SECUNDARIA — e de la que se mede o quanto
# ela esta atrasada em relacao ao primario. O nome da metrica muda por
# versao de engine (AuroraGlobalDBReplicationLag em versoes mais antigas,
# AuroraGlobalDBRPOLag nas mais novas); confirme qual existe no seu cluster
# antes de copiar este bloco.
resource "aws_cloudwatch_metric_alarm" "atraso_replica" {
  provider            = aws.regiao_dr
  alarm_name           = "cadencia-aurora-global-replication-lag"
  namespace             = "AWS/RDS"
  metric_name            = "AuroraGlobalDBReplicationLag"
  statistic                = "Maximum"
  period                     = 60
  evaluation_periods          = 3
  # 5000 ms = o RPO maximo aceito pela diretoria (5 min de PEDIDOS, nao de
  # replicacao — o alarme usa milissegundos porque a metrica e milissegundos;
  # a distancia entre os dois numeros e o motivo de este alarme existir).
  threshold                    = 5000
  comparison_operator           = "GreaterThanThreshold"
  treat_missing_data              = "breaching" # ausencia de dado de replica E uma falha aqui

  dimensions = {
    DBClusterIdentifier = aws_rds_cluster.secundario.cluster_identifier
  }

  alarm_actions = [aws_sns_topic.alertas_dr.arn]
}

# route53-failover.tf — o DNS decide sobre dado real, nao sobre opiniao
#
# O health check aponta para a rota de PRONTIDAO do ALB primario (a mesma
# distincao do L03: prontidao toca dependencia, vivacidade nao). Health
# check de failover que so verifica vivacidade aprova uma regiao que esta
# de pe e nao consegue atender ninguem.

resource "aws_route53_health_check" "primario" {
  fqdn                = aws_lb.primario.dns_name
  port                  = 443
  type                    = "HTTPS"
  resource_path             = "/health/ready"
  # A AWS so oferece dois valores para o intervalo entre checagens: 10 s
  # (mais caro) ou 30 s (padrao). Aqui 30 s foi escolhido porque a parcela
  # que domina o RTO deste modulo e escala_de_capacidade, nao deteccao.
  request_interval          = 30
  failure_threshold           = 3

  tags = { Nome = "cadencia-primario-us-east-1" }
}

resource "aws_route53_record" "primario" {
  zone_id = aws_route53_zone.cadencia.zone_id
  name     = "api.cadencia.example"
  type      = "A"

  set_identifier    = "primario"
  # TTL baixo de proposito: a documentacao da AWS recomenda reduzir o TTL
  # do registro de failover ANTES de um failover, justamente para acelerar
  # a parcela propagacao_de_dns da formula acima.
  ttl                = 30
  failover_routing_policy {
    type = "PRIMARY"
  }
  health_check_id = aws_route53_health_check.primario.id
  records           = [aws_lb.primario.dns_name]
}

resource "aws_route53_record" "secundario" {
  zone_id = aws_route53_zone.cadencia.zone_id
  name     = "api.cadencia.example"
  type      = "A"

  set_identifier    = "secundario"
  ttl                = 30
  failover_routing_policy {
    type = "SECONDARY"
  }
  # SEM health_check_id proprio aqui de proposito: o registro SECONDARY so e
  # devolvido quando o PRIMARY falha, e ele proprio nao precisa de outro
  # health check apontando para si mesmo para isso funcionar.
  records = [aws_lb.secundario.dns_name]
}

# warm-standby.tf — a segunda regiao ja de pe, em capacidade reduzida
#
# A imagem precisa existir nas DUAS regioes. Isto usa replicacao entre
# registros do ECR (configurada uma vez, no repositorio); sem ela, o
# `docker pull` da task em us-west-2 falha exatamente no momento em que
# ninguem tem tempo de descobrir por que.

resource "aws_ecr_replication_configuration" "cadencia" {
  replication_configuration {
    rule {
      destination {
        region      = "us-west-2"
        registry_id = data.aws_caller_identity.atual.account_id
      }
    }
  }
}

resource "aws_ecs_service" "api_dr" {
  provider            = aws.regiao_dr
  name                  = "cadencia-api-dr"
  cluster                 = aws_ecs_cluster.dr.id
  task_definition           = aws_ecs_task_definition.api_dr.arn
  launch_type                = "FARGATE"

  # Capacidade QUENTE: pequena, mas rodando o tempo todo. E a diferenca
  # estrutural em relacao a pilot light, onde este numero seria 0.
  desired_count = 1

  deployment_minimum_healthy_percent = 100
  deployment_maximum_percent          = 200

  network_configuration {
    subnets          = aws_subnet.privada_dr[*].id
    security_groups   = [aws_security_group.task_dr.id]
    assign_public_ip    = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.api_dr.arn
    container_name     = "api"
    container_port       = 8080
  }
}

# O que permite crescer RAPIDO quando o trafego real chegar apos o failover
# — sem este recurso, "escalar" significa alguem mudando desired_count a mao.
resource "aws_appautoscaling_target" "api_dr" {
  provider              = aws.regiao_dr
  max_capacity            = 12 # mesmo teto de producao herdado do L06
  min_capacity              = 1
  resource_id                 = "service/${aws_ecs_cluster.dr.name}/${aws_ecs_service.api_dr.name}"
  scalable_dimension           = "ecs:service:DesiredCount"
  service_namespace              = "ecs"
}

resource "aws_appautoscaling_policy" "api_dr_cpu" {
  provider          = aws.regiao_dr
  name                = "cadencia-api-dr-cpu"
  policy_type           = "TargetTrackingScaling"
  resource_id              = aws_appautoscaling_target.api_dr.resource_id
  scalable_dimension         = aws_appautoscaling_target.api_dr.scalable_dimension
  service_namespace             = aws_appautoscaling_target.api_dr.service_namespace

  target_tracking_scaling_policy_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageCPUUtilization"
    }
    target_value       = 60
    scale_in_cooldown    = 300
    scale_out_cooldown     = 60 # assimetrico de proposito: subir rapido apos um failover, descer com calma
  }
}

# backup-crossregion.tf — protecao contra corrupcao, independente da regiao
#
# Isto continua existindo mesmo com Aurora Global no ar. A replica propaga
# um DELETE sem WHERE para us-west-2 em poucos segundos — o mesmo incidente
# do L10, so que agora replicado. Quem protege contra ISSO e o PITR, nao a
# replica.

resource "aws_backup_vault" "primario" {
  name         = "cadencia-vault-primario"
  kms_key_arn = aws_kms_key.backup.arn
}

resource "aws_backup_vault" "dr" {
  provider     = aws.regiao_dr
  name         = "cadencia-vault-dr"
  kms_key_arn = aws_kms_key.backup_dr.arn
}

resource "aws_backup_plan" "cadencia" {
  name = "cadencia-pitr-cross-region"

  rule {
    rule_name         = "diario-com-copia-cross-region"
    target_vault_name = aws_backup_vault.primario.name
    schedule            = "cron(0 3 * * ? *)"

    copy_action {
      destination_vault_arn = aws_backup_vault.dr.arn
      lifecycle {
        delete_after = 35
      }
    }

    lifecycle {
      delete_after = 35
    }
  }
}

resource "aws_backup_selection" "cadencia" {
  iam_role_arn = aws_iam_role.backup.arn
  name          = "cadencia-cluster-global"
  plan_id        = aws_backup_plan.cadencia.id

  resources = [aws_rds_cluster.primario.arn]
}

// FailoverRegional/Program.cs — promove o secundario, e grava um marco por
// etapa, no mesmo espirito do roteiro cronometrado do L10.
//
// Fica de fora de proposito: chamar isto sozinho nao e "o failover" — e so a
// parcela `promocao_do_dado` da formula. Escala de capacidade (o
// Auto Scaling do ECS) e troca de DNS (o health check do Route 53) correm
// em paralelo, cada um pelo seu proprio mecanismo.

using System.Text.Json;
using Amazon.RDS;
using Amazon.RDS.Model;

var globalClusterId = args.ElementAtOrDefault(0)
    ?? throw new ArgumentException("uso: FailoverRegional <global-cluster-identifier> <cluster-arn-destino>");
var clusterArnDestino = args.ElementAtOrDefault(1)
    ?? throw new ArgumentException("informe o ARN do cluster que sera promovido");

using var rds = new AmazonRDSClient(Amazon.RegionEndpoint.USEast1); // a chamada de failover roda a partir da regiao PRIMARIA

var marcos = new List<object>();
void Marco(string nome, object? extra = null) =>
    marcos.Add(new { nome, instante = DateTimeOffset.UtcNow.ToString("O"), extra });

Marco("failover_solicitado", new { globalClusterId, clusterArnDestino });

// FailoverGlobalCluster e o FAILOVER GERENCIADO: usado quando a regiao
// primaria esta INDISPONIVEL. Para uma troca planejada com as duas regioes
// saudaveis, o metodo correto e SwitchoverGlobalCluster (RPO zero) — sao
// operacoes DIFERENTES, e usar failover para uma troca planejada descarta
// dado sem necessidade nenhuma.
//
// AllowDataLoss=true e a contrapartida programatica da flag --allow-data-loss
// da CLI: e a confirmacao explicita de que voce aceita perder as transacoes
// que ainda nao tinham replicado no instante da promocao. (Confira o nome
// exato da propriedade na versao do AWS SDK for .NET que voce usa — nao foi
// possivel confirmar a assinatura exata do SDK na documentacao consultada
// para este modulo, so o comportamento equivalente na CLI/API.)
var resposta = await rds.FailoverGlobalClusterAsync(new FailoverGlobalClusterRequest
{
    GlobalClusterIdentifier = globalClusterId,
    TargetDbClusterIdentifier = clusterArnDestino,
    AllowDataLoss = true,
});
Marco("failover_aceito", new { status = resposta.GlobalCluster.Status });

// A API aceita o pedido e devolve antes de a promocao terminar. O RTO real
// so para de contar quando o cluster novo aceita ESCRITA — por isso o laco
// abaixo consulta o estado, em vez de confiar na resposta imediata.
while (true)
{
    await Task.Delay(TimeSpan.FromSeconds(5));
    var descricao = await rds.DescribeGlobalClustersAsync(new DescribeGlobalClustersRequest
    {
        GlobalClusterIdentifier = globalClusterId,
    });
    var estado = descricao.GlobalClusters.Single().Status;
    Marco("polling", new { estado });
    if (estado == "available")
    {
        Marco("failover_concluido");
        break;
    }
}

var caminho = $"marcos-failover-{DateTimeOffset.UtcNow:yyyyMMdd-HHmmss}.json";
await File.WriteAllTextAsync(caminho, JsonSerializer.Serialize(marcos, new JsonSerializerOptions { WriteIndented = true }));
Console.WriteLine($"marcos gravados em {caminho}");

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PromoverClusterGlobal",
      "Effect": "Allow",
      "Action": [
        "rds:FailoverGlobalCluster",
        "rds:SwitchoverGlobalCluster",
        "rds:DescribeGlobalClusters"
      ],
      "Resource": "arn:aws:rds::111122223333:global-cluster:cadencia-global"
    },
    {
      "Sid": "LerAtrasoDeReplicacao",
      "Effect": "Allow",
      "Action": ["cloudwatch:GetMetricData", "cloudwatch:GetMetricStatistics"],
      "Resource": "*"
    }
  ]
}

#!/usr/bin/env bash
# implantar-dr.sh — sobe as duas regioes; a ordem importa
set -euo pipefail

PROJETO="${PROJETO:?defina PROJETO}"
REGIAO_PRIMARIA="us-east-1"
REGIAO_DR="us-west-2"

echo "== 1/3: cluster global e as duas regioes de banco =="
terraform apply -target=aws_rds_global_cluster.cadencia \
                 -target=aws_rds_cluster.primario -target=aws_rds_cluster_instance.primario \
                 -auto-approve
# o secundario so pode ser criado DEPOIS de o primario existir — e por isso
# que este script nao aplica tudo de uma vez.
terraform apply -target=aws_rds_cluster.secundario -target=aws_rds_cluster_instance.secundario \
                 -auto-approve

echo "== 2/3: capacidade quente em us-west-2 =="
terraform apply -target=aws_ecs_service.api_dr -target=aws_appautoscaling_target.api_dr \
                 -target=aws_appautoscaling_policy.api_dr_cpu -auto-approve

echo "== 3/3: DNS de failover e backup cross-region =="
terraform apply -target=aws_route53_health_check.primario -target=aws_route53_record.primario \
                 -target=aws_route53_record.secundario -target=aws_backup_plan.cadencia -auto-approve

echo "no ar: ${REGIAO_PRIMARIA} ativa, ${REGIAO_DR} quente"

# provas-dr.sh — cinco medicoes; nenhuma conclusao vem de "o console mostrou verde"

PROJETO=cadencia; PRIMARIA=us-east-1; DR=us-west-2

# ── Prova 1: o RPO real da MINIMA (backup/restore), medido de verdade ────────
# Distancia entre o instante do desastre simulado e a copia cross-region mais
# recente do AWS Backup. Esperado: proximo de 24h no pior caso, contra a 1h
# que o runbook antigo promete.
ULTIMA_COPIA=$(aws backup list-recovery-points-by-backup-vault --region "$DR" \
  --backup-vault-name "${PROJETO}-vault-dr" \
  --query 'sort_by(RecoveryPoints,&CreationDate)[-1].CreationDate' --output text)
echo "ultima copia cross-region: ${ULTIMA_COPIA}"

# ── Prova 2: o RTO real da MINIMA, cronometrado ponta a ponta ────────────────
# Cronometra do 'terraform apply' na regiao vazia ate o primeiro 200 na nova
# URL. E o numero que confronta o "RTO: 4h" do documento.
INICIO=$(date +%s)
terraform -chdir=infra-dr-minima apply -auto-approve
until curl -sf "https://dr.${PROJETO}.example/health/ready"; do sleep 5; done
FIM=$(date +%s)
echo "RTO medido da minima: $(( (FIM - INICIO) / 60 )) minutos"

# ── Prova 3: o RPO real da PRODUCAO — o atraso de replicacao do Aurora Global ─
aws cloudwatch get-metric-statistics --region "$DR" \
  --namespace AWS/RDS --metric-name AuroraGlobalDBReplicationLag \
  --dimensions Name=DBClusterIdentifier,Value="${PROJETO}-secundario" \
  --start-time "$(date -u -d '10 min ago' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 60 --statistics Maximum --query 'Datapoints[].Maximum'
# Esperado: valores na casa de segundos ou menos, medidos em milissegundos.
# Acima de 5000 ms (o limiar do alarme) o RPO exigido pela diretoria ja nao
# esta sendo cumprido.

# ── Prova 4: o RTO real da PRODUCAO — failover promovido e medido ────────────
dotnet run --project FailoverRegional -- "${PROJETO}-global" \
  "arn:aws:rds:${DR}:$(aws sts get-caller-identity --query Account --output text):cluster:${PROJETO}-secundario"
# O arquivo marcos-failover-*.json grava o instante de cada etapa. RTO_promocao
# = failover_concluido - failover_solicitado. Compare contra os 30 min do requisito.

# ── Prova 5: o Route 53 realmente desviou, sem intervencao manual no DNS ─────
dig +short api.cadencia.example
# Esperado, com a regiao primaria fora do ar: o endereco devolvido resolve
# para o ALB de us-west-2. Se ainda resolver para o ALB de us-east-1 depois
# do health check ter marcado insalubre, o problema mais comum e TTL alto em
# cache de resolvedor de terceiros — nao no registro do Route 53 em si.

#!/usr/bin/env bash
# limpar-dr.sh — a segunda regiao tem recursos que a primeira nao tem, e eles
# cobram sozinhos se ficarem esquecidos.
set -uo pipefail

PROJETO=cadencia; PRIMARIA=us-east-1; DR=us-west-2

echo "== 1: Terraform administra a maior parte =="
terraform destroy -auto-approve

# 2. CLUSTER SECUNDARIO DO AURORA GLOBAL: se o failover foi ensaiado, a
#    identidade de primario/secundario pode ter INVERTIDO. Confirme QUAL
#    regiao e a primaria antes de destruir, ou o destroy tenta apagar quem
#    esta servindo trafego real.
aws rds describe-global-clusters --global-cluster-identifier "${PROJETO}-global" \
  --query "GlobalClusters[0].GlobalClusterMembers[].{Cluster:DBClusterArn,Writer:IsWriter}" \
  --output table

# 3. REGISTRO GLOBAL: um cluster global nao e removido pelo destroy dos
#    clusters regionais — ele tem de ser desfeito por ultimo, depois que
#    NENHUM cluster regional pertencer mais a ele.
aws rds describe-global-clusters --query "GlobalClusters[].GlobalClusterIdentifier" --output table

# 4. VAULT DE BACKUP NA REGIAO DR: guarda ate 35 dias de recovery points por
#    plano. Apagar o vault sem esvaziar os recovery points falha; esvaziar
#    manualmente e o passo que mais gente pula.
aws backup list-recovery-points-by-backup-vault --region "$DR" \
  --backup-vault-name "${PROJETO}-vault-dr" --query "length(RecoveryPoints)" --output text

# 5. REPOSITORIO ECR REPLICADO em us-west-2: a replicacao copia a imagem;
#    apagar o repositorio na regiao primaria NAO apaga a copia na regiao DR.
aws ecr describe-repositories --region "$DR" --query "repositories[].repositoryName" --output table

# 6. ALB, GRUPO DE DESTINO E ELASTIC IP eventual na regiao DR: cobram por
#    hora ligada mesmo com desired_count=1 e nenhum trafego real.
aws elbv2 describe-load-balancers --region "$DR" --query "LoadBalancers[].LoadBalancerArn" --output table

# 7. Prova final: nada com a tag do projeto de pe em NENHUMA das duas regioes.
for r in "$PRIMARIA" "$DR"; do
  echo "-- $r --"
  aws resourcegroupstaggingapi get-resources --region "$r" \
    --tag-filters Key=Projeto,Values="${PROJETO}" \
    --query "ResourceTagMappingList[].ResourceARN" --output table
done