How Amazon Web Services Started as an Idea to Solve a Technical Challenge and Became a $1 Trillion Business

It was September of 2003. Andy Jassy was nervous. He had an idea that had been brewing in his mind for over a year. Simply put, Andy thought Amazon should build and sell digital infrastructure to third parties. But Andy was one of the few people who understood the potential business opportunity.

Andy knew that if he didn’t convince Jeff Bezos and the rest of the senior leadership team, it wouldn’t just be a setback for his career at the company. Amazon would miss out on a massive market.

Amazon Pickup Return

The Pitch That Started a Trillion-Dollar Business

He made his pitch. And just like that, Jeff Bezos approved it right then and there. Neither man knew it at the time, but they just started a business which 20 years later is worth more than a trillion dollars.

This is the story of how Andy Jassy, Jeff Bezos, and the rest of Amazon discovered one of the biggest markets in history. This is the story of Amazon Web Services (AWS).

AWS is one of the most revolutionary ideas in the history of tech. And it’s arguably the most successful second act for any major tech company.

Today, the world’s biggest companies rely on AWS for everything – from their storage and compute to their payroll and CRMs. An entire generation of amazing startups that form the fabric of our everyday lives – names like Uber, Netflix, Airbnb – all owe their existence to AWS.

Why the AWS Origin Story is Complex

It’s not just startups either. NASA uses AWS. The literal CIA uses AWS.

The history of AWS is a history of the ways computing, software development, and even capitalism itself have evolved over the last 20 years. And that’s important, so maybe it isn’t a surprise that the origin story is pretty complicated.

The main reason is that it’s just plain complex, especially for people who don’t understand software. And that lack of societal-wide understanding has allowed some false narratives to emerge.

For example, there’s a theory that Jeff Bezos and other senior people at Amazon got the idea for AWS because they wanted to make extra money renting out excess server capacity.

It’s true that Jeff Bezos was annoyed at how much Amazon was paying for server costs. But back then, almost 20 years ago, it wasn’t possible to rent out capacity like it was a storage locker.

Innovation Rarely Happens Through Individual Genius

Another reason why the origin story of AWS is so complex is that it’s hard to get a real sense of what goes on behind the scenes at Amazon. So you need to kind of piece it together from secondary sources.

But the main reason AWS has such complex origins is because of the nature of innovation itself.

We love stories about individual founders who came up with world-changing ideas on their own and then built incredible companies. But a lot of the time, especially within large organizations, that’s not how it works.

Don’t get me wrong – Jeff Bezos and Andy Jassy are incredibly important people in the history of AWS, probably the two most important people. It just doesn’t happen without either of them.

But they didn’t invent the concept of AWS. The truth is no one person did. It was the culmination of dozens, probably hundreds of memos, meetings, and random conversations.

Bezos and Jassy’s Key Contributions

Jeff and Andy’s main contributions were in seeing the big picture of what Amazon was trying to do, nurturing the good ideas, and then maintaining a laser-like focus on execution.

That doesn’t make their contributions less important. And it doesn’t make the story of AWS any less exciting. In fact, I think it’s the opposite – Amazon created AWS because it was the only company in the world that could.

Amazon’s Architectural Constraints

There’s an irony here. Throughout the development of AWS, Amazon’s leaders were obsessed with building something that could be used by kids working on a project in their dorm room.

But they also wanted it to be so scalable that when those kids turned into Mark Zuckerberg or Patrick Collison, they would stick with AWS.

Like I said, AWS has a complicated backstory. But that doesn’t mean we can’t tell the story from the beginning.

To begin, let’s rewind a little – a few years before Andy Jassy made his pitch to Amazon’s S-Team.

It was the late 1990s and Amazon had a problem. It didn’t look like it from the outside – sales grew by 800% between 1997 and 1998. Amazon was adding new features almost every day and hiring tons of engineers.

Amazon’s Success Created New Technical Challenges

But that insane growth was precisely the problem. Basically, Amazon was suffering from success.

Internally, the company was running on what at the time was a traditional two-tier architecture:

  • On one side, you had a monolithic application that served the pages on the website.
  • Then on the other side, you had a bunch of different databases that grew with every new customer, product category and market.

