Deploying to Amazon's Cloud Is a Pain in the AWS Younger Devs Won't Tolerate

Posted2 months agoActive2 months ago

raw_anon_1111

18 points

11 comments

theregister.comTechstory

calmmixed

Debate

40/100

AWSCloud DeploymentInfrastructure-as-Code

Key topics

AWS

Cloud Deployment

Infrastructure-as-Code

The article discusses the challenges younger developers face when deploying to Amazon's cloud, with commenters offering varying perspectives on whether AWS is overly complex or simply powerful.

Snapshot generated from the HN discussion

Discussion Activity

Light discussion

First comment

53m

Peak period

0-2h

Avg / period

2.2

Comment distribution11 data points

Loading chart...

Based on 11 loaded comments

Key moments

01Story posted
Nov 5, 2025 at 6:52 AM EST
2 months ago
Step 01
02First comment
Nov 5, 2025 at 7:45 AM EST
53m after posting
Step 02
03Peak activity
5 comments in 0-2h
Hottest window of the conversation
Step 03
04Latest activity
Nov 6, 2025 at 2:30 PM EST
2 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (11 comments)

Showing 11 comments

deweller

2 months ago

1 reply

AWS Amplify was supposed to solve this. It is built on the AWS CDK. But I found it too clunky and slow and gave up on it.

These days I use SST (https://sst.dev) which is built on top of Pulumi. I find this to be a manageable infrastructure-as-code solution for AWS deployments.

raw_anon_1111Author

2 months ago

AWS Amplify does far too many abstractions and it keeps you on the rails. It’s like AWS Beanstalk

basfo

2 months ago

1 reply

AWS is built for production. It’s complex because it’s designed to create robust environments that can scale almost infinitely, that’s why half of the internet runs on AWS. But to make the most of it, you need to understand how it works and why it’s built that way. That’s why being an “AWS expert” is practically a job description on its own, thats why cloud engineering teams exists, platforms, SRE, etc.

For quick and dirty app deployments, though, other vendors like Heroku probably do a better job.

zamadatix

2 months ago

1 reply

I think the larger reason being an "AWS expert" is a job description is lock in. If you've hired people who have spent years grokking the AWS names, terminology, and options then your likelihood of switching to anything else is much lower.

Not that AWS doesn't also enable scaling or something, it just (conveniently) doesn't give an option to deploy anything but scalable services you'll train your staff on. A lot of the time AWS interfaces/offerings are copied not because they were ideal, but because it's an easier way to break past that barrier with your offering.

JustExAWS

2 months ago

1 reply

And that’s true if you base your tech stack on VMWare, colo’s, GCP, Azure, etc.

No one can be an expert on everything. Even if you base your expertise on Kubernetes, someone still needs to know the underlying cloud infrastructure. Kubernetes is just an abstraction that maps to underlying infrastructure.

zamadatix

2 months ago

1 reply

It's true in that any technology is going to require some jargon and understanding, it isn't true in that this does not imply each offering seeks to minimize that instead of maximize that. AWS is far from the only one, but they are definitely one of the worst in the latter regard.

JustExAWS

2 months ago

1 reply

You can’t both have versatility and simplicity and the entire leaky abstractions thing. Give me AWS with a bunch of primitives for anything that is moderately complicated over something like Vercel, AWS Amplify. Elastic Beanstalk etc.

This isn’t rah rah AWS, it’s just the one I know from an architectural level - I was pure developer before I got into AWS seven years ago and before then I hadn’t had to manage architecture since 2003. I would say the same that I prefer the raw primitives of GCP, Azure, or on prem Kubernetes more than the equivalent leaky “easy to use” alternative.

zamadatix

2 months ago

It's not about whether abstractions exist, it's about whether the jargon for them requires remembering long lists of services from index cards so you equate "AWS Fargate" with "AWS Serverless Containers" and having the certification training teach you to say the whole stack that way so nobody but AWS certified people know what the hell you've proposed or built is.

I've built plenty of things with AWS and a lot of the technology is quite good, but it's not about that.

tajd

2 months ago

1 reply

Life is easy when you don't want to think about scale or security. Until you have to, that is.

Spivak

2 months ago

Yeah the author is broadly talking about the difference between IaaS vs PaaS where in the latter the vendor is also your DevOps team. The cost being a more opinionated setup you have less control over.

A trade worth making oftentimes but it doesn't make the complexity go away.

jqpabc123

2 months ago

AWS doesn't want to avoid details, they want to wallow in them.

Technology advances by increasing the number of things a person can achieve without thinking about them. AWS has lots of room for advancement.

View full discussion on Hacker News

ID: 45821860Type: storyLast synced: 11/20/2025, 1:30:03 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN