ความผิดพลาด AWS มูลค่า $1,000

 (geocod.io)
12 คะแนน โดย GN⁺ 2025-11-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • กรณีที่ การตั้งค่าเครือข่าย VPC และ NAT Gateway ของ AWS ผิดพลาด ทำให้เกิดค่าใช้จ่ายในการโอนถ่ายข้อมูล S3 ราว $900 ภายในวันเดียว และยอดสะสมรายเดือนเกิน $1,000
  • แม้จะเข้าใจกันว่าการโอนถ่ายจาก EC2 ไปยัง S3 นั้นฟรี แต่หาก วิ่งผ่าน NAT Gateway ภายใน VPC จะมีค่าประมวลผลข้อมูลแบบคิดเงิน
  • สาเหตุของปัญหาคือ ไม่ได้ตั้งค่า VPC Gateway Endpoint สำหรับ S3 จึงไม่มีเส้นทางเชื่อมต่อไปยัง S3 โดยตรงโดยไม่ผ่าน NAT Gateway
  • Gateway Endpoint นั้น ฟรีและไม่มีค่าบริการรับส่งข้อมูล สามารถตั้งค่าได้ง่ายด้วย Terraform เป็นต้น
  • เป็นกรณีตัวอย่างที่แสดงให้เห็นถึง ความสำคัญของการเฝ้าระวังค่าใช้จ่ายและการตรวจสอบการตั้งค่า VPC Endpoint เมื่อต้องดูแลโครงสร้างพื้นฐานบน AWS

เบื้องหลังของปัญหา

  • Geocodio ใช้ AWS เพื่อทำมิเรอร์ไฟล์ข้อมูลภูมิศาสตร์ภายในขนาดใหญ่ไปยัง S3
    • ข้อมูลประกอบด้วย address points, boundary data, ข้อมูลสำมะโนประชากร ฯลฯ มีขนาดตั้งแต่หลาย GB ไปจนถึงหลายร้อย GB
    • จำเป็นต้องซิงก์เป็นประจำจากแพลตฟอร์ม ETL ที่โฮสต์บน Hetzner ไปยังโครงสร้างพื้นฐานประมวลผลบน AWS
  • เรื่องที่ ค่าโอนถ่ายข้อมูลของ AWS สูง เป็นข้อร้องเรียนร่วมกันของทั้งอุตสาหกรรม โดย Cloudflare และ Corey Quinn ก็เคยชี้ปัญหานี้ไว้
  • ผู้เขียนได้ตรวจสอบโครงสร้างค่าใช้จ่ายก่อนเริ่มโปรเจกต์ และประเมินต้นทุนจากข้อเท็จจริงว่า
    1. การโอนถ่าย EC2–S3 ภายในรีเจียนเดียวกันนั้นฟรี
    2. การอัปโหลดไปยัง S3 (ขาเข้า) ฟรี

ค่าใช้จ่ายที่ไม่คาดคิด

  • หลังจากนำกระบวนการซิงก์กับ S3 ขึ้นใช้งาน ก็ได้รับการแจ้งเตือนความผิดปกติจาก AWS Cost Anomaly Detection
    • ภายในวันเดียว ปริมาณข้อมูลผ่าน NAT Gateway อยู่ที่ 20,167.32GB คิดเป็นค่าใช้จ่าย $907.53
    • ค่าใช้จ่ายสะสมรายเดือนทะลุ $1,000 ไปแล้ว
  • จึงเริ่มตรวจสอบว่า เหตุใดจึงถูกคิดค่าบริการ NAT Gateway ทั้งที่เข้าใจว่าการโอนถ่าย EC2–S3 ฟรี

การวิเคราะห์สาเหตุ: วิ่งผ่าน NAT Gateway

  • หาก VPC ใช้ NAT Gateway ทราฟฟิกไปยัง S3 ก็จะถูก route ผ่าน NAT Gateway โดยปริยาย
    • แม้จะเป็นการเรียกใช้บริการ AWS ภายในรีเจียนเดียวกัน หากผ่าน NAT ก็จะมี ค่าประมวลผลข้อมูล $0.045 ต่อ GB
  • ด้วยเหตุนี้ แม้การโอนถ่ายระหว่าง EC2–S3 จะฟรี ก็ยังถูกคิด ค่าใช้จ่ายของ NAT Gateway
  • วิธีแก้คือ สร้าง VPC Gateway Endpoint สำหรับ S3
    • ทำให้ เชื่อมต่อจาก VPC ไปยัง S3 ได้โดยตรง โดยไม่ผ่าน NAT Gateway หรือ Internet Gateway
    • ฟรีทั้งหมด ไม่มีทั้งค่าบริการรายชั่วโมงและค่ารับส่งข้อมูล

