Trong bài viết này, chúng ta sẽ đi sâu vào từng thành phần của AWS Global Infrastructure:
- Regions
- Availability Zones
- Edge Locations
- Regional Edge Caches
- Local Zones
- Wavelength Zones
- AWS Outposts
Đặc biệt, mình sẽ đề cập đến những điểm đặc biệt liên quan đến Việt Nam để bạn có thể áp dụng ngay vào dự án của mình.
AWS Regions - Nền Tảng Địa Lý Của Cloud
Region là gì?
AWS Region là một khu vực địa lý độc lập hoàn toàn, nơi AWS triển khai các data center và dịch vụ cloud của mình. Mỗi Region được thiết kế để hoạt động độc lập với các Region khác, đảm bảo khả năng chịu lỗi (fault tolerance) và tính ổn định cao nhất.
Hiện tại (2026), AWS đang vận hành 39 Geographic Regions trên toàn cầu với 123 Availability Zones phân bố khắp các châu lục. Để tiếp tục đáp ứng nhu cầu ngày càng tăng, AWS đã công bố kế hoạch mở rộng với 7 Availability Zones bổ sung và 2 Regions hoàn toàn mới tại Vương quốc Ả Rập Saudi (Kingdom of Saudi Arabia) và Chile. Mỗi Region được đặt tên theo hai cách:
- Friendly Name: Tên thân thiện dễ nhớ như "Asia Pacific (Singapore)" hoặc "Asia Pacific (Tokyo)"
- Code Name: Tên mã để sử dụng khi code như
ap-southeast-1 (Singapore) hoặc ap-northeast-1 (Tokyo)
Tham khảo: https://aws.amazon.com/about-aws/global-infrastructure/regions_az/
Trên AWS Console
Tại sao Region quan trọng?
1. Geographic Proximity - Độ trễ thấp
Khi bạn chọn Region gần với end users, độ trễ (latency) sẽ giảm đáng kể. Ví dụ, nếu startup của bạn phục vụ khách hàng Việt Nam, việc chọn ap-southeast-1 (Singapore) thay vì us-east-1 (Virginia) có thể giảm latency từ 200-300ms xuống còn 30-50ms.
2. Data Compliance - Tuân thủ pháp luật
Nhiều quốc gia có quy định nghiêm ngặt về nơi lưu trữ dữ liệu. Ví dụ, các dự án cho khách hàng Nhật Bản thường yêu cầu data phải nằm trong lãnh thổ Nhật Bản, do đó bạn cần sử dụng ap-northeast-1 (Tokyo) hoặc ap-northeast-3 (Osaka).
3. Service Availability - Dịch vụ khả dụng
Không phải tất cả AWS services đều có sẵn ở mọi Region. Một số services mới thường được ra mắt ở US Regions trước, sau đó mới mở rộng sang các khu vực khác. Điều này ảnh hưởng trực tiếp đến việc thiết kế kiến trúc của bạn.
4. Pricing - Chi phí
Giá cả các dịch vụ AWS khác nhau giữa các Regions. Ví dụ, EC2 instances ở Singapore thường đắt hơn 5-10% so với Oregon (us-west-2), và đắt hơn khoảng 15-20% so với Virginia (us-east-1).
Làm sao để chọn Region phù hợp?
Khi bắt đầu một dự án mới, bạn cần cân nhắc các yếu tố sau theo thứ tự ưu tiên:
- Compliance requirements: Có yêu cầu pháp lý nào về nơi đặt data không?
- User location: Khách hàng chính của bạn ở đâu?
- Service availability: Các AWS services bạn cần có sẵn ở Region đó không?
- Pricing: Ngân sách dự án của bạn như thế nào?
Ví dụ thực tế: Với dự án CloudExam.pro phục vụ học viên Việt Nam, mình chọn ap-southeast-1 (Singapore) vì:
- Latency thấp nhất cho users ở Việt Nam (30-50ms)
- Đầy đủ services cần thiết (ECS, RDS, S3, CloudFront)
- Chi phí chấp nhận được cho startup
- Không có yêu cầu data residency đặc biệt
Availability Zones - Trái Tim Của High Availability
Availability Zone là gì?
Availability Zone (AZ) là một hoặc nhiều data centers riêng biệt trong cùng một Region, mỗi AZ có hệ thống điện dự phòng, mạng lưới và kết nối độc lập. AWS hiện vận hành hơn 123 Availability Zones trên toàn thế giới, phân bố trong 39 Regions.
Một điểm quan trọng: Nhiều người nghĩ 1 AZ = 1 data center, nhưng thực tế một AZ thường bao gồm nhiều data centers riêng biệt (discrete data centers) đặt gần nhau. Điều này tạo thêm một lớp redundancy (dự phòng) bên trong chính AZ đó.
Thiết kế Availability Zone Independence (AZI)
AWS thiết kế các AZ theo nguyên tắc Availability Zone Independence (AZI) - tức là các AZ hoàn toàn độc lập để tránh "shared fate scenarios" (cùng chung số phận):
Khoảng cách vật lý:
- Các AZ trong cùng Region được đặt cách xa nhau có ý nghĩa (meaningfully distant)
- Khoảng cách: lên đến 60 dặm (~100 km) để tránh các sự cố tương quan
- Đủ gần để sử dụng synchronous replication với latency chỉ vài milliseconds (single-digit millisecond)
Cô lập hoàn toàn về infrastructure:
Các AZ được thiết kế để KHÔNG bị ảnh hưởng đồng thời bởi các tình huống thảm họa chung:
- Mất điện
- Gián đoạn cung cấp nước
- Cô lập cáp quang
- Động đất
- Hỏa hoạn
- Lốc xoáy
- Lũ lụt
Không chia sẻ điểm lỗi chung:
- Máy phát điện (generators) và thiết bị làm mát (cooling equipment) KHÔNG được chia sẻ giữa các AZ
- Mỗi AZ được cung cấp điện từ các trạm biến áp khác nhau (different power substations)
- Đảm bảo nếu một hệ thống hỗ trợ bị lỗi, các AZ khác không bị ảnh hưởng
Kết nối mạng giữa các AZ
Tất cả các AZ trong cùng Region được kết nối bằng:
- High-bandwidth, low-latency networking
- Fully redundant, dedicated metro fiber (cáp quang chuyên dụng hoàn toàn dự phòng)
- Latency: Single-digit millisecond (vài milliseconds, thường 1-2ms)
Mỗi AZ kết nối internet thông qua:
- 2 transit centers (trung tâm truyền tải)
- AWS peer trực tiếp với nhiều tier-1 internet providers
- Đảm bảo khả năng kết nối internet cao nhất
Số lượng AZ theo Region
Mỗi Region có tối thiểu 3 AZs, và nhiều Region lớn có 4-6 AZs. Ví dụ:
ap-southeast-1 (Singapore): 3 AZs (ap-southeast-1a, 1b, 1c)us-east-1 (Virginia): 6 AZs (us-east-1a, 1b, 1c, 1d, 1e, 1f)
Tại sao AZ quan trọng?
AZs là nền tảng để xây dựng High Availability (HA) architecture. Khi bạn deploy resources across multiple AZs, ứng dụng của bạn vẫn tiếp tục hoạt động ngay cả khi một AZ gặp sự cố.
Ví dụ thực tế: Vào tháng 6/2023, ap-southeast-1a (Singapore) gặp sự cố power và network trong vài giờ. Các hệ thống được thiết kế Multi-AZ như:
- Application Load Balancer deployed trên 3 AZs → Tự động chuyển traffic sang 1b và 1c
- RDS Multi-AZ → Database tự động failover sang standby ở AZ khác
- ECS tasks trên 3 AZs → Tasks ở 1a bị terminate, nhưng tasks ở 1b và 1c vẫn phục vụ bình thường
Kết quả: Người dùng không hề bị gián đoạn dịch vụ. Đây chính là giá trị của Availability Zone Independence.
Cách triển khai Multi-AZ đúng cách
Best Practice cho High Availability:
Ví dụ Architecture cho CloudExam.pro
Đặc điểm:
- Khoảng cách vật lý: lên đến 60 dặm giữa các AZ
- Latency giữa AZs: 1-2ms (single-digit millisecond)
- Dedicated metro fiber: Fully redundant
- Độc lập về power, cooling, network
Lưu ý quan trọng về AZ Mapping
AWS maps AZ identifiers khác nhau cho mỗi AWS account. Nghĩa là ap-southeast-1a trong account A có thể không phải là cùng physical AZ với ap-southeast-1a trong account B. Điều này giúp AWS phân bố tài nguyên đều hơn giữa các AZs.
Giải pháp: Nếu bạn cần coordinate resources giữa nhiều accounts, hãy sử dụng AZ ID thay vì AZ name. Ví dụ:
apse1-az1, apse1-az2, apse1-az3 → Consistent across all accountsap-southeast-1a, ap-southeast-1b → Khác nhau giữa các accounts
aws ec2 describe-availability-zones --region ap-southeast-1
Edge Locations - Mạng Lưới Phân Phối Nội Dung Toàn Cầu
Edge Location là gì?
Edge Locations là các điểm hiện diện (Points of Presence - PoPs) của AWS được triển khai tại các thành phố lớn và khu vực đông dân trên toàn thế giới. Hiện tại, AWS có 750+ CloudFront POPs và 15 Regional edge caches, nhiều hơn gấp nhiều lần số lượng Regions.
Điểm khác biệt quan trọng: Edge Locations không phải là nơi bạn deploy infrastructure chính như EC2, RDS hay VPC. Thay vào đó, chúng là cache servers phục vụ cho các dịch vụ content delivery và routing của AWS.
Edge Locations tại Việt Nam
Tin vui cho developers Việt Nam: AWS hiện có 2 Edge Locations tại Việt Nam:
- Hà Nội (Hanoi)
- Thành phố Hồ Chí Minh (Ho Chi Minh City)
Điều này có nghĩa là khi bạn sử dụng CloudFront hoặc các dịch vụ liên quan, content sẽ được cache ngay tại Việt Nam, mang lại trải nghiệm người dùng tốt nhất có thể.
Các dịch vụ sử dụng Edge Locations
1. Amazon CloudFront (CDN)
CloudFront là dịch vụ phổ biến nhất sử dụng Edge Locations. Khi người dùng request content lần đầu, CloudFront sẽ fetch từ Origin (S3, EC2, hoặc on-premises), cache tại Edge Location gần nhất, và serve cho các requests tiếp theo từ cache.
Ví dụ thực tế với CloudExam.pro:
CloudFront tự động route users đến Edge Location gần nhất. Với 2 Edge Locations tại Việt Nam (Hà Nội và TP. Hồ Chí Minh), học viên từ mọi nơi đều được hưởng lợi:
Scenario 1: Học viên ở Hà Nội
Without CloudFront:
User (Hà Nội) → S3 Origin (Singapore) → ~40-50ms latency
Mỗi request đều phải đi Singapore và về
With CloudFront:
Request 1: User (Hà Nội) → Edge Hà Nội → S3 (Singapore) → Edge Hà Nội → User (~50ms)
Request 2+: User (Hà Nội) → Edge Hà Nội → User (5-10ms) ✨
[Cache hit, không cần đi Singapore nữa]
---
Scenario 2: Học viên ở TP. Hồ Chí Minh
Without CloudFront:
User (TP.HCM) → S3 Origin (Singapore) → ~35-45ms latency
With CloudFront:
Request 1: User (TP.HCM) → Edge TP.HCM → S3 (Singapore) → Edge TP.HCM → User (~45ms)
Request 2+: User (TP.HCM) → Edge TP.HCM → User (5-10ms) ✨
---
Scenario 3: Học viên ở Đà Nẵng (miền Trung)
Without CloudFront:
User (Đà Nẵng) → S3 Origin (Singapore) → ~40-50ms latency
With CloudFront:
CloudFront routing: User (Đà Nẵng) → Edge Hà Nội (~15-20ms to Edge)
Request 1: User → Edge Hà Nội → S3 (Singapore) → Edge Hà Nội → User (~60-65ms)
Request 2+: User → Edge Hà Nội → User (15-20ms) ✨
[Vẫn nhanh hơn ~50-70% so với direct S3]
2. Amazon Route 53 (DNS Service)
Route 53 sử dụng Edge Locations để cung cấp DNS resolution với latency thấp. Khi người dùng ở Việt Nam query DNS, request sẽ được xử lý tại Edge Location Hà Nội hoặc TP.HCM thay vì đi ra Singapore hay Tokyo.
3. AWS Global Accelerator
Global Accelerator sử dụng AWS global network và Edge Locations để route traffic theo đường đi tối ưu nhất đến application endpoints, giảm thiểu packet loss và jitter.
4. AWS WAF và AWS Shield
Web Application Firewall (WAF) và Shield (DDoS protection) được triển khai tại Edge Locations để chặn traffic độc hại trước khi nó đến được infrastructure chính của bạn.
CloudFront: Two-Tier Caching Architecture
CloudFront thực tế có hai tầng cache:
Tier 1: Edge Locations (PoPs)
- Số lượng: 750+ locations toàn cầu
- Cache size: Nhỏ hơn (GB - TB)
- Purpose: Serve content với latency thấp nhất
Tier 2: Regional Edge Caches
- Số lượng: ~13 regional caches (ít hơn nhiều)
- Cache size: Lớn hơn nhiều (TB - PB)
- Purpose: Cache layer giữa Edge Locations và Origin
Cách hoạt động:
User Request Flow:
1. User request → Edge Location
2. Cache hit ở Edge? → Yes → Return (fastest)
3. Cache miss ở Edge? → Check Regional Edge Cache
4. Cache hit ở Regional? → Return to Edge → Return to User
5. Cache miss ở Regional? → Fetch from Origin → Cache at Regional + Edge → Return to User
Lợi ích của Regional Edge Caches:
- Content được giữ lâu hơn (higher TTL)
- Giảm tải cho Origin servers
- Cải thiện cache hit ratio tổng thể
- Đặc biệt hữu ích cho nội dung ít được truy cập (long-tail content)
Local Zones - Đưa AWS Đến Gần Bạn Hơn
Local Zone là gì?
AWS Local Zones là phần mở rộng (extension) của một Region, được đặt gần các thành phố lớn để cung cấp dịch vụ compute, storage, database và networking với latency chỉ vài milliseconds (single-digit).
Điểm khác biệt chính:
- Edge Locations: Chỉ cache content, không chạy compute resources
- Local Zones: Cho phép deploy EC2, EBS, RDS và nhiều services khác, giống như trong Region
Hiện tại, AWS có 35+ Local Zones đang hoạt động với 14 locations bổ sung đang được lên kế hoạch (Trong đó có Local Zone HaNoi, VietNam).
https://aws.amazon.com/about-aws/global-infrastructure/localzones/locations/
Available Local Zones
Local Zone Naming Convention
Local Zone code được đặt tên theo format: {region-code}-{city-code}-{number}
Ví dụ:
us-west-2-lax-1a: Los Angeles Local Zone, thuộc Region us-west-2 (Oregon)us-east-1-nyc-1a: New York City Local Zone, thuộc Region us-east-1 (Virginia)ap-southeast-1-bkk-1a: Bangkok Local Zone, thuộc Region ap-southeast-1 (Singapore)
Local Zones tại Đông Nam Á
Bangkok Local Zone (ap-southeast-1-bkk-1a):
- Là Local Zone đầu tiên tại Đông Nam Á
- Connect về parent Region ap-southeast-1 (Singapore)
- Phục vụ customers tại Bangkok và khu vực Thái Lan với ultra-low latency
Local Zone tại Hà Nội - Đã Có Mặt! 🎉
Hanoi Local Zone (ap-southeast-1-han-1a):
- Zone Name:
ap-southeast-1-han-1a - Parent Region: ap-southeast-1 (Singapore)
- Status: Sắp chính thức ra mắt (Announced 2025)
AWS đã công bố việc ra mắt AWS Local Zone tại Việt Nam như một phần trong cam kết đầu tư dài hạn vào chuyển đổi số của đất nước. Theo ông Eric Yeo, Country General Manager của AWS Vietnam, phát biểu tại buổi họp báo ở Hà Nội ngày 19 tháng 2 năm 2025:
"Chúng tôi sẽ tiếp tục hỗ trợ chuyển đổi số của Việt Nam, mở rộng hạ tầng, đầu tư sâu hơn vào phát triển kỹ năng và thúc đẩy việc áp dụng AI có trách nhiệm. Nhìn về phần còn lại của năm 2025 và xa hơn, AWS vẫn cam kết đầu tư dài hạn vào Việt Nam."
AWS Local Zone tại Việt Nam là hạ tầng triển khai mang các dịch vụ AWS compute, storage, database và các dịch vụ khác đến gần hơn với các trung tâm dân cư, công nghiệp và CNTT lớn. Điều này cho phép khách hàng đưa các ứng dụng yêu cầu độ trễ dưới 10 milliseconds đến gần hơn với người dùng cuối hoặc data center tại chỗ.
Lợi ích khi Hà Nội có Local Zone:
- Latency xuống còn dưới 10ms cho applications yêu cầu real-time
- Tuân thủ các yêu cầu về data residency tại Việt Nam
- Cải thiện đáng kể user experience cho gaming, video streaming, fintech apps
- Mở ra cơ hội cho các use cases mới như autonomous vehicles, IoT edge computing
- Hỗ trợ chuyển đổi số cho khu vực công và doanh nghiệp Việt Nam
Bối cảnh mở rộng khu vực:
AWS đã và đang mở rộng sự hiện diện tại ASEAN với:
- Thailand Region: Ra mắt tháng 1/2025
- Malaysia Region: Ra mắt tháng 8/2024
- Vietnam Local Zone: Thông báo ra mắt 2025 (nhưng tại thời điểm 1/2026 vẫn chưa hoàn thành)
Đây là minh chứng cho cam kết của AWS trong việc đáp ứng nhu cầu khách hàng về độ trễ thấp, hiệu suất được cải thiện và thúc đẩy tăng năng suất cho khách hàng trong khu vực.
Use Cases cho Local Zones
1. Real-time Gaming
Traditional Architecture:
Game Server in Singapore → Player in Hanoi
Latency: 40-50ms → Noticeable lag, poor experience
With Local Zone in Hanoi:
Game Server in Hanoi Local Zone → Player in Hanoi
Latency: dưới 5ms → Smooth gameplay, competitive advantage
2. Live Video Streaming & Content Creation
Các nhà sáng tạo nội dung (streamers, video editors) có thể upload và process video tại Local Zone gần họ, giảm thời gian upload và rendering.
3. Financial Services & Low-Latency Trading
Fintech applications yêu cầu latency cực thấp cho transaction processing có thể deploy tại Local Zone để đảm bảo competitive advantage.
4. Healthcare & Telemedicine
Medical imaging applications, telemedicine platforms cần xử lý data với latency thấp để đảm bảo real-time diagnosis và consultation.
Cách sử dụng Local Zones
Tham khảo: Getting started with AWS Local Zones
Wavelength Zones - AWS Meets 5G
Wavelength Zone là gì?
AWS Wavelength Zones là infrastructure được nhúng trực tiếp vào data centers của các nhà mạng 5G như Verizon, KDDI, SK Telecom, Vodafone. Điều này cho phép developers xây dựng applications có thể deliver ultra-low latency (dưới 10ms) cho mobile users và IoT devices kết nối qua mạng 5G.
Điểm đặc biệt: Traffic từ 5G devices đến Wavelength resources không bao giờ rời khỏi mạng của nhà mạng, giảm thiểu network hops và loại bỏ hoàn toàn public internet path.
https://aws.amazon.com/wavelength/locations/
Wavelength Zones Naming
Format: {region-code}-{carrier-code}-{city-code}-{number}
Ví dụ:
us-east-1-wl1-bos-wlz-1: Verizon Wavelength ở Bostonap-northeast-1-wl1-nrt-wlz-1: KDDI Wavelength ở Tokyoeu-west-2-wl1-lon-wlz-1: Vodafone Wavelength ở London
Wavelength tại châu Á
Nhật Bản - KDDI Wavelength:
- Tokyo:
ap-northeast-1-wl1-nrt-wlz-1 - Osaka:
ap-northeast-1-wl1-kix-wlz-1
Hàn Quốc - SK Telecom Wavelength:
- Seoul:
ap-northeast-2-wl1-cjj-wlz-1
Việt Nam - Tương lai của Wavelength?
Việt Nam đang tích cực triển khai hạ tầng 5G với các nhà mạng lớn như Viettel, VNPT, MobiFone. Khi hạ tầng 5G trở nên phổ biến, việc AWS hợp tác với các nhà mạng Việt Nam để mở Wavelength Zones là một triển vọng đầy hứa hẹn.
Use Cases cho Wavelength
1. Interactive Live Video Streaming
- Streamers có thể broadcast với latency dưới 100ms
- Viewers tương tác real-time không bị delay
2. Augmented Reality (AR) / Virtual Reality (VR)
- AR navigation applications
- VR gaming và entertainment
- Industrial AR for training và maintenance
3. Connected Vehicles & Autonomous Driving
- Vehicle-to-Everything (V2X) communication
- Real-time traffic updates và routing
- Safety-critical applications
4. Industrial IoT & Smart Manufacturing
- Real-time monitoring và control
- Predictive maintenance
- Quality control với AI/ML
AWS Outposts - Đưa AWS Về On-Premises
AWS Outposts là gì?
AWS Outposts là một giải pháp fully managed cho phép bạn chạy AWS infrastructure, services và APIs ngay tại on-premises data center của mình. Đây là cách AWS "đưa cloud về nhà" cho những khách hàng có yêu cầu đặc biệt về data residency, low latency hoặc local data processing.
Các hình thức Outposts
1. Outposts Rack (42U rack)
- Full rack 42U
- Scale từ 1 rack đến 96 racks
- Phù hợp cho large deployments
2. Outposts Servers (1U/2U servers)
- Rack-mountable servers
- Phù hợp cho smaller deployments, edge locations
- Space-constrained environments
Outposts hoạt động như thế nào?
On-Premises Data Center
├── AWS Outpost Rack(s)
│ ├── EC2 instances (M5, C5, R5, G4)
│ ├── EBS volumes
│ ├── S3 on Outposts
│ ├── RDS on Outposts
│ ├── ECS/EKS clusters
│ └── ELB
│
└── Connect to AWS Region
├── Via AWS Direct Connect (recommended)
└── Via VPN (alternative)
Access to:
├── DynamoDB (via PrivateLink)
├── S3 (Region)
├── All other AWS services
└── AWS Management Console
Use Cases cho Outposts
1. Data Residency Requirements
Ngành ngân hàng, chính phủ, y tế thường có quy định nghiêm ngặt về nơi lưu trữ dữ liệu. Outposts cho phép bạn giữ data tại on-premises trong khi vẫn sử dụng AWS services.
2. Low Latency Applications
Manufacturing plants, hospitals, hoặc facilities cần xử lý data với latency cực thấp (dưới 1ms) có thể dùng Outposts để đưa compute gần với data sources.
3. Hybrid Cloud Strategy
Doanh nghiệp có legacy systems on-premises nhưng muốn dần dần migrate lên cloud có thể sử dụng Outposts như một bước trung gian.
4. Disconnected Environments
Outposts có thể hoạt động trong "disconnected mode" trong thời gian ngắn khi connection tới AWS Region bị gián đoạn, đảm bảo business continuity.
Dedicated Outposts
AWS Dedicated Outposts (announced 2023) là phiên bản Outposts dành riêng cho một khách hàng hoặc community, thường dùng trong public sector hoặc highly regulated industries.
Đặc điểm:
- Completely isolated infrastructure
- Có thể deploy tại customer's facility
- Meet strict security và compliance requirements
- Mission-critical workloads
Mối Quan Hệ Giữa Các Components
Sơ đồ phân cấp
AWS Global Infrastructure
│
├── AWS Regions (39 regions worldwide)
│ │
│ ├── Availability Zones (3-6 AZs per Region)
│ │ └── Multiple Data Centers per AZ
│ │
│ ├── Local Zones (Extension of Region)
│ │ └── Single-digit millisecond latency
│ │
│ └── Wavelength Zones (Inside telco 5G networks)
│ └── Ultra-low latency for 5G devices
│
├── Edge Locations (750+ locations globally)
│ ├── CloudFront PoPs
│ └── Regional Edge Caches (13 locations)
│
└── AWS Outposts (Customer premises)
└── On-premises AWS infrastructure
So sánh nhanh
| Component | Số lượng | Mục đích chính | Latency Target | Deploy Infrastructure |
|---|
| Regions | 39 | Geographic isolation, compliance | 50-300ms (inter-region) | ✅ Full |
| Availability Zones | 123+ | High availability, fault tolerance | dưới 2ms (intra-region) | ✅ Full |
| Edge Locations | 750+ | Content caching, CDN | 5-20ms | ❌ Cache only |
| Regional Edge Cache | ~13 | Secondary cache layer | 10-30ms | ❌ Cache only |
| Local Zones | 35+ (49 planned) | Ultra-low latency in cities | dưới 5ms | ✅ Limited services |
| Wavelength Zones | 30+ | 5G ultra-low latency | dưới 10ms | ✅ Limited services |
| Outposts | Custom | On-premises hybrid cloud | dưới 1ms (local) | ✅ On-premises |
Best Practices tổng quát
1. Always deploy Multi-AZ cho production
Single AZ = Single Point of Failure ❌
Multi-AZ = High Availability ✅
2. Sử dụng CloudFront cho static content
Benefit cho users Việt Nam:
- Latency giảm
- Bandwidth cost giảm (CloudFront rẻ hơn direct S3)
- Better user experience = Higher conversion rate
3. Chọn Region gần users, backup ở Region xa
Primary: ap-southeast-1 (Singapore) - serve Vietnam
DR: ap-northeast-1 (Tokyo) - geographic diversity
4. Chuẩn bị cho future: Local Zones và Wavelength
Khi AWS mở rộng Local Zones và Wavelength tại Việt Nam, bạn nên:
- Thiết kế architecture linh hoạt, dễ dàng mở rộng
- Sử dụng Infrastructure as Code (CloudFormation, Terraform)
- Document clear migration strategy
Kết luận
AWS Global Infrastructure là một hệ sinh thái phức tạp nhưng được thiết kế rất tốt để phục vụ mọi nhu cầu từ startup nhỏ đến enterprise lớn. Việc hiểu rõ từng component và cách chúng hoạt động cùng nhau là nền tảng quan trọng để:
- Thiết kế architecture có tính sẵn sàng cao: Multi-AZ và Multi-Region strategies
- Tối ưu chi phí: Chọn Region phù hợp, sử dụng CloudFront hiệu quả
- Cải thiện performance: Leverage Edge Locations, Local Zones và Wavelength
- Đáp ứng compliance: Data residency với Regions, Outposts
Đối với developers và solutions architects tại Việt Nam:
✅ Hiện tại: Tận dụng ap-southeast-1 (Singapore) + 2 Edge Locations (Hanoi, HCMC)
🚀 Tương lai: Chuẩn bị cho Local Zone tại Hà Nội và Wavelength với nhà mạng Việt Nam
📚 Học tập: Những concepts này là core knowledge cho mọi AWS certifications (SAA, SOA, DVA, SAP)
Hy vọng bài viết này giúp bạn hiểu rõ hơn về AWS Global Infrastructure và áp dụng được vào các dự án thực tế của mình.
Về tác giả: Mình là Phong - Hiện là Cloud Solutions Architect với hơn 5 năm kinh nghiệm triển khai các dự án cloud cho khách hàng Nhật Bản. Founder của CloudExam.pro - nền tảng luyện thi AWS certifications bằng tiếng Việt.
Tham khảo thêm:
