Hạ tầng toàn cầu của AWS

Vì sao cần ứng dụng toàn cầu

Một “ứng dụng toàn cầu” là ứng dụng được triển khai ở nhiều vị trí địa lý khác nhau, thay vì chỉ chạy tại một region duy nhất. Trên AWS, việc “trải rộng” này có thể thực hiện bằng cách dùng nhiều Region và/hoặc các Edge Location. Có ba lý do chính khiến việc này trở nên cần thiết:

Giảm độ trễ (Decreased Latency): latency (độ trễ) là thời gian một gói tin mạng cần để đi từ máy người dùng tới server và ngược lại. Nếu server đặt ở Mỹ mà người dùng ở châu Á, gói tin phải đi qua khoảng cách vật lý rất lớn — tốn nhiều thời gian hơn. Bằng cách đặt server (hoặc bản sao nội dung) gần người dùng hơn, độ trễ giảm xuống và trải nghiệm người dùng tốt hơn rõ rệt.
Khắc phục thảm họa (Disaster Recovery – DR): nếu một AWS Region gặp sự cố nghiêm trọng (động đất, bão, mất điện, thậm chí vấn đề chính trị khiến region ngừng hoạt động), ứng dụng có thể “fail-over” (chuyển hướng) sang một region khác đang hoạt động bình thường. Có một kế hoạch DR rõ ràng giúp tăng độ sẵn sàng (availability) tổng thể của hệ thống.
Chống tấn công tốt hơn (Attack protection): một hạ tầng phân tán trên phạm vi toàn cầu vốn khó bị tấn công triệt để hơn so với một điểm tập trung duy nhất — kẻ tấn công phải nhắm vào nhiều nơi cùng lúc mới có thể làm sập toàn bộ hệ thống.

Nhắc lại hạ tầng toàn cầu

Trước khi đi vào các dịch vụ cụ thể, hãy nhắc lại ba thành phần cấu thành hạ tầng toàn cầu của AWS, vì mọi giải pháp trong chương này đều xây dựng dựa trên chúng:

Region: nơi bạn triển khai ứng dụng và hạ tầng chính (ví dụ EC2, RDS…). Mỗi Region là một vùng địa lý độc lập.
Availability Zone (AZ): mỗi Region gồm nhiều AZ, mỗi AZ lại gồm một hoặc nhiều trung tâm dữ liệu (data center) vật lý riêng biệt, cách ly lỗi với nhau.
Edge Location (Point of Presence – PoP): là các điểm hạ tầng nằm rải rác ở rất nhiều thành phố trên thế giới — nhiều hơn số lượng Region rất nhiều — dùng để phân phối nội dung (content delivery) đến gần người dùng cuối nhất có thể.

Region dùng để chạy hạ tầng “nặng” (compute, database…), còn Edge Location dùng để phục vụ nội dung nhanh nhất tới người dùng ở khắp nơi mà không cần họ phải kết nối trực tiếp tới Region xa xôi.

Amazon Route 53 – Managed DNS

Route 53 là dịch vụ DNS (Domain Name System) được AWS quản lý hoàn toàn. DNS về cơ bản là một tập hợp các quy tắc và bản ghi (record) giúp máy khách (client) biết cách “tìm đường” tới đúng server khi gõ vào một địa chỉ URL — giống như một cuốn “sổ điện thoại” của Internet, dịch tên miền dễ nhớ (như www.example.com) thành địa chỉ IP mà máy móc thực sự dùng để kết nối.

Các loại record phổ biến nhất trong Route 53 mà bạn cần biết:

Loại record	Chức năng	Ví dụ
A	Hostname → địa chỉ IPv4	`www.example.com` → `12.34.56.78`
AAAA	Hostname → địa chỉ IPv6	tương tự A nhưng cho IPv6
CNAME	Hostname → một hostname khác	`search.example.com` → `www.example.com`
Alias	Hostname → một resource của AWS	trỏ tới ELB, CloudFront, S3, RDS…

Luồng hoạt động cơ bản của một A record: trình duyệt gửi yêu cầu DNS cho myapp.mydomain.com → Route 53 trả về địa chỉ IP tương ứng (ví dụ 32.45.67.85) → trình duyệt gửi HTTP Request tới đúng địa chỉ IP đó → nhận về HTTP Response từ Application Server.

Route 53 – Routing Policies

