Route 53 Alias vs CNAME: Kapan Harus Pakai Alias Record untuk Zone Apex?

Saat pertama kali mengarahkan domain ke Application Load Balancer, hampir semua engineer langsung berpikir: 'pakai CNAME saja.' Masalahnya, CNAME tidak bisa dipakai di zone apex — dan itulah titik di mana Route 53 Alias record menjadi satu-satunya solusi yang benar.

TL;DR: Route 53 Alias vs CNAME

Aspek CNAME Record Route 53 Alias Record
Zone apex (example.com) ❌ Tidak didukung (RFC 1912) ✅ Didukung penuh
Target Hostname arbitrer AWS resource endpoint (ALB, CloudFront, S3, dll.)
Biaya query DNS Dikenakan biaya per query Gratis untuk target AWS tertentu
Health check integrasi Tidak langsung Bisa dievaluasi terhadap target alias
TTL Dikonfigurasi manual Dikelola Route 53, tidak bisa diubah
Response type CNAME RR dikembalikan ke client A/AAAA record langsung dikembalikan

Bagaimana DNS Zone Apex Bekerja

Zone apex — disebut juga 'naked domain' atau 'root domain' — adalah nama domain tanpa subdomain, misalnya example.com. Standar DNS (RFC 1034 dan RFC 1912) melarang CNAME record berada di apex karena di titik itu harus ada SOA dan NS record. Jika CNAME ditempatkan di apex, ia akan 'memakan' NS record dan merusak resolusi DNS seluruh zone.

Route 53 Alias record bukan CNAME. Ia adalah ekstensi proprietary Route 53 yang berperilaku seperti A record dari sisi client — resolver menerima alamat IP langsung, bukan referensi ke hostname lain. Resolusi alias dilakukan di sisi Route 53, bukan di sisi client.

graph TD ClientA["Client Query example.com (CNAME)"] --> ResolverA["DNS Resolver"] ResolverA --> CNAME_RR["CNAME RR returned: alb-xyz.elb.amazonaws.com"] CNAME_RR --> SecondQuery["Second Query alb-xyz.elb.amazonaws.com"] SecondQuery --> IPResult_A["IP Address returned"] ClientB["Client Query example.com (Alias)"] --> ResolverB["Route 53 Resolver"] ResolverB --> AliasEval["Route 53 evaluates Alias target internally"] AliasEval --> IPResult_B["A Record (IP) returned directly to client"] ZoneApex["Zone Apex: example.com"] --> SOA["SOA Record"] ZoneApex --> NS["NS Record"] ZoneApex --> CNAME_CONFLICT["CNAME Record ❌ Konflik dengan SOA/NS"] style CNAME_CONFLICT fill:#ff4444,color:#fff style IPResult_B fill:#22aa44,color:#fff style AliasEval fill:#2266cc,color:#fff
  1. CNAME flow: Client query ke www.example.com, resolver mengembalikan CNAME ke alb-xyz.us-east-1.elb.amazonaws.com, lalu client harus melakukan query kedua untuk mendapatkan IP.
  2. Alias flow: Client query ke example.com, Route 53 langsung mengembalikan IP address ALB — satu round-trip, tanpa CNAME chain.
  3. Zone apex constraint: CNAME di example.com akan konflik dengan NS/SOA record — Route 53 bahkan tidak mengizinkan konfigurasi ini di console.

Perbedaan Teknis Alias vs CNAME yang Sering Disalahpahami

Banyak engineer mengira Alias record hanya 'CNAME yang lebih baik.' Kenyataannya lebih dalam dari itu.

Ketika Route 53 menerima query untuk Alias record, ia mengevaluasi target secara real-time dan mengembalikan A atau AAAA record langsung ke resolver. Client tidak pernah tahu ada indirection. Ini berbeda fundamental dengan CNAME di mana indirection terekspos ke seluruh chain resolver.

Bayangkan CNAME seperti tanda 'Lihat halaman lain' di buku telepon — pembaca harus mencari lagi. Alias seperti operator yang langsung membaca nomor yang benar tanpa menyebut ada pengalihan.

Satu hal yang sering luput: TTL pada Alias record tidak bisa dikonfigurasi. Route 53 menggunakan TTL dari target resource. Jika ALB mengubah IP-nya, Route 53 akan mengikuti perubahan itu secara otomatis tanpa perlu update record manual.

Kapan Menggunakan Alias Record untuk ALB

Gunakan Alias record dalam kondisi berikut:

  • Mengarahkan zone apex (example.com) ke ALB, CloudFront, S3 static website, atau AWS resource lainnya.
  • Ingin menghindari biaya DNS query — Route 53 tidak mengenakan biaya untuk Alias query ke resource AWS tertentu seperti ALB, CloudFront, dan S3 bucket.
  • Butuh integrasi health check Route 53 yang mengevaluasi kondisi target alias.

