0Pricing
Cloud & IT Cert Prep · บทเรียน

การปรับขนาดให้เหมาะสมและ Compute Optimizer

ใช้คำแนะนำจาก AWS Compute Optimizer เพื่อลดขนาดอินสแตนซ์ EC2 ฟังก์ชัน Lambda และวอลุ่ม EBS ที่จัดสรรเกินความจำเป็น เพื่อลดต้นทุน

การปรับขนาดให้เหมาะสมและ Compute Optimizer เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

ปัญหาการจัดสรรทรัพยากรมากเกินไป

หนึ่งในข้อผิดพลาดที่พบบ่อยและมีค่าใช้จ่ายสูงที่สุดในการออกแบบสถาปัตยกรรมคลาวด์คือ การจัดสรรทรัพยากรมากเกินไป — จัดสรรทรัพยากรมากกว่าที่เวิร์กโหลดต้องการจริง ทีม IT มักจัดสรรทรัพยากรมากเกินไปเนื่องจากเคยชินกับการทำงานในศูนย์ข้อมูลภายในองค์กร (ซื้อความจุไว้รองรับโหลดสูงสุด) กังวลว่าประสิทธิภาพจะลดลง หรือไม่เคยกลับมาตรวจสอบการตัดสินใจเรื่องขนาดในครั้งแรก ใน AWS อินสแตนซ์ EC2, วอลุ่ม EBS และฟังก์ชัน Lambda ที่จัดสรรเกินความจำเป็นทำให้สิ้นเปลืองเงินทุกนาทีที่ทำงานอยู่ การปรับขนาดให้เหมาะสม คือกระบวนการอย่างเป็นระบบเพื่อค้นหาและกำจัดความสูญเปล่านี้

# Common over-provisioning symptoms:
# EC2: average CPU < 10%, memory < 20%
# RDS: storage auto-grow never triggered
# Lambda: allocated memory rarely exceeds 40%
# EBS: provisioned IOPS consistently unused

# Cost impact example:
# Over-provisioned r5.8xlarge at $1.92/hr: $1,382/month
# Correct size r5.xlarge at $0.252/hr:      $181/month
# Savings: $1,201/month per instance

ภาพรวม AWS Compute Optimizer

AWS Compute Optimizer วิเคราะห์ utilizationMetrics ในอดีตจาก CloudWatch และใช้การเรียนรู้ของเครื่องเพื่อแนะนำทรัพยากรประมวลผล AWS ที่เหมาะสมที่สุด โดยรองรับ EC2 instances EC2 Auto Scaling Groups EBS volumes Lambda functions และ Amazon ECS on Fargate Compute Optimizer ต้องมีประวัติเมตริกอย่างน้อย 30 วันจึงจะสร้างคำแนะนำที่มีความมั่นใจได้ คุณสามารถเปิดใช้งานได้ฟรี และจะได้รับคำแนะนำพร้อม estimatedMonthlySavings และระดับความเสี่ยงจากการเปลี่ยนแปลง

# Opt in to Compute Optimizer
aws compute-optimizer update-enrollment-status \
  --status Active

# Get EC2 recommendations
aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[].{Instance:currentInstanceType,Recommended:recommendationOptions[0].instanceType,Savings:recommendationOptions[0].estimatedMonthlySavings.value,Risk:recommendationOptions[0].performanceRisk}'

# Get Lambda recommendations
aws compute-optimizer get-lambda-function-recommendations

การปรับขนาด EC2 ให้เหมาะสมด้วย Compute Optimizer

Compute Optimizer วิเคราะห์ การใช้ CPU ของ EC2, การใช้หน่วยความจำ (ผ่าน CloudWatch agent), ปริมาณงานเครือข่าย และ EBS IOPS ในช่วง 3, 14 หรือมากกว่า 30 วันที่ผ่านมา จากนั้นจะแนะนำผลการประเมินหนึ่งในสี่แบบ: Optimized (ขนาดปัจจุบันเหมาะสมแล้ว), จัดสรรเกินความจำเป็น (สามารถลดขนาดได้), จัดสรรไม่เพียงพอ (ควรเพิ่มขนาด) หรือ ไม่ได้ปรับให้เหมาะสม (ข้อมูลไม่เพียงพอ) โปรดตรวจสอบ performanceRisk เสมอ — Compute Optimizer กำหนดความเสี่ยงเป็น VeryLow, Low, Medium, High สำหรับคำแนะนำแต่ละรายการ

