Domain 4 of 4 · Chapter 1 of 4

Cost-Optimized Compute

RI vs Savings Plans: the apply order, and why it matters

AWS billing applies discounts in a fixed sequence each hour, and the order changes which mechanism is the right one to buy.

Apply order, every billing hour:

  1. Reserved Instances are applied first — to any usage that matches the RI's family, region, AZ (if zonal), tenancy, and OS.
  2. Savings Plans are applied next — to any remaining eligible usage, in the order that maximizes customer savings (highest-discount usage first).
  3. On-Demand rates apply to whatever is left.

Why this matters for buying decisions:

If you already own RIs that fully cover your baseline (e.g., 10 reserved m5.xlarge), buying a Compute Savings Plan that overlaps that same usage gains you nothing — RIs consume it first, and the Savings Plan sits idle and unutilized.

The right buying order is the inverse: layer Savings Plans on top of un-RI-covered usage, then add RIs only when a specific instance type's utilization is reliably steady over 1-3 years.

Practical pattern:

  • Have a steady baseline that's family-locked? Standard or Convertible RIs (highest discount: up to 72%).
  • Have a steady baseline that spans EC2 + Fargate + Lambda? Compute Savings Plan (one commitment, three services).
  • Have a steady baseline that's EC2-only but instance-family-stable with size flexibility? EC2 Instance Savings Plan (up to 72%, family-locked but size-flexible — m5.large/xl/2xl all count toward the same $/hr commitment).

Further reading: How Savings Plans apply[3].

Spot interruption handling and Spot Fleet allocation strategies

Spot Instances offer up to 90% off On-Demand, but only if the application can absorb the 2-minute termination notice and the variable-capacity reality.

Interruption signals:

  • 2-minute termination notice — written to the instance metadata service at http://169.254.169.254/latest/meta-data/spot/instance-action. Applications should drain in-flight requests, checkpoint state, and deregister from load balancers within this window.
  • Rebalance recommendation — issued earlier than the termination notice when Spot interruption probability becomes elevated. Acts as a soft warning so applications can proactively migrate work before the 2-minute hard notice arrives.

Spot Fleet allocation strategies:

  • capacity-optimized (recommended default) — launches instances from the pool with the lowest predicted interruption rate. Best for long-running workloads where uptime stability matters more than raw $/hr.
  • capacity-optimized-prioritized — same, but respects an instance-type priority list. Useful when ML/HPC workloads have a preferred instance type for performance reasons.
  • lowest-price — launches from the cheapest pool. Best for short-lived workloads where interruption recovery is fast.
  • price-capacity-optimized — a hybrid balancing cost and interruption risk. New default for many Spot consumers.
  • diversified — spreads across all configured pools. Maximizes resilience but may not pick the cheapest pool.

Pairing with Mixed Instances Policy: Auto Scaling groups can specify multiple instance types and a Spot/On-Demand split. OnDemandBaseCapacity defines a minimum guaranteed On-Demand floor; OnDemandPercentageAboveBaseCapacity controls the split for capacity above that floor.

Further reading: EC2 Spot Fleet allocation strategies[10].

Compute Optimizer: when it generates recommendations, when it can't

Compute Optimizer analyzes utilization metrics to recommend right-sizing for EC2, Auto Scaling groups, EBS volumes, Lambda, and ECS on Fargate.

Minimum data requirements (these matter for the exam):

  • EC2 / Auto Scaling: 30 hours of metrics within the past 14 days; the more history, the better the confidence rating.
  • Lambda: ≥50 invocations across at least 14 days. Functions invoked fewer than 50 times in that window receive no recommendation.
  • EBS volumes: 30 consecutive hours of metrics.
  • ECS on Fargate: 24 hours of metrics over the past 14 days.

If you see an exam question where Compute Optimizer 'cannot generate' or 'has insufficient data' — it's almost always one of these thresholds.

What it recommends:

  • Over-provisioned: downsize to a smaller instance/family or reduce memory allocation.
  • Under-provisioned: upsize, or switch to a higher-performance family.
  • Optimized: no change recommended.
  • Inferred workload type (EC2): Compute Optimizer detects whether a workload looks CPU-bound, memory-bound, etc., and may recommend a different family (e.g., m5 → c5 for CPU-heavy patterns, m5 → r5 for memory-heavy).

Enhanced infrastructure metrics: opt-in for memory utilization metrics from CloudWatch Agent — recommendations are sharper because Compute Optimizer can see memory pressure that the default CPU-only metrics miss.

