AWS Global Accelerator — Đường cao tốc riêng trên backbone AWS cho ứng dụng của bạn
Bạn có một ứng dụng SaaS deploy tại
ap-southeast-1(Singapore). Người dùng ở Châu Âu và Bắc Mỹ bắt đầu phàn nàn về độ trễ cao và kết nối WebSocket hay bị ngắt. Team bạn quyết định đặt CloudFront phía trước ALB — “có Edge Location khắp nơi mà, chắc sẽ nhanh hơn”. Và đúng thật, latency có giảm. Nhưng rồi những vấn đề mới xuất hiện: client IP biến mất (rate limiter liên tục block nhầm), WebSocket tự động ngắt sau 10 phút idle, và mỗi lần debug bạn phải “soi” thêm một lớp CloudFront giữa client và ALB.Bạn đã dùng một CDN làm network proxy — và nó đi kèm những tác dụng phụ mà bạn không hề muốn.
Có một dịch vụ AWS được thiết kế chính xác cho bài toán này: AWS Global Accelerator.
1. Global Accelerator là gì?
AWS Global Accelerator là dịch vụ networking giúp tăng tốc traffic từ người dùng đến ứng dụng của bạn. Thay vì để traffic đi qua internet công cộng với đường đi không thể đoán trước, Global Accelerator đưa traffic vào mạng nội bộ của AWS ngay từ điểm gần người dùng nhất.
Sức mạnh cốt lõi của Global Accelerator đến từ ba thành phần:
1.1. AWS Backbone Network
AWS Backbone Network là mạng riêng nội bộ của AWS, kết nối tất cả các Region và Edge Location với nhau. Mạng này hoàn toàn tách biệt khỏi internet công cộng — được AWS xây dựng và vận hành riêng với cáp quang chuyên dụng.
Khi traffic đi trên backbone:
- Nhanh hơn — đường đi được tối ưu, không phải nhảy qua nhiều ISP trung gian
- Ổn định hơn — không bị ảnh hưởng bởi tắc nghẽn trên internet công cộng
- Nhất quán hơn — latency ít biến động giữa các lần request
Đây là sức mạnh cốt lõi số một: đường truyền riêng, không chia sẻ với internet công cộng.
1.2. Edge Locations
AWS có hơn 100 Edge Location trải khắp thế giới. Khi người dùng gửi request, traffic sẽ được tiếp nhận tại Edge Location gần nhất, rồi từ đó đi vào backbone network.
Điều này có nghĩa: phần lớn hành trình của traffic diễn ra trên “đường cao tốc riêng” của AWS, thay vì lang thang trên internet công cộng. Người dùng ở Frankfurt chỉ cần đi một đoạn ngắn trên internet công cộng đến Edge Location tại Frankfurt, sau đó toàn bộ hành trình từ Frankfurt đến Singapore đều đi trên backbone.
Đây là sức mạnh cốt lõi số hai: rút ngắn quãng đường đi trên internet công cộng xuống mức tối thiểu.
1.3. Anycast IP
Thông thường, mỗi địa chỉ IP là Unicast — nghĩa là một IP gắn với một server duy nhất tại một vị trí cụ thể. Khi bạn kết nối đến IP đó, traffic luôn đi đến đúng server đó, bất kể bạn ở đâu.
Anycast thì ngược lại: cùng một IP được quảng bá (advertise) từ nhiều điểm trên thế giới cùng lúc. Khi client kết nối đến IP này, hệ thống routing của internet tự động đưa traffic đến điểm gần nhất — hoàn toàn tự động, không cần DNS routing phức tạp.
Global Accelerator cấp cho bạn 2 static Anycast IP, được quảng bá từ tất cả Edge Location. Bất kể người dùng ở đâu, họ luôn kết nối đến Edge gần nhất chỉ bằng cách truy cập cùng một IP.
Đây là sức mạnh cốt lõi số ba: một IP duy nhất, tự động đến điểm gần nhất, không phụ thuộc DNS.
Kết hợp lại
Ba sức mạnh này hoạt động cùng nhau tạo thành luồng xử lý:
- Client kết nối đến Anycast IP → tự động đến Edge Location gần nhất
- Traffic đi vào AWS Backbone Network — đường cao tốc riêng
- Traffic đến endpoint của bạn (ALB, NLB, EC2, Elastic IP) tại Region đích
2. Global Accelerator giải quyết vấn đề gì?
2.1. Internet công cộng không thể đoán trước
Khi traffic đi qua internet công cộng, nó phải nhảy qua nhiều hop — từ ISP này sang ISP khác, qua các peering point (điểm trao đổi traffic giữa các mạng). Mỗi hop đều có thể gây thêm latency, và đường đi có thể thay đổi bất cứ lúc nào.
Kết quả: latency biến động, có lúc nhanh có lúc chậm, đặc biệt với người dùng ở xa Region deploy. Global Accelerator loại bỏ vấn đề này bằng cách đưa traffic vào backbone ngay từ Edge gần nhất.
Ví dụ: bạn đang ở Việt Nam và gọi đến server đặt ở Region us-east-1 (Virginia, Mỹ). Khi traffic đi qua internet công cộng, nó phải nhảy qua hàng loạt mạng độc lập — từ ISP nội địa (Viettel/VNPT), qua peering point trong nước (VNIX), ra cáp quang biển (AAG/APG), đến các điểm peering quốc tế (Equinix Singapore, Tokyo), qua các Tier-1 transit (NTT, Telia, Cogent), rồi cuối cùng đến ISP ở Mỹ và server đích. Mỗi mạng đều thuộc một công ty khác nhau, không ai chịu trách nhiệm cho toàn tuyến.
Còn khi đi qua AWS Backbone Network, traffic vào AWS ngay tại Edge Location gần nhất (HCMC hoặc Singapore), rồi đi thẳng trên cáp quang riêng của AWS đến Region đích. Chỉ một bên (AWS) sở hữu và vận hành toàn tuyến — không peering, không phụ thuộc BGP, không jitter.
2.2. Static IP — không phụ thuộc DNS propagation
Khi bạn thay đổi endpoint phía sau (ví dụ: chuyển từ ALB này sang ALB khác, hoặc failover sang Region khác), 2 Anycast IP của Global Accelerator không thay đổi. Client vẫn kết nối đến cùng IP.
So sánh với DNS-based failover (ví dụ Route 53): khi bạn đổi record DNS, phải đợi TTL hết hạn. Trong khoảng thời gian đó, một số client vẫn kết nối đến endpoint cũ. Với Global Accelerator, việc chuyển đổi là tức thì vì IP không đổi.
2.3. Health-based failover tức thì
Global Accelerator liên tục health-check các endpoint. Khi phát hiện endpoint không healthy, traffic được tự động chuyển sang endpoint healthy khác trong vài giây.
Nhanh hơn rất nhiều so với DNS failover (phụ thuộc vào TTL, thường từ 60-300 giây). Với các ứng dụng yêu cầu high availability, vài giây so với vài phút là khác biệt lớn.
2.4. Multi-Region với traffic weights
Global Accelerator cho phép bạn phân phối traffic giữa nhiều Region theo tỷ lệ (weight). Ví dụ: 70% traffic đến ap-southeast-1, 30% đến us-east-1. Bạn có thể điều chỉnh weight bất cứ lúc nào — hữu ích cho:
- Active-active: chạy ứng dụng ở nhiều Region cùng lúc
- Gradual migration: dần dần chuyển traffic từ Region cũ sang Region mới
- Blue-green deployment: chuyển traffic giữa hai phiên bản bằng cách điều chỉnh weight
2.5. Tăng tốc thiết lập kết nối — TCP termination tại Edge
Một kết nối TCP chỉ gửi được byte dữ liệu đầu tiên sau khi client và endpoint hoàn tất three-way handshake. Nếu endpoint nằm ở Region xa, mỗi bước bắt tay phải đi trọn một vòng trên internet công cộng, nên riêng pha thiết lập kết nối đã chậm trước cả khi truyền dữ liệu. Đây là lý do người dùng ở xa thường thấy lúc mở kết nối ban đầu rất lâu, dù sau đó truyền dữ liệu vẫn ổn.
Global Accelerator giải quyết bằng kỹ thuật TCP termination tại Edge: client hoàn tất bắt tay TCP ngay với Edge Location gần nhất, gần như cùng lúc Global Accelerator mở một kết nối TCP thứ hai từ Edge đến endpoint và chạy trên backbone. Client nhận phản hồi từ Edge ở sát bên thay vì chờ trọn vòng đến tận Region, nhờ đó thời gian thiết lập kết nối giảm đáng kể.
AWS đo ở p90 bằng công cụ đo từ người dùng thật: first byte latency giảm tới 49%, jitter giảm tới 58%, và throughput tăng tới 60%. Với ứng dụng nhạy cảm ở pha mở phiên như video conferencing hay real-time API, đây là khác biệt cảm nhận được ngay.
Đây cũng là chỗ Route 53 latency-based routing thua kém. Latency routing chỉ chọn Region có độ trễ thấp nhất ở tầng DNS: nó trả về IP của endpoint gần nhất, nhưng sau đó packet vẫn tự đi trên internet công cộng đến Region đó. Nó không rút ngắn pha bắt tay, không đưa traffic vào backbone, và vẫn dính các điểm yếu của DNS là cache, TTL và failover chậm. Global Accelerator vừa chọn endpoint khỏe gần nhất vừa tăng tốc chính đường đi của dữ liệu, nên với tình huống giảm latency toàn cầu cho TCP/UDP mà vẫn giữ nguyên hạ tầng NLB/EC2 sẵn có, Global Accelerator là lựa chọn đúng còn latency routing là bẫy.
3. Các use case thực tế
Gaming và ứng dụng real-time
Global Accelerator hỗ trợ cả TCP và UDP. Với game online, mỗi millisecond latency đều quan trọng. Đưa traffic vào backbone thay vì internet công cộng giúp giảm latency và giảm jitter.
Nền tảng tài chính / giao dịch
Với trading platform, latency nhất quán quan trọng hơn latency thấp tuyệt đối. Bạn không muốn request lúc mất 50ms lúc mất 500ms. Backbone network đảm bảo latency ổn định vì đường đi không thay đổi theo tình trạng internet công cộng.
Multi-Region failover
Bạn có ALB ở ap-southeast-1 và us-east-1. Khi Singapore gặp sự cố, Global Accelerator tự động chuyển traffic sang US trong vài giây. Client không cần đổi IP, không cần đợi DNS propagation.
IoT và long-lived connections
Các thiết bị IoT thường duy trì kết nối TCP lâu dài. Global Accelerator không can thiệp vào connection — không parse, không timeout, không modify. Traffic đi thẳng đến endpoint.
Blue-green deployment
Bạn đang chạy v1 trên ALB-A và muốn chuyển sang v2 trên ALB-B. Thay vì đổi DNS (phải đợi propagation), bạn thêm ALB-B vào Global Accelerator với weight 10%, quan sát, rồi dần tăng lên 100%. Nếu có vấn đề, chuyển weight về 0% ngay lập tức.
Cách tiếp cận quen thuộc hơn cho blue-green là Route 53 weighted routing — một chính sách định tuyến của Route 53 cho phép gán trọng số cho từng bản ghi DNS để phân phối traffic theo tỷ lệ (ví dụ bản ghi trỏ về ALB-A nhận 90%, bản ghi trỏ về ALB-B nhận 10%). Ý tưởng giống hệt: điều chỉnh trọng số để dịch chuyển traffic dần dần. Khác biệt nằm ở tầng nó hoạt động — Route 53 chuyển traffic ở tầng DNS, nên gánh đúng điểm yếu của DNS là caching.
Khi một client phân giải tên miền, kết quả được cache lại ngay trên thiết bị và ở các resolver trung gian (resolver của ISP, của mạng công ty) cho đến khi TTL hết hạn. Nhiều thiết bị — đặc biệt là mobile — còn giữ cache lâu hơn cả TTL bạn đặt. Hệ quả khi bạn đổi trọng số: không phải client nào cũng nhận tỷ lệ mới ngay. Một phần traffic vẫn đi theo bản ghi cũ cho đến khi cache của nó hết hạn, nên tỷ lệ thật mà v2 nhận được khó đoán và lệch so với con số bạn cấu hình. Khi cần rollback gấp (đưa v2 về 0%), những client đang cache vẫn tiếp tục gửi request đến v2 trong một khoảng thời gian.
Global Accelerator điều chỉnh weight ngay tại tầng network, phía sau 2 Anycast IP cố định, nên hoàn toàn không phụ thuộc DNS cache. Thay đổi có hiệu lực trong vài giây, tỷ lệ traffic được kiểm soát chính xác, và rollback là tức thì. Vì vậy với những đợt blue-green cần dịch chuyển nhanh và có kiểm soát — nhất là khi phần lớn người dùng ở mobile, nơi DNS dễ bị cache lâu — Global Accelerator an toàn hơn Route 53 weighted routing.
4. Đừng nhầm lẫn CloudFront với Global Accelerator
Đây là điểm nhiều người hay nhầm: cả hai đều sử dụng Edge Location của AWS, nhưng bản chất hoàn toàn khác nhau.
4.1. Bản chất khác nhau
CloudFront là CDN. Nhiệm vụ của nó là cache và phân phối nội dung gần người dùng hơn. Nó hoạt động ở Layer 7 (tầng ứng dụng) — đọc HTTP request, xử lý headers, cache response.
Global Accelerator là network accelerator. Nhiệm vụ của nó là mang traffic đến origin nhanh hơn qua AWS backbone, không can thiệp vào request. Nó hoạt động ở Layer 3/4 (tầng mạng/vận chuyển) — chỉ lo vận chuyển packet, không quan tâm nội dung bên trong.
Khi bạn đặt CloudFront phía trước ALB cho một dynamic API không cần cache, bạn đang dùng CDN làm network proxy. Nó hoạt động được, nhưng bạn sẽ gánh toàn bộ pipeline xử lý của CDN dù không cần — và đi kèm đó là các tác dụng phụ.
4.2. Tác dụng phụ khi dùng CloudFront làm network proxy
Cache layer luôn chạy — Kể cả khi bạn set CachingDisabled, CloudFront vẫn phải evaluate cache policy mỗi request. Đây là một bước xử lý bắt buộc trong pipeline của CDN. Global Accelerator không có cache layer — traffic đi thẳng.
Client IP bị thay đổi — CloudFront terminate kết nối TCP từ client và tạo kết nối mới đến origin. Kết quả: ALB nhận thấy IP của CloudFront, không phải IP thật của client. Ứng dụng phải đọc header X-Forwarded-For để lấy IP gốc. Nếu bạn có logic rate-limiting hoặc geo-blocking dựa trên IP, tất cả đều phải điều chỉnh. Global Accelerator giữ nguyên client IP — traffic đến ALB vẫn mang IP thật của người dùng.
Request/response bị parse — CloudFront đọc HTTP headers, có thể modify hoặc strip một số headers, áp dụng size limits cho headers và body. Nếu ứng dụng của bạn dựa vào custom headers hoặc gửi payload lớn, bạn cần kiểm tra kỹ. Global Accelerator không đọc, không parse, không modify bất kỳ thứ gì.
WebSocket idle timeout 10 phút — CloudFront tự động ngắt kết nối WebSocket nếu không có hoạt động trong 10 phút. Với các ứng dụng real-time sử dụng WebSocket (ví dụ Soketi, Socket.io), đây là vấn đề nghiêm trọng vì long-lived connection có thể bị drop bất ngờ. Global Accelerator không áp đặt idle timeout lên connection.
Debug khó hơn — Thêm một lớp HTTP processing giữa client và ALB nghĩa là khi có vấn đề, bạn phải phân biệt: lỗi do CloudFront hay do ALB? Do cache policy hay do origin? Global Accelerator transparent — traffic đi thẳng, ít biến số hơn khi debug.
4.3. Bảng so sánh
| Tiêu chí | CloudFront | Global Accelerator |
|---|---|---|
| Mục đích chính | CDN — cache và phân phối nội dung | Tối ưu đường truyền mạng |
| Hoạt động ở tầng | Layer 7 (HTTP/HTTPS) | Layer 3/4 (TCP/UDP) |
| Cache | Có (luôn evaluate dù set CachingDisabled) | Không có |
| Client IP | Bị thay đổi — cần đọc X-Forwarded-For | Giữ nguyên |
| Request modification | Parse headers, có thể modify/strip | Không can thiệp |
| WebSocket | Idle timeout 10 phút | Không timeout bởi GA |
| Static IP | Không (dùng DNS CNAME) | 2 Anycast IP tĩnh |
| Protocol hỗ trợ | HTTP, HTTPS | TCP, UDP |
| Chi phí cố định | $0 (trả theo request + bandwidth) | ~$18/tháng |
4.4. Chọn đúng công cụ
Dùng CloudFront khi:
- Nội dung có thể cache: static assets (JS, CSS, images), API responses ít thay đổi
- Cần xử lý logic ở edge: Lambda@Edge, CloudFront Functions
- Mục tiêu là đưa nội dung gần người dùng hơn
Dùng Global Accelerator khi:
- Dynamic API, traffic không cần cache
- Cần giữ nguyên client IP
- Long-lived connections: WebSocket, gRPC streaming
- Cần static IP cho whitelist hoặc DNS-less integration
- Mục tiêu là đưa traffic về origin nhanh hơn
Hai dịch vụ có thể dùng song song: CloudFront cho static assets + Global Accelerator cho API/WebSocket traffic. Đây là kiến trúc phổ biến khi ứng dụng có cả nội dung tĩnh và dynamic.
5. Hai loại accelerator: Standard và Custom Routing
Global Accelerator có hai loại, và đề thi SAA thường nói rõ “standard accelerator” để bạn phân biệt với loại còn lại.
Standard accelerator là loại mặc định, cũng là loại mà toàn bộ bài viết này mô tả. Endpoint là NLB, ALB, EC2 hoặc Elastic IP. Global Accelerator định tuyến mỗi client đến endpoint tối ưu dựa trên vị trí người dùng, kết quả health check và weight bạn cấu hình; khi một endpoint không healthy, traffic tự chuyển sang endpoint khỏe khác trong vài giây. Đây là loại dùng cho hầu hết bài toán giảm latency toàn cầu và multi-Region failover.
Custom Routing accelerator giải một bài toán khác: ghim một client đến đúng một EC2 instance và port cụ thể bên trong một VPC subnet, dựa trên cặp Anycast IP và listener port mà client kết nối tới. Endpoint ở đây là VPC subnet chứa các EC2 instance, không phải load balancer. Điểm phải nhớ: Custom Routing không health-check và không failover — định tuyến là tất định, traffic luôn tới đúng instance đã ánh xạ bất kể nó còn khỏe hay không. Loại này hợp với ứng dụng cần tự quyết định user này phải vào đúng server kia, ví dụ VoIP gán nhiều người gọi vào một media server, hoặc game real-time gán nhiều người chơi vào cùng một session trên một game server.
Mẹo thi: đề nói định tuyến toàn cầu, giảm latency, failover sang NLB/ALB/EC2 thì chọn Standard accelerator; chỉ khi đề nhấn vào việc gán client đến đúng một instance/port cụ thể cho gaming session hay VoIP mới là Custom Routing.
6. Kết luận
Global Accelerator là đúng tool khi bạn cần mang traffic về origin nhanh hơn mà không can thiệp vào request. Nó transparent, giữ nguyên client IP, không cache, không parse, không timeout.
CloudFront là đúng tool khi bạn cần đưa nội dung gần người dùng hơn — cache static assets, xử lý logic ở edge.
Hai dịch vụ phục vụ mục đích khác nhau. Đừng dùng CDN làm network proxy khi có tool chuyên biệt cho việc đó. Dùng đúng tool cho đúng công việc.