AWS employee here. When I was an AWS customer I was also often surprised by the quality of the support answers. Now from the other side I can explain why: even on the cheaper support plans it isn't uncommon for difficult questions to make their way back to the relevant team and the answer you are getting was often written by an engineering manager or engineer on the team that built and operates the thing you were asking about.
Obviously there is a balancing act here to avoid slamming the engineers with too much load answering support questions, but it is not uncommon for customers to be getting answers from the people who built the thing. And on my team at least we always try to use support questions to know where we need to improve documentation with more troubleshooting steps, etc.
> And on my team at least we always try to use support questions to know where we need to improve documentation with more troubleshooting steps, etc.
Absolutely. In my ex-team at AWS, you could literally see visceral pain on the on-call's face when a customer tickets-in with a totally avoidable issue. The feedback from such customer contacts did inform most of the product roadmap.
And most certainly, the most heavily prioritized and celebrated feature launches were the ones improving operation excellence including fixing things that a lot of customers had complained about.
That said, cloud support engineers, often times, in my experience, were more knowledgeable than software engineers owing to their interactions with customers which lead them to internalise a tonne of troubleshooting patterns. Only a novel issue would stump them where a software engineer would have to work in-tandem to sort it out.
The detailed internal knowledge-base that these support/software engineers write for issues impacting customers probably also plays an important role, because then even semi-technical folks like TAMs can more or less help the customer out pronto by searching through the knowledge-base, without requiring to escalate further.
Agreed. AWS technical support is exactly that. It's been a pleasure every time, that when I open a ticket, I actually have a real technically minded human behind it.
As a converse, I've also had the extreme displeasure in dealing with Oracle and Tenable/Nessus support...
With Oracle, its either a continual feature-push to go to professional for only starting $50k/yr more (NO), or troubleshooting ends up asking 100 questions for your question.. And if you answer them, they give you 100 more. Effectively its a technical DOS in the hopes you abandon the ticket.
Nessus/Tenable is similar. They want you to use their terrible tenable.io (which isn't fedramped), and will badger you incessantly. And service tickets demand enhanced logs be turned on and provided to them. Their tool can censor some passwords, but have caught passwords in there along with services, addresses, and exploit data about them. And even if you censor the logs prior to shipping to them, they will put their foot down and demand unedited logs.
This would explain the response I got (backstory - I am a contributor to a number of open source packages / not totally clueless, but was coming in from a micro personal account). I was like, how the heck do they afford this response for $99! (or whatever it cost back then - this was a long time ago).
I kept my support plan active for a year as a courtesy though I never had another question aside from the first two I put in.
That said, as a programmer I like time to focus so being asked customer questions would drive me nuts, hopefully they filter out the idiots who just can't setup things right (80% of issues are not bugs but customer setup issues).
For most services, this is how the AWS escalation path works:
1.) Support engineer receives the case. In most cases, for most services, the run-of-the-mill support engineer has gotten enough training on the service that they'd considered a SME at any AWS partner/enterprise.
2.) If front-line support engineer can't solve the case, they talk to their more tenured friends.
3.) If they still can't solve the case, they escalate to Premium Support SMEs in the service. These are support engineers that have proven they have solved complex enterprise-level cases and get specialized training from the service teams on the internals of the service.
4.) If the SME can't figure it out, it's escalated to the service team (i.e. the actual software engineers that write the code).
Steps 1-3 deflect a lot of the annoying, unnecessary escalations. But sometimes escalation to the teams is unavoidable. For example, some service limits are hardcoded into the service and updates require a code push. Or (somewhat rarely) there's a service bug.
That being said, Premium Support engineer have access to the backend service code for most everything. While not every PS engineer knows how to code, on more than one occasion, I've dug through a code repo to figure out why something was behaving oddly.
Obviously there is a balancing act here to avoid slamming the engineers with too much load answering support questions, but it is not uncommon for customers to be getting answers from the people who built the thing. And on my team at least we always try to use support questions to know where we need to improve documentation with more troubleshooting steps, etc.