รู้จัก AWS EC2 Instance Family: เลือกให้ถูก ใช้ให้คุ้ม

เวลาเราจะสร้าง EC2 instance สักตัว สิ่งแรกที่ต้องเจอคือหน้าจอเลือก Instance Type ที่มีให้เลือกเป็นร้อยๆ แบบ ทั้ง t3.micro, m6i.large, c7g.xlarge, r7a.2xlarge ฯลฯ ดูแล้วอาจงงว่าทำไมต้องมีเยอะขนาดนี้ บทความนี้จะพาไปทำความเข้าใจตั้งแต่พื้นฐานว่า "family" คืออะไร ทำไมต้องแยก และควรเลือกใช้ตัวไหนให้เหมาะกับงาน

1. Instance Type และ Family คืออะไร

ชื่อ instance ของ AWS จะมีโครงสร้างประมาณนี้ เช่น m6i.xlarge

• m = ตัวอักษรบอก "family" (กลุ่มการใช้งาน) เช่น m = general purpose, c = compute optimized, r = memory optimized
• 6 = generation หรือรุ่นของฮาร์ดแวร์ (ยิ่งเลขสูง ยิ่งใหม่ ยิ่งแรง และมักคุ้มค่ากว่า)
• i = ตัวอักษรเสริมบอกประเภท CPU หรือคุณสมบัติพิเศษ เช่น i = Intel, a = AMD, g = AWS Graviton (ARM), n = network optimized, d = มี local NVMe storage ในตัว
• xlarge = ขนาดของเครื่อง (size) บอกจำนวน vCPU และ RAM

พูดง่ายๆ Family คือ "กลุ่มเครื่อง" ที่ถูกออกแบบมาให้มีสัดส่วนทรัพยากร (CPU : RAM : Network : Storage) ที่เหมาะกับงานลักษณะใดลักษณะหนึ่งเป็นพิเศษ ส่วน "size" คือขนาดภายใน family เดียวกันที่ปรับสเปกขึ้นลงตามสัดส่วนเดิม

AWS แบ่งกลุ่มหลักๆ ออกเป็น 6 กลุ่มตามที่จะพูดถึงในบทความนี้ ได้แก่ General Purpose, Compute Optimized, Memory Optimized, Accelerated Computing, Storage Optimized และ High Performance Computing (HPC)

2. ในเมื่อความต่างคือสเปก CPU/RAM/Storage ทำไมต้องแยกเป็น Family ด้วย

นี่คือคำถามที่หลายคนสงสัย ในเมื่อสุดท้ายก็เลือก CPU กับ RAM เอง ทำไมไม่รวมเป็นเมนูเดียวแล้วปรับ CPU/RAM แบบ custom ไปเลย เหตุผลหลักๆ คือ

2.1 สัดส่วนทรัพยากรไม่เหมือนกัน แต่ละ family ไม่ได้ต่างกันแค่ "ปริมาณ" แต่ต่างกันที่ "อัตราส่วน" ระหว่าง vCPU : RAM ต่อ 1 vCPU เช่น

• General Purpose (M) มักอยู่ที่ RAM 4 GiB ต่อ 1 vCPU (สมดุล)
• Compute Optimized (C) มักอยู่ที่ RAM 2 GiB ต่อ 1 vCPU (เน้น CPU)
• Memory Optimized (R) มักอยู่ที่ RAM 8 GiB ต่อ 1 vCPU (เน้น RAM)

ถ้ารวมเป็นเมนูเดียวแล้วให้ผู้ใช้ปรับเองแบบอิสระ ต้นทุนด้าน hardware และ pricing model จะซับซ้อนมาก เพราะฮาร์ดแวร์จริงถูกผลิตและปรับแต่งมาให้เหมาะกับสัดส่วนนั้นๆ อยู่แล้ว

2.2 ฮาร์ดแวร์ภายในต่างกันจริง ไม่ใช่แค่การจำกัด quota เช่น Storage Optimized ใช้ NVMe SSD แบบต่อตรงกับเครื่อง (local instance store) ที่ให้ throughput/IOPS สูงมาก ซึ่งเป็นฮาร์ดแวร์คนละแบบกับ EBS ทั่วไป หรือ Accelerated Computing ที่มี GPU/AI chip ติดตั้งมาจริงๆ ไม่ใช่แค่ปรับซอฟต์แวร์

2.3 ช่วยให้เลือกง่ายและคาดเดาราคา/performance ได้ การแบ่ง family ช่วยให้วิศวกรเลือกตาม "โจทย์งาน" แทนที่จะต้องมานั่งคำนวณเองว่าควรได้ CPU เท่าไร RAM เท่าไร ลดความผิดพลาดในการ provision และช่วยให้ AWS ทำ capacity planning และตั้งราคาต่อ workload ได้แม่นยำกว่า

2.4 Network และ storage bandwidth ก็ถูกออกแบบมาต่างกัน บาง family (เช่น n หรือ storage-optimized) ได้ network bandwidth สูงกว่าปกติมาก เพราะถูกออกแบบมาสำหรับงานที่ต้องรับส่งข้อมูลจำนวนมาก ซึ่งเป็นคุณสมบัติที่แยกจาก CPU/RAM ล้วนๆ

3. วัตถุประสงค์การออกแบบของแต่ละ Family

• General Purpose (T, M)

ออกแบบมาให้ "สมดุล" ระหว่าง CPU, RAM และ Network เหมาะกับงานที่ยังไม่รู้ว่า bottleneck อยู่ตรงไหน หรืองานที่โหลดไม่หนักมาก M family ให้ performance สม่ำเสมอ (non-burstable) ส่วน T family ใช้ระบบ "CPU Credit" คือสะสมเครดิตตอน CPU ว่าง แล้วเอาไปใช้ตอนโหลดพุ่ง เหมาะกับงานที่ใช้ CPU ไม่สม่ำเสมอ

• Compute Optimized (C)

เน้นสัดส่วน CPU สูงกว่า RAM ต่อราคา เหมาะกับงานประมวลผลหนักที่ต้องการความเร็ว CPU เช่น batch processing, การเข้ารหัสวิดีโอ, HPC เบื้องต้น, machine learning inference, game server

• Memory Optimized (R, X, High Memory)

เน้น RAM สูงต่อ vCPU เพื่อรองรับงานที่ต้องเก็บข้อมูลจำนวนมากไว้ใน memory เพื่อลด latency จากการอ่านดิสก์ เหมาะกับ in-memory database, real-time analytics, SAP HANA

• Accelerated Computing (P, G, Trn, Inf)

มีฮาร์ดแวร์เร่งความเร็วพิเศษติดตั้งมาด้วย เช่น GPU (สำหรับ P, G) หรือชิปออกแบบเฉพาะสำหรับ AI (Trainium, Inferentia) เหมาะกับ deep learning training/inference, การประมวลผลกราฟิก 3D, การเรนเดอร์วิดีโอ

•  Storage Optimized (I, D, H)

เน้น local NVMe storage ที่ throughput และ IOPS สูงมาก เหมาะกับงานที่ต้องอ่าน-เขียนข้อมูลปริมาณมากแบบต่อเนื่อง เช่น NoSQL database, data warehouse, distributed file system

•  High Performance Computing (HPC — Hpc7 และตระกูลที่มี network เฉพาะทาง)

ออกแบบมาสำหรับงานคำนวณวิทยาศาสตร์/วิศวกรรมขนาดใหญ่ที่ต้องรันบนหลายเครื่องพร้อมกัน (multi-node) จึงเน้นเรื่อง network ความหน่วงต่ำ (low latency) ผ่านเทคโนโลยีอย่าง Elastic Fabric Adapter (EFA) เพื่อให้เครื่องหลายพันเครื่องสื่อสารกันได้เร็วเหมือนอยู่เครื่องเดียวกัน เหมาะกับ genomics, weather simulation, computational fluid dynamics (CFD)

4. ตัวอย่างขนาด (Size) ในแต่ละ Family

โครงสร้างขนาดของ AWS ส่วนใหญ่ไล่ตามลำดับนี้ (ไม่ใช่ทุก family จะมีครบทุกขนาด):

