Setup Disaster Recovery dan Multi-Region Deployment di AWS: Strategi Failover dan Backup Database Otomatis

Memahami Konsep Disaster Recovery dan Metrik RTO-RPO

Ketika sebuah region AWS mengalami gangguan, seluruh layanan yang bergantung padanya ikut terdampak. Kehilangan akses aplikasi berarti kehilangan revenue, reputasi, dan kepercayaan pengguna. Disaster Recovery (DR) adalah rencana terstruktur untuk memulihkan layanan dan data ketika bencana terjadi — entah itu bencana alam, kegagalan infrastruktur, atau kesalahan manusia.

Dua metrik menjadi dasar perancangan setiap strategi DR. RTO (Recovery Time Objective) mengukur waktu maksimal yang dibutuhkan untuk memulihkan layanan setelah gangguan. RPO (Recovery Point Objective) menentukan seberapa banyak data yang boleh hilang saat pemulihan. Kedua angka ini ditentukan oleh toleransi bisnis, bukan oleh tim teknis semata. Aplikasi pembayaran mungkin menuntut RTO di bawah satu jam, sementara sistem pelaporan internal bisa mentolerir pemulihan dalam satu hari.

RTO dan RPO seperti dua alarm pada sistem cadangan — satu mengukur seberapa cepat kita kembali beroperasi, sementara yang lain mengukur berapa banyak data yang rela kita korbankan. AWS menyediakan empat strategi DR dengan tradeoff berbeda antara biaya dan kecepatan pemulihan. Backup and Restore adalah yang paling murah namun paling lambat. Pilot Light menjaga versi inti aplikasi tetap berjalan dengan skala kecil. Warm Standby mempertahankan versi lengkap yang siap ditingkatkan, dan Multi-Site Active-Active membagi traffic ke semua region dengan pemulihan hampir instan. Pemilihan strategi bergantung pada seberapa ketat target RTO dan RPO yang harus dipenuhi.

Gambar: Arsitektur Multi-Site Active-Active dengan dua region AWS, replikasi database otomatis, dan pembagian traffic oleh Route 53 — Sumber: AWS Well-Architected Framework

Gambar: Arsitektur Pilot Light menunjukkan region recovery dengan replika database yang tetap sinkron namun server aplikasi belum berjalan — Sumber: AWS Well-Architected Framework

Merancang Multi-Region Deployment dengan Route 53 Failover Routing

Langkah pertama membangun DR yang tangguh adalah mendesain arsitektur yang berjalan di lebih dari satu region. Aplikasi utama beroperasi di region primer, sementara region sekunder menunggu sebagai cadangan. Data direplikasi antar kedua region, dan lalu lintas pengguna diarahkan oleh sistem DNS.

Route 53 Failover Routing menjadi otak dari mekanisme ini. Layanan ini bekerja pada level DNS dan mengalihkan traffic secara otomatis ketika health check mendeteksi region primer tidak sehat. Ketika health check gagal, record DNS langsung menunjuk ke region sekunder tanpa intervensi manual.

Berikut contoh konfigurasi Terraform untuk membuat dua record alias dengan kebijakan failover di Route 53:

resource "aws_route53_record" "primary" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "app.rumahcoding.co.id"
  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-region"
}

resource "aws_route53_health_check" "primary" {
  fqdn              = aws_lb.primary.dns_name
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
}

resource "aws_route53_record" "secondary" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "app.rumahcoding.co.id"
  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-region"

  health_check_id = aws_route53_health_check.primary.id
}

Output:

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:
route53_record_primary   = "app.rumahcoding.co.id -> primary-region"
route53_record_secondary = "app.rumahcoding.co.id -> secondary-region"

Konfigurasi ini menciptakan pasangan record PRIMARY dan SECONDARY. Record sekunder mereferensikan health check dari region primer, sehingga ketika layanan primer gagal melampaui ambang batas, Route 53 otomatis memindahkan traffic ke record sekunder. Pendekatan ini berbeda dengan Latency-based Routing yang memilih region terdekat secara geografis, atau Weighted Routing yang membagi traffic berdasarkan persentase. Failover Routing adalah satu-satunya yang dirancang khusus untuk skenario pemulihan bencana.

Mengonfigurasi Backup Database Otomatis dan Replikasi Antar Region

Database menyimpan data paling berharga, sehingga strategi backup-nya harus dirancang dengan cermat. AWS RDS menyediakan automatic backup yang membuat snapshot harian dan mencatat transaction logs secara kontinu. Kombinasi keduanya memungkinkan pemulihan point-in-time — kita bisa mengembalikan database ke detik tertentu sebelum insiden terjadi.

Penting membedakan dua konsep yang sering tertukar. Multi-AZ menciptakan replika sinkron dalam satu region untuk menjaga high availability terhadap kegagalan hardware. Cross-Region Read Replica menyalin data ke region lain secara asinkron untuk tujuan disaster recovery. Keduanya melayani kebutuhan berbeda, dan arsitektur DR yang matang menggunakan keduanya.

Berikut perintah AWS CLI untuk mengaktifkan backup otomatis dan membuat read replica lintas region:

# Aktifkan automatic backup dengan retensi 7 hari
aws rds modify-db-instance \
  --db-instance-identifier mydb-primary \
  --backup-retention-period 7 \
  --preferred-backup-window "02:00-03:00"

