Day 5 - Week 11 Review: Cost and Performance Operations as One Decision Flow

The tools covered in Week 11 - Compute Optimizer, Trusted Advisor, Cost Explorer, Budgets, Savings Plans, Spot - look separate on their own, but in practice they connect into a single flow. Cost optimization is not about pulling tools out at random but is an ordered pipeline. First you match the size of the container (Right Sizing), then you cut the stable usage with commitments, handle the variable portion with Spot, and analyze, control, and check the whole thing. If you reverse this order - for example, locking in commitments before Right Sizing - you make the expensive mistake of committing to the wrong size for 3 years.

This article organizes Week 11 along two axes. First, compress each tool's role into one sentence and solidify the "exam keyword → correct service" mapping; second, see how the tools tie together into one decision flow. Then we check your instincts with 12 practical scenario questions. On the exam, cost and performance questions are usually in the form of picking "the single tool best suited to this situation," and that choice hinges on knowing exactly each tool's own domain.

Week 11 One-Sentence Summary and Keyword Mapping

The exam picks out the tool through situational keywords. This mapping is the key.

💡 Related theory: Underlying this tool classification is the operational OODA loop (Observe-Orient-Decide-Act). Observation (Observe) is handled by CloudWatch, Cost Explorer, and CUR; judgment (Orient) by Compute Optimizer, Trusted Advisor, and Anomaly Detection; decision (Decide) by purchasing commitments and changing families; and action (Act) by Budgets Action, Spot reclamation handling, and automatic recovery. If, instead of memorizing tools by function, you classify them as "is this observing, judging, or acting," what is the answer in which situation narrows down naturally. For example, the distinction between "only detects and cannot block" (Anomaly Detection) and "actually blocks" (Budgets Action) is exactly the difference between Orient and Act.

The Right Order of Cost Optimization - Why Right Sizing Comes First

Knowing the cost optimization tools is different from applying them in the right order. If the order is wrong, the savings are halved or you even lose money.

Step 1 ─ Right Sizing (match the container size)
        Compute Optimizer recommendation → downsize, change family
        gp2 → gp3, io1 → gp3 migration
        ※ Must come first! Committing to a wrong size locks in the wrong cost for 3 years

Step 2 ─ Commitment discounts (cut the stable baseline)
        24/7 always-on workload 60-70% → Compute SP 3-year
        Only for the minimum usage that never shrinks

Step 3 ─ Variable workloads (On-Demand + Spot)
        Hard-to-predict variable portion → On-Demand 20-30%
        Stateless, tolerates reclamation → Spot 10-20% (capacityOptimized)

Step 4 ─ Continuous monitoring (observation and control)
        Cost Explorer analysis / Budgets control / Anomaly detection
        Check SP/RI Utilization and Coverage

The reason Step 1 must come first is that commitments are irreversible. If an m5.4xlarge would really be fine as an m5.large, and you put a 3-year Standard RI on this large instance without Right Sizing, then even if you want to downsize a year later, you cannot because you are tied to the commitment. The order is to find the right size first, and then place the commitment on the baseline of that right size. A commitment is the last step that cuts the "already optimized size," not the first step.

⚠️ Pitfall: Besides the mistake of reversing the order of Right Sizing and commitments, the mistake of "committing above the baseline" is also common. If you commit to match the peak of a workload whose traffic surges and dips, you pay for a considerable part of the commitment without using it during the trough hours (low Utilization). Always place commitments only on "the floor line of the graph (the part that never shrinks)" and support everything above it with On-Demand and Spot. On the exam, for "highly variable workload + cost savings," a full Standard RI commitment is likely the wrong answer, and the Compute SP (baseline) + Spot (variable) combination is the right direction.

Frequently Confused Boundaries - The Distinctions the Exam Targets

Most exam questions in the cost and performance area make you pick "one of two similar-looking tools." Here are the key boundaries.

Detection vs blocking: Cost Anomaly Detection detects and alerts on abnormal cost with ML but cannot stop the cost. The only thing that actually blocks is Budgets Action (EC2 stop, IAM/SCP). If the keyword is "block automatically," it is Budgets Action, and if it is "notice the abnormality," it is Anomaly Detection.

Fixed threshold vs pattern anomaly: Budgets alerts when a fixed threshold like "$5,000 per month" is exceeded. Cost Anomaly Detection catches outliers against the usual pattern. A sudden spike within the threshold is not caught by Budgets but is caught by Anomaly - they are complementary.

Right Sizing recommendations vs best practice checks: Compute Optimizer produces precise size recommendations per instance. Trusted Advisor is a coarse best practice check across the account. "Shrink which instance to which type" is Compute Optimizer, and "an overall check of cost, security, and fault tolerance" is Trusted Advisor.

Discount vs capacity guarantee: SP/RI are discounts and do not guarantee capacity. Capacity Reservation guarantees capacity and is not a discount. If it is "must be able to launch," it is Capacity Reservation, and if it is "cheaply," it is SP/RI.

My settings vs AWS-side events: Trusted Advisor looks at problems in my account's settings, and Personal Health Dashboard looks at AWS-side events (retirement, maintenance).

Quick summary vs raw data: Cost Explorer is a pre-aggregated quick summary (console), and CUR is raw data at the hour/resource level (S3 + Athena with arbitrary SQL).

The fundamental reason these boundaries exist is that each tool is optimized for a different data resolution and a different time of operation. Cost Explorer is pre-aggregated by day/hour so it is fast but coarse, and CUR is raw at the resource/hour level so it is precise but heavy. Anomaly Detection is asynchronous ML inference so it is strong at detection but cannot block in real time, and Budgets Action is based on threshold triggers so it blocks immediately but cannot see patterns. When memorizing tools, if you ask "what resolution of data does this process, and at what point in time," you can see why that tool does only that job well - the reason there is no single tool that does everything is the trade-off between data resolution and latency.

Commitment Check Metrics - The Meaning of Utilization and Coverage

Buying a commitment (SP/RI) is not the end of it. Workloads change, so you must continuously check whether the commitment is still right, and the key metrics for that are Cost Explorer's Utilization and Coverage. If you mix these two up, you make the wrong decision.

• Utilization: The ratio of the purchased commitment that was actually used and received the discount. At 90% you are using 90% of the commitment, and at 60% you are wasting 40% (over-commitment). If low, you should reduce the commitment.
• Coverage: The ratio of total On-Demand-eligible usage that the commitment covers. At 50%, half of the usage is still paid at list price (On-Demand). If low, there is room to commit more (an additional savings opportunity).

You must look at both together - if Coverage is low and Utilization is high, "you would use it all even if you bought more commitment," so an additional commitment is safe. If Coverage is high but Utilization is low, you are already over-committed, so you should not buy more.

According to industry surveys by the FinOps Foundation, the major axes of cloud cost waste are ① idle resources that were not turned off and ② wrongly purchased commitments. Many organizations, thinking "committing is always cheaper," bought large amounts of RIs matched to peak usage, then suffered failures where the workload shrank or the family changed and Utilization fell below 50% - the unused commitment became even more expensive than On-Demand. With this lesson, the industry made "conservative commitments + regular Utilization/Coverage checks" the standard, and AWS also eased the rigidity of commitments by introducing Convertible RIs and the flexible Compute SP. A commitment is not something at the moment of purchase but something you manage while operating.

Wrap-Up

The Week 11 tools implement the operational loop of "observe → judge → decide → act" in the cost and performance area. Whether on the exam or in practice, the key is each tool's own domain and the order in which they are tied together.

Compressed to five points: ① Compute Optimizer = Right Sizing recommendations (14 days of metrics, memory requires the Agent), Step 1 of cost optimization. ② Trusted Advisor = best practice checks in five categories (all of them require Business+ Support, limits give an advance warning at 80%). ③ Cost Explorer (multi-dimensional analysis) + Budgets (blocks via Action) + Tag (allocation, activation is not retroactive) + Anomaly Detection (ML detection, not blocking). ④ Commitments only on the baseline (Compute SP flexible / EC2 Instance SP and Standard RI tied down / RDS and Redshift use RIs), checked with Utilization and Coverage. ⑤ Spot is only for stateless workloads that tolerate reclamation (capacityOptimized, handle the 2-minute notice), and Capacity Reservation guarantees capacity rather than a discount. Applying them in this order - Right Sizing → commitments → Spot → monitoring - is the canonical way of cost optimization.

📝 Practice Questions

Click a choice to reveal the answer and explanation.

Question 1

You operate 200 EC2 instances and want to know precisely, per instance, which instances are over-provisioned. What is the most suitable tool?

• APut per-instance CPU and memory graphs on a CloudWatch Dashboard and have operators manually identify over-provisioned ones
• BCompute Optimizer - analyzes the percentile distribution of 14 days of metrics with ML and presents Over/Under/Optimized per instance along with the recommended type
• CCheck for low-utilization instances across the account against best practices with the Trusted Advisor Performance category
• DBreak down cost by instance type in Cost Explorer and presume the instances with large spend are over-provisioned

Question 2

The operations team sets a $5,000 monthly budget and wants an alert at 80% and some EC2 instances automatically stopped at 100%. Without human intervention.

• AMonitor monthly spending in Cost Explorer and have an operator manually stop EC2 once it passes 80%
• BAWS Budgets + Budgets Action (alert at 80%, EC2 stop or IAM Deny attachment at 100%)
• CDetect the cost surge with Cost Anomaly Detection, send an SNS alert, and automatically stop EC2
• DPut a CloudWatch Alarm on the billing metric (EstimatedCharges) and stop EC2 with Lambda when the threshold is reached

Question 3

You want to track the cost of the CloudOps team and the DevOps team separately. What is the lightest method?

• ACreate a separate AWS account for each team and separate the cost by account using Organizations consolidated billing
• BAssign a Team tag to resources + activate the Cost Allocation Tag + Cost Explorer Group by Tag
• CCreate a Budget for each team and track each team's cost separately by budget
• DDownload CUR to S3 and manually analyze cost by team daily with Athena or spreadsheets

Question 4

A company will run EC2 stably for the next 3 years but changes families and Regions often. To get the maximum discount without code changes?

• AStandard RI 3-year - commit to a specific instance family for the maximum discount and repurchase the RI when changing families
• BCompute Savings Plans 3-year - applies automatically within the committed amount across all Regions, families, and EC2/Fargate/Lambda
• CRun On-Demand, keeping the freedom to change families and Regions but giving up the discount
• DRun on Spot to get up to a 90% discount, automatically substituting another family on reclamation

Question 5

You run an EMR batch with 100 nodes only at night. It is stateless and can simply be rerun if reclaimed. How do you minimize cost?

• ALaunch 100 On-Demand instances at list price for each nightly batch and terminate them, operating flexibly without commitments
• BCommit to 100 Standard RIs for 3 years to apply the maximum discount to the batch nodes
• CSpot Fleet + capacityOptimized - the best for stateless, reclamation-tolerant batch, up to a 90% discount + stability
• DCommit to the hourly spend of the nightly batch with Compute Savings Plans to receive a discount

Question 6

You want to automatically receive a warning when the limits (quotas) of all AWS services approach 80%.

• APublish per-service usage directly as CloudWatch Custom Metrics and manually configure an 80% threshold alarm
• BTrusted Advisor Service Limits + EventBridge notification (Business+ Support)
• CTrack the number of resources per service with Config Rules and evaluate whether it exceeds 80% of the limit
• DManually check each quota's utilization regularly in the Service Quotas console

