The recoverable money in a cloud bill was put there by architecture decisions, which is why it comes back through engineering work and not through a procurement conversation.
One engineer picks an instance type at 2pm on a Thursday, under deadline, with no price anywhere on the screen. Cloud cost optimization is the work of going back to decisions like that one, which makes it an engineering discipline and not a billing exercise. The bill is downstream: a printed record of choices about instance sizes, storage classes, network topology and environment lifecycles, and it changes when those choices change.
That is why the finance-led version of this work stalls so reliably. You can renegotiate a commitment, tag every resource, and build a dashboard that shows the spend rising in high resolution. None of it moves an idle node.
Teleport Dynamix publishes the number we work to: companies on AWS, GCP or Azure typically have 20 to 40% of cloud spend recoverable, and every point of it comes back through configuration, sizing, storage tiering and architecture rather than through a negotiation. That band is not a promise about your account. It is a statement about where the money usually sits, and this piece, the opening chapter of a six-part series on cloud cost, is about how to go and get it.
Key takeaways
- Cloud cost optimization is an engineering discipline. The bill is a printout of design choices, so the fix lives wherever those choices were made.
- Teleport Dynamix's published band is 20 to 40% of cloud spend recoverable. Peak provisioning, stale sizing estimates and resources nobody audits are what make it that large.
- The waste has an address. Idle and orphaned resources, over-provisioned compute, untiered storage, egress, non-production environments running nights and weekends, and thin commitment coverage.
- Rank every finding by recovered spend divided by engineering weeks. Some of the recovery is a config change on a Tuesday. Some of it is a quarter of engineering.
- Savings regress by default. Unless one person owns a unit-cost number, the bill grows back to the shape of the org chart.
Your bill is a lagging indicator of architecture
Cost in the cloud is a physical consequence of a design. Every provisioned CPU-second, every gigabyte at rest, every packet crossing a boundary you drew has a price attached, and the invoice is simply the integral of those choices over a month.
That is the whole reframe. Nothing else in this article makes sense until it lands.
Every default is a price somebody chose
When an engineer accepts the storage class the console offered first, they are setting a price. When they leave log retention at forever because nobody specified a number, they are setting a price. When they build a service that talks across an availability zone boundary because the diagram looked cleaner that way, they are setting a recurring price that will be paid every day for years.
None of those people were being careless. Each decision was locally correct and made under deadline. The cost was invisible at the moment it was created and only becomes visible thirty days later, aggregated with a thousand others, on a document nobody who made those decisions will read.
That gap between the decision and the signal is the actual disease. Everything else is a symptom.
Why the recoverable share is so consistently large
The 20 to 40% band surprises people until they understand what produces it. Three habits, none of them careless, produce that number:
- Provisioned for a peak that may never arrive. Capacity gets booked against the worst day the system might one day see, then billed on every ordinary day in between.
- Sized against a stale estimate. The load guess was made before the product had users, and nobody revisited it once real traffic showed up.
- Left alone because nothing is broken. A resource that works is a resource nobody audits, so the oversizing quietly persists.
Scale changes underneath the architecture, and the architecture does not notice. A system built for the traffic you had at seed is still running when you are three years past it, oversized in the places that never grew and undersized in the one place that did.
Growth hides all of it. When revenue climbs faster than the bill, nobody audits the bill. The waste is the accumulated residue of moving fast, and it compounds quietly.
Waste has an address, and there are six of them
Vague spend does not exist. Every dollar of recoverable cost is attached to a specific resource in a specific account, and in practice it lands in one of six categories. Naming them is the difference between an optimization program and a mood.
Idle and orphaned resources
The pure-waste category has a recognizable shortlist:
- Volumes detached from terminated instances, still billing for storage nobody reads.
- Load balancers with no targets, routing to services that were switched off.
- Snapshots of machines that no longer exist, kept because deleting them felt risky.
- Elastic IPs reserved for a service that was decommissioned in a sprint two years ago.
This category is pure waste with no counter-argument, and it is the reason a first pass so often pays for itself. The provider will happily bill you forever for a resource nobody has queried since the person who created it left. Deleting it costs nothing and risks nothing, once you have proven the resource is genuinely unreferenced.
Proving it is the step people skip. An unattached volume tells you nothing about whether it is garbage or the last copy of something, and the cheap check has two parts. Confirm the resource has no attachment and no read activity in the provider's own access logs across a window longer than your slowest recovery cycle, then snapshot it once and delete the original.
The failure mode is deleting an Elastic IP that a partner hardcoded into an allowlist, or a snapshot that turns out to be the only restore point for a dataset somebody signed a contract about. Both of those are survivable if you moved in that order. Neither is if you did not.
Compute provisioned for a peak that never comes
Right-sizing is where the largest share of that 20 to 40% band usually sits, and it is the lever people resist hardest, because "give it headroom" feels like professional caution.
It is not caution. It is a bet placed with the company's money, on a load curve you can actually measure. Both AWS and Azure publish the same discipline in their well-architected guidance: size the resource against observed utilization, then verify. The AWS Well-Architected cost optimization pillar is explicit that matching supply to demand is a design activity, not a monthly clean-up, and Microsoft's Azure cost optimization guidance frames the same thing as a continuous obligation of the workload owner.
The account-by-account version of this pass, resource by resource, is laid out in an AWS cost optimization checklist for scaling teams, which is where to go once the principle is clear.
Because this is where the money is, it is also where the mechanism matters. Read utilization at the percentile that reflects your actual risk, not at the mean and not at the max. Then move one size class, watch it, and move again. Two careful steps beat one heroic step that pages someone at 3am and burns the team's willingness to ever try this again.
Storage that nobody ever tiered
Object storage grows without anyone deciding to grow it. Logs, exports, build artifacts, backups of backups, the dataset someone pulled for a board meeting in 2024.
Every provider offers a lifecycle mechanism precisely because they know this happens, and almost nobody configures it at the moment they create the bucket. Google Cloud's cost optimization framework treats storage class and lifecycle policy as a first-class design decision, and it is: data that is written once and read never is worth a fraction of what you are paying to keep it instantly retrievable.
The mechanism to internalize is access frequency. Tier by how the data is actually read. Feelings are not an access pattern.
Egress you designed in without noticing
Data transfer is the cost that engineers create with a diagram. Cross-zone chatter between two services that could have been co-located. A caching layer that misses because its TTL was set defensively. An analytics pipeline that pulls the full dataset out of the cloud every night to do work that could have run next to the data.
Egress is difficult to right-size after the fact because the topology is the cost. That is what makes it an architecture conversation and, on a bad day, a scalability review rather than a config change.
Non-production running nights and weekends
Staging, QA, dev, the demo environment, the load-test cluster spun up for a launch that shipped in March. Development environments follow the working week, and the working week is under a third of the hours in it.
An environment that only needs to exist from 8am to 6pm on weekdays and is instead running continuously is paying about 250% more than it needs to. The engineering is trivial: a schedule, a teardown, an infrastructure-as-code definition good enough that anyone can rebuild the environment in minutes rather than hoarding it because rebuilding is scary.
That last clause is the real work. Teams leave environments running because their infrastructure is not reproducible, so the environment is precious. Fix the reproducibility and the savings follow as a side effect.
Commitment coverage, which is a forecasting problem
Reserved instances, savings plans and committed use discounts are the one lever that is genuinely financial, and they are the one people reach for first, which is exactly backwards.
Commit to a baseline you have not right-sized and you have applied a discount to capacity you were about to delete. Optimize the architecture first, establish the floor the workload actually holds, then buy commitments against that floor. Datadog's analysis of AWS cost data across hundreds of organizations shows how quickly the shape of spend moves under teams, with GPU instances alone climbing to around 14% of compute costs as AI workloads arrive. Commitment strategy has to survive that kind of movement.
Which of the six pays back fastest
The six addresses differ sharply in what it costs to clear them and in what breaks if you rush, which is what makes the order of attack a real decision.
| Waste address | Effort to clear | Risk profile | Where it lands in the sequence |
|---|---|---|---|
| Idle and orphaned resources | Hours | Low once the resource is proven unreferenced | Week one |
| Untiered storage | Days | Low, a lifecycle rule can be restored | Week one |
| Non-production running around the clock | Days | Low, the schedule is the whole change | Week one |
| Over-provisioned compute | Weeks | Moderate, needs measurement and a rollback plan | The middle sprint |
| Thin commitment coverage | Days to model | Moderate, the term runs one to three years | After right-sizing, never before |
| Egress designed in by accident | A quarter of engineering | High, the fix is an architecture change | The roadmap tail |
Nothing in that table says how much money each address holds. That varies by account, which is why the ranking that decides the order has to combine effort with the money actually sitting there.
Sequence the work by ROI, not by outrage
Every cost program produces a list. The list is not the hard part. The hard part is that the list contains a config change worth $40,000 a year sitting next to a rewrite worth 60,000 a year that will consume a quarter of your best engineer, and both look like one row.
Our cloud cost audit runs as a 2 to 3 week sprint and ends in a 90-day savings roadmap with ROI per action, and the per-action part is the whole point. A finding without an effort estimate is a wish.
Rank by recovered spend divided by engineering weeks
That single ratio resolves nearly every argument in the room. It puts the ugly, embarrassing, boring wins at the top, where they belong, and it pushes the intellectually interesting rewrite down to where its actual value places it.
It also protects the team. Engineers resist cost work because it usually arrives as an unbounded demand from someone who cannot say what it is worth. Done in this order, cost work stops competing with the roadmap, which is the whole case for reducing cloud costs without losing engineering speed.
Week one is free money
Nothing in the first band requires a design review, a migration, or a conversation with a vendor, and in a typical account it is a meaningful share of the total recovery. The whole band is reversible, which is what makes it safe to run before anyone has agreed a budget for the program.
Do this first for a reason that has nothing to do with the money. It buys you credibility for the harder work, and it does it inside a week.
The middle band needs a sprint
Right-sizing, autoscaling policy and instance family migration sit here, and they are the reason a cost program needs a change window at all. Move too fast through this band and the team learns that cost work breaks things, which ends the program far more reliably than a missed saving does.
In Kubernetes environments this is where the horizontal pod autoscaler earns its place, and where requests and limits that were copied from a tutorial three years ago get set against real utilization for the first time.
The tail needs an architecture decision
Egress topology, a data platform that reads the whole warehouse to answer a small question, a monolith that has to scale as a unit because one component is hot. Each of those is a design finding that presents as a cost finding.
They belong on the roadmap, costed and argued like any other engineering investment, and they are frequently the ones a board actually needs to see. That is the kind of finding that surfaces in technical due diligence whether or not you went looking for it, so it is better to find it yourself.
Tooling tells you where, engineers tell you why
Every provider ships a cost explorer, and a market of platforms exists to make that data prettier. Both are useful. Neither is the discipline. Four layers sit between a raw invoice and a decision, and each one answers a different question.
| Layer | What it answers | What it cannot answer |
|---|---|---|
| Provider cost explorer | Where the spend went, by service and by account | Which design decision put it there |
| Third-party cost platform | Allocation across teams, plus anomaly detection | Whether the architecture itself should change |
| Kubernetes cost tooling | What a namespace or workload costs inside a shared cluster | Whether that workload should run at the size it runs |
| Engineering judgment | Why the cost exists and what to change to remove it | Nothing, and no product substitutes for it |
Allocation comes before optimization
You cannot optimize what you cannot attribute. If 30% of spend lands in an untagged bucket labeled "shared," every conversation about it will be a negotiation rather than an engineering exercise.
Tagging is dull, and it is load-bearing. Enforce it at provisioning time in code, because a tag policy that depends on asking nicely in a Slack channel has a half-life measured in weeks.
Kubernetes hides the bill on purpose
Containers exist to abstract away the machine, which means they abstract away the price of the machine. A cluster shows up as one line on the invoice while twenty teams share it, and none of them can see what their namespace costs.
This is what OpenCost was built to solve, and why cost allocation became a governed concern inside the Cloud Native Computing Foundation rather than a vendor feature. Until a team can see the cost of its own workload, it has no feedback loop, and without a feedback loop, cost work is something that happens to engineers rather than something they do.
Unit economics beat total spend
Total cloud spend is a number that should go up. If it is falling while the business grows, something is wrong.
The number that matters is cost per unit of value delivered: per active user, per transaction, per tenant, per thousand inferences. The FinOps Foundation's framework makes this the center of the practice, defining FinOps as an operating model that puts financial accountability into engineering decisions rather than into a monthly report. What that model asks of a scaling company is the subject of FinOps as an operating discipline, not a cost tool. Track a unit cost and a growing bill becomes readable. Track only the total and every month is an argument.
Savings regress unless somebody owns the number
Here is the part that separates a real program from a one-off cleanup. Cloud cost work has a half-life. The savings you win in a quarter erode over the following two, because the same pressures that created the waste are still running:
- New services get provisioned generously, because headroom is the path of least resistance under a deadline.
- Autoscaling ceilings get raised during an incident and never lowered once the incident passes.
- The environment spun up for a migration outlives the migration, because nobody owns the teardown.
Guardrails belong at provisioning time
Put the constraint where the decision is made. Four mechanisms cover almost all of the ground, and each one fails in a different way, which is why teams run several rather than picking a favorite.
| Guardrail | What it blocks | Where it lives | How it fails |
|---|---|---|---|
| Budget alert | A month closing far above plan | Provider billing console | Fires after the spend is already committed |
| Instance-type allowlist | Oversized and exotic instance families | Infrastructure as code | Blocks a legitimate workload nobody exempted |
| Pipeline policy check | Non-compliant resources reaching production | CI, before anything is provisioned | Teams route around it when it is slow |
| Required tag | Spend nobody can attribute to an owner | Provisioning module or API | Tags that are present but meaningless |
The principle is the same one that governs reliability engineering. Google's SRE practice is built on the idea that you cannot manage what you do not measure and cannot sustain what you do not automate, and cost obeys the same law. Manual vigilance always loses to a Friday deploy.
One owner, one number, one review
The FinOps operating model runs on a cycle of informing, optimizing and operating, and the operating part is where organizations quietly give up. Publications like IBM's FinOps material, the Flexera FinOps analysis, CloudZero's cost research and Vantage's cloud cost reporting all converge on the same unglamorous finding: the companies that hold their savings are the ones where a named person reports a unit-cost number on a fixed cadence.
Not a committee. A person. When cost is everyone's job it is nobody's, and the bill grows back into the shape of the org chart. Why that named ownership cannot be handed to software is the whole of cloud cost management needing an owner, not a tool.
The review is the part that decays first. A unit-cost number presented monthly to people who can change the architecture behaves like a service level objective. The same number filed quarterly into a finance pack behaves like weather. Cadence is what converts a metric into a decision, and it has to run fast enough that a regression is still cheap to reverse by the time anyone sees it.
Senior judgment beats another headcount
Nearly nobody needs a full-time cloud economist at Series A. What you need is someone senior enough to say no to a design that is expensive for no reason, and to say yes to one that is expensive for a good one.
That is a fractional CTO question far more often than it is a hiring question, and it is why our advisory practice sits next to the studio rather than inside it. The engineers who build our ventures are the ones who audit other people's.
What this looks like when it works
Three months after a serious pass, the bill is lower. That is the boring part and the part everyone focuses on. The interesting part is what else has changed:
- A pull request that adds an expensive dependency now gets a comment, because the person reviewing can finally see the cost.
- The staging environment does not exist at 3am on a Sunday, and nobody misses it.
- When traffic doubles, the bill goes up by less than double, because the architecture no longer pays a fixed tax on capacity it never uses.
Someone can now answer the question a board eventually asks: what does one customer cost you to serve, and is that number going in the right direction. For a founder optimizing burn before a raise, that answer is worth considerably more than the size of the bill, and it is the same reframing that governs the raise itself in startup fundraising as a purchase, not a milestone. A lower bill extends the runway by a quarter. A defensible unit cost changes the conversation in the room.
The discipline compounds the same way the waste did, only in your favor. Engineers who can see the price of a decision make better decisions, and they make them at 2pm on a Thursday, which is the only moment that was ever going to matter. Same team. Same speed.
Better decisions.
Frequently Asked Questions
What are the 4 pillars of cost optimization?
No canonical set of four exists, so treat any such list as one organization of the work rather than a standard. Teleport Dynamix groups it as visibility, right-sizing, waste elimination and pricing strategy. Visibility allocates every dollar to an owner. Right-sizing matches resources to observed demand. Elimination removes idle resources. Pricing covers commitments, which come last.
What is a cloud cost optimization tool?
Cloud cost optimization tools collect billing and utilization data, then attribute spend to teams, services or customers so someone can act on it. The providers ship native ones, and third-party platforms add allocation, anomaly detection and Kubernetes-level breakdowns. A tool tells you where the money went. It cannot tell you which architecture decision put it there.
How do you reduce cost in the cloud?
Start by deleting idle and orphaned resources, then schedule non-production environments so they stop running nights and weekends, then apply storage lifecycle rules. After that, right-size compute against measured utilization and only then buy commitments against the floor that remains. Sequence matters, because commitments purchased before right-sizing lock the waste in.
What is the cloud cost optimization framework?
The best-known framework is the FinOps Foundation's operating model, which runs on three phases: inform, optimize and operate. Each cloud provider also publishes its own cost guidance inside its well-architected framework. They agree on the substance. Allocate spend to owners, match supply to demand, then govern the result so the savings do not erode.
How much cloud spend is actually recoverable?
Companies running on AWS, GCP or Azure typically have 20 to 40% of cloud spend recoverable through configuration adjustments, resource right-sizing, storage optimization, and architecture calibrated to current scale. The share depends on how fast the company grew and how long it has been since anyone looked. Faster growth generally means a larger recoverable band.
Is cloud cost optimization a finance job or an engineering job?
Engineering, with finance as a partner. The costs are created by architecture decisions, so they can only be removed by architecture decisions. Finance sets the target, provides the allocation model and holds the review cadence, but every actual saving is a change an engineer makes to a resource, a policy or a design.
Continue Reading:
More In This Series:
- AWS Cost Optimization Checklist for Scaling Teams
- Reduce Cloud Costs Without Losing Engineering Speed
- 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
- Series A Fundraising Buys a Different Kind of Proof
Explore the Insights Categories:
