ลดค่าใช้จ่ายการถ่ายโอนข้อมูลบน AWS อย่างมาก

 (bitsand.cloud)
5 คะแนน โดย GN⁺ 2024-01-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การ ถ่ายโอนระหว่าง Availability Zone ภายในรีเจียนเดียวกันของ AWS จะคิดค่าบริการทั้งฝั่งส่งและรับฝั่งละ $0.01 ต่อ GB ทำให้การถ่ายโอนตรง 1TB มีค่าใช้จ่ายประมาณ $20 แต่ถ้าใช้ S3 เป็นจุดพักข้อมูลชั่วคราว จะลดค่าใช้จ่ายลงเหลือระดับเซนต์ได้
  • บัคเก็ต S3 มาตรฐานทำงานในระดับ รีเจียน และ AWS จะทำสำเนาไปยัง Availability Zone อย่างน้อย 3 แห่งภายในรีเจียน จึงเข้าถึงได้เหมือนกันจากหลาย AZ ในรีเจียนเดียวกัน
  • เมื่อ EC2 อัปโหลดไปยัง S3 ในรีเจียนเดียวกัน แล้วดาวน์โหลดจาก AZ อื่น ค่าถ่ายโอนข้อมูลจะฟรี ค่าใช้จ่ายจริงจะเหลือแค่ ค่าเก็บข้อมูล S3 สำหรับระยะเวลาจัดเก็บสั้น ๆ และค่า API request
  • หากเก็บข้อมูล 1TB ใน us-east-1 ไว้น้อยกว่า 1 ชั่วโมง จะเสียเพียงประมาณ $0.03 ซึ่งเป็น 1/720 ของราคา S3 Standard $23/TB-month และแม้แต่ 1PB ก็ลดจากการถ่ายโอนตรง $20,000 เหลือประมาณ $32
  • วิธีนี้ไม่ใช่ ตัวแทนแบบ drop-in สำหรับโค้ดถ่ายโอนผ่านเครือข่าย และอาจมี latency สูงขึ้น แต่สำหรับการถ่ายโอน cross-AZ ปริมาณมากที่ให้ความสำคัญกับต้นทุนเป็นอันดับแรก สามารถลดค่าใช้จ่ายได้มากกว่า 99%

จุดที่ค่าใช้จ่ายการถ่ายโอนข้อมูลบน AWS เพิ่มสูงขึ้น

  • หากย้ายข้อมูลบน AWS โดยไม่ระมัดระวัง ค่าใช้จ่ายการถ่ายโอนจะสะสมอย่างรวดเร็ว
  • ณ เวลาที่เขียน อัตราค่าถ่ายโอนข้อมูลหลัก ๆ มีดังนี้
    • การถ่ายโอนออกจาก AWS ไปยังอินเทอร์เน็ตสาธารณะอยู่ที่ $0.09 ต่อ GB ใน us-east-1 และสูงถึง $0.154 ต่อ GB ใน af-south-1 ทำให้การถ่ายโอน 1TB มีค่าใช้จ่าย $90~$154
    • การถ่ายโอนออกจากรีเจียน AWS หนึ่งไปยังอีกรีเจียนอยู่ที่ $0.02 ต่อ GB ใน us-east-1 และสูงถึง $0.147 ต่อ GB ใน af-south-1 แม้ข้อมูลจะไม่ออกจากเครือข่าย AWS ก็อาจเสีย $20~$147 ต่อ 1TB
    • การถ่ายโอนระหว่าง Availability Zone ต่างกันในรีเจียนเดียวกันคิด $0.01 ต่อ GB ต่อทิศทาง หากส่ง 1TB จาก us-east-1a ไป us-east-1b จะเป็นค่าส่ง $10 และค่ารับ $10 รวม $20
  • การถ่ายโอนไปอินเทอร์เน็ตและการถ่ายโอนข้ามรีเจียนจะจ่ายเฉพาะ ค่า egress สำหรับข้อมูลขาออก แต่การถ่ายโอนระหว่าง AZ ภายในรีเจียนเดียวกันจะคิดค่าใช้จ่ายทั้งสองทิศทาง
  • การจัดวางทรัพยากรไว้ในหลาย Availability Zone ช่วยเพิ่มความเสถียรและ availability แต่ถ้าทรัพยากรใน AZ ต่างกันส่งข้อมูลหากัน จะเกิดค่าใช้จ่าย cross-AZ

ข้อควรระวังเกี่ยวกับ PrivateLink และ VPC endpoint

  • หากถ่ายโอน 1TB จากอินสแตนซ์ EC2 ไปยังบัคเก็ต S3 สาธารณะในรีเจียนอื่น อาจถูกคิด ค่า internet egress $90 แทนค่าโอนข้ามรีเจียน $20 ตามที่คาดไว้
  • AWS PrivateLink และ VPC endpoint มีประโยชน์ด้านราคาและความปลอดภัย เพราะช่วยรับประกันว่าข้อมูลข้ามรีเจียนจะไม่ออกจากเครือข่าย AWS
  • อย่างไรก็ตาม ฟีเจอร์เหล่านี้ไม่ฟรี และมีข้อจำกัดกับรายละเอียดค่าบริการของตัวเอง
  • เอกสารที่เกี่ยวข้อง

เลี่ยงค่าใช้จ่ายการถ่ายโอน cross-AZ ด้วย S3

  • storage class ส่วนใหญ่ของ S3 จัดเก็บบัคเก็ตในระดับ รีเจียน ไม่ใช่ Availability Zone
    • ผู้ใช้อัปโหลดไปยังบัคเก็ต us-east-1 ไม่ใช่บัคเก็ต us-east-1a หรือ us-east-1b
    • AWS ทำสำเนาข้อมูลภายในไปยัง Availability Zone อย่างน้อย 3 แห่งในรีเจียน
  • ข้อมูลในบัคเก็ต S3 มาตรฐานเข้าถึงได้เหมือนกันจาก Availability Zone ทั้งหมดของ AWS ในรีเจียนเดียวกัน และจากมุมมองของ S3 ไม่มีความแตกต่างว่าจะดาวน์โหลดจาก us-east-1a หรือ us-east-1b
  • การดาวน์โหลดภายในรีเจียนเดียวกันจาก S3 Standard นั้นฟรี และจะคิดค่าถ่ายโอนข้อมูลตามปกติเมื่อดาวน์โหลดไปยังรีเจียนอื่นหรืออินเทอร์เน็ตสาธารณะ
  • การอัปโหลดไป S3 ไม่มีค่าถ่ายโอนข้อมูลสำหรับทุก storage class
    • แต่ยังมีค่า S3 API request
    • ค่า request ค่อนข้างเล็ก

คำนวณค่าใช้จ่ายสำหรับ 1TB และ 1PB

  • หากส่ง 1TB ตรงจากอินสแตนซ์ EC2 ใน us-east-1a ไปยังอินสแตนซ์ EC2 ใน us-east-1b จะเสีย $20
  • หากอัปโหลดข้อมูลเดียวกันไป S3 แล้วให้อินสแตนซ์ใน AZ อื่นดาวน์โหลด ค่าโอนข้อมูลสำหรับการอัปโหลดและดาวน์โหลดจะฟรี
  • ค่าใช้จ่ายที่เหลือคือค่าเก็บข้อมูล S3
    • S3 Standard storage ใน us-east-1 มีราคา $0.023 ต่อ GB ต่อเดือน หรือ $23 ต่อ TB ต่อเดือน
    • คิดค่าบริการเป็นรายชั่วโมง
    • หากออกแบบให้ข้อมูลอยู่ใน S3 น้อยกว่า 1 ชั่วโมง จะเป็นประมาณ $0.03 ซึ่งคือ 1/720 ของ $23 จากฐาน 720 ชั่วโมง
    • หลังถ่ายโอนเสร็จต้องลบออบเจ็กต์ S3
  • ในการคำนวณนี้ ค่าโอนข้อมูลลดจาก $0.02 ต่อ GB เหลือ $0.000032/GB หรือราว 0.15% ของค่าบริการเดิม
  • ตัวอย่างสุดขั้วคือ การถ่ายโอน 1PB จะเสียประมาณ $32 ด้วยวิธีนี้ แทนที่จะเป็น $20,000 ตามวิธีมาตรฐาน

