The Memo That Turned Amazon's Plumbing Into A $108bn Business

In 2024, Amazon's shops — the bit with the boxes, the vans and the "buy it again" button — brought in $530 billion. Amazon Web Services, the unglamorous cloud division that mostly rents out computers, brought in $107.6 billion.

Now look at profit. AWS made $39.8 billion of Amazon's $68.6 billion total operating income that year. The shops, the ones everyone thinks of when they hear "Amazon", made the rest. One division with 17% of the revenue generated 58% of the profit, and it started life as an internal IT project nobody asked to be a business.

That's not a cloud-computing story. It's a story about one short, bad-tempered memo from 2002 — and it's one every owner of a 10–250-person company can steal from, without building a single data centre.

The Email Nobody Was Allowed To Ignore

By the early 2000s, Amazon's own engineers couldn't move fast any more. Every team had bolted its code straight onto whatever it needed — another team's database, another team's internal functions — the way a growing company's systems always end up: connected by hope and tribal knowledge.

So, as recounted by Steve Yegge, a former Amazon engineer who later worked at Google, in a long internal memo that leaked in 2011, Jeff Bezos sent out a mandate that read, in part:

"All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network."

And then, because Bezos apparently doesn't do gentle nudges:

"Anyone who doesn't do this will be fired."

No team was allowed to quietly read another team's database any more. Every function, every bit of data, had to be offered through a defined interface that worked the same way whether the caller sat three desks away or on the other side of the planet. It was a brutal, company-wide tidy-up, and it must have felt, at the time, like pure overhead with zero upside.

From "Keep The Site Up" To Selling The Plumbing

Here's the twist nobody in that 2002 meeting saw coming. Once every team's storage, queues and compute were wrapped in clean, externally-shaped interfaces, Amazon's infrastructure team — led at the time by Chris Pinkham and Benjamin Black — realised those same interfaces didn't actually care who was calling them. A team in Seattle and a developer in Berlin looked identical to the system.

So in March 2006 Amazon quietly turned on Simple Storage Service (S3). Five months later, Elastic Compute Cloud (EC2) followed. Amazon wasn't launching a new business so much as opening the doors on infrastructure it had already built to run its own shop — and charging rent for the spare capacity.

Nobody planned AWS as "the thing that eventually funds the dividend." It was the by-product of a company being forced to make its internal plumbing good enough to survive contact with a stranger.

Thirty Years Later: The Shop Makes The Revenue, The Plumbing Makes The Profit

The numbers from Amazon's own 2024 full-year results, filed with the SEC, make the point better than any slide deck could:

AWS's operating margin sits around 37%. Retail, Amazon's actual day job, runs on much thinner margins because that's simply what selling physical goods at scale looks like. The side project born from an internal tidy-up is now the most profitable thing the company does, by a wide margin.

Illustrative comparison, not a prediction for your business: if a 60-person engineering firm spent a painful quarter forcing its scattered spreadsheets and scripts into one clean internal system, nobody would call that a new product line. Amazon didn't either, at first. It just happened to have the market and the scale to turn "our own tooling, done properly" into a second company.

Why This Worked (And Why It Isn't Magic)

Three things had to be true for the mandate to pay off, and they're worth separating from the Amazon-sized mythology:

1. The interfaces had to be genuinely well-designed, not just reachable. A network call to a mess is still a mess, just slower and with more timeouts.
2. Someone had to enforce it without exceptions. "Service interfaces, please, unless it's Thursday and you're in a hurry" would have produced nothing.
3. The company had to be big enough that "externalisable" was ever going to matter. Most teams that build a clean internal API never sell it to a stranger. That's fine — the pay-off was never really the external sale.

That third point is the one most retellings of this story skip, and it's the one that matters for you: the pay-off from tidy internal plumbing shows up long before, and regardless of whether, you ever sell access to it.

The SME Version Of The Mandate

You don't need Bezos's temper or his legal team to borrow the useful part. The useful part is this: treat your internal tools and data as if a stranger — or at least a colleague in another department — had to use them without asking you first.

In practice, for a 10–250-person company, that means:

• Pick one system that everyone quietly works around. The spreadsheet that only Sandra understands. The database three tools read from directly instead of through anything resembling an interface.
• Give it one proper way in and out. Not five scripts that each half-work. One API, one export, one source of truth — documented well enough that the next hire doesn't need a 45-minute handover call.
• Make it nobody's back door. If finance, sales and support all quietly query the same production database directly, one schema change breaks three departments at once. We've opened that particular Pandora's box for clients more than once, and it's never pretty.
• Then — and only then — ask if it's worth exposing further. To a partner. To a client portal. To the next product you build. Most of the time the honest answer is no, and that's a perfectly good answer. The tidy-up already paid for itself in fewer 2am phone calls.

This is exactly the territory our buy, bend or build framework covers: the "bend" column — tools that mostly work but don't talk to each other — is where most companies are quietly bleeding hours. Tidying the interfaces is cheaper than either buying a new platform or building one from scratch, and it's where Amazon started too.

Where To Draw The Line

In the spirit of this blog's one non-negotiable rule — no advice without the trade-off attached — here's the honest version:

• Don't do this to everything. A mandate with no exceptions makes sense when you have thousands of engineers and years to absorb the cost. For a 30-person company, tidy the two or three systems that actually cause pain, and leave the rest alone.
• Don't expect an AWS. The overwhelming majority of companies that clean up their internal tooling never sell it externally, and they shouldn't try to. The win is fewer breakages and faster onboarding, not a second revenue line.
• Don't skip the ugly first step. Amazon's teams spent real, unglamorous time rebuilding things that already "worked". If the thing genuinely works and nobody's job depends on understanding why, you can leave it be. If three people are quietly afraid to touch it, that's your signal.

Steal One Line From The Memo This Week

You don't need the firing clause. You need the first sentence: expose it through an interface, don't reach straight into the data. Pick the one internal system your team works around rather than with, and spend a week giving it a proper front door instead of four side doors.

If you'd rather have someone else do the unglamorous tidy-up — the kind that turns duct tape into something closer to custom software you actually trust — that's the work we do every day, minus the Seattle weather.

Not sure which of your systems is the one everyone works around? The free scorecard takes three minutes and tells you exactly where to start.

Written by Markus

Founder & Chief Unicorn Officer at VEONIO. Leads every engagement personally. Still can’t say no to a good idea.