Cutting the AWS bill: the cost equation, twelve levers and fourteen thinking patterns.

Most AWS bills are not reduced by a clever trick. They are reduced by a method: make the bill queryable, question every large number, and attack the right term of a simple equation. This first part distils 28 public, numbers-backed AWS cost-reduction stories (published 2012 to September 2026) into one cost equation (spend is quantity times unit price times time times topology, plus the choice of venue), twelve levers, an eight-step order of operations, four shapes of spend and fourteen recurring thinking patterns. The stories range from a $2,410-a-month clean-up at Levels.fyi to Dropbox's $74.6 million storage exit. Every later part in this series zooms into one group of cases; read this one first, because it gives you the vocabulary they all share.

1. Why study other people's AWS bills

Cloud cost work has a strange property: the techniques are public, the tools are cheap, and yet most organisations still overspend by a large margin. The gap is rarely knowledge of a single feature. It is the habit of looking. The 28 case studies behind this series were selected because each one is public, AWS-centric (or directly about leaving AWS), and contains concrete numbers or specific, reproducible techniques. Together they cover startups, scale-ups, enterprises and Amazon itself.

The point of reading them is not to copy the headline percentage. It is to see how the engineers reasoned: what made them look, how they tested a hypothesis before acting, what they refused to trust, and what they got wrong. Techniques change every time AWS launches a new storage class or instance family. Thinking patterns last.

1.1 The range of outcomes

Measure	Value	What it tells you
Case studies	28	Startups, scale-ups, Amazon itself, enterprises
Distinct levers	12	Each case combines one to seven of them
Typical reduction	15-90% scoped, 15-40% whole-bill	Full-bill programmes land in the teens to forties
Dollar-quantified savings	$130M+ (excluding projections)	Dominated by Dropbox ($74.6M) and HERE ($50M)
Smallest win	$2,410 per month (Levels.fyi Part 2)	Four fixes, nothing switched off

2. The cost equation

Every AWS line item is a product of a few terms. Seeing the bill this way turns the vague instruction "cut costs" into specific questions about which term to attack.

Spend = Quantity x Unit price x Time x Topology     (plus: where it runs at all, the venue)

Term	What it means	How to attack it	Seen in
Quantity	How many instances, GB, requests, log lines, snapshots or state transitions you consume	Delete idle resources, right-size, shorten retention, send fewer requests, log less, cache longer	Levels.fyi, Segment, Duolingo
Unit price	What AWS charges per unit: depends on product, class, generation and purchase model	Graviton and newer generations, cheaper storage classes, Spot, Savings Plans and RIs, Aurora I/O-Optimized, DynamoDB Standard-IA	Canva, Pinterest, HERE, Salesforce
Time	How long the resource exists or the data is kept	Autoscaling to the traffic curve, schedules for non-production, TTLs and lifecycle rules	Pinterest 2012, Moneysmart
Topology	The path data takes: across AZs, through NAT, out to the internet and back, through per-request edge services	Gateway and interface endpoints, zone-aware routing, PrivateLink, avoiding hairpins	DoorDash, nOps, Levels.fyi
Venue	Where the workload runs at all	Stay, move to a cheaper provider, or run on owned hardware	37signals, Dropbox, OneUptime

3. The twelve levers

Across the 28 cases, every action fits one of twelve levers. Counting how many cases used each one says something important: the biggest wins rarely come from a pricing trick alone.

Lever	Cases using it	Typical move
Storage tiering	8	Match S3 class to real access patterns; lifecycle rules
Right-size / autoscale	8	Requests, task counts, node consolidation, schedules
Visibility and attribution	7	CUR / Data Exports in a warehouse, tags, unit metrics
Architecture / code	7	Fix chatty designs, inner loops, IPC, hot partitions
Leave the cloud (partially)	6	Repatriate steady, storage-heavy workloads
Spot	5	Interruptible, restartable, diversified workloads
Graviton / newer generation	5	Arm instances, gp3, newer families
Culture and ownership	4	Showback, leaderboards, cost in design docs
Network path / data transfer	4	Endpoints, zone-aware routing, no hairpins
Commitments	4	Savings Plans, RIs, Database Savings Plans
Eliminate idle	4	Delete forgotten instances, volumes, caches
Retention and logging	3	Set retention, stop logging payloads, cheaper destinations

