Why devs are quitting aws and what they’re choosing instead

The cloud giant isn’t invincible here’s why some engineers are ditching AWS for leaner, meaner setups Introduction: rage quitting the cloud boss battle If AWS were a video game boss, it would be the one with 27 different attack modes, a second health bar, and a $437 surprise invoice when you respawn. For years, Amazon Web Services was the obvious choice for developers powerful, scalable, and used by the big leagues. But now? A growing number of devs are hitting the eject button and exploring new terrain. This article isn’t a salty rant from someone who got burned by CloudWatch fees (okay, maybe a little). It’s a real look at how AWS, once the darling of cloud infrastructure, is becoming less attractive especially for indie hackers, startups, and lean dev teams. We’ll break down why developers are walking away from AWS in 2025, what they’re choosing instead, and whether you should consider doing the same. Spoiler: it’s not just about money. It’s about sanity. Let’s gear up you’re about to enter the post-AWS era. Section 1: the aws honeymoon is over There was a time when deploying your app on AWS felt like leveling up. You weren’t just spinning up a server you were entering the cloud arena like a pro. EC2, S3, Lambda… the acronyms alone made you sound like a DevOps wizard. But let’s be honest that honeymoon phase? It’s long over. For many developers today, AWS feels more like an over-engineered mess of services duct-taped together with IAM policies you barely understand. What used to be “cool” is now “complicated.” Want to deploy a simple app? Better be ready to write Terraform scripts, define 15 roles, and pray to the AWS gods you didn’t accidentally open your entire S3 bucket to the public internet. It’s not just the setup either it’s the mental overhead. There are now over 200 services in AWS. Some do the same thing. Some sound like they do the same thing but don’t. Some were probably built in a hackathon and never removed. Unless your full-time job is just keeping up with new AWS services (shout out to AWS Heroes), you’re probably doing what the rest of us do: googling “how to allow access to DynamoDB from Lambda” for the 14th time this month. For small teams and solo builders, this complexity kills momentum. You’re not building fast you’re configuring YAML files like it’s a full-time job. And let’s not even get started on CloudFormation errors. The magic is fading. And developers are starting to ask: is this really worth it anymore? Section 2: you’re not saving money, you’re burning it Let’s talk about the elephant in the billing dashboard: AWS is expensive sometimes cartoonishly so. Sure, the free tier lures you in like a friendly NPC offering free potions. But the moment your app actually starts getting traffic or you forget to shut down a dev environment, surprise! You’re hit with a multi-line invoice that looks like someone ran Math.random() over your wallet. And don’t get me started on egress fees. You’d think downloading your own data would be free in 2025 but in AWS land, moving data out of S3 or EC2 costs more than a VPN and two therapy sessions. Here’s the real kicker: half the time, you don’t even know what is costing you money. CloudWatch logs? That thing you forgot you enabled two weeks ago? It’s been racking up charges like a kid with your unlocked iPad. NAT Gateways? You’ll pay for those like you owe them lunch money. And just wait until you hit that Lambda “invocation per month” threshold. Real example: A dev on Hacker News once shared how their tiny API hosted on Lambda and fronted by API Gateway was costing them over $70/month. They moved it to Fly.io, rewrote it in Go, and now run it for $2/mo and that includes logging, metrics, and backups. It’s not that AWS is trying to scam you it’s just built for enterprises who don’t blink at five-figure invoices. But for indie devs, bootstrappers, or small teams? That’s death by a thousand billing cuts. So no, you’re not saving money on AWS you’re paying for complexity you didn’t ask for. Section 3: aws complexity is now a feature, not a bug There’s a cruel joke in the cloud world: AWS doesn’t solve your problems it gives you more powerful problems to manage. And that’s the thing complexity in AWS isn’t accidental. It’s systemic. It’s built in. It’s the reason entire industries exist just to help you understand it (hello, AWS consultants and $6,000 cert bootcamps). Want to launch a simple backend with a database and a cron job? On AWS, you’re suddenly juggling: IAM roles and trust relationships VPCs and subnets (even if you didn’t ask for them) CloudWatch just to get basic logs Route 53 DNS weirdness CloudFormation or Terraform spaghetti to glue it all together It’s like AWS hands you an IKEA box full of services and says “Good luck building your app the manual’s somewhere in the documentation jungle.” Meanwhile, dev-first platforms like Railway, Render, or Fly.io are saying, “Paste your GitHub repo, and boom here’s your app, deployed.” T

