Every saving in a cloud bill is bought with something, and the job is knowing what you are spending to get it.
How much cheaper is a spot instance than the on-demand machine you are running right now? Up to 90%, which is Azure's own published number for unused spot capacity against pay-as-you-go prices. Every major provider prices spot on the same logic.
That figure is real. It is also incomplete, because the capacity is borrowed. The provider can take it back when it needs it, so the 90% is less a discount than a price you agreed to pay in reliability, invoiced later and usually to someone who was not in the room.
Every lever in a cloud cost program has that shape. Some of the prices are trivial and some of them will cost you a quarter of engineering velocity, and this piece, the third chapter of the series that treats cloud cost work as engineering, not billing, is about telling those two apart before you pull anything.
Key takeaways
- Cloud savings are trades, not gifts. Reserved capacity buys a discount with your flexibility, spot buys it with reliability, and right-sizing buys it with headroom.
- Cost and speed are not opposites. They trade against each other only at the margin, and the margin is where every bad cost decision gets made.
- Your stage decides which cuts are safe. Pre-revenue, scaling and optimizing burn before a raise are three different problems wearing the same invoice.
- Rank levers by what they cost you, not by what they save. A saving that removes an engineer's ability to ship is the most expensive money you will ever recover.
- The safe cuts are boring, reversible and unglamorous, and they are usually enough. The heroic ones need an argument, not a spreadsheet.
Every cloud saving is a trade, and something else pays
Nobody hands you money in a cloud account. You take a discount and you post collateral against it, and the collateral is almost always flexibility, headroom or someone's afternoon.
The trades are legible once you name them, which is the part nearly every cost deck skips. Three levers carry the headline savings in a cloud account, and each one bills you in a different currency.
| Lever | Discount advertised | What you trade for it | Safe when |
|---|---|---|---|
| Commitments and reservations | Up to 72% off on-demand pricing | One to three years of locked flexibility | The baseline is already right-sized and stable |
| Spot and preemptible capacity | Up to 90% off pay as you go | Reliability, plus the retry logic to survive interruption | The workload is idempotent and restartable |
| Right-sizing compute | The largest single lever in a typical account | Headroom for the spike you did not forecast | Utilization is measured and you move one size at a time |
Commitments buy a discount with your future optionality
AWS Savings Plans and Azure reservations publish those discounts, and the mechanism underneath both is the same. You promise the provider a level of usage, and the provider pays you for the certainty.
It is the wrong instrument eight months out from a migration, a re-architecture or a scale event that changes the shape of your compute entirely. The commitment outlives the decision that made it obsolete.
Commit against an unoptimized baseline and the 72% is fiction. You have locked in the waste at a discount, for three years, in writing.
Spot buys a discount with your reliability budget
Spot and preemptible capacity are the cheapest compute in the world and the least dependable, which is a fair deal for the workloads that can absorb it. Batch jobs, CI runners, video encoding, anything idempotent that can be retried without a human noticing.
It is a terrible deal for a stateful service handling checkout traffic on a Friday night, and the reason is accounting rather than squeamishness. The cost of the outage lands on a different line of the P&L than the saving, and only one of those two lines has your attention this quarter.
The decision is quantifiable, which is the good news. AWS publishes a Spot Instance Advisor carrying the average interruption frequency and the saving for each instance pool over the trailing month, and the other providers publish the equivalent. Look up your own pool before you bet a workload on it, then decide whether the retry logic you would have to write is cheaper than the discount you would collect. Platforms like Cast AI automate that survival work on Kubernetes, which moves the question from whether you can hold spot capacity to whether you want the dependency.
Right-sizing buys a discount with your headroom
Cutting an over-provisioned instance down to observed utilization is the largest single lever in a typical account, and it is the one that quietly removes your margin for the thing you did not forecast. The word doing the work in that sentence is observed.
That word is what separates right-sizing from the cuts you can take this week without measuring anything. The utilization data has to exist first, gathered over a window long enough to contain your real peaks, and you move one size class at a time with a rollback ready. Done provider by provider, service by service, that walk is much of the AWS cost optimization checklist, which is worth having open the first time you try it.
Headroom is not waste. Headroom is insurance, and like all insurance it looks like pure cost until the day it does not. The work is to know what you are paying for and to decide, on purpose, how much of it you want to keep.
Speed and cost meet at the margin, and only there
Cost and velocity travel together across the ordinary range of decisions. They collide at the edges, and almost all the damage happens there.
At the healthy end, the two move together. Deleting a load balancer with no targets costs nobody anything. Applying a lifecycle rule to a bucket of 2024 build artifacts costs nobody anything. Fixing an infrastructure definition so an environment can be rebuilt in minutes makes the team faster and cheaper in the same commit.
That whole band is free. Take all of it.
The collision starts when the cut begins consuming attention, removing safety, or asking an engineer to hold a constraint in their head that a machine should be holding. That is the margin, and it is where a cost program either earns its reputation or burns it for a decade.
The real currency is engineering attention, not dollars
A $30,000 saving that costs 40 hours of senior engineering to build and 2 hours a month to maintain forever is worth considerably less than 30,000. The gap is a permanent tax on the scarcest resource in the company.
Martin Fowler's framing of technical debt is the right lens here, because a badly designed cost control is debt in exactly the same way. It is a shortcut that charges interest, and the interest is paid in the speed of every change that comes after it.
Reliability engineering already solved the shape of this problem
Google's SRE workbook built its whole operating model on an error budget: a stated, quantified tolerance for failure that lets a team spend risk deliberately instead of arguing about it.
Cost deserves the same instrument. Decide in advance how much reliability you are willing to trade for a discount, write it down, and then let engineers spend that budget without a meeting. Practitioner venues like USENIX SREcon are full of teams who learned this the expensive way, and the lesson repeats: an unstated tolerance always gets set by whoever shouted last.
Your stage decides which cuts are safe
There is no universal answer to which savings are worth taking, and anyone who gives you one is selling something. What the answer depends on is legible. The same cut that is reckless before revenue is negligent to skip once you are scaling, and where the company is standing decides which of those two it is.
Three stages give the same cost work three different jobs.
| Stage | What cost work is for | Cuts worth taking | What to leave alone |
|---|---|---|---|
| Pre-revenue | Staying out of the way of product discovery | The free band, plus one budget alert | Commitments, re-architecture, anything needing a design review |
| Scaling | Architecture, because the bill is a design signal | Right-sizing, topology fixes, autoscaling policy | Trims that do not change the shape of the bill |
| Before a raise | Narrative, because unit cost is what gets read | A defensible cost per user, tenant or transaction | Panic commitments on workloads nobody measured |
Pre-revenue, cost work is mostly a distraction
If the company has not found the thing people pay for, a cloud bill of a few thousand a month is noise. The real risk is building the wrong product on beautifully optimized infrastructure.
Take the free band and stop there. The only question that pays at this stage is whether anyone wants this, and cloud cost work is a comfortable way to avoid asking it.
Scaling, cost work is architecture work
Once the product works, the bill starts growing faster than the business. That gap is legible if you read it as design: cross-zone chatter, a monolith that has to scale as one unit because one component is hot, container requests and limits copied from a tutorial in 2023 and never questioned.
These are the findings that show up in a scalability review, and they are worth real engineering time because the saving compounds with growth instead of decaying against it.
Optimizing burn before a raise, cost work is narrative work
Founders optimizing burn before a raise are one of the audiences our cloud cost audit is built for, and the bill is rarely their real problem. What they are managing is the story the bill tells to a room of people deciding whether to give them money.
A lower monthly number buys runway. A defensible unit cost buys credibility, and that is the number an investor's technical due diligence will actually pull on. Runway is arithmetic. Credibility is the raise. That framing matters because a raise is a purchase, not a milestone, and a clean unit cost is part of what the buyer is paying for.
The failure mode at this stage is the panic cut. Somebody sees the burn chart, reserves three years of capacity on a workload nobody measured, and buys a discount on infrastructure the company will have outgrown before the commitment expires. That is not thrift. That is a two-year mortgage taken out to look responsible for one board meeting.
Rank the levers by what they cost you, not by what they save
Every cost program produces a list sorted by dollars, which is the one sort order guaranteed to put the dangerous items at the top. Sorted by what they cost you instead, the levers fall into four bands.
| Savings band | Levers it covers | What it costs you | When to run it |
|---|---|---|---|
| Free cuts | Delete idle and orphaned resources, tier cold storage, fix infrastructure definitions | Nothing | This week, with no design review and no permission |
| Measured cuts | Right-size compute, schedule non-production, lower autoscaling floors | Headroom, plus an engineer in another timezone waiting | After you have measured, one step at a time, with a rollback |
| Priced cuts | Spot capacity, one to three year commitments and reservations | Reliability, or years of locked flexibility | Only with an owner, a written argument and an exit |
| Structural cuts | Re-architecture, topology change, splitting out a hot component | A quarter of your best engineers for a quarter | When the saving compounds with growth |
Credibility gets spent in that order too. A team that banks the free band first earns the right to ask for the priced cuts later, and a team that opens with a three-year commitment rarely gets asked a second time.
That is the entire method. Free things first, priced things on purpose.
Two savings that look free and are not
Nobody puts checkout on spot capacity by accident. The dangerous cut is the quiet one, the move that presents as free and then bills you somewhere the finance dashboard cannot see. Two of them catch almost every team.
Shutting non-production at night, on a distributed team
Turning off dev and staging outside working hours is the standard advice, and it is correct roughly as often as your team shares a timezone.
If an engineer in another region starts their day into a dead staging environment, you have not saved money. You have converted a cloud cost into a payroll cost at a considerably worse exchange rate. Schedule against where your people actually are, and make the environment cheap to bring back up.
Autoscaling floors set to the last incident
Every autoscaling minimum in your account is a fossil of the last time somebody got paged. Ceilings get raised at 3am and never lowered, floors get set defensively, and nobody revisits either because nobody owns them.
Lowering them is real money. Lowering them without measuring the ramp is how a cost program becomes the thing engineering blames for the next outage, and there is no recovering from that in the same fiscal year. Measure the cold start, then move.
Deploy frequency is the number that proves the program worked
A year of this work leaves three numbers worth checking. Spend comes down, unit cost comes down, and deploy frequency sits exactly where it was before anybody touched the account.
That last number is the one worth watching, because it is the one every failed cost program quietly sacrifices. It holds when the expensive trades stop being made by accident, since a cut that would have cost delivery speed gets priced before anyone writes the ticket.
Four things change in the ordinary week:
- The free band runs without a meeting. Deleting orphans and tiering cold storage happen inside normal work, because they are written down, reversible and nobody's decision to defend.
- Right-sizing stops being frightening. One size class at a time against measured utilization, with a rollback ready, is a change an engineer makes on a Tuesday afternoon.
- The dangerous cuts arrive with an owner and a date. Spot capacity and multi-year commitments still happen, as decisions with an argument attached rather than as savings somebody found.
- Constraints live in policy, not in people's heads. Limits sit in the infrastructure definitions where a machine enforces them, which is the difference between a cost program and a permanent tax on attention.
Cost stopped being something that arrives from finance and started being an input to design. Given an owner and a budget, that shift is what FinOps means for a scaling company. IBM's cost optimization material reaches the same conclusion from the enterprise end of the market, and Flexera's 2026 State of the Cloud Report, a survey of 753 cloud decision-makers, still puts self-reported wasted cloud spend at 29%. The trades stay invisible until somebody makes them explicit.
Holding that line takes a named person rather than a dashboard, which is the whole argument in cloud cost management needs an owner, not a tool. The people who audit these trades for other companies are the same people making them, at risk, on our own ventures, which is why the advisory work survives contact with a real bill.
The bill came down and the delivery pace never moved, which is the only version of this work worth running.
Frequently Asked Questions
How do you reduce cloud costs without hurting performance?
Start with the cuts that have no performance cost at all: delete orphaned resources, tier cold storage, and stop non-production environments outside working hours. Then right-size compute one size class at a time against measured utilization, verifying after each step. Performance only suffers when you skip the measurement and cut in one heroic move.
Which cloud cost cuts are safe to make in the first week?
Deleting idle and orphaned resources is safe, reversible and requires no design review. So is applying storage lifecycle rules to data you already know is cold, and scheduling non-production environments around your team's actual working hours. These pay for themselves quickly and buy the credibility you will need for the harder architectural work later.
Can I reduce the cost of Cloud Run without re-architecting?
Yes. Google's Cloud Run guidance points at concurrency settings, minimum instances and container start time, and all three are configuration rather than architecture. Raising concurrency means fewer instances serve the same traffic. Minimum instances trade a little idle cost for lower cold-start latency, which is a deliberate purchase.
Does moving off the public cloud reduce cloud costs?
Sometimes, and it is a large, slow decision rather than a cost tactic. Repatriation can help predictable, steady-state workloads at scale, but it exchanges a variable bill for capital expenditure, hiring, and an operations burden the cloud was absorbing. Optimize what you have first, because a badly sized workload is expensive in any data center.
What are the 5 pillars of AWS?
AWS's Well-Architected Framework now has six pillars, not five: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. Sustainability was added after the original five. Cost optimization is deliberately one pillar among several, because AWS's own framing treats cost as something you trade against reliability and performance rather than maximize alone.
Is AI replacing cloud computing?
No. AI workloads run on cloud infrastructure, and they are one of the fastest-growing lines on a modern bill because GPU capacity is expensive and easy to leave idle. If anything, AI raises the stakes on cost discipline, since an unattended training cluster or an over-provisioned inference endpoint burns money faster than anything that came before it.
Continue Reading:
More In This Series:
- Cloud Cost Optimization Is Engineering, Not Billing
- AWS Cost Optimization Checklist for Scaling Teams
- FinOps Is an Operating Discipline, Not a Cost Tool
- Cloud Cost Management Needs an Owner, Not a Tool
- Azure Cost Optimization Starts With Your Licensing
More from Teleport Dynamix:
- Hospitality Software Was Built for Someone Else
- Startup Fundraising Is a Purchase, Not a Milestone
- Pitch Deck Is a Trailer, Not the Film Investors Buy
- Hospitality Management Platform Built for the Shift
Explore the Insights Categories:
