Day 5 - Cost Optimization Comprehensive Review: The Math of Commitments and Spot, and the Tradeoffs of Hidden Costs

Cost optimization is not simply "buy Reserved Instances." The Pro exam is a tradeoff problem where you find the optimal answer in a four-dimensional matrix of workload pattern + commitment model + instant discount + hidden costs. Even for the same EC2, the answer differs for 24-hour operation, nightly batch, and spiky traffic, and "invisible" costs like the NAT Gateway often account for more than 30% of the total bill. All of these decisions also rest on the five design principles of the Well-Architected Framework's Cost Optimization pillar (adopt a consumption model, measure efficiency, stop spending money on undifferentiated heavy lifting of data center operations, analyze and attribute expenditure, and use managed services to reduce the cost of ownership). Today we pull together all of Week 12's cost optimization and point out the traps of the Pro exam.

Five Commitment Discount Models: The Risk Spectrum of Flexibility vs Discount Rate

The essence of a commitment discount is risk transfer. AWS has to buy physical servers for its data centers in advance (capital expenditure + inventory risk), and when a customer promises "I will definitely use $X per hour for 1 or 3 years," that capacity planning risk is reduced. The price of that is the discount. So the more specific the commitment (= the more of AWS's uncertainty you remove), the bigger the discount. This is exactly the same economics as a financial forward contract.

Viewed as a risk spectrum: On-Demand (AWS bears all the risk, 0% discount) → Convertible RI → Compute SP → EC2 Instance SP / Standard RI (the customer bears the commitment risk heavily, ~72%) → Spot (the customer bears even the interruption risk, ~90%). The "flexibility vs discount" tradeoff in every exam scenario is a matter of where on this spectrum to place the workload.

🎯 Scenario: "A company runs the EC2 m5 family 24 hours a day and has no plans to change families over the next 3 years. It has cash to spare. What is the maximum discount?" — Answer: EC2 Instance Savings Plans or Standard RI (3-year All Upfront). If the family and Region are fixed, there is no reason to buy flexibility, so the most specific commitment is the answer. EC2 Instance SP is free across size, OS, and AZ within the same family, so it is one step more flexible than Standard RI at the same ~72%.

The difference in commitment unit creates the SP's flexibility. RI commits to an "instance," but SP commits to "$/hour," which is the CS idea of an abstraction layer. SP puts an abstract layer called "normalized hourly cost" on top of physical resources so the commitment matches whether the instance underneath is m5 or m6i. It is the typical pattern where abstraction lowers coupling so the commitment does not break even when the workload is modernized.

The payment options (All/Partial/No Upfront) follow the same risk logic. With All Upfront, AWS receives cash in advance (eliminating credit risk + the time value of money) and gives the biggest discount. "Cash to spare + maximum discount" signals All Upfront, and "minimize upfront cash + commitment discount" signals No Upfront. The order of application is Zonal RI → Regional RI → Savings Plans → On-Demand, with the most specific commitment absorbing usage first. That is why over-buying RIs lets RIs claim usage first and lowers SP utilization, the classic cause of "low SP utilization."

Spot Instances: Up to 90% Discount + Interruption Risk

• 10-30% of the normal price, with price fluctuating by market supply and demand
• Reclaimed after a 2-minute advance notice (the EC2 instance rebalance recommendation comes earlier)
• Suitable for: stateless, fault-tolerant, batch, CI/CD, distributed training, rendering, container workers

Spot Fleet / EC2 Fleet Allocation Strategies

(Hypothetical case) A video rendering company groups more than 10 instance pools such as c5, c5n, c5a, m5, and m5n with capacity-optimized. When one pool's capacity runs short, it automatically substitutes another pool, keeping the interruption rate at 5% or below while cutting cost by about 80%. Lesson: the key to Spot stability is not "low price" but pool diversification; if you pile into the single cheapest pool, everything collapses when that pool is reclaimed.

Spot pool diversification is the same as diversification in financial portfolio theory. If you spread across multiple pools with low correlation, the effect of one pool's interruption (idiosyncratic risk) on the whole shrinks. capacity-optimized chose "minimizing variance (stability)" over "maximizing return (lowest price)," so the more sensitive a mission is to interruption, the more capacity-optimized/price-capacity-optimized rather than lowest-price is the answer.

🎯 Scenario: "Run Kubernetes (EKS) data processing workers at minimum cost while tolerating interruption." → Karpenter or Managed Node Group + Spot (capacity-optimized) + On-Demand mix + diverse instance types. Respond to the 2-minute notice with a Pod Disruption Budget and graceful drain. Pure Spot with a single type risks a total outage when reclaimed.

Four Recommendation and Analysis Tools — Boundaries by Purpose

Because of the semantic gap of virtualization (the hypervisor cannot see guest memory), memory recommendations appear only if the CloudWatch Agent is installed. The answer to "why don't memory recommendations show up?" is almost always that the CW Agent is not installed. Turning on Compute Optimizer enhanced infrastructure metrics extends the lookback from 14 days up to 93 days to reflect seasonality (paid).

The division of labor between Trusted Advisor (rules) and Compute Optimizer (ML) is the classifier's precision-recall tradeoff. Rules are fast and interpretable but produce many false positives (mistaking a batch spike), while ML reduces false positives but needs training data and time. Operations use a layered structure of screening broadly with TA and then analyzing precisely with CO. Other clouds are isomorphic: Azure Advisor and GCP Recommender correspond respectively.

Budgets vs Cost Anomaly Detection — Control vs Detection

🎯 Scenario: "If the monthly budget is exceeded, refuse to launch any more new EC2 instances." → Automatically apply an IAM Deny Policy with a Budgets Action. A CloudWatch Alarm only notifies, a Lambda schedule is an after-the-fact batch, and Cost Anomaly only detects. However, because of the billing data update delay, if "must never exceed" is emphasized, suspect a preventive SCP/Service Quotas used in parallel.

⚠️ Pitfall: Budgets Action must be designed to distinguish "block new creation (IAM/SCP Deny)" from "stop currently running resources (EC2/RDS stop)." If the scenario verb is "prevent," it is Deny, and if it is "halt," it is stop.

Hidden Costs

NAT Gateway: Double Billing by Hour + Throughput

• Hourly charge about $0.045/h × 24h × 30d ≈ $32/month (multiplied by the number of AZs if one per AZ)
• Throughput about $0.045/GB (varies by Region)
• 1TB of internet traffic from inside the VPC ≈ $45 in throughput alone

The NAT Gateway often becomes a bigger cost item than RDS. In particular, when Lambda or ECS Tasks in private subnets call external or AWS APIs, all traffic goes through NAT and cost explodes. S3 and DynamoDB use a Gateway Endpoint (free), and other AWS services (SQS, SNS, KMS, ECR, Secrets Manager, and so on) bypass NAT with an Interface Endpoint (PrivateLink, about $0.01/hour per AZ + throughput). The tripwire rule of thumb: "if a month of NAT cost exceeds the Interface Endpoint hourly charge, switch to the Endpoint." Container environments with frequent ECR pulls and S3 access are the first candidates.

(Hypothetical case) A SaaS uploads 100GB to S3 every day from ECS Tasks. Via the NAT Gateway, the throughput cost alone is about $4,500 per month. After switching to an S3 Gateway Endpoint, that traffic costs $0. Simply bypassing through routing saves about $54,000 a year. Lesson: whether S3 and DynamoDB traffic from private subnets is riding NAT is the first anti-pattern to check.

Cross-AZ Traffic: Billed in Both Directions

• Communication between different AZs in the same Region: about $0.01/GB is charged on both sides (round trip ≈ $0.02/GB)
• Cross-AZ DB replication, ALB → instances in another AZ, distributed cache synchronization, and the like are surprisingly large costs

This is the fundamental tradeoff between availability and cost. Multi-AZ spreads across AZs for fault tolerance (the WA Reliability pillar), but at the price of Cross-AZ traffic cost. If read latency is acceptable, you reduce it by placing read replicas in the same AZ or by topology-aware routing (for example, the ALB cross-zone setting, client AZ affinity), which is a deliberate choice to give up a little availability and save cost. The Pro-level awareness is that "maintaining high availability + minimizing Cross-AZ cost" is inherently difficult to reconcile.

Internet Egress vs CloudFront

🎯 Scenario: "Serve S3 static content to global users + minimize cost and latency." → CloudFront + S3 (+ Origin Shield). Transfer from S3 to CloudFront is free so egress shrinks, and edge caching also reduces origin load and latency. Exposing S3 directly means higher egress cost and no caching. Transfer Acceleration is for upload acceleration and Global Accelerator is for static IPs and TCP/UDP acceleration, so their purposes differ from static content distribution.

Automatic S3 Storage Class Transitions

⚠️ Pitfall: Intelligent-Tiering is not simply "free automatic transition"; there is a separate per-object monitoring cost (a small amount per 1,000 objects). If objects are very small (under 128KB do not transition to IA) or very numerous, the monitoring cost can offset the savings. "Unknown access pattern + large objects" is Intelligent-Tiering's answer, but for "hundreds of millions of small objects," suspect the monitoring cost trap.

Cleaning Up Incomplete Multipart Uploads

• If a multipart upload fails midway, the partial chunks keep being stored and billed invisibly
• Recommended: auto-delete after 7 days with a Lifecycle rule (detect the accumulated amount with S3 Storage Lens)
• In large environments it can accumulate to tens of TB

(Hypothetical case) A company investigated unexplained growth in S3 cost and found that failed multipart upload fragments accumulated over years were occupying tens of TB. They did not appear in the console or ordinary listings, so discovery was late. They confirmed the incomplete multipart accumulation with Storage Lens and cleaned it up immediately with a lifecycle rule (7-day abort). Lesson: the number one suspects for "invisible storage cost" are incomplete multipart uploads and old versions (versioning).

Multi-Account and Organization Cost Governance

Cost scenarios on the SAP exam almost always presuppose multiple accounts. The core principle: commitment discounts are shared across the entire Org through Consolidated Billing, so buying centrally in bulk (the management account or a dedicated billing account) is superior in both utilization and management. "Buy SP in each member account" is a typical wrong answer.

Org-level commitment pooling is resource pooling in distributed systems plus the law of large numbers in statistics. If you merge multiple workloads into one pool, individual spikes cancel out and variability shrinks, so it is safe to commit more tightly to the usage floor (baseline). So the larger the pool, the higher you can raise Coverage without over-commit risk. Consolidated billing also applies volume tier discounts in aggregate, so the essence of multi-account cost design is to split accounts for cost separation while sharing the discounts.

Scenario Keyword → Answer Mapping Table

Wrapping Up

Cost optimization has three axes of (commitments + instant discounts + hidden costs), with the Well-Architected Cost Optimization pillar and the FinOps Inform → Optimize → Operate cycle laid on top. The SP/RI application order, Spot interruption and pool diversification strategy, and the hidden costs of NAT/AZ/Egress: you must recall the tradeoffs among these three all at once to solve exam scenarios. The tools form a four-stage workflow of Compute Optimizer (recommendation), CUR (analysis), Budgets (control), and Anomaly Detection (detection), and in a multi-account setup, you share commitments through consolidated billing and govern in bulk from the center.

Next week (Week 13) is a comprehensive wrap-up of the Well-Architected 6 pillars.

📝 Practice Questions

Click a choice to reveal the answer and explanation.

Question 1

A company uses EC2, Fargate, and Lambda and frequently changes instance families depending on the workload. It wants to apply discounts as broadly as possible with a 1-year commitment. What is the most suitable?

• AStandard RI (m5 family 3-year All Upfront)
• BEC2 Instance Savings Plans (specific Region and family fixed)
• CCompute Savings Plans
• DSpot Fleet (capacity-optimized, diverse pools)

Question 2

After the cost team bought a large amount of RIs and SPs at the same time, SP utilization falls short of 100%. What is the most likely cause and action?

• ASP can never be 100% utilized — leave it as is
• BRIs absorb usage first, leaving too little for SP to match — reduce RIs or standardize new commitments on SP
• CCompute SP cannot cover Fargate — replace with EC2 Instance SP
• DSP is not shared under consolidated billing — repurchase per account

Question 3

A distributed data processing job runs only at night, can be restarted if interrupted, and you want to cut cost as much as possible. You can use several instance types. What is the most suitable?

• AOn-Demand with a single type, started only at night
• BA Standard RI 3-year commitment to minimize the hourly unit price
• CSpot Fleet, capacity-optimized strategy + diverse instance pools
• DA Compute Savings Plans 1-year commitment for a stable discount

Question 4

Lambda and ECS Tasks in a private subnet access S3 and DynamoDB, and the NAT Gateway throughput cost is very large. How do you bring the cost close to zero?

• APlace Interface Endpoints (PrivateLink) for S3 and DynamoDB in each AZ
• BS3 and DynamoDB Gateway Endpoints
• CAdd NAT Gateways per AZ to spread the throughput
• DRoute the private subnet directly to the Internet Gateway

Question 5

Data transfer cost is large at 25% of the total, but Cost Explorer cannot break down which traffic it is. How do you pin down the root cause?

• ASet a budget and alert on the data transfer line item with Budgets
• BQuery the CUR with Athena and break it down by UsageType
• CRun Trusted Advisor to check the cost category
• DNarrow the Cost Explorer filter further by service and UsageType

Question 6

You want to serve static web content stored in S3 to global users while minimizing egress cost and latency. What is the most suitable?

• AMake the S3 bucket public and egress directly through the Internet Gateway
• BCloudFront + S3 (+ Origin Shield)
• CAccelerate transfer through the edge with S3 Transfer Acceleration
• DProvide a static IP and Anycast path with Global Accelerator

Question 7

You want to automatically and immediately block new EC2 creation when a development account's monthly cost exceeds the threshold. You also need a guarantee that the threshold can absolutely never be exceeded (a hard cap), regardless of billing delay. What is the most suitable combination?

• AA CloudWatch Billing Alarm that only sends an SNS notification when the threshold is exceeded
• BBlock after the fact with a Budgets Action (IAM/SCP Deny) + limit the resource ceiling itself in advance with a preventive SCP/Service Quotas
• CA Lambda daily schedule that checks cost and terminates instances if exceeded
• DDetect and alert on ML-based abnormal cost with Cost Anomaly Detection

Question 8

You want to replace instances operated by an Auto Scaling Group with smaller, newer-generation types following Compute Optimizer recommendations. What is the correct method?

• AStop each instance → change the type with ModifyInstanceAttribute → start
• BPut the recommended type in a new Launch Template version and replace in a rolling fashion with Instance Refresh
• CDelete the ASG, create a new ASG with the recommended type, and switch traffic
• DTerminate the instances directly and the ASG automatically restarts them with the new type

Question 9

Compute Optimizer gives CPU and network recommendations for EC2 but no memory recommendation at all. What is the cause?

• ACompute Optimizer does not support memory recommendations at all
• BThe CloudWatch Agent is not on the guest OS, so memory metrics are not collected
• CInsufficient IAM permissions blocked all of Compute Optimizer's recommendations
• DThe 14-day lookback period has not yet passed, so recommendations are pending

Question 10

In an Organization with 50 member accounts, you want to minimize total compute cost while maximizing commitment utilization. What is the most suitable commitment purchasing strategy?

• AEach member account buys and manages its own SP according to its own usage
• BPurchase SP centrally in the management account (or a dedicated billing account) sized to the Org-wide baseline and enable sharing
• CEach member account buys its own Standard RI according to its own family
• DUse only On-Demand with no commitments and analyze after the fact with Cost Explorer

Question 11

A media company holding a large amount of m4 Standard RIs tried to modernize its workloads to m6i and fell into a situation where the old RIs sit idle and the new instances are billed On-Demand. To prevent the same problem going forward, what should the new commitment be?

• ABuy additional m4/m5 Standard RIs to match the existing commitments
• BCompute Savings Plans (or Convertible RI)
• CReserve capacity in a specific AZ with Zonal RI
• DCancel all commitments and switch to On-Demand

Question 12

S3 cost keeps rising with no explanation. The console's object listing does not reveal the cause. What hidden cost should you suspect most, and what is the action?

• AAccumulated Glacier retrieval and restore charges — move the objects to S3 Standard
• BAccumulated failed Incomplete Multipart Upload fragments — confirm with Storage Lens and clean up with a Lifecycle rule (for example, 7-day abort)
• CCloudFront edge cache storage cost — disable the cache
• DA Cost Explorer aggregation bug — request a correction through a support ticket