Amazon Didn't Plan AWS. It Stumbled Into the Biggest Business Idea in History.
There is a line in a book whose name nobody can quite remember: "Life unfolds before us all at once."
Amazon Web Services was not planned. It was not the product of a strategic vision document or a whiteboard session or a McKinsey presentation. It was discovered, almost by accident, while Amazon's engineers were trying to solve a problem that had nothing to do with selling anything to anyone outside the company.
The problem was this: Amazon in the early 2000s was a chaos of internal systems. Every team built its own infrastructure. Every service talked to every other service in ways that were undocumented, inconsistent, and deeply fragile. Adding a new feature required navigating a web of dependencies that nobody fully understood. The company was scaling rapidly and the internal architecture was not scaling with it.
In 2002, Jeff Bezos sent a memo. It has since become one of the most discussed internal documents in the history of corporate management, though its exact wording has been reproduced and paraphrased so many times that the original is now something of a ghost. The substance is clear enough.
All teams will henceforth expose their data and functionality through service interfaces. Teams will communicate with each other through these interfaces and only through these interfaces. There will be no other form of inter-process communication — no direct linking, no shared memory, no back doors. The interfaces must be designed from the ground up to be externalizable — meaning, capable of being opened to the outside world. Anyone who does not do this will be fired.
The last line was characteristically Bezos.
What the memo was trying to do was impose discipline on internal infrastructure. What it inadvertently did was build the template for a business that would eventually generate more profit than selling books, music, electronics, clothing, furniture, food, and everything else Amazon has ever sold, combined.
If every team had to expose its capabilities through a clean interface — and if those interfaces had to be designed as if they were going to be offered to the outside world — then offering them to the outside world was not a large conceptual leap. It was just a matter of deciding to do it.
Amazon decided to do it in 2006. S3, the storage service, launched in March. EC2, the compute service, launched in August. The target customer was not enterprise IT departments. It was startups — small companies that needed infrastructure immediately and could not afford to build it themselves.
Nobody in the market understood what Amazon was doing. IBM didn't. Oracle didn't. Microsoft didn't, yet. The conventional wisdom was that infrastructure was a capital-intensive, low-margin business best left to companies that had spent decades building data centres. Amazon was a bookstore. What did a bookstore know about enterprise computing?
Quite a lot, it turned out. Amazon had spent years solving the exact problems that every other scaling business would eventually face. The difference was that Amazon had been forced to solve them at scale, under pressure, with real consequences for failure. The internal infrastructure they had built was not theoretical. It was battle-tested.
AWS launched quietly. It grew quietly. By the time the rest of the industry understood what was happening, AWS had a lead that was measured not in months but in institutional knowledge, customer relationships, and engineering talent that had been accumulating for years.
Today, AWS generates roughly 70% of Amazon's total operating profit. The retail business — the part everyone thinks of when they think of Amazon — operates on margins that are, in some quarters, barely above zero. The supermarket and the streaming service and the same-day delivery and the warehouses full of robots are all, in a meaningful financial sense, subsidised by the cloud business that started as an internal memo about cleaning up a mess.
There is a version of this story that gets told as a triumph of foresight. Bezos saw the future, the story goes. He understood that infrastructure would become a utility. He planned for it.
This is not quite right.
Bezos saw that his internal chaos needed fixing. He imposed a discipline that happened to produce an asset that happened to be valuable to the rest of the world. The insight was not "we should build a cloud business." The insight was "our internal systems are broken and this is how we fix them." The business followed from the fix.
This is how most of the important things get built. Not from a vision of the destination, but from a clear-eyed diagnosis of what is broken right now. The vision comes later, when you look back at what you were actually doing and realise it was bigger than the problem you thought you were solving.
Life unfolds before us all at once. So does the business hiding inside the infrastructure you built to survive.
