Dear AWS,
Your annual AWS re:Invent conference is coming up soon. I’m sure you have 50,000 new services coming out, and are now in the process of naming them all. I’m gonna be blunt: you gotta get better at naming these things — because the current state is a mess.
First off, I know naming is hard. Our CEO tells a good story about how Roomba was almost named “Cybersuck”. But with the ever-increasing constellation of services on AWS, being able to keep a large number of names straight is critical for users — and we can only do that with your help.
This is not a new issue, and I’m not the only one to complain. AWS in Plain English has been around for years to help users better understand the AWS ecosystem, and even includes helpful suggestions for alternative names, many of which are clearly superior.
Here are some tips:
Rule #1: Plain Descriptions
Ideally, a plain description of what it does is the best way to name a service — but think hard about if it will get confusing for people when they are talking about the service. Certificate Manager, Batch, and Direct Connect are all fine.
But, I’m tired of saying that our IoT solution uses IoT. And tired of trying to differentiate between API Gateway the service, and the APIs created inside the service. And tired of asking another customer “Are you using a WAF on AWS or AWS WAF?” And tired of explaining that I just spoke “Recognition” but spelled it with a “k”.
Rule #2: Mashing Terms
If you want to go the “obvious name” route, pick a couple terms and mash them together in a way that creates a unique term that would otherwise never be used. WorkDocs — great. CodeCommit — great. Device Farm — good. This can be better than a plain description for the confusing cases.
Rule #3: Avoid Opaque Terms
At the other end of the spectrum, don’t choose a completely opaque term with no link to its functionality. Nobody who isn’t directly working with them remembers what Fargate or Greengrass or Sumerian does.
Rule #4: Funky Names
If you insist on going all “funky name” for a service, pick a term or two that are linked to the functionality. We can remember the service if there’s some mnemonic aspect to the naming convention.
SageMaker and Polly — great. GuardDuty — decent. Step Functions — not that good. What even is a Step Function? Comprehend — bad. What kind of data does it comprehend?
Rule #5: Mini-Brands
Don’t try to create mini-brands. “Kinesis stream” can mean four different things — and one of them, Kinesis Video Streams, is completely unrelated to the rest.
Some IoT functionality is grouped into “IoT Core” and other into separate services also branded “IoT”. Systems Manager is a branded grab-bag over 100 API methods, including subsections like Systems Manager Session Manager, which by itself breaks rule #1 twice.
Plan the names better for growth of functionality.
Rule #6: Scope of Names
Don’t scope the name too narrowly. IoT Analytics is completely applicable outside IoT — besides also violating rules #1 and #5. Also, the AppSync service provides GraphQL endpoints usable outside web & mobile apps.
Rule #7: Amazon versus AWS
Finally, don’t waste any energy on deciding to call the service “Amazon X” vs. “AWS X”. Literally no one cares — and almost no one even notices you’re making a distinction.
Kind Regards
When looking to use AWS services to create a solution, I want to narrow down my options in a first pass based on name alone. I don’t want to have to read a paragraph for 30 different services just to remember what they do.
We’re all excited about the new services launched during the year, and we’ll be excited by the launches at re:Invent. But we need your help to make sure we can get the most value of them — and that starts with being able to keep them straight in our heads.
As a customer-obsessed company, AWS needs to recognize that for service names the balance has tipped from being about branding and marketing — to being about customer usability.