That architecture was basically fine when Amazon was a small online bookseller. But as Amazon expanded, that system increasingly struggled to cope.

The end result was like a Jenga tower – one wrong move, or one new feature that wasn’t properly implemented, and everything could topple over. It was a big mess that created tons of redundancy.

Those architectural constraints created real business constraints. Jeff Bezos didn’t want to just sell books – he wanted Amazon to become the everything store.

This problem came to a head when Amazon was hired by their competitors – the large physical retailers like Walmart and Target – to build out their ecommerce platforms.

Realizing Amazon Had to Change to Keep Growing

I’ll let Andy Jassy explain:

“There were a few things going on between the years 2000 and 2003 that made us think this could be a good idea. You know the first was this business in Amazon called where we sold our ecommerce technology to third party merchants. These are companies like Target, Marks and Spencer.

And when we went to deliver that solution to those companies it turned out to be way harder and way more time consuming than any of us imagined. And that’s because we had really kind of jumbled up a bunch of parts of our platform, growing as fast we did the first eight years.

And to deliver these through APIs, which is the way that these companies wanted to consume them, it took a lot of decoupling and a lot of work that we just hadn’t thought about before.”

Jassy and Bezos knew that the legacy architecture put a hard limit on Amazon’s future. In fact, it was already eating into its margins. And because Amazon was so far ahead of its competitors, there weren’t many real life examples of how to solve this problem.

They couldn’t just pick a solution off the shelf. They pretty much had to invent one. So that’s what they proceeded to do.

The Distributed Computing Manifesto Lays the Groundwork

Back in 1998, a team of Amazon engineers wrote something they called the Distributed Computing Manifesto.

At this stage I should stress something – the creation of AWS was a deeply collaborative endeavor. Dozens, probably hundreds of people were involved. But there are memos and moments and people which I’ll talk about in this article that really matter.

The Distributed Computing Manifesto is one of those memos that really matters. In just over 3,000 words, the authors did three things:

  1. Identified the flaws in Amazon’s existing two-tiered architecture
  2. Proposed a different architecture model to replace it
  3. Described the change in mindset that needed to accompany the technical changes for the shift to work

The model proposed in the manifesto was what’s called a service oriented architecture (SOA).

In software, a service is something that’s designed to complete a specific task – like executing an operation or retrieving some information. In the case of Amazon it might have been something like fulfilling an order or delivering it to the customer.

Services allow different business functions to be performed remotely and independently. In other words, they’re modular and flexible – ideal for a company that wants to scale quickly.

SOA is just the name for all those different services working together. If that still doesn’t make a whole lot of sense, here’s an analogy:

Transitioning to SOA Was Like Going From Jenga to Lego

For Amazon, transitioning to service oriented architecture was like going from building on top of a Jenga tower to building with Lego blocks:

  • Jenga was delicate and fragile – any new feature or change to an existing feature and the whole thing could collapse.
  • But Lego is different – the blocks fit together perfectly. They’re reusable. And they’re almost impossible to break.

The Distributed Computing Manifesto was a blueprint for a different kind of company. It would go on to influence Jeff Bezos’s thinking as he considered how to modernize Amazon’s architecture.

He met with people who urged him to embrace APIs as a way of opening Amazon to outside developers. He had long conversations with his most trusted employees, including Andy Jassy.

He read books about architecture design. Then, after months of absorbing advice and information, Bezos made a call – it was time to take a hammer to the existing monolithic architecture.

Bezos Mandates a Transition to SOA

It was time to embrace SOA.

Bezos knew it would be one of the biggest leadership challenges of his career, because it’s no exaggeration to say it could make the difference between Amazon being a trillion dollar company or just another internet retailer lost in the mists of time.

The Distributed Computing Manifesto is an important document in Amazon’s journey from a monolithic architecture to building AWS. Except it was more of a mandate.

Here’s what it said:

“All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. All service interfaces, without exception, must be designed from the ground up to be externalizable. Anyone who doesn’t do this will be fired.”