Ngoài việc “dịch” tên miền thành IP, Route 53 còn cho phép chọn chiến lược định tuyến — tức là quyết định trả về IP nào khi có nhiều đích đến khả dụng. Ở mức Cloud Practitioner, bạn chỉ cần biết ở mức tổng quan bốn chính sách sau:

Simple Routing Policy: đơn giản nhất, không có health check — chỉ trả về (một hoặc nhiều) giá trị đã cấu hình, không quan tâm server đó có “sống” hay không.
Weighted Routing Policy: chia traffic theo tỷ trọng (weight) do bạn định nghĩa, ví dụ 70% traffic đi tới target A, 20% tới target B, 10% tới target C — hữu ích khi test A/B hoặc triển khai dần (canary release).
Latency Routing Policy: định tuyến người dùng tới vị trí có độ trễ (latency) thấp nhất đối với họ, dựa trên vị trí thực tế của người dùng — giúp tối ưu trải nghiệm toàn cầu.
Failover Routing Policy: phục vụ cho chiến lược Disaster Recovery — Route 53 liên tục health-check một đích chính (primary); nếu đích chính báo “unhealthy”, traffic sẽ tự động chuyển sang đích phụ (secondary).

Amazon CloudFront (CDN)

Amazon CloudFront là dịch vụ Content Delivery Network (CDN) của AWS. Nhiệm vụ chính của CDN là cải thiện hiệu năng đọc (read performance) bằng cách lưu (cache) một bản sao nội dung tại các Edge Location trên khắp thế giới — khi người dùng ở gần một edge location yêu cầu nội dung, họ nhận được ngay từ edge gần nhất thay vì phải đi hết đường về server gốc ở xa.

CloudFront có hàng trăm Points of Presence (edge location dùng để cache) trên toàn cầu. Ngoài lợi ích về tốc độ, CloudFront còn tích hợp sẵn khả năng chống tấn công DDoS trên phạm vi toàn cầu, cùng với tích hợp AWS Shield và AWS WAF để bảo vệ ứng dụng khỏi các cuộc tấn công web phổ biến.

CloudFront có thể lấy nội dung từ nhiều loại “origin” (nguồn gốc) khác nhau:

S3 bucket: để phân phối file tĩnh và cache tại edge, hoặc để upload file lên S3 thông qua CloudFront; được bảo vệ bằng Origin Access Control (OAC).
VPC Origin: dùng cho ứng dụng đặt trong private subnet của VPC.
Application Load Balancer / Network Load Balancer / EC2 Instance.
Custom Origin (HTTP): ví dụ một website tĩnh trên S3 (phải bật chế độ static website hosting trước), hoặc bất kỳ backend HTTP công khai nào khác.

Luồng hoạt động ở mức tổng quan: client gửi GET request → CloudFront Edge Location kiểm tra cache cục bộ (Local Cache) → nếu chưa có (cache miss), CloudFront chuyển tiếp yêu cầu tới Origin (S3 hoặc HTTP Origin) → nhận nội dung, lưu vào cache và trả kết quả về cho client. Từ lần sau, cùng nội dung đó sẽ được trả trực tiếp từ cache mà không cần hỏi lại Origin, cho tới khi cache hết hạn (TTL).

CloudFront + S3 Origin & OAC

Một mô hình rất phổ biến là dùng S3 bucket làm Origin cho CloudFront. Ví dụ, các edge location đặt tại Los Angeles, Mumbai, Melbourne, São Paulo (và rất nhiều nơi khác) đều lấy nội dung gốc từ cùng một Origin S3 bucket. Điểm quan trọng là bucket S3 này hoàn toàn có thể được giữ ở trạng thái private (không public) — chỉ CloudFront mới được phép đọc từ bucket, thông qua Origin Access Control (OAC) kết hợp với bucket policy cho phép OAC đó.

Nhờ vậy, traffic đi từ CloudFront tới S3 (chặng “origin fetch”) luôn đi trong mạng nội bộ (private) của AWS, trong khi traffic công khai (public www traffic) từ người dùng chỉ chạm tới các edge location, không bao giờ chạm trực tiếp vào S3 bucket. Đây là cách vừa tăng tốc độ phân phối, vừa giữ được tính bảo mật cho dữ liệu gốc.

CloudFront vs S3 CRR

