재해 복구·백업 — 백업 · 리전 간 DR · RTO/RPO

1장에서 Multi-AZ가 한 AZ 장애를 견디는 운영의 기본이라고 했고, 11장 RDS에서 Multi-AZ 옵션을 다뤘습니다. 이 챕터는 그보다 한 단계 위의 질문을 다룹니다 — 백업이 실제로 복구되는가, 그리고 한 리전 전체가 무너지면 어떻게 하는가입니다.

재해 복구(DR)는 평소에는 보이지 않다가 사고가 났을 때 회사의 생사를 가릅니다. 핵심은 두 숫자를 먼저 정하는 것입니다 — 얼마나 오래 멈춰도 되는가(RTO), 얼마만큼의 데이터를 잃어도 되는가(RPO). 이 챕터의 백업·DR 설계는 29장 보안 거버넌스의 계정 분리, 6부 캡스톤의 운영 체크리스트와 함께 봅니다.

먼저 두 숫자 — RTO와 RPO #

RTO 4시간 / RPO 1시간이라면, 4시간 안에 복구하되 사고 직전 1시간 분량의 데이터는 잃을 수 있다는 뜻입니다. 이 두 숫자가 작을수록 비용이 급격히 오릅니다. 그래서 DR 설계는 “얼마나 튼튼하게"가 아니라 “이 서비스에 RTO/RPO가 실제로 얼마여야 하는가"에서 시작합니다. 사내 관리 도구와 결제 시스템의 답은 완전히 다릅니다.

백업 — 데이터를 잃지 않기 #

DR의 토대는 백업입니다. 서비스별 도구가 다릅니다.

RDS — 자동 백업과 PITR #

• 자동 백업 — 보존 기간(최대 35일) 안에서 매일 스냅샷 + 트랜잭션 로그를 남깁니다. backup_retention_period로 켭니다.
• PITR(Point-in-Time Recovery) — 보존 기간 안의 임의 시점(초 단위)으로 새 인스턴스를 복원합니다. 실수로 테이블을 지운 5분 전으로 되돌릴 수 있습니다.
• 수동 / 자동 스냅샷의 리전 간 복사 — 다른 리전에 사본을 두어 리전 장애에 대비합니다.

resource "aws_db_instance" "main" {
  identifier              = "myapp-prod"
  backup_retention_period = 14                  # 14일 PITR 가능
  backup_window           = "17:00-17:30"       # UTC (KST 02:00)
  copy_tags_to_snapshot   = true
}

# 자동 백업을 DR 리전으로 복제 (별도 리전 provider)
resource "aws_db_instance_automated_backups_replication" "dr" {
  provider               = aws.dr            # 예: us-west-2
  source_db_instance_arn = aws_db_instance.main.arn
  retention_period       = 14
}

복구는 보지 않고 시점을 지정해 새 인스턴스를 띄웁니다. 원본을 덮어쓰지 않고 새 인스턴스로 복원한 뒤 앱의 연결을 바꾸는 것이 안전합니다.

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier myapp-prod \
  --target-db-instance-identifier myapp-restored \
  --restore-time 2026-05-24T09:25:00Z

Aurora Serverless v2는 비prod / 유휴 DB 라면 **최소 용량 0 ACU(자동 일시정지)**로 두어 멈춰 있는 동안 컴퓨팅 비용을 0으로 만들 수 있습니다(스토리지만 과금). 다만 항상 최신을 유지해야 하는 DR 리전의 읽기 사본은 일시정지하면 안 되므로 낮은 최소 ACU로 켜 둡니다.

S3 — 버전 관리와 Cross-Region Replication #

• 버전 관리(Versioning) — 객체를 덮어쓰거나 지워도 이전 버전이 남습니다. 실수 삭제와 랜섬웨어 대비의 기본입니다.
• 복제(CRR: Cross-Region Replication) — 다른 리전 / 계정 버킷으로 자동 복제해 리전 장애에 대비합니다. 버전 관리가 켜져 있어야 합니다.
• 객체 잠금(Object Lock) — 규제 데이터를 일정 기간 삭제 불가로 묶습니다.