Notice that storage tiering and right-sizing lead the count, while commitments sit near the bottom. Pricing tools are the cheapest lever in engineering terms, but they are rarely the biggest one, and they are dangerous when applied too early.

4. Order of operations

The cases converge on a sequence. Doing the steps out of order is the most common way to waste effort, for example buying three-year commitments for instances that right-sizing would have halved.

Step	Verb	What it involves
1	See	Make spend queryable and attributable: CUR 2.0 / Data Exports, tags, per-team views, anomaly detection
2	Stop	Delete what nobody needs: idle instances, orphaned volumes and caches, forgotten environments
3	Shrink	Right-size instances, containers and databases; shorten retention; cut log volume
4	Swap	Move to better price-performance: Graviton, gp3, newer generations, cheaper storage classes
5	Flex	Match capacity to demand: autoscaling, schedules, Spot, Karpenter consolidation
6	Redesign	Fix chatty paths, hairpins, cross-AZ fan-out and per-request inner loops
7	Commit	Buy Savings Plans, RIs or Database Savings Plans on the new, smaller baseline
8	Relocate	For steady, storage-heavy workloads, compare other venues on full cost of ownership

5. Four shapes of spend

Before choosing tools, classify each large line item by its shape over time. The shape tells you which lever fits.

Shape	Typical examples	Best-fit levers	Seen in
Flat baseline	Databases, core services, always-on clusters	Right-size, Graviton, then commit (Savings Plans / RIs / Database Savings Plans)	HERE, Zomato
Periodic	Web tiers with day/night cycles, office-hours non-production	Autoscaling, schedules	Pinterest 2012, Moneysmart
Spiky / batch	ETL, CI/CD, analytics jobs, ML training	Spot, Karpenter, serverless at low duty cycles	Salesforce, Tinybird, Lyft CI
Growing with data	S3, snapshots, logs, DynamoDB tables	Lifecycle, tiering, TTLs, retention policy	Canva, Snap, Duolingo

6. Fourteen thinking patterns

These are the recurring moves that separated successful programmes from generic cost-cutting. Each lists evidence from the cases and a concrete way to apply it.

6.1 Patterns about looking (P01-P05)

P01. Start from the bill, not the diagram. Engineers tend to optimise the components they know. The bill shows what actually costs money, which is often something nobody thinks about: a CDN, backups, a NAT gateway. Apply it: rank the top 20 line items by cost and by month-over-month growth, and investigate both lists. Evidence: Levels.fyi (both parts), Segment, Duolingo, Lyft.

P02. Ask "expected or buggy?" and watch slopes. A large number can be fine; a small number growing every day is a lead. Levels.fyi chased a $26 line item because it kept rising; Segment noticed its bill rising faster than usage. Apply it: plot each service's daily cost with a 30-day trend line, and alert when growth outpaces your unit metric.

P03. Treat defaults and old decisions as suspects. Almost nothing in these cases was a bug. Log destinations, retention periods, autoscaling rules and capacity bumped during incidents were each correct once and expensive later. Apply it: for every large resource, find the decision behind it and ask whether its reason still holds.

P04. Price every copy and every day kept. Storage cost is bytes times copies times duration. Backups, versions, snapshots and logs multiply silently. Apply it: write retention as a table (what, how many copies, how long, why) and enforce it in code.

P05. Estimate cost per unit of work for each design. Services priced per request, transition or GB processed turn traffic patterns into bills. High-frequency inner loops belong in memory, not in queues, object stores or orchestrators. Apply it: in design reviews, compute cost per request, event or stream-second for each proposed path. Evidence: Prime Video, Levels.fyi Part 2, Duolingo, DoorDash.

6.2 Patterns about deciding (P06-P10)

P06. Normalise by a business unit. Absolute spend hides efficiency; cost per ride, per event or per GB reveals it and makes teams comparable. Apply it: publish one unit-cost number per product weekly, with a team breakdown. Evidence: Lyft, Segment, Canva.

