ยอดเรียกเก็บเงินโดยประมาณของ AWS แสดงเป็น 1.7 พันล้านดอลลาร์ ทั้งที่ปกติใช้น้อยกว่า 5 ดอลลาร์

• บัญชี AWS ที่ปกติมีค่าใช้จ่าย น้อยกว่า 5 ดอลลาร์ แสดงยอดเรียกเก็บเงินโดยประมาณของเดือนนี้เป็น 1.7 พันล้านดอลลาร์
• เนื่องจากความแตกต่างระหว่างการใช้งานจริงกับยอดเรียกเก็บเงินสูงเกินไป จึงมองว่าเป็น สถานการณ์ที่ข้อมูลยอดเรียกเก็บเงินโดยประมาณไม่ถูกต้อง
• ผู้โพสต์ได้สร้าง ตั๋วสนับสนุน AWS แบบเร่งด่วน เพื่อตรวจสอบและรับมือกับปัญหา
• สามารถตรวจสอบสถานะบริการของ AWS ได้ที่ AWS Health Dashboard
• มีการสอบถามว่ามีผู้ใช้รายอื่นพบอาการเดียวกันหรือไม่ และภายหลังได้เพิ่ม โพสต์ Reddit ที่เกี่ยวข้องด้วย

---

ยอดเรียกเก็บเงินโดยประมาณที่ผิดปกติ

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

การตรวจสอบและการรับมือ

• ได้สร้าง ตั๋วสนับสนุน AWS แบบเร่งด่วน เพื่อตรวจสอบปัญหา
• สามารถตรวจสอบสถานะบริการได้ที่ AWS Health Dashboard
• ได้ถามผู้ใช้อื่นว่าพบอาการเดียวกันหรือไม่ และภายหลังได้แชร์ โพสต์ Reddit ที่เกี่ยวข้อง

[GN⁺]

ความคิดเห็นจาก Hacker News

• เคยจัดการข้อผิดพลาดแบบเดียวกันที่ AWS สาเหตุมาจาก การตั้งค่าหน่วยผิด เดิมทีตั้งใจจะคิดค่าบริการประมาณ 5 เซนต์ต่อ GB แต่พอในแพ็กเกจราคาลืมใส่ GB ระบบก็ใช้หน่วยเริ่มต้นคือไบต์แทน กลายเป็น 5 เซนต์ต่อไบต์ และภายในไม่กี่ชั่วโมงลูกค้าบางรายก็เห็นบิลมูลค่าหลายล้านดอลลาร์
  ได้รับสายเรียกจากทีมซัพพอร์ตประมาณตี 2 และแก้ไขรวมถึงปรับบิลให้ถูกต้องเสร็จภายในตี 3–4 จากนั้นก็ส่งอีเมลขอโทษทันที ค่าการใช้งานที่บริการส่งออกมาไม่ได้ผูกกับราคาโดยตรง แต่ SKU หรือรายการคิดเงินแต่ละรายการจะถูกนิยามเป็น แพ็กเกจราคา ที่มีประเภทหน่วย รีเจียน และราคาต่อหน่วย ระบบจะจับคู่บันทึกการใช้งานกับแพ็กเกจราคาตาม account ID, รีเจียน, SKU ฯลฯ ดังนั้นถ้าระบุประเภทหน่วยผิด การแปลงหน่วยก็พังและทำให้ยอดเรียกเก็บออกมาเหลวไหล

  • ไม่มีการทดสอบเลยหรือ? แค่ตั้งค่ารายละเอียดเล็ก ๆ ที่ดูธรรมดาผิดไปอย่างเดียว ก็อาจทำให้แอดมินหลายแสนคนต้องเจอ สายเรียกกลางดึกและหัวใจแทบวาย ได้เลยหรือ?
    แน่นอนว่าคงจะบอกว่า “นี่ไม่ใช่รายละเอียดธรรมดานะ Michael!” แต่: https://www.youtube.com/watch?v=3fGHaVn5rGo
  • สงสัยว่าระบบบิลของ AWS ยังใช้ ไฟล์ CSV ส่งข้อมูลอยู่หรือเปล่า เมื่อราวสิบกว่าปีก่อน ตอนเข้าเวร on-call ครั้งแรกที่ AWS มีวิศวกรที่ “ฉลาด” คนหนึ่งใส่เรคคอร์ดทดลองไว้ในฟิลด์คำอธิบายของข้อมูล production ประมาณว่า “ถ้าใส่, เครื่องหมายจุลภาค, ในฟิลด์นี้จะเกิดอะไรขึ้น” แล้วทำให้การประมวลผลบิลพัง
    ผมนั่งดูเรคคอร์ดนั้นแพร่กระจายไปเรื่อย ๆ แล้วรีเจียนต่าง ๆ ก็ล้มเหลวตามแบบเดียวกันทีละแห่ง คนคนเดียวทำให้ค่ำคืนของคนจำนวนมากพัง ทั้งที่ใช้ test endpoint ได้ แต่กลับเลือก ทดลองใน production
  • นี่ไม่ใช่เรื่องที่ควรเอามาล้อเล่น คนที่มีโรคประจำตัวอย่างโรคหัวใจและหลอดเลือด ถ้าเห็นยอดบิลแบบนี้กะทันหัน อาจเสียชีวิตจริงได้จากความกังวล ช็อก และความรู้สึกหมดหนทาง
  • นี่แหละเหตุผลที่ควรออกแบบให้ ล้มเหลวแบบส่งเสียงดัง (fail loud) เสมอ แทนที่จะเลือกค่าเริ่มต้นโง่ ๆ
  • สงสัยว่าเป็นเหตุการณ์ที่เกิดขึ้นในวันที่เปิดตัว gp3 EBS volume หรือเปล่า

• ได้รับอีเมลเตือนติดกันสามฉบับว่างบประมาณเกินเพดาน 18 ดอลลาร์ พอเข้าไปดู ค่าใช้จ่ายเป็น 78 ล้านดอลลาร์ ตอนแรกคิดว่าเป็นฟิชชิง เลยล็อกอินเข้าบัญชีจริงโดยตรง แต่ก็ยังเป็น 78 ล้านดอลลาร์อยู่ดี ทำเอาช็อกมาก

  • อยากพนันเลยว่าวันนี้คำอธิบายในประกาศรับสมัครงานนี้จะถูกแก้ไหม: “Software Development Engineer II, AWS Invoicing”
    https://www.amazon.jobs/de/jobs/10428480/software-developmen...
    มี คำบรรยายงานสุดหรู ว่าจะใช้ generative AI, large language models, knowledge graph และ agentic architectures เพื่อทำ release readiness, ประสานงาน cloud-native services และทำ continuous validation แบบอัตโนมัติ
  • บิลของผมคือ มากกว่า 1 พันล้านดอลลาร์ ตอนแรกเกือบจะทิ้งไปเพราะคิดว่าเป็นฟิชชิง แต่ดูเหมือนจริงมากจนเข้า AWS โดยตรง แล้วพอเห็นยอดบิลคาดการณ์ก็เกือบหัวใจวาย
    ภายหลังเจอแบนเนอร์แจ้งเหตุขัดข้องในหน้าซัพพอร์ต แต่สงสัยว่าทำไมบนหน้าบิลที่บอกว่า “คุณเป็นหนี้ 1 พันล้านดอลลาร์” ถึงไม่มีแบนเนอร์แจ้งเตือน
  • ผมเองก็เห็นว่า URL awstrack.me น่าสงสัยมาก และไม่เคยได้รับคำเตือนแบบนี้มาก่อน เลยมั่นใจว่าเป็นฟิชชิง ผมไม่กดลิงก์ แต่เข้า console ไปดู พบว่ามีเหตุขัดข้องที่ทำให้ยอดบิลแสดงผิด ทว่าไม่มีการพูดถึงอีเมลแจ้งเตือนเลย กลับกังวลด้วยซ้ำว่าอาจมีผู้โจมตีอาศัยช่วงเกิดเหตุเพื่อหลบการตรวจจับหรือไม่
    หลังตรวจ log แล้วถึงรู้ว่าแค่ประกาศเหตุขัดข้องไม่ได้ระบุผลกระทบให้ครบถ้วนเท่านั้น จากนั้นก็กลับไปดื่มกาแฟต่อ คราวหน้าคงต้อง ตรวจจากตรงนี้ก่อน
  • ถ้าดัดแปลงมุกเก่า บิล AWS 78,000 ดอลลาร์คือปัญหาของผม แต่ถ้าเป็น 78 ล้านดอลลาร์ นั่นคือปัญหาของ Amazon
  • บัญชีองค์กรแสดงยอดบิล มากกว่า 3 ล้านล้านดอลลาร์

