There's a particular type of AWS cost that nobody consciously chooses. It doesn't show up as a line item with a label that says "money we could have saved." It just appears, month after month, as part of the total, indistinguishable from everything else.

That's the cost of staying on On-Demand pricing for workloads that have been running the same way for a year or more.

This post explains the difference between On-Demand and commitment-based pricing, why most organisations underspend on commitments, and what a more deliberate approach looks like.

On-Demand: The Default That Keeps Costing You

On-Demand pricing is AWS's standard rate. You pay for what you use, by the hour or the second, with no upfront commitment and no minimum term. It's genuinely useful for variable or unpredictable workloads: things you spin up temporarily, workloads that spike and fall in ways you can't predict.

But On-Demand is also the default. Which means that unless someone has made an active decision to move to something cheaper, that's what you're paying, even for infrastructure that has been running continuously for two or three years without meaningful change.

AWS doesn't nudge you to optimise. On-Demand is profitable for them.

Reserved Instances and Savings Plans

AWS offers two main mechanisms for commitment-based pricing.

Reserved Instances (RIs) are a commitment to use a specific instance type in a specific region for one or three years. In exchange, you receive a discount that can reach 60–72% compared to On-Demand rates, depending on the instance family, region, and whether you pay upfront. They're well-suited to stable workloads where you know what you're running and you're confident it won't change significantly.

Savings Plans are more flexible. Rather than committing to a specific instance type, you commit to a minimum level of spend per hour, measured in dollars, across a defined scope. Compute Savings Plans are the most flexible, applying across instance families, sizes, regions, and even across EC2, Fargate, and Lambda. They offer slightly lower discounts than RIs but significantly more headroom to change.

Both mechanisms work by rewarding predictability. If your infrastructure is broadly stable, you're leaving money on the table by not using them.

Why Most Organisations Don't Act on This

The gap between knowing and doing is real. Most engineering teams are aware that commitment pricing exists. Most CFOs would approve it if it were put in front of them clearly. So why does it so often go unaddressed?

A few reasons come up repeatedly:

Lack of baseline clarity. Before you can commit, you need to know what your stable baseline actually looks like: what's running consistently versus what fluctuates. Without a clear picture of your usage patterns, commitment decisions feel like guesswork.

Organisational friction. Reserved Instance purchases and Savings Plans commitments typically require finance involvement. They're not the same kind of decision as spinning up a new EC2 instance. Getting that decision through the right approval process takes time and energy, and it often gets deprioritised in favour of work that feels more urgent.

Fear of over-committing. There's a reasonable concern about committing to capacity you might not need if workloads change. This is a genuine risk, but it's manageable with proper analysis, and it's often exaggerated. Unused RIs aren't worthless; they can sometimes be sold on the AWS Marketplace, and the risk of modest over-commitment is usually smaller than the cost of indefinite On-Demand pricing.

No one owns it. In many organisations, cloud spend sits in an ambiguous space between finance and engineering. Engineers see it as a billing problem. Finance sees it as a technical one. Without clear ownership, nothing changes.

What Good Looks Like

A mature approach to AWS commitment pricing involves a few things.

First, a clear view of your usage patterns over a rolling 12-month period, understanding which workloads are stable and predictable versus which are genuinely variable.

Second, a commitment strategy that covers the stable baseline without over-reaching into variable capacity. Savings Plans tend to be the right starting point for most organisations because they tolerate change better than RIs.

Third, a regular review cadence, at least quarterly, to assess whether your commitments still match your actual usage, and to top up or adjust as the environment evolves.

None of this is technically complex. It's largely an analytical and governance exercise. But it requires someone to own it and see it through.

The Compounding Effect

The reason this matters more than it might initially appear is the compounding effect over time. A business paying On-Demand rates for workloads that would qualify for a 40% discount isn't just overpaying this month. It's overpaid for every month since those workloads became stable, and it will keep overpaying until someone acts.

There's no point in recovering sunk cost. But there is every reason to stop the clock.