www.theregister.com
How AWS is losing the younger generation with complexity
# Deploying to Amazon's cloud is a pain in the AWS younger devs won't tolerate ## They have no need to prove their bonafides 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. … 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 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. … 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. … 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? ... 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.
Related Pain Points3件
Excessive setup complexity for simple deployments
7Deploying a basic webapp to AWS requires navigating IAM Identity Center, SSO, permission sets, IAM roles, GitHub Actions/CodeBuild integration, OIDC setup, and service selection (Amplify vs CodeCatalyst vs others) before any code runs. Without pre-existing CI/CD infrastructure, the process is prohibitively complex compared to platforms like Vercel.
Poor AWS documentation quality and accessibility
6AWS documentation is difficult to navigate, unclear, and poorly organized. It reads as if written in isolation without practical developer context. The SSO/IAM Identity Center URL is so hard to remember developers build custom redirectors. Documentation doesn't effectively explain relationships between services or provide clear decision trees.
Fragmented console experience across multiple services
5Deploying an app requires managing resources scattered across different AWS console sections (S3, CloudFront, Route 53, EC2/Fargate/Lambda+API Gateway, RDS/DynamoDB, billing alarms). These services don't integrate well out-of-the-box, forcing context switching and manual coordination.