5 điểm bởi GN⁺ 2024-01-16 | 1 bình luận | Chia sẻ qua WhatsApp
  • Truyền giữa các Availability Zone trong cùng một region trên AWS bị tính $0.01/GB ở cả phía gửi lẫn phía nhận, nên truyền trực tiếp 1TB tốn khoảng $20, nhưng nếu dùng S3 làm điểm trung chuyển tạm thời thì có thể hạ chi phí xuống mức vài cent
  • Bucket S3 tiêu chuẩn hoạt động ở cấp region và được AWS sao chép sang ít nhất 3 Availability Zone trong region, nên có thể truy cập như nhau từ nhiều AZ trong cùng region
  • Nếu EC2 tải lên S3 trong cùng region rồi tải xuống từ AZ khác, phí truyền dữ liệu sẽ là miễn phí; chi phí thực tế thu hẹp còn chi phí lưu trữ S3 trong thời gian ngắn và phí request API
  • Trong us-east-1, nếu giữ 1TB dưới 1 giờ thì S3 Standard với giá $23/TB-tháng chỉ tốn khoảng $0.03, tức 1/720, và ngay cả 1PB cũng giảm từ $20,000 khi truyền trực tiếp xuống khoảng $32
  • Cách này không phải là thay thế drop-in cho mã truyền mạng và độ trễ có thể lớn hơn, nhưng với truyền cross-AZ khối lượng lớn khi chi phí là ưu tiên số một thì có thể giảm hơn 99%

Điểm khiến chi phí truyền dữ liệu AWS tăng vọt

  • Nếu di chuyển dữ liệu trên AWS mà không cẩn thận, chi phí truyền sẽ tích lũy rất nhanh
  • Tại thời điểm viết bài, các mức phí truyền dữ liệu chính như sau
    • Truyền dữ liệu từ AWS ra Internet công cộng có giá $0.09 mỗi GB ở us-east-1, lên tới $0.154 mỗi GB ở af-south-1, tương đương $90~$154 cho 1TB
    • Truyền dữ liệu từ một AWS region sang region khác có giá $0.02 mỗi GB ở us-east-1, lên tới $0.147 mỗi GB ở af-south-1, nên ngay cả khi không rời khỏi mạng AWS thì 1TB vẫn có thể tốn $20~$147
    • Truyền giữa các Availability Zone khác nhau trong cùng region có giá $0.01 mỗi GB cho mỗi chiều, nên gửi 1TB từ us-east-1a sang us-east-1b sẽ tốn $10 phía gửi và $10 phía nhận, tổng cộng $20
  • Truyền ra Internet và truyền liên region chỉ bị tính phí egress cho dữ liệu đi ra, nhưng truyền giữa các AZ trong cùng region bị tính phí theo cả hai chiều
  • Cấu hình phân bổ tài nguyên trên nhiều Availability Zone giúp tăng độ ổn định và tính sẵn sàng, nhưng khi tài nguyên ở các AZ khác nhau trao đổi dữ liệu thì sẽ phát sinh chi phí cross-AZ

Lưu ý về PrivateLink và VPC endpoint

  • Nếu truyền 1TB từ một EC2 instance sang bucket S3 công khai ở region khác, bạn có thể bị tính phí egress Internet $90 thay vì phí truyền liên region $20 như kỳ vọng
  • AWS PrivateLink và VPC endpoint hữu ích về cả giá thành lẫn bảo mật vì đảm bảo dữ liệu liên region không rời khỏi mạng AWS
  • Tuy nhiên, các tính năng này không miễn phí và có các giới hạn cũng như chi tiết tính phí riêng
  • Tài liệu liên quan

Lách chi phí truyền cross-AZ bằng S3

  • Phần lớn các storage class của S3 lưu bucket ở cấp region chứ không phải Availability Zone
    • Người dùng tải lên bucket us-east-1, không phải bucket us-east-1a hay us-east-1b
    • AWS nội bộ sao chép dữ liệu sang ít nhất 3 Availability Zone trong region
  • Dữ liệu trong bucket S3 tiêu chuẩn có thể được truy cập như nhau từ mọi Availability Zone trong cùng region; tải xuống từ us-east-1a hay us-east-1b đều không khác gì từ góc nhìn của S3
  • Tải xuống từ S3 Standard trong cùng region là miễn phí, còn tải xuống sang region khác hoặc ra Internet công cộng sẽ bị tính phí truyền dữ liệu thông thường
  • Tải lên S3 là miễn phí về mặt phí truyền dữ liệu ở mọi storage class
    • Tuy vậy vẫn có phí request API của S3
    • Chi phí request tương đối nhỏ

