กลับไปใช้ AWS แล้ว แต่ก็ได้ตระหนักอีกครั้งว่าทำไมฉันถึงเลิกใช้มัน

 (fourlightyears.blogspot.com)
18 คะแนน โดย GN⁺ 2026-05-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้จะสนับสนุน AWS มาตั้งแต่แรก แต่เมื่อความไม่พอใจสะสมมากขึ้น เช่น *โครงสร้างการคิดค่าบริการที่ซับซ้อน และความซับซ้อนของทั้งแพลตฟอร์ม ก็ทำให้เลิกชอบ AWS ไปในที่สุด
  • มองว่าทั้งค่าใช้จ่ายของ DynamoDB, ค่าบริการ egress ที่สูงถึง 9 เซนต์ต่อกิกะไบต์, รวมถึงการคิดเงินซ้ำซ้อนสองต่อสามต่อสำหรับการย้ายข้อมูลภายใน ล้วนยังแพงและเข้าใจได้ยาก
  • กลับมาใช้งานเพื่อทดสอบ Claude บน AWS Bedrock และเบนช์มาร์กเครื่องระดับ 192 คอร์ แต่เพราะมีกิจกรรมเกิดขึ้นกะทันหันในบัญชีที่แทบไม่ได้ใช้ จึงมีการแจ้งเตือนว่า สงสัยว่าบัญชีถูกเจาะระบบ และบัญชีถูกระงับ
  • เมื่อบัญชีถูกระงับ แม้แต่ AWS WorkMail สำหรับใช้งานธุรกิจ ก็หยุดทำงานไปด้วย และตลอด 4 วันภายใต้แผนซัพพอร์ตฟรีก็ยังไม่สามารถกู้คืนบัญชีได้
  • จึงสรุปว่าควรย้ายบริการทั้งหมดที่ยังเหลืออยู่บน AWS ออกไป และ ออกจาก AWS อย่างถาวร

จากผู้สนับสนุน AWS ยุคแรกสู่การตีตัวออกห่าง

  • เคยสนับสนุน AWS อย่างมากตั้งแต่ยุคที่ยังเป็นบริการขนาดเล็กกว่านี้ โดยมี SQS, S3, EC2 และ SimpleDB เป็นแกนหลัก และถึงขั้นจัดงานแรกใน Melbourne ที่ผู้ดูแล AWS จากสหรัฐฯ เดินทางมาพูดถึง AWS
  • คลาวด์คอมพิวติ้งเป็นการเปลี่ยนแปลงครั้งใหญ่ เพราะทำให้สตาร์ทอัพสามารถรันระบบคอมพิวเตอร์ของตัวเองได้ภายในไม่กี่นาที โดยไม่ต้องติดตั้งและดูแลระบบในดาต้าเซ็นเตอร์เอง
  • เชื่อมั่นใน AWS อย่างมากมาราว 15 ปี แต่เมื่อเวลาผ่านไปสิ่งที่ไม่สะดวกใจก็ค่อย ๆ สะสม จนถึงจุดหนึ่งก็ไม่ชอบ AWS อีกต่อไป

