(For context, unless you pay 20% extra for AWS support, you basically get no support. There is a public forum for those that like to scream into the void.)
I always liked Amazon's approach to this. In extremis, like if a whole region is down or something, they'll eventually change the green indicator to green with information mark.
> Given that they shut down suddenly and you could not reach a human, it sounds more like Google Cloud ;)
On Google Cloud for over four years, with three kubernetes clusters and a few dozen VMs across three projects... and this thing you describe has never happened. Have you had a different experience with them?
Your numbers are wrong, you can get 'developer support' for $29/mo or 3% of AWS cost (whichever is higher), and 'business support' at $100/mo or 10% of AWS cost. In my experience, the support reps are qualified engineers that take your issues seriously, and it's something that we gladly pay for (particularly since it's opt-in, and you can change your mind at any time).
AWS without paying extra for support can still be fine for a lot of people. Where I work we use AWS, but not many AWS services other than basic virtual machines.
As far as what we run on the machines goes (OS, applications) we are fine dealing with that ourselves. It's what we did back when our machines were machines we owned at a colocation facility, and its not much different when its on a VM at Amazon.
When something goes wrong that affects us and requires AWS intervention, 99.9% of the time it is something that is going wrong for many other people too, some of those will have paid support and bring it to Amazon's attention if it isn't something Amazon notices on their own, and when Amazon fixes it that fix will fix it for all of us.
I can only recall one time it didn't work that way. I was trying to track down a problem with our applications that involved something whose processing involved steps on three different systems. I needed to rely on the logs from those three systems to figure out the order things had happened in, and it was making no sense. I checked the clocks, and found that the three systems had wildly different notions of time.
It turned out that the clocks on some of our instances were ticking at the wrong rate. They were ticking at steady rates, and normally the time code in Linux systems can figure out how far off the rate is and apply a correction, but some of the AWS instances had rates that were something like an order of magnitude more than the Linux code can deal with.
We found some other people talking about this in the forums, but it apparently wasn't hitting anyone with paid support. Someone finally bought some paid support and reported it, and it got fixed. (It turned out that it had only affected one fairly small instance type, and only an older version of it that you were supposed to migrate away from over the next few months, which made it so that only a very small fraction of VMs were affected).
I trust AWS over others primarily because of support. Over last three years we must have opened about a dozen support tickets, 100% of them were resolved to satisfaction.
First line can be terrible, and I've had situations where I have tickets stuck in first line because someone in a timezone 12 hours different picked it up.
They then are resolved several times without an actual resolution. The last time it happened I only found out in the end it was fixed was because I managed to speak to a member of the technical team for a different reason and enquired.
It was the API Gateway dropping headers that contained underscores that happened for about 6 months last year if it impacted anyone else.
In relative terms though, they are far and away better than the alternatives. At least I can get to speak to people quite easily, and I was able to even speak to folks on the team working on API Gateway and they even got my ticket.
The joys of inheriting codebases is that you learn all sorts of edge cases.
Apache used to silently drop http headers with underscores in them because they state incorrectly that it is against spec, which Nginx then decided to copy in the name of "security" although it was just a flag so could be ignored if you aren't doing CGI scripting.
AWS silently added this to load balancers in 2019 until there was a backlash and they restored functionality, and then tried again to add this to API Gateways in early 2020 until, again, people complained.
HA Proxy doesn't, never did and likely never will because underscores are valid.
I don't pay anything for support at AWS, and I had <24h response every time I needed them, despite having a ridiculously low monthly invoice.
That is in stark contrast to other providers to which I give a lot more money, and who can't be bothered to answer in a week... And when they do ally do answer, it takes another full week to do finally have a solution.
You need to buy support on a per-account basis and if you're doing something complex enough with AWS you'll end up with multiple accounts for each environment and for security segmentation etc.
They'll give you general information from your account with the support plan but can't investigate any resources or logs without you owning a support plan on the other account and opening a ticket there.
Also, many companies will have this set up on each account and hardly use it. I don't think it's a loss leader.
Work in AWS Premium Support. Given the sheer volume of accounts with support plans, I'm confident it doesn't lose money in aggregate. Premium Support isn't where you'll find AWS's giant money printer, but it's not losing money.
That being said, I've definitely had cases where the engineering time to solve a case was worth more than that specific account was paying for support (at least for that month).
Well, yeah exactly. This whole business is set up so you don't pay for support if you don't want to. And AWS is set up the same way, they just also let you pay for support.