May 9, 2025 - 09:26

Why devs are quitting aws and what they’re choosing instead

The cloud giant isn’t invincible here’s why some engineers are ditching AWS for leaner, meaner setups

Introduction: rage quitting the cloud boss battle

If AWS were a video game boss, it would be the one with 27 different attack modes, a second health bar, and a $437 surprise invoice when you respawn. For years, Amazon Web Services was the obvious choice for developers powerful, scalable, and used by the big leagues. But now? A growing number of devs are hitting the eject button and exploring new terrain.

This article isn’t a salty rant from someone who got burned by CloudWatch fees (okay, maybe a little). It’s a real look at how AWS, once the darling of cloud infrastructure, is becoming less attractive especially for indie hackers, startups, and lean dev teams.

We’ll break down why developers are walking away from AWS in 2025, what they’re choosing instead, and whether you should consider doing the same. Spoiler: it’s not just about money. It’s about sanity.

Let’s gear up you’re about to enter the post-AWS era.

Section 1: the aws honeymoon is over

There was a time when deploying your app on AWS felt like leveling up. You weren’t just spinning up a server you were entering the cloud arena like a pro. EC2, S3, Lambda… the acronyms alone made you sound like a DevOps wizard.

But let’s be honest that honeymoon phase? It’s long over.

For many developers today, AWS feels more like an over-engineered mess of services duct-taped together with IAM policies you barely understand. What used to be “cool” is now “complicated.” Want to deploy a simple app? Better be ready to write Terraform scripts, define 15 roles, and pray to the AWS gods you didn’t accidentally open your entire S3 bucket to the public internet.

It’s not just the setup either it’s the mental overhead.

There are now over 200 services in AWS. Some do the same thing. Some sound like they do the same thing but don’t. Some were probably built in a hackathon and never removed. Unless your full-time job is just keeping up with new AWS services (shout out to AWS Heroes), you’re probably doing what the rest of us do: googling “how to allow access to DynamoDB from Lambda” for the 14th time this month.

For small teams and solo builders, this complexity kills momentum. You’re not building fast you’re configuring YAML files like it’s a full-time job. And let’s not even get started on CloudFormation errors.

The magic is fading. And developers are starting to ask: is this really worth it anymore?

Section 2: you’re not saving money, you’re burning it

Let’s talk about the elephant in the billing dashboard: AWS is expensive sometimes cartoonishly so.

Sure, the free tier lures you in like a friendly NPC offering free potions. But the moment your app actually starts getting traffic or you forget to shut down a dev environment, surprise! You’re hit with a multi-line invoice that looks like someone ran Math.random() over your wallet.

And don’t get me started on egress fees. You’d think downloading your own data would be free in 2025 but in AWS land, moving data out of S3 or EC2 costs more than a VPN and two therapy sessions.

Here’s the real kicker: half the time, you don’t even know what is costing you money. CloudWatch logs? That thing you forgot you enabled two weeks ago? It’s been racking up charges like a kid with your unlocked iPad. NAT Gateways? You’ll pay for those like you owe them lunch money. And just wait until you hit that Lambda “invocation per month” threshold.

Real example:

A dev on Hacker News once shared how their tiny API hosted on Lambda and fronted by API Gateway was costing them over $70/month. They moved it to Fly.io, rewrote it in Go, and now run it for $2/mo and that includes logging, metrics, and backups.

It’s not that AWS is trying to scam you it’s just built for enterprises who don’t blink at five-figure invoices. But for indie devs, bootstrappers, or small teams? That’s death by a thousand billing cuts.

So no, you’re not saving money on AWS you’re paying for complexity you didn’t ask for.

Section 3: aws complexity is now a feature, not a bug

There’s a cruel joke in the cloud world: AWS doesn’t solve your problems it gives you more powerful problems to manage.

And that’s the thing complexity in AWS isn’t accidental. It’s systemic. It’s built in. It’s the reason entire industries exist just to help you understand it (hello, AWS consultants and $6,000 cert bootcamps).

Want to launch a simple backend with a database and a cron job? On AWS, you’re suddenly juggling:

IAM roles and trust relationships
VPCs and subnets (even if you didn’t ask for them)
CloudWatch just to get basic logs
Route 53 DNS weirdness
CloudFormation or Terraform spaghetti to glue it all together

It’s like AWS hands you an IKEA box full of services and says “Good luck building your app the manual’s somewhere in the documentation jungle.”