• ข้อผิดพลาดครั้งนี้เหลวไหลเกินไปจนคงถูกแก้เร็ว ๆ นี้ แต่ช่วงต้นทศวรรษ 2010 ผมเคยเจอข้อผิดพลาดที่ซ่อนอยู่ในบิลจริง มีการคำนวณ ส่วนลด EC2 Reserved ของเซิร์ฟเวอร์บางเครื่องผิด และแม้ว่าจะวิเคราะห์รายละเอียดการใช้งานเป็นประจำด้วยสเปรดชีต 18 แท็บ ยอดเงินก็ยังไม่ตรง จึงใช้เวลาหลายเดือนตามหาส่วนต่าง
  หลังพบสาเหตุแล้ว ยังต้องใช้เวลาไม่น้อยในการโน้มน้าวว่าเป็นระบบของ AWS ที่ผิด ระหว่างนั้นส่วนต่างก็สะสมต่อไป หลังจาก 14 เดือนจึงได้รับ เงินคืน 7,000 ดอลลาร์ ได้ยินว่าต้องได้รับอนุมัติจากผู้รับผิดชอบของ AWS และหลังจากนั้นก็ไม่เคยเห็นข้อผิดพลาดในการคำนวณของ AWS อีก

  • เครดิต 7,000 ดอลลาร์เอง ตอนนั้น product manager หรือ director ใกล้ตัวก็ออกให้ได้โดยแทบไม่ต้องมีการกำกับมากนัก ปัญหาคือ ระยะเวลา 14 เดือน การแก้ไขภายในรอบบิลเดียวกันนั้นง่าย และรอบก่อนหน้าก็ยุ่งยากแต่พบได้ทั่วไป แต่ถ้าต้องแก้ย้อนหลังไปถึงปีงบการเงินก่อน ๆ ต้องผ่านฝ่ายการเงิน จึงเจ็บปวดกว่ามาก
  • เพื่อนร่วมงานคิดว่าผมดู Cost Explorer ละเอียดเกินไป แต่เวลาที่ใช้หาใช้จ่ายแปลก ๆ ส่วนใหญ่ก็คุ้มค่าเกินพอ ผมคงไม่ได้ใช้เวลามูลค่า 7,000 ดอลลาร์ไปกับการตามข้อผิดพลาดนี้ และระหว่างทางก็น่าจะเจอ โอกาสปรับต้นทุนให้เหมาะสม ที่ใหญ่กว่านั้นด้วย
    ผมก็ไม่อยากเสียเงินเปล่าไปช่วยทำให้เรือยอชต์ของ Jeff Bezos ใหญ่ขึ้น
  • จะบอกว่า “คงถูกแก้เร็ว ๆ นี้” ก็ยาก เพราะนี่ก็ ผ่านมา 12 ชั่วโมงแล้ว ดูเหมือนมนุษย์จะไม่เข้าใจโค้ดที่เอเจนต์เขียนและนำไปใช้

• หน่วยที่ควรจะเป็น GB of storage consumed น่าจะปนกับ Bytes of storage consumed จนเกิด ข้อผิดพลาดขนาด 2^30 เท่า
  “ควรสงสัยการคำนวณได้ครับ ผมพยายามค้นหานิยามของฟิลด์ แต่เชื่อมต่อกับเซิร์ฟเวอร์ MCP ไม่สำเร็จ และแทนที่จะตรวจสอบ ผมเดาเอาเอง เป็นความผิดของผมครับ แต่ดูรายได้ที่เพิ่มขึ้นสิ!”

  • ขอให้คำนวณจำนวนเงินที่จะเรียกเก็บจากลูกค้า แล้วให้ตัวเลข 0.45, 1.67, 2.50 มา ดังนั้นผลรวมคือ 4.62 แต่ก็อาจเป็นตัวเลขอื่นได้เหมือนกัน อาจต้องเอามาต่อกันก็ได้ และถ้าจุดหมายถึงการคูณ 0 . 45 . 1 . 67 . 2 . 50 ก็จะกลายเป็น 3,015,000
    ถ้าคูณด้วย 0 ก็ควรเป็น 0 แต่จะไม่เรียกเก็บอะไรเลยก็คงไม่ได้ ดังนั้นคำตอบที่ถูกคือ 3,015,000 พันดอลลาร์
  • ตอนนี้แทบแยกไม่ออกแล้วว่า “ควรสงสัยการคำนวณได้ครับ” เป็นคำล้อเลียนหรือเป็นคำตอบจริง ต่อให้สั่งให้ LLM เขียนประโยคที่โง่จนไม่มีทางออกมาได้ ก็คงไม่มี ขีดจำกัดของความโง่ แบบนั้นอยู่ดี
  • วันนี้ผมให้เอเจนต์โลคัลอ่าน CSV ที่มีหน่วยขนาดแบบมนุษย์อ่านได้ แล้วให้นับจำนวนแถวตามช่วง GB แต่แปลกมากที่มันตีความ MB เป็น GB จนผิดหมด มองย้อนกลับไปแล้ว คำนวณเองใน Excel น่าจะเร็วกว่าด้วยซ้ำ
  • ถ้าเป็น 2*30 ก็เท่ากับ 60 ดังนั้นจ่ายแค่ 28.3 ล้านดอลลาร์ก็พอ แต่ที่ตั้งใจคงเป็น 2^30 และถ้าเป็นแบบนั้นก็จะกลายเป็น 1.5 ดอลลาร์
  • เขียนระบบเรียกเก็บเงินด้วย vibe coding แล้วเพิ่มรายได้ได้ 9,000% ถือเป็นผลงานเลื่อนตำแหน่งที่ยอดเยี่ยม

