Almost every architect we work with has the Azure Well-Architected Framework bookmarked. Far fewer have ever finished a review. The framework gets treated the way people treat a gym membership — acquired with sincere intent, referenced when someone asks, rarely used in the way it was designed to be used.
That’s a shame, because the framework is genuinely good, and it isn’t good for the reason most people assume. Its value isn’t the reference content. It’s that the framework gives a room full of people with competing priorities a shared vocabulary for arguing about trade-offs, and a structure that stops any one priority from quietly winning by default.
What the Azure Well-Architected Framework actually is
Briefly, because Microsoft documents this thoroughly and there’s no point repeating it: the Azure Well-Architected Framework is a set of design principles, trade-off guidance, and assessment tooling organized around five pillars — reliability, security, cost optimization, operational excellence, and performance efficiency. Microsoft positions it as guidance for individual workloads rather than for an entire cloud estate, and provides a self-assessment that scores a workload against each pillar and produces a recommendations list.
If you want the canonical definition of any pillar, go read Microsoft’s. It’s better than anything a consultancy will write, and it’s free. What Microsoft’s documentation cannot do — because it isn’t a document’s job — is tell you which pillar your organization is systematically underweighting, and why nobody has said so out loud.
The pillars are in tension, and that’s the feature
The most common misreading of the framework is treating the five pillars as five boxes to tick, as though a well-architected system maximizes all five simultaneously. It doesn’t, and it can’t. The pillars pull against each other, deliberately:
- Reliability wants redundancy across zones and regions. Cost optimization wants you to stop paying for capacity that sits idle.
- Security wants private endpoints, inspection, and segmentation. Performance efficiency notices that each of those adds a hop and some latency.
- Operational excellence wants everything standardized, reviewed, and deployed through a pipeline. Delivery teams want to ship on Thursday.
A workload that scores perfectly on all five pillars usually means one of two things: nobody was honest during the assessment, or the workload is trivial. Real systems make choices. The point of the framework is to make those choices deliberate, recorded, and attributable — instead of accidental, undocumented, and discovered eighteen months later by whoever is on call.
This is why the framework is most valuable at the moment of disagreement. When the security lead and the finance lead want different things, “which pillar are we trading away, and who agreed to that?” is a far better question than “is this secure enough?” One is answerable. The other generates a meeting.
What a real Well-Architected review looks like
A useful review is not a solo exercise with a scoring tool. It’s a facilitated conversation, and the structure matters more than the score.
Pick one workload, not the estate. The framework is workload-scoped for a reason. “Review our Azure environment” produces generic findings nobody owns. “Review the claims-processing service” produces specific findings with a named owner and a due date.
Get the right people in the room at the same time. The application owner, the platform engineer, someone from security, and someone who sees the bill. Reviews run asynchronously through a questionnaire lose exactly the thing that makes them valuable — the moment when the person paying and the person on call discover they have different assumptions about the recovery time objective.
Establish the business requirements before you touch the pillars. How much downtime is actually tolerable? What is the data classification? What is the cost ceiling? Without those numbers, every recommendation is unfalsifiable — more redundancy is always “better,” so you either gold-plate or ignore the finding entirely.
Record trade-offs as decisions, not as gaps. This is the step most teams skip. When you consciously accept a single-region deployment because the recovery objective permits it and the budget doesn’t stretch, that’s not a finding to remediate — it’s a decision with a rationale and an owner. Write it down. In two years, when someone asks why this workload isn’t multi-region, the answer exists and nobody re-litigates it from scratch.
Come out with fewer than ten things. A review that generates forty recommendations generates zero changes. Rank ruthlessly and cut the tail.
Where the assessment tool stops helping
Microsoft’s self-assessment is a reasonable starting structure, and it’s free, which makes the price of trying it hard to argue with. Two limits are worth knowing before you build a program around it.
The first is that it measures what you say, not what you run. The assessment asks whether you have backups tested, whether you have alerting on the right signals, whether access follows least privilege. It has no way to check. Teams answer aspirationally — not dishonestly, just optimistically, describing the intended state rather than the deployed one. The output is a picture of your intentions.
The second is that it scores a workload at a point in time, and architecture drifts continuously. A workload that scored well in March, after two quarters of urgent changes, hot-fixed configuration, and one engineer leaving, is not the same workload. Nothing in the assessment notices this.
Both limits point in the same direction. The framework tells you what good looks like; it has no mechanism to make it stay true.
The landing zone is where the answers get enforced
This is where the review stops being a document and starts being architecture.
Most of what a Well-Architected review recommends is platform-level, not application-level: identity and least-privilege access, network segmentation, encryption defaults, backup and recovery posture, cost tagging and budgets, monitoring and log retention, allowed regions. Those are precisely the concerns a governed Azure landing zone owns. Land the workload on a foundation where policy-as-code already enforces them, and a large share of your review findings never occur — not because someone remediated them, but because the platform wouldn’t allow them in the first place.
That inverts the economics of the whole exercise. A review against an ungoverned environment produces per-workload remediation, forever, once per workload. A review against a governed foundation produces a much shorter list, because the platform has already answered the repeatable questions and the review can spend its attention on the genuinely workload-specific ones — the recovery objective, the data model, the scaling behaviour under load.
A review tells you what good looks like. A landing zone is what makes it stay true after everyone stops paying attention.
We saw this play out on a migration for a Canadian public-sector pension plan. They had already been through a high-level assessment with a large consultancy and come out the other side convinced that migration was too complex and risky to attempt — close to postponing cloud adoption for another five years. What changed the outcome wasn’t a better assessment. It was building the thing the assessment kept pointing at: a production-ready, Cloud Adoption Framework–aligned Azure landing zone, deployed as code in under four weeks, with governance, networking, identity and cost controls in place before workloads moved. Infrastructure costs came down by half, and the internal team was trained to run the platform themselves. The architecture review had been correct all along. It just had nowhere to land.
Well-Architected or Cloud Adoption Framework?
This question comes up in every engagement, and the distinction is simpler than the naming suggests. The Cloud Adoption Framework is about the journey — how an organization plans, governs, and operates its move to the cloud, at the estate level. The Well-Architected Framework is about a workload — whether a specific system is designed well for its purpose.
You need both, in that order. CAF gets you a governed foundation and an operating model. WAF is how you evaluate each thing you put on it. Teams that run WAF reviews without a landing zone underneath end up documenting the same five findings over and over across every workload, which is a slow and expensive way to learn that you had a platform problem, not an architecture problem.
Where to start
If you’ve never run a review, don’t start with a program. Start with one workload that matters, four people, two hours, and an honest conversation about what the business actually requires. You’ll learn more from the disagreements in that room than from any score the tool produces.
Then look at what came out of it. If most of your findings are platform concerns — identity, network, backup, cost visibility, region control — that’s your signal. You don’t have five architecture problems across five workloads. You have one foundation problem, and it’s cheaper to fix once than five times.
Deop runs Well-Architected reviews against real Azure estates and builds the governed foundations that make the findings stick — CAF-aligned, as code, with Canadian data residency. See how we approached a public-sector cloud migration or explore our cloud foundation and governance work.