Meanwhile, dev-first platforms like Railway, Render, or Fly.io are saying, “Paste your GitHub repo, and boom here’s your app, deployed.”

Those tools hide complexity. AWS seems to celebrate it.

And sure, that’s great for Fortune 500s with 17 teams and an SRE army. But for indie devs? It’s exhausting. When your actual product takes a backseat to infrastructure configs and billing dashboards, something’s broken.

You know what used to be fun? Coding.
You know what’s not fun? Realizing you’ve spent 9 hours debugging an IAM permission just to let a Lambda function write to DynamoDB.

Section 4: what devs are choosing instead (2025 version)

So if AWS is becoming the cloud version of a Rubik’s cube made of fire and billing surprises, where are developers running to?

Spoiler: they’re not going off-grid they’re just switching to cloud platforms that don’t fight back.

The indie-friendly cloud scene has exploded, and devs are picking platforms that:

Don’t require a PhD in infrastructure
Offer transparent pricing
Deploy apps in minutes, not days
Have great DX (developer experience), because yes, that matters

Here’s a quick rundown of AWS alternatives devs are loving in 2025:

Real dev feedback:

“I moved my entire stack from AWS to Railway in a weekend. Same performance, 10x better developer experience.”
“Supabase is like AWS but designed by humans.”
a startup dev who’s had enough

These platforms aren’t trying to be AWS. That’s the point. They’re trying to give developers what they actually need: a fast, sane way to ship software.

The indie cloud isn’t just cute it’s functional, affordable, and kind of a joy to use.

Section 5: who should still use aws

Let’s be real AWS isn’t going anywhere.

In fact, there are still great reasons to use AWS, especially if you’re:

Running at scale with millions of users
Handling high compliance requirements (HIPAA, SOC 2, etc.)
Needing multi-region failover or fine-grained control over infrastructure
Working in a team that already has deep AWS expertise and tooling

If you’re Netflix, you’re not moving your stack to Vercel.
If you’re a unicorn startup with a full-time DevOps team and a budget that doesn’t blink at $15K/month, AWS makes sense. You get power, flexibility, and battle-tested reliability if you know how to wield it.

Use AWS if:

You need services like EKS, Redshift, or Elastic Transcoder (not easily replaceable)
You’re already embedded in the AWS ecosystem (and migrating would hurt more)
You have the team and time to tame its complexity

So no, this isn’t a “never use AWS” take. It’s a “be honest about your needs” take.

The mistake devs make is assuming AWS is the default the “grown-up” choice. But unless your project requires the deep firepower AWS offers, it’s like renting a jet engine to power a bicycle.

Section 6: the rise of the indie-friendly cloud

Once upon a time, “alternative to AWS” meant you were either a hipster or a risk-taker. In 2025? It means you value developer sanity and don’t want your infrastructure to feel like a second job.

The indie-friendly cloud is no longer a niche movement it’s a full-blown uprising.

Platforms like Railway, Render, Fly.io, Vercel, Supabase, and Cloudflare are leading the charge with a shared philosophy:

Great DX by default
Instant deployments via Git
Transparent pricing, with no surprise egress fees
Modern UIs, not AWS Console nightmares
Batteries included observability, logging, backups, all built-in

These platforms aren’t trying to give you every tool under the sun. They give you the right tools, tightly integrated, optimized for getting things done. Think Heroku’s original magic, reborn for the modern web.

Bonus points:

Most of them offer generous free tiers that actually work for small projects
They make rollback and redeploys as easy as clicking a button
Many support PostgreSQL, Docker, edge functions, and even monorepos natively

Devs are no longer picking platforms for resume clout;they’re picking what makes their day-to-day life suck less.

Section 7: what devs are saying

Don’t just take my word for it — the developer community has been loud about their AWS breakups lately. From Hacker News threads to spicy tweets, you’ll find hundreds of engineers sharing their “I escaped AWS and survived” stories like it’s a support group.

Here are a few real quotes that sum up the mood:

“AWS feels like a toxic relationship. You’re afraid to leave, but you’re also constantly stressed out and confused.”
comment on r/devops
“I replaced S3, Lambda, and CloudFront with a single Vercel deployment. I sleep better now.”
@frontenddude on Twitter/X
“My AWS bill was $280/month. I moved to Fly.io + PlanetScale and cut it to $19. No change in performance.”
startup founder on Indie Hackers
“I don’t want to need a cert to deploy a blog.”
thread from a junior dev, still recovering from IAM trauma

And the conversation isn’t just about cost it’s about friction.