# Buat Cross-Region Read Replica dari snapshot terbaru
aws rds create-db-instance-read-replica \
  --db-instance-identifier mydb-replica \
  --source-db-instance-identifier mydb-primary \
  --region ap-southeast-1 \
  --source-region ap-southeast-3 \
  --db-instance-class db.t3.medium \
  --publicly-accessible false

Output:

{
    "DBInstance": {
        "DBInstanceIdentifier": "mydb-replica",
        "DBInstanceStatus": "creating",
        "MultiAZ": false,
        "ReadReplicaSourceDBInstanceIdentifier": "mydb-primary",
        "ReplicaMode": "read-only"
    }
}

Ketika disaster terjadi, read replica dipromosikan menjadi primary dengan satu perintah aws rds promote-read-replica. Replika berhenti menerima data dari sumber dan menjadi instance writable yang mandiri. Aplikasi kemudian diarahkan ke endpoint baru ini. Proses ini memakan waktu beberapa menit, sehingga target RTO harus memperhitungkan durasi promosi dan perubahan endpoint aplikasi.

Mengotomatiskan Failover dengan AWS Backup, Lambda, dan CloudWatch

Manajemen backup manual rawan dilupakan ketika insiden benar-benar terjadi. AWS Backup menyatukan pengelolaan backup lintas layanan — RDS, EBS, dan S3 — di bawah satu kebijakan dengan jadwal dan retensi terpusat. Kebijakan ini menjamin snapshot selalu dibuat tepat waktu tanpa ketergantungan pada konfigurasi tiap layanan.

Keandalan DR meningkat drastis ketika failover diotomatiskan. CloudWatch Alarm mendeteksi kegagalan region primer dan memicu Lambda function yang menjalankan runbook pemulihan. Function ini mempromosikan read replica, mengubah record DNS di Route 53, dan membalikkan traffic pengguna ke region sekunder. Otomatisasi menghilangkan jeda reaksi manusia yang sering menjadi sumber kesalahan.

Berikut contoh Lambda function berbasis Python yang mengotomatiskan proses failover:

import boto3
import json

def lambda_handler(event, context):
    rds = boto3.client("rds")
    route53 = boto3.client("route53")

    # 1. Promosikan read replica menjadi primary
    response = rds.promote_read_replica(
        DBInstanceIdentifier="mydb-replica"
    )

    # 2. Alihkan record DNS ke region sekunder
    change = route53.change_resource_record_sets(
        HostedZoneId="Z1234567890ABC",
        ChangeBatch={
            "Changes": [
                {
                    "Action": "UPSERT",
                    "ResourceRecordSet": {
                        "Name": "app.rumahcoding.co.id",
                        "Type": "A",
                        "TTL": 60,
                        "ResourceRecords": [
                            {"Value": "13.228.123.45"}
                        ]
                    }
                }
            ]
        }
    )

    return {
        "statusCode": 200,
        "body": json.dumps({
            "db_status": response["DBInstance"]["DBInstanceStatus"],
            "dns_change_id": change["ChangeInfo"]["Id"]
        })
    }

Output:

{
  "statusCode": 200,
  "body": "{\"db_status\": \"available\", \"dns_change_id\": \"/change/C0123456789\"}"
}

Function ini bekerja dalam tiga langkah. Pertama, mempromosikan read replica menjadi primary. Kedua, mengubah record DNS agar menunjuk ke endpoint region sekunder. Ketiga, mengembalikan status untuk keperluan logging. IAM role pada Lambda harus memiliki izin minimal untuk operasi rds:PromoteReadReplica dan route53:ChangeResourceRecordSets, sesuai prinsip least privilege.

Best Practice DR dan Pengujian Berkala untuk Production

Rencana DR yang tidak pernah diuji adalah rencana yang tidak bisa dipercaya. Banyak organisasi menemukan kegagalan fatal pada runbook mereka justru saat disaster nyata terjadi — persis ketika runbook paling dibutuhkan. Menguji rencana secara berkala adalah bagian yang tidak terpisahkan dari strategi DR yang sehat.

Pendekatan Game Days sengaja mematikan region primer secara terkendali untuk memverifikasi kesiapan tim dan otomatisasi. Latihan ini mengungkap celah dalam runbook, ketergantungan yang tidak terdokumentasi, dan masalah izin akses sebelum menjadi insiden produksi. Dokumentasi runbook yang jelas dan pembagian tanggung jawab on-call memastikan setiap anggota tim tahu persis apa yang harus dilakukan.

Keamanan data cadangan juga wajib diperhatikan. Enkripsi snapshot menggunakan AWS KMS melindungi data cadangan dari akses yang tidak sah. Kontrol akses berbasis IAM memastikan hanya peran yang berwenang yang bisa membaca atau memulihkan backup. Terakhir, biaya DR harus diseimbangkan dengan toleransi bisnis — strategi Active-Active menawarkan pemulihan tercepat namun mahal, sementara standby dingin murah tetapi lambat. Memilih kombinasi yang tepat berdasarkan metrik RTO dan RPO yang telah ditetapkan adalah keputusan arsitektur paling penting dalam membangun sistem yang tangguh.

Tertarik membangun arsitektur cloud yang andal dan tahan bencana? Program Cloud & DevOps di Rumah Coding membahas disaster recovery, high availability, dan multi-region deployment secara end-to-end dengan studi kasus arsitektur production-grade.