The story traces back to September 2003 when Andy Jassy pitched a groundbreaking idea to Jeff Bezos about transforming Amazon by offering digital infrastructure to third parties. This idea, eventually leading to the birth of Amazon Web Services (AWS), was initially met with skepticism but gained approval. The pioneering service transformed the tech industry, becoming integral to companies like Uber, Netflix, and NASA, providing the backbone for numerous digital services. The origins of AWS involved overcoming significant challenges, from navigating complex software architectures within Amazon to external pressures, forcing innovation.

The launch of AWS radically changed the technological landscape, providing an affordable, scalable infrastructure for both startups and enterprises. S3 and EC2 emerged as core products, offering storage and computational power that drastically reduced enterprise costs. Amazon's success with AWS is also attributed to the company's rigorous internal culture, which emphasized decentralization and independent innovation. This unique combination allowed Amazon to dominate the cloud computing market and provided a blueprint for innovation that other tech giants like Microsoft and Google have struggled to emulate.

Please remember to turn on the CC button to view the subtitles.

Key Vocabularies and Common Phrases:

1. percolating [ˈpɜːrkəleɪtɪŋ] - (verb) - Gradually becoming more intense or widespread within a context or system. - Synonyms: (brewing, simmering, seething)

He had an idea that had been percolating in his mind for over a year.

2. infrastructure [ˈɪnfrəˌstrʌktʃər] - (noun) - The basic physical and organizational structures and facilities needed for the operation of a society or enterprise. - Synonyms: (framework, foundation, base)

Andy thought Amazon should build and sell digital infrastructure to third parties.

3. culmination [ˌkʌl.mɪˈneɪ.ʃən] - (noun) - The highest or climactic point of something, particularly after a long time. - Synonyms: (peak, zenith, apex)

It was the culmination of dozens, probably hundreds of memos.

4. disrupted [dɪsˈrʌptɪd] - (verb) - Interrupted by causing a disturbance or problem. - Synonyms: (disturbed, interrupted, upset)

Amazon disrupted the old business model because s three scaled with its customers.

5. redeployment [ˌriːdɪˈplɔɪmənt] - (noun) - The action of assigning people to new tasks or positions. - Synonyms: (repositioning, reassignment, transfer)

Teams inside Amazon had been spending too much time doing things that didn't make their beer taste any better.

6. elasticity [ˌiːlæˈstɪsəti] - (noun) - The ability to change and adapt easily; flexibility. - Synonyms: (flexibility, adaptability, resilience)

It provides you elasticity, so you only pay for what you consume

7. embraced [ɪmˈbreɪst] - (verb) - Accepted or supported willingly and enthusiastically. - Synonyms: (accepted, adopted, welcomed)

Bezos made a it was time to take a hammer to the existing monolithic architecture. It was time to embrace SOA.

8. decentralized [ˌdiːˈsɛntrəˌlaɪzd] - (adjective) - Distributed or spread power away from a central authority. - Synonyms: (distributed, spread out, dispersed)

It was a totally scalable, decentralized system

9. revolutionary [ˌrɛvəˈluʃəˌnɛri] - (adjective) - Involving or causing a complete or dramatic change. - Synonyms: (transformational, radical, groundbreaking)

AWS is one of the most revolutionary ideas in the history of tech.

10. constrained [kənˈstreɪnd] - (verb) - Restricted or limited in flexibility, scope, or action. - Synonyms: (restricted, limited, bounded)

I believe AWS is market size unconstrained.

Untold Origins of Amazon's Digital Command Center

It was September of 2003. Andy Jassy was nervous. He had an idea that had been percolating in his mind for over a year. Simply put, Andy thought Amazon should build and sell digital infrastructure to third parties. But he was one of the few who understood the 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 step backwards for his career at the company. Amazon would miss out on a massive market.

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 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 and 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. 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 and 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 society 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.

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 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. 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. 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 four xed between 1997 and 1998. Amazon was adding new features almost every day and hiring tons of engineers. 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 the 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. And 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 e-commerce platforms.

I'll let Andy Jassy explain. There were a few things going on, I'll call it between the years 2000 and 2003 that made us think this could be a good idea. You know, the first was this business at Amazon called Merchant.com, where we sold our e-commerce technology at 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 as 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. Jassi 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. 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 video that really matter. The distributed computing manifesto is one of those memos that really matters.

In just over 3000 words, the authors did three things. Firstly, they identified the flaws in Amazon's existing two-tiered architecture. Secondly, they proposed a different architecture model to replace it. And then, last but not least, they 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, or 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, don't worry. Here's an analogy 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, and then, after months of absorbing advice and information, Bezos made a it was time to take a hammer to the existing monolithic architecture.

