AWS ในปี 2025: สิ่งที่คุณคิดว่ารู้อยู่แล้ว แต่ตอนนี้กลับไม่ถูกต้อง

 (lastweekinaws.com)
8 คะแนน โดย GN⁺ 2025-08-21 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • บริการหลักของ AWS กำลังพัฒนาอย่างรวดเร็ว
  • ความสามารถสำคัญอย่าง EC2, S3, Lambda มอบประสิทธิภาพและความยืดหยุ่นที่เหนือความคาดหวังของผู้ใช้ เมื่อเทียบกับในอดีต
  • มีการเปลี่ยนแปลงและการปรับแต่งมากมายในด้าน เครือข่าย การยืนยันตัวตน และแนวทางลดต้นทุน
  • อาจเกิดความสับสนได้จาก โพสต์บล็อกเก่า หรือข้อมูลที่ล้าสมัย
  • การเข้าใจอัปเดตล่าสุดและนโยบายที่เปลี่ยนไปเป็นสิ่งจำเป็นต่อการใช้งาน AWS

AWS 2025: ปัจจุบันที่เปลี่ยนไปจากความเข้าใจในอดีต

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

EC2

  • ตอนนี้สามารถเปลี่ยน Security Group และ IAM Role ของ EC2 Instance ได้โดยไม่ต้องหยุดเครื่อง
  • สามารถ ปรับขนาด เชื่อมต่อ/ถอด EBS Volume บนอินสแตนซ์ที่กำลังทำงานอยู่ได้
  • ช่วงหลังสามารถ บังคับหยุดหรือยุติการทำงาน ของ EC2 Instance ได้แล้ว จึงไม่จำเป็นต้องรอ timeout นาน ๆ
  • มีการเพิ่มความสามารถ Live Migration ระหว่าง physical host ทำให้คำเตือนเรื่องประสิทธิภาพของอินสแตนซ์ลดลงอย่างมาก
  • ความน่าเชื่อถือของอินสแตนซ์ดีขึ้นมาก จนแทบไม่เกิดเหตุที่อินสแตนซ์หายไปโดยไม่มีสัญญาณล่วงหน้าเหมือนในอดีต
  • ความผันผวนของราคา Spot Instance เปลี่ยนเป็นแบบ ค่อยเป็นค่อยไป มากขึ้น จึงไม่ต้องคอยเฝ้าราคาแบบเรียลไทม์เหมือนสนามเก็งกำไร
  • เคสที่จำเป็นต้องใช้ Dedicated Instance กลายเป็นเรื่องที่พบได้น้อยมาก (แม้แต่ HIPAA BAA ก็แทบไม่จำเป็นมาตั้งแต่เกือบ 10 ปีก่อน)
  • AMI Block Public Access เปิดใช้งานเป็นค่าเริ่มต้นในบัญชีใหม่ (และตั้งแต่ปี 2023 ยังใช้กับบัญชีที่ไม่มี public AMI มานานเกิน 90 วันด้วย)

S3

  • S3 ไม่ได้เป็นแบบ Eventually Consistent อีกต่อไป แต่ให้ Read-After-Write Consistency
  • ไม่จำเป็นต้องสุ่มส่วนต้นของ object key อีกแล้ว ทำให้กังวลเรื่องการกระจายข้อมูลและ hotspot น้อยลง
  • ACLs (Access Control List) ไม่ใช่แนวทางที่แนะนำอีกต่อไป และใน bucket ใหม่จะถูกปิดไว้เป็นค่าเริ่มต้น
  • Bucket ใหม่จะตั้งค่า Block Public Access เป็นค่าเริ่มต้น
  • มีการใช้ การเข้ารหัสข้อมูลที่จัดเก็บ โดยอัตโนมัติ
  • ก่อนที่ Glacier จะกลายเป็น storage class ของ S3 มันเคยเป็นบริการแยกต่างหาก แต่ปัจจุบันรวมเข้าด้วยกันแล้ว โดยเหลือเพียงร่องรอยในรายการค่าใช้จ่ายบางส่วน
  • ค่าใช้จ่ายและความเร็วในการกู้คืน Glacier กลายเป็นสิ่งที่คาดการณ์ได้มากขึ้นและถูกลงมากเมื่อเทียบกับในอดีต เรื่องค่า restore ที่น่ากลัวแบบเดิมไม่เป็นจริงแล้ว

เครือข่าย (Networking)

  • EC2-Classic หายไปอย่างสมบูรณ์แล้ว
  • ที่อยู่ IPv4 สาธารณะ ไม่ฟรีอีกต่อไป และมีค่าใช้จ่ายเท่ากับ Elastic IP
  • มีตัวเลือกที่ดีกว่า VPC Peering เกิดขึ้นแล้ว เช่น Transit Gateway, การแชร์ VPC/ทรัพยากร, และ Cloud WAN
  • สามารถแก้ปัญหาเครือข่ายที่ซับซ้อนได้ง่ายขึ้นด้วย VPC Lattice และ Tailscale
  • เวลาเผยแพร่อัปเดตของ CloudFront ลดลงจาก 45 นาทีเหลือราว 5 นาที (แม้ตอนรอ deployment ของ CloudFormation ก็อาจยังรู้สึกว่านาน)
  • ELB Classic เคยคิดค่ารับส่งข้อมูลข้าม AZ แต่ ALB คิดเฉพาะค่า LCU เท่านั้น ส่วน NLB ยังมีค่าบริการข้าม AZ อยู่ ต้องระวัง
  • มีการเพิ่มการรองรับ Security Group ให้กับ Network Load Balancer
  • เดิมที ID ของ Availability Zone แตกต่างกันในแต่ละบัญชี แต่ตอนนี้สามารถจัดแนว Zone ID ได้ผ่าน Resource Access Manager

Lambda

  • Lambda เพิ่มเวลาทำงานจากข้อจำกัด 5 นาที เป็น 15 นาที และรองรับ container image (Docker), EFS shared storage, RAM สูงสุด 10GB, และ /tmp 10GB
  • ความเร็วในการเรียก Lambda ภายใน VPC ดีขึ้นอย่างมาก
  • ปัญหา cold start เบาลงมากเมื่อเทียบกับในอดีต

EFS

  • ตอนนี้สามารถปรับ ประสิทธิภาพ IO ของ EFS แยกจากความจุได้แล้ว จึงไม่ต้องเติมข้อมูลไร้ประโยชน์เพื่อกินพื้นที่ให้มากขึ้น

EBS

  • EBS Volume ใหม่สามารถใช้งาน ประสิทธิภาพสูงสุดได้ทันที หากไม่มีข้อมูลตั้งต้น
  • Volume ที่สร้างจาก snapshot อาจช้าเมื่ออ่านข้อมูลครั้งแรก จึงแนะนำให้อ่านทั้งดิสก์หนึ่งรอบก่อน (และก็มีตัวเลือกที่เร็วกว่าให้ใช้ด้วย)
  • io1 Volume สามารถเชื่อมต่อพร้อมกันกับหลาย EC2 Instance ได้ แต่ในทางปฏิบัติแนะนำเฉพาะกรณีที่เฉพาะทางมากเท่านั้น

DynamoDB

  • ตอนนี้อนุญาตให้มี ฟิลด์ว่าง ภายใน item ได้
  • ประสิทธิภาพมีความสม่ำเสมอมากขึ้น จนไม่ค่อยจำเป็นต้องใช้เครื่องมือแยกเพื่อติดตามปัญหา hot key เหมือนเมื่อก่อน
  • ด้วยการเปลี่ยนแปลงด้าน Pricing ผู้ใช้ส่วนใหญ่จะพบว่าแบบ On Demand สมเหตุสมผลกว่า

ตัวเลือกลดต้นทุน (Cost Savings Vehicles)

  • Reserved Instances กำลังค่อย ๆ ถูกเลิกใช้ และ Savings Plans กำลังกลายเป็นมาตรฐานในอนาคต แม้อัตราส่วนลดของ Savings Plan จะลดลงเมื่อเทียบกับ RI แต่ก็มีความยืดหยุ่นสูงกว่า
  • ค่าใช้งาน EC2 คิดเงินเป็นวินาที จึงคุ้มค่าต้นทุนแม้จะเปิดอินสแตนซ์ในช่วงเวลาสั้นมาก
  • Cost Anomaly Detector ตรวจจับรูปแบบการใช้งานที่ผิดปกติได้อย่างแม่นยำมากและใช้งานฟรี
  • Compute Optimizer ให้คำแนะนำกับทรัพยากรหลากหลายรวมถึง EBS และมีความน่าเชื่อถือสูง ขณะที่คำแนะนำจาก Trusted Advisor ยังขาดความสม่ำเสมอ

การยืนยันตัวตน (Authentication)

  • แนะนำให้ใช้การกำหนดสิทธิ์ผ่าน IAM Role ส่วน IAM User เหมาะกับแอป legacy เท่านั้น
  • IAM Identity Center เข้ามาแทน AWS SSO และใช้สำหรับการเข้าถึงบัญชี ซึ่งทำให้เกิดความสับสนอยู่บ้าง
  • สามารถลงทะเบียน อุปกรณ์ MFA ได้หลายตัว ให้กับ root account
  • ไม่จำเป็นต้องตั้งค่า root credential แยกต่างหากให้กับบัญชีสมาชิกในองค์กร

อื่น ๆ (Miscellaneous)

  • ความน่าเชื่อถือและความทนทานของ us-east-1 ดีขึ้นมากจากเดิม เหตุขัดข้องที่เคยเกิดบ่อยในอดีตตอนนี้กลายเป็นเรื่องระดับข่าวแล้ว
  • การ ยุติบริการ (Deprecation) ของ AWS ยังพบไม่บ่อย แต่มีแนวโน้มเพิ่มขึ้น จึงควรพิจารณาความเสี่ยงหากพึ่งพาบริการรองมากเกินไป
  • ปัญหาที่ ข้อมูล CloudWatch จุดสุดท้ายแสดงค่าต่ำผิดปกติจากความไม่สอดคล้องกันนั้นไม่เกิดขึ้นอีกแล้ว
  • สามารถ ปิดบัญชี AWS ของบัญชีสมาชิกในองค์กรได้โดยตรงจาก root account

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

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

 
roxie 2025-08-23

ว้าว เปลี่ยนไปมากจริงๆ นะ
 
howudoin 2025-08-23

ตอนนี้ AWS ไม่ใช่สิ่งที่เลือกใช้แค่บริการเดียวได้อีกแล้ว
จะทำอะไรสักอย่างก็ต้องผูกใช้หลายอย่างเข้าด้วยกันทั้งหมด
มันไม่เรียบง่ายเลย
ถ้าสตาร์ตอัปจะใช้ ก็ต้องจ่ายไม่ใช่แค่ค่า cloud แต่รวมถึงต้นทุนบุคลากร devops ด้วย
ถ้าจะวางระบบให้ดี เวลาพัฒนาก็แทบจะถูกกินหมดจนปริมาณงานพุ่งเกินความจำเป็น
ยิ่งไปกว่านั้น ในหลายกรณีก็ต้องใช้ managed service ถึงจะดีกว่า ทำให้ในระดับโค้ดเองก็ผูกติดกับแพลตฟอร์มไปแล้ว
 