There’s a growing awareness that just because AWS is powerful doesn’t mean it’s the right fit especially for indie devs, early-stage startups, and solo engineers who just want to ship cool things.

Want proof? Browse any of these trending threads:

The vibe is clear: Devs are done being infrastructure babysitters.

Section 8: how to transition away from aws (without nuking your app)

Okay, so you’re convinced. You’re eyeing that AWS billing dashboard with suspicion, your CloudFormation files are giving you hives, and you’re thinking… maybe it’s time.

But let’s be real moving away from AWS feels risky. Like disarming a bomb made of YAML and Terraform.

Good news: you don’t have to rip everything out in one go. Here’s a step-by-step guide to a stress-free AWS escape plan:

1. Audit what you’re actually using

Start by asking:

What services are critical to your app?
Which ones are just… there because you followed some Medium tutorial? Use tools like Infracost or CloudForecast to get a grip on your usage and costs.

2. Test the waters with new platforms

Try deploying a clone of your app or a staging environment on platforms like:

Render for web services + background jobs
Supabase for your database and auth
Fly.io for global apps and Dockerized projects
Vercel or Netlify for frontend + APIs

Bonus: most of these tools let you deploy from GitHub with a single click.

3. Migrate incrementally

Don’t do a Big Bang rewrite.

Move static files from S3 → Cloudflare R2 or Backblaze
Replace API Gateway + Lambda → Vercel or Render endpoints
Gradually shift databases to Supabase or PlanetScale

You can even run side-by-side and A/B test performance before committing.

4. Clean up your AWS setup

As you migrate:

Remove unused services
Delete old CloudWatch log groups
Kill zombie EC2 instances from 2019
Archive billing reports, and unsubscribe from all those “Free Tier Usage Alert” emails

Future-proof your infra

Wherever you go, prefer

Open standards (Docker, PostgreSQL, REST/GraphQL APIs)
Platforms that support easy export/migration
Providers with a real status page and human support

Remember: freedom is a feature too.

AWS isn’t a prison but escaping it feels a lot easier once you break it down into steps. You don’t need to go “cold turkey” overnight. Just start walking toward clarity, simplicity, and fewer 3 a.m. billing surprises.

Section 9: think before you cloud

Let’s hit pause for a second.

This whole discussion isn’t just about AWS. It’s about how we, as developers, default to complex tools way too quickly. Somewhere along the way, spinning up 10 microservices, a message queue, and a Kubernetes cluster became the “hello world” of backend dev.

But here’s the question: do you actually need all that?

Before reaching for any cloud service AWS, Vercel, Fly.io, or the shiny new platform your favorite YouTuber just demoed ask yourself:

“Am I solving a real problem or building infrastructure for its own sake?”

If your app:

Has a few hundred users
Doesn’t need five-nines uptime
Isn’t handling mission-critical compliance

…then maybe you don’t need a cloud fortress. Maybe you need a boring, reliable, minimal stack that lets you ship fast and sleep well.

Some dev truth bombs:

You don’t need a Kubernetes cluster to host your side project.
You don’t need 17 AWS services to serve a blog and API.
You don’t need to chase scale unless scale is chasing you.

There’s a reason the indie-friendly cloud is winning hearts it lets you focus on the thing you’re actually building.

So the next time you’re architecting your app, don’t reach for AWS out of habit. Reach for it if and when it makes sense.

Section 10: conclusion you’re not broken, the cloud is

If AWS has ever made you feel like you’re bad at devops, confused by default, or in need of a certification just to push code — it’s not you. It’s the system.

Amazon Web Services is an incredible platform. It powers Netflix, NASA, and half the Fortune 500. But that doesn’t mean it’s the right choice for you, right now.

The shift away from AWS isn’t about being edgy it’s about devs reclaiming clarity, speed, and peace of mind.

In 2025, building in the cloud doesn’t have to mean wrestling with IAM, deciphering region-based pricing, or waking up to a four-digit bill because of misconfigured egress.

You now have options. Good options.

Whether you’re shipping a startup, deploying a weekend project, or running a SaaS with a lean team, the indie cloud is finally mature enough to be a first-class choice.

So next time you think “Let’s just do it on AWS,” stop and ask:

Do I want to build my product? Or do I want to become a part-time cloud janitor?

Choose wisely, friend.

Helpful resources & further reading

Here are some links to help you explore AWS alternatives, pricing tools, and migration guides:

Final thought:

If your stack feels like a second job, maybe it’s time to fire it.