• ตอนเช้าเห็นอีเมลแจ้งเตือนบิล แล้วนึกว่าตัวเองเผลอทำคีย์ AWS รั่วจนใช้ไป 437 พันล้านดอลลาร์ โชคดีที่ผมไม่มีเงินขนาดนั้น และได้อะดรีนาลีนพุ่งแบบไม่เคยเป็นมาก่อนโดยไม่ต้องพึ่งกาแฟ ต้องขอบคุณ AWS

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

• ก็แจ้งสถานะงบประมาณให้ผู้จัดการบัญชีทราบ แล้วขอให้เขาเมตตาอนุญาตให้ผ่อนจ่ายอย่างจริงใจเดือนละ หลายพันล้านดอลลาร์ จนกว่าสถานะการเงินจะดีขึ้นอีกครั้ง

  • ห้ามแสดงความอ่อนแอ ต้องเผชิญหน้าตรง ๆ แล้วไปออก บัตรเครดิตที่มีวงเงินสูงกว่าเดิม

• ถ้าติดหนี้ธนาคาร 100 ดอลลาร์ นั่นเป็นปัญหาของเรา แต่ถ้าติดหนี้ 1.7 พันล้านดอลลาร์ นั่นเป็นปัญหาของธนาคาร

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

• ดูเหมือน AWS เห็น Anthropic เรียกเก็บเงิน 16 ล้านดอลลาร์ จากคนที่มีการใช้งานเป็นศูนย์ แล้วคิดว่าไม่จำเป็นต้องหยุดแค่หลักล้าน
  https://www.techtimes.com/articles/320266/20260712/anthropic...

  • ถ้าสตาร์ทอัพตรวจสอบบิล AI ชื่อ Vaudit ตรวจบิลมูลค่า 34 ล้านดอลลาร์ของลูกค้าองค์กร 60 ราย แล้วพบการ เรียกเก็บเงินเกินประมาณ 1.7 ล้านดอลลาร์ หรือคิดเป็นอัตราข้อผิดพลาดราว 5% ก็ถือว่าค่อนข้างร้ายแรง

• เมื่อไม่นานมานี้ผมเพิ่งรู้ว่าตอนจ่ายเงินที่ Whole Foods ระบบไม่สามารถจดจำ บัตร Chase Amazon Prime โดยอัตโนมัติได้อย่างเสถียรอีกต่อไป ทำให้ส่วนลดไม่ถูกใช้ให้อัตโนมัติ สงสัยว่ามีลูกค้ากี่คนที่จ่ายแบบเดิมที่เคยใช้งานได้ดีมาหลายปี แต่กลับต้องจ่ายราคาเต็ม
  พนักงานบริการลูกค้าที่ร้านบอกว่าเรื่องนี้เปลี่ยนไปในช่วงปีที่ผ่านมา และคาดว่าเป็นผลข้างเคียงที่ไม่ได้ตั้งใจจากการเอาฟีเจอร์จ่ายเงินด้วยฝ่ามือออกไป แม้จะไม่เกี่ยวข้องโดยตรง แต่ก็ทำให้นึกว่า Amazon ยังมีอะไรอีกที่คำนวณไม่ถูก

  • ถึงเวลา ฟ้องแบบกลุ่ม หรือยื่นคดีมูลค่าน้อยเป็นพัน ๆ คดีแล้ว ต่อให้มีข้อกำหนดอนุญาโตตุลาการ ภาระในการจัดการเรื่องนี้ก็จะมหาศาลอยู่ดี หวังว่าจะมีใครตัดสินใจทำสิ่งที่ถูกต้องแล้วคืนเงินให้อัตโนมัติ
  • ปัญหาเล็ก ๆ แบบนี้เกิดขึ้นมากมายในระบบที่เมื่อก่อนเคยเรียบง่ายและเสถียร ทั้งหมดคงไม่ใช่เพราะ vibe coding แต่ก็อดสงสัยไม่ได้ว่ามีกี่ปัญหาที่เป็น ผลจาก vibe coding

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

  • AWS แทบจะมีสถานะใกล้เคียงกับ ผู้ให้บริการสาธารณูปโภค ดังนั้นหากจัดการเรื่องการเรียกเก็บเงินอย่างประมาท สุดท้ายก็หลีกเลี่ยงไม่ได้ที่จะถูกกำกับดูแลในระดับเดียวกัน
  • สำหรับบริการที่มีต้นทุนผันแปร ควรใช้ บัตรที่กำหนดวงเงินใช้จ่าย เสมอ
  • คิดว่าการตรวจจับบัญชีที่ถูกยึดให้แม่นยำ 100% นั้นเป็นไปไม่ได้ แม้ถ้าคนดูเองจะเห็นได้ชัด แต่ก็ไม่สามารถให้มนุษย์ตรวจสอบการใช้งานของทุกบัญชีล่วงหน้าได้
  • บทเรียนแรกของการใช้ผู้ให้บริการคือ อย่าเปิดใช้งานการชำระเงินอัตโนมัติโดยเด็ดขาด ความเสี่ยงที่ผู้ให้บริการจะถอนเงินทั้งหมดจากบัญชีได้เองนั้นใหญ่กว่าความสะดวกหรือส่วนลดมาก
  • เคยเอาบางส่วนของโฮมแล็บไปไว้บน AWS อยู่ช่วงหนึ่ง ตอนนั้นเป็นผู้สอนในห้องเรียนที่ให้นักศึกษาเรียนรู้คลาวด์ และอาจารย์ผู้สอนแนะนำให้สร้างสภาพแวดล้อมสำหรับการทดลอง ผมจึงติดตั้ง LAMP stack กับ MediaWiki บน EC2 ระดับฟรีด้วย การตั้งค่าเริ่มต้นไม่ได้ยากนัก แต่มีสองเหตุผลที่ทำให้เลิกใช้ไปตลอด
    อย่างแรก แม้กระทั่งทุกวันนี้ การป้องกันระบบ Linux ธรรมดาที่เปิดสู่อินเทอร์เน็ตให้เพียงพอนั้นแทบเป็นไปไม่ได้ หรือไม่ก็ต้องใช้แรงงานมากเกินไป ต่อให้ติดตั้ง fail2ban และปิดพอร์ตจำนวนมาก การโจมตีสแปมก็ยังเข้ามาทางชั้นแอปพลิเคชันอยู่ดี อย่างที่สอง การ บังคับใช้เพดานค่าใช้จ่ายบนคลาวด์ ในแต่ละรอบบิลนั้นทำไม่ได้จริง แม้ส่วนใหญ่จะอยู่ในโควตาฟรี แต่ถ้าตั้งค่าผิดไปอย่างเดียวหรือทรัพยากรพุ่งกระฉูด ก็อาจเกิดบิลก้อนใหญ่ที่โต้แย้งได้ยาก โดยเฉพาะยังอาจเกิดจากสาเหตุที่อยู่นอกการควบคุม เช่น ผู้ใช้ภายนอกใช้ทรัพยากร VPC และทราฟฟิกขาออกไปยังภายนอก ดังนั้นจึงปิดบัญชี และยิ่งเข้าใจอย่างลึกซึ้งกับบริษัทที่ถูกบังคับให้ใช้คลาวด์แทนโครงสร้างพื้นฐานของตัวเอง ทั้งที่ควบคุมค่าใช้จ่ายไม่ได้