GN⁺ 2025-08-21
ความคิดเห็นใน Hacker News
  • พอเห็นว่า "Block Public Access" ของ S3 ตอนนี้ถูกเปิดใช้เป็นค่าเริ่มต้นกับบักเก็ตใหม่ ก็คิดว่านี่เป็นการตัดสินใจที่ถูกต้องอยู่แล้ว เพราะที่ผ่านมาเกิดข้อมูลรั่วไหลครั้งใหญ่จากการตั้งค่า S3 bucket ผิดพลาดกันเยอะมาก แต่บางครั้งฉันก็อยากสร้าง S3 bucket ที่เปิดสิทธิ์อ่านแบบสาธารณะเพื่อเสิร์ฟไฟล์ให้คนทั่วไป และทุกครั้งก็มักมีอะไรเปลี่ยนไปจนสูตรเดิมใช้ไม่ได้ ต้องกลับไปศึกษาใหม่ตั้งแต่ต้นซ้ำๆ
    • อยากบอกว่าให้ดูการตั้งค่า "Block Public Access" ให้ละเอียด เพราะมันเป็นเหมือนตัวกันพลาดที่ช่วยไม่ให้คนทำเรื่องผิดพลาดใหญ่ๆ ต่อให้ตั้ง bucket policy หรือ ACL ที่หละหลวมมากๆ (แม้จะเป็นของเก่าแต่ก็ยังใช้อยู่) ถ้าเปิด Block Public Access ไว้ก็จะเข้าถึงแบบสาธารณะไม่ได้ ในทางกลับกัน ถ้าปิด Block Public Access และใช้ bucket policy ที่ออกแบบมาดีมากก็ไม่มีปัญหา โดย bucket policy จะเป็นตัวกำหนดทั้งหมดว่าใครเข้าถึงได้บ้าง แน่นอนว่าในระยะยาว policy อาจถูกเปลี่ยนโดยไม่ตั้งใจ หรือมีการเพิ่ม IAM role แบบไม่คาดคิด หรือ trust policy ถูกแก้ไขได้ ดังนั้นการจัดการเรื่องพวกนี้จึงสำคัญ
    • ฉันใช้ LLM บ่อยในสถานการณ์แบบนี้ ให้มันอ่านเอกสารแล้วดึง demo code ที่กระจายอยู่ตามเอกสารทางการของ AWS ออกมาให้ จากนั้นก็ถามต่อได้เลยว่าจะปรับแต่งแบบที่ต้องการยังไง
    • มันให้ความรู้สึกเดจาวูว่าเรื่องนี้เราเคยทำไปแล้วหรือเปล่า เหมือนเมื่อ 10 ปีก่อนทุกคนก็เปิดบักเก็ตทิ้งไว้จนต้องมีมาตรการแบบนี้ไม่ใช่เหรอ
    • การเปลี่ยนแปลงแบบนี้ทำให้คำถามสัมภาษณ์อย่าง "คุ้นเคยกับเทคโนโลยีนี้ไหม" คลุมเครือมาก เพราะเทคโนโลยีเปลี่ยนทุกเดือน จนอยากถามกลับว่ารู้ ณ ช่วงเวลาไหน
    • ถ้าอยากเรียนอย่างเป็นทางการก็จ่าย $250 แล้วไปสอบใบรับรองได้เลย
  • บน EC2 การเปลี่ยน security group หรือ IAM role โดยไม่ต้องปิด instance นั้นทำได้มาหลายปีแล้ว ส่วน spot instance เมื่อก่อนเป็นตลาดประมูล แต่ตอนนี้ไม่มีการประมูลแล้ว ทำให้ไม่มีทั้งความผันผวนของราคาที่รุนแรงหรือสถานการณ์ที่มีผู้ใช้บางกลุ่มเท่านั้นเข้าถึงได้ ซึ่งดีกว่ามาก และเมื่อก่อนยังต้องสุ่มคำนำหน้าของ object key เพื่อหลีกเลี่ยง hotspot แต่ตอนนี้ไม่จำเป็นแล้ว ฉันใช้เวลานานมากกว่าจะอธิบายให้เพื่อนร่วมงานเชื่อได้ ทั้งที่คนพวกนั้นก็เก็บแต่ไฟล์จิ๋วๆ ที่ไม่ได้เกี่ยวอะไรกับคอขวดฝั่ง backend ของ S3 อยู่แล้ว Lambda เมื่อก่อนจำกัดเวลาไว้ 5 นาทีและยังไม่รองรับ container image แต่ตอนนี้รองรับ runtime 15 นาที, Docker image, การแชร์ผ่าน EFS, RAM สูงสุด 10GB และพื้นที่เก็บข้อมูล /tmp 10GB แล้ว อีกเรื่องที่ฉันเพิ่งตระหนักคือ global scope ของ Python ก็อยู่รอดได้เหมือน /tmp
  • การกู้คืนจาก Glacier ตอนนี้ไม่จำเป็นต้องช้าจนน่าทรมานอีกต่อไป ถ้าเดาแบบ Amazon สไตล์ ฉันเคยคิดว่า Glacier สมัยก่อนน่าจะทำงานอยู่ในคลังสินค้าจริงของ Amazon ที่ไหนสักแห่ง พอมีคำขอข้อมูลก็จะมีพนักงานไปหยิบสื่อบันทึกแบบถอดย้ายได้จากชั้นวางมาเสียบเข้ากับเซิร์ฟเวอร์ คล้ายกับระบบสำรองข้อมูลลงเทปของคอมพิวเตอร์แบบ timesharing ยุคก่อน ที่ตอนนั้นต้องเปลี่ยนเทปกันจริงๆ ด้วยมือ
    • ในความเป็นจริงน่าจะใช้อุปกรณ์อัตโนมัติอย่างหุ่นยนต์จัดการเทปมากกว่า ตัวอย่างภาพที่เกี่ยวข้อง, คือให้หุ่นยนต์ไปหยิบเทปมาใส่ไดรฟ์ กรอไปยัง offset แล้วอ่าน จากนั้นกรอกลับและเอาไปเก็บคืน เวลารอจึงเกิดจากการหาเทป การกรอกลับ และการรอคิวไดรฟ์ น่าจะมีการจัดการแบบพอใส่เทปครั้งหนึ่งแล้วก็ประมวลผลทุกคำขอที่เกี่ยวข้องให้หมดเพื่อประสิทธิภาพก่อนค่อยเอาออก
    • พูดเรื่องภายในลึกๆ ไม่ได้ แต่ฉันยังไม่เคยเห็นใครเดาสถาปัตยกรรม Glacier ถูกตรงเลย ฉันเองก็เคยอยู่ AWS มาก่อน แต่บอกได้ว่า Glacier ก็รันอยู่ในดาต้าเซ็นเตอร์เดียวกับบริการ AWS อื่นๆ นั่นแหละ สิ่งสำคัญในงานวิศวกรรมหรือการจัดการผลิตภัณฑ์คือการบริหารความคาดหวังของลูกค้าให้ดี ถ้าบอกว่าอัปโหลดได้จำกัด 10 รายการ แต่ปล่อยให้อัปได้ 12 รายการ ลูกค้าก็จะเริ่มคาดหวังที่ 12 อยู่เรื่อยๆ การจัดการความคาดหวังจึงสำคัญ
    • เพราะฮาร์ดดิสก์มีรูปแบบสม่ำเสมอ ฉันเลยคิดว่าคลังเก็บพวกนี้น่าจะทำงานด้วยหุ่นยนต์อัตโนมัติ ส่วนที่ยังต้องใช้คนมักเป็นงานจัดการสิ่งที่ไม่มาตรฐาน เช่น ขนาดหรือรูปทรงที่หลากหลาย
    • ยังไงก็ตาม อุปกรณ์แบบนี้ก็ถูกทำให้เป็นหุ่นยนต์มาหลายสิบปีแล้ว
  • ฉันล็อกอินเข้า AWS account ของตัวเองไม่ได้อีกต่อไป เพราะไม่ได้ตั้ง MFA ไว้ล่วงหน้า และพอจะขออุปกรณ์ก็ต้องล็อกอินก่อนอยู่ดี แม้จะเคยได้รับคำเตือนล่วงหน้า แต่โครงสร้างที่ทำให้ขออุปกรณ์ MFA โดยไม่ล็อกอินไม่ได้ก็น่าหงุดหงิดไม่น้อย
    • น่าจะลองติดต่อทีมซัพพอร์ตดู
      ติดต่อ AWS Support
    • ดูเป็นปัญหาที่ทีมซัพพอร์ตน่าจะแก้ให้ได้ไม่ยาก
  • คิดว่าน่าจะมีคนแบบฉันเยอะเหมือนกัน ที่อยากเลิกยุ่งกับความซับซ้อนสไตล์ AWS เดิมๆ — การไปจับ API Gateway, serverless Lambda และ IAM role ให้ลงตัว — แล้วหันกลับมาใช้แค่ EC2 หรือ LightSail VPS, S3 bucket และ Route53 ผูกโดเมน จากนั้นก็ไม่ต้องคิดเรื่องอื่นอีก
    • ถ้าจะใช้แค่ storage + VPS แบบนั้น traditional VPS ถูกกว่า AWS มาก สำหรับฉัน ถ้าจะใช้ AWS ก็ต้องใช้ให้คุ้มและใช้เยอะๆ คือมอบทุกอย่างที่มอบให้ Amazon จัดการแทนได้ เพื่อแลกกับประสิทธิภาพและการลดต้นทุน Step Functions, Lambda และ DynamoDB ก็เหนือกว่าทางเลือกอื่นมาโดยตลอด เพียงแต่รู้สึกเสียดายที่นักพัฒนาจำนวนมากยังไม่ค่อยเก่งเรื่องการใช้ประโยชน์จากผู้ให้บริการให้เหมาะสมที่สุด
    • อุตสาหกรรมจำนวนมากก็ลดความซับซ้อนของคลาวด์จริงๆ และเหตุผลก็คือข้อจำกัดด้าน region ของบริการหรือเรื่องค่าใช้จ่ายที่คาดการณ์ได้
    • การจัดการ IAM กินเวลามากเกินไป จนรู้สึกว่าเวลาที่เคยใช้ดูแลระบบเมื่อก่อน ตอนนี้ถูกเอาไปลงกับการจัดการ permission หมดแล้ว IAM ยากเกินไปจนในทางปฏิบัติกลับขาดทุนสุทธิ น่าจะมีจุดลงตัวอยู่ระหว่าง VPS กับการทำ serverless แบบ least privilege ที่เข้มเกินไป ซึ่ง Fargate อาจเป็นตัวเลือกนั้น และฉันก็กำลังจะลองย้ายไปทดลองเพิ่ม
  • อยากให้ AWS โฟกัสกับ "บริการพื้นฐานแต่สำคัญ" ที่ตัวเองทำได้ดีอยู่แล้ว มากกว่าจะออกของฝั่ง AI แบบกระจัดกระจายเพื่อไล่ตามคนอื่น รู้สึกว่าผู้นำของ AWS หลงทิศทางในเรื่อง GenAI แต่ยังทำโครงสร้างพื้นฐานพื้นฐานได้ดีอยู่ AI ทำให้ดูเหมือนอยู่ในสภาวะตื่นตระหนก และจากมุมลูกค้าก็มันวุ่นวายเกินไปจนใช้งานลำบาก
    • ทิศทางของผู้บริหารตอนนี้คือทำให้อินฟราฯ อยู่ในสภาพที่ทุกคนเลือกโมเดลแล้วใช้งานได้ทันที แบบไม่ต้องเจอความซับซ้อนเรื่องการตั้งค่า
  • มันไร้เหตุผลจริงๆ ที่ S3 bucket แม้อยู่ region เดียวกับ VPC แต่ถ้าวิ่งผ่าน public internet ก็ยังโดนคิดค่า NAT Gateway ค่าเริ่มต้นควรเป็นแบบ opt-out มากกว่า แต่ที่กลายเป็น opt-in น่าจะเพราะ AWS ได้รายได้เพิ่มจากโครงสร้างแบบนี้ และคนที่อยากได้เส้นทางแบบปัจจุบันจริงๆ ก็น่าจะมีน้อยมาก
    • นี่เป็นการออกแบบโดยคำนึงถึงการที่ security เป็นค่าเริ่มต้น ถ้าไม่ตั้งค่า NAT Gateway, VPC Gateway Endpoint (S3) หรือทางออกอินเทอร์เน็ตอื่นๆ workload ก็จะเข้าถึง S3 ไม่ได้ networking ควรถูกปิดไว้ก่อน และถ้าผู้ใช้ไม่เข้าใจเส้นทางให้ดีแล้วสร้างอะไรขึ้นมาเอง ความรับผิดชอบก็อยู่ที่ลูกค้า ต้องคิดว่า AWS ให้มาแค่เครื่องมือดิบแบบ Infrastructure as a Service (IaaS)
    • S3 VPC Gateway Endpoint ก็มีไว้เพื่อจุดประสงค์นี้โดยตรง และไม่มีค่าใช้จ่าย
      เอกสารทางการของ AWS
    • พอลองตั้งค่าพวก VPC, subnet, PrivateLink endpoint และอย่างอื่นทั้งหมดแล้ว มันชวนให้รู้สึกเหลือเชื่อจริงๆ ยังอุตส่าห์ตั้งชื่อว่า PrivateLink อย่างตั้งใจด้วย (ซึ่งทางเทคนิคก็มีความหมายอยู่) ทั้งที่สิ่งแบบนี้ควรมีให้เป็นค่าเริ่มต้นโดยไม่ต้องตั้งค่าอะไรเลยด้วยซ้ำ แถมถ้าใช้ private subnet วิธีเข้าถึง S3 และบริการคล้ายกันก็ดูเหมือนจะมีทางเดียวคือ PrivateLink ด้วย ยิ่งรู้สึกแปลกเข้าไปอีก
    • ฉันคิดว่า VPC endpoint ทั้งหมดควรถูกเปิดใช้แบบฟรีเป็นค่าเริ่มต้น จะมาเก็บเงินเพิ่มแม้แต่กับการเรียกใช้ service API ของตัวเองก็ดูหนักไปหน่อย
    • นี่คือการแบ่งระดับราคานั่นเอง ลูกค้าที่ไม่ไวต่อราคาก็ไม่สนใจ ส่วนคนที่สนใจก็จะพยายามลดค่าใช้จ่าย และถึงจะอยู่ในสถานการณ์แบบนั้นก็มักยังต้องใช้ AWS อยู่ดี
  • บทความนี้ทำให้ฉันสบายใจขึ้น เพราะฉันกังวลเสมอว่า Amazon จะเปลี่ยนอะไรใหญ่ๆ แล้วบังคับให้ต้องย้ายระบบ ทั้งที่ฉันใช้งาน EC2 instance มาตั้งแต่ปี 2013 ได้อย่างราบรื่นโดยแทบไม่ต้องดูแลอะไรเลย ดีแล้วที่ไม่มีการเปลี่ยนแปลงไม่คาดคิด
  • เรื่องที่ Availability Zones ในอดีตถูกแมปแบบสุ่มตามแต่ละ account เป็นเรื่องที่ช็อกมาก
    • นั่นเป็นไปเพื่อการกระจายโหลด ถ้าหลาย account เลือกใช้ AZ เฉพาะอย่าง 1b เหมือนกัน ก็ยังทำให้การกระจายทางกายภาพจริงๆ ออกมาสม่ำเสมอได้ ภายหลังจึงมีการให้ canonical name ของแต่ละ AZ ซึ่งฉันคิดว่าเพราะ account ที่สร้าง hotspot จริงๆ กับ account ที่ต้องการ metadata เป็นคนละกลุ่มกัน
    • ดูเหมือนมีจุดประสงค์เพื่อไม่ให้ทุกคนที่ใช้ค่าเริ่มต้นเลือก us-east-1a กันหมดแล้วไปกองใน AZ เดียว
    • ตอนแรกมันดีต่อการกระจายโหลด แต่พอจะเชื่อมเครือข่ายข้ามหลาย account (เช่น PrivateLink) ก็สับสนมาก เพราะต้องมานั่งเช็กทีละอันว่า AZ ไหนของใครตรงกับอะไร ฉันเลยเคยทำวิธีแมปแบบหนึ่งต่อหนึ่งตาม account และสร้างตารางอ้างอิงภายในขึ้นมาเอง แต่ภายหลัง AWS ก็เพิ่ม zone ID เข้าไปใน metadata ทำให้ตรวจสอบได้ง่ายขึ้น
    • นโยบายนี้ทำให้ฉันลำบากมามากจริงๆ
  • มีบางอย่างที่อยากแก้ไข เพราะเกร็ดความรู้ไร้สาระที่ไม่มีความหมายอาจถูกล้มล้างได้ทั้งหมด
    Weird Al: Everything You Know is Wrong
    Firesign Theatre: Everything You Know is Wrong