Gunakan CNAME jika target adalah hostname non-AWS, atau jika Anda membutuhkan subdomain yang mengarah ke endpoint eksternal di luar ekosistem AWS.

Membuat Route 53 Alias Record ke ALB via AWS CLI

Sebelum membuat record, ambil dulu hosted zone ID dari Route 53 dan DNS name ALB Anda.

# Ambil Hosted Zone ID
aws route53 list-hosted-zones-by-name \
  --dns-name "example.com" \
  --query "HostedZones[0].Id" \
  --output text

# Ambil DNS name dan Hosted Zone ID dari ALB
aws elbv2 describe-load-balancers \
  --names your-alb-name \
  --query "LoadBalancers[0].{DNSName:DNSName,CanonicalHostedZoneId:CanonicalHostedZoneId}" \
  --output table

Setelah mendapatkan nilai-nilai tersebut, buat file JSON untuk change batch. Perhatikan bahwa HostedZoneId di dalam blok AliasTarget adalah Hosted Zone ID milik ALB (bukan hosted zone domain Anda).

🔽 Klik untuk melihat: alias-record-change-batch.json 
{
  "Comment": "Create Alias record for zone apex pointing to ALB",
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "example.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z35SXDOTRQ7X7K",
          "DNSName": "your-alb-1234567890.us-east-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }
  ]
}

Nilai HostedZoneId untuk ALB bervariasi per region. Gunakan output dari perintah describe-load-balancers di atas untuk mendapatkan nilai yang benar — jangan hardcode.

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1PA6795UKMFR9 \
  --change-batch file://alias-record-change-batch.json

Setelah perintah dijalankan, Route 53 akan mengembalikan ChangeInfo dengan status PENDING. Propagasi biasanya selesai dalam hitungan detik hingga menit, tapi SLA resmi Route 53 tidak menjamin waktu spesifik.

Verifikasi Alias Record Berfungsi Benar

Verifikasi dari dua sisi: Route 53 API dan resolusi DNS aktual.

# Verifikasi record sudah terdaftar di Route 53
aws route53 list-resource-record-sets \
  --hosted-zone-id Z1PA6795UKMFR9 \
  --query "ResourceRecordSets[?Name=='example.com.']" \
  --output json
# Verifikasi resolusi DNS dari luar
dig example.com A +short

# Pastikan tidak ada CNAME chain — output harus langsung IP address
dig example.com +trace

Jika output dig menampilkan IP address langsung (bukan CNAME), Alias record bekerja dengan benar. Jika masih melihat CNAME dalam chain, kemungkinan ada record lama yang belum dihapus atau TTL cache belum expired.

IAM Permission untuk Mengelola Route 53 Records

Jika menjalankan operasi ini dari CI/CD pipeline atau role terpisah, berikut permission minimal yang dibutuhkan:

🔽 Klik untuk melihat: IAM policy untuk Route 53 record management 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Route53RecordManagement",
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets",
        "route53:ListResourceRecordSets",
        "route53:GetChange"
      ],
      "Resource": [
        "arn:aws:route53:::hostedzone/Z1PA6795UKMFR9"
      ]
    },
    {
      "Sid": "Route53ListZones",
      "Effect": "Allow",
      "Action": [
        "route53:ListHostedZones",
        "route53:ListHostedZonesByName"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DescribeALBForAliasTarget",
      "Effect": "Allow",
      "Action": [
        "elasticloadbalancing:DescribeLoadBalancers"
      ],
      "Resource": "*"
    }
  ]
}

Perhatikan bahwa route53:ListHostedZones dan route53:ListHostedZonesByName memerlukan "Resource": "*" — ini adalah perilaku yang terdokumentasi di Service Authorization Reference Route 53, bukan kelonggaran kebijakan.

Kasus Nyata: Mengapa CNAME Gagal di Zone Apex

Ini pola yang berulang di tim yang baru migrasi ke AWS. Setup awal: domain di registrar lama, CNAME example.com diarahkan ke ALB. Di beberapa registrar, ini 'berhasil' karena mereka mengimplementasikan CNAME flattening secara diam-diam. Lalu domain dipindah ke Route 53 — dan tiba-tiba tidak bisa membuat CNAME di apex sama sekali.

Diagnosisnya salah: tim mengira ada masalah propagasi atau permission. Padahal Route 53 memang menolak CNAME di zone apex karena mengikuti standar DNS dengan ketat. Solusinya bukan workaround — langsung ganti ke Alias record.

Yang menarik: setelah pindah ke Alias record dengan EvaluateTargetHealth: true, Route 53 mulai mendeteksi ketika ALB target group tidak healthy dan menghentikan traffic ke endpoint tersebut — sesuatu yang tidak pernah bisa dilakukan dengan CNAME biasa.

stateDiagram-v2 [*] --> ConfigureDNS : Engineer setup domain ConfigureDNS --> CNAME_Apex : Coba CNAME di example.com CNAME_Apex --> Rejected : Route 53 menolak (InvalidChangeBatch) Rejected --> AliasRecord : Ganti ke Alias Record AliasRecord --> EvalHealth_False : EvaluateTargetHealth = false AliasRecord --> EvalHealth_True : EvaluateTargetHealth = true EvalHealth_False --> TrafficAlways : Traffic diteruskan meski ALB tidak healthy EvalHealth_True --> HealthCheck : Route 53 evaluasi health ALB target group HealthCheck --> TrafficOK : Target healthy → IP dikembalikan HealthCheck --> SERVFAIL : Semua target tidak healthy → SERVFAIL
  1. CNAME di zone apex: Route 53 menolak konfigurasi ini — console akan menampilkan error, CLI akan mengembalikan InvalidChangeBatch.
  2. Alias dengan EvaluateTargetHealth false: Traffic tetap diarahkan meski ALB tidak healthy.
  3. Alias dengan EvaluateTargetHealth true: Route 53 mengevaluasi health target dan bisa menghentikan resolusi jika target tidak sehat — ini integrasi yang tidak ada padanannya di CNAME.

EvaluateTargetHealth: Detail yang Sering Diabaikan

Parameter EvaluateTargetHealth pada Alias record adalah satu fitur yang membedakan Alias dari sekadar 'CNAME yang bisa di apex.' Ketika di-set ke true dan target adalah ALB, Route 53 akan mengevaluasi health check yang dikonfigurasi pada target group ALB.

Jika semua target di belakang ALB tidak healthy, Route 53 akan merespons query DNS dengan SERVFAIL — bukan mengembalikan IP ALB yang tidak bisa melayani traffic. Ini perilaku yang perlu dipahami sebelum mengaktifkannya di production: SERVFAIL di DNS bisa terlihat seperti 'domain tidak ada' dari sisi client, bukan seperti 'server error.'

Wrap-Up: Route 53 Alias Record untuk Domain Production

Untuk mengarahkan domain ke ALB di AWS, gunakan Route 53 Alias record — terutama untuk zone apex. CNAME bukan pilihan di example.com, dan Alias record memberikan keuntungan tambahan: resolusi satu langkah, tanpa biaya query untuk target AWS, dan opsi health check terintegrasi.

Langkah selanjutnya yang disarankan:

  • Baca dokumentasi resmi: Choosing between alias and non-alias records
  • Jika menggunakan multi-region, pertimbangkan Route 53 Latency-based routing dengan Alias record ke ALB di masing-masing region.
  • Aktifkan EvaluateTargetHealth di environment production dan uji perilaku SERVFAIL sebelum go-live.

Glosarium

Istilah Penjelasan
Zone Apex Nama domain root tanpa subdomain (contoh: example.com). Disebut juga naked domain atau root domain.
Alias Record Ekstensi proprietary Route 53 yang mengembalikan A/AAAA record langsung ke client, mengarah ke AWS resource endpoint.
CNAME Record DNS record standar yang mengarahkan satu hostname ke hostname lain. Tidak bisa digunakan di zone apex.
EvaluateTargetHealth Parameter Alias record yang mengaktifkan evaluasi health check Route 53 terhadap target AWS resource.
CanonicalHostedZoneId Hosted Zone ID yang dimiliki oleh AWS resource (seperti ALB), digunakan sebagai HostedZoneId dalam konfigurasi AliasTarget.

Komentar

Posting Komentar

Postingan populer dari blog ini

EC2 Tidak Bisa Akses Internet di Custom VPC: Cara Pasang Internet Gateway dan Update Route Table

Kamu baru saja membuat custom VPC, meluncurkan EC2 instance di public subnet, lalu mencoba ping google.com — dan tidak ada respons sama sekali. Ini adalah salah satu jebakan paling umum saat pertama kali bekerja dengan EC2 no internet access di custom VPC , dan penyebabnya hampir selalu kombinasi dari tiga hal: tidak ada Internet Gateway, route table yang belum diupdate, atau Security Group yang memblokir traffic. TL;DR: Checklist EC2 Tidak Bisa Internet di Custom VPC Komponen Yang Harus Dicek Kondisi Benar Internet Gateway Sudah dibuat dan di-attach ke VPC State: attached Route Table Ada route 0.0.0.0/0 ke IGW Target: igw-xxxxxxxx Subnet Association Public subnet terhubung ke route table yang benar Subnet ID muncul di associations Security Group Inbound HTTP/HTTPS/ICMP diizinkan Rule eksplisit untuk port 80, 443, atau ICMP Public IP Instance punya public IP atau Elastic IP PublicIpAddress tidak n...
Baca selengkapnya