The first AWS Leadership Principle is “Customer obsession”, and a lot of what they build is a direct result of demand of their customers. This manifests itself in a plethora of ways to leave feedback  on an AWS product.

It isn’t always easy to choose the right path to get your feedback heard and/or to get feedback about your request. In this post we will take a look at different ways of contacting AWS, and a standard way to phrase your request.

Why you should open feature requests

To build with customer obsession, AWS should know what their customers are asking and how many of them are asking for the same thing. That’s the reason that it’s good idea to submit a feature request even if you know that other people may have asked for the same thing. By opening a feature request you make it easier for AWS to tie the request to a customer and obsess over it.

The goal of feature requests

Before contacting AWS it’s a good idea to think about what you want to achieve with your request. Most of the time you submit a feature request, because you identified a gap in the services that AWS offers. This can be a completely new service, or an improvement to an existing service. In a lot of cases you will have to decide if and how you’re going to fill that gap right now, and what you will do if AWS releases the feature you requested.

In almost all cases the important question is not “When will X be available?”, but “Should I build X myself?” and “How should I build X?”. Sometimes it makes sense to start building immediately, even if the requested feature will be released next week. In some cases knowing what’s coming, and waiting for it, may even be a downside. Take for example EFS, which had more than a year between announcement and release. In that case it might have made sense to run your own fileserver instead of waiting because something might be released in the future.

Submitting a feature request

The following flowchart gives a high level overview of how to submit a feature request with the previously stated goal in mind. It will not always be the most direct path to the service team, but it will help you formulate the right answers to the questions “Should I build” and “How should I build”.

The order of this diagram is based on what we’ve seen and heard in practice. If you think there are errors  or steps missing. Please let us know.

Using the “Feedback” button

The “Feedback” button is probably the easiest way to submit feedback to AWS. The low bar puts it at the front of our flow, but because the ways AWS can communicate things back to you are very limited, we don’t use it for non-trivial requests.

Working with a partner

While a partner can’t give you any non-public information, they can help you navigate the different roles that exists within AWS (they should already know the diagram above), give recommendations on possible workarounds, and engage their contacts within AWS. If you’re already working with a partner, it pays off to keep them in the loop, as they will have technical knowledge of both your workload and the AWS ecosystem.

Leveraging your account team

Depending on your relationship with AWS and the support level you have on your accounts, you might have access to a Technical Account Manager, Solutions Architect or Account Manager. They are well placed to discuss your architecture and your specific needs.

Using AWS Support

If you pay for AWS support (even developer support), you can open feature requests from the support console. They will have less knowledge about your particular workload than the account team, but will let you know when they forwarded your request, and will probably know a workaround if other people ran into the same issue before.

Tweeting with #awswishlist

If you search twitter you will notice that @AWSSupport regularly reacts to the #awswishlist hashtag. While this isn’t an official channel, it looks like AWS is aware of people using this, and sending the feedback along internally.

Looking on GitHub

AWS has a lot of open source projects. If your feature requests is directly related to them, opening an issue on GitHub is a good way to discuss your use case directly with the team.

The container team also has its roadmap on GitHub, so you can engage that team there too.

Asking in Slack

A few of the AWS service teams are running a developers slack as a beta test. The url is https://awsdevelopers.slack.com. Since it’s in beta, there is no official page the sign up but you can try to use this invitation url. Searching for the domain in your favourite search engine or talking to a Developer Advocate will usually give you a person to contact to request an invite if that stops working. The Slack workspace has a mix of AWS-employees and AWS users in it, so keep that in mind when asking your question.

Using the forums

The AWS forums are monitored by AWS, and access to them is part of the “basic” (free) support plan. Just like with Slack, the people in the forums are also a mix of employees and users.

Using the community

Our chart doesn’t include any community driven projects, but a lot of value can be found there too. You can post on Reddit, join communities like og-aws (join the Slack workspace here), DevOpsChat (join here, use the #aws channel) and ServerlessForum (join here, use the #vendor_aws channel), ask questions on StackOverflow, go to Meetups organized by User Groups, and probably a whole list of things I’m forgetting to include here.
And if all else fails, you can talk to Corey at Last Week in AWS about the feature and he will needle AWS to death until they provide it

Writing a feature request

Now that we know where to leave our feedback, it’s a good idea to look at what makes a good feature request. When working with AWS, it’s best to include these elements in your request:

• The feature you need
• The gap it fills
• The workload it represents
• What you would do without this feature

Or if you write this in mad-lip style: “We would like to have feature because of current gap so that we can use this on workload instead of workaround or current state”.

The feature you need

This one is self-explanatory. Write a description of what you want the service to do. For example: “Who would like to have a coffee-as-a-service offering, controlled via HTCPCP).

The gap it fills

This is the “why” of your request. Having a clear use case will help both in getting a usable implementation and in working on a workaround. For example: “We want this because currently we have to get up and walk to the coffee machine ourselves”.

The workload it represents

Describing the workload indicates how this feature would enable you to use the cloud more and better, and isn’t necessarily about size. The service teams inside of AWS do work with feedback from all customers, not only from the big ones. For example “We currently have 25 developers who check the coffee pot every 2 hours, and take 15 minutes to do that”.

What you would do without this feature

If you already have an alternative plan in mind, it’s a good idea to mention that too. Not only does it show that there is a real need, it also identifies other places where this feature may be used. For example: “Currently we are planning on attaching an alarm to the coffee pot, so that it will disturb all developers at once when the coffee is ready. This will convert the pull-based model in an event-based one.”

Putting it all together

We know how to write a feature request and who to contact, so we follow the diagram, send our request and rent an alarm until AWS releases ECPS (Elastic Coffee Pot Service). When that becomes available, we can plan our migration and stop using the alarm.

Or we could do exactly the same thing with a real feature request and now you can do that too.