aws / architecture / cloud
Practical AWS architecture tradeoffs for small products
Where simple static hosting helps, where it does not, and how to avoid solving the wrong infrastructure problem too early.
There is a recurring temptation to design the future version of a system instead of the current one.
For a personal site or small product, that usually means reaching for runtime infrastructure before there is any real evidence that runtime complexity is needed.
Start with the lowest-friction architecture
If the site is mostly content, static generation buys a lot:
- strong performance
- low operating cost
- straightforward deployment
- fewer moving parts to debug
That does not mean the architecture is toy-sized. It means the shape of the solution matches the problem.
Complexity should be earned
A good rule is to ask what a service is doing while traffic is low. If the answer is nothing useful, that service probably does not belong in the stack yet.
That is why static delivery through a private S3 bucket and CloudFront is such a solid baseline. It keeps the system boring in the best way.
Know what you are trading away
Static hosting is not magic. It is a choice with constraints:
- Dynamic personalization is limited.
- Search usually needs either a client-side approach or an external service.
- Anything genuinely request-time becomes a separate concern later.
Those are acceptable trade-offs when the core goal is publishing, not application behaviour.
The useful question
Instead of asking what is the most powerful architecture, ask what is the simplest architecture that still feels production-appropriate.
That framing leads to better systems more often than people expect.