NAT Gateway tính hai khoản cộng dồn: phí theo giờ cho mỗi NAT Gateway đang tồn tại, và phí xử lý dữ liệu theo GB cho mọi byte đi qua nó — cả chiều ra lẫn chiều vào. Traffic tới S3 qua NAT vẫn nằm trong AWS nhưng vẫn bị tính phí xử lý, đó là lý do hoá đơn tăng dù không có băng thông internet nào thật sự.
Tối ưu:
1. Gateway endpoint cho S3 và DynamoDB — miễn phí, không tính phí xử lý dữ liệu. Nó chỉ thêm route vào route table của subnet để traffic đi thẳng tới service, bỏ hẳn NAT khỏi đường đi. Đây là biện pháp hiệu quả nhất cho tình huống này và nên coi là cấu hình mặc định.
2. Interface endpoint (PrivateLink) cho các service khác (ECR, Secrets Manager, CloudWatch Logs, STS…). Loại này có phí giờ và phí GB, nhưng thường vẫn rẻ hơn NAT khi lượng dữ liệu lớn — phải tính chứ đừng mặc định bật hết.
3. Đúng số lượng NAT Gateway. Mỗi AZ một NAT là chuẩn cho tính sẵn sàng; dùng chung một NAT cho nhiều AZ vừa rẻ hơn vừa thêm phí truyền dữ liệu cross-AZ và tạo điểm hỏng chung. Ở môi trường dev/staging thì một NAT dùng chung, hoặc tắt ngoài giờ, là đánh đổi hợp lý.
4. Kiểm tra ai đang đẩy traffic. Bật VPC Flow Logs rồi truy ra IP/ENI tiêu thụ nhiều nhất; thường lộ ra thứ không ngờ: pull image Docker mỗi lần khởi động task, đẩy log, hoặc job đồng bộ dữ liệu chạy quá dày.
Nguyên tắc chung để nhớ: traffic ở lại trong AWS thì tìm đường không đi qua NAT.