บทที่ 10: Cost Optimization & Financial Governance
1. วัตถุประสงค์บท
หัวข้อที่มีชื่อว่า “1. วัตถุประสงค์บท”บทนี้เป็นเจ้าของ Cost Optimization pillar ใน Domain 3 (Continuous Improvement for Existing Solutions) โดยตรง และเป็นบทที่ต้องรวบทุกกลไกด้าน “การจ่ายเงินให้ AWS ให้ถูกที่สุดโดยไม่กระทบ requirement อื่น” เข้าด้วยกัน คำถามระดับ Professional ในโดเมนนี้แทบไม่เคยถามว่า “อะไรถูกที่สุด” แบบลอย ๆ แต่จะถาม most cost-effective solution ภายใต้ constraint อื่นเสมอ เช่น without impacting performance, for a steady-state workload running 24/7 for 3 years, for a fault-tolerant batch job, หรือ with the least operational overhead — keyword เหล่านี้ (เชื่อมโยงบทที่ 01 — keyword mapping) เป็นตัวชี้ว่าควรเลือก pricing model ใด และควรใช้ visibility/governance tool ใด
จุดที่ SA Pro ต่างจาก Associate คือไม่ใช่แค่รู้ว่า “Reserved Instance ลดราคา” หรือ “Spot ถูกกว่า On-Demand 90%” แต่คือการ ออกแบบ commitment portfolio ที่ผสม On-Demand + Savings Plans + RI + Spot ให้ครอบคลุม workload ที่มี usage pattern ต่างกัน, วางระบบ cost visibility และ chargeback ข้ามหลายร้อย account ใน organization, สร้าง guardrail เชิงการเงิน (Budgets actions, anomaly detection) ที่ป้องกันค่าใช้จ่ายวิ่งหนีก่อนสิ้นเดือน และ เลือกได้ว่าเมื่อไหร่ commitment คุ้ม เมื่อไหร่ไม่คุ้ม โดยชั่งความยืดหยุ่น (flexibility) กับส่วนลด (discount) เสมอ
บทก่อนหน้าฝาก cross-reference มายังบทนี้จำนวนมาก: บทที่ 01 ฝาก most cost-effective keyword และตัวอย่าง Spot batch; บทที่ 02 ฝาก consolidated billing เชิงลึก, RI/Savings Plans sharing ข้าม account, Cost Categories, cost allocation tag (บท 02 แตะเฉพาะมุม governance); บทที่ 05 ฝาก Spot strategy เชิงลึก (Spot Fleet/EC2 Fleet, capacity-optimized, interruption handling) และ Savings Plans สำหรับ Fargate/Lambda; บทที่ 06 ฝาก cost model เต็มของ storage (tiered pricing, request cost, egress/data transfer, S3 Storage Lens); บทที่ 07 ฝาก DynamoDB reserved capacity, Aurora I/O-Optimized, RDS Reserved Instances, Redshift RA3 TCO — จะครอบคลุมให้ครบที่นี่
เมื่อจบบทนี้คุณจะสามารถ:
- แยกและเลือก pricing models ทั้งหมด: On-Demand, Reserved Instances (Standard/Convertible, regional/zonal, payment options), Savings Plans (Compute/EC2 Instance/SageMaker), Spot
- สร้างกรอบตัดสินใจ Savings Plans vs RI โดยชั่ง flexibility กับ discount และรู้วิธี combine หลาย commitment
- ออกแบบ Spot strategy ที่ทนต่อ interruption: EC2 Fleet/Spot Fleet, capacity-optimized allocation, rebalance recommendation, workload ที่เหมาะ/ไม่เหมาะ
- วางระบบ cost visibility: Cost Explorer, Cost and Usage Report (CUR) + Athena/QuickSight, Cost Anomaly Detection, S3 Storage Lens
- ตั้ง financial guardrail: AWS Budgets (cost/usage/RI-SP coverage) + Budget Actions, billing alarms
- ออกแบบ cost governance ใน multi-account: cost allocation tags + Tag Policies, Cost Categories, consolidated billing (RI/SP sharing, volume tiering), chargeback/showback
- ทำ right-sizing ด้วย Compute Optimizer และ Trusted Advisor cost checks
ขอบเขต: performance tuning / observability → บทที่ 11 (บทนี้แตะ metric เฉพาะมุมต้นทุน); รายละเอียด storage class แต่ละตัว → บทที่ 06 (บทนี้อ้างอิงและต่อยอดเฉพาะ cost model); network connectivity เชิงสถาปัตยกรรม → บทที่ 04 (บทนี้พูดเฉพาะการลด data transfer cost)
2. แนวคิดหลัก
หัวข้อที่มีชื่อว่า “2. แนวคิดหลัก”2.1 เสาหลัก Cost Optimization 5 แกน (mental model)
หัวข้อที่มีชื่อว่า “2.1 เสาหลัก Cost Optimization 5 แกน (mental model)”AWS Well-Architected Cost Optimization pillar (บทที่ 01) วางหลักไว้ 5 ด้าน ใช้เป็นแกนตัด distractor:
| แกน | หลักการ | ตัวอย่างเครื่องมือในบทนี้ |
|---|---|---|
| Practice Cloud Financial Management | มีทีม/กระบวนการ FinOps, budget, chargeback | Budgets, Cost Categories, cost allocation tags |
| Expenditure & usage awareness | มองเห็นว่าใครใช้อะไรเท่าไร | Cost Explorer, CUR, Storage Lens, anomaly detection |
| Cost-effective resources | เลือก pricing model + right-size | Savings Plans, RI, Spot, Compute Optimizer |
| Manage demand & supply | จ่ายตามที่ใช้จริง, ปิดของที่ไม่ใช้ | Auto Scaling (บท 05), scheduling, serverless |
| Optimize over time | ทบทวนและ adopt ของใหม่ต่อเนื่อง | Trusted Advisor, right-sizing recommendation |
หลักการออกสอบ: โจทย์ cost มักไม่ได้มีคำตอบเดียว — ต้องดูว่า workload มี usage pattern แบบใด (steady-state / spiky / fault-tolerant / unpredictable) แล้ว map ไป pricing model ที่ตรง อย่ารีบเลือก “ถูกสุด” โดยไม่ดู constraint (เช่น Spot ถูกสุดแต่ห้ามใช้กับ workload ที่ทน interruption ไม่ได้)
2.2 Pricing models: ภาพรวมและ trade-off
หัวข้อที่มีชื่อว่า “2.2 Pricing models: ภาพรวมและ trade-off”EC2 compute มี pricing model 4 กลุ่มหลัก เรียงตามส่วนลดและความผูกมัด:
| Model | ส่วนลดเทียบ On-Demand | ความผูกมัด | ความยืดหยุ่น | เหมาะกับ |
|---|---|---|---|---|
| On-Demand | 0% (ราคาเต็ม) | ไม่มี | สูงสุด | workload สั้น/คาดเดาไม่ได้/dev-test/spiky ครั้งแรก |
| Savings Plans | สูงสุด ~72% [uncertain ตัวเลขปัจจุบัน] | 1 หรือ 3 ปี, commit เป็น $/ชม. | สูง (Compute SP ครอบทุก region/family/OS/tenancy + Fargate + Lambda) | steady-state ที่อยากได้ทั้งส่วนลดและความยืดหยุ่น |
| Reserved Instances | สูงสุด ~72% [uncertain] | 1 หรือ 3 ปี, commit เป็น instance attribute | ต่ำกว่า SP (ผูก family/region; Convertible แลกได้) | steady-state ที่ต้องการ capacity reservation (zonal RI) |
| Spot | สูงสุด ~90% | ไม่มี commit แต่ถูก reclaim ได้ (2-min notice) | ต้อง architect ให้ทน interruption | fault-tolerant/stateless/batch/CI/big data |
หลักคิดกลาง: commitment (SP/RI) แลกส่วนลดด้วยความผูกมัดระยะยาว, Spot แลกส่วนลดด้วยความไม่แน่นอนของ capacity, On-Demand จ่ายแพงเพื่อความยืดหยุ่นเต็มที่ โดยทั่วไป production ที่ดีจะ layer กัน: ใช้ Savings Plans/RI คลุม baseline ที่รันตลอด, ใช้ Spot รับ burst ที่ fault-tolerant, และเหลือ On-Demand เป็น buffer
2.3 Reserved Instances เชิงลึก
หัวข้อที่มีชื่อว่า “2.3 Reserved Instances เชิงลึก”RI ไม่ใช่ “เครื่องที่จอง” แต่เป็น billing discount ที่ apply กับ instance usage ที่ตรง attribute โดยอัตโนมัติ (ยกเว้น zonal RI ที่ให้ capacity reservation ด้วย) มีมิติที่ต้องแยก:
Standard vs Convertible RI:
| Standard RI | Convertible RI | |
|---|---|---|
| ส่วนลด | สูงกว่า | ต่ำกว่าเล็กน้อย |
| แลกเปลี่ยน (exchange) | ทำไม่ได้ (เปลี่ยนได้แค่บาง attribute เช่น AZ/size ใน family เดิม) | แลกเป็น family/OS/tenancy อื่นได้ (มูลค่าเท่ากันหรือมากกว่า) |
| ขายใน Marketplace | ได้ | ไม่ได้ |
| เหมาะกับ | workload นิ่งมาก รู้แน่ว่าใช้ instance family นี้ 3 ปี | workload ที่อาจเปลี่ยน family (เช่นย้ายไป Graviton ในอนาคต) |
Regional vs Zonal RI:
| Regional RI | Zonal RI | |
|---|---|---|
| ขอบเขต | ทั้ง region (ทุก AZ) | AZ เดียวที่ระบุ |
| Capacity reservation | ไม่มี (แค่ billing discount) | มี (การันตี capacity ใน AZ นั้น) |
| Instance size flexibility | มี (normalize ตาม size ภายใน family เดียว/OS Linux) | ไม่มี |
| AZ flexibility | มี (ใช้ AZ ไหนก็ได้) | ผูก AZ เดียว |
Payment options (ยิ่งจ่ายล่วงหน้ามากยิ่งลดมาก): All Upfront (ลดมากสุด) > Partial Upfront > No Upfront (ลดน้อยสุดแต่ไม่ต้องวางเงินก้อน)
จุดออกสอบ: ถ้าโจทย์ต้องการ guarantee capacity ใน AZ เฉพาะ (เช่น critical workload ที่ต้อง launch ได้แน่นอนแม้ช่วง peak) ต้องใช้ zonal RI หรือ On-Demand Capacity Reservation (ODCR) — Savings Plans และ regional RI ไม่การันตี capacity ให้ นี่คือเหตุผลเดียวที่ยังต้องเลือก RI แทน Savings Plans
2.4 Savings Plans เชิงลึก และการเทียบกับ RI
หัวข้อที่มีชื่อว่า “2.4 Savings Plans เชิงลึก และการเทียบกับ RI”Savings Plans (SP) เป็น commitment แบบ $ ต่อชั่วโมง ที่ยืดหยุ่นกว่า RI มี 3 ชนิด:
| ชนิด Savings Plan | ครอบคลุม | ความยืดหยุ่น | ส่วนลด |
|---|---|---|---|
| Compute Savings Plans | EC2 (ทุก family/region/size/OS/tenancy) + AWS Fargate + AWS Lambda | สูงสุด — ย้าย region/family/บริการได้อิสระ | ต่ำกว่า EC2 Instance SP เล็กน้อย |
| EC2 Instance Savings Plans | EC2 family เดียวใน region เดียว (เปลี่ยน size/OS/AZ/tenancy ได้) | กลาง — ผูก family+region | สูงกว่า Compute SP (ใกล้เคียง Standard RI) |
| SageMaker Savings Plans | Amazon SageMaker instance usage | เฉพาะ SageMaker | — |
กรอบตัดสินใจ Savings Plans vs RI (จุดที่ออกสอบบ่อยมาก):
- อยากได้ ความยืดหยุ่นสูงสุด + ครอบ Fargate/Lambda → Compute Savings Plans (คำตอบ default สำหรับ modern/container/serverless workload)
- อยากได้ ส่วนลดสูงใกล้ RI แต่ยังยืดหยุ่น size/OS ภายใน family เดียว → EC2 Instance Savings Plans
- ต้องการ capacity reservation → ต้องเป็น zonal RI (SP ทำไม่ได้)
- ใช้บริการที่ SP ไม่ครอบ เช่น RDS, Redshift, ElastiCache, OpenSearch → ต้องใช้ Reserved Instances/Reserved Nodes ของบริการนั้น (Savings Plans ไม่ครอบ database — จุดหลอกสำคัญ)
เชื่อมโยงบทที่ 07: RDS Reserved Instances, Redshift Reserved Nodes, ElastiCache Reserved Nodes, OpenSearch Reserved Instances เป็น commitment แยกของแต่ละบริการ — Savings Plans ไม่ครอบ. ส่วน DynamoDB มี reserved capacity (สำหรับ provisioned mode) และ Aurora มี I/O-Optimized configuration ที่เหมาะเมื่อ I/O cost เกิน ~25% ของ bill
การ combine: AWS apply ส่วนลดตามลำดับ — RI/zonal reservation ก่อน (specific สุด) → Savings Plans เติมส่วนที่เหลือ → ที่เหลือคิด On-Demand จึงไม่มี “double discount” และควร commit เฉพาะ baseline ที่มั่นใจ (เช่น p10–p25 ของ usage) แล้วปล่อย variable ส่วนบนเป็น On-Demand/Spot
2.5 Spot Instances และ interruption handling เชิงลึก
หัวข้อที่มีชื่อว่า “2.5 Spot Instances และ interruption handling เชิงลึก”เชื่อมโยงบทที่ 05 — mixed instances policy, capacity provider (Fargate Spot). บทนี้ลงลึกกลไก Spot เอง
Spot ให้ราคาถูกสุดโดยใช้ spare capacity ที่ AWS reclaim คืนได้เมื่อต้องการ กลไกสำคัญ:
- 2-minute interruption notice: AWS ส่งสัญญาณผ่าน instance metadata (
/latest/meta-data/spot/instance-action) และ EventBridge event ก่อน reclaim 2 นาที — application ต้อง checkpoint/drain ในช่วงนี้ - EC2 Rebalance Recommendation: สัญญาณ เตือนล่วงหน้าเร็วกว่า 2-min notice ว่า instance นี้มีความเสี่ยงสูงจะถูก interrupt เร็ว ๆ นี้ ใช้ให้ ASG proactively launch replacement ก่อน
- Interruption behavior: terminate (default), stop, หรือ hibernate
Allocation strategies (สำคัญมากในข้อสอบ):
| Strategy | พฤติกรรม | เหมาะกับ |
|---|---|---|
| capacity-optimized | เลือก pool ที่มี capacity เหลือมากสุด (โอกาสถูก interrupt ต่ำสุด) | production ที่อยาก ลด interruption — คำตอบ default ปัจจุบัน |
| capacity-optimized-prioritized | เหมือน capacity-optimized แต่เคารพลำดับ priority ที่กำหนด | อยากลด interruption แต่มี preference instance type |
| lowest-price | เลือก pool ที่ราคาถูกสุด | batch สั้น ๆ ที่ interruption ไม่เจ็บ (เสี่ยงถูก interrupt มากกว่า) |
| price-capacity-optimized | ชั่งทั้งราคาและ capacity | balance — มักเป็นคำแนะนำใหม่สุด [uncertain ชื่อ/สถานะ] |
EC2 Fleet vs Spot Fleet: ทั้งคู่ provision instance ข้ามหลาย instance type/AZ (Spot pool หลายอัน) เพื่อกระจายความเสี่ยง — ยิ่ง diversify มาก pool ยิ่งลด interruption impact EC2 Fleet เป็นรุ่นใหม่กว่า รวม On-Demand + Spot ใน request เดียว, Spot Fleet เป็นรุ่นเดิม ปัจจุบันแนะนำใช้ผ่าน ASG mixed instances policy (บท 05) มากกว่าเรียก Fleet API ตรง เพราะ ASG จัดการ rebalance/replacement ให้อัตโนมัติ (least operational overhead)
Workload ที่เหมาะ Spot: stateless web tier หลัง LB, containerized task (ECS/EKS + Fargate Spot), CI/CD runner, big data (EMR task node), rendering, ML training ที่ checkpoint ได้ ไม่เหมาะ: single stateful DB, workload ที่ interruption แล้วสูญเสียงานทั้งหมด, license-bound instance ที่ boot ช้ามาก
2.6 Cost Visibility Stack
หัวข้อที่มีชื่อว่า “2.6 Cost Visibility Stack”การจะ optimize ได้ต้องเห็นก่อน — AWS มี visibility tool หลายชั้นที่ต้องแยกบทบาท:
| เครื่องมือ | ระดับ | ใช้ทำอะไร | granularity |
|---|---|---|---|
| AWS Cost Explorer | UI/API สำเร็จรูป | ดู trend, filter/group ตาม service/tag/account, RI/SP utilization & coverage report, forecast, right-sizing recommendation | รายวัน (หรือรายชั่วโมง/resource ถ้าเปิด) |
| Cost and Usage Report (CUR) | ไฟล์ดิบละเอียดสุด | line-item ทุก resource ต่อชั่วโมง ส่งเข้า S3 → query ด้วย Athena / visualize ด้วย QuickSight | รายชั่วโมง/รายresource, ทุก field |
| Cost Anomaly Detection | ML alerting | ตรวจจับ spike ผิดปกติด้วย ML แล้วแจ้งเตือน (per service/account/tag monitor) | near-real-time |
| AWS Budgets | guardrail | ตั้งเพดาน cost/usage/RI-SP coverage + trigger action | รายวัน/เดือน |
| S3 Storage Lens | storage analytics | มองเห็น usage/activity ของ S3 ทั้ง org, ชี้ bucket ที่ควร lifecycle/ลด cost (บท 06) | ระดับ bucket/prefix |
| Trusted Advisor | best-practice check | idle/underutilized resource, unassociated EIP, low-util RI | on-demand check |
| Compute Optimizer | ML right-sizing | แนะนำ instance/volume/Lambda memory ที่เหมาะกว่า (over/under-provisioned) | per resource |
หลักการเลือก: อยาก สำรวจ/รายงานเร็ว ๆ ระดับ dashboard → Cost Explorer (least ops); ต้องการ วิเคราะห์เชิงลึก/custom report/allocation ที่ Cost Explorer ทำไม่ได้ (เช่น amortized cost ต่อ team ต่อ feature) → CUR + Athena + QuickSight; อยาก ถูกเตือนเมื่อค่าใช้จ่ายผิดปกติ โดยไม่ต้องตั้ง threshold เอง → Cost Anomaly Detection (ML); อยาก หยุด/เตือนเมื่อถึงเพดาน → Budgets + actions
2.7 AWS Budgets และ financial guardrails
หัวข้อที่มีชื่อว่า “2.7 AWS Budgets และ financial guardrails”AWS Budgets ตั้งได้หลายชนิด:
- Cost budget — เพดานค่าใช้จ่าย ($) ต่อเดือน/ไตรมาส/ปี
- Usage budget — เพดานปริมาณ (เช่น GB, hours)
- RI/Savings Plans utilization budget — เตือนเมื่อ utilization ของ commitment ต่ำกว่าเป้า (กันซื้อ RI แล้วใช้ไม่คุ้ม)
- RI/Savings Plans coverage budget — เตือนเมื่อ % ของ usage ที่ถูกคลุมด้วย commitment ต่ำกว่าเป้า (ชี้ว่าควรซื้อเพิ่ม)
Budget Actions คือส่วนที่ยกระดับจาก “เตือน” เป็น “บังคับ”: เมื่อถึง threshold สามารถ trigger อัตโนมัติ เช่น apply restrictive IAM/SCP policy (deny การ launch resource เพิ่ม), stop EC2/RDS instance, หรือส่ง SNS/แจ้งทีม — เป็น preventive control เชิงการเงินที่ตรงกับ prevent runaway cost (เชื่อมโยงบทที่ 02 — SCP เป็น guardrail)
Billing alarm แบบเดิม: CloudWatch billing metric (EstimatedCharges ใน us-east-1) + alarm → SNS ยังใช้ได้ แต่ Budgets ครอบคลุมกว่าและ granular กว่า จึงเป็นคำตอบที่นิยมกว่าในโจทย์สมัยใหม่
2.8 Cost Governance ใน Multi-Account
หัวข้อที่มีชื่อว่า “2.8 Cost Governance ใน Multi-Account”เชื่อมโยงบทที่ 02 — consolidated billing, cost allocation tag, Tag Policies. บทนี้ต่อยอดมุมการเงิน
Consolidated billing (จาก management/payer account) ให้ประโยชน์ 3 อย่างที่ออกสอบ:
- RI & Savings Plans sharing — commitment ที่ซื้อใน account ใดจะถูกแชร์ apply ให้ทุก account ใน organization โดยอัตโนมัติ (เปิด/ปิด sharing ต่อ account ได้จาก payer) ทำให้ไม่ต้องซื้อ RI แยกทุก account และเพิ่ม utilization
- Volume discount tiering — usage รวมทุก account มา tier เดียวกัน (เช่น S3, data transfer ที่ราคาลดตามปริมาณ) จึงได้ราคาต่อหน่วยถูกลงเมื่อรวมกัน
- จ่ายบิลเดียว — payer จ่ายรวม แต่แยกดูต่อ account ได้
Cost allocation tags — key สำหรับ chargeback/showback:
| ประเภท tag | ตัวอย่าง | ต้องทำอะไร |
|---|---|---|
| AWS-generated tags | aws:createdBy, aws:cloudformation:stack-name |
AWS ใส่ให้ ต้อง activate ใน Billing console |
| User-defined tags | CostCenter, Project, Environment, Team |
ผู้ใช้ใส่เอง ต้อง activate ใน Billing console ก่อนจึงจะ group ใน Cost Explorer/CUR ได้ |
การ enforce ให้ทุก resource มี tag ต้องใช้กลไกจากบทที่ 02: Tag Policies (detective — รายงาน non-compliant) ร่วมกับ SCP ที่ deny การสร้าง resource ที่ไม่มี tag key ที่กำหนด (aws:RequestTag / aws:TagKeys condition) — Tag Policy อย่างเดียว ไม่บล็อก การสร้าง
Cost Categories — กฎ (rule-based) ที่จัดกลุ่ม cost ให้ตรงโครงสร้างธุรกิจ (เช่น map หลาย account + tag → “Business Unit A”) เพื่อทำ showback ตามหน่วยงานจริง แม้ tag ไม่สมบูรณ์ ใช้ใน Cost Explorer/Budgets/CUR ได้
Chargeback vs Showback: chargeback = คิดเงินแต่ละทีม/BU จริงตาม usage; showback = แสดงให้เห็นว่าใครใช้เท่าไร (โปร่งใส) แต่ยังไม่คิดเงินจริง — ทั้งคู่พึ่ง tag/Cost Categories/CUR เป็นฐานข้อมูล
2.9 Right-sizing และการลด cost เชิงสถาปัตยกรรม
หัวข้อที่มีชื่อว่า “2.9 Right-sizing และการลด cost เชิงสถาปัตยกรรม”- AWS Compute Optimizer — ใช้ ML วิเคราะห์ CloudWatch metric แนะนำ EC2 instance type, ASG config, EBS volume, Lambda memory ที่เหมาะกว่า (ชี้ over-provisioned → ประหยัด, under-provisioned → performance เชื่อมโยงบท 11) เปิดใช้ฟรี, อ่าน metric ที่มีอยู่
- Trusted Advisor cost checks — idle load balancer, low-utilization EC2, unassociated Elastic IP, underutilized RI/redshift, idle RDS (ต้อง Business/Enterprise Support สำหรับ check ครบ)
- ลด data transfer cost (เชื่อมโยงบทที่ 04/06): data-out สู่ internet และ cross-AZ transfer เป็นต้นทุนซ่อน — ลดด้วย gateway endpoint สำหรับ S3/DynamoDB (ฟรี, ไม่ผ่าน NAT/internet), CloudFront ลด egress (ราคา data-out ถูกกว่า + caching ลด origin fetch), ออกแบบให้ traffic อยู่ใน AZ เดียวกันเมื่อทำได้, และหลีกเลี่ยง NAT Gateway processing cost ด้วย VPC endpoint
- ลด storage cost (เชื่อมโยงบทที่ 06): S3 lifecycle → Glacier/Deep Archive, S3 Intelligent-Tiering เมื่อ access pattern ไม่แน่นอน, ลบ incomplete multipart upload, EBS gp3 แทน gp2 (~20% ถูกกว่า), ลบ snapshot/EBS ที่ไม่ใช้, EBS/S3 minimum duration awareness
3. ตารางเปรียบเทียบบริการ
หัวข้อที่มีชื่อว่า “3. ตารางเปรียบเทียบบริการ”3.1 requirement/keyword → pricing model → เหตุผล
หัวข้อที่มีชื่อว่า “3.1 requirement/keyword → pricing model → เหตุผล”| requirement / keyword ในโจทย์ | เลือก | เหตุผล / trade-off |
|---|---|---|
| steady-state 24/7, 3-year commitment, ครอบ Fargate/Lambda ด้วย | Compute Savings Plans | ยืดหยุ่นสูงสุด ครอบทุก region/family + serverless; ส่วนลดต่ำกว่า EC2 SP นิดหน่อย |
| steady-state, family เดียว region เดียว, อยากส่วนลดสูงสุด แต่ยังยืดหยุ่น size | EC2 Instance Savings Plans | ส่วนลดใกล้ Standard RI + ยืดหยุ่น size/OS ใน family |
| ต้อง guarantee capacity ใน AZ เฉพาะ | Zonal Reserved Instance หรือ ODCR | เท่านั้นที่ให้ capacity reservation; SP/regional RI ไม่ให้ |
| อาจเปลี่ยน instance family ในอนาคต (เช่นย้าย Graviton) | Convertible RI หรือ Compute SP | แลก/ครอบ family อื่นได้ |
| fault-tolerant batch / CI / stateless, most cost-effective | Spot (ASG mixed + capacity-optimized) | ถูกสุด ~90%; ต้องทน interruption |
| unpredictable / short-lived / dev-test / spiky ครั้งแรก | On-Demand | ไม่มี commit; จ่ายแพงแลกความยืดหยุ่น |
| RDS / Redshift / ElastiCache steady-state | Reserved Instances/Nodes ของบริการนั้น | Savings Plans ไม่ครอบ database |
| baseline + burst ผสมกัน | SP/RI คลุม baseline + Spot รับ burst + On-Demand buffer | layered commitment — คุ้มสุดในโลกจริง |
3.2 requirement → visibility/governance tool → เหตุผล
หัวข้อที่มีชื่อว่า “3.2 requirement → visibility/governance tool → เหตุผล”| requirement / keyword | เลือก | เหตุผล / trade-off |
|---|---|---|
| ดู trend / forecast / RI-SP utilization เร็ว ๆ ระดับ dashboard | Cost Explorer | สำเร็จรูป least ops; granularity จำกัดกว่า CUR |
| custom cost analysis / amortized cost ต่อ team / query เอง | CUR + Athena + QuickSight | ละเอียดสุดทุก line-item; ต้อง setup + query เอง |
| detect abnormal cost spike โดยไม่ตั้ง threshold เอง | Cost Anomaly Detection | ML-based; แจ้งอัตโนมัติ |
| prevent/หยุด cost เมื่อถึงเพดาน (dev account) | Budgets + Budget Actions | apply restrictive policy/stop resource อัตโนมัติ |
| เตือนเมื่อ RI/SP coverage ต่ำ (ควรซื้อเพิ่ม) | RI/SP coverage budget | ชี้ under-commitment |
| แนะนำ instance/volume/Lambda memory ที่เหมาะ | Compute Optimizer | ML right-sizing; อ่าน metric ที่มีอยู่ |
| หา idle resource / unassociated EIP / low-util RI | Trusted Advisor cost checks | best-practice check (ต้อง Business+ Support) |
| มองเห็นและ optimize S3 usage ทั้ง org | S3 Storage Lens | storage analytics ระดับ org/bucket/prefix (บท 06) |
| chargeback ตาม business unit แม้ tag ไม่สมบูรณ์ | Cost Categories | rule-based grouping เหนือ tag/account |
3.3 Savings Plans vs Reserved Instances (ตารางตัดสินใจ)
หัวข้อที่มีชื่อว่า “3.3 Savings Plans vs Reserved Instances (ตารางตัดสินใจ)”| มิติ | Compute SP | EC2 Instance SP | Standard RI | Convertible RI |
|---|---|---|---|---|
| ครอบ Fargate/Lambda | ✅ | ❌ | ❌ | ❌ |
| ครอบทุก region/family | ✅ | ❌ (family+region เดียว) | ❌ | ❌ |
| Capacity reservation | ❌ | ❌ | ✅ เฉพาะ zonal | ✅ เฉพาะ zonal |
| แลก/เปลี่ยน family | (ยืดหยุ่นโดยธรรมชาติ) | ❌ | ❌ | ✅ exchange |
| ขาย Marketplace | ❌ | ❌ | ✅ | ❌ |
| ส่วนลดสัมพัทธ์ | กลาง | สูง | สูงสุด | กลาง-สูง |
| ความยืดหยุ่น | สูงสุด | กลาง | ต่ำ | กลาง |
4. สถาปัตยกรรมตัวอย่างและ trade-off
หัวข้อที่มีชื่อว่า “4. สถาปัตยกรรมตัวอย่างและ trade-off”4.1 Layered commitment portfolio สำหรับ enterprise หลาย account
หัวข้อที่มีชื่อว่า “4.1 Layered commitment portfolio สำหรับ enterprise หลาย account”โจทย์: องค์กรมี 40 account ใน AWS Organizations, workload ผสมทั้ง production steady-state (EC2 + Fargate + RDS), batch fault-tolerant, และ dev-test ต้องการลด compute cost ให้มากที่สุดโดยไม่กระทบ production availability
สถาปัตยกรรม:
- management (payer) account: ซื้อ Compute Savings Plans คลุม baseline ของทั้ง org (คำนวณจาก p20–p25 ของ usage ต่อชั่วโมงจาก Cost Explorer) — เปิด RI/SP sharing ให้ discount ไหลข้าม account
- RDS/ElastiCache steady-state: ซื้อ Reserved Instances ของบริการนั้น แยก (SP ไม่ครอบ)
- production compute ส่วน burst: ASG mixed instances policy — On-Demand base + Spot ด้วย capacity-optimized (บท 05)
- batch/CI: Spot เต็ม (lowest-price หรือ price-capacity-optimized)
- dev-test account: On-Demand + Budget Actions ที่ stop instance นอกเวลางาน + scheduled scaling
- cost governance: cost allocation tag (
CostCenter,Project) + Tag Policy + SCP บังคับ tag; Cost Categories map เป็น BU; CUR → Athena → QuickSight สำหรับ chargeback รายเดือน
Trade-off: ได้ประโยชน์คือ commitment ถูก apply แบบ org-wide (utilization สูง), production ไม่กระทบเพราะ Spot อยู่เฉพาะ tier ที่ fault-tolerant, และ dev-test ไม่วิ่งค่าใช้จ่ายหนี แลกกับความซับซ้อนในการบริหาร portfolio (ต้องมี FinOps review ต่อเนื่อง) และความเสี่ยง over-commit ถ้า usage ลดลงกว่าที่ commit — จึง commit เฉพาะ baseline ที่มั่นใจ ไม่ commit 100%
ทำไมไม่เลือกทางอื่น: ซื้อ Standard RI คลุมทั้งหมดจะได้ส่วนลดสูงกว่านิดหน่อยแต่ ผูก family/region ทำให้ modernization (ย้าย Graviton/Fargate) ติดขัด; ใช้ On-Demand ล้วนแพงเกิน; ใช้ Spot ล้วนกับ production เสี่ยง availability
4.2 Financial guardrail สำหรับ sandbox/dev accounts
หัวข้อที่มีชื่อว่า “4.2 Financial guardrail สำหรับ sandbox/dev accounts”โจทย์: ทีม developer มี sandbox account จำนวนมาก เคยมีเหตุ resource ถูกลืมเปิดค้างจน bill พุ่ง ต้องการ prevent runaway cost โดยอัตโนมัติและ least operational overhead
สถาปัตยกรรม:
- AWS Budgets ต่อ account (deploy ผ่าน Control Tower/StackSets จากบท 02) ตั้ง cost budget รายเดือน
- Budget Actions: ที่ 80% ส่ง SNS เตือนทีม; ที่ 100% apply SCP/IAM deny policy บล็อกการ launch resource ใหม่ (
ec2:RunInstances,rds:CreateDBInstance) - Cost Anomaly Detection ต่อ account แจ้ง spike ผิดปกติทันที
- Instance Scheduler / EventBridge Scheduler ปิด non-prod นอกเวลางาน
- SCP จำกัด instance type/region ที่ sandbox ใช้ได้ (กัน launch เครื่องแพง)
Trade-off: guardrail อัตโนมัติป้องกัน bill shock โดยไม่ต้องมีคนคอยเฝ้า แลกกับความเสี่ยงที่ Budget Action deny อาจบล็อกงานที่ถูกต้องชั่วคราว (แก้ด้วย threshold หลายชั้น + exception role) และ SCP ที่เข้มเกินอาจขวาง experimentation — จึงใช้เฉพาะ sandbox/dev ไม่ใช้กับ production
ทำไมไม่เลือกทางอื่น: billing alarm (CloudWatch) อย่างเดียวแค่เตือน ไม่หยุดค่าใช้จ่าย; ให้คนคอยดู Cost Explorer manual มี operational overhead สูงและช้าเกินไป
4.3 Chargeback ข้าม organization ด้วย CUR
หัวข้อที่มีชื่อว่า “4.3 Chargeback ข้าม organization ด้วย CUR”โจทย์: บริษัทมีหลาย business unit แชร์ platform เดียว ต้องการคิดเงินคืนแต่ละ BU ตาม usage จริง รวมถึง amortized cost ของ Savings Plans/RI และแยก shared cost (เช่น TGW, log) ให้เป็นธรรม
สถาปัตยกรรม:
- เปิด Cost and Usage Report (CUR) ที่ payer account ส่งเข้า S3 (มี resource-level + amortized cost columns)
- Athena query CUR ต่อ tag/account/Cost Category; QuickSight dashboard ต่อ BU
- Cost Categories map account+tag → BU และแยก shared service cost ด้วย split charge rule
- cost allocation tag บังคับผ่าน Tag Policy + SCP; AWS-generated tag activate เพิ่ม
- amortized view เพื่อกระจายค่า upfront ของ RI/SP ตามการใช้จริงรายเดือน (ไม่ให้เดือนที่ซื้อกระโดด)
Trade-off: CUR ให้ความละเอียดและความยืดหยุ่นสูงสุดในการ allocate ทุก line-item แลกกับ operational overhead ในการ build/maintain pipeline (Athena/QuickSight, schema เปลี่ยนเมื่อ AWS เพิ่ม field) — เหมาะเมื่อ Cost Explorer grouping ไม่ละเอียดพอ ถ้าองค์กรเล็ก Cost Explorer + Cost Categories ก็พอ (least ops)
ทำไมไม่เลือกทางอื่น: Cost Explorer อย่างเดียวทำ amortized ต่อ BU แบบ custom split ไม่ได้ครบ; แบ่งบิลด้วยมือจาก invoice ไม่ scale และผิดพลาดง่าย
5. ข้อผิดพลาดที่พบบ่อยในข้อสอบ
หัวข้อที่มีชื่อว่า “5. ข้อผิดพลาดที่พบบ่อยในข้อสอบ”- คิดว่า Savings Plans ครอบ RDS/Redshift/ElastiCache — ไม่ครอบ ต้องใช้ Reserved Instances/Nodes ของบริการนั้นแยก Savings Plans ครอบเฉพาะ EC2 + Fargate + Lambda (Compute SP) และ SageMaker
- สับสนว่า Savings Plans/regional RI การันตี capacity — ไม่การันตี เป็นแค่ billing discount; ต้องการ capacity reservation ต้อง zonal RI หรือ ODCR
- เลือก Spot กับ workload ที่ทน interruption ไม่ได้ — Spot เหมาะเฉพาะ fault-tolerant/stateless; single stateful DB หรืองานที่ interruption แล้วเสียหายทั้งหมดห้ามใช้
- เลือก lowest-price allocation ทั้งที่โจทย์ต้องการลด interruption — production ควร capacity-optimized; lowest-price เพิ่มความเสี่ยงถูก reclaim
- เลือก Convertible RI ทั้งที่ workload นิ่งและต้องส่วนลดสูงสุด — Standard RI ให้ส่วนลดสูงกว่า; Convertible เหมาะเฉพาะเมื่อคาดว่าจะเปลี่ยน family
- ใช้ billing alarm ทั้งที่โจทย์ต้องการหยุดค่าใช้จ่ายอัตโนมัติ — alarm แค่เตือน; ต้อง Budgets + Budget Actions จึงจะ apply policy/stop resource
- คิดว่า Tag Policy บังคับให้ต้องมี tag ตอนสร้าง — Tag Policy เป็น detective (รายงาน/มาตรฐาน format); การ บล็อก ต้องใช้ SCP +
aws:RequestTagcondition (เชื่อมโยงบทที่ 02) - ลืม activate cost allocation tag — user-defined/AWS-generated tag ต้อง activate ใน Billing console ก่อน จึงจะ group ใน Cost Explorer/CUR ได้ ไม่ใช่แค่ tag resource ก็พอ
- เลือก Cost Explorer ทั้งที่ต้องการ custom line-item analysis / amortized ต่อ team — งานนั้นต้อง CUR + Athena + QuickSight; Cost Explorer เป็น dashboard สำเร็จรูป granularity จำกัด
- มองข้าม RI/SP sharing ผ่าน consolidated billing — commitment ที่ซื้อ account เดียวแชร์ทั้ง org ได้ ไม่ต้องซื้อแยกทุก account (เชื่อมโยงบทที่ 02)
- สับสน Cost Anomaly Detection กับ Budgets — anomaly detection ใช้ ML ตรวจ spike ผิดปกติ (ไม่ต้องตั้ง threshold); Budgets เป็นเพดานที่ตั้งเอง + action
- ลืมว่า Compute Optimizer/Trusted Advisor ทำ right-sizing — โจทย์ reduce cost of over-provisioned instances → Compute Optimizer (ML) หรือ Trusted Advisor ไม่ใช่ซื้อ RI (RI ลดราคาต่อหน่วย ไม่แก้ over-provisioning)
- commit 100% ของ usage — ควร commit เฉพาะ baseline ที่มั่นใจ (p20–p25) เผื่อ usage ลดลง มิฉะนั้น over-commit จ่ายเปล่า
- มองข้าม data transfer/egress เป็นต้นทุน — cross-AZ, NAT processing, data-out เป็นต้นทุนซ่อน; ลดด้วย gateway endpoint (ฟรี)/CloudFront (เชื่อมโยงบท 04/06)
6. คำถามทบทวน
หัวข้อที่มีชื่อว่า “6. คำถามทบทวน”ข้อ 1. workload production รัน EC2 ตลอด 24/7 บวก AWS Fargate task และ AWS Lambda จำนวนมาก องค์กรวางแผนใช้ต่อเนื่อง 3 ปี และอาจย้ายบาง service ข้าม region ในอนาคต ต้องการส่วนลดสูงและยืดหยุ่นสุด ควรเลือกอะไร
เฉลย
Compute Savings Plans (3-year) — ครอบ EC2 ทุก region/family + Fargate + Lambda และยืดหยุ่นย้าย region/family ได้
- EC2 Instance Savings Plans ผิด — ผูก family+region เดียว และไม่ครอบ Fargate/Lambda
- Standard RI ผิด — ผูก family/region ไม่ยืดหยุ่น และไม่ครอบ serverless
- Spot ผิด — production 24/7 ต้องการความแน่นอน ไม่ใช่ capacity ที่ถูก reclaim ได้
ข้อ 2. ทีมมี batch processing job ที่ stateless, checkpoint ได้, และทนการหยุดกลางคันได้ ต้องการต้นทุน most cost-effective พร้อมลดโอกาสถูก interrupt ให้น้อยที่สุด ควรออกแบบอย่างไร
เฉลย
Spot Instances ผ่าน ASG/EC2 Fleet ด้วย allocation strategy = capacity-optimized กระจายหลาย instance type/AZ
- lowest-price allocation ผิด — ถูกกว่าเล็กน้อยแต่เพิ่มโอกาสถูก interrupt โจทย์ระบุอยากลด interruption
- On-Demand ผิด — แพงกว่ามาก โดยไม่จำเป็นเพราะ workload ทน interruption ได้
- Reserved Instances ผิด — batch ที่ไม่รันตลอดไม่คุ้ม commit และไม่ได้ถูกเท่า Spot
ข้อ 3. critical application ต้อง launch instance ได้แน่นอนใน AZ เฉพาะแม้ช่วง peak demand ของ region และต้องการส่วนลดจากการ commit ระยะยาว ควรเลือกอะไร
เฉลย
Zonal Reserved Instance — ให้ทั้งส่วนลดและ capacity reservation ใน AZ ที่ระบุ (หรือใช้ ODCR + Savings Plans ถ้าต้องการยืดหยุ่น)
- Regional RI ผิด — ให้ส่วนลดแต่ ไม่การันตี capacity ใน AZ เฉพาะ
- Compute Savings Plans ผิด — ยืดหยุ่นแต่ไม่ให้ capacity reservation เลย
- On-Demand ผิด — ไม่มีส่วนลดจาก commitment
ข้อ 4. organization มี 30 account ต้องการ prevent ค่าใช้จ่ายวิ่งหนีใน dev account โดยอัตโนมัติเมื่อถึงเพดาน โดยไม่ต้องมีคนคอยเฝ้า ควรใช้อะไร
เฉลย
AWS Budgets + Budget Actions — ตั้ง cost budget แล้วให้ action apply restrictive SCP/IAM policy (deny launch) หรือ stop resource เมื่อถึง threshold
- CloudWatch billing alarm ผิด — แค่เตือน ไม่หยุดค่าใช้จ่าย
- Cost Anomaly Detection ผิด — ตรวจ spike ผิดปกติและแจ้งเตือน ไม่ enforce เพดาน
- ให้ทีมดู Cost Explorer ทุกวัน ผิด — operational overhead สูงและช้าเกินป้องกัน
ข้อ 5. ต้องการ chargeback ต่อ business unit โดยแยก amortized cost ของ RI/SP และ split shared service cost (TGW, logging) อย่างละเอียดในระดับ line-item ควรใช้อะไร
เฉลย
Cost and Usage Report (CUR) → Athena → QuickSight ร่วมกับ Cost Categories (split charge rules) และ cost allocation tags
- Cost Explorer อย่างเดียว ผิด — granularity/custom allocation ไม่พอสำหรับ amortized + split charge เชิงลึก
- Trusted Advisor ผิด — เป็น best-practice check ไม่ใช่ allocation/chargeback tool
- Budgets ผิด — เป็น guardrail/เพดาน ไม่ใช่เครื่องมือ allocate cost
ข้อ 6. fleet EC2 หลายร้อยตัวถูกตั้งค่า over-provisioned ต้องการ reduce cost โดยหา instance type ที่เหมาะสมกว่าแบบอัตโนมัติจาก metric ที่มีอยู่ ควรใช้อะไร
เฉลย
AWS Compute Optimizer — ใช้ ML วิเคราะห์ CloudWatch metric แนะนำ instance type/size ที่เหมาะ (down-size over-provisioned)
- ซื้อ Reserved Instances ผิด — ลดราคาต่อหน่วยแต่ ไม่แก้ over-provisioning (ยังจ่ายเกินขนาดที่ต้องการ)
- Cost Explorer ผิด — ดู cost ได้แต่ไม่แนะนำ right-sizing per resource (Cost Explorer มี rightsizing recommendation จำกัดกว่า Compute Optimizer)
- Spot ผิด — เปลี่ยน pricing model ไม่ใช่แก้ขนาดที่ over-provisioned
ข้อ 7. payer account ซื้อ Savings Plans ไว้ แต่พบว่า account อื่นใน organization ยังจ่าย On-Demand เต็ม ทั้งที่ usage รวมควรถูกคลุมได้ ปัญหาน่าจะเกิดจากอะไรและแก้อย่างไร
เฉลย
RI/Savings Plans sharing ถูกปิด — เปิด discount sharing ใน Billing preferences ของ payer เพื่อให้ commitment apply ข้าม account ทั้ง org (consolidated billing)
- “ต้องซื้อ Savings Plans แยกทุก account” ผิด — sharing ทำให้ไม่ต้องซื้อแยก
- “Savings Plans ใช้ข้าม account ไม่ได้เลย” ผิด — ใช้ได้ผ่าน consolidated billing เมื่อเปิด sharing
- “ต้องย้าย workload ไป account เดียว” ผิด — ไม่จำเป็น sharing แก้ได้ที่ระดับ billing
ข้อ 8. องค์กรต้องการให้ทุก resource มี tag CostCenter เสมอ มิฉะนั้นสร้างไม่ได้ และต้องการรายงาน resource ที่ไม่ตรงมาตรฐาน tag ควรใช้กลไกใด
เฉลย
SCP ที่ deny การสร้าง resource เมื่อไม่มี aws:RequestTag/CostCenter (บล็อก/preventive) ร่วมกับ Tag Policy สำหรับมาตรฐาน format และรายงาน non-compliant (detective) — และอย่าลืม activate cost allocation tag ใน Billing
- “Tag Policy อย่างเดียว” ผิด — Tag Policy ไม่บล็อกการสร้าง เป็น detective เท่านั้น (เชื่อมโยงบทที่ 02)
- “Config rule อย่างเดียว” ผิด — ตรวจหลังสร้าง (detective) ไม่ preventive
- “IAM policy ต่อ user” ผิด — ไม่ scale ระดับ org; SCP เป็น guardrail ที่เหมาะกว่า
ข้อ 9. ต้องการถูกแจ้งเตือนเมื่อค่าใช้จ่ายของ service ใด service หนึ่งพุ่งผิดปกติ โดยไม่ต้องกำหนด threshold ตายตัวเอง ควรใช้อะไร
เฉลย
AWS Cost Anomaly Detection — ใช้ ML เรียนรู้ pattern แล้วแจ้งเตือนเมื่อเกิด spike ผิดปกติ (monitor ต่อ service/account/tag)
- AWS Budgets ผิด — ต้องตั้ง threshold เอง ไม่ใช่ ML anomaly
- Trusted Advisor ผิด — best-practice check ไม่ใช่ anomaly alerting
- CloudWatch billing alarm ผิด — ตั้ง static threshold เอง
ข้อ 10. application หลาย EC2 ใน VPC เรียก Amazon S3 และ DynamoDB ปริมาณมากผ่าน NAT Gateway ทำให้ค่า data processing/transfer สูง ต้องการลดต้นทุนนี้ ควรทำอย่างไร
เฉลย
สร้าง Gateway VPC Endpoint สำหรับ S3 และ DynamoDB — traffic ไม่ผ่าน NAT/internet, endpoint ฟรี ลดทั้ง NAT processing cost และ data transfer (เชื่อมโยงบทที่ 04/06)
- Interface endpoint (PrivateLink) สำหรับ S3/DynamoDB ผิดในบริบทนี้ — มีค่าใช้จ่าย hourly/GB; gateway endpoint ฟรีและเหมาะกว่าสำหรับ S3/DynamoDB
- เพิ่มขนาด NAT Gateway ผิด — ยิ่งจ่ายมากขึ้น ไม่แก้ต้นเหตุ
- ย้ายไป On-Demand ราคาถูกลง ผิด — ไม่เกี่ยวกับ data transfer cost
7. Cross-references
หัวข้อที่มีชื่อว่า “7. Cross-references”- บทที่ 01 — Exam Blueprint & SA-Pro Mindset: (รับ cross-ref) keyword most cost-effective → เลือก pricing model ตาม usage pattern; ตัวอย่าง Spot batch จากบท 01 ขยายเต็มที่ 2.5; Cost Optimization pillar เป็นกรอบตัดสินใจ (2.1)
- บทที่ 02 — Multi-Account Governance: (รับ cross-ref) consolidated billing เชิงลึก (RI/SP sharing, volume tiering) ที่ 2.8; cost allocation tag + Tag Policy + SCP enforcement — Tag Policy เป็น detective, SCP บล็อก (2.8); Budget Actions apply SCP เป็น guardrail การเงิน (2.7); Control Tower/StackSets deploy Budgets ต่อ account (4.2)
- บทที่ 04 — Networking at Scale: การลด data transfer/egress cost — gateway endpoint (ฟรี), CloudFront ลด egress, cross-AZ awareness, NAT processing cost (2.9, ข้อ 10)
- บทที่ 05 — Compute & Application Integration: (รับ cross-ref) Spot strategy เชิงลึก, mixed instances policy, capacity provider/Fargate Spot; Savings Plans ครอบ Fargate/Lambda (2.4, 2.5); Auto Scaling/scheduling เป็น demand management (2.1)
- บทที่ 06 — Storage & Data Transfer: (รับ cross-ref) cost model ของ storage — S3 storage class/lifecycle/Intelligent-Tiering, minimum duration, gp3 vs gp2, S3 Storage Lens (2.6, 2.9); รายละเอียด storage class → บท 06
- บทที่ 07 — Databases & Data Migration: (รับ cross-ref) RDS/Redshift/ElastiCache Reserved Instances/Nodes (Savings Plans ไม่ครอบ), DynamoDB reserved capacity, Aurora I/O-Optimized (2.4)
- บทที่ 11 — Operational Excellence & Monitoring: (ฝากไป) performance tuning และ observability เชิงลึก; Compute Optimizer มุม performance (under-provisioned) และ CloudWatch metric ที่ใช้เป็นฐาน right-sizing → บท 11
- บทที่ 14 — Exam Scenarios & Decision Frameworks: (ฝากไป) decision framework เลือก pricing model (SP/RI/Spot/On-Demand) และ cost governance เข้าเป็น flowchart สังเคราะห์ + cross-domain scenario (cost + security + networking)
keyword ที่บทนี้ผูกไว้ให้บทหลังใช้ต่อ: most cost-effective → เลือก pricing model ตาม usage pattern; guarantee capacity → zonal RI/ODCR; fault-tolerant/stateless batch → Spot capacity-optimized; prevent runaway cost → Budgets + Actions; detect abnormal cost → Cost Anomaly Detection; custom/amortized chargeback → CUR + Athena + QuickSight; right-size over-provisioned → Compute Optimizer