How to Cut Cloud Costs by 40% Without Changing Your Stack

The seven levers, ranked by effort vs savings

The ranking below assumes a typical mid-market account: a few years old, grown organically, never seriously audited. If you have already pulled a lever properly, skip it — the table is a checklist, not a ritual.

Lever 1: audit egress first, because it is priced to be invisible

Data transfer out is the highest-margin line on a hyperscaler invoice and the one least likely to have an owner. AWS publicly lists internet egress starting around $0.09 per GB at the first tier, as of this writing — verify current rates — and the charge applies in places teams forget to look: cross-region replication, cross-AZ traffic inside a VPC, load balancer processing, NAT gateway data handling. Pull your bill's transfer lines, group them by service, and ask one question of each: is this traffic load-bearing, or is it an accident of where we put things?

The fixes are usually placement, not re-architecture: move the analytics job into the region where the data lives, put a CDN in front of the media origin, peer instead of hair-pinning through a NAT gateway. The deeper structural answer — when the egress line exceeds what colocation or wholesale connectivity would cost — is its own analysis, and our article on when cloud egress becomes more expensive than colocation walks the crossover math.

Levers 2–4: storage lifecycle, right-sizing, and the idle-resource sweep

Storage tiering is the closest thing to free money on a cloud bill. Most object storage sits in the default hot tier regardless of access pattern. Lifecycle policies that move untouched objects to cooler tiers after 30–90 days — or delete expired snapshots and incomplete multipart uploads outright — routinely cut the storage line by a third to a half, and they are configuration, not engineering. One caution: cool tiers have retrieval charges and minimum-duration terms, so tier by measured access pattern, not by age alone.

Right-sizing is boring and effective: two to four weeks of utilization metrics, then resize the instances whose p95 CPU sits under 20% and whose memory never comes under pressure. Expect resistance from teams who remember the one time a service fell over; bring the graphs. Target the top ten instances by spend first — the tail is not worth the meetings.

Idle-resource reclamation is a sweep, not a strategy: unattached block volumes, orphaned snapshots past retention, idle load balancers, stopped-but-billed instances, forgotten dev environments, elastic IPs attached to nothing. Every provider's bill has an archaeology layer. Delete it, tag it so it cannot silently regrow, and put the sweep on a quarterly calendar — the same discipline our SaaS spending audit framework applies to subscription sprawl.

Levers 5–6: commitment math and the support plan nobody reviewed

Committed-use discounts — reserved instances, savings plans, committed-use contracts depending on provider — publicly advertise discounts roughly in the 20–45% range against on-demand for one- to three-year commitments, as of this writing; the exact number depends on provider, term, payment option and flexibility class, so verify current terms. The trap is committing to your unoptimized baseline: buy reservations after levers 1–4 shrink the baseline, or you have prepaid your waste. Commit only to the floor you are certain of — a conservative rule is covering 60–80% of steady-state usage and leaving burst on on-demand.

Support plans are a percentage-of-spend line item that grows automatically as your bill grows, and many accounts carry a tier justified by an incident three years ago. Read what your tier actually buys — response times, technical account management, architectural reviews — and match it to what you have used in the last twelve months. Downgrading or restructuring a support plan is one meeting and one billing cycle, and on a large bill the delta alone can pay for the whole audit.

Lever 7: wholesale suppliers for the workloads that outgrow hyperscaler economics

The first six levers optimize what you pay your current provider. The seventh asks whether the workload belongs there at all — and it is where the largest single-workload savings live. Two categories dominate. Object storage at scale: wholesale S3-compatible providers price storage flat per terabyte with no egress meter, which restructures the entire cost model for backups, media and archives — our ByteCloud vs AWS S3 comparison runs that math line by line. GPU capacity for training and inference: specialized GPU clouds and brokered wholesale capacity typically price sustained H100/A100-class workloads well under hyperscaler on-demand — see our wholesale GPU access guide.

