Azure Well-Architected Review: [Workload name]
Review workbook for one workload running on Microsoft Azure, organised on the five pillars of the Microsoft Azure Well-Architected Framework (Reliability, Security, Cost Optimization, Operational Excellence and Performance Efficiency), as published on Microsoft Learn (hub page dated 11 September 2026). For each pillar it records the design principles, original review questions mapped to the pillar's design review checklist codes (RE:01 to RE:10, SE:01 to SE:12, CO:01 to CO:14, OE:01 to OE:11, PE:01 to PE:12), current state, evidence and a rating. It then covers the workload guidance that applies (AI, Microsoft Fabric, SaaS, mission-critical, HPC or sustainability), the Azure service guides for the services in use, pillar trade-offs, a risk register (high and medium risk), an improvement plan and a re-review record that tracks the Azure Well-Architected Review assessment score. Sustainability is a workload guide in the Azure framework, not a sixth pillar. Replace every [bracketed] value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [AZR-CLAIMS-2026-01] |
| Workload | [Claims processing platform] |
| Subscriptions in scope | [sub-claims-prod, sub-claims-nonprod] |
| Management group and landing zone | [Corp application landing zone under mg-landingzones-corp] |
| Azure regions in scope | [West Europe primary, North Europe secondary] |
| Review type | [Initial / Periodic / Pre-launch / After major incident / Workload guide deep dive] |
| Workload guidance applied | [Mission-critical, AI] |
| Assessment used | [Azure Well-Architected Review on Microsoft Assessments, taken YYYY-MM-DD] |
| Framework pages checked on | YYYY-MM-DD |
| Review date | YYYY-MM-DD |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Owner (workload owner) | [@workload-owner] |
| Lead reviewer | [@lead-reviewer] |
| Approvers/reviewers | [@engineering-manager], [@security-lead], [@platform-lead], [@finops-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Next review | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Date |
|---|
| Workload owner | [@name] | [Accepted plan / Changes requested] | YYYY-MM-DD |
| Lead reviewer (solution architect) | [@name] | [Decision] | YYYY-MM-DD |
| Security representative | [@name] | [Decision] | YYYY-MM-DD |
| Platform team (landing zone owner) | [@name] | [Decision] | YYYY-MM-DD |
| FinOps representative | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | Pre-review questionnaire filled by the workload team |
| 0.2 | YYYY-MM-DD | [@name] | Example: Ratings after review session; 5 High, 12 Medium; assessment score recorded as R-001 |
| 1.0 | YYYY-MM-DD | [@name] | Example: Improvement plan approved |
| 1.1 | YYYY-MM-DD | [@name] | Example: Re-review; 0 High, 7 Medium; assessment retaken as R-002 |
Contents
1. Review scope and method
1.1 Scope
| In scope | Out of scope |
|---|
| Example: Claims API on Azure Kubernetes Service, Azure SQL Database, Azure Service Bus, Azure Functions and the deployment pipeline | Hub network, Azure Firewall and DNS in the connectivity subscription (owned by the platform team, reviewed against the Landing zone design, architecture/landing-zone-design) |
| Example: Non-production subscription where it affects release safety | Microsoft Entra ID tenant configuration |
| [Item] | [Item] |
1.2 Method
- The workload team fills sections 2 and 3, takes the Azure Well-Architected Review assessment and pre-fills the questions in sections 4 to 10 with links to evidence.
- The lead reviewer runs a session of [half a day] with the workload owner, an engineer who operates the system, a security representative, the platform team and FinOps.
- Each question gets a current-state description, evidence and a rating. Azure Advisor recommendations, Azure Policy compliance results and Microsoft Defender for Cloud findings are used as evidence where they exist.
- High and Medium findings go to the risk register (section 11) and the improvement plan (section 12). Findings owned by the platform team are raised to them with a reference.
- After the actions close, the assessment is retaken and the score recorded (section 13).
1.3 Rating scale and identifiers
| Rating | Meaning | Expected response |
|---|
| High risk | Gap that can plausibly cause serious customer, financial, security or compliance impact within 12 months | Action this quarter, or signed acceptance |
| Medium risk | Gap that raises impact or effort but is unlikely to cause a severe event alone | Action within two quarters |
| None | Practice in place with evidence | No action |
| Not applicable | Does not apply, with a stated reason | Reason recorded |
Questions use AZR-[pillar]-NN with the pillar codes Microsoft uses in its checklists (RE, SE, CO, OE, PE), plus AZR-WL-NN for workload guidance and AZR-SVC-NN for service guides. The column "Checklist code" gives the related recommendation, such as RE:04. Findings use FND-NNN, actions ACT-NNN, acceptances RA-NNN and assessment results R-NNN.
2. Workload definition
2.1 Business context
| Item | Value |
|---|
| Purpose | Example: Receives, validates and settles insurance claims from web, partner API and call centre channels |
| Users and consumers | Example: 120,000 policyholders per month, 40 partner brokers, 300 internal handlers |
| Business criticality | Example: Business critical; regulatory deadlines on claim acknowledgement |
| Regulatory context | Example: EU data protection, insurance supervisory guidelines on outsourcing and ICT risk |
| Landing zone and governance | Example: Application landing zone with Azure Policy initiatives assigned at management group level |
| Change frequency | Example: Weekly releases, monthly platform updates |
| Architecture link | [Solution architecture, architecture/solution-architecture] |
2.2 Critical flows and targets
| Flow ID | Flow | Criticality | Availability target | Latency target | RTO | RPO |
|---|
| FLW-01 (Example) | Submit claim (web and partner API) | High | 99.95% monthly | p95 below 800 ms | 1 hour | 5 minutes |
| FLW-02 (Example) | Handler works a claim | Medium | 99.9% in business hours | p95 below 1.5 s | 4 hours | 15 minutes |
| FLW-03 (Example) | Nightly settlement batch | Medium | Completes by 06:00 | Not applicable | 6 hours | 1 hour |
| FLW-04 (Example) | Reporting export | Low | Best effort | Not applicable | 24 hours | 24 hours |
| [FLW-NN] | [Flow] | [High / Medium / Low] | [Target] | [Target] | [RTO] | [RPO] |
Record the service level objectives in the SLO document (dev/slo-doc) and the recovery strategy in the Resilience tiering design (architecture/resilience-tiering-ha-dr-design).
2.3 Architecture summary
| Layer | Services and configuration |
|---|
| Ingress and edge | Example: Azure Front Door with WAF policy, Azure API Management for partners |
| Compute | Example: Azure Kubernetes Service across availability zones; Azure Functions for document processing |
| Data | Example: Azure SQL Database (zone redundant, failover group to secondary region); Azure Blob Storage for documents |
| Integration | Example: Azure Service Bus Premium with geo-disaster recovery alias |
| Identity and secrets | Example: Microsoft Entra ID, managed identities, Azure Key Vault |
| Observability | Example: Azure Monitor, Application Insights, Log Analytics workspace in the management subscription |
| Delivery | Example: Bicep modules, pipeline with environment approvals |
3. Framework, guidance and tools
3.1 Framework structure
The Azure Well-Architected Framework is organised as five pillars, each with design principles, a design review checklist of coded recommendations, recommendation guides and a trade-offs page. Around them sit workload guidance for classes of workload, service guides for individual Azure services, design guides for cross-cutting topics (for example capacity resilience) and review tools. The framework assumes the workload sits in a governed platform, typically an Azure landing zone built with the Cloud Adoption Framework, and divides responsibility between the workload team and central teams.
| Pillar | Checklist codes | Pages checked (date) |
|---|
| Reliability | RE:01 to RE:10 | [Principles, checklist, trade-offs, YYYY-MM-DD] |
| Security | SE:01 to SE:12 | [YYYY-MM-DD] |
| Cost Optimization | CO:01 to CO:14 | [YYYY-MM-DD] |
| Operational Excellence | OE:01 to OE:11 | [YYYY-MM-DD] |
| Performance Efficiency | PE:01 to PE:12 | [YYYY-MM-DD] |
The checklist counts above match the Microsoft Learn checklist pages as checked on 23 October 2026; check them again before each review, because Microsoft renumbers or merges recommendations when it revises a pillar.
3.2 Workload guidance selection
| Workload guidance | Apply? | Reason |
|---|
| Artificial intelligence (AI) | [Yes / No] | Example: Yes: document classification uses a hosted model |
| Microsoft Fabric | [Yes / No] | [Reason] |
| Software as a service (SaaS) | [Yes / No] | Pair with Multi-tenancy design (architecture/multi-tenancy-design) |
| Mission-critical | [Yes / No] | Example: Yes: claim submission has regulatory deadlines |
| High-performance computing (HPC) | [Yes / No] | [Reason] |
| Sustainability | [Yes / No] | Pair with Sustainability architecture assessment (architecture/sustainability-architecture-assessment) |
3.3 Tools and evidence sources
| Tool | Use in this review | Status |
|---|
| Azure Well-Architected Review (Microsoft Assessments) | Self-assessment across the five pillars; gives an overall score and per-category guidance; results can be shared or exported to CSV when signed in | [Taken YYYY-MM-DD, result R-001] |
| Azure Advisor and Advisor score | Resource-level recommendations grouped by the pillars, used as evidence | [Score, date] |
| Azure Policy compliance | Evidence for guardrails inherited from the landing zone | [Initiatives, compliance %] |
| Microsoft Defender for Cloud | Security posture findings and recommendations | [Findings count] |
| Azure Monitor and Application Insights | Health model, availability and latency evidence per flow | [Workbook link] |
| Azure Cost Management | Cost data, budgets and anomaly alerts | [Report link] |
4. Reliability
4.1 Design principles
| Azure design principle | What the reviewer looks for |
|---|
| Design for business requirements | Reliability outcomes agreed per critical flow, with time horizons, dependencies and constraints known |
| Design for resilience | Critical path separated from degradable components, failure points identified, redundancy and scale-out where needed |
| Design for recovery | Documented, rehearsed recovery plans, repairable data and self-healing for transient faults |
| Design for operations | Correlated observability, predictive and actionable alerts, failure simulation and learning from incidents |
| Keep it simple | A lean critical path, standards in code and process, and platform features preferred over custom builds |
4.2 Review questions
| ID | Question | Checklist code | Current state | Evidence | Rating |
|---|
| AZR-RE-01 | Has each component on the critical path been challenged for necessity, and have unneeded parts been removed? | RE:01 | [State] | [Evidence] | [Rating] |
| AZR-RE-02 | Are user and system flows listed and rated by criticality, and does the rating drive design effort? | RE:02 | Example: Flows listed in section 2.2, ratings not yet used in design | Flow catalogue | Medium |
| AZR-RE-03 | Has a failure mode analysis been done for each critical flow, covering dependencies such as identity, DNS and the hub network? | RE:03 | [State] | [Evidence] | [Rating] |
| AZR-RE-04 | Are availability, RTO and RPO targets defined per flow, composed from the SLAs of the services used, and reflected in a health model? | RE:04 | [State] | [Evidence] | [Rating] |
| AZR-RE-05 | Is redundancy in place at the levels the targets need (zones, regions, instances), with no single-zone component left on a high-criticality flow? | RE:05 | Example: The Redis cache instance is not zone redundant | Resource configuration | High |
| AZR-RE-06 | Does each tier scale automatically on measured signals, within known quota and regional capacity limits? | RE:06 | [State] | [Evidence] | [Rating] |
| AZR-RE-07 | Do components protect themselves (retries with backoff, circuit breakers, bulkheads, queue-based load levelling) and heal automatically? | RE:07 | [State] | [Evidence] | [Rating] |
| AZR-RE-08 | Are fault injection and load tests run on a schedule, including a zone outage and a dependency outage? | RE:08 | [State] | Chaos experiment (ops/chaos-experiment) | [Rating] |
| AZR-RE-09 | Is there a disaster recovery plan for the whole workload, tested end to end within the past 12 months, including failback? | RE:09 | [State] | Disaster recovery plan (ops/disaster-recovery-plan) | [Rating] |
| AZR-RE-10 | Is health measured per flow with retained data, and do alerts reach the owning team in time to act? | RE:10 | [State] | [Evidence] | [Rating] |
5. Security
5.1 Design principles
| Azure design principle | What the reviewer looks for |
|---|
| Plan your security readiness | A security plan tied to business priorities, segmentation, role-based training, compliance requirements and alignment with the security operations centre |
| Design to protect confidentiality | Need-to-know access, classification, encryption, exfiltration controls and an audit trail |
| Design to protect integrity | Strong authentication and authorisation, supply chain protection, cryptographic verification and immutable backups |
| Design to protect availability | Limits on compromised identities, protection from resource exhaustion, prioritised controls on critical flows and secure recovery |
| Sustain and evolve your security posture | Asset inventory, threat modelling, posture measurement, periodic testing and staying current on patches |
5.2 Review questions
| ID | Question | Checklist code | Current state | Evidence | Rating |
|---|
| AZR-SE-01 | Is there a written security baseline for the workload, derived from compliance needs and platform guidance, and is drift measured against it? | SE:01 | [State] | [Evidence] | [Rating] |
| AZR-SE-02 | Does the development lifecycle include threat modelling, secure coding standards and security gates in the pipeline? | SE:02 | [State] | Threat model (security/threat-model) | [Rating] |
| AZR-SE-03 | Are data and systems labelled by sensitivity, and do the labels drive storage, access and monitoring decisions? | SE:03 | [State] | [Evidence] | [Rating] |
| AZR-SE-04 | Are segmentation boundaries designed on purpose across subscriptions, resource groups, networks, roles and workload identities? | SE:04 | [State] | [Evidence] | [Rating] |
| AZR-SE-05 | Do people and services authenticate with Microsoft Entra ID (managed identities for services), with conditional access, least privilege and just-in-time elevation? | SE:05 | Example: Three service principals use client secrets; standing Owner role for two engineers | Role assignment export | High |
| AZR-SE-06 | Is inbound and outbound traffic filtered at every boundary, with private endpoints for platform services and controlled egress? | SE:06 | [State] | [Evidence] | [Rating] |
| AZR-SE-07 | Is data encrypted at rest and in transit with platform-native methods, and are customer-managed keys used where classification requires? | SE:07 | [State] | [Evidence] | [Rating] |
| AZR-SE-08 | Are compute, containers and services hardened (minimal images, disabled unused features, secure configuration baselines)? | SE:08 | [State] | [Evidence] | [Rating] |
| AZR-SE-09 | Are secrets, keys and certificates held in Azure Key Vault, access-audited and rotated on a schedule and on demand? | SE:09 | [State] | [Evidence] | [Rating] |
| AZR-SE-10 | Are threat detection signals collected and sent to the security operations process with a defined triage path? | SE:10 | [State] | [Evidence] | [Rating] |
| AZR-SE-11 | Is there a testing programme that combines scanning, penetration tests and validation that detection actually fires? | SE:11 | [State] | [Evidence] | [Rating] |
| AZR-SE-12 | Are incident response procedures written for this workload, with named owners, and exercised? | SE:12 | [State] | Incident response plan (compliance/incident-response-plan) | [Rating] |
Record design detail in the Security architecture (security/security-architecture) and the Zero trust architecture (security/zero-trust-architecture).
6. Cost Optimization
6.1 Design principles
| Azure design principle | What the reviewer looks for |
|---|
| Develop cost-management discipline | A cost model, an accountability model with roles, realistic budgets and communicated cost impact of changes |
| Design with a cost-efficiency mindset | A cost baseline including growth, guardrails in the architecture and environments sized to their purpose |
| Design for usage optimization | Full use of what is paid for, dynamic capacity and committed resources used for new needs |
| Design for rate optimization | Commitment discounts for stable usage, licence benefits, the right billing model and cheaper regions where requirements allow |
| Monitor and optimize over time | Expense captured and classified, budget alerts, regular architecture reviews and decommissioning |
6.2 Review questions
| ID | Question | Checklist code | Current state | Evidence | Rating |
|---|
| AZR-CO-01 | Do engineers see the cost of their choices, with training and tooling to act on it? | CO:01 | [State] | [Evidence] | [Rating] |
| AZR-CO-02 | Is there a cost model with initial, run-rate and growth estimates, and a budget with a buffer? | CO:02 | [State] | TCO analysis (architecture/tco-analysis) | [Rating] |
| AZR-CO-03 | Is cost data collected daily, reviewed against the model, and are anomaly alerts in place? | CO:03 | [State] | [Evidence] | [Rating] |
| AZR-CO-04 | Are spending guardrails in place (policies on SKUs and regions, budgets, release gates)? | CO:04 | [State] | [Evidence] | [Rating] |
| AZR-CO-05 | Are reservations, savings plans and licence benefits used for steady usage, and reviewed regularly? | CO:05 | Example: No commitments on steady AKS node pools | Cost Management report | Medium |
| AZR-CO-06 | Is resource usage aligned to how each service is metered, and were major cost drivers validated by a proof of concept? | CO:06 | [State] | [Evidence] | [Rating] |
| AZR-CO-07 | Are unused or legacy components, features and resources identified and removed? | CO:07 | [State] | [Evidence] | [Rating] |
| AZR-CO-08 | Are non-production environments sized, scheduled and licensed differently from production on purpose? | CO:08 | [State] | [Evidence] | [Rating] |
| AZR-CO-09 | Is spend per flow proportional to the flow's criticality? | CO:09 | [State] | [Evidence] | [Rating] |
| AZR-CO-10 | Do data stores use tiering, retention, right-sized replication and efficient formats? | CO:10 | [State] | [Evidence] | [Rating] |
| AZR-CO-11 | Has code been profiled for expensive paths, such as chatty calls or oversized payloads? | CO:11 | [State] | [Evidence] | [Rating] |
| AZR-CO-12 | Is scaling configured against the cost model, with limits and scale-in that actually happens? | CO:12 | [State] | [Evidence] | [Rating] |
| AZR-CO-13 | Is time spent on builds, debugging and operational noise measured and reduced? | CO:13 | [State] | [Evidence] | [Rating] |
| AZR-CO-14 | Are resources consolidated where safe, and are shared central services used instead of duplicates? | CO:14 | [State] | [Evidence] | [Rating] |
Review spend with the FinOps cost review (ops/finops-cost-review).
7. Operational Excellence
7.1 Design principles
| Azure design principle | What the reviewer looks for |
|---|
| Embrace DevOps culture | Shared tools and backlog, blameless learning, clear ownership and use of central operations skills |
| Establish development standards | Documented requirements, a tuned methodology, unified source control, early quality assurance and style standards |
| Evolve operations with observability | A separate monitoring stack, consistent instrumentation, the right signal for each purpose and actionable alerts |
| Automate for efficiency | Workflows evaluated for automation value, build-or-buy decisions recorded, automation treated as a critical dependency |
| Adopt safe deployment practices | IaC for all infrastructure, small frequent changes, automated pipelines, progressive exposure and a ready fix-forward path |
7.2 Review questions
| ID | Question | Checklist code | Current state | Evidence | Rating |
|---|
| AZR-OE-01 | Are roles, responsibilities and standard practices for building and running the workload written down, with a blameless improvement culture? | OE:01 | [State] | [Evidence] | [Rating] |
| AZR-OE-02 | Are routine, ad hoc and emergency operations standardised as runbooks with clear triggers? | OE:02 | [State] | Runbook (dev/runbook) | [Rating] |
| AZR-OE-03 | Is the development process from idea to release visible to the team and stakeholders? | OE:03 | [State] | [Evidence] | [Rating] |
| AZR-OE-04 | Are tools, source control, design patterns, documentation and style guides standardised across the team? | OE:04 | [State] | [Evidence] | [Rating] |
| AZR-OE-05 | Is all infrastructure defined in modular, reviewed IaC (Bicep or Terraform), with drift detected? | OE:05 | Example: Network rules changed in the portal during incidents and not back-ported | Activity log | High |
| AZR-OE-06 | Do all changes pass through automated pipelines with tests and gates in every environment? | OE:06 | [State] | [Evidence] | [Rating] |
| AZR-OE-07 | Does the monitoring stack capture metrics, logs and traces from infrastructure and code, correlated per flow? | OE:07 | [State] | Observability specification (ops/observability-spec) | [Rating] |
| AZR-OE-08 | Is there an incident management process with roles, severities, communication and post-incident review? | OE:08 | [State] | [Evidence] | [Rating] |
| AZR-OE-09 | Does the testing strategy cover functional, integration, performance and resilience tests tied to business objectives? | OE:09 | [State] | [Evidence] | [Rating] |
| AZR-OE-10 | Is operational automation itself versioned, tested, secured and monitored? | OE:10 | [State] | [Evidence] | [Rating] |
| AZR-OE-11 | Are releases small and progressive (rings, canary, feature flags) with defined rollback and an emergency path? | OE:11 | [State] | Deployment runbook (ops/deployment-runbook) | [Rating] |
8. Performance Efficiency
8.1 Design principles
| Azure design principle | What the reviewer looks for |
|---|
| Negotiate realistic performance targets | Targets agreed with business owners per flow, informed by measurement and historical data |
| Design to meet capacity requirements | Elasticity needs per flow, right-sized resources, capacity planning and a proof of concept for risky choices |
| Achieve and sustain performance | A testing strategy, performance gates, end-to-end monitoring and a backlog for degradation |
| Optimize for long-term improvement | Time reserved for optimisation, targets revisited from production data and new platform features adopted |
8.2 Review questions
| ID | Question | Checklist code | Current state | Evidence | Rating |
|---|
| AZR-PE-01 | Does every flow in section 2.2 have a numeric performance target agreed with the business? | PE:01 | [State] | [Evidence] | [Rating] |
| AZR-PE-02 | Is capacity planned ahead of known demand changes (seasonal peaks, campaigns, regulatory deadlines)? | PE:02 | [State] | Capacity plan (ops/capacity-plan) | [Rating] |
| AZR-PE-03 | Were services and tiers selected against the targets and expected capacity, comparing platform features with custom builds? | PE:03 | [State] | ADR (architecture/adr-full) | [Rating] |
| AZR-PE-04 | Is performance measured consistently against baselines so that degradation is detected? | PE:04 | [State] | [Evidence] | [Rating] |
| AZR-PE-05 | Is there a defined scale unit, and are data and compute partitioned to scale out predictably? | PE:05 | [State] | [Evidence] | [Rating] |
| AZR-PE-06 | Are load tests run regularly in a production-like environment, for example with Azure Load Testing in the pipeline? | PE:06 | Example: Last load test before launch, 11 months ago | Test report | Medium |
| AZR-PE-07 | Does code offload work to platform features and avoid unnecessary processing? | PE:07 | [State] | [Evidence] | [Rating] |
| AZR-PE-08 | Are data stores, partitions and indexes tuned to actual query patterns? | PE:08 | [State] | [Evidence] | [Rating] |
| AZR-PE-09 | When resources are constrained, do critical flows get priority over lower ones? | PE:09 | [State] | [Evidence] | [Rating] |
| AZR-PE-10 | Are routine operations (backups, index rebuilds, secret rotations, deployments) scheduled or designed to limit performance impact? | PE:10 | [State] | [Evidence] | [Rating] |
| AZR-PE-11 | Is there a process for live performance incidents, with owners, communication and preventive follow-up? | PE:11 | [State] | [Evidence] | [Rating] |
| AZR-PE-12 | Are components that degrade over time (databases, networking) reviewed and optimised on a schedule? | PE:12 | [State] | [Evidence] | [Rating] |
9. Workload guidance review
| ID | Workload guide | Question | Pillars affected | Current state | Evidence | Rating |
|---|
| AZR-WL-01 (Example) | Mission-critical | Is the workload built from independent scale units (stamps) that can be deployed and replaced without affecting others? | Reliability, Performance Efficiency | Single shared AKS cluster per region | Architecture diagram | Medium |
| AZR-WL-02 (Example) | Mission-critical | Is there a health model that combines application, platform and dependency signals into a healthy, degraded or unhealthy state per flow? | Reliability, Operational Excellence | Component dashboards only | Workbook | High |
| AZR-WL-03 (Example) | Mission-critical | Is the deployment approach able to replace infrastructure as well as code without downtime? | Operational Excellence | Code only | Pipeline | Medium |
| AZR-WL-04 (Example) | AI | Are model versions pinned, evaluated before change and monitored for quality drift? | Operational Excellence, Reliability | Pinned, not evaluated | Model registry | Medium |
| AZR-WL-05 (Example) | AI | Are prompts and grounding data protected from injection and oversharing, and is content filtering configured? | Security | Filtering at default level | Configuration | Medium |
| AZR-WL-06 (Example) | Sustainability | Is there a carbon or energy proxy metric per transaction with a baseline? | Cost Optimization, Performance Efficiency | None | None | Medium |
| [AZR-WL-NN] | [Guide] | [Question] | [Pillars] | [State] | [Evidence] | [Rating] |
For AI workloads, record model risk and evaluation in the GenAI Well-Architected review (architecture/genai-well-architected-review).
10. Service guide review
| ID | Service | Service guide checked (date) | Deviation found | Pillar | Decision | Rating |
|---|
| AZR-SVC-01 (Example) | Azure Kubernetes Service | YYYY-MM-DD | System and user node pools share one pool; no zone spread for user pool | Reliability | Split pools, enable zones | High |
| AZR-SVC-02 (Example) | Azure SQL Database | YYYY-MM-DD | Failover group configured, read-only endpoint unused | Performance Efficiency | Route reporting reads to secondary | Medium |
| AZR-SVC-03 (Example) | Azure Service Bus | YYYY-MM-DD | Geo-disaster recovery alias covers metadata only; message replication not designed | Reliability | Evaluate moving from Geo-DR to Service Bus Geo-Replication (Premium tier; replicates metadata and message data, synchronous or asynchronous mode) to meet the 5-minute RPO of FLW-01; otherwise document the message loss tolerance for FLW-01 | Medium |
| AZR-SVC-04 (Example) | Azure Front Door | YYYY-MM-DD | WAF in detection mode | Security | Switch to prevention after tuning | High |
| AZR-SVC-05 (Example) | Azure Key Vault | YYYY-MM-DD | Public network access enabled | Security | Private endpoint, disable public access | Medium |
| [AZR-SVC-NN] | [Service] | YYYY-MM-DD | [Deviation] | [Pillar] | [Decision] | [Rating] |
11. Risk register and trade-offs
11.1 Findings
| Finding ID | Question | Pillar | Risk | Finding | Business impact | Owner team | Response |
|---|
| FND-001 (Example) | AZR-RE-05 | Reliability | High | Single-zone cache on FLW-01 | Zone loss stops claim submission | Workload | ACT-001 |
| FND-002 (Example) | AZR-SE-05 | Security | High | Client secrets and standing Owner role | Credential theft gives full control | Workload | ACT-002 |
| FND-003 (Example) | AZR-OE-05 | Operational Excellence | High | Portal changes to network rules | Drift breaks DR deployment | Workload and platform | ACT-003 |
| FND-004 (Example) | AZR-WL-02 | Mission-critical | High | No health model | Slow detection and wrong failover decisions | Workload | ACT-004 |
| FND-005 (Example) | AZR-SVC-04 | Security | High | WAF in detection mode | Attacks reach the API | Workload | ACT-005 |
| FND-006 (Example) | AZR-CO-05 | Cost Optimization | Medium | No commitments for steady nodes | Overspend on steady compute | Workload and FinOps | ACT-006 |
| FND-007 (Example) | AZR-PE-06 | Performance Efficiency | Medium | No recent load test | Peak failures undetected | Workload | ACT-007 |
| FND-008 (Example) | AZR-WL-06 | Sustainability workload guide | Medium | No carbon or energy baseline | Sustainability goal cannot be tracked | Workload | RA-001 |
| [FND-NNN] | [AZR-ID] | [Pillar] | [High / Medium] | [Finding] | [Impact] | [Team] | [ACT-NNN / RA-NNN] |
The Example rows show a subset; the completed register lists every question rated High or Medium in the sections above.
11.2 Summary by pillar
| Pillar or area | High | Medium | None | Not applicable |
|---|
| Reliability | [n] | [n] | [n] | [n] |
| Security | [n] | [n] | [n] | [n] |
| Cost Optimization | [n] | [n] | [n] | [n] |
| Operational Excellence | [n] | [n] | [n] | [n] |
| Performance Efficiency | [n] | [n] | [n] | [n] |
| Workload guidance | [n] | [n] | [n] | [n] |
| Service guides | [n] | [n] | [n] | [n] |
| Total | [n] | [n] | [n] | [n] |
11.3 Trade-off decisions
| Decision | Pillar favoured | Pillar affected | Rationale | Decided by |
|---|
| Example: Active-passive secondary region instead of active-active | Cost Optimization | Reliability (RTO 1 hour, not near zero) | Business owner accepted 1 hour RTO for FLW-01 | [@workload-owner] |
| Example: Private endpoints for all PaaS services | Security | Operational Excellence, Reliability (DNS dependency) | Classification requires private access; DNS failover tested | [@security-lead] |
| [Decision] | [Pillar] | [Pillar] | [Rationale] | [@name] |
Escalate long-lived risks to the Risk register (compliance/risk-register).
12. Improvement plan
12.1 Action backlog
| Action ID | Finding | Action | Owner | Effort | Target date | Acceptance criterion | Status |
|---|
| ACT-001 (Example) | FND-001 | Move cache to a zone-redundant tier | [@dev-lead] | S | YYYY-MM-DD | Zone failure drill keeps FLW-01 within target | [Open] |
| ACT-002 (Example) | FND-002 | Replace secrets with managed identities; move Owner to just-in-time elevation | [@platform-eng] | M | YYYY-MM-DD | No client secrets; no standing Owner assignments | [Open] |
| ACT-003 (Example) | FND-003 | Back-port network rules to IaC; deny portal writes by policy except break-glass | [@platform-eng] | M | YYYY-MM-DD | Drift report empty for 30 days | [Open] |
| ACT-004 (Example) | FND-004 | Build a layered health model for FLW-01 and FLW-02 | [@sre-lead] | L | YYYY-MM-DD | Health state drives alerting and failover runbook | [Open] |
| ACT-005 (Example) | FND-005 | Tune WAF rules and switch to prevention mode | [@security-eng] | S | YYYY-MM-DD | Prevention mode for 14 days without false-positive incidents | [Open] |
| ACT-006 (Example) | FND-006 | Buy commitments for baseline node pools | [@finops] | S | YYYY-MM-DD | Commitment coverage at agreed level | [Open] |
| ACT-007 (Example) | FND-007 | Add a load test stage with pass criteria per flow | [@qa-lead] | M | YYYY-MM-DD | Pipeline fails when p95 exceeds target | [Open] |
| [ACT-NNN] | [FND-NNN] | [Action] | [@owner] | [S / M / L] | YYYY-MM-DD | [Criterion] | [Status] |
12.2 Responsibilities
| Activity | Workload owner | Lead reviewer | Workload team | Platform team | Security | FinOps |
|---|
| Approve scope and guides | A | R | C | C | C | C |
| Provide evidence | A | C | R | R | R | R |
| Rate and record findings | C | A/R | C | C | C | C |
| Prioritise and fund actions | A/R | C | C | C | C | C |
| Implement workload actions | A | I | R | C | C | C |
| Implement platform actions | C | I | C | A/R | C | I |
| Retake assessment and report | A | R | C | I | I | I |
R = responsible, A = accountable, C = consulted, I = informed.
13. Re-review and progress record
13.1 Progress record
| Result ID | Date | Assessment overall score | Weakest category | High open | Medium open | Notes |
|---|
| R-001 (Example) | YYYY-MM-DD | [Score] | [Category] | 5 | 12 | Baseline; CSV export stored in [location] |
| R-002 (Example) | YYYY-MM-DD | [Score] | [Category] | 0 | 7 | ACT-001 to ACT-005 closed |
| [R-NNN] | YYYY-MM-DD | [Score] | [Category] | [n] | [n] | [Notes] |
13.2 Re-review triggers
- The scheduled interval is reached ([every 6 months for business critical, 12 months for others]).
- A major change: new region, new data store, change of compute platform or a new workload class (for example adding AI features).
- A Severity 1 incident, a failed disaster recovery test or a security incident.
- A significant revision of a pillar checklist or workload guide on Microsoft Learn.
- A change in regulation or contract that alters the targets in section 2.2.
14. Risk acceptance and sign-off
14.1 Accepted risks
| Acceptance ID | Finding | Reason | Compensating control | Accepted by | Expiry |
|---|
| RA-001 (Example) | FND-008 | Organisation-level carbon reporting arrives next quarter | Cost right-sizing reduces footprint meanwhile | [@workload-owner] | YYYY-MM-DD |
| [RA-NNN] | [FND-NNN] | [Reason] | [Control] | [@name] | YYYY-MM-DD |
14.2 Review conclusion
| Item | Value |
|---|
| Overall conclusion | [Ready for production / Ready with conditions / Not ready] |
| Conditions | [Each linked to an action] |
| Go-live link | [Go-live readiness review, project/go-live-readiness-review, if pre-launch] |
| Next review date | YYYY-MM-DD |
15. Glossary and references
15.1 Glossary
| Term | Meaning in this document |
|---|
| Pillar | One of the five areas of the Azure Well-Architected Framework |
| Design review checklist | The coded list of recommendations per pillar (for example RE:01) on Microsoft Learn |
| Workload guidance | Guidance for a class of workload (AI, Microsoft Fabric, SaaS, mission-critical, HPC, sustainability) |
| Service guide | Guidance for configuring one Azure service against the pillars |
| Flow | A user or system path through the workload, rated by criticality |
| Scale unit | A group of resources that scale together as one unit of capacity |
| Application landing zone | Subscriptions dedicated to a workload inside a governed Azure landing zone |
| Advisor score | Azure Advisor's aggregate of its recommendations, which can be viewed by pillar |
15.2 References
| Reference | Version or date | Use |
|---|
| Microsoft Azure Well-Architected Framework hub, learn.microsoft.com/azure/well-architected | Page dated 2026-09-11 | Structure, pillars, workloads, service guides |
| Pillars overview page | Page dated 2025-01-22 | Five pillars, assessment and Advisor links |
| Pillar design principles and design review checklist pages | Checked 2026-10-23 (dates per page) | Sections 4 to 8 |
| Workload guidance page | Page dated 2025-08-12 | Section 9, shared responsibility |
| Service guides hub | Updated 2026-10-01 | Section 10 |
| Azure Service Bus Geo-Replication, learn.microsoft.com/azure/service-bus-messaging/service-bus-geo-replication | Page dated 2026-08-24 | AZR-SVC-03 |
| Microsoft Assessments, Azure Well-Architected Review and FAQ | FAQ dated 2026-08-10 | Section 13 |
| Related templates | Current | Cloud architecture review (architecture/cloud-architecture-review), AWS Well-Architected review (architecture/aws-well-architected-review), Google Cloud Well-Architected review (architecture/google-well-architected-review), Cloud adoption strategy (architecture/cloud-adoption-strategy) |
Standard and licence note
Structure aligned with the five pillars, design principles, design review checklist codes, workload guidance, service guides and review tools of the Microsoft Azure Well-Architected Framework as published on Microsoft Learn and checked on 23 October 2026. Pillar, principle, workload and service names and checklist codes are used for mapping only. The review questions, ratings, guidance and examples are original text written for this collection and do not reproduce Microsoft's checklist or recommendation wording. Check the current official pages before each review; Microsoft updates the framework frequently and dates each page separately. Microsoft, Azure and the products named are trademarks of their owners; this template is not affiliated with or endorsed by them. Template licence: MIT.