Cloud Pricing Complexity Is a Business Model, Not an Accident

The bill is confusing because confusion pays

Cloud Pricing Complexity Is a Business Model, Not an Accident
James

On July 23, 2021, Cloudflare's CEO co-signed a blog post with a spreadsheet in it. AWS's Egregious Egress estimated that AWS was charging US and Canadian customers roughly 80 times its own bandwidth cost, with markups in some regions approaching 8,000%. AWS never published the rebuttal that would have settled it, the one with its actual costs in a table. It didn't need to. Egress pricing wasn't an error anyone had to defend; it was a mechanism doing its job.

So here's the thesis, stated flat: cloud pricing complexity is a business model. The bill nobody can predict and the bandwidth charge that only applies in one direction aren't accidents of a complicated product. They're structural incentives, built by smart people, working as intended. Treating them as accidents is how you lose to them.

The one-way valve

Data transfer into a hyperscaler is free. Transfer out is metered. A pipe that's free inbound and expensive outbound isn't a pipe, it's a valve, and the valve has a compounding property: every gigabyte you store raises the cost of ever leaving. Egress was never priced as bandwidth. It's an exit tariff that grows with your own success.

Watch what happened when the tariff met regulation. Within nine weeks in early 2024, Google (January 11), AWS (March 5), and Microsoft (March 13) all announced free data transfer out for customers leaving their platforms entirely, each framed as generosity rather than compliance. The trigger was the EU Data Act, which caps switching charges at direct cost today and bans them outright on January 12, 2027. Costs didn't change that quarter. Law did. A price that survives well over a decade and dies only when regulators kill it was strategy all along.

And read the fine print: only the final exit got free. The meter on ordinary operational egress, the kind you pay every month while staying, runs exactly as before.

A discount you need a trading desk for

On-demand is the sticker price almost nobody pays at scale. The real prices sit behind reserved instances and savings plans: one-year and three-year commitments, partially or fully prepaid, with discounts deep enough that refusing them looks irresponsible in any budget review. That's a forward contract on compute. AWS even operates a Reserved Instance Marketplace where customers resell commitments they mis-sized, and the moment your discount program needs a secondary market, it has stopped being a discount program.

An entire profession formed around reading the bill. The FinOps Foundation runs certifications and an annual conference for the discipline of understanding what you're paying for. Sit with that. Your office electricity bill doesn't support a career track.

The commitment machine's subtlest effect is political: once three years of spend are prepaid, your CFO becomes the cloud's advocate inside your own company, because every workload that might move somewhere better is now a workload that strands committed dollars. Lock-in enforced by your own finance department costs the vendor nothing. The discount is the moat.

Complexity as a sorting machine

Every dimension a bill gains makes it harder to predict and easier to segment. Per-request pricing here, per-GB-month there, a separate rate for traffic that crosses an availability zone boundary, and an hourly charge for the NAT gateway somebody enabled years ago that everyone since has been afraid to touch. Classic price discrimination requires the seller to learn each buyer's willingness to pay. A sufficiently complex price sheet does it automatically: buyers with FinOps staff excavate the discounts, and everyone else pays sticker.

The $4,847 bill that started this company, for an app serving 10,000 requests a day, wasn't a malfunction. It was the machine sorting. Light Cloud exists because that bill landed in the tier reserved for people who don't employ someone to fight it. The pricing pages are all public, and still nobody can compute their own invoice from them; both facts are stable, and the second one is the point.

The honest defense

The strongest counterargument deserves stating properly: cloud pricing is complex because the underlying costs are complex. Hardware differs by region, power costs swing with local grids, and metering usage at fine granularity is exactly the thing that lets a hobby project cost pennies a month instead of a license fee. Usage-based pricing is also fairer than the per-core licensing world it replaced, where you paid the same whether the server idled or burned. All of that is true, and I'll concede more: nobody designed this in one villainous meeting. It accreted, one reasonable-looking SKU at a time.

But complex costs don't force complex prices. Utilities face brutally variable input costs and still sell flat tariffs, because absorbing pricing risk is part of the product a utility sells, and hyperscaler margins leave plenty of room to hedge internally. The tell is where the complexity clusters: thick around the places where switching decisions happen, like egress and long-term commitments, and thin where they don't. Accidental complexity would be evenly distributed. This isn't.

This is why Light Cloud prices the way it does. Usage-based, scaling to zero when nothing runs, with a pricing page meant to be computable by one person with a napkin; if you can't predict your bill from it, we treat that as our bug rather than your homework.

A two-person company keeping pricing simple proves little, and I know it; simplicity is cheap when you're small. The commitment is about direction. Complexity added to a pricing page becomes revenue somebody defends later, so the discipline is refusing the first SKU we can't explain in one sentence.

Next time a cloud bill surprises you, don't ask what you did wrong. Ask which mechanism found you: the valve, the commitment, or the sorter. Then ask the sharper question: which one is your architecture feeding right now?


Related: Cloud Pricing That Makes Sense, where I laid out our own model. More about what we're building at light-cloud.com.