P07. Do the payback maths before flipping a switch. Migrations, transitions and hardware purchases have one-off costs. The winning teams ranked options by payback period. Apply it: payback months equals one-off cost divided by monthly saving; prioritise anything under six months. Evidence: Canva, Rewind, 37signals, Dropbox.

P08. Verify from the inside before deleting. Metrics on a resource do not prove it is used; its own internals do (Redis INFO, connection counts, access logs). Apply it: snapshot, inspect, scale to zero or block access for a week, then delete.

P09. Change the unit price with low-risk swaps. Graviton, gp3, t4g and newer generations offer lower prices for equal or better performance with little code change. Apply it: build multi-arch images once and migrate the largest compute consumer first.

P10. Make workloads movable, then let automation move them. Spot, consolidation and schedules only save money when workloads handle interruption gracefully. Apply it: graceful shutdown, disruption budgets and checkpointing before you enable Spot or consolidation.

6.3 Patterns about commitment and verification (P11-P14)

P11. Optimise first, commit last. Commitments discount whatever you run, waste included, for one to three years. Apply it: commit only to the trough of the optimised baseline and ladder purchases quarterly. Evidence: HERE, Airbnb, Duolingo.

P12. Profile when compute dominates. In CPU-bound fleets, inefficiency in code looks like ordinary EC2 usage on the bill; only a profiler finds it. Apply it: set a "cores per unit of work" goal and profile the hottest service against it. Evidence: Recall.ai, Segment.

P13. Measure both sides of a change, and distrust fresh billing data. Cost Explorer's latest days are incomplete, and a change can move cost somewhere else (backend load, another AZ). Apply it: use a control line item and real-time signals, and wait several days before declaring victory. Evidence: Levels.fyi Part 2.

P14. Know what the cloud premium is buying. Elasticity, managed operations and speed are worth paying for; for steady, storage-heavy loads with in-house skills they may not be. Lift-and-shift gets the worst of both worlds. Apply it: score each large workload on variability, managed-service dependence, storage and egress share, and operations capability. Evidence: 37signals, Dropbox, Prerender, OneUptime, GEICO.

7. The scoreboard: all 28 cases at a glance

Keep this table open while you read the rest of the series. It lists each case, its dominant lever and its headline result exactly as the company reported it. Scopes differ, so compare within a lever, not across the whole column.

#	Company	Primary lever	Headline result
CS-01	Levels.fyi, Part 1 (2024)	Eliminate idle	~15% of total cloud spend removed
CS-02	Levels.fyi, Part 2 (Sep 2026)	Retention and logging	$28.9K a year (~$2,410 a month) across four fixes
CS-03	Segment (2016-17)	Visibility and attribution	Over $1M a year from a three-month effort
CS-04	Duolingo (2024)	Visibility and attribution	20% annualised cloud savings in a few months
CS-05	Lyft (2018-19)	Visibility and attribution	~40% lower AWS cost per ride in six months
CS-06	Airbnb	Visibility and attribution	CUR loaded into its own warehouse for team attribution
CS-07	Canva	Storage tiering	$3.6M a year (~$300K a month), growing
CS-08	Snap Inc.	Storage tiering	Tens of millions of dollars, same user experience
CS-09	Rewind	Storage tiering	~35% lower total S3 cost, ~6-month payback
CS-10	Pinterest	Graviton / newer gen	47% saving on one important workload
CS-11	Honeycomb	Graviton / newer gen	100% of the EC2 fleet on Graviton
CS-12	Zomato	Graviton / newer gen	~30% lower compute cost, ~25% better performance
CS-13	Zendesk	Graviton / newer gen	Up to 42% lower cost, up to 30% better performance
CS-14	Salesforce Audience Studio	Spot	48% overall savings after moving to Spot
CS-15	Tinybird	Spot	~20% off the total AWS bill (up to 90% for CI/CD)
CS-16	Salesforce (EKS to Karpenter)	Right-size / autoscale	~5% in FY2026, 5-10% more expected
CS-17	Moneysmart Group	Spot	~58% net saving on Spot-managed capacity
CS-18	HERE Technologies	Commitments	$50M saved plus $150M avoided over ~3.5 years
CS-19	Amazon Prime Video	Architecture / code	~90% lower infrastructure cost for one service
CS-20	Recall.ai	Architecture / code	Over $1M a year saved by replacing an IPC mechanism
CS-21	DoorDash	Network path	Cross-AZ traffic localised inside each zone
CS-22	nOps (own account)	Network path	$12K a month removed by one routing fix
CS-23	37signals	Leave the cloud	$10M+ projected savings over five years
CS-24	Dropbox	Leave the cloud	$74.6M operating-expense reduction over two years
CS-25	X (formerly Twitter)	Leave the cloud	~60% lower monthly cloud cost (company claim)
CS-26	Prerender.io	Leave the cloud	$1M to $200K annual server cost (-80%)
CS-27	OneUptime	Leave the cloud	$230K saved a year (55%+)
CS-28	GEICO (cautionary tale)	Leave the cloud	2.5x growth in cloud bills after ten years of migration

