In 2002, Amazon launched a side business with little fanfare: cloud Infrastructure as a service. 20 years later, it now makes over $70B in annual revenue. It’s a huge business. In fact, AWS’ hefty profit represents well over 50% of Amazon’s total.
It is Amazon’s crown jewel. In a conglomerate full of great businesses, it is the best. One of AWS’ first leaders, Andy Jassy, has now become the CEO of Amazon itself.
So, you’d think AWS was a well-known story. It isn’t. Most of my family members whom I chatted with while writing this piece had never even heard of it.
By comparison, Coca-Cola did about $40B of revenue in 2021. AWS is on track for nearly double Coke’s revenue, yet operates in the shadows. Even tiny $4B revenue Zoom is more well known.
Moreover, what has been written about AWS’ history is hilariously wrong. TechCrunch and most other major publications write that AWS began in 2003 after Andy Jassy’s conceptualization of an ‘Internet OS.’ They then say the service itself was launched in 2006.
Both “facts” are completely incorrect. The breadcrumbs of the internet, aided by sites like the Wayback Machine and technology like caching, never disappear. AWS first launched in 2002 and was led by Colin Bryar.
For a business that is doing over $70B in annual revenue, the lack of a lucid and correct history of the company is baffling.
But that’s why I write the Product Growth newsletter, to tell the product stories of today’s most significant technology businesses. Like we did with Stripe, PayPal, Coinbase, and Kayak, we’re going to set the record straight on the product vision, strategy, and roadmap that AWS used to conquer an industry.
I am particularly excited to present a collaboration with Ruchin and the team from the Top of the Lyne this week. They write one of the best newsletters on product-led growth and themselves just raised a $15M series A from Sequoia. There’s no better group of guys to analyze AWS.
We have spent the last four months going deep to get you the real history and product lessons from the giant, with a likely $500B+ enterprise value. So let’s get into it.
Lesson 1: Productize Your Strengths
In 1998, Amazon was still a young company. Started 4 years earlier, the company had grown meteorically. But in such a whirlwind of growth, the company perennially planned for the next year – not the next ten. Thinking so far ahead was not even realistic.
As a result, the codebase was mostly a mess. Changes to the codebase to add new features like video streaming took far longer than they should have, because the monolithic application was originally built for the retail business. The company was hiring more engineers, but was not able to build things faster.
One business unit that acutely felt these frustrations was Amazon’s new e-commerce service, to be known as Merchant.com. The way everything on the site was built into a single monolith had become too much to support development.
As a result, an internal engineering document was created and widely circulated, “The Distributed Computing Manifesto.” It became legendary. And the initiative picked up steam. APIs worked to drive a smoother development environment for Merchant.com. They helped with both the speed and difficulty problems.
Specifically, the service architecture represented three key evolutions:
- The microservices architectural pattern
- One to one database to microservice mapping
- Enabled each team to release independently
These evolutions were so dramatic and valuable that by the year 2000, the whole company committed to them. Amazon made the conscious shift to become a “services company,” with a well-documented set of APIs.
Amazon built these API-access systems leanly and efficiently. Under Bezos’ leadership, in which frugality was a core value, these internal services were built with considerable cost advantages compared to alternative options.
The company’s success in developing such a great option for internal teams led to the company testing the external market. In March 2002, led by Colin Bryar, the company released its first AWS product. It was targeted at affiliate marketers. The SDK (software development kit) allowed them to query extensive data about Amazon’s product catalog.
The product was an instant success. Interest from developers was immediate – not just affiliate marketers.
Literally hours after releasing this feature, I knew that we were onto something big and that our experiment would far exceed our expectations
Colin Bryar
Developers across the world were using the web service to develop new web sites and applications. One site quizzed users on the subject of cover art. Another, the whimsical baconizer.com, mapped the connections between any two items in Amazon’s catalog.
AWS’ first feature became a rich service for media sites.
Lesson 2: Work Backwards
While the affiliate service was a hit, that product is no longer even available. It was the feature that started AWS, but not the feature that would grow it. For that, the Amazon leadership had to return to the key tenets of Bezos’ philosophy, now enshrined as a leadership principle: work backwards.
The process of working backwards starts with a fundamental insight. Customers always want more. As Jeff puts it, “Customers are beautifully, wonderfully, dissatisfied.”
Working backwards emanates from this epicenter of dissatisfaction. First, the locus of customer dissatisfaction is clearly defined. Second, the team works backward to invent on the customer’s behalf. Finally, three core artifacts are created:
- A Press Release – announces the product that addresses the pain point. Drafted iteratively until it’s convincing enough for the product to be truly sellable.
- An FAQ doc – a supplementary document that accompanies the PR release and answers predictable questions from internal stakeholders and potential customers.
- A visual representation of the customer experience that distills drives home an endpoint to innovate towards.
The AWS team completed these three in real-time. In July of that year, the team released one of Amazon’s famous press releases. It’s one of those rare product artifacts we as external observers get to see.
What’s remarkable about this press release is how the first two paragraphs encapsulate the vision of AWS for 20+ years to come:
Today Amazon.com (Nasdaq: AMZN) launched its first version of “Amazon.com Web Services,” a platform for creating innovative Web solutions and services designed specifically for developers and web site owners.
By using Amazon.com Web Services (www.amazon.com/webservices) developers can build applications and tools that will allow them to incorporate many of the unique features of Amazon.com into their web sites — free of charge.
Press Release
It’s proof that in 2002, the AWS team was already working backward. It identified that the affiliate feature was just the “first version,” of a future platform for developers to incorporate the unique features of Amazon into their own websites.
Working backward is deceptively simple. But it forces clarity and helps prevent building for building’s sake (“the build trap”.) For AWS, it narrowed the team’s field of vision to solving real customer needs. Inc. Magazine has gone so far as to call working backward “Amazon’s Secret Weapon.”
As a result of this working backward process, the initial AWS product continued to grow in usage throughout 2002 and 2003, demonstrating the market demand for similar services. Amazon executives noticed the success of both the distributed computing manifesto and AWS.
At a retreat at Jeff Bezos’ house in 2003, the executive team conducted an exercise to identify their core competencies. Infrastructure as a service rated particularly highly. They realized Amazon had gotten particularly good at running reliable, scalable, low-cost infrastructure.
So they decided to invest more in the Affiliate feature to try and build a full-fledged AWS initiative.
Lesson 3: Build Lego Blocks
As part of investing in a full-fledged AWS, Jeff put one of his most trusted executives, Andy Jassy, on the project. As Andy settled into the job, he pinpointed the company’s strengths in compute, storage, and databases. He also identified these as the three key building blocks for web-scale applications.
To articulate his vision, he began calling this, “an operating system (OS) for the internet.” That would become the product vision for AWS. Jassy assembled a mix of business and engineering folks to kick off the initiatives.
Over the course of 2003, one of the team’s main objectives was to learn from its pre-existing users. Colin Bryar described this period before the initial launch of AWS as virtually 18 months of engineers not writing code.
Instead, the goal of the team was to deeply understand user needs. Amazon held a conference for users of the data. Eight people came. But one of those would be another key early hire for AWS: Jeff Barr, who is still with the company today as Chief Evangelist.
Jeff started the AWS news blog and has been writing posts almost daily. He has penned thousands of posts expanding on the concept of Amazon S3 and AWS features as lego blocks. These posts have helped to, internally and externally, build the shared understanding of AWS features as building blocks for modern internet applications.
With user research and fundamental technical insight from what Jassy described as, “ten of the best technology minds and ten of the best product management minds,” the team created the early product roadmap of lego blocks: databases, storage, and compute as initial infrastructure pieces to launch.
Meanwhile, by mid-2004, 50,000 developers had downloaded the original affiliate-targeted Amazon SDK. Over a hundred applications were built.
The team followed up the SDK with the release of two beta services, to begin achieving the vision of a web OS: Alexa Web Information Service (AWIS) and Simple Queue Service (SQS). AWIS was a natural evolution of the product catalog. It is now sunset.
SQS is still around today. SQS helps developers decouple and scale microservices without the need to maintain messaging middleware. It played an important part in building out the OS layer for the internet.
Lesson 4: Price Based on Usage
AWS’ products, for the most part, were free beta features up until 2005. Over the course of that year, the team focused on understanding the next user cases and graduating those features from beta to full-fledged products.
The two crown jewels of the web OS strategy, compute and storage, were offered to customers under non-disclosure agreements. The beta testers loved both. So, Jassy and the team knew they needed to pair their great product with a great pricing model.
They ultimately decided to price based on usage. This would prove to be a fundamental insight. By providing low-cost services on a usage basis, AWS could cater to everyone from the newest garage startup to large, Fortune 500 companies.
Usage is one of the most democratic pricing models. It recalls the customer friendliness of Netflix’s recent move to cancel unused subscriptions for users. If you forget to use AWS, you’re not going to get a bill. If you’re not seeing value out of AWS, you can just stop using it.
The iconic feature to first take on this pricing model was Amazon’s storage product. In March of 2006, Amazon released Simple Storage Service (S3). It would make the type of storage that had been available to Amazon’s developers for years – virtually infinitely scalable, cheap, and available online – available to any developer. It was the second step toward Jassy’s web OS.
What was especially remarkable about pricing based on usage is how attractive the service was to startups. It’s worth listening to how startup developers described the S3 functionality. It was much better than anything else available.
There was nothing that we had access to that provided anything remotely like what S3 could do. I felt like somebody had just given me the keys to the candy store.
Don Alvarez, whose startup FilmmakerLive used S3 in 2006
For larger companies, they could often create in-house, on-premises storage solutions that were cheaper than S3. But for startups, those initial fixed costs to build data centers was far too high. This meant that S3 was clearly the superior option for generational startups like Airbnb, Pinterest, and Stripe.
Later that year, Amazon launched the next most important component of the web OS: compute. Elastic Compute Cloud (EC2) was released just four months after S3, in August. Where S3 brought Amazon-style storage to any developer, EC2 brought compute that was virtually infinitely scalable, cheap, and available online.
Essentially, EC2 Amazon allowed developers to rent virtual computers in a datacenter. With those computers, they could run their own applications. At 10 cents an hour, it was an easy, relatively inexpensive way to scale up computers to run “web-scale” applications.
Important for being available online, that data was also highly reliable and secure. An upstart could have created the same service as Amazon at the time, but it wouldn’t have been as successful because it wasn’t backed by the Amazon name, which had by that point established a 12-year track record of security and reliability.
Like S3, EC2 proved to have near-instantaneous product-market fit. As a result of the two products’ success, the company would book $21M of revenue in 2006. Even as the company released a litany of new products over the years, compute and storage would represent a majority of Amazon’s revenue for over a decade to come.
Lesson 5: Think Aggressively Long-Term
With EC2 and S3, Amazon had cracked open the cloud infrastructure as a service market. Cash was flowing in. Analysts were peppering executives with questions about operating margins. Executives demurred. But internally they knew they were strong. Amazon just kept reinvesting those margins back into the business.
One example of this was geographical expansion. Just a few weeks after the launch of EC2 in full public beta for the US, Amazon added Europe. Imagine if a startup went to Europe in their first few weeks. You’d laugh that they’re set up to fail. But AWS did it. They made the big investment, thinking for the long-term. And, they succeeded.
This was not long-term thinking. This was aggressively long-term thinking. It was not just thinking about the next few quarters. It was investing for the next few decades.
Amazon is a very strong believer in moving very aggressively
Chris Pinkham, Engineering Head of Amazon Infrastructure in the Early 2000s
A few months later, Amazon followed up geographical expansion with another explosive product launch. The next component in the web OS, after compute and storage, was a database. Amazon launched Amazon SimpleDB, which used Hadoop technology atop EC2 and S3.
Over the course of 2006 and 2007, the team launched all three products determined to be the key components of a web OS: compute, storage, and database. It was another testament to Amazon’s ability to think aggressively long-term that it would launch such a broad range of services so quickly.
The company also priced with the long-term in mind. Margins were kept razor-thin to “shut the door” on competitors.
By 2007, developer websites were already touting AWS as the solution to the dreaded “TechCrunch problem.” A startup would experience 100x, or even 1000x, of its traffic load when being featured on TechCrunch. But their on-premises compute and storage systems could not support that traffic. The site would crash at precisely the team it had the most visitors.
As a result, when Google finally released the first true competitor to AWS in 2008, it did so to much less fanfare. Google App Engine’s initial product offer included not only infrastructure but also a set of Google APIs for authenticating users and sending email and a fully-featured local development environment.
Those features could not stop the momentum of AWS, however. The App Engine had low limits on daily usage. It was not ready for web-scale. Being nearly two years late to the game had its consequences. Amazon was beyond Google offering a limited service in 2008. In that year, AWS was busy graduating its beta service to full launch.
In the same year Google Cloud launched for beta, EC2 launched to public release with a service level agreement (SLA). Amazon made the remarkable commitment that its compute services would be available for 99.95% of requests at any time. This gave customers the confidence even the largest scale applications would run dependably on AWS. While App Engine was going after startups, EC2 was moving up through mid-sized businesses and into enterprises.
By 2009, this strategy was working in spades. It was clear AWS was going to be a success story. Jeff gave the business line a prominent mention in his annual letter:
We are investing heartily in Amazon Web Services.
Jeff Bezos
But instead of starting to milk the business for profits, the company continued to funnel cash its way. This manifested in several notable product launches.
To extend its compute offering, Amazon released a processing tool. In April, it launched Elastic MapReduce (EMR). EMR made it easier to quickly process vast amounts of data. Then, in May, it released a suite of products to make compute scaling easier. Elastic Load Balancing (ELB), Auto Scaling, and CloudWatch helped developers better manage rapid growth and the “TechCrunch problem.”
Amazon didn’t neglect the storage business, either. That same month, Amazon also released an Import/Expert service. This made it easier for users to get data into S3.
Amazon followed up its huge compute and storage launches with opening its third business line: networking. In August, it launched Virtual Private Cloud (VPC). VPC allowed customers to launch EC2 instances into their own isolated networks. It would prove to be a dramatic hit.
Against the backdrop of all these product launches, finally in February 2010, came the third big player in the cloud infrastructure market: Microsoft Azure. By that time, AWS already had a long head-start. It was opening in Asia. Because they had been willing to think aggressively long-term.
Lesson 6: Go Deep with Customers
While Google and Microsoft’s cloud teams were busy getting together their initial offerings, Amazon used 2010 to learn more about its customer needs. The team supported hands-on integrations with two important customers in particular: Netflix (today’s market cap: $85B) and Autodesk (today’s market cap: $40B).
AWS worked to learn how to move all of Netflix and Autodesk’s traffic to AWS. It was a process of closely engaging with the engineering teams at Netflix and Autodesk. It was a classic example of the Amazon leadership principle of, “Customer Obsession.”
Going deep worked. By the end of 2010, the majority of Netflix’s traffic was supported by AWS. As their VP of Engineering at the time wrote:
We think cloud computing is the future
Netflix VP of Engineering, John Ciancutti
AWS had managed to prove to the world that the cloud was the future. To capitalize on that success, it widened the use cases.
2010 would see a suite of product launches, including the Simple Notification Service (to compete with Google’s email APIs mentioned above), CloudFormation (an early example of a declarative Infrastructure as Code tool), and Route 53 (a Domain Name System accessible via API).
When asked about how AWS chose the right features time and time again, Jassy explained how the team built their product roadmaps. 90% came from going deep with customers, and 10% came from inventing on customers’ behalf.
Many companies talk about being customer-focused. Very few walk that walk… 90% of our roadmap, and what we build, is driven by what customers tell us matters. The other 10%, we try to listen to what customers are trying to articulate, then read in between the lines, and invent on their behalf.
Andy Jassy
By spending so much time with these rapidly scaling web 2.0 companies, Amazon was able to shape its product roadmaps precisely for their needs.
This paid off in the eyes of analysts. When Gartner released its magic quadrant for Cloud Infrastructure as a Service and Web Hosting, Amazon ranked highest in terms of completeness of vision.
The competitors at the time were mainly web hosting providers, many of whom have since exited the infrastructure as a service market. AT&T, Rackspace, Verizon – these are network providers who lacked technology DNA. You don’t see them in the quadrants anymore.
Instead of worrying about the weak competition, Amazon focused on being obsessed with the customer.
Indeed, the third customer the team focused on that year was quite important: itself (the Amazon retail business). The team again went deep to learn the final blockers fo the business: reliability, backups, scaling. It added features to solve those blockers, and, again, it worked. By the end of 2010, Amazon Retail announced it had fully migrated its web services to AWS.
After moving Netflix, Autodesk, and Amazon Retail over to AWS, the team had the confidence to turn on the sales machine.
Lesson 7: Build for your Ideal Customer
With all the components in place for a full cloud SaaS offering, Amazon added top-notch sales execution to its playbook between 2011 and 2015. Of course, the company continued its rapid pace of product launches, but what’s most notable about this time period is how it also started a deliberate and expensive outbound sales motion to capture larger customers.
But it didn’t just build for everyone. Building for everyone is building for no one.
There’s a concept in sales of the ICP: the Ideal Customer Profile. Amazon’s was the #2 or #3 player in any space. They were the one’s most likely to embrace transformational IT. The #1 player, on the other hand, is far more likely to want to feel confidence in its current solutions and want to avoid ripping the guts of its core systems out and into Amazon’s hands.
This allowed the product and sales teams to focus on 3,500 named accounts that they wanted to win. To them, AWS deployed armies. As Jassy revealed at AWS re:Invent 2016, it had thousands on its field sales and solution architecture teams.
One of the reasons AWS turned to beefing up its sales teams so dramatically was the competition. By 2013, Azure made an appearance on Gartner’s new quadrant focused on Infrastructure as a Service. Starting on the bottom right, it quickly jumped to just behind AWS in 2014, when Google Cloud also shows up. Since then, the two of them, followed in distant fourth by IBM, have been challenging the market Amazon opened up.
Between 2012 and 2015, Gartner would analyze 24 new entrants to the market in total. While these players would be throwing money at the problem, AWS was already massively profitable.
Lesson 8: Create a New Product Flywheel
In 2013, VentureBeat published a piece on, “Amazon’s ‘mountain of margin’ in cloud services.” It estimated that the division had gross profit margins of over 80%.
Much of this margin was and is driven by EC2, one of the original products the team had conceived of 10 years earlier. Two of the methods EC2 used to drive such hefty margins are:
- Not deprecating products
- Allowing customers discounts on reservations for future use
Both are somewhat counter-intuitive. Most companies deprecate older products, so they can reduce maintenance complexity. But AWS took good care of its old servers. Instead of taking them offline, it offered them to customers at cheaper costs than new machines.
Allowing future reservations is also counter-intuitive, but useful. It helps the company better predict how much hardware it needs to bring online to the cloud. In that way, it helps control costs. So it is a win for both customers and AWS.
Beyond EC2, another large driver of profit for the company is data transfer. Although the cost of bandwidth continues to fall, AWS continues to charge the same price for data transfer fees.
All this profit from EC2, data transfer, and other existing products was deployed to launch new products to help the challenger player take over. In 2013, Amazon released Kinesis, for real-time processing of streaming data. This enabled analysts to look at the data as it is happening.
This is a must for former gaming PMs like myself. When a Fortnite event was happening, we needed to know how many players were coming online. Such data needs are important but also computationally expensive.
These types of applications built atop AWS infrastructure have the benefit of ringing up large bills on their own, and also ringing a bigger bill in infrastructure costs.
Similarly, in 2014, AWS introduced the concept of serverless with AWS Lambda. Customers who use Lambda end up paying almost double in EC2 costs.
This generates, “the AWS New Product Flywheel.” AWSreleases new products, which enable customers to generate more business value, which creates continued increasing demand for AWS’ infrastructure products, which enables the company to fund the development of more new products. Each activity feeds the next.
The Flywheel works to generate hefty profits, too. At scale, it doesn’t need to all be re-invested. By 2016, AWS was significant enough a driver of Amazon’s total profit that the company began breaking it out in its annual reports.
Since then, it has been tapping on AWS’ tremendous gross margins to drive operating margin that funds the rest of Amazon’s businesses. AWS has gone from the cost center to the profit center. On that amazing $70B in ARR, operating margins are about 30% – and increasing.
Lesson 9: Define Success for Customers
Towards the end of the last decade, AWS’s lead in the market was beginning to slip. IBM, Google, Microsoft and others made big bets on cloud computing, and started bolstering their offerings.
In particular, Microsoft made tremendous inroads into the market. In fact, market analyst Cloud Wars places Microsoft ahead of Amazon in cloud revenue.
On the back of Microsoft landing the US Military’s $10B JEDI contract in 2019, AWS announced that they were doubling their sales staffing numbers. This shift in sales strategy was a war cry.
Like their product counterparts, AWS Sales teams defined success through their customers’ eyes. In fact, this has been formalized into widely-known and publicized four-step process, known as OBAM (Outcome-Based Account Management):
- Explore: where a value hypothesis is drawn up based on extensive research of a prospect’s digital strategy, external factors, challenges and opportunities.
- Engage: where the credibility and trust are earned, leads qualified, and the initial value proposition is delivered. Customer maturity is graded based on org structure, the mechanics of procurement/legal, etc.
- Empathize: where a tailor-made fit is identified for each lead based on org culture, and even personal agendas, and communication styles of individuals. This stage is all about relationship building.
- Enable: where the roles and responsibilities of AWS resources and the account value proposition are fleshed out.
OBAM is very similar to the product team’s working bakwards approach. It hinges on the sales team defining success for customers.
And, despite the cheesy name, it has been working tremendously.
Lesson 10: Be So Good the Government Needs You
Since losing the JEDI contract (now canceled), AWS has seen a tremendous run of growth in the public sector. Major contracts include:
AWS has hired at least 66 former government officials with IT software procurement experience. This helps AWS get the leg up in procurement processes, since they know exactly how to respond.
Former government acquisition officials help Amazon win contracts because of their “intimate familiarity with the bureaucracy associated with the ‘request for proposal’ process. Somebody who’s been on the other side knows exactly how RFP proposals are competitively considered and analyzed. That’s where we get the leg up
Hazem Eldakdoky, senior technical program manager at AWS, former deputy chief information officer at DOJ’s Office of Justice
In 2021, the Economic Times published that, “AWS’ public sector business has seen its headcount double every year for the last three years. The company is even forecasting massive growth in the years ahead.
AWS has succesfully become so good the government needs them. And it’s not just the US government. AWS has signed large contracts with governments around the world, from Australia to Zimbabwe.
Takeaways
It’s truly rare these days to see pre-existing tech companies with major success in one business area expand to a new one. Amazon was able to remarkably do so with AWS. It opened a truly new business line. In learning the true history of its product launches and business growth, we walk away with ten timeless product growth lessons.
