cost-optimised-cloud 3 min read
04 May 2026

The Hidden Cost of Cloud Flexibility

Pay-as-you-go carries a 40–72% premium for flexibility. Most organisations pay it forever, for resources they will never remove.

Daniel Inman
Daniel Inman Cloud Solution Architect

Practical architecture guidance grounded in delivery, trade-offs, and real platform constraints.

#reserved instances #savings plans #cost optimisation #finops
Architecture Brief Systems thinking, implementation detail, and a bias toward clarity over noise.

Cloud vendors sell flexibility as a feature. They are right to — it is genuinely valuable. But flexibility is a product, and like every product, it has a price. The price is 40 to 72 per cent more than committed pricing, depending on the service. Most organisations pay it indefinitely, for resources they have no intention of ever removing.

You Are Paying for Optionality You Are Not Using

Pay-as-you-go pricing is priced to include the cost of unused capacity the cloud vendor must reserve for you. The premium exists because the vendor cannot sell that capacity to someone else while it is reserved for your potential use.

If your production database server has been running unchanged for 18 months and will be running unchanged in 18 months’ time, you are paying a significant premium for optionality you are not exercising.

This is not a mistake — it is a choice. But it should be a deliberate one, not a default.

The Three Types of Flexibility — And Which One You Actually Need

Real-time flexibility: The ability to scale up and down in response to demand. You need this. Autoscaling handles it. Reservations do not prevent it.

Strategic flexibility: The ability to migrate workloads, change architecture, or move vendors. You need this sometimes. One-year commitments accommodate it. Three-year commitments reduce it.

Psychological flexibility: The comfort of feeling like nothing is locked in. You are paying for this more than you realise, and it is rarely worth what it costs.

Most organisations justify pay-as-you-go pricing on strategic flexibility grounds. The actual constraint is usually psychological.

A Simpler Framework

If a workload has been running for more than six months with no architectural change planned: it is a reservation candidate.

If a workload is in active development or expected to change specification in the next 12 months: leave it on pay-as-you-go.

If a workload is genuinely experimental: pay-as-you-go is the right answer.

The question is not “should we commit?” The question is “which category does this workload belong to?” For most organisations, a majority of production compute belongs in the first category and is on pay-as-you-go by default.

[DAN: Add a brief note about how you’ve framed the reservation conversation with a leadership team — specifically the psychological flexibility point. Decision-makers respond to this framing because it reframes the conversation from “committing to spend” to “paying a premium we don’t need.”]


Flexibility is worth paying for when you use it. The goal is to identify the workloads where you are paying for flexibility you will never exercise, and make a deliberate decision — not to assume pay-as-you-go is the safe default.

Identifying which workloads are reservation candidates and which genuinely need flexibility is an architectural assessment. Get in touch if you want an independent view.

Daniel Inman
About the Author

Daniel Inman

Cloud Solution Architect focused on Azure, platform design, and translating technical complexity into decisions that teams can actually execute.

Previous Azure Cost Anomaly Alerts That Actually Work Next FinOps Is What Happens When Architecture Decisions Aren't Deliberate