Azure Well-Architected review
Perform an evidence-based five-pillar review and return prioritized, IaC-first findings.
When to invoke
- Review an Azure workload against the Well-Architected Framework.
- Assess Azure IaC before production or a major change.
- Compare deployed resources with intended IaC and identify drift.
- Prepare WAF findings or an approved issue backlog.
Prerequisites and context
Confirm subscription/resource-group scope, environments, business criticality, workload owners,
recovery objectives, data classification, cost constraints, and review time window.
Procedure
- Confirm scope and load current Microsoft WAF guidance plus service-specific recommendations.
- Inspect
**/*.bicep, **/*.tf, and ARM template JSON for the intended architecture.
- Collect approved read-only live inventory and compare it with IaC; flag unmanaged drift.
- Review every pillar using the criteria below and record evidence or missing evidence.
- Classify findings by demonstrated impact and likelihood, not generic best-practice language.
- Present a summary and obtain explicit approval before creating GitHub issues.
- For approved findings, create one issue per root cause plus an optional tracking epic.
Criteria
| Pillar |
Review focus |
| Reliability |
Availability zones, failure isolation, backup/restore, recovery objectives, health checks, capacity and dependency failures |
| Security |
Identity, least privilege, secrets, network boundaries, encryption, policy, threat detection, secure delivery |
| Cost Optimization |
Validated spend, utilization, scale, tier, retention, commitment, ownership and budgets |
| Operational Excellence |
IaC ownership, deployment safety, observability, incident response, runbooks, drift and change control |
| Performance Efficiency |
Service/SKU fit, scaling, quotas, caching, data path, latency, throughput and load evidence |
Severity:
- High: credible security exposure, unrecoverable data risk, single critical failure, or inability to restore.
- Medium: material reliability, cost, operational, or performance risk with a plausible trigger.
- Low: bounded optimization or maintainability gap with limited immediate impact.
Output template
## Azure Well-Architected review result
**Status:** COMPLETE | BLOCKED
**Scope:** <subscription/resource groups/environments>
| Severity | Pillar | Finding | Evidence | Impact | IaC remediation | Validation |
| --- | --- | --- | --- | --- | --- | --- |
### Drift and missing evidence
- <item or none>
### Issue creation
- Approval: <granted/not granted>
- Issues: <links or none>
Limits
- Do not claim compliance or pillar maturity without evidence.
- Do not create issues, deploy, or modify Azure resources without approval.
- Prefer IaC remediation; CLI commands are validation or recovery guidance, not the source of truth.
- Do not fabricate availability, cost, performance, or recovery metrics.
Related primitives
| Name |
Type |
Use it when |
azure-infrastructure |
skill |
A finding needs an Azure architecture pattern. |
azure-pricing |
skill |
Cost evidence requires current pricing. |
open-horizons-architect |
agent |
Findings require a cross-domain architecture decision. |
open-horizons-security-reviewer |
agent |
A security finding needs independent validation. |
Quality gate
References
1---2name: azure-well-architected-review-53description: Reviews Azure workload IaC and current resource evidence against all five Azure Well-Architected Framework pillars. Use when assessing reliability, security, cost optimization, operational excellence, or performance efficiency and preparing prioritized findings.4---56# Azure Well-Architected review78Perform an evidence-based five-pillar review and return prioritized, IaC-first findings.910## When to invoke1112- Review an Azure workload against the Well-Architected Framework.13- Assess Azure IaC before production or a major change.14- Compare deployed resources with intended IaC and identify drift.15- Prepare WAF findings or an approved issue backlog.1617## Prerequisites and context1819Confirm subscription/resource-group scope, environments, business criticality, workload owners,20recovery objectives, data classification, cost constraints, and review time window.2122## Procedure23241. Confirm scope and load current Microsoft WAF guidance plus service-specific recommendations.252. Inspect `**/*.bicep`, `**/*.tf`, and ARM template JSON for the intended architecture.263. Collect approved read-only live inventory and compare it with IaC; flag unmanaged drift.274. Review every pillar using the criteria below and record evidence or missing evidence.285. Classify findings by demonstrated impact and likelihood, not generic best-practice language.296. Present a summary and obtain explicit approval before creating GitHub issues.307. For approved findings, create one issue per root cause plus an optional tracking epic.3132## Criteria3334| Pillar | Review focus |35| --- | --- |36| Reliability | Availability zones, failure isolation, backup/restore, recovery objectives, health checks, capacity and dependency failures |37| Security | Identity, least privilege, secrets, network boundaries, encryption, policy, threat detection, secure delivery |38| Cost Optimization | Validated spend, utilization, scale, tier, retention, commitment, ownership and budgets |39| Operational Excellence | IaC ownership, deployment safety, observability, incident response, runbooks, drift and change control |40| Performance Efficiency | Service/SKU fit, scaling, quotas, caching, data path, latency, throughput and load evidence |4142Severity:4344- **High:** credible security exposure, unrecoverable data risk, single critical failure, or inability to restore.45- **Medium:** material reliability, cost, operational, or performance risk with a plausible trigger.46- **Low:** bounded optimization or maintainability gap with limited immediate impact.4748## Output template4950```markdown51## Azure Well-Architected review result5253**Status:** COMPLETE | BLOCKED54**Scope:** <subscription/resource groups/environments>5556| Severity | Pillar | Finding | Evidence | Impact | IaC remediation | Validation |57| --- | --- | --- | --- | --- | --- | --- |5859### Drift and missing evidence60- <item or none>6162### Issue creation63- Approval: <granted/not granted>64- Issues: <links or none>65```6667## Limits6869- Do not claim compliance or pillar maturity without evidence.70- Do not create issues, deploy, or modify Azure resources without approval.71- Prefer IaC remediation; CLI commands are validation or recovery guidance, not the source of truth.72- Do not fabricate availability, cost, performance, or recovery metrics.7374## Related primitives7576| Name | Type | Use it when |77| --- | --- | --- |78| `azure-infrastructure` | `skill` | A finding needs an Azure architecture pattern. |79| `azure-pricing` | `skill` | Cost evidence requires current pricing. |80| `open-horizons-architect` | `agent` | Findings require a cross-domain architecture decision. |81| `open-horizons-security-reviewer` | `agent` | A security finding needs independent validation. |8283## Quality gate8485- [ ] Scope and workload quality attributes are explicit.86- [ ] All five pillars were reviewed.87- [ ] Findings cite IaC or current read-only evidence.88- [ ] Drift and missing evidence are visible.89- [ ] Severity, owner, remediation, and validation are actionable.90- [ ] Issues were created only after explicit approval.9192## References9394- [Azure Well-Architected Framework](https://learn.microsoft.com/azure/well-architected/)
paulasilvatech