Azure Well-Architected Framework: Run a Review with the Five Pillars

An Azure Well-Architected Review is a structured check of one workload against the five pillars of the Azure Well-Architected Framework: Reliability, Security, Cost Optimization, Operational Excellence and Performance Efficiency. You scope the workload, state its business requirements, work through each pillar's design review checklist, run Microsoft's assessment to get a score and recommendations, and turn the results into a prioritised backlog. This guide shows how to run that process in a few focused sessions.

Who this is for

This is for architects, engineers and technical leads who own a workload running, or about to run, on Azure and want a repeatable way to find design gaps. By the end you will have a scoped review, a record of tradeoffs and a ranked list of improvements that you can re-score later.

What the framework is

Microsoft describes the Azure Well-Architected Framework as a design framework that can improve the quality of a workload by helping it to be resilient, available and recoverable; be as secure as you need it to be; deliver a sufficient return on investment; support responsible development and operations; and accomplish its purpose within acceptable timeframes. Those goals map to five pillars.

Each pillar provides design principles, checklists, key design strategies, tradeoffs, design patterns and a maturity model. The documentation stresses that design decisions must be balanced across all pillars given the business requirements, and that the framework covers architecture, not implementation. Implementation choices depend on your organisation's requirements and constraints.

Step 1: Scope the review

Review a workload, not a subscription or a whole estate. The framework is aimed at teams improving workloads and cross-cutting concerns; Microsoft points to the Cloud Adoption Framework if you want to improve a portfolio of workloads through centralised controls.

Write a one-page scope note:

• Workload name and purpose. What business outcome does it support?
• Components. The Azure services, external dependencies and data stores involved.
• Criticality. How costly is an hour of downtime or a data loss?
• Targets. Availability, recovery time and recovery point objectives, performance goals and budget, if they exist.
• Compliance constraints. Regulations or contractual requirements that apply.
• Participants. Someone with authority to make decisions within the workload's scope. The framework notes that architects, developers, operators and business stakeholders can all benefit if they can make decisions in scope.

If you cannot write down the targets, that is itself your first finding. Many other answers depend on them.

Step 2: Learn the principles before the checklists

Microsoft suggests a learning order: first understand the design principles of every pillar, then prioritise checklist items, then be ready to make tradeoffs, then match workload scenarios, and then select and configure the right services using service guides. Spend an hour on the five principles pages before the workshop, and share them with participants. The principle pages are the foundation; the later layers are harder to follow without them.

Step 3: Walk each pillar's design review checklist

Each pillar has a design review checklist. For each item, record one of: meets, partially meets, does not meet, or not applicable, with a sentence of evidence. Keep evidence concrete, such as a link to a diagram, a policy assignment or a runbook.

A practical way to run the session:

1. Take one pillar at a time and time-box it, for example 45 to 60 minutes.
2. Read each checklist item aloud and ask what the workload does today.
3. Record evidence and any gap. Don't fix things during the workshop.
4. Note which gaps conflict with another pillar, for example redundancy that raises cost.

Prioritise the items relevant to your business goals first. The framework advises addressing the checklist items relevant to your workload and goals, considering business criticality, compliance needs and time to market, and deferring less relevant ones.

Step 4: Run the Azure Well-Architected Review assessment

Microsoft offers the Azure Well-Architected Review as a free assessment, described in the framework documentation as a collection of questionnaires tied to the pillar checklists. The assessment page says it takes about 60 minutes, uses multiple choice and multiple response questions, and returns personalised guidance, recommendations and a score that you can improve by following the recommendations.

To run it:

1. Open the Azure Well-Architected Review from the Microsoft Learn assessments page.
2. Select Start Assessment.
3. Answer the questions with the workload scope in mind, using the evidence you gathered in step 3.
4. Review the results and recommendations, and copy the score and the key recommendations into your own review record so you can compare later runs.

Track the score through iterative runs. Microsoft describes the score as a moving measure that evolves with the workload, not a one-time pass mark. Run the review again after you complete a batch of improvements, and at major changes such as a new region or a new data store.

The same Learn assessments area lists related assessments, such as the Mission Critical Well-Architected Review and the Go-Live Well-Architected Review, for workloads with those needs.

Step 5: Add live signals from Azure Advisor

A questionnaire reflects what people believe about the workload. Azure Advisor adds what the platform observes. The framework documentation says Advisor uses the core pillars as a basis for analysing your resource configuration and usage telemetry and provides recommendations, and that Advisor score aggregates recommendations into a score that can be categorised by pillar, to prioritise the actions that yield the biggest improvement.

Compare the two sources. If the questionnaire says backups are tested and Advisor flags unprotected resources, resolve the contradiction before you record a result.

Step 6: Record tradeoffs and risks

Each pillar page includes tradeoffs, and the framework highlights that adopting a recommendation in one pillar might require a choice against another. Typical examples:

• Zone-redundant deployments improve reliability and raise cost.
• Tighter network isolation improves security and adds operational work.
• Aggressive autoscaling improves performance efficiency and makes costs less predictable.

For each decision, write down the options considered, the choice, the pillar that gave way, and the risk you accepted. Reviewers months later will otherwise treat accepted risks as oversights.

Step 7: Turn findings into a backlog

Convert every gap into a work item with:

• the pillar and checklist item it comes from;
• the business risk if it is not fixed;
• an estimate of effort;
• an owner;
• the metric that proves it is fixed.

The framework recommends a pragmatic approach to avoid analysis paralysis. Evaluate both the value and the cost of each practice, since adopting something too early can cost more and adopting it too late can mean rework, choose a deliberate implementation sequence because some practices are building blocks for others, and be realistic about team capacity.

Use the maturity model to phase the work

The framework includes a five-level maturity model for each pillar.

Microsoft states that these boundaries are guidelines rather than strict rules. A workload early in its funding might target levels 1 and 2 and reserve higher levels for later, while an always-on business-critical workload should aim higher sooner.

Troubleshooting the review process

The workshop turns into a design debate. Park design discussions. The goal of the session is to record the current state, and the fix discussion belongs in backlog refinement.

Everything looks urgent. Rank by the business risk you wrote in the scope note. Items that threaten the stated targets for availability, data protection or compliance go first.

Teams argue over what "meets" means. Require evidence for every answer. If evidence does not exist, the item is "does not meet" until it does.

Scores don't improve between runs. Check that changes actually moved the questionnaire answers, and that your recommendations were implemented, not only planned. Also confirm that you are scoring the same workload scope each time.

Guidance doesn't match your service. The framework includes service guides for individual Azure services and workload guides for specific classes of workload; use them when the general checklist is too coarse.

Checklist

• One workload scoped, with targets and criticality written down.
• Design principles read by all participants.
• All five pillar checklists walked with evidence.
• Azure Well-Architected Review completed and the score saved.
• Azure Advisor recommendations compared with the questionnaire.
• Tradeoffs and accepted risks recorded.
• Backlog created with owners and success metrics.
• Re-review date set.

For a specific pattern that supports the Reliability, Cost Optimization and Performance Efficiency pillars, see Queue-Based Load Leveling with Azure Service Bus.

References

• Microsoft Learn, How to use the Azure Well-Architected Framework documentation: https://learn.microsoft.com/en-us/azure/well-architected/what-is-well-architected-framework
• Microsoft Learn, Azure Well-Architected Framework pillars: https://learn.microsoft.com/en-us/azure/well-architected/pillars
• Microsoft Learn, Azure Well-Architected Review assessment: https://learn.microsoft.com/en-us/assessments/azure-architecture-review/