Applies toAny production workload on Azure; Azure Well-Architected Framework pillars, Well-Architected Review assessment, Azure Advisor, Resource Graph
Why bother
Workloads drift: quick fixes, new features, team changes. A structured review every 12 months (or before a big change) finds the risks that the next incident would otherwise find.
1. Scope
- One workload, with its owner, critical user flows and business targets (availability, RTO/RPO, performance).
- In scope: all resources the workload depends on, including shared ones (networking, identity, monitoring).
- Time-box: preparation (1–2 days), review session (2–3 hours), write-up (1 day).
2. Gather evidence first
| Evidence | Source |
|---|---|
| Architecture diagram (current, not the original design) | Owner + Resource Graph |
| Resource inventory with SKUs, zones, regions | Resource Graph query |
| Advisor recommendations | Azure Advisor export |
| Incidents in the last 12 months | ITSM tool, postmortems |
| Monitoring and alerts | Alert rules, dashboards |
| Backup/DR configuration and last test | Backup reports, DR drill records |
| Cost trend | Cost Management |
| Security posture | Defender for Cloud secure score / recommendations |
resources
| where resourceGroup in~ ("rg-orders-prod", "rg-orders-data")
| project name, type, location, sku = tostring(sku.name), zones, tags
| order by type asc
3. Walk the pillars with concrete questions
| Pillar | Questions that find real risks |
|---|---|
| Reliability | What happens if one zone fails? Single instances anywhere? Last DR test and its result? Health probes meaningful? Retry/timeouts in code? |
| Security | Secrets in code or config? Public endpoints needed? Who has standing admin access? Managed identities used? WAF in front of public apps? |
| Cost optimization | Idle or oversized resources? Non-prod running 24×7? Reservations/savings plans for steady use? Log ingestion trend? |
| Operational excellence | Is everything deployed by IaC/pipelines? Runbooks for top failures? Alerts actionable and owned? How long does a rollback take? |
| Performance efficiency | Load tested recently? Autoscale configured and tested? Known bottlenecks (database, cache)? Performance SLOs measured? |
The Microsoft Well-Architected Review assessment provides a full question set if you want structure and a scored report.
4. Rate findings
| Rating | Meaning | Example |
|---|---|---|
| High | Likely to cause an outage, breach or data loss | No backup on the database; single-instance VM for a Tier 1 app |
| Medium | Increases impact or recovery time | Alerts without runbooks; manual deployments |
| Low | Improvement | Old VM generation; tagging gaps |
Each finding: description, evidence, risk, recommendation, effort estimate, suggested owner.
5. Turn it into work
- Findings go into the owning team's backlog, not a PDF.
- High-risk items get dates; review progress in 30/60/90 days.
- Accepted risks are recorded with the business owner's sign-off.
6. Make it repeatable
- Keep the evidence queries and checklist in a repo; reuse for the next workload.
- Track findings across workloads. Repeated themes (e.g. "no DR tests") point to platform-level fixes.
Tip
Invite the people who get paged for the workload. They know where it really hurts, and their findings are often more valuable than any checklist.
Checklist
- Workload, owner and targets scoped
- Evidence gathered before the session
- Five pillars walked with concrete questions
- Findings rated with evidence and owners
- Backlog items with dates; accepted risks signed off
- Follow-up review scheduled