The Email That Built AWS: How Bezos's API Mandate Created Amazon Web Services

Around 2002, Jeff Bezos sent Amazon's engineers an email that changed how the company built software. It told every team to talk to every other team only through service interfaces, and to build each interface as if outside developers would one day use it. Four years later, outside developers did: that email is the root of Amazon Web Services.

But the email was one step in a longer chain. Here is the full sequence, from a tangled codebase in 2000 to a business with a $184 billion annual revenue run rate today, and what architects and developers can learn from it.

1. The problem: a codebase nobody could pull apart (2000–2002)

Around 2000, Amazon tried to launch Merchant.com, a service that would let other retailers build online stores on Amazon's e-commerce engine. It ran into a wall. Amazon's original code had grown so tangled that the pieces could not be separated into a platform anyone else could use.

Amazon responded by breaking its systems apart into documented APIs and expecting internal teams to build in the same decoupled way. Andy Jassy later summed it up: "So very quietly around 2000, we became a services company with really no fanfare."

A second problem showed up next. Amazon kept hiring engineers, yet projects stayed slow. Jassy, then Bezos's chief of staff, dug in and found that every team was building its own storage, compute and databases from scratch for each project. Even the basics could take months. Amazon later called this work "undifferentiated heavy lifting."

2. The mandate: interfaces or nothing (around 2002)

Bezos turned the shift to services into a hard rule. As former Amazon engineer Steve Yegge later recalled it, the mandate said:

1. Every team exposes its data and functionality through service interfaces.
2. Teams communicate with each other only through those interfaces.
3. No other access is allowed: no direct linking, no reading another team's database, no shared memory, no backdoors. Only service calls over the network.
4. The technology used doesn't matter.
5. Every interface is designed from the start so it could be exposed to outside developers.
6. Anyone who doesn't do this will be fired.

Rule 5 is the one that mattered most. It forced every team to treat other teams the way it would treat an unknown outside customer.

It wasn't free. Yegge described real pain: debugging across many services got much harder, and every team had to assume other services could be slow or broken. Amazon had to invest heavily in monitoring, timeouts and service discovery. The payoff was teams and systems that could grow independently.

3. The realization: "we're good at this" (2003)

In 2003, Amazon's leadership held an offsite at Bezos's house. The team ran an exercise to list the company's core competencies, one they expected to take about 30 minutes. It ran much longer.

Beyond selection and fulfilment, they realized something new. After years of untangling systems and running data centers at scale, Amazon had become very good at operating reliable, cost-efficient infrastructure. Other companies needed exactly that and had nowhere to buy it.

Through 2003 the team began describing the idea as an "operating system for the internet": basic building blocks like storage, compute and databases that any developer could use. By the fall they concluded that none of those blocks existed yet. Jassy wrote the proposal as a six-page memo, which reportedly went through 31 revisions, and got the green light in October 2003.

In parallel, engineers Chris Pinkham and Benjamin Black wrote a short internal paper describing a fully standardized, automated infrastructure built on web services. Near the end, they suggested Amazon could sell access to virtual servers. Bezos approved the idea. Pinkham, who was from South Africa, set up an engineering office in Cape Town, where a small team built what became EC2.

4. The launches (2004–2006)

The first piece reached the public in November 2004: Simple Queue Service (SQS), a message queue for connecting systems, released in beta. It fits the story well. The first public service was the plumbing that lets loosely coupled systems talk to each other.

On March 14, 2006, Amazon launched Simple Storage Service (S3). Amazon treats this as AWS's official birthday. S3 was its first metered cloud service: developers paid only for what they used, with no upfront commitment. Launch pricing was $0.15 per GB stored per month, and 12,000 developers reportedly signed up on day one.

On August 25, 2006, the first beta of Elastic Compute Cloud (EC2) went live, about 21 months after the Cape Town office opened. Anyone with a credit card could now rent servers by the hour.

That pricing model was the real disruption. Before AWS, starting a tech company meant buying servers and sizing them for peak demand. After AWS, a student in a dorm room had the same building blocks as a large enterprise.

5. How the world heard about the email (2011)

For almost a decade, the mandate stayed inside Amazon. That changed in October 2011.