# EC2 recommendation findings:
# Finding: OVER_PROVISIONED
# CurrentInstanceType: m5.4xlarge
# RecommendedInstanceType: m5.xlarge
# CPU utilisation: P99 = 22%, P50 = 4%
# Memory utilisation: P99 = 18%, P50 = 8%
# EstimatedMonthlySavings: $380
# PerformanceRisk: VeryLow

# Always check:
# - Does current instance have burstable credits? (T3)
# - Are there workload spikes not captured in averages?
# - Is there seasonality to consider?

การปรับขนาด Lambda ให้เหมาะสม

ฟังก์ชัน Lambda คิดค่าบริการตามเวลาที่ทำงานเป็นมิลลิวินาทีคูณด้วยหน่วยความจำที่จัดสรร การจัดสรรหน่วยความจำมากเกินความจำเป็นทำให้สิ้นเปลืองเงิน แต่หน่วยความจำที่มากขึ้นก็หมายถึง CPU ที่มากขึ้นด้วย ดังนั้นจุดสมดุลที่เหมาะสมคือ การตั้งค่าหน่วยความจำที่ทำให้ค่าใช้จ่ายต่อการเรียกใช้หนึ่งครั้งต่ำที่สุด Compute Optimizer วิเคราะห์ระยะเวลาการเรียกใช้ Lambda อัตราข้อผิดพลาด และเมตริก timeout เพื่อแนะนำการตั้งค่าหน่วยความจำที่เหมาะสมที่สุด เครื่องมือโอเพนซอร์ส Lambda Power Tuning ยังสามารถเรียกใช้ฟังก์ชันของคุณด้วยการตั้งค่าหน่วยความจำต่าง ๆ เพื่อค้นหาการกำหนดค่าที่มีต้นทุนเหมาะสมที่สุดจากการทดสอบจริง

# Compute Optimizer Lambda recommendations
aws compute-optimizer get-lambda-function-recommendations \
  --function-arns arn:aws:lambda:us-east-1:123:function:my-function

# Response shows:
# currentMemorySize: 1024 MB
# recommendedMemorySize: 256 MB
# utilizationMetrics:
#   - type: MEMORY_MAXIMUM, value: 89 (MB)
# estimatedMonthlySavings: $45

# 89 MB actual vs 1024 MB allocated = 935 MB wasted

การปรับขนาด EBS Volume ให้เหมาะสม

EBS volumes มักถูกจัดสรรเกินความจำเป็นทั้งในด้าน ขนาด (พื้นที่ดิสก์ที่ไม่ได้ใช้) และ IOPS (IOPS ที่จัดสรรไว้แต่ไม่เคยถูกใช้งาน) Compute Optimizer วิเคราะห์เมตริก VolumeReadOps, VolumeWriteOps, VolumeReadBytes, VolumeWriteBytes คำแนะนำที่พบบ่อยคือย้ายจาก gp2 ไปเป็น gp3 (ซึ่งแยกขนาดออกจาก IOPS) — คุณสามารถปรับขนาด IOPS แยกกันได้ โดยมักประหยัดค่าใช้จ่ายได้ 20% นอกจากนี้ควรค้นหา วอลุ่ม EBS ที่ไม่ได้เชื่อมต่อ (อินสแตนซ์ถูกยกเลิกแต่ยังเหลือวอลุ่มไว้) แล้วสร้างสแนปชอตหรือลบวอลุ่มเหล่านั้น

# Get EBS volume recommendations
aws compute-optimizer get-ebs-volume-recommendations \
  --volume-arns arn:aws:ec2:us-east-1:123:volume/vol-12345

# Common finding: gp2 -> gp3 migration
# gp2: 500 GB = 500 GB * $0.10 = $50/month
#   IOPS: 1,500 (3 IOPS/GB, not configurable)
# gp3: 500 GB = $40/month + 3,000 IOPS free
#   Save $10/month plus get MORE baseline IOPS

# Find unattached EBS volumes
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[].{VolumeId:VolumeId,Size:Size,Created:CreateTime}'

คำแนะนำสำหรับ Auto Scaling Group

Compute Optimizer วิเคราะห์ utilizationMetrics ของ ASG จากอินสแตนซ์ทั้งหมดในกลุ่ม และแนะนำ การเปลี่ยนแปลง launch template สำหรับ instanceType หากอินสแตนซ์ทั้งหมดใน ASG ถูกจัดสรรเกินความจำเป็นอย่างต่อเนื่อง การเปลี่ยนไปใช้ instanceType ที่เล็กลงจะช่วยลดค่าใช้จ่ายเมื่อใช้งานในปริมาณมาก ตัวอย่างเช่น หาก ASG มีอินสแตนซ์ m5.large โดยเฉลี่ย 10 อินสแตนซ์ การเปลี่ยนเป็น m5.medium จะประหยัดได้ 50% ต่ออินสแตนซ์ Compute Optimizer ยังแนะนำ อินสแตนซ์ที่ใช้ Graviton เมื่อซอฟต์แวร์ของคุณเข้ากันได้ ซึ่งช่วยเพิ่มประสิทธิภาพและลดค่าใช้จ่ายได้พร้อมกัน

# Get ASG recommendations
aws compute-optimizer get-auto-scaling-group-recommendations \
  --auto-scaling-group-arns arn:aws:autoscaling:us-east-1:123:autoScalingGroup:abc:autoScalingGroupName/my-asg

# If recommendation is to switch to Graviton:
# Current: m5.large (x86, $0.096/hr)
# Recommended: m6g.large (Graviton2, $0.077/hr)
# Savings: 20% per instance
# ASG at 10 instances average = $220/month savings

Trusted Advisor สำหรับข้อมูลเชิงลึกด้านค่าใช้จ่าย

AWS Trusted Advisor เป็นอีกเครื่องมือหนึ่งที่ให้ข้อมูลเชิงลึกเพื่อปรับค่าใช้จ่ายให้เหมาะสม พร้อมการตรวจสอบด้านความปลอดภัย ประสิทธิภาพ ความทนทานต่อข้อผิดพลาด และขีดจำกัดบริการ การตรวจสอบด้านค่าใช้จ่ายที่สำคัญ ได้แก่ Low Utilization EC2 Instances (CPU ต่ำกว่า 10% เป็นเวลาอย่างน้อย 4 วัน), Unassociated Elastic IP Addresses (มีค่าใช้จ่ายเมื่อไม่ได้เชื่อมต่อ), Underutilized EBS Volumes, Idle Load Balancers (ไม่มีเป้าหมายที่สถานะปกติ) และ Unused Reserved Instances การตรวจสอบพื้นฐานของ Trusted Advisor ไม่มีค่าใช้จ่าย แต่การตรวจสอบทั้งหมดต้องใช้ Business หรือ Enterprise Support

# Trusted Advisor: get cost optimisation checks
aws support describe-trusted-advisor-checks \
  --language en \
  --query 'checks[?category==`cost_optimizing`].{Name:name,Id:id}'

# Key checks:
# Qkj5MU5fNp: Low utilisation EC2 instances
# Z4AUBRNSmh: Unassociated Elastic IP addresses
# DAvU99Dc4C: Underutilized EBS volumes
# hjLMh88uM8: Idle load balancers
# 1e93e4c0b5: Unused reserved instances

การอัปเกรดรุ่นของอินสแตนซ์

