This workflow performs a structured Azure Well-Architected Framework (WAF) review against your workload's IaC files and deployed infrastructure. It identifies risks across all 5 WAF pillars and creates GitHub issues to track remediation.
az) configured and authenticatedFetch current Azure WAF best practices:
https://learn.microsoft.com/en-us/azure/well-architected/
https://learn.microsoft.com/en-us/azure/well-architected/service-guides/)If the microsoft.docs.mcp MCP server is available, use it to query the latest pillar checklists and service-specific recommendations.
Establish the review scope, then inventory both the code and the live environment:
**/*.bicep, bicepconfig.json
**/*.tf (azurerm/azapi providers)**/azuredeploy*.json, **/*.template.json, files with $schema containing deploymentTemplate
az resource list --resource-group <rg> --output json (or subscription-wide), plus targeted az <service> show calls for configuration details the pillar checks need.Identify key Azure services in use (compute, data, networking, security, observability) and generate a Mermaid architecture diagram.
* → * allow rules)minimumTlsVersion, httpsOnly)az security pricing list)az consumption budget list)For each finding, classify:
🏗️ Azure Well-Architected Review Summary
📊 Review Results:
• IaC Files Analyzed: X
• Azure Services Identified: Y
• Total Findings: Z
• High Risk: A (immediate action required)
• Medium Risk: B (should address soon)
• Low Risk: C (nice to have)
🔴 Top High Risk Findings:
1. [Pillar]: [Finding] — [Why it matters]
2. [Pillar]: [Finding] — [Why it matters]
💡 This will create Z individual GitHub issues + 1 EPIC issue.
❓ Proceed with creating GitHub issues? (y/n)
Gate: Only proceed to Steps 6–7 if the user gives an explicit affirmative response (e.g. "y", "yes"). On a negative, ambiguous, or missing response, do not create any GitHub issues — output the full findings as formatted markdown to the console and stop.
Label with "well-architected" and the pillar name (e.g., "security", "reliability").
Title: [WAF-<PILLAR>] [Brief Finding] — [Risk Level]
Body:
## 🏗️ Well-Architected Finding: [Brief Title]
**Pillar**: [Name] | **Risk Level**: [High/Medium/Low] | **Effort**: [Low/Medium/High]
### 📋 Description
[Clear explanation of the finding and why it matters]
### 🔧 Remediation
**IaC Fix** (preferred):
```bicep
// Bicep example
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
name: storageAccountName
location: location
sku: { name: 'Standard_ZRS' }
kind: 'StorageV2'
properties: {
minimumTlsVersion: 'TLS1_2'
allowBlobPublicAccess: false
supportsHttpsTrafficOnly: true
}
}
```
**Azure CLI fallback**:
```bash
az storage account update --name <name> --resource-group <rg> \
--min-tls-version TLS1_2 --allow-blob-public-access false --https-only true
```
### 📚 Azure Reference
- [WAF Best Practice Link]
- [Microsoft Learn Documentation Link]
### ✅ Validation
- [ ] Change implemented in IaC and deployed
- [ ] Azure Policy compliance passes (if applicable)
- [ ] Microsoft Defender for Cloud recommendation resolved (if applicable)
**Well-Architected Recommendation**: [WAF checklist item this maps to]
Label with "well-architected" and "epic".
Title: [EPIC] Azure Well-Architected Review — X findings across 5 pillars
Body: Executive summary with pillar breakdown table (finding counts by pillar and risk level), Mermaid architecture diagram, prioritized checklist linking all individual issues (High → Medium → Low), and success criteria:
az resource list) and note the gap