Recently, I was spinning up yet another terribly coded thing for fun because I believe in making my problems everyone else’s problems, and realized something that had been nagging at me for a while: working with AWS is relatively painful.

This may strike you as ridiculous, because most of the time in established companies it’s not particularly burdensome: you push code to a repo, the CI/CD nonsense (which curiously enough is probably some guy named “Jenkins,” who’s worked at most of the same places that I have — yet strangely I’ve never met him in person) fires off, and it winds up in production somehow. But that tooling is exactly my point: without a fair bit of work to set it up, it doesn’t exist, at which point working with AWS is a massive pain in the ass.

Allow me to demonstrate.

Starting from zero, if you want to deploy a simple webapp to AWS, you get to create an account, spin up the AWS SSO app (intuitively renamed “IAM Identity Center,” and which also requires starting an AWS organization), affiliate a permission set (whatever the hell that is) with an IAM role, log into the SSO panel (which lives at such a hard-to-remember URL that I’ve built an automatic redirector: for my “shitposting” AWS account I can visit “shitposting.badUX.cloud” and it will direct me to the proper location; you can do this with any subdomain at that domain you’d like for the same behavior), select that role (often from a lengthly list), get dropped into an AWS account, then hook it up to your local development environment via AWS SSO command line tool or preferably granted.dev, an open source project that enables the Customer Obsession that AWS has studiously ignored in this area.

You then either have to do something monstrous with key storage, or set up an OIDC relationship between GitHub (yes, or GitLab, I hear you, please do not email me) and AWS, then prod GitHub Actions if you’re sane (or AWS CodeBuild if you’re not) into doing the deploy for you. Then you get to figure out what the hell AWS service you deploy this webapp to, whether you integrate with AWS Amplify, whether you use Amazon CodeCatalyst – oh wait, nevermind, it got deprecated recently – and so on.

Then you get to configure the best part of this: IAM.

You carefully read the documentation, which was originally written by a monk in isolation while being slowly crushed to death by a wine barrel, and allow your resources just the permissions they need to talk to one another — which of course doesn’t work. You broaden it again, and it still doesn’t work. Then you say “oh screw this,” grant it permissions to do anything, put a “TODO” in the comments reminding yourself to fix it, and move on with your life. That TODO will remain there until the last copy of your code is lost in the Great Holographic Library Fire of 2351.

Meanwhile, Google gets this very right. By default, every project in GCP can talk to everything else in its project. Some security troglodytes tell you that “this isn’t enterprise,” and they’re correct, which is why sophisticated organizations can disable this behavior and explicitly declare permissions for everything, invariably by hiring a team of those same troglodytes, but the rest of us deeply appreciate not having a security model that’s the equivalent of forcing us to drown a struggling German Shepherd in the bathtub every time we want to build something.

So, back to building our code.

Next, we get to tag in S3, CloudFront, Route 53, EC2/Fargate/Lambda+API Gateway, RDS/DynamoDB/something else databaselike, and unless you’re insane, billing alarms. All of these are different sections of the AWS console, and don’t work together out of the box particularly well.

And then you push your code and realize that, on balance, baby seals get more hits than your website does because nobody cares about the things we build anymore.

Now, let’s contrast this with deploying a simple webapp on, say, Vercel? It takes less time to sign up and start serving traffic than it took me to convince my editor to whack “publish” on this article. The same is true of Netlify, Render, and a host of other modern developer-centric cloud offerings that will no doubt crop up in self-promotional comments within minutes of this article publishing.

• Amazon brain drain finally sent AWS down the spout
• OpenAI spreads the imaginary wealth beyond Microsoft with $38B AWS deal
• Amazon juggernaut continues hauling in more cash despite recent bad news
• Amazon axes 14,000 desk jobs in AI-powered slimming plan

This is a choice

Easy deployment isn’t some technical impossibility for AWS to achieve; Vercel is built atop AWS. The difference between the Vercel user experience and the AWS user experience is purely one of the will to have a good experience at the highest levels of the company.

This feels generational to me. For folks of a certain age (Gen X and Millenials), AWS and GCP have made their bones. We came of technical age with the platforms and we’re used to their foibles. Azure is of course the Boomer Cloud, but Gen Z is using platforms that aren’t designed as tests of skill to let customers prove how much they want something.

The thing is, increasingly we’re deploying things to platforms not based on their merits, but rather based upon what the LLM selects. Recently I was building a demo for an upcoming re:Invent talk via cyberbullying a robot into doing it for me, and it actively tried to talk me out of using AWS, citing its complexity. I eventually won the argument, but here’s the thing: that AI is going to train the next generation of developers. And those developers aren’t going to have the patience, institutional knowledge, or masochistic dedication required to navigate AWS’s deliberately Byzantine experience. They’re going to build on platforms that don’t make them prove their worth through suffering.

AWS spent two decades building the most powerful cloud platform in the world. They may spend the next two watching it become irrelevant to anyone who wasn’t already bought in. ®