AWS เปิดตัว EC2 instance รุ่นใหม่ที่มีประสิทธิภาพมากขึ้นเป็นประจำ โดยให้ประสิทธิภาพดีกว่าด้วยค่าใช้จ่ายที่ต่ำกว่าหรือเท่าเดิม การเปลี่ยนจาก รุ่นที่ 5 (m5, c5, r5) เป็น รุ่นที่ 7 (m7g, c7g, r7g) อาจเพิ่มประสิทธิภาพการประมวลผลได้ 40% ด้วยค่าใช้จ่ายใกล้เคียงกันหรือต่ำกว่า Compute Optimizer จะระบุโอกาสอัปเกรดเป็นรุ่นใหม่โดยเฉพาะ รวมถึงอินสแตนซ์ที่ใช้ Graviton การอัปเกรดอินสแตนซ์มักเป็นวิธีปรับขนาดให้เหมาะสมที่ง่ายที่สุด — การกำหนดค่าเดิม ฮาร์ดแวร์ใหม่ ประสิทธิภาพดีขึ้น และค่าใช้จ่ายลดลง

# EC2 instance generation comparison (same price tier):
# m5.large:  2 vCPU, 8 GB, $0.096/hr  (2019)
# m6i.large: 2 vCPU, 8 GB, $0.096/hr  (2021, ~10% faster)
# m7i.large: 2 vCPU, 8 GB, $0.1008/hr (2023, ~15% faster)
# m7g.large: 2 vCPU, 8 GB, $0.0808/hr (2023, Graviton3, cheapest)

# Upgrade path for Linux workloads:
# m5 -> m7g (Graviton): best price/performance
# m5 -> m7i: same architecture, no code changes

การปรับขนาด RDS Instance ให้เหมาะสม

RDS instances มีค่าใช้จ่ายสูงและมักถูกจัดสรรเกินความจำเป็น ใช้ เมตริก CloudWatch เพื่อประเมิน utilizationMetrics ของ RDS ได้แก่ CPUUtilization, FreeableMemory, ReadIOPS และ WriteIOPS หาก CPU ต่ำกว่า 20% และหน่วยความจำเหลืออยู่ในระดับสูงอย่างสม่ำเสมอ ให้พิจารณาลดขนาด สำหรับฐานข้อมูล production ที่ใช้ Multi-AZ การปรับขนาดให้เหมาะสมจะเพิ่มเงินที่ประหยัดได้เป็นสองเท่า เนื่องจากทั้งเครื่องหลักและเครื่องสำรองมีการเปลี่ยนแปลง นอกจากนี้ควรพิจารณาเปลี่ยนจาก RDS MySQL/PostgreSQL เป็น Aurora ซึ่งมักให้ประสิทธิภาพดีกว่าด้วยค่าใช้จ่ายใกล้เคียงกัน และมีประสิทธิภาพด้านต้นทุนมากกว่าเมื่อใช้งานในปริมาณมาก

# Monitor RDS utilisation for right-sizing
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value=mydb \
  --start-time 2026-05-21T00:00:00Z \
  --end-time 2026-06-21T00:00:00Z \
  --period 86400 \
  --statistics Maximum Average

# If 30-day P99 CPU < 30%, consider downsizing
# If P99 CPU > 80%, consider upsizing

การทำให้การปรับขนาดเป็นกระบวนการปฏิบัติงาน

การปรับขนาดให้เหมาะสมควรเป็นกระบวนการที่ดำเนินต่อเนื่อง ไม่ใช่การทำเพียงครั้งเดียว กำหนด รอบการทบทวนรายเดือนหรือรายไตรมาส: ดึงคำแนะนำจาก Compute Optimizer ประเมินว่ารายการใดนำไปใช้ได้อย่างปลอดภัย ดำเนินการเปลี่ยนแปลงในช่วงบำรุงรักษา และวัดผลการประหยัด ทำงานอัตโนมัติสำหรับรายการที่ทำได้ง่าย เช่น การล้างวอลุ่ม EBS ที่ไม่ได้เชื่อมต่อ การปล่อย Elastic IP ที่ไม่ได้ใช้ และการลบโหลดบาลานเซอร์ที่ไม่มีการใช้งาน ซึ่งสามารถเขียนสคริปต์ได้ สร้าง แดชบอร์ดการปรับค่าใช้จ่ายให้เหมาะสม ใน CloudWatch เพื่อติดตามค่าใช้จ่ายรายเดือนแยกตามบริการและเน้นการเพิ่มขึ้นที่ผิดปกติ