resource "aws_s3_bucket_versioning" "main" {
  bucket = aws_s3_bucket.main.id
  versioning_configuration { status = "Enabled" }
}

resource "aws_s3_bucket_replication_configuration" "crr" {
  bucket = aws_s3_bucket.main.id
  role   = aws_iam_role.replication.arn
  rule {
    id     = "to-dr"
    status = "Enabled"
    destination {
      bucket        = aws_s3_bucket.dr.arn   # DR 리전 버킷
      storage_class = "STANDARD_IA"
    }
  }
}

AWS Backup — 한곳에서 묶어 관리 #

서비스마다 따로 백업을 설정하면 빠뜨리기 쉽습니다. AWS Backup은 RDS · EBS · EFS · DynamoDB · S3 등의 백업 정책을 한 곳에서 정하고, 보존 기간 · 리전 간 복사 · 백업 검증을 자동화합니다.

resource "aws_backup_plan" "daily" {
  name = "daily-with-dr-copy"
  rule {
    rule_name         = "daily"
    target_vault_name = aws_backup_vault.main.name
    schedule          = "cron(0 17 * * ? *)"   # 매일 UTC 17:00
    lifecycle { delete_after = 35 }
    copy_action {
      destination_vault_arn = aws_backup_vault.dr.arn   # DR 리전 vault
      lifecycle { delete_after = 35 }
    }
  }
}

# 태그로 백업 대상 자동 선택 (Backup=true 태그가 붙은 모든 리소스)
resource "aws_backup_selection" "tagged" {
  name         = "tagged-resources"
  plan_id      = aws_backup_plan.daily.id
  iam_role_arn = aws_iam_role.backup.arn
  selection_tag {
    type  = "STRINGEQUALS"
    key   = "Backup"
    value = "true"
  }
}

29장의 Organizations와 묶으면 Backup 정책을 조직 전체에 일괄 적용할 수 있어, 새 계정도 자동으로 백업 대상이 됩니다.

백업은 복구를 해봐야 백업입니다. 복원 절차를 실제로 돌려 RTO를 측정해 보지 않은 백업은 “있다고 믿는 백업” 일 뿐입니다. 분기마다 복원 훈련을 권장합니다.

리전 간 DR 패턴 #

한 리전 전체가 무너지는 일은 드물지만, 일어나면 Multi-AZ로는 막을 수 없습니다. 다른 리전에 얼마나 준비해 두느냐로 네 패턴이 갈립니다. 아래로 갈수록 RTO/RPO가 작고 비용이 큽니다.

Pilot Light — 실전의 출발점 #

대부분의 서비스에 현실적인 첫 DR은 Pilot Light입니다.

• DR 리전에 DB만 복제해 항상 최신으로 둡니다(RDS read replica 또는 자동 백업 복제).
• 앱(ECS / Lambda)과 네트워크는 Terraform 코드로 정의만 해두고 평소엔 desired_count = 0 이거나 apply 하지 않은 상태로 둡니다.
• 사고 시 DR 리전에 Terraform으로 앱을 띄우고(또는 desired_count를 올리고), Route 53으로 트래픽을 전환합니다.
• 평소 비용은 DB 복제분 정도로 낮고, RTO는 “앱을 띄우는 시간 + DNS 전파"입니다.

32장 캡스톤의 인프라가 Terraform으로 코드화되어 있으면, DR 리전 복구는 “같은 모듈을 DR 리전 provider로 apply"로 단순해집니다. IaC가 DR의 전제 인 이유입니다(25장 Terraform 입문).

Route 53으로 전환 #

리전 전환의 스위치는 12장 Route 53입니다. 헬스 체크 + 페일오버 라우팅으로, 주 리전이 죽으면 자동으로 DR 리전 DNS로 넘깁니다.

resource "aws_route53_health_check" "primary" {
  fqdn              = "primary.example.com"
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_record" "primary" {
  zone_id        = data.aws_route53_zone.main.zone_id
  name           = "api.example.com"
  type           = "A"
  set_identifier = "primary"
  failover_routing_policy { type = "PRIMARY" }
  health_check_id = aws_route53_health_check.primary.id
  alias {
    name                   = aws_lb.primary.dns_name
    zone_id                = aws_lb.primary.zone_id
    evaluate_target_health = true
  }
}

resource "aws_route53_record" "secondary" {
  zone_id        = data.aws_route53_zone.main.zone_id
  name           = "api.example.com"
  type           = "A"
  set_identifier = "secondary"
  failover_routing_policy { type = "SECONDARY" }
  alias {
    name                   = aws_lb.dr.dns_name      # DR 리전 ALB
    zone_id                = aws_lb.dr.zone_id
    evaluate_target_health = true
  }
}

Multi-Site에서는 페일오버 대신 가중치(weighted) 또는 지연(latency) 라우팅으로 두 리전에 트래픽을 항상 분배합니다.

한 장의 결정 흐름 #

1. 서비스별 RTO / RPO를 먼저 적습니다. 전사 동일 값은 없습니다.
2. 백업(RDS PITR + S3 버전 관리 + AWS Backup, 리전 간 복사 포함)을 모든 서비스에 깝니다. 여기까지가 최소선입니다.
3. RTO/RPO가 시간 단위로 허용되면 Backup & Restore로 충분합니다.
4. 분 단위가 필요하면 Pilot Light → Warm Standby로 올립니다.
5. 무중단이 매출에 직결되면 Multi-Site를 검토하되, 비용과 운영 복잡도가 가장 큽니다.
6. 어느 패턴이든 복원 훈련으로 RTO를 실측 합니다.

연습문제 #

1. 본인 서비스(또는 가상 서비스)의 RTO와 RPO를 숫자로 적고, 그 근거(멈췄을 때의 사업 영향)를 한 단락으로 쓰세요. 그 숫자에 §“리전 간 DR 패턴"의 네 패턴 중 어느 것이 맞는지 고르세요.
2. 운영자가 실수로 prod 테이블을 DROP 했습니다. RDS PITR와 S3 버전 관리 중 무엇이 이 사고를 되살리는지, 그리고 원본을 덮어쓰지 않고 새 인스턴스로 복원한 뒤 서비스를 다시 세우는 절차를 §“백업"의 CLI를 근거로 적어 보세요.
3. Pilot Light가 Warm Standby보다 싼 이유를 “평소에 무엇이 떠 있는가”(DB만 vs 축소 앱까지) 관점에서 설명하고, 25장 Terraform 입문의 IaC가 왜 Pilot Light의 전제가 되는지 한 단락으로 적어 보세요.

한 줄 요약: DR은 RTO(허용 정지 시간)와 RPO(허용 데이터 손실) 두 숫자를 서비스별로 정하는 데서 시작하고, 이 숫자가 작을수록 비용이 급등한다. 토대는 백업이다 — RDS는 backup_retention_period + PITR + 자동 백업 리전 복제, S3는 버전 관리 + CRR, AWS Backup은 태그 선택으로 RDS/EBS/S3 등을 한 플랜에 묶어 DR 리전 copy까지 자동화한다. 복원 훈련으로 RTO를 실측한다. 리전 간 DR은 Backup & Restore → Pilot Light → Warm Standby → Multi-Site로 갈수록 RTO가 작고 비싸며, 대부분은 DB만 복제하고 앱은 Terraform으로 띄우는 Pilot Light가 현실적 출발점이다. 전환 스위치는 Route 53 헬스체크 + 페일오버 라우팅이고, IaC가 DR의 전제다.

다음 챕터 #

다음 31장 Lambda 깊이에서는 17장 Lambda 기초 위에서 production 운영 관점을 더합니다. 콜드 스타트와 Provisioned Concurrency, Layers와 컨테이너 이미지 패키징, Lambda Powertools 기반 관측성, Step Functions 결합, 그리고 비용 트레이드오프를 다룹니다.