Route 53: “Load Balancer Miễn Phí” Mà Bạn Đã Có Sẵn Trong Tay
Khuyến nghị: Nếu bạn chưa nắm rõ DNS hoạt động như thế nào — resolver, authoritative server, record type, TTL — hãy đọc bài DNS hoạt động như thế nào dưới lớp vỏ trước. Bài viết này sẽ dễ hiểu hơn rất nhiều khi bạn đã có nền tảng đó.
Bạn đang trả $16/tháng cho một ALB chỉ để phân phối traffic giữa hai môi trường A/B testing? Hay đang cân nhắc dựng thêm một Load Balancer ở region khác cho Disaster Recovery?
Có một tin vui: bạn đã có sẵn một “Load Balancer” trong tay — và nhiều khả năng bạn đang trả $0.50/tháng cho nó mà chưa khai thác hết. Đó chính là Amazon Route 53.
Về bản chất, Route 53 là một DNS service — hay chính xác hơn là một authoritative DNS server kết hợp domain registrar. Nếu bạn từng mua domain trên Namecheap, GoDaddy, hay dùng DNS của Cloudflare — thì Route 53 đóng vai trò tương tự: nơi bạn quản lý domain và cấu hình các bản ghi DNS (A, CNAME, MX, …). Nó cũng chỉ là một DNS như bao DNS khác: nhận query, tra bảng record, trả về IP.
Nhưng điểm khác biệt lớn: trong khi Namecheap hay GoDaddy chủ yếu trả về IP một cách “cứng nhắc” — record nào thì trả đúng IP đó — thì Route 53 có thể ra quyết định dựa trên trọng số, vị trí địa lý, độ trễ mạng, hay tình trạng sức khỏe của server trước khi chọn IP nào để trả về. Cloudflare cũng có một số tính năng tương tự (Load Balancing, geo-steering), nhưng đó là gói trả phí riêng — còn với Route 53, các routing policy này đã có sẵn trong chi phí cơ bản.
Lúc đó, DNS không còn là danh bạ nữa — nó trở thành một bộ cân bằng tải.
Route 53 cung cấp 8 routing policy cho phép bạn biến DNS resolution thành các chiến lược phân phối traffic khác nhau: từ A/B testing, canary release, blue/green deployment cho đến failover đa vùng. Tất cả đều ở tầng DNS — không cần thêm infrastructure, không cần thay đổi code.
1. Tại sao Route 53 lại là “Load Balancer”?
Hầu hết kỹ sư nghĩ về Load Balancer là ALB hoặc NLB — những dịch vụ hoạt động ở Layer 4/7, ngồi giữa client và server để phân phối request. Nhưng Route 53 hoạt động ở tầng DNS — sớm hơn nhiều trong vòng đời request.
Sự khác biệt cốt lõi:
- Route 53 quyết định TRƯỚC KHI client kết nối — “Bạn nên gọi đến IP nào?”
- ALB/NLB quyết định SAU KHI client đã kết nối — “Request này nên đi đến backend nào?”
Điều này có nghĩa Route 53 không thể làm được những gì ALB làm (path-based routing, SSL termination, sticky session). Nhưng ngược lại, có những bài toán mà Route 53 giải quyết đơn giản hơn, rẻ hơn, và ở phạm vi toàn cầu — điều mà một ALB đơn lẻ không thể.
Mỗi Hosted Zone trên Route 53 đã là một Load Balancer chờ được cấu hình. Bạn chỉ cần chọn đúng routing policy.
2. 8 “Chế Độ” Cân Bằng Tải Của Route 53
| Routing Policy | Cách hoạt động | Khi nào dùng |
|---|---|---|
| Simple | Trả về 1 (hoặc nhiều) giá trị, không logic | Dev/staging, setup đơn giản |
| Weighted | Chia traffic theo tỷ lệ trọng số | A/B testing, canary, blue/green |
| Latency | Chọn region có độ trễ thấp nhất | App global, tối ưu UX |
| Failover | Primary/Secondary, tự chuyển khi lỗi | Disaster Recovery |
| Geolocation | Routing theo quốc gia/châu lục | Nội dung theo vùng, compliance |
| Geoproximity | Routing theo khoảng cách + bias | Mở rộng/thu hẹp vùng phục vụ |
| Multivalue Answer | Trả về tối đa 8 IP khỏe mạnh | Client-side LB cơ bản |
| IP-based | Routing theo CIDR của client | Phân luồng nội bộ/bên ngoài |
Hãy đi sâu vào từng policy:
2.1 Simple Routing — “Mặc định, không cần suy nghĩ”
Đây là chế độ mặc định khi bạn tạo record trên Route 53. Một domain trỏ đến một (hoặc nhiều) IP. Nếu có nhiều IP, Route 53 trả về tất cả theo thứ tự ngẫu nhiên — tương tự DNS round-robin.
Hạn chế: Không có health check. Nếu một server chết, Route 53 vẫn vui vẻ trả về IP đó.
Cấu hình trên AWS Console:
| Record name | Type | Routing policy | Value | TTL |
|---|---|---|---|---|
app.example.com | A | Simple | 10.0.1.100, 10.0.2.100 | 300 |
Dùng khi nào? Môi trường dev/staging, hoặc khi bạn chỉ có một endpoint duy nhất.
2.2 Weighted Routing — “Chia bánh theo phần trăm”
Đây là ngôi sao của bài viết. Weighted Routing cho phép bạn gán trọng số cho từng record, và Route 53 sẽ phân phối traffic theo tỷ lệ tương ứng.
Ví dụ: bạn cần chia traffic cho api.example.com giữa Production (80%) và Canary (20%). Bạn tạo 2 record cùng tên với routing policy = Weighted:
| Record name | Type | Routing policy | Value | Weight | Set ID | TTL | Health check |
|---|---|---|---|---|---|---|---|
api.example.com | A | Weighted | 10.0.1.100 | 80 | production-v1 | 60 | (optional) |
api.example.com | A | Weighted | 10.0.2.100 | 20 | canary-v2 | 60 | (optional) |
Kết quả: 80% DNS query trả về IP của Production, 20% trả về IP của Canary. Đơn giản vậy thôi.
Công thức tính phần trăm:
% traffic = Weight của record / Tổng tất cả weightsNếu bạn đặt weight 0 cho một record, Route 53 sẽ ngừng gửi traffic đến đó — cực kỳ hữu ích khi cần “tắt” một endpoint mà không xóa record.
Mẹo: Weight không nhất thiết phải cộng lại thành 100. Route 53 tự tính tỷ lệ. Weight 3 và 7 cho kết quả giống 30 và 70.
2.3 Latency-based Routing — “Ai gần thì đến”
Route 53 duy trì một bảng dữ liệu về độ trễ mạng giữa các vùng AWS và vị trí của người dùng. Khi nhận DNS query, nó trả về IP ở region có latency thấp nhất.
Khác với Geolocation (routing theo địa lý cứng), Latency-based routing quan tâm đến tốc độ thực tế. Một user ở Việt Nam có thể được route đến Tokyo thay vì Singapore nếu đường truyền đến Tokyo nhanh hơn tại thời điểm đó.
| Record name | Type | Routing policy | Value | Region | Set ID | TTL | Health check |
|---|---|---|---|---|---|---|---|
app.example.com | A | Latency | 10.0.1.100 | ap-southeast-1 | singapore | 60 | hc-singapore |
app.example.com | A | Latency | 10.0.2.100 | ap-northeast-1 | tokyo | 60 | hc-tokyo |
app.example.com | A | Latency | 10.0.3.100 | us-east-1 | virginia | 60 | hc-virginia |
User ở Việt Nam sẽ tự động được route đến Singapore hoặc Tokyo — tùy region nào có latency thấp hơn tại thời điểm query.
Dùng khi nào? Ứng dụng global cần tối ưu thời gian phản hồi cho user ở nhiều khu vực.
2.4 Failover Routing — “Phòng thủ thảm họa”
Failover routing hoạt động theo mô hình Active-Passive: bạn chỉ định một Primary và một Secondary record. Route 53 liên tục kiểm tra sức khỏe của Primary qua health check. Khi Primary “ngã”, traffic tự động chuyển sang Secondary.
| Record name | Type | Routing policy | Failover type | Value | Set ID | TTL | Health check |
|---|---|---|---|---|---|---|---|
app.example.com | A | Failover | Primary | 10.0.1.100 | primary-us-east-1 | 60 | hc-primary (bắt buộc) |
app.example.com | A | Failover | Secondary | 10.0.2.100 | secondary-eu-west-1 | 60 | hc-secondary (khuyến nghị) |
Cấu hình Health Check cho Primary:
| Protocol | Endpoint | Port | Path | Request interval | Failure threshold |
|---|---|---|---|---|---|
| HTTPS | 10.0.1.100 | 443 | /health | 30 seconds | 3 |
Với health check interval 30 giây và threshold 3 lần, Route 53 phát hiện lỗi trong khoảng 60–90 giây. Kết hợp TTL thấp (60s), hầu hết client sẽ chuyển sang endpoint dự phòng trong 2–3 phút.
Hãy lưu ý rằng đây là chiến lược cho active-passive pattern, nghĩa là traffic chỉ được xử lý bởi primary, và chỉ được chuyển hướng đến secondary khi primary xảy ra sự cố.
2.5 Geolocation & Geoproximity — “Người Việt xem server Việt”
Geolocation routing theo ranh giới địa lý cứng: quốc gia, bang, hoặc châu lục. User ở Việt Nam → server Singapore. User ở Đức → server Frankfurt. Không có ngoại lệ.
| Record name | Type | Routing policy | Location | Value | Set ID | TTL |
|---|---|---|---|---|---|---|
app.example.com | A | Geolocation | Vietnam | 10.0.1.100 (Singapore) | vietnam-to-sg | 300 |
app.example.com | A | Geolocation | Europe | 10.0.2.100 (Frankfurt) | europe-to-fra | 300 |
app.example.com | A | Geolocation | Default | 10.0.3.100 (US) | default-us | 300 |
Quan trọng: Luôn tạo record Default — nếu không, user ở quốc gia chưa được map sẽ nhận response NXDOMAIN (không tìm thấy domain).
Geoproximity tinh vi hơn: routing theo khoảng cách vật lý, nhưng có thêm tham số bias cho phép “kéo giãn” hoặc “thu hẹp” vùng phục vụ của một resource. Đặt bias dương để mở rộng — hữu ích khi một region đang có dư tải và muốn nhận thêm traffic từ vùng lân cận.
| Record name | Type | Routing policy | Region | Value | Bias | Set ID |
|---|---|---|---|---|---|---|
app.example.com | A | Geoproximity | ap-southeast-1 | 10.0.1.100 | +25 (mở rộng) | singapore |
app.example.com | A | Geoproximity | ap-northeast-1 | 10.0.2.100 | 0 (mặc định) | tokyo |
Với bias +25 cho Singapore, vùng phục vụ của Singapore sẽ “kéo giãn” ra — thu hút thêm traffic từ các khu vực lân cận mà bình thường sẽ route đến Tokyo.
Dùng khi nào? Geolocation cho compliance (GDPR, data residency). Geoproximity cho tối ưu tải linh hoạt.
2.6 Multivalue Answer — “Round-robin có sức khỏe”
Giống Simple Routing nhưng có health check. Route 53 trả về tối đa 8 IP khỏe mạnh cho mỗi query. Client chọn ngẫu nhiên một IP để kết nối.
Khác với Simple Routing ở chỗ: nếu một server chết, Route 53 sẽ loại IP đó khỏi danh sách trả về. Đây là dạng client-side load balancing cơ bản nhất.
Bạn tạo nhiều record riêng biệt, mỗi record trỏ đến một IP và gắn health check:
| Record | Value | Set ID | Health check |
|---|---|---|---|
app.example.com | 10.0.1.100 | server-1 | hc-server-1 |
app.example.com | 10.0.1.101 | server-2 | hc-server-2 |
app.example.com | 10.0.1.102 | server-3 | hc-server-3 |
app.example.com | 10.0.1.103 | server-4 | hc-server-4 |
Tất cả đều có Routing policy = Multivalue answer, TTL = 60. Khi server-2 chết và health check fail, Route 53 tự động loại 10.0.1.101 khỏi response — client chỉ nhận được 3 IP còn lại.
Lưu ý: Multivalue Answer không phải thay thế cho ALB/NLB. Nó chỉ phù hợp cho các hệ thống đơn giản cần một lớp health check ở tầng DNS.
2.7 IP-based Routing — “Biết khách từ đâu đến”
Routing dựa trên CIDR block của địa chỉ IP client. Bạn định nghĩa bảng ánh xạ: dải IP nào → endpoint nào.
Bước 1: Tạo CIDR collection và CIDR block trên Route 53:
| CIDR Collection | CIDR Block | Location Name |
|---|---|---|
my-company | 10.0.0.0/8 | internal-network |
my-company | 203.0.113.0/24 | isp-a |
my-company | 198.51.100.0/24 | isp-b |
Bước 2: Tạo record với IP-based routing:
| Record name | Type | Routing policy | CIDR location | Value | Set ID | TTL |
|---|---|---|---|---|---|---|
api.example.com | A | IP-based | internal-network | 10.0.1.100 | internal | 60 |
api.example.com | A | IP-based | isp-a | 10.0.2.100 | isp-a | 60 |
api.example.com | A | IP-based | Default | 10.0.3.100 | default | 60 |
Traffic từ dải IP nội bộ công ty (10.0.0.0/8) route đến internal API, ISP-A route đến CDN gần nhất, còn lại route đến default endpoint.
Dùng khi nào? Phân luồng traffic doanh nghiệp, tối ưu theo ISP, hoặc chặn traffic từ dải IP nhất định.
3. Thực Chiến — 3 Kịch Bản Phổ Biến
3.1 A/B Testing với Weighted Routing
Bạn muốn thử nghiệm phiên bản mới của API trên 20% user? Tạo hai weighted record:
| Record name | Type | Routing policy | Value | Weight | Set ID | TTL |
|---|---|---|---|---|---|---|
api.example.com | A | Weighted | 10.0.1.100 | 80 | production-v1 | 60 |
api.example.com | A | Weighted | 10.0.2.100 | 20 | canary-v2 | 60 |
Sau đó bạn dần thay đổi weight theo lộ trình canary:
- Khởi đầu: Weight 95/5 — chỉ 5% traffic đến phiên bản mới
- Quan sát: Monitor error rate, latency trong 30 phút
- Tăng dần: 80/20 → 50/50 → 20/80
- Hoàn tất: 0/100 — chuyển hoàn toàn sang phiên bản mới
Quan trọng: Đặt TTL thấp (60s) để thay đổi weight có hiệu lực nhanh. TTL cao đồng nghĩa client sẽ cache IP cũ lâu hơn.
3.2 Blue/Green Deployment
Blue/Green đơn giản hơn canary: hai môi trường, chuyển đổi ngay lập tức.
Bước 1: Cả hai môi trường đều sẵn sàng. Traffic 100% ở Blue.
| Record name | Type | Routing policy | Value | Weight | Set ID | TTL |
|---|---|---|---|---|---|---|
app.example.com | A | Weighted | 10.0.1.50 (Blue) | 100 | blue | 60 |
app.example.com | A | Weighted | 10.0.2.50 (Green) | 0 | green | 60 |
Bước 2: Flip — chuyển Blue weight về 0, Green weight lên 100.
| Record name | Type | Routing policy | Value | Weight | Set ID | TTL |
|---|---|---|---|---|---|---|
app.example.com | A | Weighted | 10.0.1.50 (Blue) | 0 | blue | 60 |
app.example.com | A | Weighted | 10.0.2.50 (Green) | 100 | green | 60 |
Bước 3: Nếu có vấn đề, flip ngược lại trong vài giây. Rollback chỉ là thay đổi weight.
So sánh: Blue/Green bằng Route 53 không cần tạo thêm ALB hay Target Group. Chỉ cần thay đổi DNS record — zero infrastructure overhead.
3.3 Multi-Region DR với Failover + Latency
Kịch bản nâng cao: kết hợp hai routing policy bằng cách sử dụng Alias record.
Tầng 1 — Latency routing cho internal.example.com (chọn region gần nhất):
| Record name | Type | Routing policy | Value | Region | Set ID | TTL | Health check |
|---|---|---|---|---|---|---|---|
internal.example.com | A (Alias) | Latency | ALB us-east-1 | us-east-1 | us-east | 60 | hc-us-east |
internal.example.com | A (Alias) | Latency | ALB eu-west-1 | eu-west-1 | eu-west | 60 | hc-eu-west |
Tầng 2 — Failover routing cho app.example.com (DR khi cả hai region chính sập):
| Record name | Type | Routing policy | Failover type | Value | Set ID | TTL | Health check |
|---|---|---|---|---|---|---|---|
app.example.com | A (Alias) | Failover | Primary | internal.example.com | primary | 60 | hc-primary |
app.example.com | A (Alias) | Failover | Secondary | ALB ap-southeast-1 | dr-singapore | 60 | hc-dr |
Khi cả us-east-1 và eu-west-1 đều hoạt động: user được route đến region gần nhất (qua tầng Latency). Khi cả hai “ngã”: traffic tự động chuyển sang DR site ở Singapore (qua tầng Failover).
4. Giới Hạn — Khi Nào Route 53 KHÔNG Phải Load Balancer
Route 53 mạnh mẽ, nhưng không phải thần dược. Hiểu rõ giới hạn để tránh dùng sai:
-
DNS Caching / TTL: Dù bạn đặt TTL = 60s, nhiều DNS resolver cache lâu hơn quy định. Một số ứng dụng (đặc biệt Java với infinite default TTL) cache vĩnh viễn. Thay đổi traffic không bao giờ tức thì — luôn tính bằng phút, không phải giây.
-
Không có Sticky Session: Mỗi DNS query là độc lập. Không có cách nào bảo đảm user X luôn về server Y qua DNS. Nếu cần session affinity, bạn phải dùng ALB.
-
Không đọc được nội dung Request: Route 53 chỉ biết “ai đang hỏi” (IP của resolver), không biết URL path, header, cookie hay body. Routing theo
/api/v1vs/api/v2là việc của ALB. -
Cân bằng ở mức Query, không phải Request: Một client resolve DNS một lần, rồi gửi hàng nghìn request đến cùng IP đó cho đến khi TTL hết. Route 53 không kiểm soát được traffic sau bước DNS resolution.
-
Failover không tức thì: Health check interval (10–30s) × failure threshold (1–3 lần) + TTL propagation = vài phút downtime trong kịch bản failover. So sánh: ALB chuyển traffic trong vài giây.
-
Client behavior không đồng nhất: Trình duyệt, OS, thư viện HTTP — mỗi nơi cache DNS theo cách khác nhau. Bạn không kiểm soát được hết.
-
Không hỗ trợ dynamic registration: ALB tự động phát hiện instance mới khi Auto Scaling Group scale out — bạn thêm 10 instance, ALB lập tức phân phối traffic đến cả 10. Route 53 không làm được điều này. Mỗi record phải được tạo hoặc cập nhật thủ công (hoặc qua API/CLI). Nếu hệ thống của bạn cần horizontal scaling linh hoạt — thêm/bớt instance liên tục theo tải — Route 53 đơn giản là không phù hợp để đứng một mình. Bạn cần ALB/NLB phía sau để xử lý việc phân phối trong cụm instance.
Nguyên tắc: Nếu bạn cần quyết định dựa trên nội dung request → dùng ALB. Nếu chỉ cần quyết định gửi user đến đâu trước khi kết nối → Route 53 là đủ.
5. Route 53 vs ALB vs NLB — “Tam Giác Vàng”
Nếu bạn đã đọc bài ALB hay NLB, đây là mảnh ghép còn lại để hoàn thiện bức tranh:
| Tiêu chí | Route 53 | ALB | NLB |
|---|---|---|---|
| Tầng hoạt động | DNS (trước kết nối) | Layer 7 (HTTP) | Layer 4 (TCP/UDP) |
| Chi phí cơ bản | ~$0.50/zone/tháng | ~$16/tháng | ~$16/tháng |
| Độ chi tiết | Mỗi DNS query | Mỗi HTTP request | Mỗi TCP connection |
| Health check | Có (tính phí riêng) | Tích hợp sẵn | Tích hợp sẵn |
| Sticky session | Không | Có | Có |
| SSL termination | Không | Có | Có (TLS) |
| Path-based routing | Không | Có | Không |
| Weighted traffic | Có | Có (target group) | Không |
| Tốc độ failover | Phút (TTL) | Giây | Giây |
| Phạm vi | Global | Regional | Regional |
6. Kết Hợp Route 53 + ALB — “Combo Hoàn Hảo”
Trong thực tế, Route 53 và ALB/NLB không loại trừ nhau — chúng bổ sung cho nhau ở hai tầng khác nhau.
Mô hình kinh điển:
- Route 53 (Tầng Global): Latency-based hoặc Geolocation routing để đưa user đến region gần nhất
- ALB (Tầng Regional): Path-based routing để phân phối request đến đúng microservice trong region đó
Với kiến trúc này:
- Route 53 xử lý phân phối global (user Việt Nam → Singapore, user Mỹ → Virginia)
- ALB xử lý phân phối local (
/api→ API service,/web→ Web service) - Failover routing ở tầng DNS bảo vệ khi cả một region “sập”
Đây là mô hình mà hầu hết hệ thống production quy mô lớn đều sử dụng — và chi phí Route 53 trong combo này gần như không đáng kể so với ALB.
7. Route 53 Resolver — Hybrid DNS Giữa AWS Và On-Premises
Đến đây bạn có thể nghĩ Route 53 chỉ xoay quanh chuyện phân phối traffic. Nhưng nó còn một vai trò khác, ít được nhắc tới mà lại xuất hiện rất nhiều trong đề thi SAA: phân giải DNS trong môi trường hybrid — khi một phần hệ thống nằm trên AWS, phần còn lại nằm ở trung tâm dữ liệu (data center) của chính bạn.
Mỗi VPC khi được tạo ra đã có sẵn một Route 53 Resolver — một DNS resolver nội bộ luôn nằm ở .2. Nó chịu trách nhiệm phân giải tên miền cho mọi tài nguyên bên trong VPC: từ bản ghi trong Private Hosted Zone (ví dụ aws.private) cho đến tên DNS nội bộ của EC2.
Phía trung tâm dữ liệu của bạn cũng có hệ thống DNS riêng, phục vụ các tên nội bộ như onpremise.private. Hai bên được nối với nhau qua VPN hoặc Direct Connect.
7.1 Vấn Đề: Hai “Thế Giới” DNS Không Nói Chuyện Với Nhau
Sau khi nối VPN hoặc Direct Connect, mạng đã thông — EC2 ping được server on-premises theo IP, và ngược lại. Nhưng DNS thì chưa. Lý do: mỗi bên có một hệ thống DNS riêng (authoritative riêng), và theo mặc định không bên nào biết về vùng tên miền của bên kia.
- EC2 trong VPC hỏi
web.onpremise.private?: Route 53 Resolver không có bản ghi này, cũng không biết phải hỏi ai, nên trả về lỗi. - DNS server on-premises hỏi
app.aws.private?: nó không thể nhìn thấy Private Hosted Zone (vốn chỉ phân giải được từ bên trong VPC), nên cũng trả về lỗi.
Kết quả: hai hệ thống nằm cạnh nhau, mạng đã thông, nhưng vẫn phải gọi nhau bằng địa chỉ IP thô thay vì tên miền. Route 53 Resolver Endpoint sinh ra để bắc cây cầu DNS này. Có hai loại endpoint, mỗi loại mở một chiều, và bạn dùng loại nào tùy theo chiều mình cần.
Lưu ý: Cả hai loại endpoint đều yêu cầu sẵn có kết nối hybrid (VPN hoặc Direct Connect). Endpoint chỉ chuyển tiếp câu hỏi DNS — phần kết nối mạng bên dưới vẫn do VPN hoặc Direct Connect đảm nhiệm.
7.2 Inbound Endpoint — Để On-Premises Hỏi Được AWS
Inbound Endpoint cho phép DNS server on-premises chuyển tiếp câu hỏi vào trong AWS, nhờ đó on-premises phân giải được các tên riêng tư của AWS (bản ghi trong Private Hosted Zone, tên DNS nội bộ của EC2).
Luồng đi của một câu hỏi app.aws.private? xuất phát từ on-premises:
- DNS server on-premises được cấu hình forward mọi câu hỏi cho vùng
aws.privateđến địa chỉ IP của Inbound Endpoint. - Câu hỏi đi qua VPN/Direct Connect, đến Inbound Endpoint nằm trong VPC của bạn.
- Inbound Endpoint chuyển câu hỏi cho Route 53 Resolver.
- Resolver tra trong Private Hosted Zone, tìm thấy bản ghi và trả địa chỉ IP ngược về on-premises.
Inbound Endpoint thực chất là một tập ENI nằm trong subnet của bạn, mỗi ENI có một IP cố định để DNS on-premises trỏ tới:
| Thuộc tính | Giá trị ví dụ |
|---|---|
| Endpoint type | Inbound |
| VPC | vpc-aws-private (VPC chứa Private Hosted Zone) |
| IP addresses | 10.0.1.10 (AZ a), 10.0.2.10 (AZ b) |
| Security group | Cho phép cổng 53 (TCP và UDP) từ dải IP on-premises |
Trên DNS server on-premises, bạn tạo một quy tắc chuyển tiếp: với tên miền aws.private thì hỏi 10.0.1.10 và 10.0.2.10.
7.3 Outbound Endpoint + Resolver Rules — Để AWS Hỏi Được On-Premises
Outbound Endpoint là chiều ngược lại: nó cho phép Route 53 Resolver chuyển tiếp câu hỏi ra ngoài, đến DNS server on-premises, nhờ đó tài nguyên trong AWS phân giải được các tên riêng tư của on-premises.
Điểm khác biệt then chốt so với inbound: chiều outbound cần một Resolver rule để biết tên miền nào thì chuyển đi đâu. Nếu không có rule, Resolver vẫn xử lý câu hỏi theo cách mặc định (DNS công khai) và sẽ không tìm thấy onpremise.private.
Luồng đi của một câu hỏi web.onpremise.private? xuất phát từ EC2:
- EC2 hỏi Route 53 Resolver (ở địa chỉ VPC+2) như bình thường.
- Resolver thấy tên miền khớp một forwarding rule (
onpremise.private), nên chuyển câu hỏi cho Outbound Endpoint. - Outbound Endpoint gửi câu hỏi qua VPN/Direct Connect đến DNS server on-premises.
- DNS on-premises phân giải và trả địa chỉ IP ngược về EC2.
Cấu hình một forwarding rule cho vùng on-premises:
| Thuộc tính | Giá trị ví dụ |
|---|---|
| Rule type | Forward |
| Domain name | onpremise.private |
| Target IPs | 192.168.0.10, 192.168.0.11 (DNS on-premises) |
| Outbound endpoint | rslvr-out-abc123 |
| Associated VPCs | vpc-aws-private |
Mẹo phân biệt chiều: nhìn theo hướng câu hỏi DNS.
- Câu hỏi đi vào AWS (on-premises hỏi tên của AWS): Inbound
- Câu hỏi đi ra khỏi AWS (AWS hỏi tên của on-premises): Outbound
7.4 High Availability & Chia Sẻ Cross-Account (AWS RAM)
Vì endpoint được tạo từ các ENI nằm trong subnet, tính sẵn sàng của nó phụ thuộc vào số Availability Zone mà bạn trải ra. AWS yêu cầu mỗi endpoint phải có ít nhất hai địa chỉ IP nằm ở hai AZ khác nhau. Nếu một AZ gặp sự cố, ENI ở AZ còn lại vẫn tiếp tục phân giải DNS — đừng dồn cả hai IP vào một AZ.
Trong tổ chức nhiều tài khoản, bạn không cần dựng endpoint và rule riêng cho từng tài khoản. Các forwarding rule có thể được chia sẻ qua AWS RAM: một tài khoản mạng trung tâm (networking account) sở hữu Outbound Endpoint và các rule, rồi chia sẻ rule cho các tài khoản ứng dụng. Mỗi tài khoản chỉ cần liên kết rule với VPC của mình là dùng được — mô hình hub-and-spoke quen thuộc cho DNS.
7.5 Trên Đề Thi SAA
Đề thi hiếm khi hỏi lý thuyết suông; thay vào đó nó mô tả một kịch bản hybrid và bắt bạn chọn đúng loại endpoint. Mẹo: xác định chiều của câu hỏi DNS.
Cheat sheet:
- On-premises cần phân giải tên riêng tư của AWS: dùng Inbound Endpoint
- AWS cần phân giải tên riêng tư của on-premises: dùng Outbound Endpoint kèm forwarding rule
- Cần cả hai chiều: dựng cả hai endpoint
Một kịch bản kinh điển: “Công ty nối data center vào AWS qua Direct Connect. EC2 cần phân giải hostname on-premises, đồng thời server on-premises cần phân giải hostname trong Private Hosted Zone. Giải pháp ít vận hành nhất?” Đáp án là dựng cả inbound lẫn outbound endpoint kèm forwarding rule — không cần tự dựng và bảo trì DNS server trên EC2.
Lời kết
Route 53 không phải là thay thế cho ALB hay NLB — nó là tầng bổ sung mà nhiều team đang bỏ qua. Với $0.50/tháng cho mỗi hosted zone, bạn có trong tay:
- A/B testing chỉ bằng cách thay đổi weight
- Blue/Green deployment không cần thêm infrastructure
- Multi-region failover tự động với health check
- Latency-based routing cho ứng dụng global
“Tam giác vàng” cho load balancing trên AWS: Route 53 cho steering toàn cầu, ALB cho routing thông minh, NLB cho tốc độ thuần túy. Hiểu khi nào dùng cái nào — đó mới là kỹ năng thật sự.
Bạn đang sử dụng Route 53 cho kịch bản nào? Hãy chia sẻ bên dưới!