Ask when Amazon Web Services began and you get three defensible answers. Amazon's press archive has a release dated 16 July 2002 announcing "Amazon.com Web Services", an API platform for putting product data on other people's sites (Amazon, 2002). Amazon's own history page says the infrastructure business began with S3 in spring 2006 (AWS, Our Origins). And Simple Queue Service slipped out in beta in late 2004, two years before either.
The disagreement is not sloppiness. It reflects a company that did not set out to found a cloud business, and then had to work out afterwards which of its internal decisions counted as the founding one.
The problem came first
In the early 2000s, Amazon's retail systems were straining. Andy Jassy, then Jeff Bezos's chief of staff, later recalled that the effort to let outside retailers build on Amazon's e-commerce engine, Merchant.com, exposed how tangled the internal systems had become. Amazon responded by pulling capabilities apart and putting APIs in front of them; Jassy's account has Amazon becoming, "very quietly around 2000", a services company (TechCrunch, 2016). AWS's own retrospectives describe the same pain from the other side: provisioning infrastructure was slow and expensive, and engineers kept rebuilding databases, compute and storage components for their own projects (AWS, Our Origins).
This matters because it inverts the usual startup story. Amazon did not identify a market and build a capability to serve it. It built the capability under retail pressure, for itself, and only later noticed that the capability was the product.
The mandate that may not exist
Every retelling eventually reaches "Bezos's API mandate": an edict, circa 2002, requiring every team to expose data and functionality through service interfaces, communicate only through those interfaces, and design every interface as if it would one day be exposed to outsiders. The most influential version comes from former Amazon engineer Steve Yegge, who described it in a colourful published recollection after a rant about Google's internal platform went accidentally public (Yegge's recollection).
Treat it carefully. Yegge's account is a former employee's memory, not a leaked memo, and no primary document of the mandate surfaced in my sources. Jassy's separate account independently supports the broader shift towards decoupled, API-accessible services around 2000. The architectural change appears real. The dramatic decree is folklore until someone produces the text.
The paper that ended almost as an afterthought
The most direct evidence for AWS's technical origin is a short internal paper written in 2003 by Benjamin Black and his manager Chris Pinkham. Its subject was unglamorous: standardise and automate Amazon's infrastructure using web services, so that storage and computation could be provisioned the same way everywhere. Only near the end did the authors raise the possibility of selling virtual servers to outsiders. Black later wrote that Bezos liked much of the proposal, and that a more detailed virtual-server write-up followed in early 2004 (Benjamin Black, "EC2 Origins", 2009).
Black's account also contains the detail that most history lessons skip: Pinkham returned to South Africa with a lead developer and built the EC2 team there. The first compute cloud was largely assembled in Cape Town.
Jassy's telling runs on a parallel track, placing a decisive strategic discussion at a 2003 executive retreat (TechCrunch). The two accounts do not contradict each other so much as show the same idea arriving through engineering standardisation and through management capacity-planning at roughly the same time.
Three launches, not one
Announcements, betas and general availability blur in most retellings. Keeping them apart gives a cleaner sequence:
| Date | Event | Source |
|---|---|---|
| 16 Jul 2002 | "Amazon.com Web Services" developer APIs | Amazon release |
| Nov 2004 | SQS beta | AWS SQS history |
| 14 Mar 2006 | S3 launches | AWS retrospective |
| 13 Jul 2006 | SQS production launch | AWS launch post |
| 25 Aug 2006 | EC2 limited beta | AWS launch post |
| 13 Dec 2007 | SimpleDB limited-beta announcement | AWS What's New |
| Oct 2008 | EC2 exits beta | Amazon release |
Note what is absent: a keynote declaring a new era. S3 and EC2 launched as blog posts priced by the gigabyte and the hour.
The first customers were buying relief, not innovation
The earliest adopters did not talk about clouds. They talked about servers they no longer had to buy. When SmugMug moved its images to S3, CEO Don MacAskill framed it as a hardware purchase versus a utility bill: instead of roughly $25,000 upfront for a few terabytes of redundant storage, he paid $0.15 per GB-month as he consumed it. AWS quoted him in August 2006, when SmugMug was storing about 500 million images, some 300 TB (AWS, 2006). MacAskill then published his own arithmetic: about $339,430.75 saved over seven months in November 2006, updated to nearly $1 million over twelve months in April 2007 (SmugMug blog). These are customer calculations, not audited statements, and he says SmugMug began using S3 around 14 April 2006, before the public launch.
Another early user, transcription service CastingWords, migrated to S3 after a server failure. Nathan McFarland's summary was blunt: "The costs of storage and bandwidth just vanished overnight" (About Amazon retrospective). UC Berkeley's Stardust@home, a project searching interplanetary dust images for comet particles, appeared in the original S3 launch announcement for the same reason: bursty science workloads are what per-gigabyte pricing was invented for.
The pricing argument
AWS has always justified its price cuts with one rationale: scale. By its own counts it cut prices 42 times between 2008 and March 2014 (AWS, 2014), 59 times since 2006 by 2017, and 107 times by April 2021 (AWS, 2021). The 2017 post states the mechanism plainly: "our economies of scale allow us to pass on the savings to our customers."
Be careful with the version you have heard. The often-quoted formulation about always passing savings back to customers is widely attributed to Bezos personally; the sources here support it as AWS's stated policy, not as a verified quotation. The engineering point survives either way: once you run capacity for millions of customers instead of one, idle machines become someone else's option, and unit costs fall.
The rabbit hole called Dynamo
Somewhere in most AWS histories, a database called Dynamo turns up, and readers reasonably assume it is the ancestor of DynamoDB. It is more interesting than that. Amazon's 2007 paper, Dynamo: Amazon's Highly Available Key-Value Store, describes an internal store built for the parts of the retail site that could tolerate weak consistency but not downtime, such as shopping baskets and sessions (Amazon Science). AWS's own later retrospective says the work grew out of database difficulties during the 2004 holiday season, and that SimpleDB, launched in 2007, traded Dynamo's scale for operational simplicity (AWS).
So Dynamo is evidence that Amazon's engineers had already lived through the hard distributed-systems problems their customers were about to meet. It is not evidence that EC2 ran on it. The shared name is a marketing inheritance, not a lineage of code.
Nobody else was selling this
For roughly two years, AWS had the field largely to itself. Microsoft announced Windows Azure on 27 October 2008 with a limited community preview, reaching general availability on 1 February 2010 (Microsoft). Google Compute Engine arrived in limited preview on 28 June 2012 and went generally available on 2 December 2013 (Google Cloud blog).
That window is where AWS's lead was built: not in any single service, but in several years of production feedback from customers who were paying by the hour and complaining loudly whenever the units were wrong.
What the origin story is actually about
Strip away the folklore and the founding of AWS looks less like a eureka moment and more like an accretion: an architecture change around 2000, an infrastructure paper in 2003, a virtual-server design in 2004, a queue service in beta that year, storage in March 2006, compute that August. Each step was defensible on its own terms, and none required anyone to predict that renting computation would become a hundred-billion-dollar business.
The interesting lesson for anyone building internal platform tooling is that the recognisable product was already sitting inside Amazon, doing undifferentiated heavy lifting in the data centre. The invention was not the virtual machine or the gigabyte-month. It was the decision to point the pricing page at infrastructure the company had already been forced to build well. The folklore persists because a story about a founder's mandate is more satisfying than a story about two engineers trying to stop everyone rebuilding the same storage layer. But when the sources disagree about the founding date, that disagreement is the finding: the company had to decide which of its internal decisions had been the product all along.
A couple of directions I could take this next, if useful: I can turn this into a follow-up piece digging into the Dynamo paper's actual mechanisms (quorum replicas, consistent hashing, hinted handoff) as the engineering companion to this history, or run the SEO/discoverability pass to produce the title, meta description and metadata for publishing this on maurya.ie.
How AWS started: a memo, some folklore, and three different launch dates
Ask when Amazon Web Services began and you get three defensible answers. Amazon's press archive has a release dated 16 July 2002 announcing "Amazon.com Web Services", an API platform for putting product data on other people's sites (Amazon, 2002). Amazon's own history page says the infrastructure business began with S3 in spring 2006 (AWS, Our Origins). And Simple Queue Service slipped out in beta in late 2004, two years before either.
The disagreement is not sloppiness. It reflects a company that did not set out to found a cloud business, and then had to work out afterwards which of its internal decisions counted as the founding one.
The problem came first
In the early 2000s, Amazon's retail systems were straining. Andy Jassy, then Jeff Bezos's chief of staff, later recalled that the effort to let outside retailers build on Amazon's e-commerce engine, Merchant.com, exposed how tangled the internal systems had become. Amazon responded by pulling capabilities apart and putting APIs in front of them; Jassy's account has Amazon becoming, "very quietly around 2000", a services company (TechCrunch, 2016). AWS's own retrospectives describe the same pain from the other side: provisioning infrastructure was slow and expensive, and engineers kept rebuilding databases, compute and storage components for their own projects (AWS, Our Origins).
This matters because it inverts the usual startup story. Amazon did not identify a market and build a capability to serve it. It built the capability under retail pressure, for itself, and only later noticed that the capability was the product.
The mandate that may not exist
Every retelling eventually reaches "Bezos's API mandate": an edict, circa 2002, requiring every team to expose data and functionality through service interfaces, communicate only through those interfaces, and design every interface as if it would one day be exposed to outsiders. The most influential version comes from former Amazon engineer Steve Yegge, who described it in a colourful published recollection after a rant about Google's internal platform went accidentally public (Yegge's recollection).
Treat it carefully. Yegge's account is a former employee's memory, not a leaked memo, and no primary document of the mandate surfaced in my sources. Jassy's separate account independently supports the broader shift towards decoupled, API-accessible services around 2000. The architectural change appears real. The dramatic decree is folklore until someone produces the text.
The paper that ended almost as an afterthought
The most direct evidence for AWS's technical origin is a short internal paper written in 2003 by Benjamin Black and his manager Chris Pinkham. Its subject was unglamorous: standardise and automate Amazon's infrastructure using web services, so that storage and computation could be provisioned the same way everywhere. Only near the end did the authors raise the possibility of selling virtual servers to outsiders. Black later wrote that Bezos liked much of the proposal, and that a more detailed virtual-server write-up followed in early 2004 (Benjamin Black, "EC2 Origins", 2009).
Black's account also contains the detail that most history lessons skip: Pinkham returned to South Africa with a lead developer and built the EC2 team there. The first compute cloud was largely assembled in Cape Town.
Jassy's telling runs on a parallel track, placing a decisive strategic discussion at a 2003 executive retreat (TechCrunch). The two accounts do not contradict each other so much as show the same idea arriving through engineering standardisation and through management capacity-planning at roughly the same time.
Three launches, not one
Announcements, betas and general availability blur in most retellings. Keeping them apart gives a cleaner sequence:
| Date | Event | Source |
|---|---|---|
| 16 Jul 2002 | "Amazon.com Web Services" developer APIs | Amazon release |
| Nov 2004 | SQS beta | AWS SQS history |
| 14 Mar 2006 | S3 launches | AWS retrospective |
| 13 Jul 2006 | SQS production launch | AWS launch post |
| 25 Aug 2006 | EC2 limited beta | AWS launch post |
| 13 Dec 2007 | SimpleDB limited-beta announcement | AWS What's New |
| Oct 2008 | EC2 exits beta | Amazon release |
Note what is absent: a keynote declaring a new era. S3 and EC2 launched as blog posts priced by the gigabyte and the hour.
The first customers were buying relief, not innovation
The earliest adopters did not talk about clouds. They talked about servers they no longer had to buy. When SmugMug moved its images to S3, CEO Don MacAskill framed it as a hardware purchase versus a utility bill: instead of roughly $25,000 upfront for a few terabytes of redundant storage, he paid $0.15 per GB-month as he consumed it. AWS quoted him in August 2006, when SmugMug was storing about 500 million images, some 300 TB (AWS, 2006). MacAskill then published his own arithmetic: about $339,430.75 saved over seven months in November 2006, updated to nearly $1 million over twelve months in April 2007 (SmugMug blog). These are customer calculations, not audited statements, and he says SmugMug began using S3 around 14 April 2006, before the public launch.
Another early user, transcription service CastingWords, migrated to S3 after a server failure. Nathan McFarland's summary was blunt: "The costs of storage and bandwidth just vanished overnight" (About Amazon retrospective). UC Berkeley's Stardust@home, a project searching interplanetary dust images for comet particles, appeared in the original S3 launch announcement for the same reason: bursty science workloads are what per-gigabyte pricing was invented for.
The pricing argument
AWS has always justified its price cuts with one rationale: scale. By its own counts it cut prices 42 times between 2008 and March 2014 (AWS, 2014), 59 times since 2006 by 2017, and 107 times by April 2021 (AWS, 2021). The 2017 post states the mechanism plainly: "our economies of scale allow us to pass on the savings to our customers."
Be careful with the version you have heard. The often-quoted formulation about always passing savings back to customers is widely attributed to Bezos personally; the sources here support it as AWS's stated policy, not as a verified quotation. The engineering point survives either way: once you run capacity for millions of customers instead of one, idle machines become someone else's option, and unit costs fall.
The rabbit hole called Dynamo
Somewhere in most AWS histories, a database called Dynamo turns up, and readers reasonably assume it is the ancestor of DynamoDB. It is more interesting than that. Amazon's 2007 paper, Dynamo: Amazon's Highly Available Key-Value Store, describes an internal store built for the parts of the retail site that could tolerate weak consistency but not downtime, such as shopping baskets and sessions (Amazon Science). AWS's own later retrospective says the work grew out of database difficulties during the 2004 holiday season, and that SimpleDB, launched in 2007, traded Dynamo's scale for operational simplicity (AWS).
So Dynamo is evidence that Amazon's engineers had already lived through the hard distributed-systems problems their customers were about to meet. It is not evidence that EC2 ran on it. The shared name is a marketing inheritance, not a lineage of code.
Nobody else was selling this
For roughly two years, AWS had the field largely to itself. Microsoft announced Windows Azure on 27 October 2008 with a limited community preview, reaching general availability on 1 February 2010 (Microsoft). Google Compute Engine arrived in limited preview on 28 June 2012 and went generally available on 2 December 2013 (Google Cloud blog).
That window is where AWS's lead was built: not in any single service, but in several years of production feedback from customers who were paying by the hour and complaining loudly whenever the units were wrong.
What the origin story is actually about
Strip away the folklore and the founding of AWS looks less like a eureka moment and more like an accretion: an architecture change around 2000, an infrastructure paper in 2003, a virtual-server design in 2004, a queue service in beta that year, storage in March 2006, compute that August. Each step was defensible on its own terms, and none required anyone to predict that renting computation would become a hundred-billion-dollar business.
The interesting lesson for anyone building internal platform tooling is that the recognisable product was already sitting inside Amazon, doing undifferentiated heavy lifting in the data centre. The invention was not the virtual machine or the gigabyte-month. It was the decision to point the pricing page at infrastructure the company had already been forced to build well. The folklore persists because a story about a founder's mandate is more satisfying than a story about two engineers trying to stop everyone rebuilding the same storage layer. But when the sources disagree about the founding date, that disagreement is the finding: the company had to decide which of its internal decisions had been the product all along.
Enjoyed this? I write about what I'm learning.
DevOps, cloud, Linux, and automation - one honest post at a time. Follow along on my learning journey.