Routing Policies
Routing Policies
- Xác định cách Route 53 phản hồi các truy vấn DNS.
- Đừng nhầm lẫn với từ “Routing”
- Nó không giống với routing của Load Balancer – vốn thực sự route traffic.
- DNS không route traffic, nó chỉ phản hồi các truy vấn DNS.
- Route 53 hỗ trợ các chính sách định tuyến sau:
- Simple
- Weighted
- Failover
- Latency-based
- Geolocation
- Multi-Value Answer
- Geoproximity (sử dụng tính năng Route 53 Traffic Flow)
Routing Policies – Simple
- Thường dùng để route traffic đến một tài nguyên duy nhất
- Có thể chỉ định nhiều giá trị trong cùng một bản ghi
- Nếu có nhiều giá trị được trả về, client sẽ chọn ngẫu nhiên một giá trị
- Khi sử dụng Alias, chỉ được phép chỉ định một tài nguyên AWS duy nhất
- Không thể kết hợp với Health Checks

Routing Policies – Weighted
- Kiểm soát tỷ lệ (%) request được gửi đến từng tài nguyên cụ thể
- Gán cho mỗi bản ghi DNS một trọng số tương đối:
traffic (%) = (Trọng số của bản ghi cụ thể) / (Tổng trọng số của tất cả bản ghi)
→ Trọng số không bắt buộc phải cộng lại thành 100
- Các bản ghi DNS phải cùng tên và cùng loại (ví dụ: cùng là A hoặc CNAME)
- Có thể kết hợp với Health Checks
- Use cases điển hình:
- Load balancing giữa các region
- Triển khai thử nghiệm version mới của ứng dụng
- Gán trọng số bằng 0 cho một bản ghi → ngưng gửi traffic đến tài nguyên đó
- Nếu tất cả bản ghi đều có trọng số bằng 0, thì Route 53 sẽ chia đều traffic giữa các bản ghi đó

Routing Policies – Latency-based
- Chuyển hướng request đến tài nguyên có độ trễ thấp nhất gần với người dùng
- Rất hữu ích trong trường hợp độ trễ là yếu tố ưu tiên hàng đầu
- Độ trễ được xác định dựa trên lưu lượng mạng thực tế giữa người dùng và các Region của AWS
- Ví dụ: người dùng tại Đức có thể được chuyển hướng sang US nếu route đó có độ trễ thấp hơn
- Có thể kết hợp với Health Check, hỗ trợ khả năng failover

Routing Policies – Failover
- Client → Gửi DNS Requests (Yêu cầu phân giải tên miền) đến Amazon Route 53
- Amazon Route 53 thực hiện Health Check (bắt buộc) tới EC2 Instance (Primary)
- Nếu EC2 Instance (Primary) không phản hồi (tức là bị lỗi), Route 53 sẽ Failover (chuyển đổi) sang EC2 Instance (Secondary – Disaster Recovery)

Routing Policies – Geolocation
- Khác với định tuyến dựa trên độ trễ (Latency-based)!
- Chính sách định tuyến này dựa trên vị trí của người dùng
- Có thể chỉ định vị trí theo châu lục, quốc gia, hoặc bang của Mỹ
(nếu có sự trùng lặp, thì sẽ ưu tiên chọn vị trí cụ thể nhất) - Nên tạo một bản ghi "Default" (mặc định) (để xử lý trường hợp không khớp với bất kỳ vị trí nào)
- Trường hợp sử dụng:
- Cá nhân hóa nội dung website theo khu vực
- Hạn chế phân phối nội dung theo vùng
- Cân bằng tải (Load Balancing), v.v.
- Có thể kết hợp với Health Check

Routing Policies – Geoproximity
- Định tuyến lưu lượng truy cập đến tài nguyên của bạn dựa trên vị trí địa lý của người dùng và tài nguyên.
- Có khả năng chuyển hướng thêm lưu lượng đến các tài nguyên dựa trên độ lệch (bias) được xác định.
- Để thay đổi kích thước vùng địa lý, chỉ định giá trị bias như sau:
- Mở rộng (từ 1 đến 99): nhiều lưu lượng hơn sẽ được chuyển đến tài nguyên
- Thu hẹp (từ -1 đến -99): ít lưu lượng hơn sẽ được chuyển đến tài nguyên
- Tài nguyên có thể là:
- Tài nguyên AWS (chỉ định vùng AWS)
- Tài nguyên không thuộc AWS (chỉ định theo kinh độ và vĩ độ)
- Bạn bắt buộc phải sử dụng Route 53 Traffic Flow (chế độ nâng cao) để dùng được tính năng này.

Giải thích cơ chế hoạt động:
- Theo mặc định (bias = 0), người dùng sẽ được định tuyến đến region gần họ nhất về mặt địa lý.
- Nhưng ở đây, region
us-east-1được gán bias +50, tức là nó được "nở rộng" vùng ảnh hưởng địa lý → kéo ranh giới định tuyến về phía Tây.
=> Kết quả: những user đáng ra gần trung tâm sẽ bị kéo sang us-east-1 vì bias khiến us-east-1 được ưu tiên nhận traffic nhiều hơn.
Routing Policies – IP-based Routing
- Định tuyến dựa trên địa chỉ IP của client.
- Bạn cung cấp một danh sách các CIDR cho các client của mình và ánh xạ đến các endpoint/vị trí tương ứng
(mapping IP người dùng → endpoint). - Trường hợp sử dụng: Tối ưu hiệu năng, giảm chi phí mạng...
- Ví dụ: định tuyến người dùng từ một ISP cụ thể đến một endpoint cụ thể.

Giải thích luồng hoạt động:
- User A có địa chỉ IP là
203.0.113.56.- Địa chỉ IP này nằm trong subnet CIDR
203.0.113.0/24, nên được ánh xạ vào location-1. - Khi User A thực hiện truy vấn DNS cho
example.com, Route 53 sẽ kiểm tra IP này khớp với CIDR nào → tìm thấy khớp với location-1. - Route 53 trả về bản ghi DNS gắn với
location-1: IP 1.2.3.4 (đi đến EC2 Instance ở bên phải sơ đồ).
=> User A sẽ được định tuyến đến EC2 instance có IP 1.2.3.4.
- Địa chỉ IP này nằm trong subnet CIDR
- User B có địa chỉ IP là
200.5.4.100.- Địa chỉ IP này thuộc subnet
200.5.4.0/24, ánh xạ vào location-2. - Khi User B truy cập
example.com, Route 53 kiểm tra và nhận ra IP nằm trong CIDR của location-2. - Route 53 trả về bản ghi DNS tương ứng với location-2: IP 5.6.7.8 (EC2 instance ở bên trái sơ đồ).
=> User B sẽ được định tuyến đến EC2 instance có IP 5.6.7.8.
- Địa chỉ IP này thuộc subnet
Routing Policies – Multi-Value
Multi-Value routing policy thường được sử dụng khi bạn muốn có một dạng client-side load balancing cơ bản bằng DNS – nghĩa là trả về nhiều IP để client tự chọn, thường là chọn ngẫu nhiên. Đây không phải là Load Balancer thực sự, mà chỉ là trả về danh sách nhiều endpoint.
- Sử dụng khi cần định tuyến traffic đến nhiều tài nguyên.
- Route 53 sẽ trả về nhiều giá trị/tài nguyên cho cùng một truy vấn DNS.
- Có thể kết hợp với Health Checks (chỉ trả về giá trị của các tài nguyên đang “healthy”).
- Tối đa 8 bản ghi “healthy” sẽ được trả về cho mỗi truy vấn Multi-Value.
- Multi-Value không thay thế cho việc sử dụng ELB (Elastic Load Balancer)

Dưới góc độ kỹ thuật, Multi-Value Routing Policy và Load Balancer (ELB) đều giúp phân phối lưu lượng, nhưng cách làm, tính năng và mục tiêu của chúng khác nhau rõ rệt. Dưới đây là bảng so sánh chi tiết:
| Tiêu chí | Multi-Value Routing Policy (Route 53) | Load Balancer (ELB - Elastic Load Balancer) |
|---|---|---|
| Cơ chế hoạt động | DNS trả về nhiều IP (tối đa 8 bản ghi “healthy”), client sẽ chọn 1 IP ngẫu nhiên để kết nối | Load Balancer đứng trung gian, nhận request và forward đến backend instance |
| Layer hoạt động | DNS layer (L3 - trước khi client gửi request) | Application/Transport Layer (L4 - L7) |
| Health Check | Có, nhưng chỉ để loại bỏ IP “unhealthy” khỏi response DNS | Có real-time health check, phát hiện và remove instance nhanh chóng |
| Cơ chế phân phối tải | Không kiểm soát được phân phối (client chọn ngẫu nhiên IP) | Phân phối thông minh: Round Robin, Least Connection, Weighted, Sticky Session |
| SSL termination | ❌ Không hỗ trợ | ✅ Có thể terminate SSL ở LB |
| Session stickiness | ❌ Không có | ✅ Có hỗ trợ |
| Tự động scale | ❌ Không tích hợp | ✅ Tích hợp với Auto Scaling |
| Failover nhanh | ❌ Chậm do DNS TTL (client cache) | ✅ Nhanh, theo dõi tình trạng backend liên tục |
| Chi phí | Rất rẻ, chỉ tính theo số DNS queries | Cao hơn vì sử dụng compute resource |
Bạn thấy bài này thế nào?