Cả CloudFront và S3 Cross-Region Replication (CRR) đều giúp đưa nội dung tới gần người dùng hơn, nhưng chúng phục vụ mục đích khác nhau và dễ bị nhầm lẫn trong đề thi. Bảng dưới đây tóm tắt sự khác biệt then chốt:

Đặc điểm	CloudFront	S3 Cross-Region Replication
Phạm vi	Mạng Edge toàn cầu (hàng trăm điểm)	Phải tự cấu hình riêng cho từng Region muốn có bản sao
Cách cập nhật nội dung	Nội dung được cache theo một khoảng thời gian (TTL) — có thể mất tới cả ngày mới cập nhật	File được cập nhật gần như real-time (near real-time)
Kiểu dữ liệu phù hợp	Read-heavy, nội dung tĩnh cần có mặt ở khắp mọi nơi	Read only, dữ liệu động cần độ trễ thấp chỉ ở một vài region cụ thể

Nói ngắn gọn: chọn CloudFront khi cần phân phối nội dung ổn định, ít thay đổi, tới khắp thế giới với tốc độ cao nhất; chọn S3 CRR khi cần các bản sao dữ liệu cập nhật gần như tức thời, nhưng chỉ ở một số region nhất định mà bạn chủ động chọn trước.

S3 Transfer Acceleration

Vấn đề: một người dùng ở xa (ví dụ Úc) muốn upload file vào một S3 bucket đặt ở Mỹ. Nếu đi thẳng qua Internet công khai (public Internet) toàn bộ hành trình, đường truyền có thể chậm và không ổn định vì phải qua nhiều “nút” trung gian không do AWS kiểm soát.

S3 Transfer Acceleration giải quyết vấn đề này bằng cách tách hành trình thành hai chặng: chặng đầu, file được gửi từ máy người dùng tới Edge Location gần nhất qua Internet công khai (chặng này thường ngắn nên vẫn nhanh); chặng sau, dữ liệu được chuyển tiếp từ edge location đó tới S3 bucket ở region đích thông qua mạng backbone riêng, tốc độ cao của AWS. Vì phần lớn hành trình dài đi trong mạng riêng của AWS thay vì Internet công khai, tốc độ tổng thể tăng lên đáng kể.

AWS Global Accelerator

AWS Global Accelerator giúp cải thiện độ sẵn sàng và hiệu năng của ứng dụng toàn cầu bằng cách tận dụng chính mạng lưới nội bộ (global network) của AWS — AWS công bố có thể cải thiện hiệu năng tới khoảng 60% so với đi qua Internet công khai thông thường.

Khi dùng Global Accelerator, AWS tạo ra 2 địa chỉ IP Anycast cố định cho ứng dụng của bạn. “Anycast” nghĩa là cùng một địa chỉ IP đó được quảng bá (advertise) từ nhiều edge location cùng lúc — khi người dùng gửi request tới IP này, request sẽ tự động đi vào edge location gần người dùng nhất. Từ edge location, traffic sau đó được chuyển tiếp qua mạng riêng tốc độ cao của AWS tới ứng dụng thật sự — có thể đặt ở một hoặc nhiều Region (ví dụ traffic từ Mỹ, Úc, châu Âu, Ấn Độ đều được dẫn tới một Public ALB).

Global Accelerator vs CloudFront

CloudFront và Global Accelerator dễ bị nhầm vì cả hai đều dùng mạng lưới Edge Location toàn cầu của AWS và đều tích hợp với AWS Shield để chống DDoS. Nhưng bản chất hoạt động của chúng khác nhau hoàn toàn:

Đặc điểm	CloudFront	Global Accelerator
Bản chất	CDN — có cơ chế cache	Không cache, chỉ “proxy” gói tin ở edge tới ứng dụng thật
Phù hợp cho	Nội dung có thể cache được (ảnh, video, static asset)	Nhiều loại ứng dụng chạy trên TCP/UDP, không chỉ HTTP
Ưu điểm nổi bật	Tăng tốc nội dung tĩnh nhờ cache gần người dùng	IP tĩnh cố định; failover giữa các Region nhanh, có thể đoán trước (deterministic)

Ghi nhớ đơn giản: nếu nội dung của bạn cache được (ảnh, video, file tĩnh) → dùng CloudFront. Nếu ứng dụng của bạn cần traffic động, không cache được, cần IP tĩnh, hoặc cần failover nhanh giữa nhiều Region → dùng Global Accelerator.

