Skip to content
FR

Design Cost-Optimized Compute Solutions

Step 23 of 28

AWS Compute Cost Optimization: Savings Plans, Spot and Rightsizing

Where this lesson fits

This lesson covers Domain 4: Design Cost-Optimized Architectures, Task 4.2: Design cost-optimized compute solutions. Domain 4 represents 20% of the scored content of SAA-C03. AWS compute cost optimization starts with a workload profile (steady, spiky, interruptible, short-lived, unknown) and ask for the cheapest design that still meets availability and performance requirements.

Use compute selection and Auto Scaling for performance to establish the required capacity first. This lesson focuses on money: choosing the right purchasing option, the right instance size and family, the right service model (EC2, containers, Lambda), and the cost tooling that tells you what to change.

Learning objectives

After this lesson you will be able to:

  • Choose among On-Demand, Reserved Instances, Savings Plans, Spot Instances, Capacity Reservations, and Dedicated options for a described workload.
  • Distinguish Compute Savings Plans, EC2 Instance Savings Plans, and Standard versus Convertible Reserved Instances.
  • Design interruption-tolerant architectures on Spot, including mixed-instance Auto Scaling groups.
  • Right-size using Compute Optimizer, CloudWatch metrics, and Cost Explorer recommendations.
  • Choose between EC2, Lambda, Fargate, and Graviton-based instances on cost grounds.
  • Use scheduled and target-tracking scaling to stop paying for idle capacity.
  • Break down and govern cost with tags, AWS Budgets, Cost Explorer, and the Cost and Usage Report.
  • Compute and compare monthly cost for simple scenarios.

1. The cost levers of compute

Compute cost is the product of how much capacity you run, for how long, and at what price per unit. Every optimization works on one of these three:

Lever What it changes Examples
Quantity Capacity you provision Right-sizing, Auto Scaling, turning off non-production at night
Duration Hours you pay for Scheduled scaling, Lambda (pay per millisecond), stopping idle resources
Unit price Rate per hour Savings Plans, Reserved Instances, Spot, Graviton, newer generation instances

A common mistake is to start with unit price (buy a commitment) before fixing quantity. Committing to capacity you later shrink locks in waste. The order of operations on the exam and in practice is: right-size first, make capacity elastic second, discount the steady remainder last.

2. EC2 purchasing options

Option Commitment Discount (typical, versus On-Demand) Interruptions Best for
On-Demand None; supported OSes bill per second with applicable minimums 0% No Spot reclamation; no capacity reservation Short-term, unpredictable, first deployments of new workloads
Savings Plans $/hour for 1 or 3 years Up to about 72% None Steady baseline usage with flexibility
Reserved Instances (RI) Specific configuration for 1 or 3 years Up to about 72% (Standard), less for Convertible None Steady usage of known instance types
Spot Instances None Up to about 90% Reclaimable; best-effort 2-minute notice for stop/terminate Fault-tolerant, flexible, stateless work
On-Demand Capacity Reservations No term for immediate-use reservations; future-dated reservations can have commitments 0% unless combined with a Savings Plan or Regional RI None Guaranteed capacity in a specific AZ, such as for a planned event
Dedicated Hosts / Instances Optional Higher than shared tenancy None Licensing (bring your own server-bound licences) or compliance

2.1 Savings Plans in detail

Compute and EC2 Instance Savings Plans commit you to a fixed dollar amount per hour for one or three years. Usage up to the commitment is billed at the discounted rate; usage above it is billed On-Demand.

Plan Applies to Flexibility Discount
Compute Savings Plans EC2 (any family, size, Region, OS, tenancy), AWS Fargate, and AWS Lambda Highest: you can move from m5 to c7g, from us-east-1 to eu-west-1, or from EC2 to Fargate Up to about 66%
EC2 Instance Savings Plans One instance family in one Region (any size, OS, tenancy within the family) Medium Up to about 72%
SageMaker AI Savings Plans SageMaker usage Machine learning workloads Up to about 64%

