Excessive On-Demand Compute Spend Due to Low Savings Plan and Reserved Instance Coverage

Jason DiDomenico

CER:

CER-0324

Service Category

Compute

Cloud Provider

AWS

Service Name

AWS EC2

Inefficiency Type

Suboptimal Pricing Model

Explanation

AWS compute services charge the full published On-Demand rate when no commitment-based discount — such as a Savings Plan (SP) or Reserved Instance (RI) — is in effect. On-Demand pricing provides maximum flexibility, but it is also the most expensive way to run workloads that have stable, predictable usage patterns. When an organization runs a large share of its steady-state compute at On-Demand rates instead of covering that baseline with SPs or RIs, it is effectively paying a premium for capacity it could have committed to at a materially lower cost.

This inefficiency is one of the most common and impactful cost optimization gaps in AWS environments. It typically arises from a lack of commitment ownership, insufficient workload analysis to identify stable baselines, organizational silos that limit visibility into aggregate usage patterns, or hesitation around long-term contracts. The cost impact scales directly with compute spend — organizations with significant monthly compute bills can leave substantial savings on the table by failing to commit their predictable baseline. Two key dimensions define the gap: coverage (what percentage of eligible usage is protected by commitments) and utilization (whether purchased commitments are being fully consumed).

Compute Savings Plans commit to a consistent dollar-per-hour spend and automatically apply across EC2 (any instance family, size, region, OS, or tenancy), Fargate, and Lambda usage. EC2 Instance Savings Plans also commit to a dollar-per-hour spend but are scoped to a specific instance family within a chosen region, offering deeper discounts in exchange for reduced flexibility while still allowing changes across sizes, operating systems, and tenancy within that family. Reserved Instances commit to specific EC2 instance configurations. Standard Reserved Instances provide the highest discounts but cannot be exchanged; Convertible Reserved Instances offer slightly lower discounts but can be exchanged for different configurations during the term. All require one-year or three-year terms. Savings Plans with an hourly commitment of $100 or less can be returned within seven days of purchase, provided the return occurs within the same calendar month; once the calendar month ends, they can no longer be returned. Standard Reserved Instances can be sold on the Reserved Instance Marketplace under certain conditions, including a minimum 30-day holding period and at least one month remaining in the term, though Reserved Instances purchased at a discount or originally acquired from the marketplace cannot be resold. The goal is not to commit all usage — only the stable baseline. Variable and burst capacity should remain On-Demand. When commitments expire, usage silently reverts to full On-Demand pricing, which can also contribute to coverage erosion over time if renewals are not actively managed.

Relevant Billing Model

AWS compute billing varies by service but follows a common pattern: usage is metered on a per-unit-of-time basis, and the rate applied depends on the pricing model in effect.

EC2 instances are billed per-second (with a 60-second minimum) based on instance type, size, and region while in a running state.
Fargate tasks are billed based on vCPU and memory resources allocated, calculated per-second from container image download until task termination.
Lambda functions are billed based on the number of requests and compute duration measured in GB-seconds.

Three pricing models determine the effective rate:

On-Demand — the full published rate with no commitment, offering maximum flexibility at the highest cost per unit of compute.
Savings Plans — discounted rates in exchange for committing to a consistent dollar-per-hour spend for one or three years. Compute Savings Plans apply across EC2 (any instance family, size, region, OS, or tenancy), Fargate, and Lambda. EC2 Instance Savings Plans offer deeper discounts but are scoped to a specific instance family within a chosen region, though they apply across sizes, operating systems, and tenancy within that family.
Reserved Instances — discounted rates in exchange for committing to specific EC2 instance configurations for one or three years. Applicable only to EC2. Standard Reserved Instances provide the highest discounts but cannot be exchanged; Convertible Reserved Instances offer slightly lower discounts but can be exchanged for different configurations during the term. Payment options (All Upfront, Partial Upfront, No Upfront) affect the total discount, with All Upfront providing the highest savings.

Savings Plans apply to usage only after Reserved Instances are applied, and EC2 Instance Savings Plans are applied before Compute Savings Plans. Reserved Instances are billed for every hour of the term regardless of whether instances are running, while Savings Plans charge based on committed hourly spend regardless of actual usage. Savings Plans with an hourly commitment of $100 or less can be returned within seven days of purchase, provided the return occurs within the same calendar month; once the calendar month ends, they can no longer be returned. Standard Reserved Instances can be sold on the Reserved Instance Marketplace under certain conditions, including a minimum 30-day holding period and at least one month remaining in the term, though Reserved Instances purchased at a discount or originally acquired from the marketplace cannot be resold.

Detection

Identify the proportion of total EC2, Fargate, and Lambda compute spend that is being charged at On-Demand rates versus commitment-based rates.
Review historical compute usage over a representative period to determine whether usage patterns are stable and predictable enough to warrant commitment coverage.
Assess commitment coverage levels — the percentage of eligible compute usage protected by active Savings Plans or Reserved Instances — and flag accounts or services with consistently low coverage.
Evaluate whether existing commitments are nearing expiration, which would cause usage to silently revert to On-Demand pricing.
Examine usage patterns across organizational units, accounts, and teams to identify silos where commitment strategy is absent or inconsistent.
Confirm whether workloads running continuously lack any form of commitment backing.
Review commitment utilization rates to ensure that any existing Savings Plans or Reserved Instances are being fully consumed before adding new commitments.

Remediation

Analyze historical compute usage to identify the stable baseline — the minimum level of consistent usage over a representative period — and size commitments to cover only that baseline, leaving variable and burst demand at On-Demand rates.
Select the appropriate commitment type based on workload characteristics: Compute Savings Plans for broad flexibility across EC2, Fargate, and Lambda with discounts up to 66%; EC2 Instance Savings Plans or Reserved Instances for deeper discounts up to 72% on a specific instance family within a region.
Establish a regular cadence for reviewing commitment coverage and utilization, ensuring that expiring commitments are renewed or replaced before usage reverts to On-Demand pricing.
Assign clear ownership for commitment purchasing strategy — whether centralized in a FinOps team or delegated to business units — so that coverage decisions are actively managed rather than ad hoc.
Start conservatively with shorter-term (one-year) or No Upfront commitments to reduce risk, then increase commitment depth as confidence in workload stability grows.
Evaluate whether Compute Saving Plans or Convertible Reserved Instances are appropriate for workloads that may change instance types over time, since these can be exchanged for different configurations during the term.

Relevant Documentation

Submit Feedback