ความสามารถในการขยายและข้อจำกัด

  • S3 มีความสามารถในการขยายสูง จึงเหมาะกับรูปแบบที่อัปโหลดออบเจ็กต์จาก AZ หนึ่ง แล้วให้อินสแตนซ์จำนวนมากใน AZ อื่นดาวน์โหลดพร้อมกัน
    • อินสแตนซ์หลายพันตัวใน AZ ที่สองสามารถดาวน์โหลดออบเจ็กต์ S3 เดียวกันได้
    • ค่าเก็บข้อมูล S3 ยังคงเท่าเดิม
    • ค่าดาวน์โหลดก็ยังฟรี
  • ขนาดออบเจ็กต์ S3 มีข้อจำกัด
    • ออบเจ็กต์เดี่ยวต้องไม่เกิน 5TB
    • ไฟล์ที่ใหญ่กว่า 5TB ต้องแบ่งเป็นส่วน ๆ
    • การอัปโหลดครั้งเดียวต้องไม่เกิน 5GB ดังนั้นไฟล์ที่ใหญ่กว่านั้นจำเป็นต้องใช้ multipart upload
    • aws s3 cp จัดการ multipart upload ภายในให้เอง
  • S3 One Zone-Infrequent Access และ S3 Express One Zone เก็บข้อมูลไว้ใน Availability Zone เดียวเท่านั้น
    • ค่าเก็บข้อมูลต่ำกว่า แต่ต้องแลกกับด้าน availability
    • ใน us-east-1 S3 One Zone-Infrequent Access ราคา $0.01 ต่อ GB และ S3 Infrequent Access ราคา $0.0125 ต่อ GB
    • S3 One Zone-Infrequent Access ถูกออกแบบโดยมีเป้าหมาย availability 99.5% ส่วน S3 Infrequent Access มีเป้าหมาย availability 99.99%

การตั้งค่าการทดลองและค่าใช้จ่ายที่ยืนยันแล้ว

  • การทดลองใช้บัญชี AWS ใหม่ 2 บัญชีในแต่ละส่วนเพื่อลด noise ด้านค่าใช้จ่าย
  • ในแต่ละบัญชีมีอินสแตนซ์ EC2 2 ตัวใน us-east-1a และ us-east-1b และสร้าง ไฟล์ 1TB แบบสุ่มบนอินสแตนซ์ us-east-1a
  • เปรียบเทียบ 2 วิธี
    • วิธีแรกคือเปิดเซิร์ฟเวอร์ netcat บนอินสแตนซ์ us-east-1b ใน VPC ที่มี private subnet ของทั้งสอง AZ แล้วให้อินสแตนซ์ us-east-1a ส่งไฟล์ 1TB ไปโดยตรง
    • วิธีที่สองคือสร้างบัคเก็ต S3 ใน VPC ที่มี S3 Gateway endpoint จากนั้นให้อินสแตนซ์ us-east-1a อัปโหลดไฟล์ 1TB แล้วให้อินสแตนซ์ us-east-1b ดาวน์โหลดและลบไฟล์
  • AWS Free Tier อาจมีผลต่อผลการทดลองเล็กน้อย
    • S3 Free Tier ให้ 5GB-months เป็นเวลา 12 เดือน
    • 5GB-months น้อยกว่า 1TB-hours แต่ไม่ได้ต่างกันมากนัก
  • หลัง Cost Explorer อัปเดต การทดลองถ่ายโอนตรงออกมาเป็น $21.49 ซึ่งใกล้กับ $20 ที่คาดไว้
    • การหยุดและเริ่มถ่ายโอนใหม่หนึ่งครั้งช่วยอธิบายค่าใช้จ่ายส่วนเพิ่มบางส่วน
    • ไฟล์ที่สร้างขึ้นในเชิงเทคนิคมีขนาด 1024GB ดังนั้นต้นทุนพื้นฐานคือ $20.48
  • การทดลองถ่ายโอนผ่าน S3 ตอนแรกพบว่าเป็น $0.08 และไม่ปรากฏค่าโอนข้อมูล
  • ต่อมาพบว่าค่าเก็บข้อมูล S3 ถูกรายงานเป็นรายวันแยกตามบัคเก็ต และสะท้อนใน Cost Explorer ช้ากว่าค่าใช้จ่ายประเภทอื่น
    • ตามที่คาด ค่าเก็บข้อมูลที่รายงานอยู่ในระดับไม่กี่เซนต์
    • S3 storage Free Tier ถูกใช้จนหมดทั้งหมด
    • ความเป็นไปได้นี้ได้รับการแจ้งจาก Dieter Matzion แห่งชุมชน FinOps

