Lộ trình học Amazon Route 53

Ngày 1: Amazon Route 53 - Nền tảng, Hosted Zones và Routing Policies

• Buổi sáng:

  • Amazon Route 53 là gì? Dịch vụ DNS được quản lý của AWS: authoritative DNS, khả năng mở rộng, SLA 100% cho DNS data plane (đây là lý do ARC dùng Route 53 health check làm cơ chế failover đáng tin cậy).

  • Domain & DNS: phân biệt domain registration (đăng ký tên miền) và DNS hosting (Route 53 trả lời truy vấn) - hai việc độc lập, có thể đăng ký domain ở registrar khác nhưng vẫn dùng Route 53 làm nameserver.

  • Đăng ký Domain với Route 53: đăng ký mới, transfer-in, quản lý nameserver, gia hạn. Cập nhật: Route 53 Domains vừa bổ sung 34 TLD mới (05/2026) như .app, .dev, .health, .ai-adjacent... hữu ích khi đặt tên domain kỹ thuật/sản phẩm.

  • Hosted Zones và Record Sets:

    • Public Hosted Zone vs Private Hosted Zone (chỉ resolve trong VPC được associate).

    • Record types: A, AAAA, CNAME, MX, TXT, NS, SOA, và Alias Record (đặc thù của Route 53, không tính phí, hỗ trợ trỏ zone apex đến ALB/CloudFront/S3 - khác CNAME ở chỗ Alias hoạt động được tại root domain).

  • Production tip - chiến lược TTL: TTL thấp (60-300s) cho record cần failover nhanh; TTL cao hơn cho record ổn định để giảm chi phí truy vấn và độ trễ resolve. Cân nhắc TTL trước khi migrate DNS provider (hạ TTL trước 24-48h).

  • Thực hành:

    1. Tạo public hosted zone cho domain thật hoặc test (mywebsite.com), quan sát 4 nameserver được cấp (4 TLD khác nhau để tăng resilience).

    2. Thêm Alias record trỏ zone apex đến một ALB, và một CNAME cho subdomain trỏ đến CloudFront.

    3. Tạo private hosted zone (corp.internal) associate với 1 VPC, thêm A record trỏ EC2 private IP.

• Buổi chiều:

  • Routing Policies - hiểu rõ use-case production của từng loại, không chỉ định nghĩa:

    • Simple: 1 record, không hỗ trợ health check multi-value tốt - chỉ dùng cho endpoint đơn giản, không production-critical.

    • Weighted: phân bổ theo % - dùng cho canary release ở tầng DNS (lưu ý: cache DNS phía client làm rollout không mượt như Weighted Target Group ở ALB/NLB, TTL thấp giúp giảm độ trễ chuyển đổi).

    • Latency-based: route theo latency đo được giữa AWS region và người dùng - dùng cho kiến trúc multi-region active-active.

    • Failover: kết hợp health check, dùng cho active-passive DR.

    • Geolocation / Geoproximity: định tuyến theo vị trí địa lý - dùng cho compliance dữ liệu (data residency) hoặc bias traffic theo vùng (Geoproximity còn cho phép "bias" mở rộng/thu hẹp vùng phục vụ).

    • Multivalue Answer: trả nhiều IP kèm health check - là "load balancing nhẹ" ở tầng DNS khi không cần ELB, nhưng KHÔNG thay thế được ELB cho traffic lớn (giới hạn 8 record trả về).

  • Thực hành:

    1. Weighted routing 70/30 giữa 2 target, đo thời gian client thực sự chuyển traffic khi đổi tỷ lệ (phụ thuộc TTL + cache OS/browser).

    2. Failover routing với 1 primary + 1 secondary, gắn health check.

    3. So sánh Multivalue Answer routing với ALB truyền thống - khi nào đủ dùng multivalue, khi nào bắt buộc cần ALB.

Ngày 2: Health Checks và DNS Failover

