CloudFront có thể giảm chi phí egress như thế nào

Data transfer ra internet là một trong những dòng chi phí khó đoán nhất trên hóa đơn AWS. Nó tăng theo số người dùng, theo kích thước file, và thường nằm rải rác ở nhiều service khác nhau như EC2, Elastic Load Balancing hay S3. Bài viết này giải thích vì sao việc đưa traffic ra internet qua CloudFront có thể làm khoản này giảm đáng kể, khi nào nó không giúp được gì, và cách đo trước khi quyết định.

Egress được tính phí như thế nào

Khi một EC2 instance, một Application Load Balancer hay một S3 bucket trả dữ liệu trực tiếp cho người dùng trên internet, AWS tính phí data transfer out theo từng GB. Tại us-east-1, tại thời điểm viết bài, mức giá cho 10 TB đầu tiên mỗi tháng là khoảng $0.09/GB, và một số region ở châu Á có mức cao hơn. Bạn nên kiểm tra bảng giá của region mình đang dùng, vì đây là con số quyết định phần lớn phép tính bên dưới.

Khi cùng lượng dữ liệu đó đi qua CloudFront, cách tính thay đổi ở hai điểm:

• Dữ liệu từ origin trên AWS tới CloudFront không tính phí. Trang giá CloudFront ghi rõ việc fetch từ bất kỳ origin nào trên AWS (S3, EC2, Elastic Load Balancing) là miễn phí. Bạn chỉ trả phí data transfer từ edge của CloudFront tới người dùng.
• Mức giá egress của CloudFront thấp hơn ở nhiều khu vực, và có free tier riêng. Mỗi tháng CloudFront miễn phí 1 TB data transfer ra internet và 10 triệu request. Sau đó, giá cho 9 TB tiếp theo là $0.085/GB tại Mỹ và châu Âu, $0.120/GB tại nhóm Singapore, Việt Nam, Thái Lan và các nước lân cận.

5.000 GB × $0.09                    ≈ $450 / tháng

1.000 GB đầu tiên                   = $0 (free tier)
4.000 GB × $0.085                   ≈ $340 / tháng
Origin fetch từ ALB tới CloudFront  = $0

Cache hit ratio là đòn bẩy chính

Giá egress rẻ hơn chỉ là một phần. Phần lớn giá trị của CloudFront đến từ việc response được trả từ cache ở edge thay vì quay về origin. Mỗi request được phục vụ từ cache không tạo ra tải cho EC2, không đi qua ALB, không phát sinh request tới S3.

Với các hệ thống chúng tôi xem qua, cache hit ratio thấp hiếm khi do nội dung thực sự không cache được. Nguyên nhân thường nằm ở cấu hình:

• Cache key chứa quá nhiều thành phần. Nếu toàn bộ query string, cookie hoặc header được đưa vào cache key, mỗi biến thể nhỏ, ví dụ một tham số tracking như utm_source, sẽ tạo ra một object riêng trong cache. Cache policy nên chỉ giữ lại những thành phần thực sự làm thay đổi nội dung response.
• Origin trả về header ngăn cache. Các framework web thường mặc định gửi Cache-Control: no-cache hoặc private cho mọi response. Với static asset và các trang công khai, bạn cần đặt Cache-Control rõ ràng ở origin, hoặc đặt TTL trong cache policy.
• File không có version trong tên. Khi tên file không đổi giữa các lần deploy, đội thường đặt TTL ngắn để tránh nội dung cũ. Đặt hash vào tên file (app.3f9a2c.js) cho phép đặt TTL dài và gần như không bao giờ phải invalidate.

resource "aws_cloudfront_cache_policy" "static" {
  name        = "static-assets"
  default_ttl = 86400
  max_ttl     = 31536000
  min_ttl     = 0
 
  parameters_in_cache_key_and_forwarded_to_origin {
    cookies_config       { cookie_behavior = "none" }
    headers_config       { header_behavior = "none" }
    query_strings_config { query_string_behavior = "none" }
    enable_accept_encoding_gzip   = true
    enable_accept_encoding_brotli = true
  }
}