Question 7

One day the company's cost spiked to 3 times the usual pattern. It did not exceed the fixed budget threshold. To automatically detect such an anomaly?

• ASlice the monthly fixed threshold finely with AWS Budgets to catch the pattern deviation as a threshold breach
• BCost Anomaly Detection - learns the usual pattern with ML and detects statistical outliers
• CCheck for wasted resources with the Trusted Advisor Cost category to find the cause of the cost surge
• DPut a CloudWatch Alarm on the billing metric (EstimatedCharges) to detect a surge against the usual

Question 8

You want to secure new m7i instances so they can always be launched immediately in a specific AZ for BCP. The goal is availability, not cost savings.

• AStandard RI (gives a discount but does not guarantee capacity)
• BEC2 Capacity Reservation - secures capacity in a specific AZ, the discount is separate (combine with SP/RI)
• CSecure it in advance on Spot in that AZ and re-request immediately when reclaimed
• DPre-launch On-Demand instances for BCP, keep them in the stopped state, and start them when needed

Question 9

You run RDS PostgreSQL 24/7 and want a commitment discount.

• ACommit to hourly spend with Compute Savings Plans to apply a discount to the RDS instance as well
• BCommit to a specific instance family with EC2 Instance Savings Plans to discount compute including RDS
• CReserved Instances (RDS RI)
• DLaunch the RDS instance on Spot for the maximum discount while preparing for reclamation

Question 10

To cut EBS cost, you want to automatically identify candidates for gp2 → gp3 migration.

• AQuery the type and IOPS of all volumes with the CLI and manually select gp2 volumes in a spreadsheet
• BCompute Optimizer EBS Volume recommendations + Trusted Advisor Cost category
• CBreak down EBS cost by volume type in Cost Explorer and presume the volumes with large gp2 spend as candidates
• DMark gp2 volumes as noncompliant with a Config Rule to generate a migration candidate list

Question 11

The Cost Explorer Utilization of a Compute SP the company bought a year ago is a low 55%. What does it mean and what is the action?

• AIt is a signal that the commitment is insufficient, so enlarge the baseline and buy additional SP to widen the discount range
• BOver-commitment - 45% of the commitment is being wasted unused, so size the next commitment down to match the baseline that never shrinks
• CSince it is Coverage and not Utilization that is low, buy more commitment to cover the usage still paid On-Demand
• DUtilization varies too much by point in time to be a reliable metric, so judge by Coverage alone

Question 12

An API server the operations team was running on a t3.large has steadily growing traffic, and every afternoon response times plunge and CPU hits a ceiling at a fixed value. What is the correct action considering both cost and performance?

• AScale the instance up to t3.2xlarge
• BThe cause is CPU credit exhaustion, so change to an m/c family suited to steady load (for example, m6i) and verify the right size with Compute Optimizer
• CChange the volume to gp3
• DSwitch to Spot

📌 Today's Summary

1. Cost optimization is an ordered pipeline - Right Sizing (step 1) → commitments (baseline) → Spot (variable) → monitoring. Match the size before committing so you do not commit to the wrong cost
2. Keyword mapping: size recommendations→Compute Optimizer, 5-category checks→Trusted Advisor, automatic blocking→Budgets Action, ML detection→Anomaly Detection, capacity guarantee→Capacity Reservation
3. Boundaries: detection (Anomaly) vs blocking (Budgets Action), quick summary (Cost Explorer) vs raw data (CUR), discount (SP/RI) vs capacity guarantee (Capacity Reservation), my settings (TA) vs AWS side (PHD)
4. Commitments only on the baseline, Compute SP (flexible) / EC2 Instance SP and Standard RI (tied down) / RDS and Redshift use RIs, check suitability with Utilization and Coverage
5. Spot is only for stateless, reclamation-tolerant workloads (capacityOptimized, handle the 2-minute notice), and T family credit exhaustion is corrected with the m/c families