Payment options are All Upfront, Partial Upfront, and No Upfront, with rates depending on plan, term and payment option. Compare actual offered prices, and size the hourly commitment at discounted rates; unused hourly commitment does not roll over.

2.2 Reserved Instances in detail

Type Flexibility Discount Marketplace
Standard RI Fixed family; size flexibility within the family for Regional Linux/Unix RIs with default tenancy Highest (up to about 72%) Can be sold on the Reserved Instance Marketplace
Convertible RI Can be exchanged for another family, OS, or tenancy of equal or greater value Up to about 66% Cannot be sold

A Regional RI discounts matching usage across AZs without reserving capacity. Size flexibility is restricted to eligible Linux/Unix RIs with default tenancy. A Zonal RI reserves capacity in one AZ. RIs also exist for RDS, ElastiCache, OpenSearch, and Redshift (covered in Chapter 13), but EC2 RIs do not discount ordinary Lambda duration or Fargate usage; Compute Savings Plans can cover those. Lambda Managed Instances is a separate exception: EC2 RIs or Savings Plans can discount its underlying EC2 compute, while its management fee remains undiscounted.

Exam tip. "Steady 24/7 workload, will run for at least 3 years, will not change instance family" → EC2 Instance Savings Plan or Standard RI, 3-year. "Steady workload, but we might move to Graviton, change Regions, or adopt containers or Lambda" → Compute Savings Plan. Compare specified flexibility, price and capacity needs rather than choosing from a keyword alone. Savings Plans do not reserve EC2 capacity.

2.3 Spot Instances in detail

Spot Instances use spare EC2 capacity at up to about 90% off. AWS can reclaim them. Stop/terminate notices are best effort and normally provide two minutes through instance metadata and EventBridge; hibernation begins immediately. Checkpoint continuously rather than relying on a guaranteed cleanup window. Therefore Spot suits work that is:

  • Stateless or checkpointed (the work can resume elsewhere).
  • Flexible in time (batch, rendering, CI builds, big-data processing, test fleets).
  • Distributed so that losing a node is a delay and not an outage (web tier behind a load balancer with extra on-demand baseline, container tasks, EMR task nodes).

Good practices that the exam tests:

  1. Diversify across many instance types and AZs so one pool's capacity shortage does not stop you. Use the price-capacity-optimized allocation strategy.
  2. Use a mixed instances policy in an Auto Scaling group: a base of On-Demand capacity (or a covered-by-Savings-Plan baseline) plus a percentage above that on Spot.
  3. Handle interruptions: poll metadata or react to EventBridge events, drain the instance from the load balancer, write checkpoints to S3 or a queue-based design ( SQS) so another worker can retry the item.
  4. Spot Fleet and EC2 Fleet request a target capacity across pools; for a stateful database or a single-instance non-resumable job, Spot is the wrong answer.

2.4 Worked example: choosing purchasing options

Scenario. QuillSoft runs an order-processing platform. It needs at least 20 m6i.xlarge instances 24/7 (they have run for 18 months and will for years), plus a nightly batch of 100 instances for 3 hours that can restart if interrupted, plus a load test fleet used for a few days each quarter. The architects must minimize cost without affecting the order platform's availability.

Step 1: classify each workload.

  • Order platform baseline: steady, interruption-intolerant, known profile.
  • Nightly batch: interruptible, flexible, short.
  • Quarterly load test: short, unpredictable schedule, a few days.

Step 2: select the option.

  • Baseline: 3-year Compute Savings Plan or EC2 Instance Savings Plan sized to cover about 20 instances of baseline spend (never above the baseline, to avoid paying for an unused commitment). A Compute Savings Plan is preferable if a move to Graviton (m7g) is plausible; an EC2 Instance Savings Plan has a deeper discount if the family is certain.
  • Batch: Spot through an Auto Scaling group or AWS Batch with multiple instance types; checkpoint or let SQS redeliver the jobs.
  • Load test: On-Demand (or Spot if the test can tolerate interruption), because no commitment pays off for a few days per quarter.