• Buổi sáng:

  • 3 loại Health Check của Route 53 và use-case production:

    • Endpoint health check: kiểm tra HTTP/HTTPS/TCP đến 1 endpoint. Lưu ý: health checker của Route 53 chạy từ nhiều location toàn cầu - endpoint phải public reachable (hoặc dùng CloudWatch alarm health check cho resource private).

    • Calculated health check: kết hợp nhiều health check con bằng AND/OR/quorum (ví dụ: "healthy nếu ≥ 2/3 con khỏe") - dùng để tránh false failover khi 1 location health-checker bị nhiễu mạng tạm thời.

    • CloudWatch alarm health check: bắt buộc dùng khi endpoint không có public IP (ví dụ RDS, internal NLB) - health check theo dõi CloudWatch Alarm thay vì gọi trực tiếp endpoint.

  • Production tip: luôn bật health check từ ≥ 3 location, và cấu hình FailureThreshold phù hợp (mặc định 3 lần fail liên tiếp) để tránh flapping.

  • Thực hành:

    1. Tạo endpoint health check giám sát web server, xem chi tiết log từ từng location checker.

    2. Tạo calculated health check kết hợp 3 endpoint health check với quorum 2/3.

    3. Tạo CloudWatch alarm health check theo dõi metric UnHealthyHostCount của một Target Group phía sau NLB nội bộ (không public).

• Buổi chiều:

  • DNS Failover: cơ chế Route 53 tự loại record "unhealthy" khỏi response khi failover routing policy được cấu hình với health check.

  • Giới hạn cần biết trong production: DNS failover phụ thuộc TTL và cache của resolver/client - RTO thực tế luôn lớn hơn TTL cấu hình vài phần trăm client vẫn cache cũ (đây là lý do enterprise dùng thêm Route 53 ARC - xem Ngày 6).

  • Thực hành:

    1. Cấu hình DNS failover 1 chính + 1 dự phòng, gắn endpoint health check.

    2. Test thực tế: tắt server chính, đo thời gian thực để traffic chuyển hẳn sang dự phòng (so với TTL cấu hình).

    3. Cấu hình failover cho A record trong private hosted zone, dùng CloudWatch alarm health check (vì EC2 private không public reachable).

Ngày 3: Traffic Flow, Route 53 Resolver & Global Resolver - Kiểm soát và Hybrid DNS

• Buổi sáng:

  • Route 53 Traffic Flow: visual policy builder cho phép kết hợp nhiều routing policy lồng nhau (ví dụ: Geolocation → trong mỗi region lại Weighted để canary) và versioning chính sách - có thể rollback về version cũ nếu policy mới gây sự cố (rất quan trọng cho production, tránh phải build lại từ đầu).

  • Route 53 Resolver (VPC Resolver):

    • Inbound Endpoint: cho phép DNS server on-premises truy vấn private hosted zone qua VPN/Direct Connect.

    • Outbound Endpoint + Resolver Rules (conditional forwarding): cho phép EC2 trong VPC resolve domain nội bộ on-premises.

    • Cập nhật mới (05/2026): Inbound endpoint hỗ trợ DNS64 (tự synthesize AAAA từ A record, giúp client IPv6-only gọi được service chỉ có IPv4) và Outbound endpoint hỗ trợ forward IPv6 qua Internet Gateway - quan trọng khi tổ chức đang migrate dần sang IPv6-only.

  • Route 53 Global Resolver (GA 03/2026) - tính năng mới quan trọng nhất của mảng Resolver:

    • Là resolver anycast, reachable từ Internet (khác VPC Resolver chỉ resolve được từ trong VPC/on-premises qua endpoint) - cho phép client ở bất kỳ đâu (chi nhánh, remote worker, laptop) resolve cả domain public lẫn private hosted zone qua một endpoint anycast duy nhất.

    • Có sẵn DNS filtering (chặn domain độc hại, NSFW, DGA, DNS tunneling), hỗ trợ DoH/DoT (DNS mã hoá), và centralized query logging.

    • Khi nào chọn Global Resolver thay vì VPC Resolver truyền thống: khi cần một giải pháp DNS hợp nhất cho nhân sự phân tán toàn cầu mà không muốn duy trì multi-region Resolver endpoint + failover riêng.

  • Thực hành:

    1. Tạo Traffic Policy nhiều tầng: Geolocation (US/EU/APAC) → trong mỗi vùng dùng Weighted để A/B testing; tạo version 2 rồi rollback về version 1.

    2. Thiết lập Inbound + Outbound Resolver endpoint, cấu hình conditional forwarding rule cho domain on-premises.

    3. (Nếu region hỗ trợ) Khởi tạo Route 53 Global Resolver ở chế độ trial, cấu hình allowlist IP cho client, so sánh trải nghiệm với VPC Resolver truyền thống.

Ngày 4: Route 53 DNS Firewall & Profiles