Further reading: AWS Compute Optimizer requirements[9].

Worked example: applying every lever to a 50-instance fleet

Scenario: A SaaS company runs 50 m5.xlarge EC2 instances on-demand in us-east-1 to serve a stateless web tier. Monthly bill: ~$5,800. Workload characteristics: 30 instances are needed 24/7 (baseline traffic), 20 fluctuate with traffic spikes 2-3 hours per day, and a separate set of 10 batch workers process queued jobs nightly.

Apply every lever:

  1. Baseline 30 instances — predictable, 24/7. Buy 30× 1-year No-Upfront Standard RIs for m5.xlarge in us-east-1. Discount: ~40% → saves ~$1,400/month.
  2. Spiky 20 instances — variable. Auto Scaling group with Mixed Instances Policy: OnDemandBaseCapacity=0, OnDemandPercentageAboveBaseCapacity=0, allocation strategy capacity-optimized. Allow m5.xlarge, m5a.xlarge, m4.xlarge, m6i.xlarge as Spot pools. Discount: ~70% on the Spot portion → saves ~$800/month at typical 50% utilization.
  3. Nightly batch workers — fault-tolerant by definition. Pure Spot Fleet with price-capacity-optimized strategy. Discount: ~80% → saves ~$300/month.
  4. Run Compute Optimizer on the entire fleet after 14 days of metrics — likely recommends downsizing some over-provisioned instances to m5.large. Estimated savings: another 15-20%.

Total monthly savings: ~$2,500-2,900, or roughly 45-50% off the original $5,800 — with zero code changes.

What the exam will probe: which lever fits which workload pattern. Memorize the matching, not the percentages.

EC2 pricing mechanisms compared

MechanismDiscount vs ODCommitmentFlexibilityInterruption riskBest for
Standard RIUp to 72%1 or 3 yr, instance family + regionCan sell on RI MarketplaceNoneStable, family-locked workloads
Convertible RIUp to 66%1 or 3 yrExchange family / OS / tenancyNoneStable but evolving workloads
Compute Savings PlansUp to 66%1 or 3 yr, $/hr commitmentAny family, any region, EC2 + Fargate + LambdaNoneMulti-service compute mix
EC2 Instance Savings PlansUp to 72%1 or 3 yr, $/hr commitmentFamily + region locked, size-flexibleNoneType-stable EC2 with size flexibility
SpotUp to 90%NoneAny instance type, any region2-min termination noticeFault-tolerant batch, CI, stateless web
On-Demand0%NoneFullNoneSpiky, unpredictable, short-lived

Decision tree

Predictable for 1+ year?(steady-state usage)YesNoSpans EC2 + Fargate/Lambda?YesNoTolerates 2-min interruption?YesNoComputeSavings PlanFamily will change?YesNoSpot(Fleet or ASG)On-Demand+ Compute OptimizerConvertible RIor Compute SPStandard RIor EC2 Instance SPAlways: run Compute Optimizer for right-sizing
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Capacity commitment for predictable usage

Steady-state EC2/Fargate/Lambda running >70% of any 1- or 3-year window fits a capacity commitment. Reserved Instances are workload-specific; Savings Plans are usage-based across families. RIs apply BEFORE Savings Plans — buy order matters.

15 questions test this
Spot for interruption-tolerant work

Spot Instances use AWS spare capacity at up to 90% off On-Demand. 2-minute interruption notice; allocation strategy price-capacity-optimized is the modern default. Use for stateless workers, batch, big-data, CI fleets. Never for stateful workloads without checkpointing.

1 question tests this
Right-sizing for everyone (Compute Optimizer)

Compute Optimizer analyzes utilization and recommends smaller instances or different families for EC2, EBS, Lambda, ECS-on-Fargate. Lambda recommendations need ≥50 invocations in 14 days. Trusted Advisor surfaces RI / SP recommendations separately.

5 questions test this
RIs apply BEFORE Savings Plans — buying order matters

Each billing hour AWS applies discounts in a fixed order: RIs first (to matching family/region/AZ/OS usage), then Savings Plans (to any remaining eligible usage, highest-discount-first), then on-demand. If you already own RIs covering your baseline, a fresh Compute SP overlapping that usage sits idle — the RIs consume the hours first. Buy SPs to cover un-RI-covered usage, then add RIs only for instance types with reliably steady utilization.

5 questions test this
Exchangeability ladder: Standard RI < Convertible RI < Compute SP