AWS Outposts

Nhiều doanh nghiệp không thể chuyển 100% hạ tầng lên cloud — vì lý do pháp lý, độ trễ, hoặc đã đầu tư sẵn hạ tầng on-premises — nên vẫn cần duy trì song song cả hạ tầng on-premises và hạ tầng cloud. Mô hình này gọi là Hybrid Cloud. Vấn đề là: quản lý hai hệ thống (cloud dùng console/CLI/API của AWS, on-premises dùng công cụ hoàn toàn khác) rất tốn công và thiếu nhất quán.

AWS Outposts giải quyết vấn đề này bằng cách đưa nguyên một “server rack” của AWS về đặt vật lý ngay tại trung tâm dữ liệu của bạn. Rack này cung cấp đúng hạ tầng, dịch vụ, API và công cụ giống hệt như trên cloud thật — nghĩa là bạn dùng chung một bộ công cụ, một cách làm việc, cho cả on-premises và cloud. AWS chịu trách nhiệm lắp đặt và quản lý (vận hành phần mềm/phần cứng) của “Outposts Rack” này, còn bạn chịu trách nhiệm về an ninh vật lý (physical security) cho rack đặt tại cơ sở của mình.

Lợi ích chính của Outposts: truy cập với độ trễ thấp tới các hệ thống on-premises hiện có, xử lý dữ liệu ngay tại chỗ (local data processing), đáp ứng yêu cầu về nơi lưu trữ dữ liệu (data residency — ví dụ luật yêu cầu dữ liệu phải nằm trong biên giới quốc gia), giúp việc di trú (migration) từ on-premises lên cloud dễ dàng hơn về sau, và vẫn là một dịch vụ được quản lý đầy đủ (fully managed). Một số dịch vụ AWS chạy được trên Outposts: EC2, EBS, S3, EKS, ECS, RDS, EMR.

AWS WaveLength

AWS WaveLength nhắm tới một nhu cầu rất đặc thù: ứng dụng cần độ trễ siêu thấp (ultra-low latency) thông qua mạng di động 5G. WaveLength Zones là các cụm hạ tầng AWS được triển khai ngay bên trong trung tâm dữ liệu của các nhà mạng viễn thông (telecommunications provider), nằm ở biên (edge) của mạng 5G — nghĩa là AWS đặt server (ví dụ EC2, EBS, VPC) ngay tại nơi mạng 5G kết nối vào, thay vì để traffic phải đi vòng về Region AWS thông thường ở xa.

Vì traffic không cần rời khỏi mạng của nhà mạng viễn thông (Communication Service Provider – CSP) để đi tới ứng dụng, độ trễ giảm xuống mức tối thiểu. WaveLength vẫn có kết nối bảo mật, băng thông cao về Region AWS “mẹ” khi cần, và không có phụ phí hay hợp đồng dịch vụ bổ sung nào ngoài chi phí sử dụng thông thường.

WaveLength phù hợp cho các use case đòi hỏi phản hồi gần như tức thì: Thành phố thông minh (Smart Cities), chẩn đoán y tế có trợ giúp của Machine Learning, xe kết nối (Connected Vehicles), livestream video tương tác, AR/VR, và game thời gian thực (Real-time Gaming).

AWS Local Zones

AWS Local Zones đặt các dịch vụ compute, storage, database và một số dịch vụ khác của AWS gần hơn với người dùng cuối, phục vụ các ứng dụng nhạy cảm với độ trễ (latency-sensitive). Về mặt khái niệm, một Local Zone hoạt động như “phần mở rộng của một AWS Region” (extension of an AWS Region) — bạn có thể mở rộng chính VPC hiện tại của mình để bao gồm cả các Local Zone, mà không cần tạo hạ tầng mạng hoàn toàn mới.

Local Zones tương thích với các dịch vụ như EC2, RDS, ECS, EBS, ElastiCache, và Direct Connect. Ví dụ: Region N. Virginia (us-east-1) có các Local Zone đặt tại các thành phố như Boston, Chicago, Dallas, Houston, Miami — cho phép một ứng dụng “gốc” nằm ở us-east-1 có thể đặt một phần compute ngay gần người dùng ở các thành phố đó để giảm độ trễ, mà vẫn quản lý như một phần của cùng một Region/VPC.