CloudFront có sẵn báo cáo cache statistics cho từng distribution, cho biết tỷ lệ hit, miss và error theo thời gian. Đây là chỉ số nên theo dõi trước và sau mỗi thay đổi cấu hình.

Origin Shield và price class

Hai tùy chọn này thường bị bỏ qua, nhưng có thể ảnh hưởng tới chi phí theo hai hướng ngược nhau.

Origin Shield thêm một lớp cache trung gian giữa các edge location và origin. Khi người dùng ở nhiều khu vực cùng yêu cầu một object, chỉ một request quay về origin thay vì mỗi edge một request. Origin Shield tính thêm phí theo request (tại Mỹ khoảng $0.0075 cho mỗi 10.000 request), nên nó có lợi khi origin đắt hoặc yếu, ví dụ origin phải render nội dung, hoặc traffic phân tán trên nhiều khu vực. Với một origin S3 đơn giản và traffic tập trung ở một khu vực, khoản phí thêm này có thể không đáng.

Price class giới hạn những khu vực edge mà CloudFront dùng. Price Class 100 chỉ dùng edge ở Mỹ, Canada, Mexico và châu Âu. Price Class 200 thêm châu Á, Nhật Bản, Ấn Độ, Trung Đông và châu Phi. Nếu người dùng chủ yếu ở Việt Nam, Price Class 100 không phù hợp vì người dùng sẽ được phục vụ từ edge xa hơn, độ trễ tăng mà chi phí không giảm theo cách bạn mong đợi.

Flat-rate plan

CloudFront hiện có thêm các gói flat-rate theo tháng, bên cạnh cách tính pay-as-you-go. Theo trang giá tại thời điểm viết bài, gói Pro có giá $15/tháng với 10 triệu request và 50 TB data transfer, gói Business có giá $200/tháng với 125 triệu request, và các gói này không tính phí vượt mức. Các gói còn bao gồm DNS, bảo vệ DDoS và một số rule AWS WAF tùy gói.

Với website và ứng dụng có lượng request vừa phải nhưng dung lượng lớn, flat-rate plan có thể rẻ hơn nhiều so với pay-as-you-go. Tuy vậy, mỗi gói có giới hạn riêng về request, tính năng và cách áp dụng ưu đãi, nên bạn cần đọc kỹ điều khoản và so sánh với usage thực tế trước khi chuyển.

Khi nào CloudFront không giúp giảm chi phí

Trường hợp cần chú ý nhất là API có rất nhiều request nhỏ. Lúc này phí request của CloudFront có thể lớn hơn phần tiết kiệm từ egress. Dù vậy, việc đưa API qua CloudFront vẫn có thể hợp lý vì lý do khác, như giảm độ trễ kết nối TLS hoặc dùng AWS WAF, chỉ là không nên kỳ vọng nó giảm chi phí.

Đo trước khi thay đổi

Trước khi đề xuất chuyển traffic sang CloudFront, chúng tôi thường xác định ba con số:

• Egress theo nguồn: trong Cost and Usage Report, lọc các usage type có chứa DataTransfer-Out-Bytes và nhóm theo service và resource. Kết quả cho biết bao nhiêu GB đang đi ra từ EC2, ELB và S3.
• Loại nội dung: ALB access logs hoặc S3 server access logs cho biết những path nào chiếm nhiều byte nhất, và chúng là nội dung tĩnh hay dữ liệu riêng cho từng người dùng.
• Khả năng cache: với từng nhóm path, xác định nội dung có giống nhau giữa các người dùng hay không, và TTL hợp lý là bao lâu.

Từ ba con số này, bạn có thể ước tính khá sát chi phí sau khi chuyển, bao gồm cả phí request, trước khi thay đổi bất kỳ cấu hình nào trên production.

Tóm lại

CloudFront giảm chi phí egress nhờ ba yếu tố: origin fetch từ AWS không tính phí, giá egress ở edge thấp hơn ở nhiều khu vực, và cache giúp origin xử lý ít hơn. Trong đó cache hit ratio là yếu tố quyết định, và nó phụ thuộc chủ yếu vào cache key, header Cache-Control và cách đặt tên file. Với traffic API cá nhân hóa hoặc lượng egress nhỏ, lợi ích về chi phí thường không đáng kể, và bạn nên đo trước khi quyết định.