ตัวอย่างจริงในแต่ละ family

• General Purpose: t3.micro, t3.medium, m6i.large, m7g.4xlarge, m6i.metal
• Compute Optimized: c6i.xlarge, c7g.2xlarge, c6a.8xlarge, c6i.metal
• Memory Optimized: r6i.large, r7g.4xlarge, x2gd.16xlarge, r6i.metal
• Accelerated Computing: g5.xlarge, p4d.24xlarge, inf2.8xlarge, trn1.32xlarge
• Storage Optimized: i4i.large, i4i.4xlarge, d3.8xlarge, i4i.metal
• HPC: hpc7a.96xlarge, hpc7g.16xlarge

5. ตัวอย่าง Use Case ของแต่ละ Family

6. วิเคราะห์ความนิยมในการใช้งาน

จากการสำรวจของผู้ให้บริการวิเคราะห์ cost/การใช้งาน AWS พบว่า General-purpose instance family อย่าง M และ T ยังคงเป็นตัวเลือกอันดับต้นๆ เพราะให้ความสมดุลของทรัพยากรที่เหมาะกับงานหลากหลายโดยไม่ต้องวิเคราะห์ bottleneck ก่อน ทำให้เป็น "default choice" ของทีมพัฒนาส่วนใหญ่ โดยเฉพาะ T family ที่ราคาถูกและเหมาะกับ dev/test

รองลงมาคือ Compute Optimized (C) ซึ่งได้รับความนิยมมากขึ้นเรื่อยๆ ในงานที่เกี่ยวกับ data processing และ inference workload เบาๆ เพราะราคาต่อ performance คุ้มกว่า general purpose เมื่อ workload เน้น CPU ชัดเจน

Memory Optimized (R, X) เป็นที่นิยมในกลุ่มองค์กรที่รันฐานข้อมูลขนาดใหญ่หรือระบบ caching แม้จำนวนผู้ใช้จะน้อยกว่า general purpose แต่เป็นกลุ่มที่ "จำเป็นต้องใช้" เพราะไม่มีทางเลือกอื่นทดแทนได้

Accelerated Computing (GPU/AI) เติบโตเร็วที่สุดในช่วงหลัง เนื่องจากกระแส AI/ML แต่ยังมีสัดส่วนผู้ใช้น้อยกว่ากลุ่มอื่นเพราะราคาต่อชั่วโมงสูงมาก มักใช้เฉพาะช่วง training หรือมี workload เฉพาะทางจริงๆ

Storage Optimized (I, D) และ HPC เป็นกลุ่มที่มีผู้ใช้เฉพาะกลุ่มชัดเจน (niche) คือองค์กรที่มีงาน data-intensive หรือ scientific computing โดยเฉพาะ ไม่ใช่ตัวเลือกสำหรับงานทั่วไป

สรุปโดยรวม: General Purpose > Compute Optimized > Memory Optimized > Accelerated Computing > Storage Optimized ≈ HPC (เรียงตามความนิยม/จำนวนผู้ใช้งาน ไม่ใช่ตามค่าใช้จ่ายรวม)

7. ตารางเปรียบเทียบสรุปแต่ละ Family

สรุปส่งท้าย

การเลือก EC2 family ที่เหมาะสมไม่ใช่แค่เรื่องสเปกเยอะ-น้อย แต่คือการเลือก "สัดส่วนและฮาร์ดแวร์ที่ถูกออกแบบมาให้ตรงกับลักษณะงาน" ซึ่งช่วยทั้งเรื่อง performance และการควบคุมค่าใช้จ่ายในระยะยาว วิธีที่ง่ายที่สุดสำหรับมือใหม่คือเริ่มจาก General Purpose (M/T) ก่อน แล้วใช้เครื่องมืออย่าง AWS Compute Optimizer เพื่อดูว่า workload จริงของเรามีแนวโน้มไปทาง CPU-heavy, Memory-heavy หรือ Storage-heavy แล้วค่อยขยับไป family ที่เหมาะสมกว่าในภายหลัง