Picking AWS Is Not a Strategy

4 MINS

I've been an AWS Certified Solutions Architect Professional for years, and I'll say the quiet thing out loud: picking AWS is not a strategy. It's a starting point. The strategy is what you do *inside* AWS — and that's where most teams stop thinking.

The "we use AWS" trap

Every team I've seen migrate to AWS has the same first conversation: "we use AWS now". As if that's the answer. It isn't. AWS is a toolbox the size of a small country. The question isn't whether you use it — it's which 5 services you actually depend on, why, and what happens when one of them changes.

Pick fewer services intentionally. The teams that use 30 AWS services usually understand 4 of them.

Know your runtime cost surface. Half your bill is a small number of line items. Find them.

Plan for a service-level outage. Not the "us-east-1 is down" fantasy — the "this one specific service is degrading and your dashboards are lying" reality.

Cloud-native isn't the same as serverless

I keep meeting teams who use the words interchangeably. They aren't.

Cloud-native is about designing the system around the cloud's actual properties — elasticity, ephemerality, distributed failure. Serverless is one (very useful) execution model for some of those properties. They're related, but not identical.

The mistake is going "serverless-first" because the conference talk said so, then discovering halfway through year two that your stateful workflow doesn't fit, and now you're paying for cold starts you don't need.

Cloud-native is a posture. Serverless is a deployment choice. Don't confuse the two.

What I tell teams in design reviews

Justify every service. If you can't say why this Lambda needs to be a Lambda, it probably shouldn't be.

Watch the seams. The places where two AWS services hand off are where the bills, the latencies, and the bugs live.

Treat IAM like real code. Permissions are the most consequential thing in your account. Review them like you review production migrations.

The honest summary

AWS will not save you from a bad design. It will, however, charge you a monthly subscription to that bad design. The cloud is a multiplier — for good architecture and for bad architecture, in equal measure.

TDD in the Real World — What 24 Years on Production Systems Taught Me

Architecture Is the Decision You Don't Get to Remake Later

Manik skipped presentations and built real AI products.

Manik Wadhwa was part of the January 2026 cohort at Curious PM, alongside 13 other talented participants.