Thiết kế kiến trúc mạng được tối ưu chi phí trên AWS

NAT Gateway, hay Network Address Translation Gateway, cho phép resource trong private subnet truy cập internet hoặc các AWS services khác mà không cần public IP. Đây là một thành phần rất phổ biến trong VPC architecture, nhưng cũng là nơi dễ phát sinh chi phí nếu cấu hình không hợp lý.

1.1 Một NAT Gateway dùng chung duy nhất

Cách đơn giản nhất là tạo một NAT Gateway trong một Availability Zone (AZ), sau đó cho nhiều private subnet dùng chung. Với workload nhỏ, dev environment hoặc hệ thống không quá quan trọng, cách này thường tiết kiệm chi phí hơn.

Nhưng bạn cần hiểu trade-off. Nếu AZ chứa NAT Gateway gặp sự cố, các resource ở AZ khác có thể mất đường ra internet. Ngoài ra, traffic từ nhiều AZ đi qua cùng một NAT Gateway có thể tạo bottleneck và làm phát sinh thêm data transfer cost giữa các AZ.

Nói dễ hiểu, một NAT Gateway dùng chung giống như cả tòa nhà chỉ có một cổng ra. Rẻ, đơn giản, dễ quản lý, nhưng nếu cổng đó bị chặn thì mọi người đều bị ảnh hưởng.

1.2 NAT Gateway cho từng Availability Zone

Một thiết kế tốt hơn cho production workload là tạo NAT Gateway riêng trong từng AZ. Khi đó, private subnet trong AZ nào sẽ đi ra internet thông qua NAT Gateway của chính AZ đó.

Cách này giúp tăng availability, giảm rủi ro single point of failure và hạn chế traffic đi chéo giữa các AZ. Điểm cần lưu ý là chi phí sẽ cao hơn, vì bạn phải trả tiền cho nhiều NAT Gateway cùng lúc.

1.3 NAT Instance

NAT Instance là cách cũ hơn, sử dụng một EC2 instance để thực hiện chức năng NAT.

NAT Instance cho bạn nhiều quyền kiểm soát hơn, ví dụ có thể tự cấu hình, tự tối ưu hoặc tự quản lý firewall rule. Tuy nhiên, bạn cũng phải tự chịu trách nhiệm về scaling, patching, monitoring và high availability. Với phần lớn use case hiện nay, NAT Gateway vẫn là lựa chọn đơn giản, managed và được khuyến nghị hơn.

1.4 Cân nhắc chi phí cho NAT Gateway

  • Mức sử dụng theo giờ: Bạn trả phí cho mỗi giờ NAT Gateway được tạo và đang hoạt động.
  • Xử lý dữ liệu: Bạn trả phí cho mỗi GB data được xử lý qua NAT Gateway.
  • Truyền dữ liệu ra ngoài: Nếu traffic đi ra internet, bạn còn có thể phát sinh thêm data transfer out cost.

Khi kết nối hệ thống on-premises hoặc network bên ngoài vào AWS, bạn cần chọn đúng kiểu kết nối. Mỗi lựa chọn sẽ có sự khác nhau về cost, performance, security và reliability.

2.1 Internet

Kết nối đến AWS qua public internet là cách đơn giản nhất. Đây thường là lựa chọn phù hợp cho workload nhỏ, môi trường test/dev hoặc ứng dụng không yêu cầu bandwidth cao và latency thấp.

Nhược điểm là public internet không ổn định bằng kết nối chuyên dụng, và mức độ kiểm soát về security cũng thấp hơn so với VPN hoặc AWS Direct Connect.

2.2 VPN (Virtual Private Network)

AWS VPN cho phép bạn tạo kết nối được mã hóa giữa on-premises network và Amazon VPC thông qua internet.

VPN phù hợp khi bạn cần kết nối bảo mật nhưng chưa cần bandwidth quá lớn hoặc latency cực thấp. Về chi phí, VPN thường cao hơn public internet thông thường, nhưng rẻ hơn AWS Direct Connect.

2.3 AWS Direct Connect

AWS Direct Connect cung cấp kết nối mạng chuyên dụng giữa on-premises data center và AWS.

Direct Connect cho performance ổn định hơn, latency thấp hơn và bandwidth cao hơn so với VPN hoặc public internet. Đây là lựa chọn đắt hơn, nhưng rất phù hợp cho enterprise workload, hybrid cloud, data migration lớn hoặc ứng dụng yêu cầu network ổn định.

2.4 Cân nhắc chi phí cho kết nối mạng

  • Truyền dữ liệu: Data transfer cost phụ thuộc vào hướng truyền dữ liệu, Region và loại kết nối bạn sử dụng.
  • Giờ port của Direct Connect: Với Direct Connect, bạn trả phí theo giờ cho mỗi port được provision.
  • Giờ kết nối VPN: Với VPN, bạn trả phí theo giờ cho mỗi VPN connection đang hoạt động.

2.5 Chọn kết nối mạng phù hợp

Để chọn đúng loại kết nối, hãy bắt đầu bằng các câu hỏi sau:

  • Yêu cầu băng thông: Bạn cần truyền bao nhiêu data giữa on-premises và AWS?
  • Yêu cầu độ trễ: Ứng dụng của bạn có nhạy cảm với latency hay không?
  • Yêu cầu bảo mật: Bạn có cần encrypted connection hoặc private connection không?
  • Ngân sách: Bạn có thể chi bao nhiêu cho network connectivity mỗi tháng?

Trong AWS, data transfer cost phụ thuộc rất nhiều vào traffic đi từ đâu đến đâu. Vì vậy, route design là một phần quan trọng khi tối ưu network cost.

3.1 Region sang Region

Data transfer giữa các AWS Region khác nhau thường phát sinh chi phí. Nếu workload truyền nhiều data liên tục giữa các Region, chi phí có thể tăng rất nhanh.

Nguyên tắc đơn giản là: nếu các resource cần nói chuyện với nhau thường xuyên, hãy cố gắng đặt chúng trong cùng một Region, trừ khi bạn có yêu cầu rõ ràng về disaster recovery, global availability hoặc compliance.

3.2 Availability Zone (AZ) sang Availability Zone

Data transfer giữa các Availability Zone trong cùng một Region cũng có thể phát sinh chi phí. Chi phí này thường thấp hơn inter-Region transfer, nhưng vẫn đáng chú ý nếu traffic lớn.

Với production workload, bạn vẫn nên triển khai multi-AZ để có high availability. Tuy nhiên, hãy thiết kế sao cho các resource giao tiếp thường xuyên được đặt gần nhau nhất có thể, nhằm giảm lượng traffic đi chéo giữa các AZ.

3.3 Private sang public

Khi resource trong VPC truy cập public endpoint, traffic có thể đi qua internet path hoặc NAT Gateway, từ đó phát sinh thêm cost.

Nếu resource trong private subnet cần truy cập AWS services như S3 hoặc DynamoDB, bạn nên cân nhắc dùng VPC Endpoint thay vì để traffic đi qua NAT Gateway. Đây là một cách rất phổ biến để giảm cost và tăng security.

3.4 VPC Endpoints

VPC Endpoint cho phép resource trong VPC kết nối riêng tư đến các AWS services được hỗ trợ, ví dụ Amazon S3, Amazon DynamoDB hoặc nhiều AWS services khác, mà không cần đi qua public internet.

Lợi ích chính là traffic riêng tư hơn, security tốt hơn và trong nhiều trường hợp có thể giúp giảm NAT Gateway cost hoặc data transfer cost.

Có hai loại VPC Endpoint:

Interface Endpoints: Đây là các Elastic Network Interface (ENI) được đặt trong subnet của bạn, dùng để kết nối private đến một AWS service.

Gateway Endpoints: Đây là gateway được gắn vào route table, thường dùng cho Amazon S3Amazon DynamoDB.

3.5 AWS Global Accelerator

AWS Global Accelerator giúp cải thiện performance cho ứng dụng global bằng cách đưa traffic của user vào AWS global network càng sớm càng tốt.

Dịch vụ này có thêm chi phí theo giờ và data transfer, nhưng có thể mang lại giá trị nếu ứng dụng của bạn phục vụ user ở nhiều quốc gia và cần latency ổn định.

Ví dụ:

  • Nếu user của bạn ở nhiều khu vực trên thế giới, Global Accelerator có thể giúp giảm latency và cải thiện trải nghiệm truy cập ứng dụng.
  • Global Accelerator cũng giúp traffic được định tuyến tối ưu hơn trên AWS global network, đặc biệt hữu ích khi ứng dụng chạy ở nhiều Region.

CDN như Amazon CloudFront giúp đưa nội dung đến gần user hơn. Kết quả là latency thấp hơn, origin server nhẹ hơn và chi phí truyền dữ liệu có thể được tối ưu tốt hơn.

CDN (Content Delivery Network): CDN lưu bản sao nội dung như image, video, file tĩnh hoặc static website tại các edge location trên toàn cầu. Khi user truy cập, nội dung sẽ được phục vụ từ edge location gần nhất thay vì phải quay về origin mỗi lần.

Edge caching: Edge caching giúp cache nội dung ở gần user. Điều này đặc biệt hiệu quả với nội dung được truy cập nhiều lần, vì nó giảm số request quay về origin và có thể giúp giảm data transfer cost.

Khi đánh giá có nên dùng CDN hay không, hãy xem xét các yếu tố sau:

  • Phân bố địa lý của người dùng: Nếu user nằm ở nhiều quốc gia hoặc nhiều khu vực, CDN gần như luôn là một lựa chọn đáng cân nhắc.
  • Loại nội dung: CDN hiệu quả nhất với static content hoặc nội dung ít thay đổi.
  • Tần suất truy cập nội dung: Nội dung càng được truy cập thường xuyên, caching càng mang lại nhiều lợi ích.

Hãy hình dung CDN giống như đặt nhiều kho hàng nhỏ gần khách hàng. Khách ở đâu thì lấy hàng từ kho gần đó, thay vì lần nào cũng phải quay về kho trung tâm.

Network cost không nên được xem một lần rồi bỏ đó. Bạn nên thường xuyên review workload để tìm ra traffic pattern bất thường, route chưa tối ưu hoặc resource đang gây chi phí cao.

Dưới đây là những khu vực quan trọng cần kiểm tra.

5.1 Chi phí truyền dữ liệu

Hãy phân tích data transfer trong cùng VPC, giữa các AZ, giữa các Region và từ AWS ra internet. Sau đó, tìm cách giảm chi phí bằng những hướng sau:

  • Đặt tài nguyên gần nhau: Resource nào giao tiếp thường xuyên thì nên đặt trong cùng AZ hoặc cùng Region khi phù hợp.
  • Sử dụng VPC Endpoint: Cho phép private subnet truy cập các AWS services như S3 và DynamoDB mà không cần đi qua public internet hoặc NAT Gateway.
  • Nén dữ liệu: Giảm kích thước data trước khi truyền để giảm bandwidth usage và data transfer cost.

Elastic IP addresses: Kiểm tra các Elastic IP address không còn sử dụng và release chúng để tránh phát sinh chi phí không cần thiết.

Mẫu lưu lượng mạng: Dùng các công cụ như VPC Flow Logs để hiểu traffic đang đi đâu, từ đó phát hiện bottleneck, traffic bất thường hoặc route chưa tối ưu.

Kết nối VPN: Review mức sử dụng VPN connection. Nếu connection thường xuyên sử dụng thấp, bạn có thể cân nhắc resize, consolidate hoặc thay đổi kiến trúc kết nối.

Kết nối Direct Connect: Theo dõi bandwidth usage của Direct Connect. Nếu sử dụng thấp trong thời gian dài, có thể cân nhắc giảm capacity hoặc dùng VPN cho một số use case ít quan trọng hơn.

Mức sử dụng NAT Gateway: Vì NAT Gateway tính phí theo GB data processed, bạn nên kiểm tra service nào đang tạo nhiều traffic qua NAT Gateway. Trong một số trường hợp, VPC Endpoint có thể giúp giảm đáng kể phần chi phí này.

Throttling là cách kiểm soát tốc độ request hoặc network traffic để tránh quá tải hệ thống và hạn chế chi phí tăng đột biến.

Khi chọn throttling strategy, hãy đi theo các bước sau.

6.1 Xác định điểm nghẽn

Trước tiên, hãy xác định bottleneck nằm ở đâu. Đó có thể là application, API, database, NAT Gateway, VPN connection hoặc một network device cụ thể.

6.2 Chọn cơ chế throttling phù hợp

AWS cung cấp nhiều cách để kiểm soát traffic, bao gồm:

  • Network ACLs (NACLs): Dùng để allow hoặc deny traffic dựa trên IP address, port và protocol ở subnet level.
  • Security Groups: Hoạt động như virtual firewall cho EC2 instance và các resource khác, kiểm soát inbound và outbound traffic.
  • AWS WAF: Bảo vệ web application khỏi malicious traffic và có thể dùng rate-based rule để giới hạn request.
  • API Gateway throttling: Kiểm soát tốc độ request đến API, giúp bảo vệ backend service khỏi bị quá tải.

6.3 Đặt giới hạn phù hợp

Giới hạn throttling nên dựa trên capacity thực tế của hệ thống và nhu cầu của application. Đừng đặt quá thấp khiến user bị ảnh hưởng, nhưng cũng đừng đặt quá cao khiến backend dễ bị quá tải.

6.4 Giám sát và điều chỉnh

Sau khi bật throttling, hãy theo dõi metric, log và user experience để điều chỉnh giới hạn cho phù hợp.

Throttling đặc biệt hữu ích khi traffic tăng đột ngột, vì nó giúp bảo vệ hệ thống và hạn chế chi phí ngoài dự kiến từ data transfer hoặc số lượng request.

Bandwidth planning giúp bạn cân bằng giữa cost và performance. Nếu cấp quá ít bandwidth, ứng dụng chậm. Nếu cấp quá nhiều, bạn trả tiền cho capacity không dùng đến.

7.1 Kết nối VPN

Một VPN: Một VPN connection có thể đủ cho workload nhỏ hoặc nhu cầu bandwidth thấp đến trung bình. Tuy nhiên, bạn cần cân nhắc rủi ro single point of failure.

Nhiều VPN: Nhiều VPN connection có thể tăng availability, redundancy và trong một số trường hợp giúp tăng tổng bandwidth. Đổi lại, chi phí và độ phức tạp vận hành sẽ cao hơn.

Cân nhắc băng thông tổng hợp: Nếu cần tổng bandwidth cao nhưng vẫn muốn kiểm soát chi phí, nhiều VPN connection có thể là một lựa chọn đáng cân nhắc trước khi chuyển sang Direct Connect.

7.2 Direct Connect

Tốc độ Direct Connect: Chọn Direct Connect speed dựa trên bandwidth requirement hiện tại và dự báo tăng trưởng. Direct Connect hỗ trợ nhiều mức tốc độ khác nhau, từ 1 Gbps đến 100 Gbps.

Vị trí Direct Connect: Chọn Direct Connect location gần on-premises network để giảm latency và cải thiện performance.

Dự phòng Direct Connect: Với workload quan trọng, nên dùng nhiều Direct Connect connection hoặc nhiều location để tăng high availability.

7.3 Các yếu tố cần cân nhắc thêm

Mẫu lưu lượng: Phân tích traffic pattern để biết bandwidth thực sự cần là bao nhiêu, đặc biệt trong peak time và các giai đoạn tăng trưởng.

Chi phí so với hiệu năng: Luôn so sánh giữa chi phí tăng thêm và lợi ích performance nhận được. Không phải workload nào cũng cần kết nối nhanh nhất hoặc đắt nhất.

7.4 Ví dụ

Nếu bạn cần khoảng 500 Mbps ổn định giữa on-premises và AWS, bạn có thể cân nhắc nhiều VPN connection để có redundancy. Cách này có thể phù hợp hơn về chi phí nếu workload chưa thật sự cần Direct Connect 1 Gbps.

Nhưng nếu bạn dự đoán traffic sẽ sớm vượt 1 Gbps, hoặc workload yêu cầu latency thấp và network performance ổn định, bắt đầu với Direct Connect có thể là lựa chọn dài hạn tốt hơn.