Networking
Amazon Route 53
DNS Service, Hosted Zones, Routing Policies, Health Checks
Tổng quan
Amazon Route 53 là dịch vụ Domain Name System (DNS) có tính sẵn sàng cao và khả năng mở rộng của AWS. Tên "Route 53" lấy từ cổng 53 - cổng tiêu chuẩn của giao thức DNS.
Nguồn: Route 53 Developer Guide
3 Chức năng chính
Route 53 cung cấp 3 chức năng chính:
┌─────────────────────────────────────────────────────────────────────┐
│ Amazon Route 53 │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Domain │ │ DNS │ │ Health │ │
│ │ Registration │ │ Routing │ │ Checks │ │
│ │ │ │ │ │ │ │
│ │ Đăng ký tên │ │ Phân giải DNS │ │ Kiểm tra sức │ │
│ │ miền mới │ │ & routing │ │ khỏe resources │ │
│ └─────────────────┘ └─────────────────┘ └─────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘| Chức năng | Mô tả | Ví dụ |
|---|---|---|
| Domain Registration | Đăng ký và quản lý tên miền | example.com, myapp.io |
| DNS Routing | Phân giải domain → IP address | example.com → 54.231.12.45 |
| Health Checks | Giám sát sức khỏe của resources | Kiểm tra endpoint còn sống không |
DNS là gì?
DNS (Domain Name System) là hệ thống "danh bạ điện thoại" của Internet, chuyển đổi tên miền thành địa chỉ IP.
Quan trọng: DNS là hệ thống phân tán toàn cầu, KHÔNG phải do AWS quản lý. Route 53 chỉ là một trong nhiều dịch vụ Authoritative DNS mà bạn có thể chọn.
Ai quản lý DNS?
| Thành phần | Ai quản lý? |
|---|---|
| Root DNS (.) | 13 tổ chức toàn cầu (ICANN, Verisign, NASA...) |
| TLD (.com, .vn...) | Domain registries (Verisign, VNNIC...) |
| Authoritative DNS (domain của bạn) | Bạn chọn - có thể là Route 53, Cloudflare, Google DNS... |
DNS Resolution Flow (Chi tiết)
┌──────────────────────────────────────────────────────────────────────────────┐
│ DNS Resolution Flow │
│ │
│ Bạn gõ: www.example.com │
│ │
│ ┌──────────┐ ① ┌──────────────┐ │
│ │ Browser │ ───────────▶ │ DNS Resolver │ (ISP hoặc 8.8.8.8) │
│ └──────────┘ └──────┬───────┘ │
│ │ │
│ ② Không có cache? Hỏi Root │
│ ▼ │
│ ┌────────────┐ │
│ │ Root DNS │ "Tôi không biết, hỏi .com đi" │
│ │ (.) │ → Trả về địa chỉ TLD servers │
│ └──────┬─────┘ │
│ │ │
│ ③ Hỏi TLD server │
│ ▼ │
│ ┌────────────┐ │
│ │ TLD DNS │ "example.com? Hỏi Route 53" │
│ │ (.com) │ → Trả về NS của example.com │
│ └──────┬─────┘ │
│ │ │
│ ④ Hỏi Authoritative DNS (Route 53) │
│ ▼ │
│ ┌────────────┐ │
│ │ Route 53 │ "www.example.com = 54.231.12.45" │
│ │(AWS) │ → Trả về IP address │
│ └──────┬─────┘ │
│ │ │
│ ⑤ Resolver cache + trả về cho browser │
│ ▼ │
│ ┌──────────┐ ⑥ ┌──────────────┐ │
│ │ Browser │ ◀─────────── │ DNS Resolver │ IP: 54.231.12.45 │
│ └────┬─────┘ └──────────────┘ │
│ │ │
│ │ ⑦ Kết nối trực tiếp đến server │
│ ▼ │
│ ┌──────────┐ │
│ │ Server │ 54.231.12.45 │
│ └──────────┘ │
└──────────────────────────────────────────────────────────────────────────────┘DNS Caching
DNS Resolver sẽ cache kết quả theo TTL, nên không phải lần nào cũng đi qua tất cả các bước:
Lần đầu truy cập:
Browser → Resolver → Root → TLD → Route 53 → Resolver → Browser
(4 bước, chậm ~100-200ms)
Lần sau (trong TTL):
Browser → Resolver (đã cache!) → Browser
(1 bước, nhanh ~1-10ms)DNS Cache được lưu ở đâu?
DNS Cache được lưu ở nhiều tầng khác nhau:
┌─────────────────────────────────────────────────────────────────────────────┐
│ DNS Cache Layers │
│ │
│ ① Browser Cache │
│ └── Chrome, Firefox... cache DNS records │
│ └── Thời gian: vài phút đến vài giờ │
│ └── Clear: chrome://net-internals/#dns │
│ │
│ ② OS Cache (Local DNS Cache) │
│ └── Windows: DNS Client service │
│ └── Linux: systemd-resolved, nscd │
│ └── macOS: mDNSResponder │
│ └── Clear: ipconfig /flushdns (Windows), sudo dscacheutil -flushcache │
│ │
│ ③ DNS Resolver Cache (ISP hoặc Public DNS) │
│ └── ISP DNS servers │
│ └── Google 8.8.8.8 │
│ └── Cloudflare 1.1.1.1 │
│ └── Cache theo TTL của record │
│ │
│ ④ Authoritative DNS (Route 53) │
│ └── KHÔNG cache - đây là nguồn chính thức! │
└─────────────────────────────────────────────────────────────────────────────┘Flow khi query:
Browser gõ example.com
│
▼
① Check Browser Cache ──── Có? → Dùng luôn, XONG
│ Không
▼
② Check OS Cache ────────── Có? → Dùng luôn, XONG
│ Không
▼
③ Hỏi DNS Resolver ─────── Có cache? → Trả về, XONG
│ Không
▼
④ Resolver hỏi Root → TLD → Authoritative DNS (Route 53)
│
▼
Cache kết quả theo TTL tại ③②① rồi trả vềDNS Hierarchy
┌─────────────────┐
│ Root (.) │ Root DNS servers (13 tổ chức)
└────────┬────────┘
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ .com │ │ .org │ │ .io │ TLD servers
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│example │ │ wiki │ │ myapp │ Authoritative DNS
│.com │ │ .org │ │ .io │ (Route 53, Cloudflare...)
└────┬────┘ └─────────┘ └─────────┘
│
┌────▼────┐
│ www │ Subdomain
└─────────┘Hosted Zones
DNS Zone là gì?
DNS Zone = "Vùng quản lý" của một domain và các subdomain của nó. DNS Zone chứa tất cả DNS records liên quan đến domain đó.
┌─────────────────────────────────────────────────────────────────┐
│ Domain: example.com │
│ │ │
│ ▼ │
│ DNS Zone: Chứa tất cả thông tin DNS của domain │
│ │ │
│ ├── NS record (ai quản lý zone này) │
│ ├── SOA record (metadata zone) │
│ ├── A record (domain → IP) │
│ ├── CNAME record (alias) │
│ └── ... các records khác │
└─────────────────────────────────────────────────────────────────┘| Thuật ngữ | Ý nghĩa |
|---|---|
| DNS Zone | Khái niệm tổng quát - "vùng quản lý DNS" |
| Hosted Zone | Tên gọi của DNS Zone trong Route 53 |
Hosted Zone trong Route 53
Hosted Zone = "Tủ hồ sơ" chứa tất cả DNS records cho một domain.
┌─────────────────────────────────────────────────────────────────┐
│ HOSTED ZONE: example.com │
│ (Tủ hồ sơ của domain) │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ DNS RECORDS (Các hồ sơ trong tủ) │ │
│ │ │ │
│ │ 📄 example.com → 54.231.12.45 (A record) │ │
│ │ 📄 www.example.com → example.com (CNAME) │ │
│ │ 📄 api.example.com → 54.231.12.46 (A record) │ │
│ │ 📄 mail.example.com → mailserver.com (MX record) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
→ 1 domain = 1 Hosted Zone
→ Trong Hosted Zone có nhiều DNS records (A, CNAME, MX...)Records tự động tạo khi tạo Hosted Zone
Khi bạn tạo một Hosted Zone, AWS tự động tạo 2 loại records bắt buộc:
┌─────────────────────────────────────────────────────────────────┐
│ KHI TẠO HOSTED ZONE, AWS TỰ ĐỘNG TẠO: │
│ │
│ ① NS Record (Name Server) │
│ └── Chỉ ra 4 name servers quản lý zone này │
│ │
│ ② SOA Record (Start of Authority) │
│ └── Metadata quản trị của zone │
└─────────────────────────────────────────────────────────────────┘NS Record (Name Server)
NS Record chứa danh sách 4 Name Servers của AWS quản lý zone của bạn:
┌─────────────────────────────────────────────────────────────────┐
│ Route 53 assign 4 Name Servers cho Hosted Zone của bạn: │
│ │
│ ns-123.awsdns-45.com (TLD .com) │
│ ns-456.awsdns-78.net (TLD .net) │
│ ns-789.awsdns-12.org (TLD .org) │
│ ns-012.awsdns-34.co.uk (TLD .co.uk) │
│ │
│ → 4 TLDs khác nhau = High Availability! │
│ → Nếu .com TLD bị sự cố, vẫn còn .net, .org, .co.uk hoạt động │
│ → Phân tán trên 100+ AWS Edge Locations toàn cầu │
└─────────────────────────────────────────────────────────────────┘Khi nào cần dùng NS Record?
- Khi bạn mua domain ở nhà cung cấp khác (GoDaddy, Namecheap...) và muốn dùng Route 53 quản lý DNS
- → Copy 4 NS này vào cài đặt nameserver của domain tại registrar
SOA Record (Start of Authority)
SOA Record = "Giấy chứng nhận quyền sở hữu" của DNS Zone, chứa thông tin quản trị.
┌─────────────────────────────────────────────────────────────────┐
│ SOA RECORD - MỤC ĐÍCH: │
│ │
│ ① Xác định ai là "chủ" của zone │
│ └── Primary name server, admin email │
│ │
│ ② Đồng bộ giữa Primary và Secondary DNS servers │
│ └── Serial number: tăng mỗi khi có thay đổi │
│ └── Refresh: Secondary check Primary sau bao lâu │
│ └── Retry: Nếu fail, thử lại sau bao lâu │
│ └── Expire: Ngừng phục vụ nếu mất liên lạc quá lâu │
│ │
│ ③ Negative Caching (TTL cho "không tìm thấy") │
│ └── Cache "record không tồn tại" trong bao lâu │
└─────────────────────────────────────────────────────────────────┘Ví dụ SOA Record:
ns-123.awsdns-45.com. hostmaster.example.com. 1 7200 900 1209600 86400
│ │ │ │ │ │ │
│ │ │ │ │ │ └─ Minimum TTL
│ │ │ │ │ └───────── Expire time
│ │ │ │ └───────────── Retry interval
│ │ │ └────────────────── Refresh interval
│ │ └───────────────────── Serial number
│ └──────────────────────────────────────────── Admin email
└─────────────────────────────────────────────────────────────────── Primary NS| Thành phần | Ý nghĩa |
|---|---|
| Primary NS | Name server chính quản lý zone |
| Admin Email | Email admin (dấu . thay cho @) |
| Serial | Version number, tăng mỗi khi có thay đổi |
| Refresh | Secondary NS check updates sau bao lâu |
| Retry | Nếu refresh fail, thử lại sau bao lâu |
| Expire | Secondary NS ngừng phục vụ nếu không liên lạc được primary |
| Minimum TTL | TTL mặc định cho negative caching |
Đối với bạn (người dùng Route 53):
- NS Record: Cần biết để cấu hình domain registrar
- SOA Record: AWS lo hết - bạn không cần sửa gì cả
Chỉ cần tập trung tạo A, AAAA, CNAME, Alias records!
Loại Hosted Zone
| Loại | Ai có thể query? | Use Case |
|---|---|---|
| Public Hosted Zone | Cả thế giới qua Internet | Website, API công khai |
| Private Hosted Zone | Chỉ trong VPC của bạn | Database, microservices nội bộ |
Public Hosted Zone: Private Hosted Zone:
┌─────────────────────────┐ ┌─────────────────────────┐
│ example.com │ │ internal.myapp.local │
│ (ai cũng query được │ │ (chỉ VPC query được) │
│ từ Internet) │ │ │
│ │ │ │
│ www → 54.231.12.45 │ │ db → 10.0.1.50 │
│ api → 54.231.12.46 │ │ cache → 10.0.2.100 │
└─────────────────────────┘ └─────────────────────────┘
│ │
▼ ▼
Users toàn cầu EC2 trong VPC onlyChi phí Hosted Zone
- $0.50/tháng cho mỗi hosted zone
- 25 hosted zones đầu tiên: $0.50/zone/tháng
- Hosted zone 26 trở đi: $0.10/zone/tháng
Route 53 Resolver cho Hybrid DNS (On-premises va VPC)
Khi workload trong VPC cần resolve domain private của hệ thống on-premises (qua Site-to-Site VPN/Direct Connect), bạn dùng Route 53 Resolver endpoints + forwarding rules.
Khi nào dùng Outbound vs Inbound Endpoint?
| Nhu cầu | Endpoint đúng |
|---|---|
VPC -> on-prem DNS (EC2/app trong VPC cần resolve corp.internal) | Outbound endpoint + forwarding rule |
| On-prem -> AWS private DNS (DNS on-prem cần resolve private hosted zone trong AWS) | Inbound endpoint |
Luồng chuẩn cho bài toán VPC resolve on-prem
EC2/App trong VPC
-> VPC Resolver (VPC+2)
-> Rule forward cho domain on-prem (vd: corp.internal)
-> Route 53 Resolver Outbound Endpoint
-> On-prem DNS server (qua Site-to-Site VPN / DX)
-> Trả kết quả ngược lại về ứng dụngCác bước cấu hình tối thiểu (VPC -> on-prem)
- Tạo Route 53 Resolver outbound endpoint trong VPC.
- Gắn security group cho endpoint, cho phép DNS (UDP/TCP port
53) outbound đến DNS server on-prem. - Tạo Resolver forwarding rule cho domain on-prem (ví dụ
corp.internal) và chỉ định IP DNS server on-prem. - Associate rule với VPC chứa ứng dụng.
Lưu ý bảo mật và vận hành
- Không dùng Private Hosted Zone để "thay thế" DNS on-prem. PHZ chỉ chứa record do Route 53 quản lý trong AWS.
- Dùng ít nhất 2 IP endpoint ở 2 AZ để tăng HA cho Resolver endpoint.
- Giới hạn security group/routing chỉ cho đúng DNS servers on-prem cần thiết.
Record Types
DNS Records = "Danh bạ" với nhiều loại thông tin khác nhau.
Các loại DNS Records phổ biến
| Record Type | Trỏ đến | Use case thực tế |
|---|---|---|
| A | IPv4 | Website: example.com → EC2 |
| AAAA | IPv6 | Website hỗ trợ IPv6 |
| CNAME | Domain khác | www → example.com, CDN |
| MX | Mail server | Nhận email @example.com |
| NS | Name servers | Route 53 quản lý domain |
| TXT | Văn bản | SPF, DKIM, xác minh domain |
| SOA | Zone metadata | Thông tin Hosted Zone (tự động) |
Chi tiết từng loại Record
1️⃣ A Record - Trỏ domain → IPv4
"example.com có địa chỉ IP là gì?"
example.com ──────▶ 54.231.12.45
domain IPv42️⃣ CNAME Record - Alias (Biệt danh)
"www là tên khác của example.com"
www.example.com ──▶ example.com ──▶ 54.231.12.45
biệt danh domain gốc IP3️⃣ MX Record - Mail Exchange
"Email gửi đến @example.com thì đi đâu?"
hello@example.com ──▶ mail.google.com (priority 10)
──▶ mail2.google.com (priority 20, backup)4️⃣ NS Record - Name Server
"Domain này dùng Name Server nào?"
example.com ──▶ ns-123.awsdns-45.com (Route 53)5️⃣ TXT Record - Text
"Ghi chú thông tin cho domain"
example.com ──▶ "v=spf1 include:_spf.google.com ~all"
──▶ "google-site-verification=abc123"Ví dụ thực tế cho 1 website
┌─────────────────────────────────────────────────────────────────┐
│ Hosted Zone: mycompany.com │
│ │
│ Record Type │ Name │ Value │
│ ────────────┼───────────────────┼──────────────────────────────│
│ A │ mycompany.com │ 54.231.12.45 (Load Balancer) │
│ A │ api.mycompany.com │ 54.231.12.46 (API server) │
│ CNAME │ www │ mycompany.com │
│ CNAME │ blog │ myblog.wordpress.com │
│ MX │ mycompany.com │ mail.google.com (Gmail) │
│ TXT │ mycompany.com │ google-site-verification=xxx │
│ NS │ mycompany.com │ ns-xxx.awsdns-xx.com │
└─────────────────────────────────────────────────────────────────┘Nhiều A Records (DNS Round Robin)
Nếu có nhiều A records cùng tên domain, DNS trả về tất cả IPs và client chọn random:
┌─────────────────────────────────────────────────────────────────┐
│ Type: A │ Name: example.com │ Value: 152.42.220.42 │
│ Type: A │ Name: example.com │ Value: 152.42.220.43 │
│ Type: A │ Name: example.com │ Value: 152.42.220.44 │
└─────────────────────────────────────────────────────────────────┘
Query example.com → DNS trả về 3 IPs → Client chọn RANDOM 1
→ Đây gọi là "DNS Round Robin" (Load Balancing đơn giản)
→ Nhược điểm: Không có health check, server chết vẫn có thể được chọn!
→ Production nên dùng Load Balancer thay vì nhiều A records!DNS biết query loại Record nào?
DNS query chỉ định rõ loại record cần lấy - không phải random!
Browser cần IP để kết nối website:
Query: "Cho tôi A record của example.com"
→ DNS trả về: 54.231.12.45
Email client gửi email:
Query: "Cho tôi MX record của example.com"
→ DNS trả về: mail.google.com| Ứng dụng | Query Type | Tại sao? |
|---|---|---|
| Browser (Chrome, Firefox) | A hoặc AAAA | Cần IP để kết nối |
| Email client (Gmail, Outlook) | MX | Cần mail server |
| DNS tools (dig, nslookup) | Bạn chỉ định | Debug |
# Test với dig command
dig A example.com # Query A record
dig MX example.com # Query MX record
dig NS example.com # Query NS record
dig ANY example.com # Query tất cả recordsGiải thích dễ hiểu: A Record vs CNAME
(Ví dụ danh bạ điện thoại)
1️⃣ A Record (Address Record)
Giống như lưu số điện thoại trong danh bạ.
- Tên: Anh Hiệp (
example.com) - Số ĐT: 0901.234.567 (
1.2.3.4) - Hành động: Gọi -> Bấm số luôn.
- Đặc điểm: Đi thẳng đến đích (IP), tốc độ nhanh nhất.
2️⃣ CNAME Record (Canonical Name Record)
Giống như ghi chú Alias/Biệt danh ("Hãy gọi cho...").
- Tên: Sếp Hiệp (
www.example.com) - Ghi chú: "Hãy gọi vào số của Anh Hiệp"
- Hành động: Tìm "Sếp Hiệp" -> Thấy ghi chú -> Tìm "Anh Hiệp" -> Ra số -> Gọi.
- Đặc điểm: Đi lòng vòng 2 bước (Hỏi tên giả -> Ra tên thật -> Mới ra IP).
Zone Apex (Root Domain) là gì?
Zone Apex = Root Domain = Domain không có subdomain phía trước.
Zone Apex (Root Domain)
│
▼
┌───────────────┐
│ example.com │ ← Đây là Zone Apex
└───────┬───────┘
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ www.example │ │ api.example │ │blog.example │ ← Subdomains
│ .com │ │ .com │ │ .com │ (KHÔNG phải Zone Apex)
└─────────────┘ └─────────────┘ └─────────────┘| Domain | Là Zone Apex? |
|---|---|
example.com | ✅ Có |
www.example.com | ❌ Không (subdomain) |
api.example.com | ❌ Không (subdomain) |
Hạn chế chí mạng của CNAME
RFC DNS quy định: Nếu một domain có CNAME record, thì nó KHÔNG ĐƯỢC có bất kỳ record nào khác (NS, MX, TXT, SOA...).
┌─────────────────────────────────────────────────────────────────┐
│ Tại sao CNAME bị "cấm" ở Zone Apex? │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Zone Apex (example.com) BẮT BUỘC phải có: │
│ ├── NS Record (ai quản lý domain này) │
│ ├── SOA Record (metadata zone) │
│ └── Thường có MX Record (nhận email @example.com) │
│ │
│ Nếu đặt CNAME cho example.com: │
│ ├── CNAME sẽ "đá bay" tất cả NS, SOA, MX records │
│ └── → Domain KHÔNG hoạt động được! │
│ │
│ ❌ KHÔNG THỂ: │
│ example.com CNAME myapp.elb.amazonaws.com │
│ example.com NS ns-123.awsdns.com ← BỊ XÓA! │
│ example.com MX mail.google.com ← BỊ XÓA! │
│ │
│ ✅ CÓ THỂ (subdomain không có NS/SOA bắt buộc): │
│ www.example.com CNAME myapp.elb.amazonaws.com │
│ │
└─────────────────────────────────────────────────────────────────┘Giải pháp: Dùng A Record hoặc Alias Record cho Zone Apex.
Alias Records (Route 53 Exclusive)
Alias Record là loại record riêng của AWS Route 53, giải quyết vấn đề "không thể dùng CNAME ở Zone Apex".
Alias là gì? (Hybrid = CNAME + A Record)
Alias KHÔNG PHẢI là A record, KHÔNG PHẢI là CNAME - nó là loại record riêng:
┌─────────────────────────────────────────────────────────────────┐
│ ALIAS = Hybrid! │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Bên trong (cách cấu hình): Giống CNAME │
│ └── Trỏ đến domain: myapp.elb.amazonaws.com │
│ │
│ Bên ngoài (trả về cho client): Giống A RECORD │
│ └── Trả về IP: 54.231.12.45 │
│ │
│ → Alias = "CNAME trá hình thành A record" │
└─────────────────────────────────────────────────────────────────┘Tại sao Alias dùng được ở Zone Apex?
┌─────────────────────────────────────────────────────────────────┐
│ CNAME Flow │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Client query: example.com │
│ │ │
│ ▼ │
│ Route 53 trả về: "example.com CNAME myapp.elb.amazonaws.com" │
│ │ ↑ │
│ │ Client thấy "CNAME" → XÓA NS/SOA! │
│ ▼ │
│ Client query tiếp: myapp.elb.amazonaws.com → 54.231.12.45 │
│ │
│ → 2 LOOKUPS + DNS thấy "CNAME" → ❌ XUNG ĐỘT với NS/SOA │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ ALIAS Flow │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Client query: example.com (type A) │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Route 53 NỘI BỘ (client KHÔNG thấy): │ │
│ │ 1. Biết example.com ALIAS → myapp.elb.amazonaws.com │ │
│ │ 2. Tự động query IP của ELB: 54.231.12.45 │ │
│ │ 3. Trả về cho client như là A RECORD! │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Client nhận: "example.com A 54.231.12.45" │
│ ↑ │
│ Client thấy "A record" → KHÔNG xung đột NS/SOA! │
│ │
│ → 1 LOOKUP + DNS thấy "A record" → ✅ HỢP LỆ │
└─────────────────────────────────────────────────────────────────┘So sánh A vs CNAME vs Alias
| Góc nhìn | A Record | CNAME | Alias |
|---|---|---|---|
| Cấu hình trỏ đến | IP trực tiếp | Domain khác | Domain khác (AWS) |
| Client nhận được | IP | Domain (rồi query tiếp) | IP (1 step) |
| Zone Apex | ✅ OK | ❌ Cấm | ✅ OK |
| Số lookups | 1 | 2 | 1 |
| Chi phí query | Có phí | Có phí | Miễn phí (AWS) |
Khi nào dùng cái nào?
| Trường hợp | Dùng loại gì? | Ví dụ |
|---|---|---|
| Zone Apex trỏ vào AWS Resource | Alias (Bắt buộc) | example.com → ALB |
| Subdomain trỏ vào AWS Resource | Alias (Nên dùng) | www → CloudFront (Free & Nhanh) |
| Trỏ sang dịch vụ NGOÀI AWS | CNAME | blog → github.io |
| Trỏ vào IP tĩnh cụ thể | A Record | server → 1.2.3.4 |
Tóm lại: Alias = "CNAME nói dối là A record" → Client thấy A record nên không xung đột với NS/SOA!
TTL (Time To Live)
TTL = "Thời hạn sử dụng" của một DNS record (tính bằng giây).
Ví dụ: Route 53 trả về: "
example.com=1.2.3.4, TTL = 300". Nghĩa là: "Nhớ địa chỉ này trong 300 giây nhé, sau đó hỏi lại tao."
Ai cache? (Quan trọng!)
Route 53 KHÔNG cache. Route 53 là nguồn gốc (Authoritative DNS), nó giữ thông tin chính thức. Người cache là các trạm trung gian:
┌────────────────────────────────────────────────────────────────────┐
│ AI CACHE? │
│ │
│ ① Browser (Chrome, Firefox...) ✅ CACHE │
│ └── Lưu DNS trong vài phút đến vài giờ │
│ │
│ ② Hệ điều hành (Windows, macOS, Linux) ✅ CACHE │
│ └── OS có DNS Cache riêng │
│ │
│ ③ DNS Resolver (ISP hoặc Google 8.8.8.8) ✅ CACHE │
│ └── Đây là nơi cache NHIỀU NHẤT theo TTL │
│ │
│ ④ Route 53 (Authoritative DNS) ❌ KHÔNG CACHE │
│ └── Đây là NGUỒN GỐC, không cần cache ai cả │
└────────────────────────────────────────────────────────────────────┘TTL hoạt động như thế nào?
Route 53 trả về: example.com = 1.2.3.4, TTL = 300s
│
▼
DNS Resolver lưu vào cache
│
┌───────────────────────┼───────────────────────┐
│ 0s - 300s │ Sau 300s │
│ (Trong TTL) │ (Hết TTL) │
│ │ │
│ Query tiếp theo │ Query tiếp theo │
│ │ │ │ │
│ ▼ │ ▼ │
│ Trả từ cache │ Hỏi lại Route 53 │
│ (NHANH, 1-5ms) │ (CHẬM hơn, 50-200ms) │
└───────────────────────┴───────────────────────┘Trade-off TTL
| TTL | Ưu điểm | Nhược điểm |
|---|---|---|
| Cao (24h) | Ít queries → giảm chi phí, truy cập nhanh (từ cache) | Đổi IP mất cả ngày mới cập nhật xong |
| Thấp (60s) | Thay đổi IP được áp dụng gần như ngay | Nhiều queries → tốn tiền hơn |
Best Practice
- Bình thường: TTL 300s - 3600s.
- Trước khi migrate/đổi IP:
- Vài giờ trước: Hạ TTL xuống 60s.
- Thực hiện đổi IP.
- Sau khi ổn định: Tăng TTL trở lại.
- Alias records: TTL tự động theo AWS resource (không set được).
Routing Policies
Route 53 cung cấp 8 routing policies để điều khiển cách traffic được định tuyến.
Record Types hỗ trợ Routing Policies
| Record Type | Hỗ trợ Routing Policy? | Ghi chú |
|---|---|---|
| A (IPv4) | ✅ Có | Phổ biến nhất |
| AAAA (IPv6) | ✅ Có | |
| CNAME | ✅ Có | Không dùng được ở Zone Apex |
| Alias | ✅ Có | Khuyên dùng (miễn phí, tự động update IP) |
| MX | ✅ Có | Email routing |
| TXT | ✅ Có | |
| NS | ❌ Không | Chỉ Simple routing |
| SOA | ❌ Không | Tự động, không edit |
Alias record được khuyên dùng với Routing Policies vì miễn phí query và tự động cập nhật IP của AWS resources.
1. Simple Routing
Trường hợp cơ bản nhất: 1 domain → 1 hoặc nhiều IP addresses.
example.com
│
└──▶ 54.231.12.45
54.231.12.46 (random selection nếu nhiều values)
54.231.12.47- ❌ Không hỗ trợ health checks
- ✅ Có thể trả về nhiều values (client chọn random)
2. Weighted Routing
Phân phối traffic theo tỷ lệ weight.
example.com
│
│ Weight: 70
├─────────────────────▶ Server A (Production)
│
│ Weight: 20
├─────────────────────▶ Server B (Production)
│
│ Weight: 10
└─────────────────────▶ Server C (Canary/Testing)
→ 70% traffic → A, 20% → B, 10% → CUse cases:
- Load balancing giữa các regions
- Canary deployment (test tính năng mới với % nhỏ users)
- A/B testing
- Blue-green deployment
Công thức tính %:
Traffic % = (Weight của record) / (Tổng tất cả weights) × 100
Ví dụ: Weight A=70, B=20, C=10
Traffic A = 70 / (70+20+10) = 70%3. Latency-based Routing
Định tuyến đến region có latency thấp nhất đến user.
User ở Tokyo User ở Paris
│ │
▼ ▼
┌─────────────────────────────────────────────────────┐
│ Route 53 tra bảng latency │
│ Tokyo → ap-northeast-1: 20ms │
│ Tokyo → eu-west-1: 250ms │
│ Paris → ap-northeast-1: 300ms │
│ Paris → eu-west-1: 15ms │
└─────────────────────────────────────────────────────┘
│ │
▼ ▼
ap-northeast-1 eu-west-1
(Japan) (Ireland)AWS đo latency như thế nào?
AWS KHÔNG đo latency real-time. Thay vào đó, họ dùng bảng latency data đã được tính toán trước:
┌─────────────────────────────────────────────────────────────────┐
│ Cách AWS xác định latency │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1️⃣ AWS đã đo sẵn (cập nhật định kỳ): │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Latency Table (pre-computed) │ │
│ │ │ │
│ │ Vietnam → ap-southeast-1 (Singapore): ~30ms │ │
│ │ Vietnam → us-east-1 (N. Virginia): ~200ms │ │
│ │ Vietnam → eu-west-1 (Ireland): ~250ms │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 2️⃣ Khi user query DNS: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ User query → Route 53 xem IP nguồn (DNS Resolver) │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ Xác định user ở đâu → Tra bảng latency │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ Trả về IP của server có latency thấp nhất │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘| Bước | Mô tả |
|---|---|
| 1. Thu thập data | AWS đo latency từ nhiều điểm trên thế giới đến các AWS Regions |
| 2. Xây dựng latency table | Tạo mapping: Location → Region → Latency |
| 3. Cập nhật định kỳ | Data được refresh thường xuyên (không real-time) |
| 4. Sử dụng IP nguồn | Route 53 dùng IP của DNS resolver để xác định vị trí |
Latency dựa trên IP của DNS Resolver, không phải IP của user!
User ở Vietnam dùng Google DNS (8.8.8.8 - server ở US):
→ Route 53 thấy IP từ US → Có thể trả về server US!
Giải pháp: Dùng DNS resolver gần với bạn (ISP DNS)Lưu ý: Latency-based routing đo network latency, không phải geographic distance.
4. Failover Routing (Active-Passive)
Disaster recovery: Primary → Secondary khi primary fails. Còn gọi là Active-Passive HA.
Health Check
│
▼
example.com ───▶ Primary (Active)
│ │
│ │ UNHEALTHY!
│ ▼
└────────▶ Secondary (Standby) ← Traffic tự động chuyển quaCấu hình:
- Primary record + Health check
- Secondary record (failover target)
┌─────────────────────────────────────────────────────────────────┐
│ Primary healthy? │
│ │ │
│ ├── YES → Trả về Primary IP │
│ │ │
│ └── NO → Trả về Secondary IP │
└─────────────────────────────────────────────────────────────────┘5. Geolocation Routing
Định tuyến dựa trên vị trí địa lý của user.
┌─────────────────────────────────────────────────────────────────┐
│ Route 53 Geolocation │
│ │
│ User từ Vietnam ──────▶ Server Singapore │
│ User từ Japan ──────▶ Server Tokyo │
│ User từ France ──────▶ Server Paris │
│ User từ nơi khác ──────▶ Default Server │
│ (bắt buộc phải có!) │
└─────────────────────────────────────────────────────────────────┘Use cases:
- Phục vụ content theo ngôn ngữ/region
- Tuân thủ regulations (GDPR - data phải ở EU)
- Restricting content distribution
Quan trọng: Luôn tạo Default record để xử lý các locations không match!
6. Geoproximity Routing
Geoproximity Routing = chọn endpoint gần user nhất, nhưng cho phép “bóp/mở vùng phục vụ” bằng bias.
Nó khác Geolocation Routing ở điểm quan trọng:
| Policy | Route theo gì? | Ví dụ |
|---|---|---|
| Geolocation | Theo location rule cố định: quốc gia/châu lục/default | User ở Vietnam → luôn đi Singapore |
| Geoproximity | Theo khoảng cách giữa user và resource | User gần Tokyo hơn Singapore → đi Tokyo |
| Geoproximity + bias | Theo khoảng cách đã được điều chỉnh | Dù gần Tokyo hơn một chút, vẫn có thể kéo traffic về Singapore nếu Singapore có bias dương |
Cách Route 53 quyết định
Với mỗi DNS query, Route 53 ước lượng vị trí của user rồi tính khoảng cách tới từng resource.
Resource có thể là:
- AWS resource: chỉ định bằng AWS Region hoặc Local Zone Group.
- Non-AWS resource: chỉ định bằng latitude/longitude.
Nếu bias = 0, Route 53 chọn resource gần nhất.
User ở Bangkok
Khoảng cách tới Singapore = 1,430 km
Khoảng cách tới Tokyo = 4,600 km
=> Chọn Singapore vì gần hơnBias là gì?
Bias là số từ -99 đến +99 dùng để thay đổi “khoảng cách cảm nhận” của Route 53.
AWS dùng công thức:
Biased distance = actual distance * [1 - (bias / 100)]Ý nghĩa:
- Bias dương: làm endpoint có vẻ gần hơn → vùng phục vụ mở rộng → nhận nhiều traffic hơn.
- Bias âm: làm endpoint có vẻ xa hơn → vùng phục vụ thu hẹp → nhận ít traffic hơn.
Ví dụ AWS đưa ra:
Server A cách user 150 km, bias +50
Server B cách user 100 km, bias 0
A biased distance = 150 * [1 - (50/100)] = 75 km
B biased distance = 100 * [1 - (0/100)] = 100 km
=> Route 53 chọn A, dù khoảng cách thật A xa hơn BNói dễ hiểu:
Không bias:
User ──100km── Server B ✅ gần hơn
User ──150km── Server A
A có bias +50:
User ──100km── Server B
User ── 75km── Server A ✅ Route 53 coi như gần hơnBias không phải phần trăm traffic cố định
Điểm rất dễ nhầm:
Bias +50 không có nghĩa là lấy 50% traffic.
Bias chỉ thay đổi ranh giới địa lý giữa các endpoint. Traffic thực tế thay đổi bao nhiêu phụ thuộc vào:
- Endpoint nằm ở đâu.
- User tập trung ở khu vực nào.
- Endpoint gần nhau hay xa nhau.
- Có nhiều user ở vùng ranh giới hay không.
Ví dụ nếu nhiều user nằm gần ranh giới giữa Singapore và Tokyo, chỉ cần bias nhỏ cũng có thể làm traffic chuyển rất nhiều.
Khi nào dùng Geoproximity?
Dùng khi bạn muốn routing theo địa lý nhưng cần điều chỉnh linh hoạt:
- Region A mạnh hơn Region B, muốn Region A nhận nhiều traffic hơn.
- Muốn dần chuyển traffic từ region cũ sang region mới theo khu vực địa lý.
- Muốn giảm tải một region bằng bias âm.
- Muốn người dùng gần endpoint nào thì đi endpoint đó, nhưng vẫn điều chỉnh được phạm vi.
Khi nào không dùng?
- Muốn chia traffic chính xác 80/20 → dùng Weighted Routing.
- Muốn user ở một quốc gia cố định đi một endpoint cụ thể → dùng Geolocation Routing.
- Muốn route theo latency đo được từ AWS regions → dùng Latency-based Routing.
Yêu cầu: Geoproximity thường được cấu hình qua Route 53 Traffic Flow. Bản đồ visualization của geoproximity chỉ có trong Traffic Flow.
7. IP-based Routing
Định tuyến dựa trên IP address range của client (CIDR blocks).
┌─────────────────────────────────────────────────────────────────┐
│ Client IP │ Target │
├───────────────────────────┼─────────────────────────────────────┤
│ 24.232.0.0/16 │ Server A (Comcast users) │
│ 203.0.113.0/24 │ Server B (Enterprise network) │
│ 10.0.0.0/8 │ Server C (Internal VPN) │
└─────────────────────────────────────────────────────────────────┘Use cases:
- ISP-specific routing
- Enterprise customer routing
- Migrating traffic từ network này sang network khác
8. Multivalue Answer Routing
Trả về nhiều IP addresses (tối đa 8), kết hợp với health checks.
Query: example.com
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ Route 53 trả về tối đa 8 healthy records: │
│ │
│ 54.231.12.45 ✓ Healthy │
│ 54.231.12.46 ✓ Healthy │
│ 54.231.12.47 ✗ Unhealthy (không trả về) │
│ 54.231.12.48 ✓ Healthy │
└─────────────────────────────────────────────────────────────────┘
Client nhận 3 IPs, tự chọn random → load balancing ở client-sideSo sánh với Simple Routing:
- Simple: Không health checks, trả về tất cả values
- Multivalue: Có health checks, chỉ trả về healthy values
Lưu ý: Multivalue Answer KHÔNG phải thay thế cho ELB. Đây là "client-side load balancing" đơn giản.
So sánh Routing Policies
| Policy | HA Pattern | Use Case | Health Check |
|---|---|---|---|
| Simple | - | Đơn giản, 1 resource | ❌ |
| Weighted | Active-Active | Canary, A/B testing | ✅ |
| Latency | Active-Active | Performance tốt nhất | ✅ |
| Failover | Active-Passive | Disaster recovery | ✅ (bắt buộc) |
| Geolocation | Active-Active | Content localization | ✅ |
| Geoproximity | Active-Active | Flexible geo routing | ✅ |
| IP-based | Active-Active | ISP/Network routing | ✅ |
| Multivalue | Active-Active | Client-side LB | ✅ |
Active-Passive = Chỉ 1 server hoạt động, server kia standby (Failover) Active-Active = Tất cả servers cùng hoạt động, chia sẻ traffic (Weighted, Latency, Geo...)
Health Checks
Route 53 Health Checks giám sát sức khỏe của resources và tích hợp trực tiếp với routing policies để tự động loại bỏ unhealthy endpoints.
Health Checks + Routing Policies
| Routing Policy | Hỗ trợ Health Check? | Hành vi khi endpoint unhealthy |
|---|---|---|
| Simple | ❌ Không | Vẫn trả về IP dù server chết |
| Weighted | ✅ Có | Loại endpoint unhealthy khỏi pool |
| Latency | ✅ Có | Chuyển sang region có latency thấp tiếp theo |
| Failover | ✅ Bắt buộc | Chuyển từ Primary → Secondary |
| Geolocation | ✅ Có | Fallback sang location khác hoặc default |
| Geoproximity | ✅ Có | Chuyển sang endpoint gần nhất còn healthy |
| Multivalue | ✅ Có | Chỉ trả về các IP healthy |
| IP-based | ✅ Có | Loại endpoint unhealthy |
┌─────────────────────────────────────────────────────────────────┐
│ Health Check + Weighted Routing │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Cấu hình: │
│ ├── Server A: Weight 50, Health Check ✅ │
│ ├── Server B: Weight 30, Health Check ✅ │
│ └── Server C: Weight 20, Health Check ✅ │
│ │
│ Khi Server B unhealthy: │
│ ├── Route 53 loại Server B khỏi pool │
│ ├── Traffic phân bổ lại: A=71%, C=29% │
│ └── (Công thức: 50/(50+20)=71%, 20/(50+20)=29%) │
│ │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ Health Check + Failover Routing │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ Healthy? ┌──────────────┐ │
│ │ Route53 │ ──────────► │ Primary │ → Trả về Primary IP │
│ └──────────┘ │ └──────────────┘ │
│ │ │
│ Unhealthy? │
│ │ ┌──────────────┐ │
│ └────► │ Secondary │ → Trả về Secondary IP│
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────────────────┐
│ Health Check + Latency Routing │
├───────────────────────────────────────────────────────────────────┤
│ │
│ User ở Vietnam, latency: Singapore 30ms, Tokyo 50ms, Sydney 100ms│
│ │
│ Bình thường: Singapore (30ms) ← Lowest latency │
│ Singapore down: Tokyo (50ms) ← Next lowest còn healthy │
│ │
└───────────────────────────────────────────────────────────────────┘Các loại Health Checks
┌─────────────────────────────────────────────────────────────────┐
│ Route 53 Health Checks │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Endpoint │ │ Calculated │ │ CloudWatch │ │
│ │ Health Check │ │ Health Check │ │ Alarm-based │ │
│ │ │ │ │ │ │ │
│ │ Kiểm tra trực │ │ Tổng hợp nhiều │ │ Dựa trên │ │
│ │ tiếp endpoint │ │ health checks │ │ CloudWatch │ │
│ │ (HTTP/HTTPS/TCP)│ │ con │ │ metrics │ │
│ └─────────────────┘ └─────────────────┘ └─────────────────┘ │
└─────────────────────────────────────────────────────────────────┘1. Endpoint Health Check
Giám sát endpoint qua HTTP, HTTPS, hoặc TCP.
Route 53 Health Checkers (15+ locations)
│
│ HTTP GET /health
▼
┌─────────────────┐
│ Your Server │
│ │
│ Response: │
│ HTTP 200 OK │ ← Healthy nếu 2xx hoặc 3xx
│ "OK" │ ← Có thể check text trong response
└─────────────────┘Cấu hình quan trọng:
| Parameter | Default | Mô tả |
|---|---|---|
| Interval | 30s | Tần suất check (10s = Fast, chi phí cao hơn) |
| Failure Threshold | 3 | Số lần fail liên tiếp để coi là unhealthy |
| Protocol | HTTP | HTTP, HTTPS, TCP |
| Port | 80/443 | Port để kiểm tra |
| Path | / | URL path cho HTTP/HTTPS |
| String Matching | - | Kiểm tra response body chứa text cụ thể |
Điều kiện Healthy:
- HTTP/HTTPS: Response code 2xx hoặc 3xx
- TCP: Connection successful
- String matching: Response body chứa expected string (trong 5120 bytes đầu)
2. Calculated Health Check
Tổng hợp kết quả từ nhiều health checks con.
Parent Health Check
(Calculated)
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Child HC 1 Child HC 2 Child HC 3
(Web server) (API server) (DB server)
│ │ │
▼ ▼ ▼
Healthy? Healthy? Healthy?
Logic conditions:
├── OR: Ít nhất 1 child healthy → Parent healthy
├── AND: Tất cả children healthy → Parent healthy
└── At least N: Ít nhất N children healthy → Parent healthy3. CloudWatch Alarm-based Health Check
Giám sát resources không public thông qua CloudWatch metrics.
Private Resource (không thể access từ Internet)
│
▼
CloudWatch Metric
(CPU, Memory, Custom)
│
▼
CloudWatch Alarm
(Threshold: CPU > 80%)
│
▼
Route 53 Health Check
(Monitors alarm state)Use cases:
- Private resources trong VPC
- DynamoDB throttles
- Custom application metrics
Route 53 + ELB Integration
Best practice: Sử dụng Alias record để trỏ từ domain đến ELB.
Route 53
│
│ Alias record
▼
┌─────────────────────────────────────────────────────────────────┐
│ example.com │
│ │ │
│ Alias → myapp-lb.us-east-1.elb.amazonaws.com │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────┐
│ Load Balancer │
└────────┬────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ EC2 │ │ EC2 │ │ EC2 │
└─────────┘ └─────────┘ └─────────┘Tại sao dùng Alias cho ELB?
- ✅ Hỗ trợ zone apex (
example.com) - ✅ Không tốn phí query
- ✅ Tự động update khi ELB IP thay đổi
Domain Registration
Route 53 có thể đăng ký và quản lý domain names.
Quy trình đăng ký
┌─────────────────────────────────────────────────────────────────┐
│ Domain Registration Flow │
│ │
│ 1. Search domain ───▶ Check availability │
│ │
│ 2. Register domain ───▶ Provide contact info │
│ │
│ 3. Payment ───▶ Annual fee (varies by TLD) │
│ │
│ 4. Verification ───▶ Email verification (required) │
│ │
│ 5. Auto-create ───▶ Hosted Zone created │
│ Hosted Zone │
└─────────────────────────────────────────────────────────────────┘Chi phí (ví dụ)
| TLD | Chi phí/năm |
|---|---|
| .com | $12 |
| .net | $11 |
| .org | $12 |
| .io | $39 |
| .dev | $12 |
Traffic Flow (Visual Editor)
Traffic Flow là công cụ visual để tạo complex routing configurations.
Traffic Flow Visual Editor:
┌─────────────────┐
│ Start Point │
│ example.com │
└────────┬────────┘
│
┌────────▼────────┐
│ Geolocation │
│ Rule │
└────────┬────────┘
│
┌────────────────────┼────────────────────┐
▼ ▼ ▼
Asia-Pacific Europe Americas
│ │ │
▼ ▼ ▼
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Weighted │ │ Weighted │ │ Failover │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
▼ ▼ ▼ ▼ ▼ ▼
Tokyo Singapore Ireland Frankfurt Primary Secondary- Chi phí: $50/month cho mỗi traffic policy record
- Lợi ích: Versioning, tái sử dụng policies
DNSSEC
DNSSEC (DNS Security Extensions) bảo vệ chống lại DNS spoofing attacks.
Không có DNSSEC (DNS Spoofing):
Client Attacker Real DNS
│ │ │
│ "example.com?" │ │
│ ──────────────────────│──────────────────────▶
│ │ │
│ (Intercept!) │ │
│ ◀─────────────────────│ │
│ "IP: 1.2.3.4" │ (fake IP) │
│ (malicious) │ │
▼ │ │
Với DNSSEC:
│ "example.com?" │ │
│ ──────────────────────│──────────────────────▶
│ │ │
│ Response: │ │
│ IP: 54.231.12.45 │ │
│ + Digital Signature │ ← SIGNED! │
│ ◀─────────────────────────────────────────────
│ │
│ Verify signature? │
│ ✓ Valid → Trust responsePricing
| Component | Chi phí |
|---|---|
| Hosted Zone | $0.50/hosted zone/tháng |
| Queries (Standard) | $0.40/1M queries (first 1B) |
| Queries (Latency-based) | $0.60/1M queries |
| Queries (Geo DNS) | $0.70/1M queries |
| Health Checks (basic) | $0.50/health check/tháng |
| Health Checks (HTTPS/String) | $0.75/health check/tháng |
| Health Checks (Fast, 10s) | $1.00/health check/tháng |
| Traffic Flow Policy | $50/policy record/tháng |
Nguồn: Route 53 Pricing
Best Practices
1. Alias over CNAME
✓ LUÔN dùng Alias cho AWS resources
- Miễn phí queries
- Hỗ trợ zone apex
- Auto-update IP
✗ KHÔNG dùng CNAME cho AWS resources
- Tốn phí
- Không dùng được cho zone apex2. Combine Routing Policies
Kết hợp Latency + Weighted:
Latency Routing
│
┌─────────────┴─────────────┐
▼ ▼
US-East-1 EU-West-1
│ │
Weighted 90/10 Weighted 90/10
│ │ │ │
▼ ▼ ▼ ▼
Production Canary Production Canary3. Health Check Strategy
Production Setup:
Primary (Active)
│
├── Health Check (HTTP 200)
│ │
│ └── Unhealthy → Failover
│
▼
Secondary (Standby in different AZ/Region)
│
└── Health Check4. TTL Strategy trước khi thay đổi
Timeline thay đổi IP:
T-24h: Giảm TTL xuống 60s
│
T-0h: Thay đổi IP address
│
T+1h: Xác nhận traffic đã chuyển
│
T+24h: Tăng TTL lên 3600sExam Tips (AWS Certification)
| Keyword trong câu hỏi | Routing Policy |
|---|---|
| "lowest latency" | Latency-based |
| "disaster recovery", "active-passive" | Failover |
| "localized content", "compliance", "restrict by country" | Geolocation |
| "canary deployment", "A/B testing", "gradually shift" | Weighted |
| "expand/shrink traffic region" | Geoproximity với Bias |
| "route based on client IP range" | IP-based |
| "return multiple healthy IPs" | Multivalue Answer |
Route 53 vs API Gateway (Hay nhầm lẫn!)
Cả hai đều có khả năng "routing", nhưng hoạt động ở tầng khác nhau:
| Tiêu chí | Route 53 | API Gateway |
|---|---|---|
| Tầng hoạt động | DNS Level (trước khi kết nối) | Application Level (HTTP/HTTPS) |
| Thời điểm quyết định | Khi browser hỏi "IP là gì?" | Sau khi đã kết nối, khi request đến |
| Nhận biết request | Chỉ biết IP client, location | Biết headers, body, path, token... |
| Phạm vi | Chọn region/server nào | Chọn function/service nào trong server |
Lưu ý: API Gateway là dịch vụ regional. Nếu muốn multi-region, phải tạo API Gateway ở mỗi region và dùng Route 53 để điều phối.
Kiến trúc Multi-Region với Route 53
Active-Active (HA cao nhất)
Route 53 (Latency-based + Health Checks)
│
┌──────────────────┴───────────────────────────┐
▼ ▼
Singapore ✅ Healthy Tokyo ✅ Healthy
┌─────────────────┐ ┌─────────────────┐
│ API Gateway │ │ API Gateway │
│ Lambda/ECS │ │ Lambda/ECS │
│ RDS (Primary) │◀── Sync ──▶ │ RDS (Replica) │
└─────────────────┘ └─────────────────┘
│ │
└────────────── Cả 2 đều nhận traffic ───────────────┘Bình thường:
- User Việt Nam → Singapore (latency thấp hơn)
- User Nhật → Tokyo (latency thấp hơn)
- Cả 2 region cùng hoạt động
Khi Singapore sập:
Route 53 Health Check phát hiện Singapore ❌ Unhealthy
│
▼
TẤT CẢ traffic tự động chuyển về Tokyo ✅
(Không cần thao tác thủ công = HA!)So sánh các mức độ HA
| Kiến trúc | Mô tả | Mức HA |
|---|---|---|
| Single AZ | 1 server, 1 datacenter | ❌ Không HA |
| Multi-AZ (cùng region) | 2+ AZs trong 1 region | ✅ HA cơ bản |
| Active-Passive (2 regions) | 1 region chạy, 1 region standby | ✅✅ HA tốt |
| Active-Active (2+ regions) | Tất cả regions cùng chạy | ✅✅✅ HA cao nhất |
Key insight: "Độc lập" = mỗi region tự chạy được. Chính vì vậy khi 1 region chết, region còn lại vẫn sống và tiếp nhận traffic. Route 53 Health Checks là "người gác cổng" tự động chuyển hướng.
Liên kết
- ELB - Load Balancing
- CloudFront - CDN
- VPC - Networking
- EC2 - Compute instances