Savings Plans

Savings Plans are a commitment-based cloud pricing model, offered by providers including Amazon Web Services and Microsoft Azure, that reduces the hourly rate charged for compute usage in exchange for a customer's commitment to a consistent amount of spend, measured in dollars per hour, over a one-year or three-year term. For FinOps teams, Savings Plans lower the unit rate paid for compute without requiring any change to the underlying architecture, but that lower rate comes with a forecasting and coverage-tracking obligation that has to be managed continuously, not set once and forgotten. The commitment applies to a dollar amount of usage per hour, not to a specific resource, and it does not move automatically if the workloads generating that usage change shape.

Understanding Savings Plans

A Savings Plan commitment is defined in dollars per hour of usage, not in a specific instance type, size, or region. This is the central difference from Reserved Instances, which discount a specific instance family, region, and operating system combination rather than a flat spend amount. Because the commitment is expressed in dollars, AWS applies the discount automatically to any matching usage without requiring the customer to manually assign or exchange reservations.

AWS Savings Plans run for a one-year or three-year term, with no upfront, partial upfront, or all upfront payment options, each offering a different discount depth in exchange for how much is paid at signing. Once purchased, a Savings Plan commitment cannot be canceled, and any committed spend that usage doesn't consume in a given hour is forfeited rather than rolled over to a future hour. This use-it-or-lose-it structure is why sizing the commitment accurately, rather than optimistically, matters more than the discount rate itself.

Types of Savings Plans

AWS offers three Savings Plans types, each trading a different amount of flexibility for the same underlying discount mechanism. Compute Savings Plans apply across instance family, region, operating system, and compute service, covering Amazon EC2, AWS Fargate, and AWS Lambda usage under a single commitment. EC2 Instance Savings Plans trade that breadth for depth: they are locked to a specific instance family within a region but remain flexible across instance size, operating system, and tenancy. SageMaker Savings Plans apply narrowly, covering only Amazon SageMaker machine learning instance usage, and suit teams whose training or inference workloads are a defined, ongoing line item rather than a small piece of a broader compute footprint.

Microsoft Azure offers a comparable mechanism, Azure savings plan for compute, which also discounts compute usage in exchange for a committed hourly spend over a one-year or three-year term. Google Cloud does not offer a product called Savings Plans. Its nearest equivalent is Committed Use Discounts, a differently structured commitment that can be tied to specific resources or to a flexible spend amount depending on the discount type chosen. Teams comparing discount strategies across providers should treat these as related but distinct mechanisms rather than assuming identical terms.

Savings Plans and Rate Optimization

Two metrics determine whether a Savings Plan commitment is actually working: coverage and utilization. Coverage measures the share of eligible compute usage that a Savings Plan discount applies to, while utilization measures the share of the committed dollar amount that gets consumed by matching usage each hour. A team can have high coverage and low utilization if it over-committed relative to actual usage, and it can have high utilization and low coverage if a large share of eligible usage sits outside any commitment. Reading either metric alone hides half the picture; both need to be tracked together to know whether the commitment is delivering real rate optimization.

A Savings Plan reduces the rate paid per hour of committed usage; it does not reduce the volume of usage generating that rate. Underutilized or oversized instances covered by a Savings Plan still cost money, just at a discounted rate, which means the commitment can mask waste that would otherwise be visible on an on-demand bill. Cost visibility work has to separately confirm that the usage underneath a commitment is actually needed, not simply that the commitment is well utilized.

Committing to a dollar-per-hour compute baseline ahead of a planned architecture change carries real risk. A team that signs a three-year Savings Plan and then migrates a workload to a serverless architecture, or shifts to a different instance family, can strand part of that commitment, paying for spend that no longer has matching usage to consume it. This risk is why FinOps teams typically size commitments against a stable, trailing usage baseline rather than against usage that's expected to change soon. Commitment coverage is also usually tracked at the account or organizational level, which complicates attributing the resulting discount to a specific team or product for chargeback purposes.

Managing Savings Plans Commitments

Sizing a Savings Plan commitment against a trailing steady-state usage baseline, commonly 30 to 60 days of stable usage rather than a recent peak, reduces the risk of committing to more spend than the workload will actually consume. Leaving deliberate coverage headroom, rather than committing to 100% of current usage, gives a team room to absorb a planned architecture change without stranding part of the commitment.

Commitments should be reviewed on a recurring cadence, typically at each renewal or whenever a major architecture change is planned, so coverage and utilization stay aligned with actual usage rather than decaying quietly over a one-year or three-year term. Tools like Infracost estimate the cost of infrastructure changes defined in Terraform before they are deployed, which gives teams visibility into how a planned change might shift usage relative to an existing Savings Plan commitment before that change reaches production, rather than after the next invoice arrives.

Related Concepts

Opportunity Cost: Committing budget to a Savings Plan ahead of a planned architecture change is a direct instance of opportunity cost, since the commitment forecloses the flexibility to change course without financial penalty.

Cloud Cost Forecasting: Sizing a Savings Plans commitment correctly depends on forecasting future compute usage accurately, not just reading current spend.

Spot and Preemptible Capacity: Spot and preemptible capacity trade availability for a discount, the inverse of a Savings Plan, which trades a spend commitment for a discount, giving the two approaches opposite risk profiles.

Multi-Cloud Cost Optimization: Because Savings Plans are provider-specific commitments, they add complexity to rate optimization for teams running workloads across more than one cloud provider.

Frequently Asked Questions (FAQs)

What are Savings Plans?

Savings Plans are a commitment-based pricing model, offered by providers including Amazon Web Services and Microsoft Azure, that reduces the hourly rate for compute usage in exchange for a customer's commitment to a consistent amount of spend over a one-year or three-year term. Savings Plans apply automatically to matching usage without requiring a specific resource to be reserved. The discount comes from the commitment itself, not from any change to the underlying infrastructure.

How do Savings Plans differ from Reserved Instances?

Savings Plans commit to a dollar amount of spend per hour, while Reserved Instances commit to a specific instance family, region, and operating system combination. This makes Savings Plans more flexible, since the discount follows usage automatically, while Reserved Instances require usage to match the exact reserved resource to receive the discount. Both are commitment-based discount instruments, but Savings Plans trade some of the discount depth Reserved Instances offer for that added flexibility.

What happens to a Savings Plans commitment if usage drops?

If usage drops below the committed dollar amount, the unused portion of the Savings Plans commitment is forfeited for that hour rather than rolled over or refunded. The customer still pays the full committed amount regardless of whether matching usage exists to consume it. This is why sizing a Savings Plans commitment against a stable usage baseline matters more than the headline discount rate.

How do you measure Savings Plans coverage and utilization?

Savings Plans coverage measures the share of eligible compute usage that a commitment's discount applies to, while utilization measures the share of the committed dollar amount actually consumed by matching usage. Both metrics need to be tracked together, since high coverage with low utilization signals over-commitment, and low coverage with high utilization signals eligible usage sitting outside any commitment. Cloud provider billing consoles and cost management tools typically report both metrics separately.

Can you cancel or modify a Savings Plans commitment?

A Savings Plans commitment cannot be canceled once purchased, and its term and committed dollar amount remain fixed for the duration of the contract. Customers can layer additional Savings Plans on top of an existing commitment as usage grows, but cannot reduce or exit a commitment already in place. This inflexibility is why sizing the initial commitment carefully matters more than trying to correct it later.

Do Savings Plans apply across different cloud providers?

Savings Plans commitments are specific to the provider that issued them and do not transfer across providers. Amazon Web Services and Microsoft Azure both offer a Savings Plans style mechanism, while Google Cloud's nearest equivalent, Committed Use Discounts, uses a differently structured commitment. Teams running workloads across more than one cloud provider need a separate commitment strategy for each one.