AWS Too Complex? 5 Reasons Developers Are Leaving — And Practical Advice

When the Most Loyal AWS Users Start Questioning

Last week, a post on Hacker News gathered hundreds of comments in hours: "I returned to AWS and was reminded why I left" — from a developer who'd used AWS for 15 years, back when SQS, S3, and EC2 were still in their infancy.

What makes this notable: it's not an anti-AWS rant from a newcomer. It's a farewell letter from someone who organized the first AWS event in Melbourne, who drank the "Kool-Aid" to the last drop.

And he's not alone. Most HN commenters agreed.

Having managed NodeJS teams running on AWS for years, this analysis breaks down the real reasons behind this wave — and more importantly, what you should do about it.

5 Core Problems with AWS

1. IAM — "Designed by Lucifer on His Burning Throne"

This is the most common complaint. IAM (Identity and Access Management) should be simple — who can do what — but in practice it's a maze of policies, roles, trust relationships, and condition keys.

A real-world example: to let a Lambda function read from an S3 bucket, you need:

• IAM role for the Lambda
• Policy attached to that role
• Bucket policy if using cross-account
• VPC endpoint if the Lambda runs in a VPC
• Security group rules for the endpoint

Just to read a file from S3. Five steps. And when something goes wrong? CloudWatch logs are nearly useless for debugging IAM — you wait minutes just to see the AccessDenied reason.

According to Datadog's 2025 cloud security report, 67% of security incidents on AWS involved misconfigured IAM — not sophisticated hacks, but developers who couldn't understand their own policies.

2. Egress Costs — "9 Cents Per GB? Seriously?"

AWS charges about $0.09/GB for data transfer out (egress). Sounds small? Do the math:

• 1TB/month = $90
• 10TB/month = $900
• 100TB/month = $9,000

And that's just internet egress. AWS also charges for inter-AZ transfers ($0.01-0.02/GB), inter-region ($0.02/GB), even between VPCs in the same region.

Result: every month your AWS bill has charges you can't explain. Especially with microservices — Service A calls Service B calls Service C, and every hop costs money.

3. Lambda Lock-in — Easy In, Hard Out

AWS Lambda is the textbook example of vendor lock-in. Once you've built:

• Event source mappings with SQS, SNS, API Gateway
• Lambda Layers for shared dependencies
• Step Functions orchestration
• Lambda@Edge for CloudFront

...migrating anywhere else means rewriting everything. Not just the code — the entire architecture.

In practice: teams have spent 3 months just refactoring Lambda functions to container-based deployment. The reason? Lambda cold starts were too slow for latency-sensitive endpoints, but extracting them meant rewriting all the event handling.

4. "Ghost" Bills — Hidden Costs Everywhere

AWS billing is a skill that regular developers shouldn't need to learn. But you must, unless you want surprise charges.

Common hidden costs:

• NAT Gateway: $0.045/hour + $0.045/GB processed. One NAT Gateway running 24/7 costs ~$33/month, before data transfer.
• CloudWatch Logs: $0.50/GB ingested. Verbose logging = huge bills.
• S3 requests: PUT, COPY, POST, LIST all incur charges. Each is $0.005, but millions of requests add up.
• EBS snapshots: Accumulate automatically over time. Nobody cleans them up.

DynamoDB is the infamous case — many developers got $75+ bills in a single day of experimentation, because they didn't understand read/write capacity units.

5. Complexity Grows Exponentially

AWS has over 200 services. That number sounds impressive, but most developers only use 10-15 regularly. The rest creates a "paradox of choice" — you don't know which to pick, and every decision has cost implications.

A team of 5 deploying a simple web app on AWS needs at least:

• EC2 or ECS for compute
• RDS for database
• S3 for static assets
• CloudFront for CDN
• Route 53 for DNS
• ACM for SSL certificates
• ALB for load balancing
• IAM for permissions
• VPC for networking
• CloudWatch for monitoring

10 services just to deploy a web app. On DigitalOcean or Railway, you need 1-2 clicks.

Counter-argument: AWS Still Has Its Place

Before deciding to "leave AWS," consider:

AWS wasn't built for simplicity. It was built for flexibility. If you need multi-region deployment, compliance certifications (HIPAA, SOC 2, PCI DSS), or scaling from 0 to 100M users — AWS is the right choice.

Egress costs are high, but AWS has CloudFront with cheaper pricing. The catch: you have to actively optimize. AWS won't do it for you.

Complexity comes with control. On DigitalOcean, you can't fine-tune IAM policies at the granularity AWS offers. For small startups, that's a feature. For enterprises, it's a limitation.

Practical Advice

If your team is < 10 people:

Don't use AWS. Seriously. Use Railway, Render, Fly.io, or Vercel. Lower cost, simpler, and you focus on code instead of infra.

If you're already on AWS and want to optimize:

1. Turn off NAT Gateways if you don't need them — use VPC endpoints for S3, DynamoDB instead
2. Use Savings Plans over On-Demand — save 30-60%
3. Clean up resources regularly — EBS snapshots, unused Elastic IPs, old S3 versions
4. Set up AWS Cost Explorer + Budget Alerts — get notified when costs exceed thresholds
5. Consider multi-cloud or hybrid — run main workloads on AWS, but use Cloudflare R2 instead of S3 (free egress)

If you're evaluating cloud providers:

Don't choose AWS just because "everyone uses it." Choose based on:

• Team expertise: what does your team know?
• Workload requirements: how much scale do you need?
• Budget: startup or enterprise?
• Vendor lock-in tolerance: how long are you willing to commit?

Conclusion

AWS is a powerful tool, but it's not always the best choice. The viral HN post isn't anti-AWS — it's a reminder that complexity has a cost, and developers should evaluate trade-offs clearly.

The question isn't "AWS or not AWS" — it's "how much complexity are you willing to accept?"

If your team is struggling with AWS, start with a cost audit — the problem is usually that you're using more than you need.

---

References:

• I returned to AWS and was reminded why I left — Hacker News discussion
• AWS Pricing Calculator
• Datadog State of Cloud Security 2025
• AWS Well-Architected Framework