AWS Disaster Recovery: RTO/RPO Với Pilot Light và Warm Standby

Disaster xảy ra lúc ít ai ngờ nhất. Mình đã chứng kiến một hệ thống e-commerce sập đúng ngày sale lớn vì region AWS us-east-1 gặp sự cố — không có DR plan, không có failover, chỉ có màn hình đỏ và điện thoại reo liên tục. Thiệt hại tính bằng chục nghìn đô mỗi giờ. Từ đó, câu hỏi "RTO bao nhiêu phút là chấp nhận được?" trở thành một trong những câu đầu tiên mình hỏi khi bắt tay vào bất kỳ dự án AWS nào.

Disaster Recovery Trên AWS: Hiểu Đúng Trước Khi Triển Khai

AWS định nghĩa bốn chiến lược DR theo thứ tự tăng dần về chi phí và tốc độ phục hồi: Backup & Restore, Pilot Light, Warm Standby, và Multi-Site Active/Active. Bài này tập trung vào Pilot Light và Warm Standby — hai lựa chọn chiếm đa số các dự án production thực tế vì cân bằng tốt giữa chi phí và RTO.

Hai khái niệm bạn phải nắm chắc trước khi đọc tiếp:

• RTO (Recovery Time Objective): Thời gian tối đa hệ thống có thể downtime trước khi business bị ảnh hưởng nghiêm trọng. RTO = 4 giờ nghĩa là trong vòng 4 giờ sau sự cố, hệ thống phải hoạt động trở lại.
• RPO (Recovery Point Objective): Lượng dữ liệu tối đa có thể mất. RPO = 1 giờ nghĩa là bạn chấp nhận mất tối đa 1 giờ transaction nếu disaster xảy ra.

Khổ nỗi là hai con số này thường xung đột trực tiếp với ngân sách. RTO và RPO càng thấp, chi phí DR càng cao. Nhiệm vụ của kiến trúc sư là tìm điểm cân bằng phù hợp với business requirements.

Pilot Light: Tiết Kiệm Chi Phí, Đánh Đổi RTO Dài Hơn

Pilot Light là chiến lược duy trì một "đốm lửa nhỏ" ở DR region — chỉ những thành phần cốt lõi nhất (thường là database) được chạy liên tục, phần còn lại nằm ở trạng thái tắt hoặc chỉ tồn tại dưới dạng AMI/snapshot.

Kiến trúc điển hình:

• Primary region: toàn bộ stack (EC2, RDS, ECS, ALB...)
• DR region: chỉ RDS replica đang chạy + pre-built AMI cho EC2 + infrastructure-as-code sẵn sàng deploy

RTO thực tế: 30 phút đến 2 giờ — phần lớn thời gian dùng để spin up EC2, chạy Terraform/CloudFormation, và warm up cache.
RPO thực tế: 1–5 phút nếu dùng RDS Multi-AZ cross-region read replica với binlog replication lag thấp.

Một điểm hay của Pilot Light là chi phí DR region rất thấp — thường chỉ 10–15% chi phí primary region. Với hệ thống production medium-sized (~$5,000/tháng primary), DR region Pilot Light chỉ tốn khoảng $500–800/tháng.

Mẹo thực tế: Đừng chỉ snapshot AMI rồi thôi. Phải test deploy từ AMI đó ít nhất mỗi quý một lần — AMI cũ 6 tháng không được test thường bị dependency hell khi cần dùng thật.

Warm Standby: Sẵn Sàng Hơn, Tốn Kém Hơn

Warm Standby nâng cấp lên một bậc: DR region luôn chạy một phiên bản thu nhỏ của production stack — không phải full scale, nhưng đủ để handle traffic ngay lập tức sau khi failover.

Kiến trúc điển hình:

• Primary: 10 EC2 instances, RDS db.r6g.2xlarge, 3 ECS tasks
• DR: 2 EC2 instances (scale up khi cần), RDS db.r6g.large (promote to primary), 1 ECS task

RTO thực tế: 5–30 phút — chủ yếu là thời gian Route 53 propagate DNS và scale up capacity ở DR region.
RPO thực tế: Dưới 1 phút với Aurora Global Database (replication lag thường dưới 1 giây).

Chi phí Warm Standby thường chiếm 30–50% primary region. Đây là khoản đầu tư đáng giá nếu business của bạn có SLA uptime 99.95% trở lên hoặc hoạt động trong lĩnh vực fintech, healthcare, e-commerce với doanh thu cao mỗi giờ.

Triển Khai Thực Tế: Từng Bước Xây DR Trên AWS

Bước 1: Xác định RTO/RPO với stakeholder

Đừng tự đặt số. Ngồi với product owner và finance team để tính chi phí downtime thực tế. Công thức đơn giản: Revenue loss per hour = (Annual revenue / 8760) × impact_factor. Impact factor thường từ 0.5–1.0 tùy loại service. Từ đó ngược lại để chọn DR tier phù hợp.

Bước 2: Thiết lập Data Replication

# Tạo cross-region read replica
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-db-dr \
  --source-db-instance-identifier prod-db-primary \
  --source-region ap-southeast-1 \
  --db-instance-class db.r6g.large \
  --region ap-northeast-1 \
  --multi-az

Với Aurora Global Database (khuyên dùng cho Warm Standby):

aws rds add-region-to-global-cluster \
  --global-cluster-identifier my-global-cluster \
  --db-cluster-identifier my-dr-cluster \
  --region ap-northeast-1

Bước 3: Infrastructure as Code cho DR Region

# Terraform — Warm Standby ASG luôn có 1 instance chạy
resource "aws_autoscaling_group" "dr_warm" {
  name             = "app-dr-warm-standby"
  min_size         = 1
  max_size         = 10
  desired_capacity = 1  # KHÔNG để 0 nếu là Warm Standby

  launch_template {
    id      = aws_launch_template.app_dr.id
    version = "$Latest"
  }

  vpc_zone_identifier = var.dr_private_subnets
}

Bước 4: Route 53 Failover Routing

resource "aws_route53_health_check" "primary" {
  fqdn              = "app.primary.yourdomain.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = "3"
  request_interval  = "10"
}

resource "aws_route53_record" "failover_primary" {
  zone_id        = var.zone_id
  name           = "app.yourdomain.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" "failover_dr" {
  zone_id        = var.zone_id
  name           = "app.yourdomain.com"
  type           = "A"
  set_identifier = "dr"
  failover_routing_policy { type = "SECONDARY" }
  alias {
    name                   = aws_lb.dr.dns_name
    zone_id                = aws_lb.dr.zone_id
    evaluate_target_health = true
  }
}

Bước 5: Promote Database Khi Failover

Đây là bước dễ quên nhất. Khi failover xảy ra, read replica không tự động thành primary — bạn phải promote thủ công hoặc tự động hóa bằng Lambda + EventBridge:

aws rds promote-read-replica \
  --db-instance-identifier prod-db-dr \
  --region ap-northeast-1

Với Aurora Global Database, quá trình này được gọi là "Managed Planned Failover" — AWS thực hiện trong vòng dưới 1 phút với RPO gần như bằng 0.

Nguyên tắc vàng: Mọi bước failover phải được document dưới dạng runbook và test drill ít nhất 2 lần/năm. DR plan không được test là DR plan không tồn tại.

Những Ổ Gà Thực Tế Khi Triển Khai DR Trên AWS

1. Quên encrypt EBS/RDS trước khi snapshot cross-region
Cross-region snapshot copy yêu cầu nguồn phải được encrypt. Nếu bạn có volume chưa encrypt, phải migrate trước. Giải pháp: bật encryption mặc định ở account level ngay từ đầu.

2. Route 53 TTL quá cao
TTL mặc định 300 giây nghĩa là trong 5 phút sau failover, user vẫn hit primary đã chết. Hạ TTL xuống 30–60 giây ít nhất 24 giờ trước khi deploy lớn. Không thể thay đổi TTL retroactively khi cần gấp.

3. Không test restore từ snapshot định kỳ
Snapshot có thể bị corrupt mà không có cảnh báo. Lên lịch Lambda job hàng tuần để restore snapshot vào instance tạm, chạy basic query validation rồi delete — chi phí chỉ vài đô nhưng đáng để đảm bảo snapshot hợp lệ.

4. Application config hardcode primary DB endpoint
Khi failover, DB endpoint thay đổi. Nếu app hardcode RDS endpoint thay vì dùng custom DNS CNAME hoặc Parameter Store, bạn phải redeploy tất cả instance — tốn thêm 20–40 phút. Luôn dùng Parameter Store hoặc Secrets Manager cho DB endpoint.

5. Bỏ qua stateful services
ElastiCache, SQS messages inflight, session store — những thứ này không tự replicate sang DR region. Cần thiết kế riêng: Redis Global Datastore cho ElastiCache, hoặc chấp nhận mất session và yêu cầu user đăng nhập lại sau failover.

FAQ

Q: Pilot Light và Warm Standby khác nhau thế nào về chi phí thực tế?

A: Với hệ thống production $5,000/tháng, Pilot Light tốn thêm khoảng $500–800/tháng cho DR region (chủ yếu là RDS replica). Warm Standby tốn $1,500–2,500/tháng vì phải chạy EC2/ECS instances. Chênh lệch ~$1,000–1,700/tháng, đổi lại RTO giảm từ 30–120 phút xuống còn 5–15 phút.

Q: Aurora Global Database có thực sự đạt RPO dưới 1 giây không?

A: Trong điều kiện bình thường, replication lag của Aurora Global Database thường dưới 1 giây và AWS cam kết RPO dưới 1 giây với managed failover. Trong lúc primary region bị tải cao, lag có thể lên 2–5 giây. Mình đo được lag trung bình 0.3–0.8 giây trong production load test.

Q: Có cần dùng AWS Elastic Disaster Recovery (DRS) không?

A: AWS DRS phù hợp nhất cho workload lift-and-shift từ on-premise hoặc other clouds sang AWS. Nếu bạn đã native AWS từ đầu, tự xây DR với RDS replica + Terraform + Route 53 failover thường hiệu quả hơn và rẻ hơn. DRS có giá $0.028/giờ/server được replicate — với 20 servers là gần $500/tháng chỉ cho agent fee.

Đáng Đầu Tư Hay Không?

Câu trả lời luôn phụ thuộc vào bao nhiêu tiền bạn mất mỗi giờ downtime. Nếu con số đó lớn hơn chi phí DR hàng tháng, bạn đang chấp nhận rủi ro không cần thiết. Pilot Light cho hầu hết startup và scaleup — RTO 1 giờ chấp nhận được nếu sự cố xảy ra lúc 3 giờ sáng. Warm Standby cho fintech, healthcare, và bất kỳ service nào mà 15 phút downtime tạo ra hậu quả pháp lý hoặc tài chính nghiêm trọng.

Nói thật thì: DR plan tốt nhất là plan bạn đã test và biết nó hoạt động. Đừng để lần đầu tiên chạy failover là lúc production đang cháy.