กระบวนการแก้ไข

  • เนื่องจากจัดการโครงสร้างพื้นฐานด้วย Terraform จึง เพิ่ม resource ของ Gateway Endpoint และผูกเข้ากับ route table
    • AWS จะอัปเดต routing ให้อัตโนมัติ เพื่อส่งทราฟฟิก S3 ไปยัง Endpoint แทน NAT Gateway
  • หลังจากนั้น การคิดค่าบริการที่เกี่ยวข้องกับ NAT Gateway ก็หยุดลง

บทเรียนและคำแนะนำ

  • แม้จะใช้งาน AWS มานาน ก็ยังเกิดค่าใช้จ่ายจาก การตกหล่นการตั้งค่า VPC Endpoint สำหรับ S3 ได้
  • ระบบเครือข่ายของ AWS มีความซับซ้อน และ โครงสร้างค่าใช้จ่ายอาจเปลี่ยนไปมากตามวิธีการตั้งค่า
  • คำแนะนำเพื่อป้องกันไม่ให้เกิดซ้ำ
    • เปิดใช้ AWS Cost Anomaly Detection: ช่วยตรวจจับค่าใช้จ่ายผิดปกติได้ตั้งแต่เนิ่น ๆ
    • ใช้ VPC Endpoint: ถือเป็นสิ่งจำเป็นเมื่อเข้าถึง S3·DynamoDB จาก VPC ที่ใช้ NAT Gateway
    • ตรวจสอบสมมติฐาน: อย่าเชื่อเพียงว่า “การโอนถ่าย EC2–S3 ฟรี” ควรทดสอบด้วยปริมาณน้อยก่อนแล้วติดตามค่าใช้จ่าย
    • คลาวด์มีความซับซ้อน: ต่อให้เป็นผู้ใช้ระยะยาวก็ยังต้องระมัดระวังอย่างต่อเนื่อง
  • ยังมีการยกตัวอย่างกรณีคล้ายกันของ Recall.ai ที่จ่าย $1 ล้านต่อปี สำหรับค่าใช้จ่ายในการประมวลผลข้อมูล WebSocket

การดำเนินการหลังจากนั้น

  • Geocodio ตรวจสอบเส้นทางการสื่อสารกับ S3 ของทุก VPC และ ตั้งค่า Gateway Endpoint ครบแล้ว
  • แนะนำผู้ใช้ AWS ให้ ตรวจสอบการตั้งค่า VPC Endpoint
  • สรุป: NAT Gateway คิดค่าบริการแม้กับทราฟฟิกไปยังบริการของ AWS และ สามารถหลีกเลี่ยงค่าใช้จ่ายได้ด้วยการใช้ VPC Endpoint

แหล่งข้อมูลเพิ่มเติม

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

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

 
GN⁺ 2025-11-21
ความคิดเห็นจาก Hacker News

  • เห็นกรณีแบบนี้ที่เป็น บิลค่าใช้จ่ายถล่มทลาย โผล่ในซับเรดดิตเกี่ยวกับคลาวด์หลัก ๆ ทั้งสามแห่งแทบวันละครั้งอยู่บ่อย ๆ
    ผู้ให้บริการคลาวด์มักส่งการแจ้งเตือนแบบล่าช้าเสมอ และผู้ใช้ก็ทำได้แค่ ภาวนาและขอความช่วยเหลือ
    แถมบางรายยังอ้างว่า “ในทางเทคนิคแล้วเป็นไปไม่ได้ที่จะมีบัญชีแบบ hard cap” แต่ในความเป็นจริง Azure มีบัญชีแบบนั้นอยู่แล้ว

    • ผมคิดว่านี่ไม่ใช่ความมุ่งร้าย แต่เป็นการผสมกันของ ความไร้ประสิทธิภาพและการขาดแรงจูงใจ มากกว่า
      ผมใช้ AWS มานานกว่าสิบปีแล้ว และพบว่าความไม่ต่อเนื่องของการออกแบบระหว่างบริการกับ การแบ่งเป็นไซโลภายในองค์กร นั้นรุนแรงมาก
      ในองค์กรใหญ่ ๆ ไม่มีผู้บริหารคนไหนอยากแก้ปัญหาที่จะกระทบ KPI ของตัวเอง แต่จะไปโฟกัสกับการเปิดตัวบริการตามกระแสอย่าง AI หรือบล็อกเชนเพื่อเก็บแต้มเลื่อนตำแหน่งแทน
    • เมื่อวาน AWS เพิ่งประกาศ แพ็กเกจราคาเหมาจ่ายแบบไม่มีค่าใช้จ่ายส่วนเกิน
      เลือกได้ระหว่างแพลน $0, $15, $200 ซึ่งช่วยกันบิลพุ่งจากคำขอใช้งานหรือการโอนถ่ายข้อมูลที่เพิ่มขึ้นแบบไม่คาดคิดได้
      ลิงก์บล็อกทางการของ AWS
    • เป็นข่าวเดียวกัน แต่คราวนี้เป็นแพ็กเกจราคาเหมาจ่ายสำหรับ CDN โดยมี tier $0 ที่รวม S3 storage และ bandwidth ด้วย
      เธรด HN ที่เกี่ยวข้อง
      แม้การตั้งเพดานค่าใช้จ่ายพร้อมรักษาเสถียรภาพของบริการจะเป็นเรื่องยาก แต่กรณีนี้ก็ พิสูจน์แล้วว่าในทางเทคนิคทำได้จริง
    • AWS เลือกแนวทางให้ลูกค้าจ่ายไปก่อนถ้าเผลอโดนคิดเงินผิด แล้วค่อยคืนเงินทีหลัง
      เพื่อหลีกเลี่ยงความเสี่ยงด้านชื่อเสียงจากการหยุดให้บริการหรือปัญหาโครงสร้างพื้นฐานล่ม
    • สิ่งที่น่าเศร้าที่สุดในโพสต์แบบนี้คือการจบลงด้วยข้อสรุปว่า “เราน่าจะเข้าใจบิลให้ดีกว่านี้”
      แต่ปัญหาอาจอยู่ที่ตัวคลาวด์เองก็ได้ สำหรับธุรกิจขนาดเล็กที่ต้องการ โครงสร้างต้นทุนที่คาดการณ์ได้ คลาวด์อาจไม่ใช่ตัวเลือกที่เหมาะ

  • เรื่องแบบนี้เกิดบ่อยเกินไปจนผมคิดว่า S3 VPC Endpoint ควรถูกตั้งเป็นค่าเริ่มต้นตอนสร้าง VPC
    และถ้าใช้ทางเลือกอย่าง fck-nat แทน NAT Gateway ก็จะประหยัดค่าทราฟฟิกต่อ GB ได้

    • แต่ S3 Gateway Endpoint จะ ทำให้การทำงานกับ S3 ข้ามรีเจียนพัง การเปลี่ยนค่าเริ่มต้นอาจทำให้ลูกค้าพังได้
    • อีกวิธีก็คือย้ายไปใช้ IPv6 แล้วใช้ Egress Gateway
    • ตอนสร้าง VPC ในคอนโซลสามารถตั้งค่าได้ด้วยติ๊กบ็อกซ์อันเดียว
    • ถ้าไม่ได้สร้างผ่านคอนโซลแต่สร้างด้วย IAC (Infrastructure as Code) ก็ควรเขียนทุกการตั้งค่าให้ชัดเจนอยู่แล้ว
    • โดยพื้นฐานแล้ว VPC ควรถูกออกแบบให้มี โครงสร้างที่ให้ความสำคัญกับความปลอดภัยเป็นอันดับแรก
      ควรอยู่ในสถานะปฏิเสธการเข้าถึงเป็นค่าเริ่มต้น แล้วค่อยอนุญาตการเข้าถึงอินเทอร์เน็ตอย่างชัดเจน ไม่เช่นนั้นผู้โจมตีอาจขโมยข้อมูลออกไปได้

  • ผมก็เคยพลาดคล้าย ๆ กัน
    เคยอัปโหลดข้อมูลทดสอบไปยังอัลกอริทึมแนะนำของ AWS แล้วลืมมันไป จนหลายเดือนต่อมาธนาคารแจ้งเตือนว่าเงินในบัญชีไม่พอ
    อัลกอริทึมยังทำงานต่อเนื่องและถูกคิดเงินเดือนละมากกว่า 1,000 ดอลลาร์ สุดท้ายเงินหายไป 5,000 ดอลลาร์

    • ผมเคยทำงานในฝ่ายเรียกเก็บเงินมาก่อน เลยมี ความหวาดระแวงแบบพอดี ๆ กับเรื่องพวกนี้
      ผมเช็กยอดเงินทุกวัน ทำเครื่องหมายให้อีเมลเรียกเก็บเงินทุกฉบับเป็นอีเมลสำคัญ
      และติดนิสัยตั้ง วงเงินบัตรเสมือน แยกไว้สำหรับแต่ละบริการ

  • ผมก็เคยพลาดแบบเดียวกันและเสียไป 60,000 ดอลลาร์
    ผมไม่เข้าใจว่าทำไม S3 Endpoint ถึงไม่ถูก deploy เป็นค่าเริ่มต้น

    • เดาว่าถ้ามีคนเสนอในประชุมภายในว่า “ใส่อันนี้เป็นค่าเริ่มต้นเถอะ” ก็คงถูกเลื่อนด้วยเหตุผลว่า “รายได้จะลดลง”
    • ยังมีมุกประมาณว่า “นั่นมันเงินเดือนทั้งปีเลยนะ แต่ลองคิดถึงความซับซ้อนของการ self-host infra เองสิ”

  • ผมมักถูกถามว่า “ทำไมค่า AWS ถึงพุ่งระเบิด” ซึ่งส่วนใหญ่เป็นเพราะการผสมกันของ NAT + S3 + สมมติฐานที่ผิด
    การโอนข้อมูลจาก EC2 ไป S3 ฟรีก็จริง แต่ถ้าวิ่งผ่าน NAT จะเสียเงิน
    เพราะงั้นผมจึงให้เช็กลิสต์นี้

    1. ถ้าเป็น private subnet ที่คุยกับ S3 หรือ DynamoDB บ่อย ให้พิจารณาใช้ Gateway Endpoint
    2. เฝ้าดูค่า NAT ผ่านแดชบอร์ดแยกต่างหาก
    3. ก่อนย้ายข้อมูลก้อนใหญ่ ให้ลองวาด ไดอะแกรมการไหลของค่าใช้จ่าย ดูก่อน
      ยังดีที่ Cost Anomaly Detection ทำงานทันเวลา เสีย 1,000 ดอลลาร์ก็ยังเจ็บ แต่ดีกว่าเสีย 20,000 ดอลลาร์

  • ผมตกใจตอนเห็นว่าการดาวน์โหลดข้อมูลจาก AWS ต้องจ่าย $0.09 ต่อ GB
    ตอนอัปโหลดข้อมูลเข้าไปฟรี แต่จะดึงออกมากลับต้องเสียเงินงั้นเหรอ?

    • นี่เป็นส่วนหนึ่งของ กลยุทธ์ lock-in เข้าได้ง่ายแต่ออกแพง
      กรณีนี้เป็นเคสพิเศษที่เกิดจากการตั้งค่า NAT ผิดจนทราฟฟิกภายในถูกนับเป็นทราฟฟิกภายนอก
    • 9 เซนต์ต่อ GB ฟังดูแทบจะเป็น การชาร์จราคาแบบโหดเหมือนแพ็กเกจมือถือ เลย นี่คงเป็นเหตุผลที่ Cloudflare ได้รับความนิยม
    • อัปโหลดถูก แต่ดาวน์โหลดแพง เป็นโครงสร้างที่ทุกครั้งที่ลูกค้าส่งข้อมูลให้ผู้ใช้ AWS ก็จะหักส่วนแบ่งไปด้วย
    • บริการสำหรับผู้บริโภคมักรวมอยู่ในค่าสมาชิกรายเดือน แต่ AWS เป็น โครงสร้างที่ทำให้คุณรับรู้ต้นทุนโดยตรง
    • ทำให้นึกถึงมุกว่า “ผลิตในแคลิฟอร์เนีย ออกไปได้ แต่จากไปไม่ได้”

  • สงสัยว่า Amazon คืนเงินสำหรับความผิดพลาดแบบนี้หรือเปล่า

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

  • VPC NAT Gateway มีชื่อเสียมาก
    ตอนอยู่ Amazon ผมก็เคยเจอปัญหาคล้ายกัน แต่เป็นบัญชีของบริษัทเลยไม่ได้เสียเงินเอง
    คนที่ต้องจ่ายเงินจริง ๆ นี่น่าเห็นใจมาก

    • ส่วนตัวผมไม่เข้าใจว่าทำไม NAT Gateway ถึงถูกใช้กันแพร่หลายขนาดนี้ ในหลายกรณี Internet Gateway ก็เพียงพอแล้ว

  • ถึงจะไม่ได้ช่วยกรณีนี้โดยตรง แต่เมื่อวาน AWS เปิดตัว แพ็กเกจราคาเหมาจ่ายสำหรับ CDN
    และยังมี tier $0 ที่รวม S3 storage กับ bandwidth มาด้วย
    ลิงก์ที่เกี่ยวข้อง
    หวังว่าในอนาคตจะขยายไปยังบริการอื่นด้วย

  • ตอนอายุ 22 ผมเพิ่งเริ่มจับงาน infra ครั้งแรก แล้วโดน บิล 300 ดอลลาร์ภายในสองวัน
    AWS ยอดเยี่ยมก็จริง แต่สำหรับมือใหม่ การคำนวณค่าใช้จ่ายไม่โปร่งใสเกินไป

    • สงสัยว่าทำไมถึงไม่ปรับปรุงเรื่องนี้