I’m pretty sure that’s not the actual text of the memo. Amazon has never released it and as far as I know Jeff Bezos has never acknowledged it.

The reason we know it exists is because of a mistake.

Steve Yegge is an engineer who’s worked at senior roles across Amazon, Google and Grab. But to the public, he’s best known for accidentally publishing an internal Google+ memo in October of 2011.

Yegge’s Leaked Memo Confirms Pivotal Moment

In the post, which was mostly criticizing Google, Yegge talks about the Bezos memo. He talks about how it was a major turning point in Jeff Bezos’s thinking about Amazon’s architecture – which therefore makes it a pivotal moment in the history of AWS.

So let’s break it down. What does it mean and why does it matter?

Okay, so the first thing to understand is that when Bezos was talking about service interfaces, he was talking about APIs.

Very quick, hyper-simplified crash course: An API or Application Programming Interface is a mechanism that allows two different software components to talk to each other according to set rules.

For example, whenever you open the weather app on your phone, it pulls the current data from the weather bureau’s software system using an API.

For Amazon, customer-facing APIs help to do things like create rankings, offer customer recommendations, and retrieve saved customer details. They’re like Lego blocks – small, modular, unbreakable.

APIs Were the Building Blocks of the Future

Bezos believed APIs were the way forward for Amazon. He even created a team within Amazon whose sole purpose was creating them to share with third-party developers.

That led directly to incorporating APIs into Almost immediately, developers came up with innovative ways to display the product catalog on their sites.

Those advances, and the progress that Amazon was making building APIs, inspired Bezos to go a step further. He figured that if Amazon could build a solution like that and transition from its monolithic architecture to service oriented architecture, maybe the company itself should follow the same pattern.

Think about how profound a change this was. As Yegge pointed out in his accidentally public memo, organizing into services taught teams not to trust each other in most of the same ways they’re not supposed to trust external developers.

It sounds completely counterintuitive, but it was precisely the lack of trust that made it work. All of a sudden, every team within Amazon had to interact using these so-called hardened interfaces.

Lack of Trust Forced Better Technical Practices

If you were in HR and needed some numbers from the marketing department, guess what? You had to build an interface to retrieve the numbers.

It was a totally scalable, decentralized system – hundreds of individual Lego blocks.

Once you truly understand the implications of what Bezos was trying to do, you realize that he was shifting Amazon onto the path that culminated with the creation of AWS.

Hiring Key Technical Talent

One of the best decisions Amazon made right around this time was hiring Alan Vermeulen. Vermeulen wound up becoming Amazon’s CTO, but his first job was to build tools that disentangled Amazon’s messy codebase and separated it into hardened interfaces that individual teams could incorporate into their work without worrying if they were going to break everything.

There’s a term in software engineering known as Conway’s law. In its general form it says that the technical infrastructure you build will mirror the structure of your organization.

I don’t know if Jeff Bezos knew about Conway’s law. He probably did – he’s a smart guy. Either way, he was enacting Conway’s law within Amazon.

Amazon Web Services Starts Small

In July 2002, a couple years after Alan Vermeulen was hired, Amazon held a developer conference. Today, Amazon’s re:Invent conferences are attended by thousands and watched by millions.

But just 8 people attended the conference where Amazon announced the launch of their new division, Amazon Web Services. Needless to say, it was nowhere near the AWS we know today. It was really just a way for outside developers to access the product catalog.

Still, it was an indication that something big was beginning to happen.

The AWS Vision Crystallizes

Developer conferences were cool, but Amazon had bigger fish to fry. This is the part of the AWS story where Andy Jassy becomes more prominent.

Today, Andy is Amazon’s CEO. But despite rising to the top of one of the world’s biggest tech companies, he’s not a software engineer. He’s a Harvard MBA who’s so obsessed with sports he almost became a sports broadcaster.

In another world, he’s giving color commentary on ESPN. Thankfully for everyone except Amazon’s competitors, he decided on a more conventional career path.

Andy joined Amazon’s marketing department way back in 1997. After the department was downsized in the wake of the dotcom crash, Bezos appointed Andy to be his shadow – a hybrid role which was part technical assistant, part chief of staff.

It was a strong signal to everyone that Andy was a rising star. Now it was his turn to prove it.

Remember, Amazon was focused on rapid growth. And that presented new challenges. For example, Amazon wanted to start selling clothes. But clothes aren’t the same as books:

  • Books are almost perfect commodities, but clothes aren’t.
  • They come in different sizes and colors.
  • In order to sell clothes, Amazon’s engineers had to build all kinds of new features – a bigger product catalog, more website traffic, more community features like username verification and review ratings.

Technical Debt Was Slowing Feature Development

But those features weren’t being added as quickly as they should have been.

Andy realized that the reason projects were taking so long was because software engineers’ time was constantly being consumed by doing work that wasn’t directly related to the feature they were building.

Instead, they were spending as much as two-thirds of their time building databases, storage, and compute infrastructure.

It’s easy to see that this was a big problem. Amazon needed a solution. If it didn’t find one, it risked squandering the advantage it worked so hard to build.

An answer arrived just in time, and once again it came in the form of a classic Amazon memo.

The author was a guy named Matt Round, a senior engineer who was persistent and outspoken about how hard it had gotten to actually build things within Amazon. His memo opened with a bang:

“To many of us, Amazon feels more like a tectonic plate than an F-16.”

That’s a great hook. From there, Matt set out some principles for maximizing the amount of time that Amazon’s engineers spent building cool things:

  • Maximizing their autonomy
  • Adoption of REST architectures
  • Standardization of infrastructure
  • Removal of bureaucracy
  • Continuous deployment

If you work in software today, none of those recommendations sound radical to you. But remember, this was 20 years ago.

Matt’s memo was probably on the agenda when Amazon’s senior leadership team gathered at Jeff Bezos’s house in Medina for an offsite. All the company’s biggest hitters were there:

  • Jeff Bezos obviously – it was his house
  • Andy Jassy
  • The CTO Alan Vermeulen
  • The CIO Rick Dalzell
  • And others

The AWS Vision Comes Together

They were there to brainstorm new business ideas and list out Amazon’s core strengths.

They thought it would take half an hour, an hour tops. But as the meeting went on, the people in the room began to realize something.

The Distributed Computing Manifesto, Amazon’s migration to SOA, Amazon launching web services in 2002, and third-party developers building more than 100 applications within 2 years, Matt Round’s memo – these weren’t disparate threads.

They were all pointing in the same direction – a couple of years after AWS properly launched, Jeff Bezos gave a talk at Y Combinator Startup School.

It was a few years before my time, but people were still talking about it when I was there. It’s a good thing – I mean for all of society – that the talk was recorded:

“I took a tour of a 300-year-old brewery in Luxembourg. Their business of course is making beer. And about 100 years ago they were one of the first factories in Luxembourg to start using electric power to help make beer, to help in the manufacturing process.

Of course they couldn’t buy the electric power off of the electric grid, because there wasn’t an electric grid. So they started making their own electric power.

If you could make your operations more efficient or do new things with electric power, the only way to get power was to set up your own generator and become an expert in electric power generation.

The important thing to notice here is that the fact that they generated their own electric power did not make their beer taste better.”

AWS Would Let Teams Focus on Core Business

What startups want – actually, companies of all sizes – is to go from their idea or vision to a successful product as quickly as possible.

The problem always is that there’s a lot of undifferentiated heavy lifting that gets in the middle between your idea/vision and that successful product.

The undifferentiated heavy lifting, by the way, has to be done at world-class levels of excellence or your vision will fail. But it’s totally undifferentiated and isn’t actually making the beer taste better.

Teams inside Amazon had been spending too much time doing things that didn’t make their beer taste any better. And if that was happening at Amazon, then it must have been happening everywhere.

Amazon already offered limited software tools to developers and businesses through Amazon Web Services 1.0. And the company was already building the digital infrastructure it needed to run its expanding operations.

Maybe it was time to take that infrastructure expertise and externalize it so other people could make their beer taste better.

The idea for AWS didn’t emerge fully formed from that offsite in 2003. But it was the day the starting gun was fired.

