Glossary
Well-Architected Framework
Also: Well-Architected review
A question catalogue from AWS for assessing an architecture along six pillars, from operational excellence to sustainability.
The framework is not a certificate but a structured self-interrogation: operations, security, reliability, efficiency, cost and sustainability. Each pillar comes with questions you can either answer or not.
The value lies less in the answers than in the gaps that surface while going through them, most often around recovery and cost attribution.
The most effective question is rarely a technical one. "How do you know that recovery works?" produces the same result in most sessions: there is a procedure, it is written down in a document, and it has never been carried out. Cost works the same way. The bill is known, the drivers behind it are not, because tags are missing.
The format is deliberately a conversation, not an examination. It only works if the people who run the system can answer honestly without their answer being recorded as a failing. If the management sits in the room and every gap turns into a question of blame, you get optimistic answers and a worthless list.
What comes out at the end is exactly that: a list. It typically contains thirty to eighty items, sorted by severity according to the catalogue, not according to the business. That pre-sorting is the point at which most reviews lose their effect, because a "high risk" from the catalogue can be entirely irrelevant for a particular company, while a medium item hits precisely the weakness that has already caused two outages.
The list becomes usable through two numbers per item: what the damage would cost, and how likely it is. Rough estimates are enough for both. Set that against the effort and you get an order you can still defend when the budget runs out after five items.
Repeating the exercise annually or ahead of larger changes makes sense. The framework does not measure whether an architecture is good, but whether it fits the requirements, and requirements change faster than architecture does.
How you notice it
- The architecture grew and was never reviewed systematically.
- There is no list of open risks, only instinct.
- A client or auditor asks about the state of the environment.
- Recovery is described but has never been carried out.
Not to be confused with
- Landing zone
- Built structure, not a questionnaire. A review regularly exposes that it is missing, but it does not replace it.
- Security audit
- Checks against a binding catalogue with a pass or fail. The review is voluntary, broader in scope and issues no certificate.
- Trusted Advisor
- Automated checks against technical rules. It finds configuration drift, but no missing procedures such as an untested recovery.
When it fits
- The architecture grew and was never reviewed systematically.
- Ahead of a larger extension or a jump in load.
- After an incident, to check what sits around the cause as well.
- When a client or auditor asks about the state of the environment.
When it does not
- Shortly after a review with nothing implemented in between: the list is still there.
- When no capacity is planned for working on the results.
- As a substitute for a concrete engagement: the review does not replace implementation.
How to approach it
- Limit the scopeOne system or one workload, not the entire environment. A review across everything stays on the surface and hits nothing.
- Get the right people at the tableWhoever runs it, whoever builds it, whoever owns the cost. Without operations you lose the knowledge about the cases that actually occur.
- Allow honest answersIt is a conversation, not an examination. Where a gap becomes a question of blame, you get polished answers and a worthless list.
- Re-sort by business consequenceFor each item, roughly estimate what the damage would cost and how likely it is. The ordering of the catalogue knows nothing about your business.
- Pick five items and put dates on themWith owners and deadlines. Working through the list in full never happens, working through a selection does.
- Repeat and compareAfter twelve months or ahead of the next major change. The comparison shows whether implementation happened or the list only got older.
Frequently asked
What does a Well-Architected review actually deliver?
A list, not a solution. Its value is that gaps get named which nobody said out loud before, usually around recovery and cost attribution. It only becomes useful once prioritized against your own cost of downtime.
How long does it take?
For a single workload, one to two days of conversation plus preparation and write-up. Anyone trying to cover the whole environment in one session gets a list without depth. The implementation is the real effort and takes weeks to months.
Do you have to go through all six pillars?
Not necessarily. If the trigger is a cost problem, it pays to focus there, with a short pass through reliability and security, because cost measures frequently have effects in exactly those areas. A full pass makes sense when the system has never been reviewed at all.
Is Trusted Advisor not enough?
For the automatically checkable items yes, and you should work through those anyway. What tools do not find are missing procedures: an untested recovery, unclear ownership during an incident, a recovery objective that was never agreed with the business. That is exactly where the expensive gaps sit.