It was time to embrace SOA. Bezos knew it would be one of the biggest leadership challenges of his career, because its 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 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 Yeage 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. In the post, which was mostly criticizing Google, Yege 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 helped to do things like create rankings, offer customer recommendations, and retrieve saved customer details. They're like Lego blocks, small, modular, unbreakable. Bezos believed APIs were the way forward for Amazon. He'd 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 Merchant.com dot. 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 change this was. As Yege 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.

If you were 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.

One of the best decisions Amazon made right around this time was hiring Alan Vermeulen. Vermulin 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 Conways law. He probably did. He's a smart guy. Either way, he was enacting Conway's law within Amazon. In July 2002, a couple years after Alan Vermeulen was hired, Amazon held a developer conference.

Today, Amazon's reinvent conferences are attended by thousands and watched by millions. But just eight 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 Amazon.com product catalog. Still, it was an indication that something big was beginning to happen.

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. So let's talk about him for a minute. 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 sportscaster 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 dot-com 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, people like Alan Vermeulen, had to build all kinds of new features. A bigger product catalog and more website traffic meant Amazon.com needed more community features like username verification and review ratings. 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 Amazon's engineers spent building cool things, maximizing their autonomy, adoption of rest architectures, standardization of infrastructure, removal of bureaucracy, and 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 Jeff Bezos. Obviously it was his house. Andy Jassy, the CTO, Alan Vermeulen, the CIO, Rick Dalzell and others.

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 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 two years. Matt rounds 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 and I mean for all of society, that the talk was recorded. I was in Luxembourg and I took a tour of a 30 zero-year-old brewery.

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. And 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. And what startup companies want, actually companies of all sizes, is they want to go from their idea or their 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 of 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.

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 ten best technical minds within Amazon, and 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, and 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. It had to be built from the bottom up and it had to launch 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, a 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 Allen Vermeulen called him the product manager of S3.

He asked questions, suggested ideas, and challenged Allen 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.

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 sites 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. Vermulin says that just before he retired from Amazon in 2021, he found the original S3 design document.

The growth projections were off by a factor of thousands. Within two months, the number of objects stored on S3 exceeded Amazon's expectations by a factor of 106 years. After launching, S3 had more than a trillion objects in storage. Today, that number has grown to over 100 trillion. That's what happens when you make infinite data storage convenient and affordable.

Amazon disrupted the old business model because S3 scaled with its customers. In effect, it allowed customers to trade upfront costs for variable costs. Every business will make that trade. Amazon's margins on S3 were never as big as Oracle's or IBM's, but that's fine. Amazon had years of experience dealing with lower margins from their retail business.

In addition to being highly cost effective, the S3 pricing model was optimistic because when you offer a solution that lets people focus on making their beer taste better and encourages other people to get into the brewing business, some of them are going to win. And when they win, they're going to need a lot more storage. They're going to need a lot more of everything that requires them to spend more money. And if you take care of them, they'll spend it on you.

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. In 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.

You won't find much mention of Chris Penkham in the official AWS story. Who was right? Does it even matter? It matters because it reminds us that a concept as disruptive as AWS could only come from Amazon's 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 Penkham 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. 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 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 from what they had onto AWS.

Enter Netflix. We were facing some extraordinary, 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 broadband networks and streaming. And so, you know, we had to take some risks, you know, doing that kind of build out 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 on an architecture that, you know, as all of this room does more 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 reinvent 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 reinvent 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 eight microservices. When Amazon CTO Werner Vogels took to the stage to deliver the keynote address at the 2022 reinvent 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, 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 Ancestry.com style family tree of all of the different AWS services. But beyond the different products and services is an extremely simple value proposition. One of the reasons we hear people move into the cloud you get to trade Capex or 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 that 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. A 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.

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 and Adela 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 catch up 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 at 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, and because it's the default choice.

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. And if it switched off the lights on Amazon.com 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 capture. And because of that, people tend to reach for analogies. Aws is like Lego, AWS is like oil, stuff like that.

But I think Jeff Bezos nailed it when he spoke at Y Combinator startup school. AWS is like electricity. 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 video, I learned something profound. Only Amazon could have created AWS when it did, because it was the only company with a combination of a hard technical problem to solve, an internal culture that encouraged ultra-smart people to explore ideas, and 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, which translates to millions of jobs, thousands of businesses, and higher standard of living for everyone.

And those numbers are still going up every single day. In his 2014 letter to Amazon shareholders, Jeff Bezos wrote that for all practical purposes, I believe AWS is market size 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 sportscaster but wound up leading AWS Andy Jassy. To learn more about another company that will define the future of computing, just watch this video next.

Thanks a lot.

Technology, Innovation, Business, Cloud Computing, Amazon, Software Development