Steve Yegge had spent six years at Amazon before moving to Google. He wrote a long post arguing that Google understood products but not platforms, and used Amazon's service mandate as the contrast. He meant it for Google colleagues only, but posted it publicly on Google+ by mistake. Tech media picked it up within hours.

That post is the only source we have for the mandate's wording. Amazon has never published the email, so the rules above are Yegge's recollection, written years after he saw it. The "memo" images that circulate online are recreations.

6. Where it went

AWS grew from three services in 2006 to more than 240 today. It crossed $100 billion in annual revenue in 2024 and reported $128.7 billion for 2025.

In Q3 2026 (July–September), AWS revenue grew 39% year over year to $46.0 billion, its fastest growth in nearly five years, putting it at a $184 billion annualized run rate. AWS operating income for the quarter was $17.8 billion, about 63% of Amazon's total operating income of $28.1 billion.

Andy Jassy ran AWS from the start. In 2021 he succeeded Jeff Bezos as CEO of Amazon.

7. The myth that won't die

The most popular version of this story says Amazon built huge capacity for the holiday shopping peak and rented out the idle servers the rest of the year. It isn't true.

Benjamin Black, who co-wrote the original EC2 proposal, has called the story "totally false" and said every part of AWS was built specifically for AWS. Amazon CTO Werner Vogels has also rejected it, and Fortune's reporting reached the same conclusion.

The real origin is less exciting and more useful: two internal problems (a tangled codebase and teams rebuilding the same infrastructure), solved with discipline, then recognized as a product.

8. What architects and leaders can take from this

After two decades in enterprise architecture, these are the lessons I keep coming back to:

• Architecture follows mandates, not slides. Amazon didn't get to services through a reference diagram. It got there because the CEO made interfaces non-negotiable and attached real consequences.
• Design every interface as if a stranger will use it. Rule 5 turned internal plumbing into a sellable product. Most enterprises still build internal APIs that only the team next door could ever use.
• Backdoors are debt. Every direct database read across teams is a dependency nobody documented. It works until you need to change, scale or sell something.
• Fix your own pain first. AWS started as a fix for Amazon's internal problems. The best platforms often come from companies solving their own problems well.
• Decoupling has a cost. Pay it on purpose. Monitoring, timeouts and service discovery are the price of independence. Amazon paid it because it bought speed.

This matters even more now. AI agents can only act on what they can reach through a clean interface. An enterprise whose data sits behind backdoors and favours will find it hard to put agents to work, just as Amazon would have found it hard to launch AWS from a monolith.

So here's my question for you: if a partner, a new product team or an AI agent needed your data tomorrow, could they get it through a proper interface? Or only through a backdoor and a favour?

Timeline at a glance

Frequently asked questions

What was the Bezos API mandate? An instruction Jeff Bezos sent to Amazon's engineering teams around 2002. Every team had to expose its data and functionality only through service interfaces, with no direct database access or other backdoors, and design every interface so it could one day be offered to outside developers.

Did the API mandate create AWS? It made AWS possible. Years of building decoupled services taught Amazon to run reliable infrastructure at scale. In 2003 leadership recognized that as a product, and AWS launched publicly with SQS in 2004, then S3 and EC2 in 2006.

Did AWS start by renting out Amazon's spare holiday capacity? No. People who built AWS, including EC2 co-author Benjamin Black and Amazon CTO Werner Vogels, have said this story is false. AWS was built specifically to be AWS.

Is the text of the original email public? No. Amazon has never published it. The wording known today comes from Steve Yegge's 2011 post, written from memory years later.

Sources

• Andy Jassy's brief history of the genesis of AWS (TechCrunch, 2016)
• How Amazon EC2 grew from a notion into a foundational element of cloud computing (TechCrunch, 2021)
• The real AWS origin story (Fortune, 2022)
• The myth about how Amazon's web service started just won't die (Network World, interview with Benjamin Black)
• Steve Yegge's Google Platforms Rant (2011, archived copy)
• Twenty years of Amazon S3 (AWS News Blog, 2026)
• Timeline of Amazon Web Services (Wikipedia)
• Amazon Q4 2025 results and Q3 2026 results (Amazon)