The Rise of Amazon Web Services
My, my, AWS, how you've grown!
Let’s look at the engineering story behind AWS and how it grew from an interesting idea into an $80 billion business in the span of 20 years (2002-2022). We’ll learn about why Amazon decided to become a services and platform company, and how a couple technical decisions shaped the entire future of AWS.
The Birth of AWS in the Midst of Web 2.0
In 2000, coincidental with the various trends of “Web 2.0”, Amazon began investing in creating reusable compute and storage systems to solve recurring infrastructure needs that kept arising in its engineering projects. Crucially, Amazon’s engineering teams were instructed in a 2002 memo - by Jeff Bezos, no less - to take an API-first approach:
Teams will expose their data and functionality through service interfaces
Teams must communicate with each other through these interfaces
No other form of interprocess communication is allowed
Teams must plan for all service interfaces to be exposed to outside developers
If you’d like to learn a bit more about this mandate, Steve Yegge’s note about it is an entertaining read. It’s obvious if you use AWS - even today, over two decades later - that these principles are still fundamental to how they operate and are a primary reason for their success. In software engineering, APIs - and the contracts they define between services and their clients - are foundational to building reliable, decoupled systems. Since these were all network APIs, AWS quickly became the ideal platform on which large scale websites could be built.
By 2002, Amazon recognized there was an opportunity to make these services available to other companies, since developers everywhere would value these capabilities. Amazon released a quiet beta of SQS to the world in 2004 and then the production launch of SQS, EC2, and S3 followed in 20061. And so it was that scalable, on-demand messaging, compute, and storage were now a reality.
Initial Reactions
The initial reception from investors, the media, and businesses to the announcement of AWS in 2006 was mixed but overall optimistic.
One piece of coverage is quite amusing now. Jeff Bezos himself had it framed.
In terms of early developer adoption of AWS, the numbers speak for themselves. Approximately six months after the official launch of AWS, over 150,000 developers had signed up to give it a try.2
The Early Growth of S3
Let’s look closer at the early growth of S3, as a proxy for studying the growth of AWS more generally. Courtesy of the first AWS re:Invent keynote, we have this chart of the total count of objects stored in S3 from 2006 to 2012.
It’s not surprising to see this exponential growth curve from a product as successful as S3 has been. Many engineers, myself included, jumped at the opportunity to try out S3 when we first learned about it, and readily incorporated it into services and products. By using S3, engineers have effectively infinite disk space, excellent durability, and a straight-forward API at their disposal.
The Magic of S3:PutObject
As a developer, it’s really incredible what a single PutObject call gets you. It’s an easy call to make and the result is an object with 99.999999999% durability, server-side encryption, and access control. That’s pretty great, in my opinion.
Netflix: A Major Success Story for AWS
In 2008, Netflix began migrating to AWS. By 2010, Netflix started using AWS for the majority of its computing needs. By 2015, they completed their migration to the cloud. These moves allowed Netflix to scale its streaming services to meet the demands of a quickly growing customer base, where each customer was also streaming more and more content. From 2008 to 2015, their customer base increased by 8x while their monthly total streaming hours increased 1000x.
Netflix's choice to use AWS was an early indicator that cloud computing was viable for a large operation like Netflix. This was a widely touted success story that gained a fair amount of coverage and acknowledgement in the industry.
One reason cited by Netflix for why they chose AWS:
Letting Amazon focus on data center infrastructure allows our engineers to focus on building and improving our business - Netflix Technology Blog3
Netflix was pivotal in demonstrating the AWS was ready for prime time. There were other success stories, of course, such as NASA JPL’s use of AWS for image and video infrastructure for the Mars rovers4. Also, the US intelligence community’s adoption of AWS via the C2S contract in 2014.
Two Pizza Teams and the Proliferation of Services
"We try to create teams that are no larger than can be fed by two pizzas. We call that the two-pizza team rule.” - Jeff Bezos5
From humble beginnings (or so it seems now) with only EC2, S3, and SQS, AWS has experienced a remarkable growth in the scope. The shape of their offerings today is interesting (as in, complex) and is a result of some of the principles mentioned earlier:
The services and API-centric approach
The two-pizza team rule which guided team size
The default stance that services should be externally available
When you combine these constraints with the growth of AWS and cloud computing overall, the natural result is a plethora of services. Here’s a great depiction of the state of AWS services today: the Periodic Table of Amazon Web Services, credit to Jerry Hargrove.
Looking at this graphic, it’s obvious why newcomers to cloud computing and AWS are often intimidated and don’t know where to start.
You can also view this as Conway’s Law6 operating at scale.
To their credit, AWS does an admirable job with compatibility and stability over time. Once a service or capability is released, developers can generally rely on it to not have breaking changes. Services are rarely discontinued. Forced upgrades are uncommon. AWS has demonstrated they’re committed to this, and I’m certain that a lot of difficult and unglamorous work happens behind the scenes to make it a reality. Developers appreciate this about AWS.
The Rise of Infrastructure-as-Code (IaC)
The point of Infrastructure-as-Code, or IaC for short, is to automate the creation of cloud resources. Cloud resources include VMs, networks, databases, and hundreds of other resources offered by the cloud provider. Using IaC is the best way to make the process fast, repeatable, reliable, and auditable.
AWS launched CloudFormation as its IaC solution in 2011. Here’s the original announcement. Today, it supports IaC provisioning with over 200 AWS services.7
Effective IaC greatly facilitated broad and large-scale cloud adoption. Without CloudFormation and Terraform, the dominant open source IaC solution, it’s likely that AWS would have grown more slowly. Mitchell Hashimoto’s origin story of Terraform relates to all this and is a fun and quick read.
AWS re:Invent
The annual AWS re:Invent conference is a highly anticipated tech event. Since its inception in 2012, always held in Las Vegas, re:Invent attracts a huge number of attendees: around 6,000 in 2012, growing to an incredible 60,000 in 2019. The event is now transitioning back to normality following a rather lackluster virtual execution during the height of COVID.
Watching the very first re:Invent keynote now is quite interesting. It’s impressive to see the progress they’d made by 2012. Here’s a quick link to the segment with Andy Jassy (now CEO of Amazon) and Reed Hastings (then CEO of Netflix).
I’d say one of the standout moments at re:Invent over the years was the Announcing AWS Lambda segment in 2014. The subsequent rise in the serverless compute movement has been transformative to the industry.
Sky High Revenue… but Slowing Growth
Starting around 2013, Amazon began sharing AWS revenue as separate from the rest of their business. At that time, AWS was at an annual revenue of $3B. By 2022, annual revenue had grown to a whopping $80B with $23B in profit.
However, there are now headwinds. Their year-over-year (YOY) revenue growth rate declined from 70% to 28% in that same time period. In Q4 2022, AWS experienced their first YOY decline in profit since 2015. Margins are tightening. As with many tech companies, Amazon implemented significant layoffs this year, including many from AWS.
Grumblings from Customers
Given its size and success, AWS is a force to be reckoned with.
One uncomfortable position for a business is to be a customer of AWS and then down the road find that AWS is suddenly competing with you. With AWS’ ever expanding offerings, a business in an adjacent or complementary space one day may find AWS directly competing with them the next. With over 200 services, this is more common than you might guess.
Next up, cost is of course one of the more common objections to AWS. The folks at Hey and Basecamp shared this in their blog recently:
Let's take HEY as an example. We're paying over half a million dollars per year for database (RDS) and search (ES) services from Amazon. Yes, when you're processing email for many tens of thousands of customers, there's a lot of data to analyze and store, but this still strikes me as rather absurd.
There are also subtle sources of costs that can add up to something significant for certain types of workloads. Some of these are regarded as anti-competitive.
The complexity of the AWS service landscape is also noteworthy. Identifying which services to use can be quite a challenge. It can be easy for developers to go all-in on a broad set of AWS services only to find out later that either the reality doesn’t match the hype, or that the rest of the team can’t understand the solution.
Takeaways
While there are plenty of justified critiques and criticisms of Amazon and AWS, it’s clear that AWS has been a tremendous business and engineering success. Stay tuned though. Indications are that the most challenging times lie just ahead.
It’s interesting to consider how AWS would have evolved differently without some of the early mandates. This is something for engineering leaders to consider in their own businesses, as they work to set directions with their teams.
Please let me know if this post was useful to you. And feel free to reach out if you’re looking for advice on how to best leverage AWS in your specific situation.