AWS solutions-architecture tradeoffs I keep re-learning

AWSSolutions ArchitecturePlatform Engineering

Every few months I end up re-deriving the same set of tradeoffs on a new AWS project. Writing them down so future-me stops re-learning them from scratch.

Managed services buy you time, not correctness

Reaching for a managed service (SQS over a self-hosted queue, RDS over self-managed Postgres, Step Functions over a hand-rolled orchestrator) almost always reduces operational burden. It does not automatically make the architecture correct. You still have to think through failure modes — what happens on a poison message, what happens when a Lambda times out mid-transaction — the managed service just changes who’s paging at 3am, not whether the failure mode exists.

Cost and latency pull in opposite directions more often than expected

Cross-AZ traffic, NAT gateway data processing charges, and Lambda cold starts all show up as “small” line items that compound at scale. The instinct to optimize for lowest latency (more AZs, more edge caching, provisioned concurrency everywhere) is usually the wrong default for a system that isn’t latency-critical yet. Start from the actual SLA the system needs, not the SLA that’s technically achievable.

Blast radius should drive account/VPC boundaries, not org charts

It’s tempting to structure AWS accounts and VPCs around team boundaries because that mirrors how the org is structured. The better question is: if this component is compromised or misconfigured, what’s the maximum damage, and does the current account/network boundary actually contain it? Multi-account setups earn their complexity when they reduce blast radius, not just when they mirror reporting lines.

IAM policy scope is a design decision, not a security afterthought

Writing Action: "*" “to unblock the demo” is the single most common way a temporary decision becomes permanent. Scoping IAM policies tightly from day one is cheaper than the retrofit later, and it forces you to actually understand what a service needs to do — which is useful architectural information in its own right.

None of these are novel insights, but they’re the ones that are easiest to skip under deadline pressure, which is exactly when they matter most.