AWS can be traced back to 2004, with the official launch of Amazon S3 in 2006. Since then, an entire generation of developers has arisen, and the world has changed.
There are a few common myths about AWS that folks oftentimes accept as true. Today, I’d like to take a bit of time to correct the record.
Given AWS’s extreme distaste for turning services off post-launch, perhaps our grandchildren will one day find this post useful.
Before I dive in, I want to point out that I’m in no way an expert on AWS’s origin story; it was before my time. To gain clarity, I chatted with AWS VP and Chief Evangelist Jeff Barr and AWS VP of Global Marketing Ariel Kelman to get to the bottom of some of these.
All mistakes are mine; all glory is theirs.
1. The first re:Invent
I once joked that re:Invent was the first cloud conference ever named after an email subject line. As it turns out, this joke hit slightly closer to home than you might think!
In 2012, the conference name included a space: “re: Invent.”
Here’s the thing: On occasion, some email clients (Outlook, I’m talking to you) would either disregard the first word or duplicate it. So, depending on what your inbox looked like, you might have called the conference “Invent” or “re: re: re: re: Invent.”
Core to AWS’s vision for the re:Invent conference was a theme of iteration—and of ensuring that this theme made it into the conference name. Well played.
2. EC2 arose from Amazon.com’s excess capacity
A common and evocative myth is that Amazon.com bought a lot of hardware to handle the holiday rush one year, and when traffic returned to normal, the hardware sat idle for the next 12 months.
This is false.
That said, Amazon.com’s retail business absolutely informed the creation of EC2. Running an e-commerce company, after all, inherently exposes you to the ebb and flow of bursty internet traffic patterns.
Everyone used to dream about how great it would be if we could just pay for capacity when we needed it. But, of course, there was no viable way to do that back then.
EC2 was launched as its own distinct project, and there are multiple examples of early Amazon employees going on record with this. Still, this myth refuses to go away.
3. EC2 was AWS’s first service
Contrary to what you might think, AWS didn’t start by offering virtual machines for rent by the hour.
No, the particular distinction of “first service launched” goes to Simple Queuing Service, or SQS. (There are arguments against this. Mechanical Turk was first, but its status as an AWS service is fuzzy. And S3 was the first service to general availability.)
At the time, the tech press widely considered this to be rather bizarre. Why does an online bookstore need a message queueing service anyway?
It turns out that message queues are foundational services; it’s very hard to build anything of significant scale without something that can fulfill that role.
But this wasn’t as widely accepted or understood 15 years ago.
It’s hard to come up with a better example of Amazon’s “willingness to be misunderstood for long periods of time.”
4. Amazon vs. AWS for service names
A somewhat pervasive myth that I’ve had no small part in spreading is that when a service is named, a coin is flipped to determine whether it gets prepended with “Amazon” or “AWS.”
In truth the answer is much simpler. If a service can be used relatively independently (e.g., Sumerian, S3, and Connect) it generally receives the Amazon appellation. If you need to be relatively deep into the AWS weeds to use a service (e.g., KMS, Systems Manager, and Fargate), its name starts with AWS.
This is, of course, a subjective measure. And, to be fair, a strong argument could be made in favor of making the decision the other way for a number of services (e.g., MSK, Database Migration Service, and Ground Station).
But it was refreshing to hear from the horse’s mouth, as they say, that this was the intended naming convention.
5. Deprecating services, name reuse
A common sub-myth here is that SimpleDB was at one point removed from the AWS Console, when in fact it was never there in the first place.
The service still exists, still has paying customers—and even still launches in new regions when required. Amazon believes (at times annoyingly so!) that “APIs are forever.” Once a service is launched to general availability, it almost never experiences breaking changes.
That said, there are exceptions. The original version of AppStream 2.0 didn’t have a number in it. And there is still an Amazon subsidiary named Alexa that can be found at alexa.com. It just doesn’t do what you probably think it does.
Here’s something to remember: From a philosophical point of view, AWS fundamentally considers an API to be a promise. Services that aren’t promoted anymore (e.g., SimpleDB, S3’s Reduced Redundancy Storage tier, and EC2 Classic) are still available, though some may require specific enabling in your account.
Think about that for a second.
A service launched 13 years ago is still actively supported to the point where you can use it today.
In a world where customers ask themselves whether they can trust a particular service enough to build their businesses on top of it, that’s quite a meaningful track record.
Amazon has built up a lot of trust over the years. When the company announces a service has become generally available, I don’t hesitate to recommend it for possible production use. Few vendors carry that gravitas.
If I left out any Amazonian myths you’ve been wondering about recently, you need to tell me. Drop me a line, say hello, and we’ll get to the bottom of them together.