Jassy’s Vision Statement Lays Out the Future of AWS

We’ve now arrived at the part of the story where Andy Jassy wrote his six-page vision statement for AWS. By now you know how high the stakes were. But I haven’t explained what was actually in that memo.

To inform his thinking, Andy assembled a “tiger team” of the 10 best technical minds within Amazon. Together they deconstructed the major web services of the day, like Google and eBay.

They reflected on their own expertise within Amazon, on Amazon’s principles as a company, their target audience, their competitors, and the vision emerged.

The team came up with a list of “primitives” – basic, highly flexible services:

  • Storage
  • Compute
  • Databases
  • A content distribution network

These are the raw materials of what became AWS – the Lego blocks, in other words.

The team also decided that in order for AWS to make an impact, it had to be:

  • Flexible and scalable
  • Built from the bottom up
  • Launched with as many services as possible

It wouldn’t be easy, but the opportunity was right there. As a result of all that planning and deliberation, Andy’s memo didn’t just suggest that Amazon rent out their unused server capacity.

He suggested a pricing model. He sketched out technical and implementation details. It was a collaboratively produced roadmap.

No wonder the S-Team was impressed. Let’s go back to Alan Vermeulen, because he wrote the six-page proposal for what became the first core component of AWS – the Simple Storage Service, or S3 for short.

He wrote most of it at the Six Arms pub in Seattle. And because he had already contributed a lot to Amazon, his ideas were taken seriously. His proposal was approved and he put together a team to build it.

Jeff Bezos was so closely involved in the development process that Alan Vermeulen called him the product manager of S3.

  • He asked questions,
  • Suggested ideas
  • Challenged Allan and his team to think big

Having Jeff Bezos as your product manager would be pretty scary. But it showed that he was all-in.

Amazon never had to raise any capital to build AWS because the company’s senior leaders were committed to the project and took the time to understand it.

The Launch of S3 and EC2

On March 14, 2006, Amazon launched S3. S3 stores objects – which is just any text, images, and other assets that customers create as part of their normal business. It’s a massive disk drive in the cloud.

Before S3, companies including Amazon itself were paying way too much for data storage. The old business model created a tough dilemma for companies that handled lots of data:

  • Either you bet on yourself, in which case you needed to spend massive amounts of money to install fixed amounts of server capacity.
  • Or you set your sights lower, spending less in the short term, but limiting long term potential.

It was a lose-lose situation. So many businesses either didn’t grow as large as they could have or were never founded in the first place – all because of data storage costs.

S3 totally turned that on its head. All of a sudden, you could store data in the cloud and you’d only pay for what you used. You didn’t need to have deep pockets to buy space in S3.

  • You could sign up with an email address,
  • Pay with a credit card
  • And get started that day

It was as flexible as you were. And according to Andy Jassy, it was informed by what Amazon’s customers were telling them:

“We were facing some extraordinary growth. So streaming at that point in 2008 was about a million hours a month. And now it’s over a billion hours a month. So we’ve had this thousand-fold ramp up in computational resources necessary over just four years with the advent basically of broadband networks and streaming.”

In August of 2006, just a few months after the launch of S3, Amazon launched the second core component of AWS – the Elastic Compute Cloud, also known as EC2.

There’s actually some controversy about how EC2 was created. The official narrative is that EC2, or something like it, was in the memo that Andy presented to Amazon’s S-Team.

The dissenting narrative is that the EC2 concept was actually developed by a guy named Chris Pinkham, who was leading Amazon’s network engineering operations at the time.

Andy Jassy actually addressed this in his infamous one-star review of the book The Everything Store when he wrote:

“The vision document proposing the AWS business and outlining the initial set of services for AWS, including our compute service EC2, was finished and presented to the executive team in September of 2003. I wrote the document and was lucky to have the help of several people in putting it together.”

Does it Matter Who Came Up With the Idea?

Who is right? Does it even matter?

It matters because it reminds us that a concept as disruptive as AWS could only come from Amazon itself. And it matters because it’s a reminder that the idea is just a small fraction of the actual work.