Kiến trúc ứng dụng toàn cầu

Khi thiết kế một ứng dụng phục vụ người dùng toàn cầu, có một “lộ trình” từ đơn giản tới phức tạp, đánh đổi giữa độ sẵn sàng/hiệu năng và độ khó khi xây dựng, vận hành:

Single Region, Single AZ: mô hình đơn giản nhất — toàn bộ hạ tầng chỉ chạy trong một AZ của một Region. Dễ dựng nhất nhưng độ sẵn sàng thấp nhất (một AZ gặp sự cố là toàn bộ ứng dụng ngừng hoạt động), và người dùng ở xa Region đó vẫn gặp độ trễ cao.
Single Region, Multi-AZ: trải hạ tầng ra nhiều AZ trong cùng một Region — tăng độ sẵn sàng trong phạm vi Region (một AZ hỏng thì AZ khác vẫn phục vụ được), nhưng vẫn không giải quyết được vấn đề độ trễ cho người dùng ở xa Region đó.
Multi-Region, Active-Passive: một Region đóng vai trò Active (nhận cả đọc lẫn ghi), Region còn lại là Passive — nó vẫn phục vụ đọc cho người dùng ở gần, nhưng mọi thao tác ghi đều phải đi về Region Active. Vì vậy độ trễ đọc trên toàn cầu là tốt, còn độ trễ ghi trên toàn cầu vẫn kém. Việc thiết lập đồng bộ giữa hai Region cũng có độ khó nhất định.
Multi-Region, Active-Active: cả hai (hoặc nhiều) Region đều ở trạng thái Active, người dùng được định tuyến (ví dụ qua Route 53 Latency Routing) tới Region gần họ nhất để đọc/ghi. Đây là mô hình có độ trễ toàn cầu thấp nhất, nhưng cũng là mô hình phức tạp nhất để xây dựng, vì cần cơ chế đồng bộ dữ liệu (data synchronization) đáng tin cậy giữa các Region để tránh xung đột dữ liệu.

Không có một mô hình nào “đúng” cho tất cả — lựa chọn phụ thuộc vào yêu cầu thực tế về độ sẵn sàng, độ trễ chấp nhận được, và ngân sách/độ phức tạp kỹ thuật mà tổ chức có thể duy trì.

Tổng kết chương

Vì sao cần ứng dụng toàn cầu: giảm độ trễ cho người dùng ở xa, có kế hoạch Disaster Recovery, và tăng khả năng chống chịu tấn công.
Route 53: dịch vụ DNS được quản lý, hỗ trợ nhiều loại record (A, AAAA, CNAME, Alias) và nhiều chính sách định tuyến (Simple, Weighted, Latency, Failover).
CloudFront: CDN toàn cầu, cache nội dung tại edge location, hỗ trợ nhiều loại Origin (S3 với OAC, VPC Origin, ALB/NLB/EC2, Custom HTTP), tích hợp Shield/WAF chống DDoS.
CloudFront vs S3 CRR: CloudFront cho nội dung tĩnh cache toàn cầu; S3 CRR cho dữ liệu cập nhật gần real-time ở một số region cụ thể.
S3 Transfer Acceleration: tăng tốc upload/download vào S3 bằng cách đi qua edge location trước, sau đó dùng mạng riêng của AWS.
AWS Global Accelerator: 2 IP Anycast cố định, proxy traffic TCP/UDP qua mạng riêng AWS tới ứng dụng ở một hoặc nhiều Region, không cache — khác CloudFront (có cache, chỉ phù hợp nội dung cache được).
AWS Outposts: mang hạ tầng AWS về đặt tại trung tâm dữ liệu của khách hàng (hybrid cloud).
AWS WaveLength: đặt hạ tầng AWS ngay tại biên mạng 5G của nhà mạng viễn thông, phục vụ ứng dụng cần độ trễ siêu thấp.
AWS Local Zones: mở rộng một AWS Region tới gần các thành phố lớn, phục vụ ứng dụng nhạy cảm với độ trễ mà không cần tự quản lý hạ tầng.
Kiến trúc toàn cầu: đi từ Single Region/Single AZ đơn giản tới Multi-Region Active-Active phức tạp, đánh đổi giữa độ sẵn sàng/độ trễ và độ khó vận hành.