Why Your AWS Bill Keeps Surprising You
Your AWS discount is only a saving if the workload still exists next year
Buying AWS commitments can look like sensible cloud housekeeping. The workload is steady, the discount is attractive, and the recommendation seems to make the business case for you. Everyone wants to pay less for infrastructure they already use.
Then the business changes.
A product team accelerates a migration. A region strategy shifts. A customer workload changes shape. A new architecture moves compute from EC2 into containers, serverless or a managed service. Yesterday’s sensible discount starts to look like tomorrow’s fixed cost.
That is the AWS commitment dilemma. Reserved Instances and Savings Plans can cut AWS spend hard, but most commitments cannot be resold once purchased, so you carry that discounted spend whether or not your usage holds. A commitment strategy needs to account for both the forecast usage at the time of purchase and the risk that future usage shifts in ways you didn't anticipate.
Strategic Blue’s proposition relieves exactly this tension. The company helps organisations cut AWS costs without sacrificing flexibility, optimising AWS pricing and managing Reserved Instance and Savings Plan commitments. The shift that makes commitments safe is treating them as an ongoing isk management discipline rather than an ad hoc procurement task.
IN SHORT
The AWS commitment dilemma is what you face when you buy Reserved Instances or Savings Plans to save money, then your usage moves and the commitment no longer fits. The discount turns into underused, hard-to-explain, roadmap-blocking cost. Avoiding it means matching commitment depth to the flexibility your roadmap actually needs.
What is the AWS commitment dilemma?
The AWS commitment dilemma is what you face when an organisation buys Reserved Instances or Savings Plans to reduce cloud costs, but future usage falls below the commitment. The commitment becomes underutilised, gets harder to explain to finance, or constrains engineers who need to modernise, migrate or resize workloads, but don't want that to drive commitment wastage.
Savings Plans are powerful because they trade a lower price for a promise: a set amount of spend on compute, measured per hour, for one or three years. AWS states that Savings Plans can deliver up to 72% savings on eligible compute compared with On-Demand pricing. That is the reward. The risk is keeping the commitment well matched to usage that keeps moving, especially when you can't sell back the Savings Plan if usage lowers during the commitment term.
“Savings Plans provide savings beyond On-Demand rates in exchange for a commitment of using a specified amount of compute power, measured per hour, for a one or three year period.” Source: AWS Savings Plans documentation
The useful framing for any buyer is to ask how much they can safely commit while keeping the flexibility their roadmap needs, before asking how much they could save by committing.
Savings Plans vs Reserved Instances at a glance
Both lower the rate you pay for steady usage. They differ in what you commit to and how much room you keep to change direction afterwards.
| |
Savings Plans |
Reserved Instances |
| You commit to |
A fixed amount of compute spend per hour, for 1 or 3 years |
A specific instance profile (family, often Region), for 1 or 3 years |
| Flexibility |
Compute Savings Plans apply automatically across eligible EC2, Fargate, and Lambda usage. This can help cover a portfolio of uncorrelated workloads that are hard to commit to individually but more stable in aggregate. |
Standard RIs are more rigid and suit known EC2 usage, although they may be resold on the AWS Secondary RI Marketplace where eligibility, demand, and marketplace rules allow. Convertible RIs can be exchanged to cover EC2 usage with different attributes in the same Region, creating room for active management as usage shifts. |
| Typical discount |
Compute Savings Plans typically trade some discount depth for broader application across compute services and Regions. |
Standard RIs can attract strong discounts for specific EC2 usage. Convertible RIs usually provide a more flexible EC2 commitment route, with lower discount levels that reflect that flexibility. |
| Best fit |
Steady compute loads that don't burst, but also work with dynamic compute spend where individual workloads may be bursty, uncorrelated, or difficult to commit to, but in aggregate the "portfolio usage" is stable enough to support an hourly commitment. |
RIs suit steady, predictable EC2 usage on a known instance profile. Convertible RIs suit EC2 usage that may shift over time, where exchange, scaling-up, and blending-forward strategies can help follow upticks and downticks. |
| Main risk |
Committing to an hourly spend level that the future compute portfolio may not sustain. Because overcommitment can reduce realised savings much more sharply than equivalent undercommitment, the risk is not simply “missing some savings”; it is paying for commitment that no longer has enough eligible usage to absorb it. |
Holding commitments that the EC2 estate no longer matches. Standard RIs can become too narrow if architecture changes, though the AWS Secondary RI Marketplace may provide a partial exit route. Convertible RIs require expertise and active management to fully unlock and preserve savings. |
Neither is automatically the right answer, and in practice a blend of commitment types often maximizes flexibility and coverage more effectively than any single type alone. The choice depends on how stable the usage is and how likely the architecture is to change, which is why centralised Reserved Instance and Savings Plan management tends to beat a one-time purchase decision.
Rate optimization and usage optimization are different problems
Cloud cost optimization gets discussed as one discipline, yet it holds two separate problems. Usage optimization asks whether you are using cloud resources efficiently: rightsizing, deleting idle resources, scheduling workloads, improving architecture and cutting technical waste.
Rate optimization asks whether you are paying the best available rate for the usage you still need: Reserved Instances, Savings Plans, commitment coverage, commitment term, utilisation, effective rates, contract structure and discount governance.
Strategic Blue’s educational content frames it simply: cloud cost is shaped by what you use and the rates you pay. Engineers are usually best placed to decide how workloads run. Rate optimization calls for a different mix of AWS pricing expertise, financial judgement, forecasting discipline and risk management. The guide to choosing a rate optimisation tool goes deeper on that split.
The trap appears when a team treats rate optimization as a large one off purchase rather than a live ongoing operating model.. A commitment bought today keeps interacting with engineering decisions made tomorrow.
For organizations looking to properly attribute AWS spend across teams and workloads, the AWS Cost and Usage Report (CUR) provides the foundational billing data used for detailed cost analysis.
Why AWS commitments are worth using
Used well, AWS commitments are among the fastest ways to cut cloud costs without asking engineers to re-architect anything. A rightsizing programme needs analysis, testing, delivery planning and change control. A well-managed commitment can produce savings on eligible usage that already exists, starting almost immediately.
Savings Plans apply automatically to eligible usage, which makes them effective for both steady state compute and consistent spending across eligible dynamic workloads. The guide to understanding AWS commitments explains the underlying trade-off: commitment-based discounts can be large, but their value depends on holding utilisation high and managing the risk that usage shifts before the term ends. With no appropriate usage to cover in a given period, the savings shrink or become waste.
So a commitment succeeds by staying useful across its whole life. The discount at purchase is only the opening move.
Coverage, utilisation and flexibility decide whether the saving is real
Three measures shape whether an AWS commitment creates value or quietly becomes a liability.
| Metric |
What it measures |
Where it turns into a trap |
| Coverage |
The share of eligible usage that sits under a commitment discount |
High coverage becomes risky when it is built too quickly on rigid or long-term commitments. Instead of driving straight to 100% coverage for three years, a safer strategy is often to build coverage progressively around the usage you expect to remain durable. |
| Utilisation |
The proportion of a purchased commitment that is actually used |
Low utilisation turns discount into waste you still pay for. Because of risk asymmetry, overcommitting is usually more damaging than undercommitting by the same percentage. |
| Flexibility |
How easily you can change technical direction without stranding a commitment |
Chasing the deepest discount on the longest term can remove room to modernise or migrate. The issue is not discount depth alone, but discount depth combined with term length and poor fit to the roadmap. |
High coverage is not automatically good if it rests on commitments that are too rigid. High utilisation matters, yet an over-cautious strategy leaves obvious savings on the table. Maximum flexibility feels safe, but avoiding commitments altogether means paying a premium for flexibility you may never use. Strategic Blue’s own guidance to partners is that utilisation is the metric that exposes a commitment with no appropriate usage to cover. The balance risk and reward approach is built around that point.
Why this becomes a FinOps capacity problem
In theory, commitment management is analytical. In practice, it is a question of capacity.
Someone has to review historical usage, understand AWS pricing options, monitor coverage, track utilisation, manage expiry, read forecasts, align with engineering roadmaps, explain variance to finance, and judge when flexibility is worth more than a deeper discount. In many organisations that work lands on a small FinOps function, a platform lead, a finance analyst, or whoever quietly became the person who translates the AWS bill.
That person is rarely doing commitment management alone. They are also handling tagging, budgets, showback, anomaly detection, stakeholder education, tooling, KPIs and executive reporting. Strategic Blue’s FinOps content makes the wider point: organisations did not move to cloud to build FinOps expertise, yet ignoring FinOps caps the value cloud delivers. Commitment management is one of the clearest places that tension shows up.
When to manage AWS commitments internally
Internal commitment management works well when usage is stable, spend is modest, and the team has enough expertise to monitor commitments over time. It works better still when finance and engineering share a clear view of the roadmap.
A strong internal model usually has clean cost allocation, mature tagging, reliable account structures, visible commitment expiry, and regular reviews across FinOps, engineering and finance. It also needs the confidence to turn down a discount when the future-usage assumption looks weak.
The complication is that AWS environments tend to get more complex as they grow. More teams deploy workloads, more accounts appear, more services enter the architecture, and more commitments overlap. At that point commitment management stops being a quarterly task and becomes continuous.
When to consider specialist rate optimisation
Specialist rate optimization earns its place when the saving opportunity is meaningful and the internal cost of managing it is high. That combination is common when engineering needs freedom to modernise while finance still needs predictable savings and lower budget variance.
Strategic Blue’s Automate service is built for this. It pairs automated analysis with human expertise to manage Reserved Instances and Savings Plans, using access only to cost and usage metadata rather than intrusive control over your environment. Rate optimization becomes more decoupled from usage optimization, enabling engineers to keep improving workloads while specialists can also manage the pricing and commitment layer. The pattern is similar to payroll, tax, treasury or commodity risk management: the business owns the strategy while specialists run a complex discipline that sits outside its core work.
How to avoid the AWS commitment trap
Avoiding the trap starts with a more disciplined decision process. Before buying or renewing, check whether the saving survives the roadmap. Separate the stable baseline from experimental, seasonal, spiky or soon-to-change workloads. Monitor coverage and utilisation continuously, rather than only at purchase. Purchase commitments regularly to form a declining risk-managed ladder, rather than making single large decisions.
Forecasting needs humility too. AWS Cost Explorer forecasts are based on past usage, and AWS states that forecasted amounts are estimates that may differ from actual charges. The honest reading is that planned business change, new workloads, volatile demand and architecture decisions all have to be layered on top of the history.
A practical commitment check therefore asks five things:
- Is the usage stable?
- Could engineering plans change it?
- Does finance understand the exposure?
- Does procurement accept the risk?
- Will someone actually monitor the commitment after purchase?
Aim for precise commitments, not a savings-versus-flexibility tug of war
The commitment conversation usually gets framed as savings versus flexibility. That framing is too blunt. The better goal is meaningful savings without paying for flexibility you do not need or giving up flexibility you do.
Commitments are not a one-off decision. They require an ongoing strategy. Buying little and often reduces future commitment risk and creates a natural declining hedge: the moment you stop purchasing, your total commitment gradually falls as existing ones expire, which means it can follow a reduction in usage automatically. For stable usage, regular top-ups as commitments expire keep coverage consistent without large single purchases that lock in too much at once.
Some organisations avoid commitments out of fear of lock-in, and so overpay for usage that was actually stable. Others chase the deepest discount and create avoidable risk when workloads change. Both waste money. The aim practical is precision: commit where the usage is genuinely durable, stay flexible where it is uncertain.
Reserved Instances and Savings Plans are strong tools that need active ownership. A Strategic Blue Savings Review can assess projected savings, commitment exposure and the trade-off between discount depth and flexibility, using your AWS cost and usage metadata. For organisations with meaningful AWS spend, it turns the question from “should we buy the discount?” into “how do we save without locking ourselves into the wrong future?” If a small FinOps team is carrying all of this, the FinOps perspective page shows where specialist support fits.
Frequently asked questions
What is the difference between AWS Savings Plans and Reserved Instances?
Savings Plans commit you to a fixed amount of compute spend per hour and apply automatically across instance families, sizes, Regions and services like EC2, Fargate and Lambda. Reserved Instances commit you to a specific instance profile. Savings Plans areflexible in return for their lower savings, although they can't be sold. Standard RIs can be sold on the AWS Secondary RI Marketplace.
Are AWS Savings Plans worth it?
For steady compute that runs regardless of the month, yes. AWS quotes up to 72% off On-Demand for eligible usage. The value of Savings Plans is seen when you hold high utilization across the one or three year term. If your usage is experimental or likely to be re-architected soon, a smaller commitment or none at all can be the better call.
Can you cancel or change a Reserved Instance or Savings Plan?
Savings Plans are locked in once purchased. The only exit is a slow, ticket-based cancellation request within the first 7 days of purchase. After that, you carry the commitment to its end date. Standard Reserved Instances can be sold on the AWS Secondary RI Marketplace. Convertible RIs can be converted to cover different usage types but not sold. The limited ability to resell commitments is why sizing your commitments correctly upfront matters so much.
What is a good Savings Plan or RI utilisation rate?
Aim to use close to all of what you commit to, with high coverage of eligible usage, while keeping enough headroom to change direction. Persistent low utilisation means you are paying for a discount you are not collecting. Coverage and utilisation should be reviewed continuously, rather than only at purchase.
Should an AWS commitment be one year or three?
Three-year terms carry deeper discounts but assume the usage and architecture hold for that long. One year commitments attract a lower discount rate but reduce lock-in risk. Match the term to how confident you are in the roadmap, and consider a layered mix of terms rather than committing everything at once.
How do I avoid AWS commitment lock-in?
Commit only to the durable baseline of your usage, keep the rest On-Demand or on flexible plans, and monitor coverage and utilisation throughout the term. Favour Compute Savings Plans or Convertible RIs where the architecture may shift, and review commitments against the engineering roadmap before every renewal.
Sources
AWS Savings Plans documentation: What are Savings Plans?
AWS Cost Management documentation: Forecasting with AWS Cost Explorer