{"id":1169,"date":"2026-04-02T10:00:00","date_gmt":"2026-04-02T09:00:00","guid":{"rendered":"https:\/\/wade.one\/blog\/?p=1169"},"modified":"2026-04-02T10:00:00","modified_gmt":"2026-04-02T09:00:00","slug":"the-problem-with-simple-aws-architectures","status":"publish","type":"post","link":"https:\/\/wade.one\/blog\/2026\/04\/02\/the-problem-with-simple-aws-architectures\/","title":{"rendered":"The Problem With “Simple” AWS Architectures"},"content":{"rendered":"

I do not trust an AWS architecture just because it looks simple on a slide.<\/p>\n

Simple diagrams are easy to draw. Simple systems are harder to run. The gap between those two things is where most cloud pain lives.<\/p>\n

A diagram with a Lambda, an API Gateway, a queue, and a database can look clean enough to reassure everybody in the room. But that picture leaves out the parts that usually matter most: retries, timeouts, permissions, deployment order, dead-letter handling, monitoring, log correlation, secrets, backfills, and what happens when one service is doing the right thing but the rest of the system is not ready for it.<\/p>\n

That is why I think “simple AWS architecture” is often a misleading phrase.<\/p>\n

The picture is not the system<\/h2>\n

An architecture diagram normally shows the happy path.<\/p>\n

It does not show the error path, and the error path is where you earn the complexity.<\/p>\n

If a request fails in one place, how many retries happen? Where do they go? Who sees them? How do you tell whether the failure is in your code, an IAM policy, a throttled dependency, or a bad deployment? If a job gets halfway through and dies, how do you restart it without duplicating work? If a message arrives twice, what keeps you safe?<\/p>\n

Those are not edge cases. Those are the actual system.<\/p>\n

The smaller the team, the more dangerous it is to pretend otherwise. Small teams do not have the luxury of a lot of operational slack. If the system is only “simple” when everything is working, then it is not really simple. It is just unfinished.<\/p>\n

AWS rewards the wrong kind of simplicity<\/h2>\n

AWS makes it easy to create a diagram that looks lightweight and modern.<\/p>\n

That is the trap.<\/p>\n

You can assemble a stack out of managed services and feel like you have avoided infrastructure complexity. In one sense, you have. In another sense, you have just moved the complexity into configuration, permissions, integration boundaries, and service behavior that is easy to underestimate until it starts failing in production.<\/p>\n

I have seen this enough times to have a pretty blunt view on it: if you do not understand the operational consequences of each managed service, you have not simplified anything. You have distributed the complexity into places that are harder to notice.<\/p>\n

That can still be the right tradeoff. I still like serverless and managed services. I just do not like pretending they are free.<\/p>\n

What I look for instead<\/h2>\n

When I say an AWS setup is good, I usually mean it is understandable under pressure.<\/p>\n

That means:<\/p>\n