11 · Compute & Storage Cost Optimization¶

Domain 4 — Design Cost-Optimized Architectures · 20%

The heart of this topic is EC2 purchasing options — matching On-Demand, Reserved Instances, Savings Plans, and Spot to a workload's shape — plus storage lifecycle to move cold data to cheaper tiers. Almost every cost question is "what's the cheapest option that still meets the constraint."

Core concept¶

Cost optimization = pay the least for what the workload actually needs. For compute, that means matching a purchasing model to the workload's predictability and interruptibility. For storage, it means putting data in the cheapest tier its access pattern allows and deleting what you don't need.

EC2 purchasing options (the core table)¶

Model	Commitment	Discount vs On-Demand	Best for
On-Demand	None	0 (baseline)	Short-term, spiky, unpredictable, dev/test
Reserved Instances (RI)	1 or 3 yr, specific config	Up to ~72%	Steady, predictable, always-on baseline
Savings Plans	1 or 3 yr, commit \$/hour	Up to ~72%	Steady usage, but want flexibility
Spot Instances	None (interruptible)	Up to ~90%	Fault-tolerant, flexible, stateless, batch
Dedicated Hosts / Instances	Optional	Most expensive	Licensing / compliance (physical isolation)

How to choose on the exam:

Predictable, always-on baseline → RI or Savings Plans (commit for the discount).
Interruptible / fault-tolerant / stateless (batch, CI, big data workers) → Spot (cheapest, but can be reclaimed with a 2-minute warning).
Short-term or unpredictable → On-Demand.
Real systems combine them: RIs/Savings Plans for the steady baseline + On-Demand or Spot for variable/burst capacity.

Reserved Instances vs Savings Plans¶

RIs commit to a specific instance configuration. Standard RIs give the biggest discount but are rigid; Convertible RIs allow changing the instance family for a smaller discount. Payment: All / Partial / No upfront (more upfront = bigger discount).
Savings Plans commit to a dollars-per-hour spend instead of a specific instance.
- Compute Savings Plans — the most flexible: apply across any instance family, size, Region, OS, tenancy, and even Fargate and Lambda.
- EC2 Instance Savings Plans — locked to a family in a Region, for a slightly bigger discount.
Reflex: want commitment savings with flexibility → Compute Savings Plans; the exam increasingly favors Savings Plans over classic RIs.

Spot ≠ guaranteed

Spot capacity can be reclaimed by AWS at any time (2-minute notice). Never put a stateful, must-not-be-interrupted workload on Spot. It's ideal for batch, rendering, CI, and other work that can checkpoint and resume.

Storage cost optimization¶

S3 lifecycle policies — automatically transition objects to cheaper classes over time (e.g. Standard → Standard-IA after 30 days → Glacier → Deep Archive) and expire them when no longer needed. Use when the access pattern is predictable by age.
S3 Intelligent-Tiering — when the access pattern is unknown/changing, let AWS move objects between tiers automatically (no retrieval fees for the moves).
Pick the right class up front — One Zone-IA for reproducible data, Glacier/Deep Archive for archives (see Topic 8 for the minimum-duration charges).
EBS — gp3 is cheaper than gp2 for equivalent performance; delete unattached volumes and old snapshots (automate snapshots with Data Lifecycle Manager); right-size over-provisioned volumes.
S3 Storage Lens gives org-wide visibility into storage usage and cost-saving opportunities.

Right-sizing and eliminating waste¶

AWS Compute Optimizer — analyzes utilization and recommends right-sized EC2 instances, Auto Scaling groups, EBS volumes, and Lambda memory.
Auto Scaling — scale to match demand so you're not paying for idle capacity.
Turn off idle resources — stop dev/test instances outside business hours; release unattached Elastic IPs (they bill when unassociated); remove idle load balancers.

Worked example — mixed workload, cheapest safe design¶

A company runs a steady baseline of 10 web servers 24/7 all year, plus bursty extra capacity during daily peaks, plus a nightly batch job that is fault-tolerant and can restart if interrupted. What's the most cost-effective purchasing mix?

Answer

Split by workload shape:

Steady 24/7 baseline (10 servers) → Reserved Instances or a Savings Plan (1- or 3-year commitment) for up to ~72% off predictable, always-on capacity.
Bursty daily peak capacity → On-Demand (or a Savings Plan sized to the typical peak) — flexible, no commitment for capacity you don't always need.
Fault-tolerant nightly batch → Spot Instances — up to ~90% off, and interruptions are fine because the job can restart.

Putting everything on On-Demand overpays for the baseline; putting the baseline on Spot risks interruption of production. Matching each shape to the right model is the cost-optimized answer.

Exam traps¶

Predictable/always-on → RI or Savings Plans; interruptible → Spot; short/unpredictable → On-Demand. Mix them for mixed workloads.
Spot = up to 90% off but can be reclaimed (2-min warning) — only for fault-tolerant/stateless.
Compute Savings Plans are the most flexible (any family/Region/OS + Fargate + Lambda); Standard RIs give the biggest but most rigid discount.
Lifecycle policies for predictable-by-age data; Intelligent-Tiering for unknown patterns.
gp3 is cheaper than gp2; delete unattached EBS volumes and unassociated Elastic IPs.
Compute Optimizer = right-sizing recommendations.
Don't pick Dedicated Hosts for cost — they're for licensing/compliance and cost more.

Practice questions¶

Q1. A company will run a fixed set of production servers 24/7 for the next three years and wants the lowest cost for this steady usage. What should it purchase?

A. On-Demand Instances
B. Spot Instances
C. A 3-year Savings Plan or Reserved Instances
D. Dedicated Hosts

Answer: C

C. A 3-year commitment via Savings Plans or RIs gives the deepest discount for predictable, always-on usage. On-Demand (A) is most expensive for steady load; Spot (B) can be interrupted, unfit for guaranteed production baseline; Dedicated Hosts (D) are for licensing/compliance and cost more.

Q2. A nightly data-processing job is fault-tolerant and can restart from a checkpoint if interrupted. The team wants the lowest compute cost. Which option?

A. Reserved Instances
B. Spot Instances
C. On-Demand Instances
D. A Compute Savings Plan

Answer: B

B. Spot Instances offer the largest discount (up to ~90%) and suit interruptible, fault-tolerant batch work. RIs and Savings Plans (A, D) fit steady long-running usage, not a short nightly job. On-Demand (C) is far more expensive for the same interruptible work.

Q3. A company wants commitment-level savings but needs the flexibility to change instance families and Regions over the term, and to also cover some Fargate and Lambda usage. Which is best?

A. Standard Reserved Instances
B. Compute Savings Plan
C. EC2 Instance Savings Plan
D. Spot Instances

Answer: B

B. Compute Savings Plans apply across any instance family, size, Region, OS, and tenancy — and cover Fargate and Lambda — while still giving commitment discounts. Standard RIs (A) are rigid; EC2 Instance Savings Plans (C) lock to a family/Region; Spot (D) has no commitment and is interruptible.

Q4. Log files in S3 are accessed frequently for 30 days, rarely for the next 60 days, and then must be archived for years at the lowest cost. Access frequency is predictable by age. What's the most cost-effective approach?

A. Keep everything in S3 Standard.
B. A lifecycle policy: Standard → Standard-IA at 30 days → Glacier/Deep Archive later.
C. S3 Intelligent-Tiering only.
D. Store the logs on EBS volumes.

Answer: B

B. Because access is predictable by age, a lifecycle policy transitioning objects to cheaper classes over time (and eventually to Glacier/Deep Archive) minimizes cost. Standard only (A) overpays. Intelligent-Tiering (C) fits unknown patterns and adds a monitoring fee that's unnecessary here. EBS (D) is far more expensive per GB than S3 for logs.

Q5. Which action helps identify right-sizing opportunities across EC2 instances, EBS volumes, and Lambda functions based on actual utilization?

A. Enable AWS Compute Optimizer
B. Buy more Reserved Instances
C. Switch all volumes to io2
D. Move everything to On-Demand

Answer: A

A. AWS Compute Optimizer analyzes utilization metrics and recommends right-sized resources (EC2, ASG, EBS, Lambda), reducing waste. Buying more RIs (B) commits spend without right-sizing; io2 everywhere (C) raises cost; On-Demand (D) is a billing model, not a right-sizing analysis.

Next: 12 · Cost Management Tools → · Revise — Cost Optimization