Tính chi phí cho 1TB và 1PB

  • Gửi trực tiếp 1TB từ EC2 instance ở us-east-1a sang EC2 instance ở us-east-1b tốn $20
  • Nếu tải dữ liệu đó lên S3 rồi để instance ở AZ khác tải xuống, chi phí truyền dữ liệu cho cả tải lên và tải xuống đều là miễn phí
  • Chi phí còn lại là chi phí lưu trữ S3
    • S3 Standard ở us-east-1 có giá $0.023 mỗi GB mỗi tháng, tức $23 mỗi TB mỗi tháng
    • Việc tính phí được tính theo giờ
    • Nếu thiết kế để dữ liệu chỉ nằm trên S3 dưới 1 giờ, chi phí sẽ là khoảng $0.03, tức $23 chia cho 720 giờ
    • Cần xóa object trên S3 sau khi truyền xong
  • Theo cách tính này, chi phí truyền giảm từ $0.02/GB xuống $0.000032/GB, tương đương khoảng 0.15% so với mức giá ban đầu
  • Ví dụ cực đoan hơn, truyền 1PB sẽ tốn khoảng $32 theo cách này thay vì $20,000 theo cách thông thường

Khả năng mở rộng và các giới hạn

  • S3 có khả năng mở rộng cao, phù hợp cả với mô hình một AZ tải object lên rồi nhiều instance ở AZ khác cùng lúc tải xuống
    • Hàng nghìn instance ở AZ thứ hai có thể tải cùng một object trên S3
    • Chi phí lưu trữ S3 vẫn giữ nguyên
    • Chi phí tải xuống cũng vẫn miễn phí
  • Kích thước object của S3 có giới hạn
    • Một object đơn lẻ không thể vượt quá 5TB
    • File lớn hơn 5TB phải được chia nhỏ
    • Một lần tải lên đơn lẻ không thể vượt quá 5GB, nên file lớn hơn cần dùng multipart upload
    • aws s3 cp xử lý multipart upload ở bên trong
  • S3 One Zone-Infrequent Access và S3 Express One Zone chỉ lưu dữ liệu trong một Availability Zone duy nhất
    • Chi phí lưu trữ thấp hơn nhưng phải đánh đổi về tính sẵn sàng
    • Tại us-east-1, S3 One Zone-Infrequent Access có giá $0.01/GB, còn S3 Infrequent Access là $0.0125/GB
    • S3 One Zone-Infrequent Access được thiết kế với mục tiêu availability 99.5%, còn S3 Infrequent Access là 99.99%

Cấu hình thử nghiệm và chi phí được xác nhận

  • Thử nghiệm dùng 2 tài khoản AWS mới cho mỗi phần để giảm nhiễu chi phí
  • Mỗi tài khoản có 2 EC2 instance tại us-east-1aus-east-1b, và một file 1TB ngẫu nhiên được tạo trên instance ở us-east-1a
  • Hai cách tiếp cận được so sánh
    • Cách thứ nhất dùng VPC có private subnet ở hai AZ, chạy netcat server trên instance us-east-1b, rồi instance us-east-1a truyền trực tiếp file 1TB
    • Cách thứ hai dùng VPC có S3 Gateway endpoint, tạo bucket S3, rồi instance us-east-1a tải lên file 1TB, sau đó instance us-east-1b tải xuống và xóa đi
  • AWS Free Tier có thể ảnh hưởng nhẹ đến kết quả thử nghiệm
    • Free Tier của S3 là 5GB-tháng trong 12 tháng
    • 5GB-tháng nhỏ hơn 1TB-giờ nhưng không chênh lệch quá lớn
  • Sau khi Cost Explorer cập nhật, thử nghiệm truyền trực tiếp cho kết quả $21.49, gần với mức dự kiến $20
    • Việc dừng và khởi động lại một lần trong lúc truyền giải thích một phần chi phí phát sinh thêm
    • File được tạo thực tế có dung lượng 1024GB nên chi phí cơ bản là $20.48
  • Thử nghiệm truyền qua S3 ban đầu được ghi nhận là $0.08, và không thấy xuất hiện chi phí truyền dữ liệu
  • Về sau xác nhận rằng chi phí lưu trữ S3 được báo cáo theo từng ngày cho từng bucket, và phản ánh trong Cost Explorer chậm hơn các loại chi phí khác
    • Đúng như dự kiến, chi phí lưu trữ được báo cáo chỉ ở mức vài cent
    • Free Tier lưu trữ S3 đã bị dùng hết hoàn toàn
    • Khả năng này được Dieter Matzion từ cộng đồng FinOps chỉ ra