Standard RI: family-locked, can sell on RI Marketplace if no longer needed. Convertible RI: can exchange for a different family/OS/tenancy without selling. Compute SP: cover EC2 + Fargate + Lambda across any family and any region; the most flexible commitment but slightly lower max discount.

11 questions test this
Spot allocation: price-capacity-optimized is the modern default

lowest-price[10] minimizes hourly cost but maximizes interruption risk (cheapest pools are reclaimed first). capacity-optimized launches from the pool with lowest predicted interruption — best for long-running workloads. price-capacity-optimized (current AWS default for Fleet/ASG) balances both. For HPC/ML with instance-type preferences, capacity-optimized-prioritized respects your priority list.

4 questions test this
Lambda Compute Optimizer needs ≥50 invocations in 14 days

Below 50 invocations / 14 days[9], Lambda functions get NO Compute Optimizer recommendation. Exam pattern: 'Compute Optimizer cannot generate a recommendation' for a low-traffic Lambda → root cause is this threshold, not a configuration issue.

1 question tests this
Graviton is the answer when 'reduce cost' meets x86-agnostic

AWS Graviton (ARM64) instances[11] deliver up to 40% better price-performance vs comparable x86. Most managed services support Graviton (RDS, Aurora, ElastiCache, Lambda, Fargate). When the question says 'reduce cost' and doesn't restrict architecture, Graviton is usually a correct answer.

1 question tests this
Fargate Spot: deep discount vs Fargate on-demand; same 2-min notice

Fargate Spot[12] uses spare ECS Fargate capacity at deep discount. Same 2-minute interruption notice as EC2 Spot. Good for: CI builds, fault-tolerant containerized batch, dev/test. Mixed capacity provider: FARGATE for baseline + FARGATE_SPOT for burst.

5 questions test this
Trusted Advisor surfaces RI / SP recommendations

Free Trusted Advisor[13] checks include "underutilized EC2 instances" (right-sizing), "RI optimization", and "Savings Plans recommendations" — once you have ~30 days of usage. Business / Enterprise support tier unlocks the full check set.

Capacity Rebalancing: proactively replaces at-risk Spot Instances before the 2-minute notice

When Capacity Rebalancing is enabled on an Auto Scaling group, it responds to EC2 instance rebalance recommendation signals — which arrive before the 2-minute interruption notice — by launching a replacement instance proactively. Pair it with lifecycle hooks to allow in-flight requests to drain gracefully before the old instance terminates.

4 questions test this
Compute Optimizer: paid Enhanced Infrastructure Metrics extends lookback to 93 days for cyclical workloads

By default Compute Optimizer analyses 14 days of CloudWatch metrics, which misses monthly or quarterly utilization spikes. The Enhanced Infrastructure Metrics paid add-on extends the lookback period to up to 93 days, enabling accurate recommendations for workloads with cyclical billing or processing patterns.

4 questions test this
Compute Optimizer: org-level preferences, no Spot recommendations, RDS MySQL supported

Recommendation preferences (approved instance families, CPU headroom, lookback period) configured from the management account automatically propagate to all member accounts in an AWS Organization, minimizing per-account overhead. Compute Optimizer does NOT generate rightsizing recommendations for Spot Instances. It does support RDS MySQL and PostgreSQL (with Performance Insights) alongside EC2, Lambda, EBS, and ECS.

4 questions test this
Zonal RIs provide a billing discount AND a capacity reservation in that specific AZ

A Regional Reserved Instance applies a billing discount across all AZs in a Region but does NOT reserve capacity. A Zonal Reserved Instance scoped to a specific Availability Zone provides both the billing discount and a guaranteed capacity reservation matching the instance attributes, ensuring instances can launch even during peak demand in that AZ.

4 questions test this
Graviton (ARM) for 20-40% better price-performance

AWS-designed ARM64 processors deliver up to 40% better price-performance vs x86 equivalents. Requires ARM-compatible runtime (most modern languages OK; some Windows AMIs + legacy binaries don't). When the question says "reduce cost" + workload is portable: Graviton.

Also tested in

References

  1. Amazon EC2 Reserved Instances
  2. What are AWS Savings Plans
  3. How Savings Plans apply
  4. Savings Plans overview (types + flexibility)
  5. Amazon EC2 Spot Instances
  6. Spot termination notices + rebalance recommendation
  7. EC2 Auto Scaling Mixed Instances Groups
  8. What is AWS Compute Optimizer
  9. Compute Optimizer requirements
  10. Spot fleet allocation strategies
  11. AWS Graviton processor
  12. Amazon ECS Fargate capacity providers (Fargate Spot)
  13. AWS Trusted Advisor