Step 3: compute the saving. Assume an illustrative On-Demand rate of $0.192 per instance-hour. Then 20 instances for 730 hours cost about $2,803 per month. If the selected 3-year plan gives an assumed 40% effective discount, the cost is about $1,682, saving about $1,121 per month. For the batch: 100 instances × 3 hours × 30 nights = 9,000 instance-hours; On-Demand is about $1,728, Spot at 70% off about $518, saving over $1,200 per month. (Figures are illustrative; the exam gives you the rates or asks only for the relative choice.)

Why not reserve for the batch? A reservation or Savings Plan discount applies to the 24-hour clock; paying for 100 instances all day to use them 3 hours is wasteful, and Spot is both cheaper and appropriate for restartable work. Why not Spot for the order platform? An interruption of every node could drop orders; size any Spot share so the On-Demand base, replacement capacity and interruption handling still meet availability requirements. No fixed minority percentage guarantees that.

3. Right-sizing and instance selection

3.1 How to right-size

Right-sizing means matching instance type and size to measured demand.

  • AWS Compute Optimizer uses CloudWatch metrics (and, with the CloudWatch agent, memory) to classify EC2 instances, Auto Scaling groups, EBS volumes, Lambda functions, and ECS-on-Fargate services as under-provisioned, optimized, or over-provisioned, and recommends new types with estimated savings and performance risk.
  • Cost Explorer rightsizing recommendations flag idle or underused instances (for example maximum CPU below 20% over 14 days) and recommend termination or downsizing.
  • Trusted Advisor cost checks (idle load balancers, low-utilization EC2) are available based on support plan.
  • CloudWatch metrics to watch: CPUUtilization, NetworkIn/Out, and, through the agent, memory and disk. Memory-bound workloads on a compute-optimized family are a classic mismatch.

3.2 Choosing family and generation

Choice Cost effect
Graviton (ARM) instances (m7g, c7g, r7g, t4g) Typically up to about 20% lower price and better price-performance than comparable x86, if the software runs on ARM (most Linux workloads, containers, Java, Python, Node)
Newer generation (m7i versus m5) Benchmark cost per completed unit of work; generation alone does not guarantee a lower bill
Burstable T instances Cheap for low average CPU with occasional bursts; use unlimited mode knowingly, because sustained high CPU incurs surplus credit charges
Right family Memory-optimized (R/X) for in-memory databases, compute-optimized (C) for CPU-bound services; wrong family wastes the dimension you do not use
Instance size Prefer a smaller size with Auto Scaling over a permanently huge instance
Operating system and licensing Windows and licensed OSes add per-hour cost; many Linux distributions avoid commercial OS charges, while others have subscription fees; License Manager and BYOL can lower licensing fees

Exam tip. If an answer says "migrate to Graviton-based instances" and the stem does not mention x86-only software, validate ARM dependencies, throughput, latency and cost per request before selecting it. An x86-only commercial binary or Windows application is incompatible with this proposed ARM migration.

3.3 Worked example: rightsizing evidence

Scenario. A web tier of 12 m5.2xlarge instances (8 vCPU, 32 GiB) shows 12% average and 30% peak CPU, and 6 GiB peak memory. The team wants to cut cost by at least 40% without reducing availability.

Step 1: read the metrics. Peak CPU 30% of 8 vCPU is about 2.4 vCPU, and memory peak 6 GiB of 32 GiB. The instances are over-provisioned on both dimensions.

Step 2: candidates. An m5.large (2 vCPU, 8 GiB) would be too tight at peak for one instance, but an m5.xlarge (4 vCPU, 16 GiB) gives headroom. An m7g.xlarge on Graviton is cheaper still if the application supports ARM. Alternatively, keep the same size and use Auto Scaling to shrink the group outside peak hours.

Step 3: decide. Downsize to m7g.xlarge (or m6i.xlarge) and place the group in an Auto Scaling group with target tracking at 50% CPU across at least two AZs. Cost per instance falls by roughly half for the size change, and a further saving comes from Graviton; then load-test normal peaks and loss of an AZ. The sizing is a candidate, not proof that the 40% saving or failure-mode capacity requirement has been met.

Why not move to Spot only? The web tier serves customers, and a Spot interruption could degrade availability; Spot could be a portion of a mixed policy but not the whole fix. Why not purchase a 3-year Reserved Instance for the current size? Reserving m5.2xlarge would lock in capacity that is double what is needed.

4. Elastic workloads: pay only for what you use

4.1 Auto Scaling policies

Policy Behavior Cost use
Target tracking Keeps a metric near a target, such as 50% average CPU or 1,000 requests per target Default for variable web load; scales in when demand drops
Step / simple scaling Adds or removes fixed amounts at alarm thresholds When you need explicit increments
Scheduled scaling Changes min/max/desired at set times Known patterns, such as business hours or month-end
Predictive scaling Forecasts load from history (daily/weekly cycles) and scales ahead Recurring patterns with slow-starting instances

Set the minimum to meet availability requirements, including sufficient capacity after an AZ loss. Bound maximum capacity to limit group growth, and use a sensible cooldown / warm-up so the group does not thrash and pay for instances that start and stop repeatedly. Maximum group size limits this group’s capacity; it is not a hard account-spending cap.

4.2 Turn it off

Non-production environments are a favorite exam target. A development environment used 10 hours a day, 5 days a week runs about 50 hours out of 168 (30%). Stopping it outside those hours saves about 70%. Implement with scheduled Auto Scaling actions (set minimum, desired and maximum to 0 for the closed period, then restore them), AWS Instance Scheduler, or EventBridge Scheduler calling Systems Manager Automation. Scaling an ASG to zero normally terminates instances rather than merely stopping them, so persist required data externally. Standalone stopped EC2 instances still bill for attached EBS volumes and allocated public IPv4 addresses, so also use snapshots and delete what you do not need.

4.3 Hibernation and warm pools

Warm pools can keep prepared instances stopped, hibernated or running. Stopped instances preserve disk initialization but lose RAM; hibernation preserves RAM in EBS. Stopped/hibernated instances avoid running compute charges but still incur EBS and allocated public IPv4 charges. Running pools also incur compute charges. Use lifecycle hooks to confirm readiness.

5. Service model and cost: EC2, containers, Lambda

The Lambda comparisons and GB-second calculations below refer to ordinary on-demand Lambda Event Functions. Managed Instances, Web Functions and MicroVMs use different pricing models.

Option Pricing unit Cost-effective when Cost-ineffective when
EC2 Instance-second Steady, high utilization, specialized hardware, need for Savings Plans/Spot discounts Very spiky or low utilization (you pay for idle)
Lambda Requests plus GB-second of duration (per millisecond) Spiky, event-driven, low or intermittent traffic; scales to zero Constant, heavy, long-running compute at high concurrency
Fargate vCPU and GB per second for task duration You do not want to manage nodes, variable container load; Fargate Spot for interruptible tasks Large steady fleets where EC2 with Savings Plans is cheaper and bin-packing is possible
ECS/ EKS on EC2 Instance-hour Tightly packed containers, using Spot and Savings Plans Low utilization of nodes
AWS Batch You pay for underlying EC2/Fargate Batch computing with automatic Spot use Interactive, low-latency services
Elastic Beanstalk / App Runner / Lightsail Pay for underlying resources or a fixed plan Small apps with minimal operations (Lightsail has predictable monthly pricing) Large complex systems

5.1 Lambda cost arithmetic

Lambda bills (requests / 1,000,000) × price per million plus GB-seconds × price per GB-second. Increasing memory also increases CPU, so a function sized at 1,769 MB gets a full vCPU. A larger setting can reduce total cost if the duration drops more than proportionally. For example, one million requests at $0.20 per million cost $0.20 for the request component before free tier, not $200,000. Include architecture/Region, provisioned concurrency and other applicable charges separately. Use AWS Lambda Power Tuning or Compute Optimizer recommendations to test memory settings; validate the cheapest measured setting against latency and error requirements.