8. How to actually read a bill

Every case in this series starts with the same physical act: getting billing data into a place where an engineer can ask questions of it. There are three levels of access, and the teams that saved the most went to the deepest one.

8.1 Level one: the console

Cost Explorer is the fastest way to see the shape of a bill. Group by service, then by usage type, then by linked account. This is how Levels.fyi discovered that roughly a quarter of its bill was CloudFront. Its weakness is resolution: you cannot join it with your own business data, and its latest days are incomplete because billing data arrives late. Levels.fyi's second clean-up made this explicit by keeping a "control" line item that should not have moved, so that a real drop could be told apart from missing data.

8.2 Level two: exports in a warehouse

Segment enabled detailed billing reports in 2016, which dropped raw line items into S3, and loaded them into Redshift. Two engineers then read the bill line by line and found about fifteen problem areas that together were roughly 40% of the monthly cost. Today the equivalent is CUR 2.0 or Data Exports queried with Athena or loaded into your own warehouse. Airbnb takes the same approach at larger scale: it uses Cost Explorer for quick views but ingests the Cost and Usage Report into its internal data platform so spend can be sliced hourly, daily or monthly and attributed to owning teams.

8.3 Level three: attributed and normalised

Lyft went one step further. A Python script divided AWS spend by the number of rides and ranked engineering teams by trend; a later pipeline handled discounts and Reserved Instance costs that the raw usage reports did not reflect transparently. Cost per ride fell 40% in six months while volume grew. The transferable idea is that once billing data sits next to business data, the same analytics stack that powers the product can power cost decisions.

Level	Tool	You can answer	You cannot answer
1	Cost Explorer	Which services and accounts are large or growing?	Which team, feature or customer caused it?
2	CUR 2.0 / Data Exports + Athena or warehouse	Which resource, tag or API operation, hour by hour?	Cost per unit of business value
3	Exports joined with business metrics	Cost per ride, event, learner or GB; team leaderboards	Anything not tagged or attributable, until you fix tagging

9. What changed in 2025-2026

Techniques date; thinking patterns do not. Four recent changes affect how you apply the patterns above, and the report calls them out explicitly.

• Database Savings Plans (December 2025). One-year, no-upfront commitments in dollars per hour that discount Aurora, RDS, DynamoDB, ElastiCache (Valkey), DocumentDB, Neptune, Keyspaces, Timestream and DMS by up to 35%, across engines, instance families and regions. Serverless options such as Aurora Serverless v2 and DynamoDB on-demand became discountable for the first time. Discounts vary by service: roughly 20% for RDS and Aurora instances, up to 35% for their serverless forms.
• Resale and pooling rules (2025). AWS reportedly restricted Reserved Instances and Savings Plans to a single end customer's usage from June 2025, limiting pooled "group buying" across unrelated customers. Any third-party commitment service you rely on should be re-checked.
• Zone-aware routing in ECS Service Connect (July 2026). On by default, it keeps most service-to-service traffic in-zone, cutting cross-AZ charges and latency without code changes (Part 6).
• Exit data transfer (since March 2024). AWS waives data-transfer-out fees for customers moving data off AWS, on request. 37signals had an egress bill of roughly $250,000 waived (Part 7).

10. A ten-minute exercise before the next part

