I do not trust an AWS architecture just because it looks simple on a slide.
Simple diagrams are easy to draw. Simple systems are harder to run. The gap between those two things is where most cloud pain lives.
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.
That is why I think “simple AWS architecture” is often a misleading phrase.
The picture is not the system
An architecture diagram normally shows the happy path.
It does not show the error path, and the error path is where you earn the complexity.
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?
Those are not edge cases. Those are the actual system.
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.
AWS rewards the wrong kind of simplicity
AWS makes it easy to create a diagram that looks lightweight and modern.
That is the trap.
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.
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.
That can still be the right tradeoff. I still like serverless and managed services. I just do not like pretending they are free.
What I look for instead
When I say an AWS setup is good, I usually mean it is understandable under pressure.
That means:
- there are obvious failure boundaries
- retries are deliberate, not accidental
- IAM is boring enough that someone else can read it later
- logs and metrics tell the same story
- deployments do not depend on undocumented ritual
- the system still makes sense when one service is degraded
That is a more useful definition of simple.
Sometimes the better architecture is not the one with the fewest boxes. Sometimes it is the one with the fewest surprises.
Simple is not the goal
I would rather have a slightly more explicit AWS architecture that I can explain, debug, and operate than a tiny-looking design that falls apart the moment the first real failure shows up.
That does not mean you should build a monster. It means you should be honest about where the complexity lives.
In cloud systems, the diagram is the easy part. The system is everything the diagram left out.