เหมาะจะใช้เมื่อใด

  • AWS ทำสำเนาข้อมูล S3 ภายในระหว่าง Availability Zone และค่าใช้จ่ายนั้นรวมอยู่ใน ค่าเก็บข้อมูล S3 ที่ผู้ใช้จ่ายแล้ว
  • วิธีผ่าน S3 ใช้ประโยชน์จากสถานะที่จ่ายค่า cross-AZ ทางอ้อมไปแล้ว ณ ตอนอัปโหลด
  • หากเก็บข้อมูลไว้ใน S3 นาน อาจแพงกว่าการถ่ายโอนตรงแบบ cross-AZ มาก
  • หากลบออบเจ็กต์ทันทีหลังถ่ายโอน จะสามารถบรรลุเป้าหมาย ลดค่าใช้จ่าย 99% ได้
  • ข้อเสียก็ชัดเจน
    • ไม่ใช่ตัวแทนแบบ drop-in สำหรับโค้ดถ่ายโอนข้อมูลที่มีอยู่
    • อาจมี latency สูงกว่าการเชื่อมต่อเครือข่ายโดยตรงมาก
  • ในกรณีที่ให้ความสำคัญกับต้นทุนเป็นอันดับแรก วิธีนี้อาจเป็นแนวทางปฏิบัติที่ช่วยลดค่าใช้จ่ายการถ่ายโอนข้อมูล cross-AZ บน AWS ได้มากกว่า 99%

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-16
ความคิดเห็นจาก Hacker News

  • ขอแชร์ทริกของผม: คุณสามารถใช้ Lightsail instance เพื่อ “พร็อกซี” ข้อมูลของทรัพยากร AWS อื่น ๆ เช่น EC2 instance หรือ S3 bucket ได้
    แต่ละ Lightsail instance จะมีปริมาณรับส่งข้อมูลที่รวมอยู่ในราคา โดย instance ราคา $3.5 ได้ 1TB, $5 ได้ 2TB, $10 ได้ 3TB, $20 ได้ 4TB และ $40 ได้ 5TB
    ถ้าคิดเป็นราคาต่อปริมาณรับส่งข้อมูล 3TB ของ instance ราคา $10 คุ้มที่สุด
    อ้างอิงจากข้อมูลในบทความ ทราฟฟิก 3TB จาก EC2 มีค่าใช้จ่าย $276.48 ใน us-east-1 และจาก S3 bucket อยู่ที่ $69
    ข้อเสียคือใน Lightsail ทั้งทราฟฟิกขาเข้าและขาออกต่างก็ถูกนับเป็น “ทราฟฟิก” ทั้งหมด

    • https://aws.amazon.com/service-terms/
      ตามข้อ 51.3 ของเงื่อนไขบริการ AWS ระบุว่าไม่ควรใช้ Amazon Lightsail ในลักษณะที่ตั้งใจหลีกเลี่ยงค่าบริการข้อมูลของบริการอื่น
      ตัวอย่างเช่น การพร็อกซีทราฟฟิกเครือข่ายจากบริการอื่นออกสู่อินเทอร์เน็ตสาธารณะหรือปลายทางอื่น หรือประมวลผลข้อมูลในปริมาณมากเกินควรผ่านบริการ load balancing/CDN และหากฝ่าฝืน AWS อาจจำกัดบริการข้อมูลหรือระงับบัญชีได้
    • อีกวิธีหนึ่งคือใช้ CloudFront free tier ซึ่งช่วยให้ดาวน์โหลดจาก AWS ได้ฟรี 1TB ต่อเดือน
      ตั้ง S3 หรือ HTTP server ที่คุณต้องการเป็น origin ได้เลย
      เมื่อก่อนเคยให้เดือนละ 50GB ในช่วง 12 เดือนแรก แต่หลังจาก Cloudflare โพสต์ https://blog.cloudflare.com/aws-egregious-egress ไม่นาน ก็เปลี่ยนเป็นฟรีถาวร 1TB
    • หากดูละเอียด $5 ได้ 2TB จริง ๆ คุ้มกว่า $10 ได้ 3TB
    • เป็นทริกที่ดี แต่เพราะ เงื่อนไขบริการของ AWS มันจึงค่อนข้างเหมือนเล่นกับไฟ

  • GCP ก็ปิดช่องลักษณะคล้ายกันไปในปี 2023 และน่าจะเป็นเพราะมีลูกค้าบางรายนำไปใช้ในทางที่เกินเลย
    ถ้าวิธีนี้แพร่หลายมากพอ AWS ก็น่าจะทำแบบเดียวกัน
    https://cloud.google.com/storage/pricing-announce#network

    • ไม่น่าเป็นไปได้เท่าไร
      “ช่อง” ที่ GCP ปิดคือการโอนข้อมูล ระหว่างรีเจียนภายในทวีปเดียวกันไปยัง GCS ได้ฟรี ซึ่งบน AWS มีค่าใช้จ่ายอยู่แล้ว
      สิ่งที่บทความต้นฉบับพูดถึงคือ แม้แต่การโอนข้าม availability zone ภายในรีเจียนเดียวกันก็ยังมีค่าใช้จ่าย GB ละ $0.02 และวิธีนี้ใช้เพื่อเลี่ยงจุดนั้น
    • ผมพอรู้วิธีดึงข้อมูลออกจาก GCP ฟรี แต่ยังไม่เคยลองจริง
      สงสัยว่าจะหาคนยอมจ่ายเงินซื้อข้อมูลนี้ได้ไหม
    • มองว่านี่ไม่ใช่ช่องโหว่เท่าไร แต่เหมือน AWS ปรับแต่ง S3 มาอย่างเหมาะเจาะ และตั้งใจให้ EC2 instance ใช้ S3 เป็น storage
      แต่อาจไม่ได้ตั้งใจให้ใช้เป็นช่องทางส่งผ่านข้อมูล และดูเหมือนจะคาดหวังให้คุณเอาข้อมูลไปเก็บไว้ที่นั่นต่อมากกว่า

  • ทริกแบบนี้ที่ช่วยลดค่าใช้จ่ายและได้ทรัพยากรฟรีมีอยู่อีกเยอะ
    มันฉลาด แต่เชื่อถือไม่ได้
    เป็นการแฮ็กประเภทเดียวกับการทำให้ GitHub Actions ขุดคริปโต ผ่าน OSS repository
    ควรมองเป็นแบบฝึกหัดการแฮ็กที่น่าสนใจมากกว่า และไม่ควรนำวิธีแบบนี้ไปใช้ในโปรดักชัน
    อย่างน้อยก็ควรได้รับการอนุมัติจากผู้ดูแลบัญชีก่อน ไม่อย่างนั้นอาจตื่นมาเจอว่า AWS account ถูกปิดไปแล้วในสักวัน

    • ผมใช้วิธีนี้และเทคนิคอื่น ๆ มาหลายปีแล้ว แต่ไม่เคยโดนบล็อกเลย
      วิธีผ่าน S3 ยังมีประสิทธิภาพกว่าการรันกระบวนการซิงก์เพื่อกระจายข้อมูลไปยังปลายทางหลายแห่งในหลายกรณีด้วย

  • ค่าเก็บข้อมูลของ S3 คิดค่าบริการเป็น GB-เดือน ดังนั้น 1TB × $0.023 ต่อ GB ÷ 730 ชั่วโมงต่อเดือน น่าจะออกมาประมาณ 3 เซนต์ถ้าเก็บไว้ใน bucket เป็นเวลา 1 ชั่วโมง
    แต่ดูเหมือนกรณีนี้ข้อมูลถูกลบแทบจะทันที ดังนั้นถ้าอยู่แค่ประมาณ 1 นาที ต้นทุนก็อาจอยู่ราว 0.03 ÷ 60
    โดยทั่วไปคาดว่า AWS จะปัดขึ้นเป็น $0.01
    ค่า TimedByteStorage ใน Cost and Usage Report จะเป็นตัวตัดสินสุดท้าย
    https://handbook.vantage.sh/aws/services/s3-pricing/

  • S3 ก็เป็นทริกที่ดี และยังมีอย่างอื่นอีก
    ถ้าคุณเป็นลูกค้า AWS รายใหญ่ เช่น ใช้จ่ายเกิน $1 ล้านต่อปี ก็สามารถขอส่วนลดได้
    ช่วงหนึ่งส่วนลด การโอนข้าม availability zone สูงมาก
    อีกทางคือพยายามรวมทุกอย่างไว้ใน availability zone เดียวให้มากที่สุด
    การตั้งค่าแบบที่ DB อยู่โซน “b” แต่เซิร์ฟเวอร์เพียงตัวเดียวอยู่โซน “a” นั้นแย่ยิ่งกว่าการทำมาตรฐานให้ทุกอย่างอยู่โซนเดียวเสียอีก
    หากจะใช้หลาย availability zone ก็ควรทำ balancing ระหว่าง availability zone แบบที่รับรู้ภาระงาน

    • พอจะนึกออกว่าคงมีบางกรณีที่ใช้การตั้งค่าแบบ “DB อยู่โซน b เซิร์ฟเวอร์ตัวเดียวอยู่โซน a” แต่ก็จินตนาการไม่ค่อยออก
      เป็นเพราะเรื่องต้นทุนหรือ? แต่ดูแล้วก็ไม่ได้ช่วยประหยัดต้นทุนด้วย
    • อีกข้อหนึ่งคือเปิดใช้ storage class S3 Intelligent-Tiering ก็ได้

  • มันให้ความรู้สึกเหมือน การเลี่ยงภาษี ในโลกเทคโนโลยี
    ถ้ามีคนทำแบบนี้มากเกินไป AWS ก็คง “ปิดช่องนี้ไปเลย”
    AWS ไม่ได้เป็นองค์กรเดียว แต่แทบจะเหมือนมี AWS หลายสิบหรือหลายร้อยชุดที่ต่างทีมต่างมี KPI ของตัวเอง
    บางทีมอยากให้คุณลดค่าใช้จ่าย แต่ไม่ได้อยากสอนวิธีลดค่าใช้จ่ายจริง ๆ
    เมื่อคุณสร้างสิ่งที่ซับซ้อนมากพอแบบ AWS ทุกอย่างจะพันกันไปหมดจนลูกค้าไม่สามารถปรับให้เหมาะเฉพาะองค์ประกอบเดียวได้

    • นี่ไม่ใช่ช่องโหว่ แต่เป็น การออกแบบที่ตั้งใจไว้
      AWS ต้องการให้มีการใช้บางบริการในบางรูปแบบ จึงตั้งราคาให้ถูกมากเมื่อใช้งานแบบนั้น
      การใช้ S3 endpoint ก็เป็นหนึ่งในวิธีที่ AWS อยากให้มีการใช้บริการ S3
      CloudFront ก็เป็นอีกตัวอย่างหนึ่ง
      AWS อยากให้คนใช้ CloudFront จึงทำให้ CloudFront ถูกกว่าการส่งข้อมูลออกแบบอื่น ๆ

  • ทางเลือกแทนระบบลดค่าใช้จ่ายคลาวด์ที่ซับซ้อนก็คือ ไม่ใช้คลาวด์ไปเลย
    โฮสต์เอง หรือใช้ Cloudflare ที่คิดค่าทราฟฟิกขาออก 0 เซนต์ต่อ GB ก็ได้
    หรือจะเช่าเซิร์ฟเวอร์คลาวด์จากผู้ให้บริการ VPS หลายเจ้าที่ถูกกว่ามาก แล้วไม่ใช้บริการคลาวด์ราคาแพงและซับซ้อนที่พยายามล็อกอินลูกค้าด้วยการดูดเงิน 9 เซนต์, 12 เซนต์, 17 เซนต์ต่อ GB ก็ได้
    เอาจริง ๆ ถ้ามาถึงจุดที่ต้องวิเคราะห์ค่าใช้จ่ายคลาวด์อย่างละเอียดมาก ก็ควรพิจารณาเลิกใช้คลาวด์

    • ถ้ากำลังวิเคราะห์ค่าใช้จ่ายคลาวด์อย่างละเอียดอยู่ ก็แปลว่ากำลังใช้คลาวด์ได้ถูกทางอยู่แล้ว
      เพราะที่อื่นแทบเป็นไปไม่ได้เลยที่จะวิเคราะห์แบบนั้น
      คนที่บอกให้กลับไป on-premise ดูเหมือนไม่รู้ว่าค่าแรงของคนที่จะดูแลดาต้าเซ็นเตอร์โดยไม่ได้ทำมันเหมือนโฮมแล็บแพงแค่ไหน
      แม้แต่ Apple iCloud ยังใช้ AWS และ GCP เพราะมันคุ้มค่าทางเศรษฐกิจ
      ถ้าคิดว่าพอใช้คลาวด์ไม่ได้ก็ต้องกลับไป on-premise ก็แปลว่าไม่ค่อยสนใจเรื่องความน่าเชื่อถือเท่าไร
      ลองเริ่มจากคำนวณ ค่าใช้จ่ายในการป้องกัน DDoS ที่เกิน 10G ก่อน แล้วค่อยมาบอกว่าคลาวด์แพงกว่า
      เราจ่ายค่าแบนด์วิดท์ AWS มากกว่า 100,000 ดอลลาร์ แต่ก็ยังถูกกว่าวงจรอินเทอร์เน็ตเฉพาะทาง เพราะไม่ต้องจ่ายค่า network engineer สำหรับดูแล 3 availability zones
    • การบอกว่า “ถ้าต้องวิเคราะห์ค่าใช้จ่ายคลาวด์อย่างละเอียด ก็เลิกใช้คลาวด์ซะ” เท่ากับว่ากำลังทิ้งเหตุผลบางส่วนที่แต่แรกทำให้เลือกใช้คลาวด์
      หลายองค์กรย้ายไปโฮสต์บนคลาวด์เพราะในบรรดาข้อดีหลายอย่าง พวกเขาสามารถทำ FinOps และการควบคุมต้นทุน ได้ลึกกว่ามาก
      ขึ้นอยู่กับโครงสร้างพื้นฐาน ถ้าความต้องการด้าน storage หรือ compute มีความผันผวน โซลูชันบนคลาวด์ก็อาจเหมาะมาก
      ท้ายที่สุดมันก็เป็นแค่เครื่องมือ
      เคยทำงานทั้งในที่ที่ต้อง SSH เข้าไปอัปเดตซอฟต์แวร์บน production bare metal server จัดการไฟร์วอลล์ และตรวจสอบสตอเรจเอง และในที่ที่ให้ผู้ให้บริการคลาวด์ดูแลโฮสติ้งส่วนใหญ่ รวมถึงเคยย้ายจากฝั่งหนึ่งไปอีกฝั่งหนึ่งด้วย
      “คลาวด์” ไม่ได้ดีกว่าหรือแย่กว่า bare metal server หรือ VPS โดยตัวมันเอง แต่มันขึ้นอยู่กับ use case
      แค่ตรวจสอบอย่างรอบคอบว่าทำไมทางเลือกหนึ่งถึงเหมาะกว่า และประเมินใหม่ทุกครั้งที่สภาพแวดล้อมเปลี่ยนไป
      ท่าทีแบบ “คลาวด์ห่วย” นี่ดูเป็นเด็ก ๆ
    • วิธีแก้ในบทความนี้ค่อนข้างนำไปใช้ได้ง่าย
      ถ้าถูกล็อกอินอยู่กับ AWS แล้ว การจะย้ายออกมีต้นทุนไม่น้อย และในบางกรณีวิธีนี้อาจเป็นจุดกึ่งกลางที่ดี
    • ถ้าจะโฮสต์เอง ในความเป็นจริงถ้ากำลังใช้ความสามารถของคลาวด์อยู่ โดยเฉพาะ managed services ก็ต้องมีแผนก IT ที่มีทักษะซึ่งหลายบริษัทไม่มี
      ต้นทุนนั้นในหลายกรณีอาจหักล้างหรือสูงกว่าจำนวนเงินที่ประหยัดได้อย่างง่ายดาย
      นี่จึงเป็นเหตุผลใหญ่ที่ทำให้การเลือกคลาวด์กลายเป็นการตัดสินใจที่ชัดเจนมากสำหรับบริษัทต่าง ๆ
    • ในกรณีนี้ “การโฮสต์เอง” ไม่น่าจะช่วยอะไรได้
      ดูเหมือนว่า AWS จะขาดทุนจากการให้บริการกรณีนี้ด้วยซ้ำ
      ผู้เขียนเจอช่องโหว่ในโครงสร้างราคา AWS เลยทำให้ถูกได้ขนาดนี้
      ถ้าทำเองอาจจะแพงกว่า
      เดาได้แค่ว่าทำไมราคา AWS ถึงตั้งมาแบบนี้ แต่มีความเป็นไปได้สูงว่าเพื่อผลักดันให้คนใช้บริการหนึ่งมากกว่าอีกบริการหนึ่ง

  • ถ้าเป็นผู้ใช้ที่ใช้แบนด์วิดท์เยอะ ก็คุ้มที่จะดู Leaseweb, PhoenixNAP, Hetzner, OVH
    ราคาแบนด์วิดท์ถูกกว่าจนน่าเหลือเชื่อ
    เคยมีสถานการณ์แปลก ๆ มาก่อนที่ถ้าต้องจ่ายตามราคามาตรฐานบริษัทจะไปไม่รอดอยู่แล้ว แต่ฝ่ายขาย AWS ก็ยังไม่ยอมลดราคาแบนด์วิดท์ให้เลย

    • นั่นดูเป็นกรณีที่ค่อนข้างผิดปกติ
      ดูเหมือนว่าค่าโอนถ่ายข้อมูลโดยมากจะเป็นรายการที่ต่อรองได้

  • อีกทริกหนึ่งคือใช้ ECR
    ส่งข้อมูลออกสู่อินเทอร์เน็ตได้ฟรี 5TB ต่อเดือน
    container image ต้องเป็นแบบสาธารณะ แต่เนื้อหาข้างในเข้ารหัสได้
    มีประโยชน์เมื่อเก็บ media archive ไว้ใน Glacier

  • ไม่เข้าใจว่า AWS ยังจะรีดเงินคนด้วย ค่าบริการโอนถ่ายข้อมูล ที่ไร้สาระแบบนี้ต่อไปได้อย่างไร
    ทั้งที่ข้าง ๆ กันมี Cloudflare R2 ที่ให้เงื่อนไขดีกว่าประมาณ 100 เท่า

    • ข้อมูลมี “แรงโน้มถ่วง”
      มันผูกคุณไว้กับที่ที่ข้อมูลอยู่ และเหมือนกับการหนีจากแรงโน้มถ่วงที่ต้องใช้เงิน การย้ายข้อมูลก็ต้องเสียเงินเช่นกัน
    • เมื่อ VM และ container ทั้งหมดอยู่บน AWS และ S3 ก็รองรับได้อย่างแข็งแกร่งมากไม่ว่าจะใช้ภาษา เฟรมเวิร์ก หรือการตั้งค่าแบบไหน การจะบอกทีมให้ไปใช้ผู้ให้บริการ object storage เจ้าอื่นจึงยากมาก
      ถ้า R2 มีปัญหาอย่างข้อมูลหายหรือโอนช้า ฉันก็จะโดนตำหนิ หรืออย่างน้อยก็โดนเรียกให้ไปช่วย
      แต่ถ้า S3 ทำข้อมูลหายหรือช้าในบางกรณี คนจะคิดว่าเราใช้งานอะไรผิดเอง และก็จะหาวิธีปรับปรุงกันต่อ
      ไม่มีใครถูกตำหนิ
      พูดตามตรง ถ้าธุรกิจสร้างมูลค่าอะไรได้บ้าง ค่าทราฟฟิกข้อมูลก็มักเล็กน้อยจนมองข้ามได้ และไม่จำเป็นต้องไป optimize มันด้วยซ้ำ
    • สร้างฟีเจอร์ใหม่ของ SaaS ที่ใช้แบนด์วิดท์ค่อนข้างมากบน R2 แล้วมันทำงานได้ดีมาก
      เงินที่ประหยัดได้ก็มหาศาลจริง ๆ
      ใช้ AWS-SDK(Node.js) เดิมทั้งหมด แค่ชี้ไปที่ R2 endpoint
    • เชื่อถือ Cloudflare น้อยกว่า AWS มาก
      ถ้าข้อมูลอยู่ใน AWS แอปพลิเคชันทั้งหมดในรีเจียนเดียวกันก็ใช้ข้อมูลนั้นได้โดยไม่เสียค่าทราฟฟิก
      อีกอย่าง ราคาที่อ้างในบทความเป็นราคาแสดงหน้าเว็บ และถ้าลูกค้าทำสัญญาซื้อแบนด์วิดท์ล่วงหน้า ราคาจะถูกกว่านี้มาก
    • R2 ยังใหม่อยู่พอสมควร
      ยังไม่แน่ใจว่าประสิทธิภาพและความพร้อมใช้งานในงาน production ดีแค่ไหน
      โดยเฉพาะเรื่อง durability นั้นตัดสินได้ยากมากหรือแทบเป็นไปไม่ได้
      S3 มีประวัติและผลงานพิสูจน์ตัวเองมายาวนานกว่ามาก ซึ่งเป็นข้อได้เปรียบ
      ถ้าทุกอย่างอยู่ใน AWS อยู่แล้ว การเก็บข้อมูลไว้ใกล้กันก็มีข้อดีเช่นกัน
      ทั้งนี้ขึ้นอยู่กับรูปแบบการใช้งานข้อมูลของคุณ ค่าใช้จ่ายขาออกอาจไม่ได้สูงมากเสมอไป
      แต่พอเริ่มมี outbound traffic มากจริง ๆ มันก็จะแพงแบบเหลือเชื่อ
      ถ้าคู่แข่งอย่าง R2 สามารถให้ความน่าเชื่อถือและประสิทธิภาพที่แข่งขันได้อย่างสมเหตุสมผล ก็น่าจะเพิ่มส่วนแบ่งตลาดได้