Do this now, with your own account, and you will read the remaining parts as a checklist instead of a story.

1. Open Cost Explorer, group by service for the last three full months, and list the top ten lines with their month-over-month change.
2. For each of the ten, write which term of the equation it is dominated by: quantity, unit price, time or topology.
3. Classify each as flat baseline, periodic, spiky or growing with data.
4. Pick the one line that is small but has grown every month. That is your pattern-P02 lead.
5. Write down the single unit metric you would use to judge progress, and its current value.

If you cannot do step one because nobody can tell you which team owns a line, that is itself the first finding: your programme starts with tagging and attribution (Part 2), not with any of the techniques in Parts 3 to 7.

10.1 Objections you will hear

"We are too small for this to matter." Levels.fyi's second round saved $28,900 a year with four fixes and nothing switched off. That paid for itself in hours of engineering time, and the method (largest line items first, ask whether the number is expected) scales down as well as up.

"Optimising will slow the roadmap." Duolingo's answer was to put cost estimates into design documents and quarterly spend reviews into team rituals, so cost became part of normal engineering rather than a separate project. Lyft's leaderboards did something similar with peer pressure.

"We will just move off AWS." Part 7 shows when that works (steady, storage-heavy loads with in-house operations skills) and when it fails (GEICO). Relocation is step eight of eight for a reason.

11. How the rest of this series is organised

The 28 cases fall into seven groups by their dominant lever, and each group gets one part. Every case follows the same layout so you can compare them quickly: context, what the team did, results, the thinking pattern, lessons to steal, and watch-outs.

Part	Cases	Dominant lever
2	Levels.fyi (x2), Segment, Duolingo, Lyft, Airbnb	Visibility, hygiene and reading the bill
3	Canva, Snap, Rewind	Storage tiering and data lifecycle
4	Pinterest, Honeycomb, Zomato, Zendesk	Graviton price-performance
5	Salesforce (x2), Tinybird, Moneysmart	Spot, autoscaling, Kubernetes
6	HERE, Prime Video, Recall.ai, DoorDash, nOps	Commitments, architecture, network
7	37signals, Dropbox, X, Prerender.io, OneUptime, GEICO	Repatriation
8	All	Technique catalogue, maths and pitfalls
9	All	90-day playbook and applying it to your stack

Is a 15-40% whole-bill reduction realistic for my company?

It is what full-bill programmes in the case studies landed at, but the scope matters. Levels.fyi removed about 15% with no trade-off; Duolingo reported 20% annualised; Tinybird 20%. Single-workload figures (47% on one Pinterest workload, 90% on one Prime Video service) are best cases and should not be extrapolated to a whole bill.

Should I buy Savings Plans first, since they need no engineering?

No. Commitments discount whatever footprint you have, including its waste, for one to three years. Right-size, delete and modernise first, then commit to the trough of the new baseline (pattern P11, Part 6).

What is the single best first step?

Make the bill queryable: enable CUR 2.0 / Data Exports to S3 and query it with Athena or your own warehouse. Every successful programme started from billing data, not from the architecture diagram.

Takeaways

• Spend is quantity times unit price times time times topology, plus the choice of venue. Naming the term you are attacking is half the work.
• Twelve levers cover all 28 cases, and the biggest wins (storage tiering, right-sizing, visibility, architecture) are not pricing tricks.
• The order is See, Stop, Shrink, Swap, Flex, Redesign, Commit, Relocate. Commit late and relocate last.
• Classify each big line item by shape (flat, periodic, spiky, growing with data); the shape picks the lever.
• Pick one unit metric and make every change report its effect on it.
• Read every saving with its scope. "90%" of one service is not "90%" of a bill.

References & further reading

• Cutting the AWS Bill: 28 Case Studies (PDF) - the full research report this series expands; sections 1, 2 and 4 are the basis of this part.
• Levels.fyi, Part 1 · Part 2 - the "expected or buggy?" method (P02).
• Segment - The million dollar engineering problem - bill-first cost engineering (P01).
• Duolingo - Reducing cloud spending - cost as an engineering signal.
• AWS Cost and Usage Reports / Data Exports - the billing data every case started from.