My AWS Bill Grew 40%. Revenue Grew 20%. Here's the Math I Showed the Board.
A bill growing twice as fast as its revenue looks like a failure waiting for a meeting. Last quarter I decomposed exactly that gap for a client board: of the extra $24,000 a month, $17,000 was customers and one AI feature doing what the business asked, $5,000 was fixable waste, and $2,000 was a commitment gap that would have sat there for years. Cost per customer had moved from $300 to $311 while the bill grew 40 percent. The split turned a hostile question into a 60-day plan worth $7,000 a month. Here is the arithmetic: the three buckets, the consoles that populate them, why the 29 percent waste headline does not apply to a growing bill, and the one slide that ended the argument.
of the increase that was customers doing their job
70%
a month was actually addressable: waste plus a commitment gap
$7,000
of the increase was a commitment gap, invisible until decomposed
8%
SEO Focus Topics
Key Takeaways
- • A 40 percent bill increase on 20 percent revenue growth decomposed into $17,000 of customer growth, $5,000 of fixable waste and a $2,000 commitment gap: the board needed the split, not the total.
- • Cost per customer moved from $300 to $311 while the bill grew 40 percent: that single line is what defensible growth looks like.
- • The 29 percent industry waste figure measures total spend, not the growth delta: the fixable share of an increase is typically a fifth to a third.
- • Commit after the cleanup: AWS's own target-coverage guidance is to leave headroom for rightsizing and buy incrementally against the stable residue.
- • The addressable slice was $7,000 a month, $84,000 a year, collected with a 60-day plan and one board slide.
The direct answer: most of the growth was the customers, and the split took one afternoon
A 40 percent increase on a $60,000 monthly bill looks like an emergency until you split it. The split took one afternoon of Cost Explorer work and found three buckets: $17,000 a month of new customer usage and one AI feature the product team had launched, $5,000 of fixable waste, and $2,000 of on-demand spend sitting outside commitment coverage. Revenue had grown 20 percent over the same year. The board had seen the 40 percent. It had never seen the split.
That is the whole method. Growth arrives bundled into one number, and the three buckets inside it have different owners, timelines and fixes. The customers belong to sales. The waste belongs to engineering. The commitment gap belongs to whoever buys the commitments. Present the bundle and you get an argument; present the buckets and you get a decision.
Bucket one: what the business asked for
Of the $24,000 monthly increase, $17,000 traced directly to usage the business had approved: existing customers consuming more, new customers onboarding, and one AI feature whose inference costs arrived before its revenue did. None of it was waste. All of it was the product working.
The test is cost per customer. At the start of the year the bill was $60,000 across roughly 200 active customers: $300 each. At the end it was $84,000 across about 270: $311 each, up under 4 percent while the bill grew 40. That single line converts a scary aggregate into a defensible trend, and it is exactly what AWS calls a unit metric: spend paired with the demand driver that causes it.
AWS's guidance on unit metrics draws the line I showed the board: a rising unit cost is a sign that something needs to be investigated. Ours rose under 4 percent, which is growth, not drift. When cost per customer doubles, the story changes from sales success to architecture problem, and the response is completely different.
- ✓ CUR or Cost Explorer allocation tags → monthly spend by product → divide by active customers. Quarterly precision is enough; the trend is the point.
- ✓ Cost Explorer → last 12 months → group by Service, monthly granularity: match each bend point to a deploy or a customer go-live.
- ✓ Watch a new AI feature separately: its inference costs arrive before its revenue does, and an unmatched bend is an open question in the meeting.
Bucket two: the fixable waste, which is smaller than the headline
The waste bucket came to $5,000 a month: idle resources nobody had deleted, oversized instances running at low utilization, and storage that had never tiered. Real money, $84,000 a year, and all of it recoverable at zero risk.
Here is the part worth being honest about. The 29 percent waste figure from Flexera's 2026 survey, 753 cloud decision-makers, measures total spend: the stock you already run. Waste concentrates in the stock. A growth delta is mostly new, purposeful usage, so the fixable share of the increase is smaller: in the audits I run it lands nearer a fifth to a third of the delta. Apply 29 percent to the increase, as I have watched happen in boardrooms, and you promise savings that were never in the room.
- ✓ Cost Optimization Hub → Recommendations → filter to idle and unattached: the only bucket anyone enjoys closing.
- ✓ Compute Optimizer → rightsizing: the oversized instances were the quiet $2,000 a month.
- ✓ S3 → lifecycle policies, and gp2 to gp3 while you are in there: storage never tiers itself, it just ages.
- ✓ Re-run the delta after the cleanup: it converts the bucket from an opinion into an invoice line.
Bucket three: the commitment gap, the quietest and most preventable
The last $2,000 a month was on-demand spend that should have been covered. The commitment portfolio had been sized for the old baseline, and the growth had outrun it. This bucket is quiet because nothing breaks: it is just list price, month after month, for usage that deserved a discount.
The fix is sequencing, not shopping. AWS's advertised Savings Plans discount runs up to 72 percent, and you only realise anything like it on the workload you actually keep running. Commit before the cleanup and you convert removable waste into contractual waste. AWS's own target-coverage guidance says the same thing in politer language: set coverage that leaves room to rightsize instances and clean up idle resources before committing further, then buy incrementally against the stable residue.
One wrinkle from the AI feature: volatile inference is exactly the workload not to commit. The stable residue gets the commitment. The experimental workload stays on demand and gets watched.
- ✓ Cost Explorer → Savings Plans → coverage: find the on-demand slice and its trend.
- ✓ Purchase Analyzer → Target coverage: model the hourly commitment against a percentage goal instead of eyeballing it.
- ✓ Commit to the residue that survived the cleanup, in the shortest term that covers it.
The slide that ends the argument
The board slide is one line and two numbers. The line: +$24,000 a month, split 17 / 5 / 2, growth, waste, pricing. The two numbers: cost per customer $300 to $311, and addressable $7,000 a month with a 60-day plan attached. No industry averages, no service pie charts, nothing the board has to take on faith.
Raw bills create fear. Decomposed bills create decisions. The 40 percent headline invited the board to imagine the worst bucket was all of it. The split showed them the worst bucket was 8 percent, already priced, with a plan. That is the difference between a meeting about the CTO's competence and a meeting about the company's money.
The next 60 days
The sequence that collected the $7,000: close the idle and rightsizing waste in the first two weeks, it is free and risk-free. Buy the commitment against the residue that survived, sized with target coverage rather than the recommender's default. Then install the ritual: a quarterly decomposition of the delta into the same three buckets, so the next growth surprise arrives pre-split.
Upload your most recent AWS bill and we will produce this exact split: Estimated Savings Rate for the waste, Commitment Lock-in Risk for the commitment gap, and the growth bucket separated out, before your board asks for it.
- For the cleanup sequence once the waste is priced: the 30-day AWS cost reduction guide , and the 18 audit patterns tell you what to look for first.
- What AWS should cost as a share of revenue: the benchmarks piece
- If the growth was sudden rather than steady: the 20-minute triage
Frequently Asked Questions
Why is my AWS bill growing faster than my revenue?
Because growth arrives bundled. Decompose the increase into customer-driven usage, fixable waste and commitment gaps before judging it. In the worked example here, 70 percent of a $24,000 increase was customers and a product launch, and the addressable part was $7,000 a month. Judging the bundle instead of the buckets is how defensibility gets lost.
How do I calculate AWS cost per customer?
Allocate monthly spend by product with CUR or Cost Explorer allocation tags, then divide by active customers. Track the trend, not the level: $300 to $311 per customer on a 40 percent bigger bill is defensible growth. AWS calls this a unit metric and flags a rising one as something that needs investigating.
Should we buy Savings Plans before or after cleaning up waste?
After. Commitments are non-refundable, so waste committed today is contractual waste for the term. AWS's target-coverage guidance is explicit: set coverage that leaves room to rightsize and clean up first, then increase coverage incrementally against the optimized baseline. The advertised discount, up to 72 percent, only applies to workloads you actually keep running.
What should I show the board about cloud costs?
One slide: the increase split into growth, waste and pricing gap, the cost per customer trend, and a plan for the addressable share. In the example, that was a 70 / 21 / 8 split of a $24,000 increase, cost per customer up under 4 percent, and $7,000 a month addressable over 60 days. Raw bills create fear. Decomposed bills create decisions.
Sources
- Flexera 2026 State of the Cloud (753 respondents, 29% waste)
- AWS: What is a unit metric (Cloud Financial Management)
- AWS Savings Plans documentation (up to 72%)
- AWS: Target coverage in Savings Plans Purchase Analyzer
- AWS: Cost Optimization Hub documentation
- FinOps Foundation: Introduction to Cloud Unit Economics
- r/devops: AWS cost optimization findings across 50+ accounts
About the author
Hermann Lotter
FinOps practitioner who has led cloud and AI cost optimization inside a 180-person organisation, identifying six-figure annual savings across AWS and LLM spend. He writes Easy Entropy from hands-on engagements, not theory. LinkedIn
Free Assessment
Want this outcome in your AWS bill?
Get a free cloud cost analysis and a prioritized optimization roadmap.
Request Free Analysis →Related Articles
FinOps
What Should AWS Cost? The Benchmarks That Survive an Exec Meeting (2026)
Ask a room what AWS should cost and you will get five numbers: 5 percent of revenue, 10 percent, 29 percent wasted, half the bill recoverable if you would only repatriate, and AWS's own efficiency score. Nearly all of it is quoted by people who never opened the source. This is the briefing I wish someone had handed me before my first cloud review: the ranges that survive contact with an exec meeting (cloud at roughly 5 to 15 percent of revenue depending on what you sell, self-estimated waste at 29 percent across Flexera's 753 respondents, 98 percent of FinOps teams now carrying AI spend), the quiet way each number lies, and the five slides I bring instead of an industry average. The benchmark that ends arguments is your own cost per customer.
Cost Optimization
How to Reduce Your AWS Bill: A 30-Day Step-by-Step Guide
To reduce your AWS bill, work in this order: turn on Cost Explorer and daily CUR to find where the money actually goes, delete idle and orphaned resources, right-size overprovisioned compute and storage, then buy Savings Plans against the baseline that survives. Most accounts that have never been optimized give up 20% to 35% within 30 days, and the first two steps cost nothing and carry no production risk. Buying commitments first is the common mistake: it locks in the waste you have not removed yet.