Posted on Jan 16

“Just use aws” is starting to sound like bad advice in 2026

#webdev #programming #aws #cloud

It used to be the safest answer in tech. now it feels like autopilot and sometimes, a trap.

There was a time when “just use AWS” was the most responsible advice you could give a developer.

Not cool.
Not clever.
Just safe.

It meant your app wouldn’t collapse under real traffic. It meant you weren’t building critical infrastructure on a half-maintained VPS and vibes. Back then, “just use AWS” was the engineering equivalent of wearing a seatbelt.

Somewhere along the way, though, it quietly changed.

Now it often means accepting a billing model you don’t fully understand, inheriting a maze of services you didn’t ask for, and trading speed for optionality you may never need. Amazon Web Services is still powerful still the right choice in many cases but the advice itself didn’t age well.

If you’ve ever opened Cost Explorer with confidence and closed it with regret, you already know that.

This isn’t a hit piece. It’s about how the industry shifted, why developers are adjusting quietly, and why defaults that once felt safe now deserve a second thought.

And yeah we should probably talk about that.

When “just use aws” actually made sense

There was a version of reality where “just use AWS” was elite-tier advice.

Not trendy. Not spicy. Just correct.

Back then, Amazon Web Services felt like a cheat code you weren’t supposed to have yet. You could spin up servers in minutes. Storage stopped being scary. Databases didn’t require a weekend ritual and a backup prayer.

If you were a small team or a solo dev it was ridiculous how much leverage you suddenly had.

EC2 meant you didn’t need to beg ops for machines.
S3 meant you stopped worrying about disks filling up.
RDS meant you could stop pretending you enjoyed managing MySQL.

And the mental model was simple. Painfully simple by today’s standards.

You had a server.
It ran your app.
If it broke, you SSH’d in and fixed it.

That was it.

No fifteen-service dependency graph. No surprise line items for “data moved between two things you assumed were basically the same thing.” No IAM policy archaeology. You could explain your entire infrastructure to another dev on a whiteboard without apologizing halfway through.

I still remember my first EC2 deploy. Not because it was perfect — but because it worked. I pushed code, refreshed the page, and the site was just… there. No ceremony. No waiting. It felt like unlocking a late-game ability way too early.

At that moment, “just use AWS” wasn’t lazy advice.
It was compassionate advice.

It meant: don’t overthink it. Don’t build your own problems. Ship something real.

The key thing we forget now is this: the advice matched the era.

AWS was simpler. Teams were bigger. Margins were looser. And the cloud hadn’t yet turned into a choose-your-own-adventure where every choice had a billing implication.

The advice wasn’t wrong.

It just hasn’t been updated since the game patched in hard mode.

What changed (and why it matters now)

At some point, AWS stopped feeling like a toolbox and started feeling like a skill tree you could accidentally brick.

This wasn’t a single moment. There was no big announcement. No blog post titled “we are about to make this emotionally expensive.” It just… accumulated.

Services piled up. Abstractions stacked on abstractions. Pricing models got sliced thinner and thinner until you weren’t paying for a server anymore you were paying for behaviors.

Requests.
Invocations.
Data moved five inches to the left.

On paper, Amazon Web Services is more powerful than ever. In practice, that power now comes with cognitive overhead that didn’t exist when the original advice was coined.

The first big shift was service sprawl. AWS didn’t just add features it added choices. Multiple ways to solve the same problem, each with slightly different tradeoffs, limits, and footnotes. Want compute? Cool. Pick between EC2, ECS, EKS, Lambda, Fargate, Batch, Lightsail… and that’s before you even talk about how they interact.

The second shift was pricing opacity. Not because AWS hides prices the docs are there but because modern pricing depends on emergent behavior. You don’t really know what something costs until it’s running under real load, doing real things, in the real world. At which point, congrats, you’re already paying for it.

This is where the tone of infra work changed.

Cost used to be something you optimized after success. Now it’s something you fear before traffic. Dashboards that were once observability tools quietly turned into anxiety generators. Cost alerts became just as important as uptime alerts sometimes more.

And then came the AI and data workloads.

Suddenly, moving data wasn’t rare. It was constant. Suddenly, “serverless” wasn’t just handling webhooks it was chewing through tokens, embeddings, logs, streams, retries. Patterns that used to be cheap at small scale started getting weirdly expensive in production, not because you messed up, but because the model changed underneath you.

None of this makes AWS bad.

But it does mean the original advice “just use AWS” assumes a simplicity that no longer exists.

It assumes you’re opting into a known quantity.
In reality, you’re opting into a system that reveals its complexity over time.

And that’s the part people don’t warn you about.

The hidden cost: cognitive load and velocity loss

The part nobody warns you about isn’t the bill.

It’s the brain tax.

AWS doesn’t just charge money it charges attention. Every new service you touch adds a little more surface area you have to remember, reason about, and explain to Future You when something breaks for reasons that feel personal.

On paper, Amazon Web Services gives you infinite flexibility. In practice, that flexibility shows up as decisions you didn’t know you were signing up for. Networking models. Permission boundaries. Execution roles. Service limits. Quotas you only learn about by hitting them.

None of these things are individually terrible. The problem is accumulation.

I’ve lost more time than I want to admit debugging IAM policies that were technically correct but emotionally hostile. You start by wanting to give a service access to one thing, and an hour later you’re three tabs deep in docs, muttering “why is this denied” like it’s a personal betrayal.