• Buổi sáng:

  • Route 53 Resolver DNS Firewall: chặn/cho phép truy vấn DNS outbound dựa trên domain list (tự tạo hoặc AWS Managed Domain Lists phân loại theo threat: malware, botnet, phishing... hoặc theo nội dung: adult, gambling...), loại bản ghi, và độ ưu tiên rule.

  • Route 53 Global Resolver cũng có DNS filtering tương đương (Managed Domain Lists + phát hiện DGA/dictionary-DGA/tunneling) - nên cân nhắc dùng Global Resolver nếu vừa cần filtering vừa cần resolve từ ngoài VPC.

  • Route 53 Profiles: quản lý tập trung private hosted zone, DNS Firewall rule group, Resolver rule - áp dụng đồng loạt cho nhiều VPC/account qua AWS RAM.

    • Cập nhật mới (03/2026): Profiles hỗ trợ IAM permission chi tiết (granular) - có thể giới hạn 1 nhóm chỉ được associate/disassociate/update một loại resource cụ thể (ví dụ team platform chỉ được gắn DNS Firewall rule group, không được sửa private hosted zone) - cực kỳ hữu ích khi tổ chức có nhiều team dùng chung landing zone.

  • Thực hành:

    1. Tạo DNS Firewall rule group dùng AWS Managed Domain List (malware) + rule tự định nghĩa chặn domain nội bộ không cho phép.

    2. Tạo Route 53 Profile gắn DNS Firewall rule group + private hosted zone + Resolver rule, share qua AWS RAM cho account khác trong Organization.

    3. Viết IAM policy chi tiết chỉ cho phép một role associate Profile vào VPC nhưng không được update nội dung Profile.

• Buổi chiều:

  • Ôn tập, làm bài tập tổng hợp: dựng mô hình bảo mật DNS tập trung cho tổ chức có 5 VPC/3 account bằng 1 Profile duy nhất, kiểm tra rule áp dụng đúng ở mọi VPC.

Ngày 5: Tích hợp Route 53 với các dịch vụ AWS & Best Practices

• Buổi sáng:

  • Tích hợp dịch vụ:

    • ALB/NLB: dùng Alias record (không CNAME) để trỏ domain đến LB - tự động cập nhật khi IP của LB đổi, không tính thêm phí truy vấn.

    • CloudFront: Alias record cho phép serve tại zone apex; cân nhắc DNS-based hay CloudFront Functions cho routing logic phức tạp hơn.

    • S3 static website hosting: Alias record trỏ bucket, lưu ý tên bucket phải trùng domain.

    • API Gateway: custom domain name + Alias record, cân nhắc Regional vs Edge-optimized endpoint khi chọn cách trỏ DNS.

  • Thực hành:

    1. Trỏ Alias record đến ALB, đo hiệu năng resolve so với CNAME.

    2. Tạo CloudFront distribution, cấu hình Alias record tại root domain.

    3. Static website trên S3 + Route 53 Alias, kiểm tra HTTPS qua CloudFront (S3 website endpoint không hỗ trợ HTTPS trực tiếp - best practice production luôn đặt CloudFront phía trước).

• Buổi chiều:

  • Best Practices production (mở rộng, không chỉ liệt kê):

    • Alias thay vì CNAME ở mọi nơi có thể - miễn phí, hỗ trợ zone apex, tự healing khi IP backend đổi.

    • DNSSEC: bật signing cho public hosted zone + validation ở Resolver; hiểu rủi ro: nếu quản lý key (KSK/ZSK) sai có thể khiến domain "sập" hoàn toàn (fail-closed) - cần rotate key theo runbook, không thao tác thủ công vội vàng.

    • IAM cho Route 53: tách quyền route53:ChangeResourceRecordSets theo hosted zone cụ thể (dùng resource-level permission + condition trên HostedZoneId), tránh cấp quyền toàn cục.

    • Query Logging + CloudWatch: bật query logging cho public hosted zone, đẩy về CloudWatch Logs/S3, dùng Athena phân tích truy vấn bất thường (dấu hiệu DNS tunneling nếu không dùng Global Resolver/DNS Firewall).

    • IaC bắt buộc: toàn bộ hosted zone, record, health check, Traffic Policy quản lý bằng Terraform/CDK - record DNS là tài nguyên "âm thầm gây outage" nếu sửa tay ngoài quy trình.

    • Nhiều health check ở nhiều location + calculated health check quorum để giảm false positive.

  • Thực hành:

    1. Bật DNSSEC cho một public hosted zone, mô phỏng quy trình rotate KSK theo đúng thứ tự an toàn (double-signature period).

    2. Viết IAM policy giới hạn 1 role chỉ sửa được record trong 1 hosted zone cụ thể.

    3. Bật query logging, viết Athena query tìm top domain được truy vấn nhiều bất thường trong 1 giờ.

Ngày 6: Route 53 Application Recovery Controller (ARC)

• Buổi sáng:

  • Vì sao DNS Failover thường (Ngày 2) chưa đủ cho production tier-0: phụ thuộc hoàn toàn vào Route 53 health check tự động phát hiện lỗi + TTL cache - không có cơ chế "manual override an toàn" khi hệ thống giám sát không phát hiện ra sự cố (ví dụ lỗi tăng error rate 5% nhưng chưa đủ để health check fail).

  • Kiến trúc ARC gồm 3 thành phần:

    • Readiness Check: liên tục kiểm tra xem region/AZ dự phòng có đủ capacity, cấu hình đúng để nhận traffic ngay lập tức hay không (Auto Scaling group, RDS, DynamoDB Global Table, LB...).

    • Routing Control: công tắc ON/OFF được lưu trên cluster 5 endpoint (5 region khác nhau) với SLA cực cao; đổi trạng thái sẽ cập nhật Route 53 health check gắn với DNS failover record - API call, không phải sửa DNS record thủ công.

    • Safety Rules: guardrail ngăn thao tác sai (ví dụ chặn việc bật cả 2 region cùng lúc nếu kiến trúc yêu cầu chỉ 1 active, hoặc chặn tắt hết tất cả region).

  • Zonal Shift & Region Switch (mở rộng của ARC): Zonal Shift cho phép dịch chuyển traffic ra khỏi 1 AZ bị lỗi trong vài phút (ví dụ do một bản deploy lỗi) mà không cần failover toàn bộ region; Region Switch hỗ trợ điều phối failover toàn diện ở cấp region cho kiến trúc phức tạp hơn.

• Buổi chiều:

  • Bài tập 1: Dựng kiến trúc active/standby 2 region (mỗi region: ALB + ASG + DynamoDB Global Table), tạo ARC cluster, control panel, routing control cho mỗi region, gắn với Route 53 health check kiểu RECOVERY_CONTROL.

  • Bài tập 2: Cấu hình Safety Rule đảm bảo tối thiểu 1 region luôn ON.

  • Bài tập 3: Thực hiện failover thật bằng một lệnh API update-routing-control-states, đo thời gian traffic thực sự chuyển vùng so với DNS failover thuần TTL ở Ngày 2.

  • Bài tập 4: Dùng Zonal Shift mô phỏng lỗi 1 AZ (không phải toàn region), quan sát traffic dịch chuyển trong cùng region mà không cần đổi DNS.

  • Bài tập 5: Viết toàn bộ hạ tầng ARC bằng Terraform (module aws-ia/terraform-aws-route53-recovery-controller hoặc tự viết), tích hợp vào pipeline CI/CD của "dự án tổng hợp".

Dự án tổng hợp: Kiến trúc DNS Production cho hệ thống Multi-Region

Mô tả: Xây dựng lớp DNS/routing hoàn chỉnh cho một ứng dụng thương mại điện tử chạy active-active ở 2 region (ví dụ us-east-1 và ap-southeast-1), bao gồm:

1. Domain & Zone: 1 public hosted zone chính, DNSSEC bật, IaC quản lý toàn bộ record.

2. Routing: Latency-based routing giữa 2 region cho traffic bình thường; bên trong mỗi region dùng Weighted routing để canary release.

3. Health & Failover: Calculated health check (quorum) cho từng region + failover routing dự phòng nếu cả region "chính" theo latency bị down.

4. DR cấp cao: ARC routing control override lên trên routing policy thường - cho phép SRE thực hiện "manual failover" tức thời khi cần, có Safety Rule chặn thao tác sai.

5. Bảo mật DNS: DNS Firewall/Global Resolver chặn domain độc hại cho traffic outbound từ VPC; Route 53 Profile áp dụng đồng nhất cấu hình cho toàn bộ VPC trong Organization.

6. Hybrid DNS: Resolver Inbound/Outbound endpoint (hoặc Global Resolver) cho phép văn phòng on-premises resolve được private hosted zone của hệ thống.

7. Quan sát & vận hành: Query logging → Athena; CloudWatch Alarm cho health check; runbook game-day định kỳ diễn tập failover bằng ARC.

Mục tiêu: không chỉ "biết dùng từng tính năng Route 53" mà hiểu được khi nào dùng DNS failover thường là đủ, khi nào bắt buộc cần ARC, cách bảo mật DNS tập trung cho tổ chức nhiều VPC/account, và toàn bộ được quản lý bằng IaC + có runbook DR thực chiến - đúng chuẩn vận hành production.