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-43description: 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<!-- Generated from harness/github-copilot/plugins/open-horizons-platform/skills/azure-well-architected-review/SKILL.md by harness/claude-code/scripts/convert_from_copilot.py. Edit the source, not this file. -->78# Azure Well-Architected review910Perform an evidence-based five-pillar review and return prioritized, IaC-first findings.1112## When to invoke1314- Review an Azure workload against the Well-Architected Framework.15- Assess Azure IaC before production or a major change.16- Compare deployed resources with intended IaC and identify drift.17- Prepare WAF findings or an approved issue backlog.1819## Prerequisites and context2021Confirm subscription/resource-group scope, environments, business criticality, workload owners,22recovery objectives, data classification, cost constraints, and review time window.2324## Procedure25261. Confirm scope and load current Microsoft WAF guidance plus service-specific recommendations.272. Inspect `**/*.bicep`, `**/*.tf`, and ARM template JSON for the intended architecture.283. Collect approved read-only live inventory and compare it with IaC; flag unmanaged drift.294. Review every pillar using the criteria below and record evidence or missing evidence.305. Classify findings by demonstrated impact and likelihood, not generic best-practice language.316. Present a summary and obtain explicit approval before creating GitHub issues.327. For approved findings, create one issue per root cause plus an optional tracking epic.3334## Criteria3536| Pillar | Review focus |37| --- | --- |38| Reliability | Availability zones, failure isolation, backup/restore, recovery objectives, health checks, capacity and dependency failures |39| Security | Identity, least privilege, secrets, network boundaries, encryption, policy, threat detection, secure delivery |40| Cost Optimization | Validated spend, utilization, scale, tier, retention, commitment, ownership and budgets |41| Operational Excellence | IaC ownership, deployment safety, observability, incident response, runbooks, drift and change control |42| Performance Efficiency | Service/SKU fit, scaling, quotas, caching, data path, latency, throughput and load evidence |4344Severity:4546- **High:** credible security exposure, unrecoverable data risk, single critical failure, or inability to restore.47- **Medium:** material reliability, cost, operational, or performance risk with a plausible trigger.48- **Low:** bounded optimization or maintainability gap with limited immediate impact.4950## Output template5152```markdown53## Azure Well-Architected review result5455**Status:** COMPLETE | BLOCKED56**Scope:** <subscription/resource groups/environments>5758| Severity | Pillar | Finding | Evidence | Impact | IaC remediation | Validation |59| --- | --- | --- | --- | --- | --- | --- |6061### Drift and missing evidence62- <item or none>6364### Issue creation65- Approval: <granted/not granted>66- Issues: <links or none>67```6869## Limits7071- Do not claim compliance or pillar maturity without evidence.72- Do not create issues, deploy, or modify Azure resources without approval.73- Prefer IaC remediation; CLI commands are validation or recovery guidance, not the source of truth.74- Do not fabricate availability, cost, performance, or recovery metrics.7576## Related primitives7778| Name | Type | Use it when |79| --- | --- | --- |80| `azure-infrastructure` | `skill` | A finding needs an Azure architecture pattern. |81| `azure-pricing` | `skill` | Cost evidence requires current pricing. |82| `open-horizons-architect` | `agent` | Findings require a cross-domain architecture decision. |83| `open-horizons-security-reviewer` | `agent` | A security finding needs independent validation. |8485## Quality gate8687- [ ] Scope and workload quality attributes are explicit.88- [ ] All five pillars were reviewed.89- [ ] Findings cite IaC or current read-only evidence.90- [ ] Drift and missing evidence are visible.91- [ ] Severity, owner, remediation, and validation are actionable.92- [ ] Issues were created only after explicit approval.9394## References9596- [Azure Well-Architected Framework](https://learn.microsoft.com/azure/well-architected/)
paulasilvatech