And that time adds up.

Infra reviews start taking longer than feature planning. Pull requests get blocked not on logic, but on configuration. You hesitate to ship small changes because you’re not entirely sure which invisible meter they might spin.

This is where velocity quietly leaks out.

Not because AWS is slow but because thinking about AWS is slow. It pulls you out of product mode and into platform-operator mode, even when you never wanted that job.

What stings most is that none of this feels like failure. You followed best practices. You chose the “safe” option. Yet somehow, shipping feels heavier than it should.

That’s the hidden cost.

Not dollars.
Not downtime.
Just the slow realization that your infrastructure is taking up more headspace than your actual product.

What devs are doing instead (quietly)

What’s interesting is that there wasn’t a mass exodus.

No dramatic blog posts. No “we deleted our AWS account and found inner peace” victory laps.

Most devs just… adjusted.

The shift isn’t away from Amazon Web Services. It’s away from treating it like a religion.

Instead of defaulting to AWS for everything, teams started using it surgically. One service here. One there. Only where it actually earns its complexity. Everything else? Fair game.

You see it in small, practical decisions. Compute running somewhere simpler because it’s predictable. Databases moved to managed providers that do one thing well and don’t require a networking PhD to operate. Static stuff pushed closer to users without an origin story involving six AWS services and a diagram nobody wants to maintain.

Polycloud stopped being a scary word and started being… normal.

Not because devs suddenly love juggling vendors, but because the tradeoff makes sense now. Using the best tool for a specific job is often cheaper, faster, and easier than forcing everything through a single mega-platform just to feel “enterprise-ready.”

I’ve watched teams replace one AWS service and immediately feel the system breathe again. Fewer permissions to reason about. Fewer pricing variables. Fewer surprise behaviors. Nothing radical just quieter infrastructure.

The funny part? Most of these teams still use AWS.

They just stopped assuming it was the answer before asking the question.

That’s the real change. The confidence to say:
“Yeah, AWS is great… but not here.”

And once you make that mental shift, the pressure lifts. Infra decisions stop feeling permanent. You stop optimizing for hypothetical scale and start optimizing for the reality you’re in.

Which, for most teams, is smaller, faster, and more constrained than the old advice ever assumed.

A better default than “just use aws”

The real fix isn’t switching clouds.
It’s switching questions.

“Just use AWS” worked when infra was the bottleneck. Today, decision quality is the bottleneck. So a better default isn’t a platform it’s a pause.

Before reaching for Amazon Web Services, I’ve started asking a few boring-but-deadly-effective questions:

How small is this really going to stay?
What’s the most expensive mistake we can make here?
Which part of this needs to scale, and which part just needs to exist?
Who is going to debug this six months from now?

The answers change everything.

Sometimes they point straight back to AWS. Big team, unpredictable growth, complex integrations, real compliance needs? Yeah. AWS earns its keep there.

But a lot of the time, the answers point somewhere quieter. Something more opinionated. Something with fewer knobs to accidentally turn. And that’s not “settling” that’s matching the tool to the moment.

The biggest mental shift for me was realizing infra choices aren’t marriages anymore. They’re leases. You can move. You can refactor. You can outgrow things without framing it as a failure.

Once you internalize that, the fear goes away.

You stop over-engineering for a future you might never reach. You stop inheriting complexity “just in case.” You ship faster, sleep better, and spend more time thinking about the product instead of the platform.

A better default isn’t “just use AWS.”

It’s: “what problem are we actually solving right now?”

A better default than “just use aws”

The fix isn’t finding a new magic platform.

It’s dropping the idea that a magic default exists.

“Just use AWS” used to save time because infra decisions were about avoiding obvious mistakes. Today, the mistakes are quieter hidden behind sensible defaults, pricing footnotes, and optional complexity you didn’t ask for.

So instead of defaulting to Amazon Web Services, a better move is to pause and ask a few boring but important questions:

How big is this really going to get?
What’s the worst bill surprise we can survive?
What actually needs to scale here?
Who’s maintaining this when context is gone?

Sometimes those answers lead straight back to AWS. Big team, real compliance, uncertain growth fair enough.

But often, they don’t.

They point to simpler systems. Fewer knobs. Less inherited complexity.

The real mindset shift is this: infra choices aren’t marriages. They’re leases. You can move. You can change your mind. You don’t need to preload complexity just to feel “responsible.”

A better default isn’t a provider.

It’s intentionality.

Once you adopt that, “just use AWS” stops being advice and becomes one option among many.

AWS isn’t the villain autopilot is

It’s easy to look for a villain.

To dunk on Amazon Web Services.
To say the cloud is broken.
To pretend there’s one better answer everyone should switch to tomorrow.

That would be easy. And wrong.

AWS didn’t suddenly get bad. The industry just grew up. Teams got smaller. Margins got tighter. Workloads got weirder. And the cost of unnecessary complexity stopped being theoretical.

The real problem isn’t AWS.
It’s autopilot thinking.

“Just use AWS” worked when avoiding infra mistakes mattered more than understanding tradeoffs. Now, blindly inheriting complexity can be just as risky as rolling your own.

The good news? We’re allowed to question defaults.

You can pick tools that match your actual scale.
You can trade optionality for clarity.
You can optimize for shipping, not hypothetical futures.

That’s not regression. That’s maturity.

If AWS is right for your problem, use it proudly.
Just don’t do it because someone said it was the “safe choice.”