This lever is medium effort because it is a sourcing decision with a migration attached, not a console toggle. But it is still not a re-architecture: S3-compatible storage takes an endpoint change, and GPU workloads move as containers and datasets. The discipline is the same as every other wholesale purchase — get the workload's real usage profile, bid multiple suppliers against the same spec, and normalize the quotes. That is the motion SmashByte's brokerage exists to run, and the marketplace is where the supplier side of it lives.

The audit checklist: one afternoon to find your number

Before you touch anything, spend one afternoon producing the baseline this checklist generates. Everything after is execution.

Illustrative savings stack: a $50,000/month bill (illustrative — run your own numbers)

To show how the levers compound, here is a worked example on a hypothetical $50,000/month account: $28k compute, $9k storage, $7k data transfer, $4k support (percentage-of-spend tier), $2k miscellaneous. The percentages are the midpoints of the ranges we typically see; the account is invented. Nothing below is a projection for your environment.

That stacks to roughly $18,000/month — 36% — before lever 7, the wholesale sourcing move, which is workload-specific and deliberately excluded from the stack. Note the ordering effect: commitments were purchased after the baseline shrank, so the discount applies to lean usage rather than locking in the fat. The sequence is the strategy.

The 30-60-90 day rollout

Cost programs die from sequencing failures more than from analysis failures. This is the cadence that keeps momentum without breaking production.

Failure modes that kill cost programs

Four patterns account for most abandoned optimization efforts, and all four are avoidable once named. Committing before cleaning is the classic: reservations purchased against an un-audited baseline lock the waste in at a discount, and the savings program is declared finished with the fat preserved. Mandates without metrics — telling engineering to "cut 20%" without per-instance utilization data — produces the incident that poisons the program; right-sizing imposed by spreadsheet instead of evidence always finds the one workload that needed its headroom.

One-time heroics is the third: a heroic sweep in March, regrowth by September, because nothing was put on a calendar and nothing was tagged with an owner. Waste is a process output, and only process changes keep it out. And optimizing the tail — spending three meetings on a $40 line item while the $9,000 transfer line goes unexamined — is a prioritization failure, not diligence. Rank by dollars, work top-down, and stop when the remaining effort exceeds the remaining waste.

Governance: keeping the savings after the quarter ends

The audit finds the money once; governance keeps it found. Three mechanisms do the work, and none of them require a FinOps platform — a shared spreadsheet and a calendar are enough to start.

The underlying principle is that cloud waste is not a mistake someone made — it is the default output of an unmonitored system. You are not fixing the past; you are installing the feedback loop that was never there.

Frequently asked questions

Is 40% realistic for every account?

No. The 25–40% aggregate range is what SmashByte typically sees on accounts that have never been seriously audited — which describes most accounts we meet. A well-managed account with an active FinOps practice may have 10–15% available, mostly in levers 5–7. Anyone promising a fixed percentage before seeing your bill is selling something. The audit checklist above exists precisely so you can size your own number in an afternoon.

Won't committed-use discounts lock me in?

They lock in the covered baseline for the term — that is what the discount buys. The defenses are sequencing (commit after right-sizing, not before), conservative coverage (60–80% of steady state, not 100%), and calendar management of expiry dates so renewals are decisions instead of defaults. Read the modification and exchange terms of the specific program; they differ by provider and change over time.

How do I get engineering to actually right-size?

Bring data, not mandates. Two to four weeks of p95 utilization per instance, priced in dollars, converts the conversation from "finance wants cuts" to "this instance uses 12% of what it costs." Start with the top ten by spend, let teams keep headroom where they can articulate why, and revisit quarterly. Right-sizing imposed without metrics creates the incident that kills the program.

When is it worth moving a workload to a wholesale supplier?

When the workload's cost is dominated by a structurally overpriced line — egress-heavy storage, sustained GPU compute — and its integration with the incumbent's proprietary services is thin. Storage and GPU capacity pass that test most often; event-driven pipelines built on proprietary triggers almost never do. The two deep-dives on this site — object storage and GPU capacity — give you the decision tables for each.