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:
- Turn off NAT Gateways if you don't need them — use VPC endpoints for S3, DynamoDB instead
- Use Savings Plans over On-Demand — save 30-60%
- Clean up resources regularly — EBS snapshots, unused Elastic IPs, old S3 versions
- Set up AWS Cost Explorer + Budget Alerts — get notified when costs exceed thresholds
- 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: