The "single neck to wring" doesn't really exist unless you're a Salesforce / Atlassian / ServiceNow sized customer. Below a certain size, good luck getting supp

The "single neck to wring" doesn't really exist unless you're a Salesforce / Atlassian / ServiceNow sized customer. Below a certain size, good luck getting support from AWS beyond "read the docs". The thing is, most of the time your outages are because you screwed up. "Shared responsibility" means that unless AWS actually loses a whole region for the day, or S3 actually loses your data forever, it is still "your fault". Because you didn't balance across AZs, take backups, test backup recovery, understand point-in-time recovery or egress charges etc. As the article says, CTOs don't change cloud providers. I've been on the hook for DR exercises where the same stack is running on the same cloud and they've failed because engineers make crazy number of invisible hard-coded design choices. Once you build your product on AWS, you're pretty much stuck there. K8s offers kinda-of an escape hatch, because it's possible to build your SaaS on EKS in such a way that it could be migrated to AKS or GKE, but it's still a ton of work for the plumbers. So the reason that AWS has this proliferation of ready-made services (and there are tons of them - try sitting an AWS professional certification) is that you'll generally use them in favour of deploying your own FOSS thing (even if it's "just a helm chart away"). Because running a database cluster (for example) is never as simple as just deploying it. Once your engineers decide to use Cognito, Lambda, Kinesis, Aurora instead of doing a DIY, you're locked in. Hell, it would even cost a fortune to simply download the data to close your account (because AWS Snowball doesn't have an egress option where they'll drive a few PB of your data to your data center in a semi-truck)