# Script to release unassociated Elastic IPs
aws ec2 describe-addresses \
  --query 'Addresses[?!AssociationId].AllocationId' \
  --output text | xargs -I {} \
  aws ec2 release-address --allocation-id {}

# Script to delete unattached EBS volumes (careful!)
# First check if snapshots exist before deleting
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[].VolumeId' \
  --output text

การปรับขนาดให้เหมาะสมเทียบกับการเปลี่ยนแปลงสถาปัตยกรรม

การปรับขนาดให้เหมาะสมช่วยแก้ปัญหาการจัดสรรทรัพยากรมากเกินไปภายในสถาปัตยกรรมเดิม แต่บางครั้งตัวสถาปัตยกรรมเองก็เป็นปัญหา อินสแตนซ์ EC2 ขนาดใหญ่เพียงเครื่องเดียวที่ทำงานหลายแอปพลิเคชันอาจต้องแยกสถาปัตยกรรม (ไมโครเซอร์วิสบน Fargate) แทนที่จะเพียงลดขนาดอินสแตนซ์ ฐานข้อมูลแบบโมโนลิทิกอาจต้องแบ่งส่วนข้อมูลหรือใช้ Caching แทนการลดขนาดอินสแตนซ์เพียงอย่างเดียว การปรับขนาดให้เหมาะสมเป็นขั้นตอนแรกที่รวดเร็วที่สุด ส่วนการปรับสถาปัตยกรรมให้เหมาะสม (Serverless, คอนเทนเนอร์, Caching) ให้การประหยัดที่ลึกซึ้งและต่อเนื่องกว่า แต่ต้องใช้ความพยายามมากกว่า เสาหลัก Cost การปรับให้เหมาะสมแนะนำให้ดำเนินการทั้งสองแนวทาง

# Cost optimisation hierarchy:
# Level 1: Right-sizing (quick wins, days)
#   - Compute Optimizer recommendations
#   - Delete unused resources
#   - Elastic IP, EBS cleanup

# Level 2: Purchasing model (weeks)
#   - Reserved Instances / Savings Plans
#   - Spot for eligible workloads

# Level 3: Architecture (months)
#   - Serverless migration
#   - Container consolidation
#   - Caching layer addition
#   - Database optimisation

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า AWS Compute Optimizer ใช้การเรียนรู้ของเครื่องกับเมตริก CloudWatch เพื่อแนะนำทรัพยากรประมวลผลที่ปรับขนาดอย่างเหมาะสม การปรับขนาดให้เหมาะสมใช้ได้กับ EC2, Lambda, EBS, ASGs และ ECS on Fargate และ การอัปเกรดเป็นอินสแตนซ์รุ่นใหม่กว่า (โดยเฉพาะ Graviton) ช่วยปรับปรุงทั้งค่าใช้จ่ายและประสิทธิภาพ ทำให้การปรับขนาดเป็นแนวปฏิบัติที่เกิดขึ้นเป็นประจำ ไม่ใช่การดำเนินการเพียงครั้งเดียว บทถัดไปเราจะสำรวจ Reserved Instances, Savings Plans และรูปแบบการจัดซื้อ Spot

คำถามที่พบบ่อย

บทเรียน “การปรับขนาดให้เหมาะสมและ Compute Optimizer” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การปรับขนาดให้เหมาะสมและ Compute Optimizer” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การปรับขนาดให้เหมาะสมและ Compute Optimizer”

ใช้คำแนะนำจาก AWS Compute Optimizer เพื่อลดขนาดอินสแตนซ์ EC2 ฟังก์ชัน Lambda และวอลุ่ม EBS ที่จัดสรรเกินความจำเป็น เพื่อลดต้นทุน คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “การปรับขนาดให้เหมาะสมและ Compute Optimizer” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม

ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การปรับขนาดให้เหมาะสมและ Compute Optimizer
  2. อินสแตนซ์แบบสงวน แผนประหยัด และ Spot
  3. Cost Explorer งบประมาณ และแท็กจัดสรรค่าใช้จ่าย
  4. การเพิ่มประสิทธิภาพต้นทุน S3 และการถ่ายโอนข้อมูล
← กลับไปที่ Cloud & IT Cert Prep