Well-architected frameworks

Each major cloud provider publishes a well-architected framework: a set of design principles and review questions for building good systems on its platform. Despite different names, the three frameworks cover nearly the same ground, which makes them a useful vendor-neutral checklist for any cloud design.

The shared pillars

Concern	What it asks
Operational excellence	Can we deploy, monitor and improve the system safely and routinely?
Security	Are identities, data and networks protected, and can we detect and respond to incidents?
Reliability	Does the system recover from failures and meet its availability targets?
Performance efficiency	Are we using the right resources, and do they scale with demand?
Cost optimization	Do we spend only what delivers value, and can we see where money goes?
Sustainability	Do we minimize the environmental impact of the workload?

AWS (opens in a new tab)’s framework names six pillars along these lines. Microsoft Azure (opens in a new tab)’s framework uses five (reliability, security, cost optimization, operational excellence and performance efficiency). Google Cloud (opens in a new tab)’s framework covers the same areas, organized slightly differently. Check each provider’s current documentation, as the frameworks are revised regularly.

How to use a framework

flowchart LR
    a[Define workload and goals] --> b[Review against each pillar]
    b --> c[List risks and gaps]
    c --> d[Prioritize fixes]
    d --> e[Improve and re-review]
    e --> b

Review a workload, not the whole estate. Assess one application or system at a time.
Answer honestly. The review questions are designed to surface risks, not to be passed.
Treat the result as a backlog. Rank the risks found and address the highest first.
Repeat. Re-review after major changes, or on a regular cycle.

Pros

A shared vocabulary between architects, engineers and management.
Free and well documented, with tools that guide the review.
Balanced: forces attention to cost and operations, not only features.

Cons

Provider-flavored: recommendations naturally favor each vendor’s own services.
Checklists can become box-ticking without real change.
Trade-offs aren’t resolved for you: reliability and cost often pull in opposite directions.

When to use it

Before launching a significant workload on the cloud.
As a periodic health check of important systems.
When preparing for cloud architect certifications, which draw heavily on these frameworks.

Common pitfalls

Reviewing once and filing the report. Value comes from fixing the findings.
Treating every pillar as equally important for every workload. A batch analytics job and a payment API have different priorities.

In practice

Netflix moves to the cloud: designing for failure and testing it deliberately.
Dropbox builds Magic Pocket: when owning infrastructure beats renting it.
Failure library: twelve public outages and the patterns that limit them.