You’ve still got to actually build the product and the business. And Chris Pinkham had left Amazon before EC2 even launched.

So what is EC2? It’s basically a network of virtual computers that you can use to run applications:

  • You log in and configure a virtual machine (an instance)
  • It’s elastic because a user can create, launch and terminate instances as they need

The same way that S3 blew people’s minds by providing infinite storage at low cost, EC2 provided a way for everyone to perform intensive computations in the cloud.

It was truly revolutionary. All of a sudden you didn’t need to spend months and millions of dollars on data centers. You could create an account and let Amazon, with their unbeatable scale, do the heavy lifting.

As a value proposition it was hard to resist.

AWS Growth Driven by Startups and Enterprises

At this point it’s important to differentiate between two types of AWS customers – startups and enterprises – because they both tell different stories about its massive success.

For startups, the use case was immediately obvious:

  • Low-cost storage and compute when you needed it
  • If you were a developer, you could even just build applications on top of it

But initially there was some skepticism about whether established enterprises would adopt it with the same enthusiasm. Even if the status quo wasn’t perfect, it seemed like a risk for enterprises to lift and shift their storage and data center operations onto AWS.

Netflix Shows the Way for Enterprises

Enter Netflix.

We were facing some extraordinary growth. So streaming at that point in 2008 was about a million hours a month. And now it’s over a billion hours a month.

So we had to take some risks. Doing that kind of buildout with your own data centers was going to be challenging. And it’s worked out great for us.

And the key is that now we’re on a cost curve and an architecture that, you know, with all of this momentum with AWS, we benefit by that collective effect that gets you to scale and brings the prices down.

Netflix started out by mailing DVDs to subscribers. But with the opportunity of streaming ahead of them, they realized they needed to change up their business model.

At first Netflix actually partnered with Microsoft to build out their video streaming capacity. It cost millions of dollars. Switching over to AWS looked risky.

But Reed Hastings knew that not switching over was a much bigger risk. By the time he spoke to Andy Jassy at the first-ever re:Invent conference in 2012, 95% of Netflix’s computation and storage was in AWS.

There’s something else worth mentioning here. As AWS was getting better, it was also getting cheaper – one of the major announcements at re:Invent was a 28% reduction in S3 storage costs, enabled by infrastructure upgrades and economies of scale.

Amazon didn’t really need the credibility of a customer like Netflix, and it probably wasn’t even the first big enterprise to switch to AWS.

But Netflix switching over showed everyone that not only did enterprises have nothing to fear from AWS – they could use it to become a better company.

And it wasn’t just Netflix:

  • Airbnb launched in 2008
  • Uber the year after
  • Stripe the year after that

All of them are multi-billion dollar companies. None of them would look the same without AWS.

Today, AWS customers use it for absolutely everything – from storage, development and testing to scientific computing, CRM, and maintaining mission critical financial systems.

More than 15 years after launch, EC2 and S3 still form the core of AWS. But Amazon’s engineers never rested on their laurels. They kept rolling out new features and they just kept on going.

In late 2008 they released CloudFront, a service that speeds up delivery of web content.

  • Virtual Private Cloud, a serverless database service
  • A massive data warehouse platform

With each new AWS product, Amazon was sending a clear message:

  • We’re listening to our customers
  • And squeezing our competitors

S3 originally launched with 8 microservices. When Amazon’s CTO Werner Vogels took to the stage to deliver the keynote address at the 2022 re:Invent conference, it had more than 235.

AWS doesn’t get taken offline for maintenance. In fact, outside of a service disruption in 2011, AWS has pretty much never gone offline.

AWS customers never have to upgrade to a new version because the service is constantly being updated.

All of this goes back to that fundamental point I made earlier – coming up with the idea of AWS was an incredible achievement that’s worth studying.

Relentless Focus on Execution

But actually executing, day in and day out, is what’s allowed Amazon’s leaders to grow it into the world’s most successful internal startup.

Today, you could easily build an family tree of all the different AWS services. But beyond the different products and services there is an extremely simple value proposition:

“The reasons we hear people moving to the cloud – you get to trade CAPEX for variable expense. That variable expense is lower than what you can do on your own.

