Savings Plans are a cloud economics pricing model in which a customer commits to a fixed amount of spend per hour, measured in dollars per hour, for a one-year or three-year term, and in return receives discounted rates on eligible usage up to that amount. The model was introduced by AWS, and comparable offerings exist as the Azure savings plan for compute and as spend-based committed use discounts in Google Cloud.
Unlike reserved instances, a savings plan commits to spend rather than to specific instance configurations, so the discount follows workloads across instance families, sizes and in some plan types across regions and services. That flexibility makes Savings Plans a central tool of FinOps for steady compute baselines.
How a savings plan commitment is applied
Every hour, the provider takes the eligible usage of that hour, prices it at the discounted savings plan rate, and deducts the result from the hourly commitment. If usage at discounted rates exceeds the commitment, the excess is billed at on-demand prices. If usage falls short, the unused part of the commitment is still charged and cannot be carried over.
When several plans or discount types overlap, the provider applies them in a defined order, typically reserved instances first, then savings plans, with each plan covering the usage that yields the highest discount percentage first. Within an organization with consolidated billing, an unused commitment in one account can usually be shared with other accounts unless sharing is disabled.
| Option | Choices | Effect on discount |
|---|---|---|
| Term length | 1 year or 3 years | Three years gives the deeper discount |
| Payment | No upfront, partial upfront, all upfront | More upfront payment increases the discount |
| Commitment unit | Dollars per hour of discounted usage | Sets the ceiling of covered spend |
| Scope | Single account or shared across the organization | Sharing improves utilization |
A commitment cannot be canceled or reduced once purchased, so the purchase decision is effectively a financial liability for the full term.
Types of Savings Plans
Plan types differ in how much flexibility they give and how much discount they return. The rule is consistent: the more the commitment is restricted, the larger the discount.
| Plan type | Covers | Flexibility | Relative discount |
|---|---|---|---|
| Compute Savings Plans | EC2, Fargate and Lambda | Any family, size, region and OS | Moderate |
| EC2 Instance Savings Plans | EC2 in one family and region | Any size, OS and tenancy in that family | Highest |
| SageMaker Savings Plans | Machine learning instances | Any instance family and region | Moderate |
Advertised maximum discounts for the deepest three-year, all-upfront options reach roughly two-thirds to about seventy percent off on-demand prices, but actual discounts vary widely by instance type, region and operating system. Realistic blended savings on a compute bill are lower, because no organization covers all of its usage.
Savings Plans compared with other pricing models
Savings Plans are one of several ways to lower the unit price of compute, and each model fits a different predictability and interruption tolerance. The comparison below places them next to the neighboring options in cloud economics.
| Model | Commitment | Flexibility | Best fit |
|---|---|---|---|
| Pay-as-you-go | None | Complete | Unpredictable or short-lived load |
| Savings Plans | Hourly spend for 1 or 3 years | High across instance types | Steady baseline that evolves |
| Reserved instance | Specific configuration for 1 or 3 years | Low to moderate | Fixed, well-known servers |
| Spot instance | None, can be interrupted | Capacity may be reclaimed | Fault-tolerant batch work |
| Google committed use discounts | Spend or resources for 1 or 3 years | Varies by type | Steady Google Cloud usage |
An important practical difference is that reserved instances can include a capacity reservation in a specific zone, whereas Savings Plans are purely a billing discount and guarantee no capacity. Teams that need guaranteed capacity combine savings plans with separate on-demand capacity reservations.
Sizing a commitment
The goal of sizing is to commit to the stable floor of compute spend, not to the average or the peak. Committing at the floor keeps utilization near 100 percent, while the variable portion above it remains on demand or moves to spot capacity.
- Analyze at least 30 to 90 days of hourly usage after rightsizing, because a commitment locks in current inefficiencies.
- Identify the minimum sustained hourly spend and exclude workloads that are being retired or migrated.
- Purchase in several smaller tranches spread over months, which staggers expirations and limits the cost of a forecasting error.
- Track utilization (share of commitment used) and coverage (share of eligible usage discounted) every week.
| Metric pattern | Meaning | Action |
|---|---|---|
| Utilization below 100 percent | Over-commitment, money wasted | Stop buying, shift workloads onto the plan |
| Coverage low, utilization full | Under-commitment | Buy an additional tranche |
| Both high | Well-sized portfolio | Re-evaluate before each expiry |
Risks and common mistakes
The main risk of Savings Plans is paying for capacity that is no longer used after an architecture change, such as a migration to managed services or containers on different pricing. Other frequent mistakes are buying before rightsizing, assuming the plan covers databases or storage when it does not, and letting large plans expire on the same date, which suddenly returns the entire baseline to on-demand prices.
The short version
A savings plan works like a prepaid phone contract. Instead of paying the full price for every minute, a company promises to spend a certain amount every hour for one or three years, and the cloud provider gives a lower price in exchange.
The deal is good when the company really uses at least that much every hour. If it uses less, it still pays the promised amount, so the skill lies in promising only what is certain to be used.
Where it makes a difference
A software company spends between 40 and 70 dollars per hour on compute, with a nightly low that never falls under 40 dollars. After a rightsizing project, the FinOps team buys a three-year Compute Savings Plan of 25 dollars per hour at discounted rates, which covers most of the floor while leaving room for planned container migrations.
Six months later it adds a one-year plan of 5 dollars per hour. Weekly reports show utilization close to 100 percent and coverage of about two-thirds of eligible usage. The compute bill falls noticeably, and when the team moves part of its servers to a different instance family, the discount follows the workload without any exchange.