ความไม่พอใจต่อ AWS ที่สะสมเมื่อเวลาผ่านไป

  • ไลบรารีไคลเอนต์และการเปลี่ยนผ่านของ Python

    • ในช่วง 6 ปีแรก AWS ไม่ได้ทำ ไลบรารีไคลเอนต์ ของตัวเอง แต่ปล่อยให้ชุมชนเป็นคนพัฒนาไลบรารีสำหรับภาษาอย่าง Python เอง ซึ่งถูกมองว่าเป็นการผลักภาระไปให้โปรแกรมเมอร์ที่สละเวลามาช่วยฟรี
    • อีกเรื่องที่ยังคาใจก็คือ AWS ใช้เวลานานเกินไปในการย้ายจาก Python 2 ไปสู่ Python 3

  • DynamoDB และประสบการณ์ด้านค่าใช้จ่าย

    • วันแรกที่ใช้ DynamoDB ก็โดนเรียกเก็บเงิน 75 ดอลลาร์ และไม่ใช่แค่เรื่องราคาเท่านั้น แต่ตัวระบบเองก็ให้ความรู้สึกว่าออกแบบมาได้แย่ที่สุดเท่าที่จะนึกออก

  • ค่าโอนย้ายข้อมูลและโครงสร้างการคิดเงินที่ซับซ้อน

    • ค่า data transfer ออกของ AWS เคยอยู่ที่ 20 เซนต์ต่อ GB และแม้ภายหลังจะลดลงมาเหลือ 9 เซนต์ต่อ GB ก็ยังมองว่าแพงมากอยู่ดี
    • แม้แต่การย้ายข้อมูลระหว่างระบบภายใน AWS เองก็ยังมีค่าใช้จ่าย และในบางกรณีก็ให้ความรู้สึกเหมือนถูกคิดเงินซ้ำสองซ้ำสาม จนถ้าไม่เข้าใจรายละเอียดลึก ๆ ก็เลี่ยงกับดักค่าใช้จ่ายได้ยาก

  • IAM และความซับซ้อนโดยรวม

    • IAM (ระบบยืนยันตัวตนและควบคุมการเข้าถึง) เป็นระบบที่ซับซ้อนอย่างยิ่ง
    • ผู้สนับสนุน AWS มักบอกว่าการดูแล Linux, ฮาร์ดแวร์, เครือข่าย และความปลอดภัยด้วยตัวเองนั้นซับซ้อนเกินไป จึงควรใช้ AWS แต่ในมุมนี้ พื้นที่แทบทุกส่วนของ AWS เองก็เต็มไปด้วยความซับซ้อนมหาศาล จนสุดท้ายก็ยังต้องมีทีมผู้เชี่ยวชาญราคาแพงอยู่ดี

  • AWS Lambda และการล็อกอินกับผู้ให้บริการ

    • แม้จะเคยหลงใหลกับข้อดีเรื่อง “ขยายระบบได้” แต่ cold start ที่ช้าและความซับซ้อนในการพัฒนาที่สูงมากกลับเป็นปัญหา
    • เมื่อเทียบกับเว็บเซิร์ฟเวอร์ที่ดูแลเองก็แทบไม่มีข้อได้เปรียบจริง และข้อเสียมีมากกว่า อีกทั้งเมื่อจะย้ายออกจาก AWS Lambda ก็เป็นส่วนที่รื้อออกยากที่สุด จนเห็นชัดว่าปัญหา vendor lock-in รุนแรงมาก

  • โปรเจกต์โอเพนซอร์สและรายได้จากโฮสติ้ง

    • มองว่า AWS เดินหน้า OpenSearch, Valkey และ DocumentDB ทั้งที่โปรเจกต์อย่าง Elasticsearch, Redis และ MongoDB เคยแสดงชัดว่าไม่ต้องการให้มีการคัดลอกไปทำรายได้
    • หลังจากที่ชุมชนและบริษัทเหล่านั้นสร้างตลาดขึ้นมา AWS ก็เข้ามาเก็บรายได้จากบริการโฮสต์ และผลที่ตามมาคือมีไลเซนส์เชิงป้องกันอย่าง SSPL, Elastic License และ RSAL รวมถึงโมเดล source-available เพิ่มมากขึ้น

บริการบางส่วนที่ยังคงเหลือหลังออกจาก AWS

  • หลังหมดความผูกพันกับ AWS ก็ย้ายทุกอย่างออกไปนอก AWS และปิดบัญชีเกือบทั้งหมด
  • อย่างไรก็ตาม ยังมีบางบริการที่ตอนนั้นมองว่าเป็นทางออกที่เหมาะสมจริง ๆ เลยคงไว้
  • โดเมนอยู่บน Route53, แบ็กอัปบางส่วนอยู่บน S3, และอีเมลธุรกิจอยู่บน AWS WorkMail
    • สำหรับ AWS WorkMail นั้นได้รับแจ้งแล้วว่าจะ ยุติบริการภายใน 12 เดือน

เหตุผลที่กลับไปใช้ AWS ชั่วคราว

  • ช่วงหลังได้กลับไปล็อกอิน AWS อีกครั้งเพื่อทำการวิจัยและทดสอบ
  • ต้องการดูว่า Claude/Anthropic ทำงานบน AWS Bedrock ได้ดีแค่ไหน และในกรณีของ Claude Code ผลคือมันทำงานได้เหมือนกัน แต่ช้ากว่าและ แพงกว่าการสมัคร Anthropic โดยตรงมาก
  • เครื่องที่แรงที่สุดที่บ้านมี CPU 20 คอร์และ RAM 32GB จึงอยากเบนช์มาร์กว่าโค้ดจะรันได้เร็วแค่ไหนบนเครื่อง 192 คอร์ และ RAM 1TB
  • เมื่อประมาณหนึ่งเดือนก่อน การทดสอบ AWS Bedrock จบลงโดยไม่มีปัญหา และหลังทดสอบก็ปิดทุกอย่างเรียบร้อย
  • AWS Bedrock อาจมีประโยชน์ถ้าต้องการความเป็นส่วนตัว แต่เพราะค่าใช้จ่าย จึงคงไม่กลับไปใช้ Claude ผ่าน AWS Bedrock อีก

ข้อจำกัดของบัญชีที่เกิดขึ้นระหว่างทดสอบ EC2 Spot

  • ต่อมาระหว่างรัน EC2 Spot instance แบบ 192 คอร์เพื่อทดสอบอยู่ราว 3 ชั่วโมง ก็ได้รับอีเมลจาก AWS ว่า “Suspected security breach of your account”
  • มองว่าเป็นไปได้ที่การที่บัญชีซึ่งแทบไม่ได้ใช้งานมานาน อยู่ ๆ ก็เริ่มใช้ทรัพยากรคอมพิวต์ราคาแพง จะ ไปกระตุ้นระบบแจ้งเตือนความปลอดภัยภายในของ AWS
  • เข้าใจและประเมินในทางบวกต่อเจตนาของ AWS ที่ต้องการปกป้องผู้ใช้
  • แต่ AWS ได้ระงับหรือจำกัดบัญชี และผลคือ บัญชีอีเมลธุรกิจหลักที่ใช้อยู่บน AWS WorkMail ใช้งานไม่ได้
  • ไม่มีใครส่งอีเมลมาได้อีกต่อไป และก็ไม่สามารถสร้างทรัพยากร AWS ใด ๆ ได้ ทำให้การทดสอบที่ตั้งใจจะทำต่อก็ทำไม่ได้เช่นกัน

การตอบสนองจากซัพพอร์ตและความล่าช้า

  • ได้ตอบกลับการแจ้งเตือนจาก AWS Support เพื่อชี้แจงว่าบัญชีไม่ได้ถูกแฮ็ก และไม่มีความผิดปกติหรือปัญหาเรื่องการคิดเงิน แต่ก็ไม่ได้รับคำตอบ
  • เนื่องจากไม่ได้ใช้พรีเมียมซัพพอร์ต จึงต้องรอเวลาตอบกลับ 24 ชั่วโมงตามที่ AWS แจ้งไว้ และแม้ผ่านไป 3 วันก็ยังไม่มีการตอบกลับจากฝ่ายซัพพอร์ต
  • หลังไปขอความช่วยเหลือในฟอรัมของ AWS ก็ได้รับคำแนะนำให้ทำตามคำสั่งในอีเมล และให้ใช้แชตแทนเว็บ
  • ได้ทำทุกขั้นตอนที่ร้องขอแล้ว ทั้งเปลี่ยนรหัสผ่าน ลบ access token ตรวจสอบประวัติการเรียกเก็บเงิน และหลังรอเชื่อมต่อแชตราว 30 นาที ก็ได้คุยกับเจ้าหน้าที่ AWS เป็นเวลานาน
  • เจ้าหน้าที่ดูเหมือนจะพอใจและบอกว่าจะส่งเรื่องให้ทีมภายในที่เกี่ยวข้องดำเนินการ แต่เมื่อผ่านไป 24 ชั่วโมง ข้อจำกัดก็ยังไม่ถูกยกเลิก
  • เมื่อสอบถามติดตามอีกครั้งในอีก 8 ชั่วโมงต่อมา ก็ได้รับเพียงคำตอบว่า “กรุณารอต่อไป”

