I’ve long been known to complain about how many services AWS has (at last check, north of 200). Because it amuses me, I even play a game with AWS employees, asking them to pick the fake service out of a given five services.

Combined with AWS’s legendary refusal to deprecate anything a customer is depending upon— and their historical penchant for the acceleration of releases over time—it’s a natural conclusion to predict a future in which there are thousands of AWS services.

While some people have interpreted this observation as “AWS should slow down/stop releasing services,” that’s never been the position I’ve held. To the extent I’ve been misunderstood as holding such a silly idea, it’s my fault for not being clearer in what I believe the real problem is.

In fact, it’s fairly apparent that AWS leadership dreams of a future in which every problem a technology worker has can be addressed by using one of their oh-so-very-many services. There’s nothing wrong with that perspective (barring antitrust concerns), but it hides the larger problem that exists today.

It’s the marketing, stupid

The problem isn’t AWS’s service variety, the number of them, or how quickly they’re releasing new ones. Rather, it’s within how those services are marketed to customers.

Many of AWS’s customers have the haunting fear that there already is an AWS service that does the thing that they need done. But due to the sheer volume of services, there’s no way to find that service.

The services listing on AWS’s site reads like a practical joke.

Inside the AWS Management Console is even worse, with the listing of services seemingly arbitrary and more than a little capricious.

For example, one column is topped by Braket, their quantum computing service that basically nobody needs today. Meanwhile, their managed Kubernetes service is at the bottom of the third column.

They’re apparently laid out in some kind of order that aligns with AWS’s internal organizational structure—or perhaps sorted by how much AWS wants to promote growth in certain areas.

This is wrong

As AWS grows their service count beyond any one person’s capacity to reason about them, the alignment needs to change from “listing off a bunch of services by AWS org/area of discipline” to describing the various offerings in the context of the problems customers have and want to solve.

No customer cares about AWS inherently; they care about what AWS allows them to do.

If we look at Twitter, forums, etc., the various questions users ask increasingly align less with “how do I do X with a given service” and more with “what service should I use to solve this problem?” When well-intentioned users ask “what service should I use to host a website,” they’re basically trampled with answers such as S3, LightSail, Elastic Beanstalk, EC2, and Fargate—none of which are wrong!

The trouble is that the user now feels that whatever they select is “wrong” because, otherwise, 75% of the respondents wouldn’t be vehemently disagreeing with their selection. This is a major failure on AWS Marketing’s part, and it stems from a lack of storytelling.

Something’s gotta give

Ultimately, AWS Marketing needs to shift their messaging from “Service With A Dumb Name lets you provision print servers in specific suburbs of Milwaukee” to asking the user what they’re trying to do and then surfacing relevant options.

This is going to be a challenge for two reasons:

  1. AWS Marketing has historically been aligned around promoting specific services to everyone, and
  2. So many services can be applied to so many different kinds of problems.

To the first point, AWS’s Marketing doesn’t really do holistic stories. My impression is that different teams have different marketing functions, whereas central or “Global” marketing, as it’s known inside AWS, is the group responsible for things like buying airport ads and naming stadiums.

Contrast this structure to every customer architecture in existence: They use a wide-ranging selection of AWS services to put together the things they’re demonstrating. This would require an unprecedented collaboration between teams that often have no idea the others exist. AWS’s organizational structure just isn’t set up for this sort of thing.

As to the second, I use Route 53 as a database, CodeDeploy as my “run this container on a scheduled basis,” and Lambda functions for all kinds of different things. Understanding these uses of those services requires a nuanced understanding of exactly what it is that I’m building, and AWS has been very up front about how much they learn about their own offerings from what customers build with them.

To improve their messaging, AWS is going to need a lot more knowledge about customer use cases than is realistic to expect of them.

We’re left with the clear fact that these challenges are the future of AWS’s marketing, with a marketing organization that shows every sign of being unprepared to deliver on that future.

I’m the head of AWS Marketing

I periodically joke that I’m the head of AWS Marketing—but only because it seems no one else is doing the job.

Looking ahead, AWS is going to need people who can demonstrate an extremely unorthodox approach to cloud services storytelling.

Until now, it seems they’ve chosen to instead bias for sending out multiple copies of the same email to existing customers, regardless of who they are and how they’re using AWS.

Something tells me that a customer trying to figure out how to create a website from scratch might have different needs and interests than whoever the heck uses AWS Ground Station, but that’s just me.

The reason that my “I run AWS Marketing” joke works is because nobody who works there is consistently telling any cross-service stories that make sense.