Khi nào đáng dùng

  • AWS nội bộ sao chép dữ liệu S3 giữa các Availability Zone, và chi phí đó đã được gộp vào chi phí lưu trữ S3 mà người dùng trả
  • Cách đi qua S3 tận dụng thực tế là chi phí cross-AZ đã được trả gián tiếp tại thời điểm tải lên
  • Nếu giữ dữ liệu trên S3 quá lâu, tổng chi phí có thể cao hơn nhiều so với truyền trực tiếp cross-AZ
  • Nếu xóa object ngay sau khi truyền, có thể đạt mục tiêu giảm 99% chi phí
  • Nhược điểm cũng rất rõ ràng
    • Đây không phải là một thay thế drop-in cho mã truyền dữ liệu hiện có
    • Độ trễ có thể cao hơn rất nhiều so với kết nối mạng trực tiếp
  • Khi chi phí là ưu tiên cao nhất, đây có thể là một cách thực dụng để giảm hơn 99% chi phí truyền dữ liệu cross-AZ trên AWS

1 bình luận

 
GN⁺ 2024-01-16
Ý kiến trên Hacker News
  • Chia sẻ mẹo của tôi: có thể dùng instance Lightsail để “proxy” dữ liệu từ các tài nguyên AWS khác, chẳng hạn instance EC2 hoặc bucket S3
    Mỗi instance Lightsail có một lượng truyền dữ liệu đã bao gồm trong giá; instance $3,5 có 1TB, $5 có 2TB, $10 có 3TB, $20 có 4TB, $40 có 5TB
    Xét theo giá trên dung lượng truyền, instance $10 với 3TB là tốt nhất
    Dựa trên dữ liệu trong bài, 3TB lưu lượng từ EC2 sẽ tốn $276,48 ở us-east-1, còn từ bucket S3 là $69
    Nhược điểm là trong Lightsail, cả lưu lượng inbound lẫn outbound đều được tính là “traffic”

    • https://aws.amazon.com/service-terms/
      Theo điều khoản AWS 51.3, không được dùng Amazon Lightsail theo cách nhằm tránh phí dữ liệu của các dịch vụ khác
      Ví dụ như proxy lưu lượng mạng từ dịch vụ khác ra Internet công cộng hoặc đến đích khác, hoặc xử lý dữ liệu quá mức thông qua dịch vụ load balancing/CDN; nếu vi phạm, dịch vụ dữ liệu có thể bị hạn chế hoặc tài khoản có thể bị đình chỉ
    • Một cách khác là dùng free tier của CloudFront, cho phép tải xuống miễn phí 1TB mỗi tháng từ AWS
      Chỉ cần đặt S3 hoặc bất kỳ máy chủ HTTP nào bạn muốn làm origin
      Trước đây là 50GB/tháng trong 12 tháng đầu, nhưng ngay sau khi Cloudflare đăng https://blog.cloudflare.com/aws-egregious-egress, nó đã được đổi thành 1TB miễn phí vĩnh viễn
    • Xét chi tiết thì 2TB với $5 còn tốt hơn 3TB với $10
    • Đây là một mẹo hay, nhưng vì điều khoản AWS nên gần như đang đùa với lửa
  • GCP cũng đã chặn một lỗ hổng tương tự vào năm 2023, có lẽ vì một số khách hàng đã lạm dụng
    Nếu cách này đủ phổ biến, tôi nghĩ AWS cũng sẽ làm tương tự
    https://cloud.google.com/storage/pricing-announce#network

    • Khả năng có vẻ thấp
      “Lỗ hổng” mà GCP chặn là việc có thể truyền dữ liệu giữa các region trong cùng một châu lục bằng GCS miễn phí, còn trên AWS thì việc này vốn đã tính phí
      Bài gốc nói rằng ngay cả truyền giữa các Availability Zone trong cùng một region cũng tốn $0,02/GB, và có thể né được khoản này
    • Tôi biết một cách để đưa dữ liệu ra khỏi GCP miễn phí, nhưng chưa thực sự thử
      Không biết có thể tìm được người mua thông tin này không
    • Cái này không giống lỗ hổng cho lắm; nó có cảm giác như AWS đã tối ưu S3 và muốn các instance EC2 dùng S3 làm nơi lưu trữ
      Tuy nhiên có thể không phải để dùng như cửa ngõ truyền tải; họ có lẽ kỳ vọng bạn đưa dữ liệu vào đó rồi tiếp tục để nó ở đó
  • Có rất nhiều mẹo kiểu này để giảm chi phí và lấy tài nguyên miễn phí
    Thông minh thì có, nhưng không đáng tin cậy
    Nó cùng loại với các kiểu hack khiến GitHub Actions đào tiền mã hóa thông qua kho OSS
    Nên xem như một bài tập hack thú vị, chứ đừng triển khai giải pháp kiểu này lên production
    Ít nhất phải có phê duyệt của account manager, nếu không có nguy cơ một ngày thức dậy thấy tài khoản AWS đã bị chấm dứt

    • Tôi đã dùng cách này và các kỹ thuật khác trong nhiều năm mà chưa từng bị chặn
      Cách đi qua S3 nhìn chung cũng hiệu quả hơn việc chạy các quy trình đồng bộ hóa khi phân phối dữ liệu đến nhiều đích
  • Chi phí lưu trữ S3 được tính theo GB-tháng, nên 1TB × $0,023 mỗi GB ÷ 730 giờ/tháng thì nếu để trong bucket một giờ, chi phí phải vào khoảng 3 cent
    Tuy nhiên có vẻ dữ liệu đã bị xóa gần như ngay lập tức, nên nếu dữ liệu chỉ tồn tại khoảng 1 phút thì có thể là cỡ 0,03 ÷ 60
    Thông thường tôi đoán AWS sẽ làm tròn lên $0,01
    Giá trị TimedByteStorage trong báo cáo chi phí và mức sử dụng sẽ là căn cứ cuối cùng
    https://handbook.vantage.sh/aws/services/s3-pricing/

  • S3 cũng là một mẹo hay, và còn có thêm nữa
    Nếu là khách hàng AWS lớn, chẳng hạn chi hơn $1 triệu/năm, bạn có thể yêu cầu giảm giá
    Có thời truyền giữa các Availability Zone được giảm giá rất mạnh
    Gom vào một Availability Zone nhiều nhất có thể cũng là một cách
    Cấu hình DB ở zone “b” còn server duy nhất ở zone “a” còn tệ hơn cả việc chuẩn hóa về một zone
    Khi dùng nhiều Availability Zone, cần cân bằng theo Availability Zone có nhận biết tải

    • Chắc cũng có trường hợp dùng cấu hình kiểu “DB ở zone b, server duy nhất ở zone a”, nhưng tôi khó hình dung
      Vì chi phí à? Nhưng có vẻ cũng chẳng tiết kiệm được chi phí
    • Ở mục 4 cũng có thể bật storage class S3 Intelligent-Tiering
  • Cái này giống tránh thuế phiên bản công nghệ
    Nếu quá nhiều người làm vậy, AWS sẽ “đơn giản là đóng lỗ hổng”
    AWS không phải là một khối duy nhất, mà gần như là hàng chục hoặc hàng trăm AWS khác nhau, mỗi bên có KPI riêng
    Một số đội muốn khách hàng giảm chi tiêu, nhưng lại không thực sự chỉ cho cách giảm chi tiêu
    Khi xây một thứ đủ phức tạp như AWS, mọi thứ đều đan xen với nhau đến mức khách hàng không thể tối ưu chỉ một yếu tố riêng lẻ

    • Đây không phải lỗ hổng mà là thiết kế có chủ đích
      AWS muốn bạn dùng một số dịch vụ theo những cách nhất định, nên họ làm cho cách dùng đó rất rẻ
      Dùng endpoint S3 cũng là một trong những cách AWS muốn bạn sử dụng dịch vụ S3
      CloudFront là một ví dụ khác
      AWS muốn bạn dùng CloudFront, nên họ làm cho CloudFront rẻ hơn các hình thức outbound dữ liệu khác
  • Phương án thay thế cho một hệ thống tối ưu chi phí đám mây phức tạp đơn giản là không dùng đám mây
    Tự host, hoặc dùng Cloudflare với phí outbound 0 cent mỗi GB là được
    Hoặc thuê máy chủ cloud từ nhiều nhà cung cấp VPS rẻ hơn nhiều, và đừng dùng các dịch vụ đám mây đắt đỏ, phức tạp, hút tiền 9 cent, 12 cent, 17 cent mỗi GB rồi tạo lock-in
    Nói nghiêm túc, nếu đã đến mức phải phân tích chi phí cloud một cách tinh vi thì nên cân nhắc bỏ cloud

    • Nếu đang phân tích chi phí cloud một cách tinh vi thì ngược lại, đó là đang dùng cloud đúng cách
      Vì ở những nơi khác, bản thân việc phân tích như vậy hoàn toàn bất khả thi
      Có vẻ những người bảo quay về on-premises không biết chi phí nhân sự cho người không đối xử với datacenter như homelab là bao nhiêu
      Ngay cả Apple iCloud cũng dùng AWS và GCP vì như vậy có lợi về kinh tế
      Hoặc là họ nghĩ vì không dùng được cloud nên phải quay về on-premises, hoặc là họ không mấy quan tâm đến độ tin cậy
      Hãy thử tính từ chi phí chống DDoS trên 10G rồi hãy nói cloud đắt hơn
      Chúng tôi chi hơn 100.000 USD cho băng thông AWS, nhưng vì không phải trả chi phí cho kỹ sư mạng để quản lý 3 availability zone nên vẫn rẻ hơn đường truyền Internet chuyên dụng
    • Nói “nếu đã đến mức phải phân tích chi phí cloud tinh vi thì hãy bỏ cloud” nghĩa là đánh mất một phần lý do ban đầu để dùng cloud
      Nhiều tổ chức chuyển sang hosting dựa trên cloud vì, trong số nhiều lợi ích, họ có thể làm FinOps và kiểm soát chi phí sâu hơn nhiều
      Tùy hạ tầng, nếu nhu cầu lưu trữ hoặc compute biến động thì giải pháp dựa trên cloud có thể rất phù hợp
      Rốt cuộc nó chỉ là một công cụ
      Tôi từng làm ở nơi SSH vào server bare-metal production để cập nhật phần mềm, quản lý firewall và kiểm tra storage; cũng từng làm ở nơi xử lý phần lớn hosting bằng nhà cung cấp cloud; và cũng đã chuyển đổi từ bên này sang bên kia
      “Cloud” không tốt hơn hay tệ hơn server bare-metal hay VPS; nó tùy thuộc vào use case
      Chỉ cần thẩm định vì sao một bên phù hợp hơn, rồi đánh giá lại mỗi khi môi trường thay đổi
      Kiểu thái độ “cloud xấu” như vậy thật trẻ con
    • Giải pháp trong bài tương đối dễ áp dụng
      Nếu đã bị lock-in vào AWS thì chi phí thoát ra khá lớn, và trong một số trường hợp cách này có thể là điểm cân bằng tốt
    • Để tự host, nếu thực tế bạn đang dùng các tính năng của cloud, tức dịch vụ được quản lý, thì phải xây dựng một bộ phận IT với năng lực mà nhiều công ty không có
      Chi phí đó trong nhiều trường hợp có thể dễ dàng triệt tiêu hoặc vượt quá khoản tiết kiệm
      Đó cũng là một lý do lớn khiến việc các công ty chọn cloud trở thành quyết định quá hiển nhiên
    • Trong trường hợp này, có vẻ “tự host” cũng không giúp được gì
      Có vẻ AWS đang vận hành trường hợp này ở mức lỗ
      Tác giả đã tìm ra một kẽ hở trong cơ chế giá của AWS, nên nó mới rẻ như vậy
      Nếu tự làm thì nhiều khả năng còn đắt hơn
      Chỉ có thể phỏng đoán vì sao giá AWS lại như thế, nhưng nhiều khả năng là để khuyến khích dùng một dịch vụ hơn dịch vụ khác
  • Nếu là người dùng nhiều băng thông thì đáng xem thử những nơi như Leaseweb, PhoenixNAP, Hetzner, OVH
    Giá băng thông rẻ hơn đến mức phi lý
    Trước đây từng có một tình huống kỳ lạ là với giá niêm yết thì công ty không thể tồn tại, vậy mà các nhân viên kinh doanh AWS hoàn toàn không chịu giảm giá băng thông

    • Điều đó có vẻ khá bất thường
      Chi phí truyền tải dường như phần lớn là hạng mục có thể thương lượng
  • Một mẹo khác là dùng ECR
    Có thể truyền miễn phí 5TB ra Internet mỗi tháng
    Container image phải là public, nhưng nội dung có thể được mã hóa
    Hữu ích khi lưu trữ archive media trong Glacier

  • Không hiểu AWS làm sao vẫn có thể tiếp tục móc túi mọi người bằng phí truyền dữ liệu vô lý như vậy
    Ngay bên cạnh đã có Cloudflare R2 đưa ra điều kiện tốt hơn gấp 100 lần

    • Dữ liệu có “trọng lực”
      Nó giữ bạn lại nơi dữ liệu đang nằm, và cũng như phải tốn tiền để thoát khỏi trọng lực, muốn di chuyển dữ liệu thì phải chi tiền
    • Khi tất cả VM và container đều ở AWS, còn S3 được hỗ trợ rất vững chắc bất kể dùng ngôn ngữ, framework hay cấu hình nào, thì thật sự rất khó yêu cầu đội dùng một nhà cung cấp object storage khác
      Nếu trên R2 xảy ra vấn đề như mất dữ liệu hoặc truyền chậm, tôi sẽ bị đổ lỗi hoặc ít nhất là bị nhờ hỗ trợ
      Ngược lại, nếu S3 làm mất dữ liệu hoặc chậm trong một số trường hợp, mọi người sẽ nghĩ là chúng ta đang dùng sai cách và sẽ tìm ra cách cải thiện
      Không ai bị đổ lỗi
      Thành thật mà nói, nếu doanh nghiệp đang tạo ra bất kỳ giá trị nào thì phí truyền dữ liệu cũng nhỏ đến mức có thể bỏ qua, không cần cố tối ưu
    • Tôi đã xây một tính năng mới cho một SaaS dùng khá nhiều băng thông bằng R2, và nó hoạt động rất tốt
      Khoản tiết kiệm cũng thật sự lớn
      Vẫn dùng nguyên AWS-SDK(Node.js), chỉ đổi sang endpoint của R2
    • Tôi tin Cloudflare kém AWS rất nhiều
      Khi dữ liệu đã vào AWS, mọi ứng dụng trong cùng region có thể dùng dữ liệu mà không mất phí truyền tải
      Ngoài ra, mức giá được trích trong bài là giá niêm yết; nếu khách hàng mua trước băng thông theo hợp đồng thì sẽ rẻ hơn nhiều
    • R2 vẫn còn khá mới
      Chưa rõ hiệu năng và tính sẵn sàng trong vận hành thực tế tốt đến đâu
      Đặc biệt độ bền dữ liệu thì khó hoặc gần như không thể đánh giá
      S3 có lợi thế vì có lịch sử và thành tích dài hơn nhiều
      Nếu mọi thứ đã nằm trong AWS, việc để dữ liệu ở gần cũng có lợi
      Tùy cách sử dụng dữ liệu, chi phí outbound không phải lúc nào cũng là khoản quá lớn
      Tuy nhiên, một khi thực sự bắt đầu tạo ra lưu lượng outbound đáng kể thì nó trở nên đắt đến vô lý
      Nếu các đối thủ như R2 có thể cung cấp độ tin cậy và hiệu năng đủ cạnh tranh một cách hợp lý, tôi kỳ vọng họ sẽ tăng thị phần