บทสรุปที่ถูกยืนยันอีกครั้ง

  • แม้เวลาจะผ่านไป 4 วันหลังบัญชีถูกจำกัด ก็ยังมีงานที่อยากทดสอบบนเครื่องใหญ่ค้างอยู่ และยังต้องกังวลว่าหากจะทำก็อาจต้องกลับไปยื่นขอ “quota” ใหม่อีก
  • ระบบอีเมลธุรกิจก็ยังคงใช้งานไม่ได้
  • ประสบการณ์การกลับมาใช้งานครั้งนี้ ย้ำชัดอีกครั้งว่าทำไมถึงเลิกใช้ AWS และทำให้ตัดสินใจว่าควรย้ายออกจาก AWS WorkMail รวมถึงย้ายโดเมนออกจาก Route53 และไม่กลับมาอีก
  • เป็นเรื่องดีมากที่ก่อนหน้านี้ได้ย้ายออกจาก AWS ไปเยอะแล้ว แต่ระบบอีเมลที่ยังไว้ใจให้คงอยู่กลับมาหยุดทำงานในระหว่างการกลับมาใช้ AWS และก่อให้เกิดความเสียหายจริง
  • วันหนึ่ง AWS อาจปลดข้อจำกัดของบัญชีให้ก็ได้ แต่ไม่มีทางรู้ว่าจะเป็นเมื่อไร

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

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

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

  • หลายปีก่อนผมเข้าร่วมบริษัทแห่งหนึ่ง รับหน้าทีมพัฒนา และถูกขอให้ออกผลิตภัณฑ์ภายใน 3 เดือน แต่พอจะเพิ่มเครื่องใหม่บน AWS ก็รู้สึกว่า โครงสร้างที่ไม่แสดงราคาใน UI เป็นสัญญาณของความสัมพันธ์ที่เป็นปฏิปักษ์และเอาเปรียบ
    ต้องเปิดตารางสเปกกับตารางราคาแยกกันแล้วเทียบเอง และจากประสบการณ์ที่ผ่านมา ผมมองว่าถ้าเห็นสัญญาณแบบนี้แล้วยังไม่ยอมออกไป ผลลัพธ์หลังจากนั้นก็เป็นความรับผิดชอบของผมเอง
    เลยสร้างบัญชี DigitalOcean แล้วย้ายทั้งหมดไปที่นั่น พร้อมตั้งค่าให้ CI/CD deploy ไปทางนั้นด้วย และใช้เวลาสองเดือนที่เหลือโฟกัสกับตัวผลิตภัณฑ์จนเปิดตัวได้เร็วกว่าที่สัญญาไว้ 1 เดือน
    ผมเคยเห็นวิดีโอขุดหลุมริมแม่น้ำแล้วต่อท่อจากแม่น้ำเข้าหลุม เพื่อให้ปลาว่ายเข้ากับดักเอง ภาพนั้นทำให้ผมจำได้ฝังใจว่า การเลือกทางที่ต้านทานน้อยที่สุดและไม่ยอมย้อนแก้ความผิดพลาด คือเคล็ดลับที่จะจบแบบปลาเหล่านั้น

    • อย่างหนึ่งที่ผมชอบใน Azure คือ เวลาสร้างรายการแต่ละอย่าง มันไม่ได้ยัดเยียดราคาเกินไป แต่กับรายการที่อาจแพงก็มักจะ แสดงราคาอย่างสมดุล
      จนถึงตอนนี้ยังไม่เคยโดนค่าใช้จ่ายทำให้ตกใจ
    • วัฒนธรรมวิศวกรรมของ Amazon ดูจะเป็น วัฒนธรรมผลิตภัณฑ์ที่ขับเคลื่อนโดยวิศวกร ค่อนข้างมาก เลยอาจทำให้นักพัฒนาต้องรับผิดชอบถึงขั้น UX และ flow ด้วย
      ผมเคยจ้างนักพัฒนารุ่นจูเนียร์ที่เพิ่งจบฝึกงาน AWS มา เขาโชว์แดชบอร์ดที่ทำคนเดียวตลอดฤดูร้อนโดยไม่มีผู้จัดการผลิตภัณฑ์หรือดีไซเนอร์ช่วยเลย และมันดูแย่มากจริงๆ
      นักพัฒนาบางคนมีเซนส์ด้านผลิตภัณฑ์/UX ที่ดี แต่คนส่วนใหญ่ค่อนข้างอ่อนเรื่อง UX มาก ดังนั้นมันอาจไม่ใช่ความตั้งใจร้าย แต่เป็นไปได้มากกว่าว่าเป็นวัฒนธรรม UX ที่แย่
    • วิธีที่ถูกต้องคือเลือก ผู้ให้บริการโครงสร้างพื้นฐานที่ช่วยให้คุณออกของได้
      AWS นั้นดี แต่ไม่เหมาะกับทุกคน และมีตำแหน่งบางจุดระหว่างบริการอย่าง Heroku กับ bare metal ที่ช่วย abstract งานดูแลออกไปมาก แต่ยังให้คุณควบคุมสถาปัตยกรรมการขยายระบบได้บางส่วน
      กล่าวคือ ในฐานะผู้ให้บริการคลาวด์ AWS ช่วยเรื่องการขยายระบบได้ แต่ไม่ใช่เครื่องมือสำหรับสร้างระบบที่ถูกและเรียบง่ายที่สุด
      ถ้ามีเงิน VC และชูเรื่องการเติบโต AWS อาจเป็นทางเลือกที่ปลอดภัย และด้วย startup credit 2 ปีจาก accelerator คุณก็โฟกัสกับการสร้างมากกว่างบ infra ได้ในช่วง 18 เดือนแรก
      ถ้าเป็นสาย bootstrap หรือ indie developer ก็เลือกสิ่งที่เรียบง่ายและรับไหวพอ และ Hetzner หรือ DigitalOcean ก็ใช้งานได้ดีมากแล้ว
    • AWS มี เครื่องคำนวณราคา ที่ค่อนข้างดีและมี preset ที่พอใช้ได้ แต่แน่นอนว่ามันเป็นแอปแยกต่างหากโดยสิ้นเชิง
      Amazon คงอยากให้มีแรงเสียดทานเล็กน้อยเวลาจะดูข้อมูลราคาได้ง่ายๆ แต่เหตุผลหลักดูจะเป็นกฎของ Conway มากกว่า
      AWS ยังปล่อยผังองค์กรของตัวเองออกมาในรูปของผลิตภัณฑ์อยู่
    • ผมเห็นด้วยระดับหนึ่ง แต่ราคาของ AWS ไม่ได้ง่ายพอที่จะคำนวณว่าจะจ่ายเท่าไรจากตัวเลขคงที่ตัวเดียวที่แสดงใน UI
      ถ้าการต้องเปิดสองแท็บเพื่อเทียบค่าใช้จ่ายเป็นเรื่องน่ารำคาญ คุณอาจควรหลีกเลี่ยงไม่ใช่แค่ AWS แต่รวมถึงผู้ให้บริการคลาวด์ทั้งหมด
      พอมี NAT Gateway, CloudFront, S3, auto scaling, load balancer เข้ามา การคำนวณต้นทุนก็ใกล้เคียงกับศิลปะมากกว่าวิทยาศาสตร์ที่แม่นยำ
      ถ้าไม่ได้ใช้พวกนี้ ก็แทบไม่มีเหตุผลอะไรให้ใช้ AWS และมีผู้ให้บริการ VPS ราคาถูกอีกมาก

  • ถ้ามองเฉพาะ OpenSearch กับ Valkey คำอธิบายว่า “AWS สร้าง fork เลยทำให้เกิดการเปลี่ยนไลเซนส์” นั้นกลับด้านทั้งหมด
    AWS สร้าง fork หลังจาก upstream project เปลี่ยนไลเซนส์แล้วเท่านั้น และโดยเฉพาะ Valkey นั้นถูกสร้างโดยอดีตสมาชิกทีมพัฒนาหลักของ Redis

    • หลายโปรเจกต์ลักษณะนี้ใช้โมเดลธุรกิจที่เปิดซอร์สผลิตภัณฑ์หลัก แล้วหารายได้จากบริการระดับสูง การติดตั้ง การดูแลรักษา และ fully managed service
      AWS ไปทำ fully managed service เพื่ออ้อมพวกเขา ดังนั้นในกรณีนี้ผมอยู่ข้างคนที่สร้างโปรเจกต์
      โดยพื้นฐานแล้ว AWS แย่งชามข้าวของพวกเขาไป และพวกเขาเลยไม่มีทางเลือกนอกจากต้องเปลี่ยนไลเซนส์
    • การเปลี่ยนไลเซนส์นั้นเองก็เป็นการตอบโต้ต่อวิธีที่ AWS สร้างรายได้จากงานของ upstream project ในแบบที่ไม่ยั่งยืนสำหรับพวกเขา
    • ผมสงสัยว่าถ้า Amazon จ่ายให้ผู้สร้างและผู้ดูแลรักษา ซอฟต์แวร์โอเพนซอร์ส ที่ตัวเองขายอยู่เพียง 1 เซนต์ต่อรอบการเรียกเก็บเงิน จะกระทบแค่ไหน
      และก็สงสัยด้วยว่ามันจะกลายเป็นเงินที่พอมีความหมายกับทีมโอเพนซอร์สหรือไม่ และอาจทำให้พวกเขากล้าร่วมพัฒนาผลิตภัณฑ์โดยไม่ต้องเสี่ยงมากขึ้น
    • ตั้งแต่ครั้งแรกที่ผมส่งแพตช์ให้ Redis แล้วมี committer คนหนึ่งไม่ตอบข้อความผม แต่เอาแพตช์นั้นเข้าไปในชื่อของตัวเอง ความเห็นใจที่ผมมีต่อปรัชญาของโปรเจกต์โอเพนซอร์สหลายแห่งก็หายไปมาก
      พวกเขาสมควรได้เจอ Valkey
      ผมยังจำ JBoss กับ Marc Fleury ได้อยู่
    • เป็นเรื่องปกติอยู่แล้วที่ AWS จะสร้าง fork ก็ต่อเมื่อมีการเปลี่ยนไลเซนส์เพื่อไม่ให้ AWS หาเงินจากโค้ดของโปรเจกต์นั้นได้
      นั่นแหละคือประเด็นสำคัญ

  • ผมสลับไปมาระหว่างบริการคลาวด์กับ self-hosting หลายครั้ง
    ตอนแรกใช้ Vercel และเพราะโปรเจกต์เป็น Next.js ประสบการณ์ก็โอเค แต่ต้องจ่าย 20 ดอลลาร์ต่อเดือนสำหรับโปรเจกต์ที่มีผู้ใช้ไม่ถึง 100 คน เลยรู้สึกว่าแพงเกินไปสำหรับบริการที่ไม่ได้ต้องการประสิทธิภาพสูง
    หลังจากนั้นผมตั้งเซิร์ฟเวอร์เองด้วย Hetzner และ Coolify ซึ่งเพราะ Coolify เป็นโอเพนซอร์ส ผมจ่ายแค่ค่า VPS และเดือนละ 5 ดอลลาร์ก็รัน PostgreSQL instance กับเว็บเซิร์ฟเวอร์ได้แล้ว
    แต่ก็ยังต้องลงมือดูแล PostgreSQL กับ Redis มากอยู่ดี และถึงจะอยู่ใน Docker container การส่ง system variable กับ environment variable ระหว่างบริการก็ยังยุ่งยาก
    เลยย้ายอีกครั้งไปที่ Cloudflare Workers, D1 Database, Cloudflare KV ซึ่งเรียกใช้ได้ตรงจากใน Worker เลย ไม่ต้องส่ง environment variable กันอีก
    ประสบการณ์ฝั่ง local development ก็ดี และราคาก็สมเหตุสมผล ตั้งแต่นั้นมาผมก็ใช้ผลิตภัณฑ์ชุด Cloudflare ต่อมาเรื่อยๆ

    • สิ่งที่ Cloudflare มีให้ตอนนี้ใกล้กับสิ่งที่ผมอยากได้จาก AWS มากกว่า
      แอป full-stack และการ deploy ไฟล์ แบบพื้นฐานนั้นง่ายกว่ามาก และ AWS ตอนนี้ยากกว่าการ self-hosting เสียอีก
    • ผมสงสัยว่า Docker ช่วยให้การดูแล PostgreSQL ง่ายขึ้นหรือเปล่า
      ปัญหาเดียวที่ผมเจอกับ PostgreSQL คือมีงาน migration เล็กน้อยตอนย้ายไป major version ใหม่
      และก็สงสัยเหมือนกันว่าการส่ง system variable กับ environment variable ระหว่างบริการนั้น Docker ทำให้ยากขึ้นหรือไม่
    • ผมอยากจะชอบ Cloudflare Workers และคงมีเหตุผลเชิงเทคนิคดีๆ อยู่ แต่แนวทางที่ต้องใช้ Wrangler project กับงานอย่างการเปิดใช้ email activation ทำให้รู้สึกเหมือนอยู่ก่อนถูก lock-in กับแพลตฟอร์มนิดเดียว
      ถ้าจะอนุญาต email ก็ต้องตั้ง binding ที่จำเป็น แต่ในคอนโซลกลับตั้งค่าไม่ได้ และหลังจาก Wrangler ตั้งค่าให้แล้วก็ดูเหมือนจะมองไม่เห็นมันจากคอนโซลด้วย

  • แปลกใจที่ผู้เขียน เกลียด DynamoDB
    มันเป็นหนึ่งในบริการ AWS ที่ผมชอบที่สุด ใช้งานได้พร้อมสูง ภาระการดูแลต่ำ และทุกครั้งที่ใช้ค่าใช้จ่ายก็ค่อนข้างต่ำ
    เพียงแต่คุณต้องใช้เวลาวาง data model ล่วงหน้า และนั่นก็ต้องอาศัยการอ่านและทำความเข้าใจเอกสารของบริการ

    • DynamoDB นั้นดีมากถ้าใช้ในแบบที่มันถูกออกแบบมา
      โดยพื้นฐานแล้วควรมองมันเป็น key-value store ที่ค่อนข้างเรียบง่าย มีความคงทนที่ดีและขยายขนาดตารางได้แทบไม่จำกัด ไม่ใช่อะไรที่ควรพยายามใช้เหมือนฐานข้อมูล SQL
      วิธีที่ง่ายที่สุดในการสร้างบิล 75 ดอลลาร์จากโค้ดต้นแบบ คือ vibe coding ใส่มันเหมือนเป็นฐานข้อมูล SQL ที่มี JOIN และ GROUP BY
      จุดที่มันเปล่งประกายจริงๆ คือเวลาคุณต้องการตารางเล็กๆ สำหรับเก็บข้อมูลถาวร 1-2 ตาราง แต่ไม่อยากดูแล RDBMS ทั้งชุด หรือเวลาคุณมีตารางใหญ่มากเพียงตารางเดียวที่ต้อง query แบบเรียบง่าย โดยไม่อยากฝืนให้เข้ากับ RDBMS
    • หลายบริการอย่าง DynamoDB และ Lambda มี use case ที่เฉพาะมาก
      อย่าเอา key-value store แสนสนุกไปใช้เป็นฐานข้อมูล
    • หลายปีก่อนตอนทำแอป ผมต้องการ DB สำหรับเก็บเรคคอร์ดประมาณ 50 ล้านรายการ มีการอ่าน+เขียนราว 10,000 ครั้งต่อเดือน และมี index 1 ตัว
      ค่าโหลดข้อมูลครั้งแรกอยู่ที่ประมาณ 50 ดอลลาร์ หลังจากนั้นค่าดูแลอยู่ระดับ 10 เซนต์ต่อเดือนเท่านั้น

  • อ่านบทความแบบนี้ทีไรก็อดขำไม่ได้ทุกที
    มันทั้งถูกและผิดในเวลาเดียวกัน และระบบควรถูกสร้างให้ “เรียบง่ายที่สุดเท่าที่เป็นไปได้ แต่ไม่ง่ายไปกว่านั้น”
    ถ้าคุณคิดว่าจะมองข้ามรายละเอียดได้ สุดท้ายจะเจอความยุ่งยากที่ใหญ่กว่าในภายหลัง
    IAM มันซับซ้อนอยู่แล้ว
    ผมนึกตัวอย่างของการทำ user, group, role, policy, identity provider, OIDC ให้เรียบง่ายจริงๆ ไม่ออกเลย
    ผมเคยเห็นคนที่คัดค้านการนำ Kubernetes มาใช้เพราะว่า “ซับซ้อนเกินไป” สุดท้ายกลับไปประดิษฐ์ Kubernetes ใหม่แบบหยาบๆ และชั่วคราวด้วย Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash และน้ำลายกับหญ้าแห้ง พร้อมทำพลาดไปมากมาย
    บางฟีเจอร์คุณอาจคิดว่าไม่จำเป็น แต่สุดท้ายก็ต้องใช้
    จากมุมมองของคนที่เคยทำหน้าที่ infra คนเดียวในสตาร์ตอัป AWS ยังอยู่ในขอบเขตที่คนส่วนใหญ่เรียนรู้ได้ และส่วนที่ห่วยจริงๆ ก็มักหลบเลี่ยงได้
    ถ้าไม่ชอบ Lambda ก็ไม่ต้องใช้ แค่ใช้ EKS, ECS, EC2 ก็พอ

    • ถ้ามองจากข้างใน IAM มีตัวเลือกเป็นพันๆ อย่าง แต่แก่นจริงๆ คือ “role นี้เข้าถึงอะไรและทำอะไรได้บ้าง (action + resource)” กับ “ใครเข้าถึง role นี้ได้บ้าง”
      ถ้ามองจากระดับสูง นั่นคือทั้งหมด
      เหตุผลที่ IAM ดีคือมันใช้ได้เหมือนกันทั้งภายนอกและภายใน
      ทีมภายใน AWS ไม่ได้มีสิทธิ์เข้าถึงมากกว่าเป็นพิเศษ และถ้าเกิดมีสิทธิ์ทำอะไรในบัญชีของลูกค้าเพื่อให้บริการบางอย่างได้ ก็เป็นเพราะลูกค้าใส่ service principal ไว้ใน trust relationship ของ IAM เพื่ออนุญาตการเข้าถึง และลูกค้าก็ตรวจสอบเรื่องนี้ได้
      ตัวอย่างเช่น Lambda มี Lambda role เพราะเราไม่อยากให้บริการ Lambda อ่าน S3 bucket ได้เพียงเพราะ “เราเป็น AWS เลยเข้าถึงได้อัตโนมัติ”
      ต่อให้เป็นการเข้าถึงภายใน AWS ลูกค้าก็มองเห็นและควบคุมได้อย่างชัดเจน
    • รูปแบบ “X ซับซ้อนเกินไป” แล้วสุดท้ายก็ไปสร้าง X ใหม่แบบหยาบๆ เอง เป็นเรื่องที่พบได้บ่อยอย่างน่าทึ่งในโลกเทคโนโลยีและซอฟต์แวร์
      บางอย่างตอนนี้ชัดเจนแล้วว่าเป็น มาตรฐาน แต่หลายคนก็ยังไม่ยอมใช้เวลาเรียนรู้มันให้ถูกต้อง
    • AWS อาจแพงกว่า self-hosting แต่เงินที่ประหยัดได้นั้นเล็กน้อยเมื่อเทียบกับต้นทุนด้านวิศวกรรม
      ถ้าวิศวกร infra ที่ดีใช้เวลา 2 เดือนกับระบบ OVH เพื่อ “ประหยัดเงิน” มันจะแพงกว่าการประหยัดที่คุณได้จากการไม่ใช้ Fargate หรือ RDS เสียอีก

  • ผมสงสัยว่าเมื่อไรเราจะเริ่มได้ยินเรื่องแบบเดียวกันกับ Anthropic หรือ OpenAI บ้าง
    กระแส AI ตอนนี้มีกลิ่นคล้าย AWS ยุคแรกๆ และดูเหมือนทุกคนกำลังขึ้นขี่มัน ก่อนจะมารู้ทีหลังว่าตัวเองสร้าง การพึ่งพาขนาดใหญ่ ที่ดึงออกได้ยาก

  • Lambda เจ๋งมากจริงๆ และผมคิดว่ามันเป็นวิธีที่ดีที่สุดในการรันบริการ deploy ด้วยรอบการทำซ้ำที่เร็วโดยไม่ปวดหัว
    ไม่จำเป็นต้องไปทาง microservices หรือแยกโค้ดออกเป็น repository เล็กๆ นับพันล้านอัน
    ตราบใดที่คุณไม่คาดหวังว่าจะแชร์ state ภายในเซิร์ฟเวอร์ข้ามระหว่าง request ได้ คุณก็ย้ายเว็บเซิร์ฟเวอร์มาตรฐานไปไว้บน Lambda ได้

  • ผมไม่ได้ทำงานในสายนี้ เลยแตะ AWS แค่ในโปรเจกต์สนุกๆ ส่วนตัวเป็นครั้งคราว และทุกครั้งมันเหมือนฝันร้าย
    ผมแค่อยากทำเซิร์ฟเวอร์เกมการ์ดทดลอง ไม่ได้จะตั้งสถาบันการเงินใหม่ แต่ทุกอย่างดูเหมือนถูกออกแบบโดยตั้งสมมติฐานว่าพรุ่งนี้ต้องขยายได้ไม่จำกัด และมีองค์กรพันคนกับงบ VC รองรับ
    โชคดีที่มีบริการอย่าง Netlify มาครอบด้านนอกไว้ เลยไม่ต้องต้มทะเลทั้งมหาสมุทร
    สักวันหนึ่งผมอาจต้องเรียนรู้ IAM, VPN และสิ่งที่ไม่รู้จักอื่นๆ จริงจัง แต่จนกว่าจะถึงตอนนั้น ทุกครั้งที่แตะ AWS ผมรู้สึกเหมือนตาจะถลน

    • ก็แค่เปิด raw VPS บน EC2 หรือ Lightsail แล้วผูก public IP ก็จบ
      คุณไม่จำเป็นต้องทำตาม enterprise pattern ทุกอย่าง
    • น่าทึ่งที่ Heroku จับสิ่งที่เว็บแอปส่วนใหญ่ต้องการได้ตรงเป๊ะตั้งแต่เกือบ 20 ปีก่อน
    • ถ้ายังไม่เคยแตะ Azure คุณอาจรู้สึกว่า AWS คนเดียวที่เหมือนฝันร้าย
    • ผมย้ายไป Cloudflare แล้ว รู้สึกหายใจโล่งขึ้นมาก
      มีทุกอย่างที่ต้องใช้ และราคาก็สมเหตุสมผล
    • AWS ไม่ได้เล็งไปที่โปรเจกต์ส่วนตัว แต่เล็งที่ enterprise
      โปรเจกต์ส่วนตัวสุดท้ายแล้วมีแต่เรื่องต้นทุน จึงสร้างรายได้ที่มีนัยสำคัญให้ AWS ไม่ได้

  • ตั้งแต่ปี 2023 เป็นต้นมา AWS มีการดึงคนสายเทคนิคออกจากระบบอย่างเป็นระบบ
    ผ่านทั้งการปลดคนครั้งใหญ่และแผนปรับปรุงผลงานสองรอบ และเพื่อนร่วมงานที่เก่งๆ ฝั่ง presales หรือ support หลายคนก็ไม่ได้อยู่กับ AWS แล้ว
    ในทางกลับกัน ผมเห็นบ่อยว่าคนที่มีประวัติผลงานคลุมเครือที่สุดกลับอยู่ต่อและได้เลื่อนตำแหน่ง
    ใครจะใช้ AWS ก็ต้องยอมรับความเสี่ยงกันเอง และ Paul Vixie จะไม่โผล่มาช่วยกู้สถานการณ์

  • ElastiCache เป็นสิ่งที่กวนใจผมมานานแล้ว
    RDS ยังพอมีคุณค่าเพิ่ม เช่น scalability, การตั้งค่าที่ปรับให้เหมาะมาในระดับหนึ่ง, backup ที่ไม่ต้องคอยกังวล เลยพอทำใจจ่ายได้
    แต่ ElastiCache แทบไม่มีมูลค่าเพิ่มอะไรเลย ขณะที่ราคากลับให้ความรู้สึกเหมือนถูกรีดไถ
    เมื่อเทียบกับการติดตั้ง Redis แบบพื้นฐาน มันทั้งช้ากว่า ปรับแต่งแย่กว่า เสถียรน้อยกว่า และ Redis ที่ไม่ตั้งค่าอะไรเลยรองรับหลาย DB แต่ ElastiCache รองรับแค่หนึ่งเดียว
    มันมีการปรับปรุงด้าน scalability อยู่บ้าง แต่ Redis พื้นฐานบน instance ใกล้เคียงกันทิ้งห่าง ElastiCache มากจนแทบไม่มีกรณีไหนที่การปรับปรุงนั้นจำเป็นจริงๆ

    • ElastiCache เป็นหนึ่งในบริการที่ควรพิจารณา self-hosting อย่างแน่นอน
      AWS ไม่ได้เพิ่มอะไรให้มากนักทั้งในแง่ API หรือความสมบูรณ์ของบริการ ในทางกลับกัน Redis/Valkey ก็เป็นหนึ่งในบริการที่โฮสต์เองได้ง่ายที่สุดอยู่แล้ว