เสาหลักการเพิ่มประสิทธิภาพต้นทุนและความยั่งยืน
ตระหนักถึงค่าใช้จ่าย เลือกขนาดทรัพยากรให้เหมาะสม และเลือกรูปแบบราคาเพื่อควบคุมต้นทุน ลดขนาดโครงสร้างพื้นฐาน และเพิ่มประสิทธิภาพการใช้พลังงานเพื่อความยั่งยืน
เสาหลักการเพิ่มประสิทธิภาพต้นทุนและความยั่งยืน เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
ภาพรวมเสาหลัก Cost Optimisation
เสาหลัก Cost Optimisation มุ่งเน้นการหลีกเลี่ยงค่าใช้จ่ายที่ไม่จำเป็นและการได้รับคุณค่าสูงสุดจากการใช้จ่าย AWS ของคุณ เสาหลักนี้มักสร้างผลกระทบได้ทันทีมากที่สุด เนื่องจากการจัดสรรทรัพยากรคลาวด์เกินความจำเป็นทำได้ง่าย หลักการสำคัญในการออกแบบมีดังนี้: ใช้การจัดการการเงินบนคลาวด์ — มองต้นทุนเป็นเมตริกสำคัญระดับเดียวกับด้านอื่น นำรูปแบบการใช้งานตามจริงมาใช้ — จ่ายเฉพาะสิ่งที่คุณใช้ วัดประสิทธิภาพโดยรวม — ติดตามต้นทุนต่อหน่วยของคุณค่าทางธุรกิจ ลดการใช้จ่ายกับงานหนักที่ไม่สร้างความแตกต่าง — ใช้บริการที่มีการจัดการแทนการจัดการโครงสร้างพื้นฐานเอง
# Cost Optimisation pillars:
# 1. Expenditure awareness - visibility into what you spend
# 2. Cost-effective resources - right instance types, storage classes
# 3. Matching supply to demand - auto scaling, spot instances
# 4. Optimising over time - regularly review and adjust
# Example: undifferentiated heavy lifting
# Instead of managing your own Redis: use ElastiCache
# Instead of managing Kubernetes: use EKS or Fargate
# Managed services reduce operational overhead AND costการปรับขนาดทรัพยากรให้เหมาะสม
การปรับขนาดให้เหมาะสมเป็นการดำเนินการเพิ่มประสิทธิภาพด้านต้นทุนที่ส่งผลมากที่สุด — โดยระบุและกำจัดทรัพยากรที่จัดสรรเกินความจำเป็น รูปแบบที่พบได้บ่อยคือการเปิดใช้ Instance ขนาดใหญ่ในช่วงจัดสรรทรัพยากรเริ่มต้น แล้วไม่เคยกลับมาตรวจสอบอีก AWS Compute Optimizerจะวิเคราะห์ตัวชี้วัดการใช้งานและแนะนำประเภท Instance ที่เหมาะสมที่สุด ตัวอย่างที่พบได้ทั่วไป: m5.4xlarge ที่ใช้ CPU เพียง 5% ควรเปลี่ยนเป็น t3.medium ซึ่งช่วยประหยัดต้นทุนการประมวลผลได้ 80% การปรับขนาดให้เหมาะสมใช้ได้กับ EC2, Lambda (หน่วยความจำ), RDS และวอลุ่ม EBS
# Get Compute Optimizer recommendations for all EC2
aws compute-optimizer get-ec2-instance-recommendations \
--filters Name=finding,Values=Overprovisioned
# Response includes:
# currentInstanceType: m5.4xlarge
# recommendedInstanceType: t3.large
# estimatedMonthlySavings: $280
# performanceRisk: VeryLow
# Also check EBS volumes:
aws compute-optimizer get-ebs-volume-recommendations \
--filters Name=finding,Values=Overprovisionedการเพิ่มประสิทธิภาพรูปแบบการจัดซื้อ
สำหรับเวิร์กโหลดที่มีการใช้งานคงที่ การคิดราคาแบบ On-Demand เป็นตัวเลือกที่มีค่าใช้จ่ายสูงที่สุด คุณสามารถประหยัดได้มากด้วยวิธีต่อไปนี้: Reserved Instances (1 หรือ 3 ปี) — ประหยัดได้สูงสุด 72% สำหรับเวิร์กโหลดที่คาดการณ์ได้ Savings Plans — ข้อผูกพันที่ยืดหยุ่น (ประหยัดได้สูงสุด 66%) ซึ่งใช้ได้กับตระกูล Instance และรีเจียนต่าง ๆ Spot Instances — ประหยัดได้สูงสุด 90% สำหรับเวิร์กโหลดที่สามารถหยุดชะงักได้ (งานแบบแบตช์, CI/CD, งานแบบไร้สถานะ) โดยทั่วไป กลุ่ม Instance ที่เพิ่มประสิทธิภาพด้านต้นทุนจะผสานทั้งสามรูปแบบเข้าด้วยกัน: ใช้ Savings Plans สำหรับการใช้งานพื้นฐาน ใช้ Spot สำหรับช่วงที่มีการใช้งานพุ่งสูง และใช้ On-Demand สำหรับกรณีเฉพาะ
# Purchasing model comparison:
# On-Demand: $0.192/hr (m5.large) No commitment
# 1yr Reserved: $0.114/hr $0.78/hr effective
# 3yr Reserved: $0.074/hr Highest savings
# Compute SP: ~$0.128/hr Flexible family/region
# Spot: $0.05-0.08/hr Interruptible
# Savings Plans cover:
# - Compute Savings Plans: EC2 + Lambda + Fargate
# - EC2 Instance Savings Plans: specific family in one regionSpot Instances เพื่อเพิ่มประสิทธิภาพด้านต้นทุน
Spot Instances ใช้ความจุ AWS ที่เหลืออยู่ โดยมีส่วนลดสูงสุด 90% แต่ AWS อาจหยุดการใช้งานได้โดยแจ้งล่วงหน้า 2 นาทีเมื่อจำเป็นต้องนำความจุนั้นกลับไปใช้ Spot เหมาะสำหรับ: การประมวลผลแบบแบตช์ (ทำจุดตรวจสอบและทำงานต่อ), ตัวแทนสร้าง CI/CD, เว็บเซิร์ฟเวอร์แบบไร้สถานะ (อยู่ด้านหลัง ALB โดย ELB จะกำหนดเส้นทางหลบ Instance ที่ถูกหยุดการทำงาน) และ โหนดผู้ปฏิบัติงานของ EMR และ EKS ใช้ Spot Fleet หรือ ASG ที่มีประเภท Instance และ AZ หลายรายการ เพื่อกระจายการใช้งานไปยังกลุ่มต่าง ๆ และลดความเสี่ยงจากการหยุดชะงัก
# ASG with mixed instances (On-Demand + Spot)
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name my-mixed-asg \
--mixed-instances-policy '{
"LaunchTemplate": {"LaunchTemplateSpecification":{"LaunchTemplateId":"lt-12345","Version":"$Latest"},"Overrides":[{"InstanceType":"m5.large"},{"InstanceType":"m5a.large"},{"InstanceType":"m4.large"}]},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 20,
"SpotAllocationStrategy": "capacity-optimized"
}
}' \
--min-size 2 --max-size 20 --desired-capacity 5การเพิ่มประสิทธิภาพต้นทุนพื้นที่จัดเก็บ S3
คุณสามารถลดต้นทุนพื้นที่จัดเก็บ S3 ได้อย่างมากด้วยการใช้คลาสพื้นที่จัดเก็บที่เหมาะสมและทำให้การเปลี่ยนคลาสเป็นอัตโนมัติ S3 Intelligent-Tiering จะย้ายออบเจ็กต์ระหว่างระดับการเข้าถึงโดยอัตโนมัติตามรูปแบบการเข้าถึง — เหมาะอย่างยิ่งเมื่อไม่ทราบรูปแบบการเข้าถึง กฎวงจรชีวิตจะเปลี่ยนออบเจ็กต์ตามกำหนดเวลา: จาก Standard → Standard-IA หลัง 30 วัน → Glacier หลัง 90 วัน → Deep Archive หลัง 180 วัน นอกจากนี้ ควรพิจารณาใช้ S3 Select เพื่อดึงเฉพาะส่วนย่อยของข้อมูลออบเจ็กต์ที่จำเป็น ซึ่งช่วยลดต้นทุนการถ่ายโอนและการประมวลผลข้อมูล
# S3 lifecycle policy for cost optimisation
aws s3api put-bucket-lifecycle-configuration \
--bucket my-data-bucket \
--lifecycle-configuration '{
"Rules": [{
"ID": "auto-archive",
"Status": "Enabled",
"Transitions": [
{"Days": 30, "StorageClass": "STANDARD_IA"},
{"Days": 90, "StorageClass": "GLACIER_IR"},
{"Days": 365, "StorageClass": "DEEP_ARCHIVE"}
]
}]
}'การติดแท็กและการจัดสรรต้นทุน
หากไม่มีการติดแท็กอย่างเหมาะสม จะไม่สามารถทราบได้ว่าแต่ละทีมหรือโครงการมีค่าใช้จ่ายเท่าใด แท็กการจัดสรรต้นทุนช่วยให้คุณแจกแจงต้นทุนตามทีม โครงการ สภาพแวดล้อม หรือมิติใด ๆ ที่คุณกำหนดได้ เปิดใช้งานแท็กในคอนโซลการเรียกเก็บเงิน จากนั้นใช้ AWS Cost Explorer เพื่อกรองและจัดกลุ่มต้นทุนตามแท็ก บังคับใช้การติดแท็กด้วย นโยบายแท็กใน AWS Organizations และใช้ กฎ AWS Config เพื่อตรวจหาทรัพยากรที่ไม่มีแท็ก วิธีนี้ทำให้สามารถทำ showback (การแสดงให้เห็นต้นทุน) และ chargeback (การจัดสรรต้นทุน) ให้แก่แต่ละทีมได้
# Enforce required tags with Config rule
aws configservice put-config-rule \
--config-rule '{
"ConfigRuleName": "required-tags",
"Source": {"Owner":"AWS","SourceIdentifier":"REQUIRED_TAGS"},
"InputParameters": "{\"tag1Key\":\"Project\",\"tag2Key\":\"Environment\",\"tag3Key\":\"Owner\"}"
}'
# Query cost by tag in Cost Explorer
aws ce get-cost-and-usage \
--time-period Start=2026-06-01,End=2026-06-30 \
--granularity MONTHLY \
--group-by Type=TAG,Key=Projectภาพรวมเสาหลักด้านความยั่งยืน
เสาหลักด้านความยั่งยืน (เพิ่มเข้ามาในปี 2021) มุ่งลดผลกระทบต่อสิ่งแวดล้อมของเวิร์กโหลดบนคลาวด์ โดยลดการใช้พลังงานและเพิ่มประสิทธิภาพ หลักการออกแบบมีดังนี้: ทำความเข้าใจผลกระทบของคุณ — วัดคาร์บอนฟุตพรินต์ของเวิร์กโหลด กำหนดเป้าหมายด้านความยั่งยืน ใช้ทรัพยากรให้เกิดประโยชน์สูงสุด — ปรับขนาดให้เหมาะสมเพื่อหลีกเลี่ยงทรัพยากรที่ไม่ได้ใช้งาน คาดการณ์และนำฮาร์ดแวร์ที่มีประสิทธิภาพสูงขึ้นมาใช้ — ใช้รุ่น Instance ล่าสุด ใช้บริการที่มีการจัดการ — AWS ดำเนินงานศูนย์ข้อมูลได้มีประสิทธิภาพกว่าองค์กรส่วนใหญ่
# Sustainability improvement areas:
# 1. Right-size instances (reduce idle energy use)
# 2. Use Graviton (ARM) instances: 60% less energy than x86
# 3. Use Spot instances: uses otherwise idle capacity
# 4. Use managed services: AWS optimises their utilisation
# 5. Use serverless: no idle servers
# 6. Move to S3/EFS instead of EC2 instance storage
# 7. Implement data lifecycle (don't store forever)AWS Graviton เพื่อความยั่งยืนและต้นทุน
โปรเซสเซอร์ AWS Graviton (ใช้ ARM) ให้ประสิทธิภาพด้านพลังงานดีขึ้นสูงสุด 60% และมีอัตราส่วนราคา/ประสิทธิภาพดีขึ้น 20-40% เมื่อเทียบกับ Instance แบบ x86 Instance Graviton3/4 (ตระกูล c7g, m7g, r7g, t4g) พร้อมใช้งานสำหรับเวิร์กโหลด EC2, Lambda และ Fargate ส่วนใหญ่ การย้ายจาก x86 ไปยัง Graviton ช่วยปรับปรุงทั้งเสาหลักด้านความยั่งยืนและการเพิ่มประสิทธิภาพต้นทุนไปพร้อมกัน — ใช้วัตต์ต่อการคำนวณน้อยลงและมีราคา Instance ต่ำลง เวิร์กโหลดส่วนใหญ่ (Linux, แอปแบบคอนเทนเนอร์, JVM) สามารถย้ายได้โดยต้องเปลี่ยนแปลงเพียงเล็กน้อย
# Compare: m5.large (x86) vs m7g.large (Graviton3)
# m5.large: $0.096/hr, 2 vCPU, 8 GB
# m7g.large: $0.0808/hr, 2 vCPU, 8 GB
# Savings: ~16% cheaper + 40% better performance
# Switch Lambda function to Graviton (arm64)
aws lambda update-function-configuration \
--function-name my-function \
--architectures arm64
# Lambda arm64 is 20% cheaper than x86
# Most Python, Node.js, Java functions work unchangedการกำจัดทรัพยากรที่ไม่ได้ใช้งาน
แหล่งสำคัญของต้นทุนและการสูญเสียพลังงานโดยไม่จำเป็นคือทรัพยากรที่ไม่ได้ใช้งาน — Instance EC2 ที่ใช้ CPU เพียง 1%, วอลุ่ม EBS ที่ไม่ได้เชื่อมต่อ, Elastic IP ที่ไม่ได้ใช้ และสภาพแวดล้อมสำหรับการพัฒนา/ทดสอบที่ถูกเปิดทิ้งไว้ตลอด 24 ชั่วโมงทุกวัน ใช้กำหนดการหยุด/เริ่มต้นสำหรับสภาพแวดล้อมที่ไม่ใช่การใช้งานจริง โดยใช้กฎ EventBridge และระบบอัตโนมัติของ Systems Manager — หยุด Instance สำหรับการพัฒนาตอน 18:00 น. และเริ่มต้นตอน 08:00 น. ใช้ AWS Trusted Advisor และ Cost Explorer เพื่อระบุ Instance ที่ไม่ได้ใช้งาน วอลุ่ม EBS ที่ไม่ได้ใช้ และ Reserved Instances ที่ใช้ประโยชน์ต่ำกว่าที่ควร
# EventBridge + SSM to stop dev instances nights/weekends
aws events put-rule \
--name stop-dev-instances \
--schedule-expression 'cron(0 22 ? * MON-FRI *)'
aws events put-targets \
--rule stop-dev-instances \
--targets '[{
"Id": "StopDevInstances",
"Arn": "arn:aws:ssm:us-east-1::automation-definition/AWS-StopEC2Instance",
"RoleArn": "arn:aws:iam::123:role/EventBridgeRole",
"Input": "{\"InstanceId\":[\"i-dev1\",\"i-dev2\"]}"
}]'วงจรชีวิตข้อมูลเพื่อความยั่งยืน
การจัดเก็บข้อมูลไว้ตลอดไปทำให้สิ้นเปลืองพลังงาน เสาหลักด้านความยั่งยืนแนะนำให้ใช้นโยบายวงจรชีวิตข้อมูลเพื่อลบหรือเก็บถาวรข้อมูลที่ไม่จำเป็นโดยอัตโนมัติ ใช้กฎวงจรชีวิต S3พร้อมวันหมดอายุเพื่อลบออบเจ็กต์หลังพ้นระยะเวลาเก็บรักษา ใช้ DynamoDB TTL เพื่อทำให้ระเบียนเก่าหมดอายุโดยอัตโนมัติ ใช้นโยบายการเก็บรักษา CloudWatch Logsเพื่อลบกลุ่มบันทึกหลังพ้นระยะเวลาที่กำหนด การลบข้อมูลที่ไม่จำเป็นช่วยลดทั้งต้นทุนพื้นที่จัดเก็บและพลังงานที่ใช้ในการจัดเก็บและระบายความร้อน
# DynamoDB TTL for session data
# Add ttl attribute to items (Unix epoch timestamp)
aws dynamodb update-time-to-live \
--table-name UserSessions \
--time-to-live-specification Enabled=true,AttributeName=expiresAt
# Item will be deleted automatically after expiresAt timestamp
# Example: {'userId': 'u1', 'expiresAt': 1750000000}
# CloudWatch Logs: set 30-day retention
aws logs put-retention-policy \
--log-group-name /aws/lambda/my-function \
--retention-in-days 30การเพิ่มประสิทธิภาพต้นทุนเทียบกับเสาหลักอื่น
บางครั้งการเพิ่มประสิทธิภาพต้นทุนขัดแย้งกับเสาหลักอื่น Multi-AZ RDSทำให้ต้นทุนฐานข้อมูลเพิ่มขึ้นเป็นสองเท่า แต่จำเป็นสำหรับเสาหลักด้านความน่าเชื่อถือ การจำลองแบบข้ามรีเจียนช่วยเพิ่มความน่าเชื่อถือ แต่เพิ่มต้นทุนพื้นที่จัดเก็บและการถ่ายโอนข้อมูล การทำงานแบบแอ็กทีฟ-แอ็กทีฟหลายรีเจียนช่วยลดเวลาแฝง (ประสิทธิภาพการทำงาน) แต่มีค่าใช้จ่ายสูงขึ้น 2-3 เท่า Well-Architected Framework ไม่ได้บอกให้เลือกตัวเลือกที่ถูกที่สุดเสมอไป แต่บอกให้ตัดสินใจแลกเปลี่ยนระหว่างเสาหลักต่าง ๆ อย่างมีสติและบันทึกเหตุผลไว้ ในการสอบจะทดสอบความสามารถของคุณในการเลือกโซลูชันที่คุ้มค่าที่สุดด้านต้นทุนและยังคงตรงตามข้อกำหนดที่ระบุ
# Cost vs reliability trade-off example:
# Single-AZ RDS: $100/month, no HA
# Multi-AZ RDS: $200/month, automated failover
# Decision: if database failure = $10,000/hour of revenue loss
# Even 1 event/year justifies Multi-AZ
# ($10,000 expected loss > $1,200/year extra cost)
# SAA-C03 exam approach:
# Meet the stated requirements FIRST
# Then choose the cheapest option that meets themตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า: การเพิ่มประสิทธิภาพต้นทุนประกอบด้วยการปรับขนาดให้เหมาะสม รูปแบบการจัดซื้อ (Reserved/Savings Plans/Spot) และการจัดการวงจรชีวิตของ S3, ความยั่งยืนมุ่งเน้นการใช้ทรัพยากรให้เกิดประโยชน์สูงสุด การใช้ Instance Graviton และการใช้นโยบายวงจรชีวิตข้อมูล และ ควรตัดสินใจแลกเปลี่ยนด้านต้นทุนกับเสาหลักอื่นอย่างมีสติ โดยอิงตามข้อกำหนดทางธุรกิจ แท็กต้นทุนช่วยให้สามารถทำ showback และ chargeback ระหว่างทีมได้ บทถัดไป เราจะสำรวจ Well-Architected Tool และกระบวนการตรวจทบทวน
คำถามที่พบบ่อย
บทเรียน “เสาหลักการเพิ่มประสิทธิภาพต้นทุนและความยั่งยืน” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “เสาหลักการเพิ่มประสิทธิภาพต้นทุนและความยั่งยืน” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “เสาหลักการเพิ่มประสิทธิภาพต้นทุนและความยั่งยืน”
ตระหนักถึงค่าใช้จ่าย เลือกขนาดทรัพยากรให้เหมาะสม และเลือกรูปแบบราคาเพื่อควบคุมต้นทุน ลดขนาดโครงสร้างพื้นฐาน และเพิ่มประสิทธิภาพการใช้พลังงานเพื่อความยั่งยืน คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน
บทเรียน “เสาหลักการเพิ่มประสิทธิภาพต้นทุนและความยั่งยืน” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม
ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- เสาหลักความเป็นเลิศด้านการดำเนินงานและความปลอดภัย
- เสาหลักความน่าเชื่อถือและประสิทธิภาพ
- เสาหลักการเพิ่มประสิทธิภาพต้นทุนและความยั่งยืน
- เครื่องมือ Well-Architected และกระบวนการทบทวน