It provides you elasticity, so you only pay for what you consume. It lets you move much more quickly. It lets you use your scarce resources of engineers on things to differentiate your business.

And then you can go global and provide that customer experience in minutes or days, as opposed to months.”

The story of how Amazon built AWS is also the story of how its rivals failed.

The simple version is that Amazon beat the existing data storage and database providers by providing a better product at lower price. And beat Microsoft and Google by being first to market.

Microsoft and Google Play Catch-Up

There’s an alternate reality where I’m making this video about Microsoft. And it’s not too different from this one because, to be honest, Microsoft should have figured out cloud computing sooner.

The reason they didn’t was because the company was a total mess in the Steve Ballmer era. Its priorities were all wrong. Windows teams had too much power internally, so anything that looked like it could cannibalize that revenue stream was watered down or scrapped entirely.

Meanwhile, Ballmer was too focused on taking down the iPhone. He eventually got with the program and of course Satya Nadella saw the potential of cloud computing right away.

But by the time Microsoft took Azure seriously, it was already a long way behind AWS. It’s been playing catchup ever since.

What about Google? The theory I’ve read which I agree with is that basically Google didn’t have the right combination of skills and incentives internally to see the opportunity like Amazon did.

Google became one of the world’s biggest and most cash-generative businesses mostly through a single product – search. But it never really needed to get its hands dirty.

Its leaders never had to learn to sell to consumers or enterprises. They never had to learn how to grow under tight profit margins. So they weren’t really equipped to build a platform like AWS.

Of course today, both Microsoft and Google do have cloud computing platforms of their own:

  • Recent estimates put Azure at about 20% market share
  • While Google Cloud is at about 10%

So they’re making inroads, but both companies should have been competing with AWS years before they actually did.

But they were too distracted by the money they were making from software and advertising to see the opportunity.

Andy Jassy talks about this all the time – everyone in Amazon was stunned that their competitors were so late to cloud computing.

AWS ran the table for years because it was first to market. And even as real competitors have emerged, Amazon’s maintained its advantage because AWS is:

  • Easy to use
  • Cost competitive
  • The default choice

By the Numbers

The numbers around AWS are hard to comprehend:

  • More than half of Amazon’s total operating profits have come from AWS
  • Its revenue curve is absolutely insane
  • If it switched off the lights on today, Amazon corporate would still have more than $100 billion worth of committed revenue coming in from AWS

But the true value of what AWS has accomplished is impossible to capture fully. Because of that people tend to reach for analogies:

  • AWS is like Lego
  • AWS is like oil

I think Jeff Bezos nailed it when he spoke at Y Combinator Startup School – AWS is like electricity.

The Engine Powering Economic Growth

It’s a powerful engine for economic growth and technological progress in the 21st century. It’s a public utility that has enabled the existence of entirely new types of companies – the app economy, SaaS companies, modern streaming services.

None of these would exist without being built on top of AWS.

Not only that, it’s allowed existing enterprises like schools, banks, government agencies, even Amazon itself to generate massive amounts of value by focusing on what they’re good at.

And through the research I did for this article, I learned something profound – only Amazon could have created AWS when it did because it was the only company with:

  • A hard technical problem to solve
  • An internal culture that encouraged ultra-smart people to explore ideas
  • A relentless focus on execution

As a result, AWS powers the modern internet. For 15 years it’s basically had a free stake in every startup. And the bigger it gets, the bigger it gets because it can achieve further economies of scale and continue lowering prices.

It’s one of the biggest flywheels ever. If I had to put a number on it, I’d say that the total value created directly by AWS is in the trillions of dollars at this point.

That translates to millions of jobs, thousands of businesses, and higher standards of living for everyone. And those numbers are still going up every single day.

Passing the Baton

In his 2014 letter to Amazon shareholders, Jeff Bezos wrote that for all practical purposes he believes AWS market size is unconstrained. The intervening decade has basically proven him right.

So when he stepped down as CEO, almost 27 years to the day after Amazon was founded, there was only one choice for his replacement – his former shadow, the guy who almost became a sports broadcaster but wound up leading AWS.