Example: a function runs 200 ms at 512 MB (0.1 GB-s per invocation) or 80 ms at 1,024 MB (0.08 GB-s per invocation). The larger memory setting costs less per invocation while also being faster, because the GB-seconds fall. For compatible ordinary Lambda functions, compare arm64 duration rates with x86 in the target Region; ARM can reduce duration charges, but benchmark execution time too. Compute Savings Plans also cover Lambda duration at steady scale.

Break-even thinking. Ordinary on-demand Event Functions have no invocation-duration charge while idle, but provisioned concurrency and connected services can still bill. There is no universal requests-per-second break-even: compare memory × duration, concurrency, architecture, commitments and operations costs. Sustained work can favor well-utilized EC2, containers or Lambda Managed Instances; measure the actual design.

5.2 Containers

  • Fargate Spot can reduce Fargate cost by up to about 70% for interruptible tasks, with a 2-minute warning.
  • ECS on EC2 uses Auto Scaling group capacity providers to match node capacity to tasks. EKS can use Karpenter or Cluster Autoscaler to supply Spot-backed nodes for pending pods.
  • Right-size task definitions (vCPU and memory). Over-allocated tasks reduce packing density and, on Fargate, bill for the full allocation.

6. Cost visibility and governance

Optimization needs data. Know which tool answers which question.

Tool Purpose
AWS Cost Explorer Visualize and forecast cost and usage; filter by service, tag, account; Savings Plans and RI recommendations and coverage/utilization reports
AWS Budgets Alerts (and actions) when actual or forecasted cost, usage, or Savings Plans coverage crosses a threshold
AWS Cost and Usage Report (CUR) Detailed billing line items in S3; Data Exports CUR 2.0 is the recommended export format; query with Athena
Cost allocation tags Attribute cost to teams, projects, environments; must be activated in Billing
AWS Cost Anomaly Detection Machine-learning alerts on unusual spend
AWS Organizations consolidated billing One bill, sharing of Reserved Instance and Savings Plans discounts across member accounts, and combined volume discounts
Compute Optimizer / Trusted Advisor Rightsizing and idle resource findings
AWS Pricing Calculator Estimate the cost of a new architecture before building
Service Quotas, SCPs, or budget actions Prevent runaway spend, such as denying very large instance types in sandbox accounts

Coverage and utilization. Utilization tells you how much of your commitment you actually use (target near 100%); coverage tells you how much of your eligible usage is discounted by commitments (raise it gradually). Buy commitments for the stable minimum, not the peak. Budgets notifications and actions depend on delayed billing data and do not impose an instant spending ceiling. Discount sharing also depends on organization and account settings.

7. Common pitfalls and exam tips

  • Do not commit before right-sizing. A 3-year commitment on oversized instances locks in the waste. (Savings Plans are in dollars per hour, so after right-sizing you may be unable to use the whole commitment.)
  • Spot is never right for stateful, uninterruptible, or latency-critical single points. It is right for batch, stateless fleets, and flexible workloads, always with diversification.
  • Dedicated Hosts require a licensing and utilization analysis. Eligible BYOL savings may justify the host charge; they are not the default choice for generic stateless servers.
  • Ordinary On-Demand Capacity Reservations do not discount by themselves. They reserve matching AZ capacity; pair eligible usage with Savings Plans or Regional RIs for price.
  • Lambda is not always cheapest. Steady heavy load favors EC2 or containers with commitments.
  • Idle resources bill too: unassociated Elastic IPs, idle load balancers, stopped instances' EBS volumes.
  • Savings Plans versus RIs: if a stem requires selling unused reservations, that is the RI Marketplace; Savings Plans cannot be sold.
  • Consolidated billing lets one account's unused RI or Savings Plan benefit be applied to another account in the organization.
  • Exam tip: In "most cost-effective" questions, check the words steady, interruptible, unpredictable, and short-term. They map to Savings Plans/RI, Spot, Lambda or Auto Scaling, and On-Demand respectively.

8. Mini case study (with solution)

Scenario. PixelForge, a video rendering startup, has three workloads. (1) A customer-facing web and API tier on 8 EC2 instances that must run 24/7, with traffic doubling during weekday evenings. (2) A rendering farm that processes uploaded clips from an SQS queue; each clip takes 5 to 20 minutes, and jobs can be retried; volume ranges from 0 to 800 concurrent jobs. (3) A thumbnail function triggered by S3 uploads, about 200,000 invocations per month at 300 ms and 512 MB. Developers also keep a staging environment of 6 instances running continuously. The finance team wants the lowest bill with no reduction in customer-facing availability.

Solution.

  1. Web and API tier: right-size using Compute Optimizer, move to Graviton if the stack permits, use an Auto Scaling group across two AZs with target tracking and a scheduled action for the evening peak. Cover the stable baseline (the minimum that always runs, for example 6 instances) with a 1-year or 3-year Compute Savings Plan; the evening burst runs On-Demand.
  2. Rendering farm: use Spot Instances in an Auto Scaling group (or AWS Batch) with many instance types and AZs, scaling on the SQS queue depth per instance (backlog-per-instance metric). Use a visibility timeout longer than processing, extend it for long jobs, and write outputs idempotently. An interrupted message becomes eligible for retry after visibility expires; retries must not duplicate completed results. For the queue architecture, review events, serverless processing and loose coupling. Scale to zero when the queue is empty.
  3. Thumbnails: keep on Lambda. The stated load consumes 200,000 × 0.5 GB × 0.3 seconds = 30,000 GB-seconds, plus 200,000 requests, before free-tier allowances or other charges. Compare Region/architecture rates; use arm64 only after compatibility and performance testing.
  4. Staging: apply scheduled scaling or Instance Scheduler to run only during working hours (about 30% of the week), saving about 70% of the compute cost.
  5. Governance: activate cost allocation tags (team, env), create AWS Budgets with alerts, and enable Cost Anomaly Detection.

Why not buy Savings Plans for the render farm? Its usage is spiky and often zero; a commitment would be billed even when idle. Why not Spot for the web tier? Customer-facing availability is a stated constraint. Why not move thumbnails to EC2? A permanently running instance would add idle compute capacity for this intermittent workload; compare its full cost with the measured function bill.

9. Key terms

  • Savings Plan: commitment to a dollar-per-hour spend in return for a discount.
  • Compute Savings Plan: most flexible plan, covering EC2, Fargate, and Lambda.
  • Reserved Instance (RI): discounted billing for a specific EC2 configuration over 1 or 3 years.
  • Spot Instance: spare EC2 capacity that can be reclaimed; interruption notice is best effort.
  • Right-sizing: matching resources to measured demand.
  • Graviton: AWS ARM-based processors with better price-performance.
  • Target tracking: Auto Scaling policy that holds a metric near a target.
  • Compute Optimizer: service giving rightsizing recommendations from metrics.
  • Coverage / utilization: share of usage covered by commitments / share of commitments used.
  • Consolidated billing: single bill and shared discounts across an AWS Organization.

10. Summary checklist

  • I can pick between On-Demand, Savings Plans, RIs, Spot, and Capacity Reservations from a workload description.
  • I can distinguish Compute from EC2 Instance Savings Plans and Standard from Convertible RIs.
  • I can design a Spot-tolerant architecture with diversification and interruption handling.
  • I can right-size with Compute Optimizer and metrics, and know when Graviton is a valid saving.
  • I can choose scheduled, target-tracking, or predictive scaling and turn off non-production resources.
  • I can compare EC2, Lambda, and Fargate on cost for a given load.
  • I can use Cost Explorer, Budgets, CUR, tags, and Organizations to see and control spend.

Stopping compute does not remove its data-storage bill. Review EBS, snapshots and storage lifecycle costs when calculating the total saving.

Sources