The AWS support page lists four support plans (as of this writing) with corresponding coverage that ranges between “Good luck,” “Developer,” “We’ll answer the phone if you call us,” and “We will take care of you with a vengeance.” The cost for each support plan naturally reflects the promises, with monthly costs that start at “$0,” “$29,” “$100,” and “$15,000” respectively.
Let’s focus on the expensive one: Enterprise Support.
At $180,000 a year, you might think that the enterprise support program is a fantastic waste of money. You would be correct—unless you use the support it buys you properly, at which point it becomes a jewel beyond price.
What Enterprise Support Buys You
The key differentiators of this support level are:
- Access to engineers with the word “senior” at the start of their titles
- A target response time of less than 15 minutes to a business-critical system down incident
- A consultative review and guidance based upon your applications
- Included Infrastructure Event Management (think big launches, Black Friday, etc.)
- Access to a “Well-Architected Review”
- Access to online self-paced labs
- A concierge support team
- A designated Technical Account Manager (TAM)
Note that these are just the additional benefits that are beyond those of the next most expensive tier. For an in depth exploration of everything offered consult the support page directly.
Note also that unlike every other paid support tier, Enterprise Support applies to every linked AWS account. Every other support tier applies per AWS account. Ergo, if you have 500 AWS accounts in your organization, you’d very possibly be facing a monthly support bill for “premium” (but not Enterprise) support that starts at $50,000 a month. In other words, for some organizational configurations, you save money by switching to Enterprise Support.
Common mistakes in working with Enterprise Support
If your company does sign up for enterprise support, it makes sense to make good use of the financial investment. However, I have seen a number of ways that companies engage with Enterprise Support that result in poor outcomes.
DON’T believe that Enterprise Support replaces staff training. You may well find yourself asking AWS Support relatively basic questions. This isn’t a bad thing; that’s what they’re there for. That said, if your primary mode of engagement with Enterprise Support is to ask basic “How do I use this service” questions, your money may be better spent on hiring internal staff who are already up to speed on AWS concepts. Despite their best efforts, AWS cannot take ownership of your applications the way that internal staff can – and should.
DON’T treat the Enterprise Support staff as though they’re the enemy. Because they’re not. I have seen people draw sharp lines between “us” and “them.” These start at the level of communications failures, and continue into the realm of failures of empathy.
Yes, I understand that you want to keep company information proprietary. You’re loathe to explain that the technical problem you’re trying to solve is to sort Twitter for Pets’s dog-tweets by breed at scale. But you have to find an acceptable way to share what you are trying to do, or the professionals are limited in their ability to help you. If you refuse to tell your account team what you’re working on, you cannot reasonably be upset if it turns out that AWS releases a service that solves your exact problem.
AWS builds a great number of services that solve common problems. I constantly marvel at how often I see an architectural problem in one client’s environment that mirrors what’s going on in another client’s environment. If you’re trying to move data from one place to another, or working around a frustrating limitation in AWS’s offering (or your perception of such a limitation), start by talking with your account team. Very often the answer takes the form of, “Wait a few weeks and this will go away.”
DON’T be rude to the Enterprise Support team. f your first response whenever there’s an AWS service incident is to berate your TAM, not only are you wasting your money, but you’re being a jerk. TAMs are customer-facing support personnel. They have no ability to cause service outages (well, not without a tremendous amount of creativity!), fix service outages, or demand customer-specific answers from the engineers who are doing their best to respond to the outage. By yelling at them, you’re becoming the business version of someone who calls Dell to scream at the poor phone support agent about your laptop not working properly. You absolutely have a right to be upset when a service you’re paying for fails; however, it isn’t a productive use of anyone’s time to take out that frustration on the people who are themselves often as much in the dark as you are.
DO treat Enterprise Support as more than a supercharged ticket tracking service. One common pattern is for engineers to treat Enterprise Support as if the support team’s sole job is to track the AWS tickets you opened. While tickets are indeed important (they’re sadly one of the only ways that large organizations communicate internally between various units), this is the smallest piece of what Enterprise Support offers a business. If you view support only in defect-tracking terms, it would be wiser and cheaper for you to hire several entry-level people to fulfill this function.
DO expect expertise. Don’t pay for Enterprise Support so you can sit in planning meetings with AWS, then use that time to imply that their engineers are morons. This is incredibly toxic behavior, unfair to the people you’re speaking down to, and a hilarious misunderstanding of reality. If you do so, you are wasting your money; dead wrong; and I think I used to work at your company.
I’ve found my fair share of AWS annoyances over the past decade. Invariably I eventually spoke with an AWS engineer about the problem who understood the problem far better than I did. The engineer also had an accessible explanation as to why things were the way that they were, and the complexities involved in overcoming it. (Of course, they were actively working to address it.)
DO listen to their advice. You don’t have to follow it. You may find yourself sitting with an AWS architecture team discussing your environment, wherein they make suggestions about what you should do. You may well decide not to implement what they suggest. This is ambiguous. It could be that you’re wasting your money by ignoring their expertise, or it may be that your specific business constraints make a “best practice” inapplicable to your environment. You know your shop better than they do, after all. It’s hard to say without further context whether you’re wasting money in this situation.
Please note that I’m not suggesting you blindly follow AWS’s suggestions without consideration! Ultimately, their advice is advice, not binding rules you must follow; I simply advise that you take it seriously instead of rejecting out-of-hand.
DO take advantage of their knowledge. One key differentiator of AWS Enterprise Support is that it grants you access to a host of architectural review services. By all means, use them! This **lends itself to several positive outcomes. First, it’s a certainty that the expert team with whom you consult has seen many more environments than you. As a result, they see patterns invisible to you, which makes them well positioned to opine upon what works (or doesn’t work) in particular scenarios. They’ve got the kind of experience that most external engineers take a decade to acquire.
As a part of this process, you absolutely should be as transparent about your future plans as you can be. It’s entirely common that you’ll mention a problem that AWS engineers have encountered a lot—and they may know about a new, not-yet-announced service to which you can get beta access! You’ll be a lot happier than if you built your own solution and deployed it a week before the service is publicly announced. I’ve been on the wrong end of that story several times myself; it’s not fun, and you kick yourself for all of the wasted effort you poured into something that suddenly isn’t a problem anymore.
DO understand that you’ll need to reset the relationship periodically. There are a lot of benefits to Enterprise Support, but they only exist if you and your team know they exist. To that end, it’s important to recognize how the relationship changes with AWS ages. You hire new staff; they rotate staff on their end; and suddenly you have a team of developers who’s never been introduced formally to enterprise support. Refresh and renew that relationship regularly, and especially do so whenever there are staffing changes to the team on either side.
In summary, pay for Enterprise Support and use it properly, or save your money.
