v0.1.0 to v0.1.1

25 added, 88 removed. Audit A to A.

---

name: azure-waf-reliability-review

description: "Review Azure workload reliability against the Well-Architected Framework Reliability pillar: availability targets, AZ/region topology, health monitoring, data resilience, deployment safety, and chaos testing."

allowed-tools: Read Grep Glob

metadata:

- author: "github: Raishin"

- version: "0.1.0"

- updated: "2026-05-09"

+ author: github: Raishin

+ version: 0.1.1

+ updated: "2026-06-04"

category: resilience

---

- # Azure WAF Reliability Review

- The Azure Well-Architected Framework Reliability pillar covers designing, building, and operating workloads that are resilient to failures, meet availability targets, and recover gracefully from disruptions.

- ## 5 Reliability Design Principles

- 1. **Design for business requirements** — translate business requirements into measurable reliability targets; define RTO, RPO, availability SLOs

- 2. **Design for resilience** — ensure the workload survives fault conditions without complete outage; design for partial failure

- 3. **Design for recovery** — assume failures will happen; implement automated recovery; test recovery procedures regularly

- 4. **Design for operations** — build operations into the design; implement health modeling; use automated deployments

- 5. **Keep it simple** — avoid design complexity that introduces reliability risks; use managed services to reduce operational burden

- ## Azure Reliability Service Areas

- ### Availability Zones

- - Zone-redundant services: ZRS Storage, Zone-redundant Azure SQL, AKS across zones

- - Zonal deployments: pin to specific zone for latency-sensitive workloads

- - Regional services: single-zone, not HA — use only for non-critical or dev/test workloads

- ### Fault Tolerance

- - Azure Load Balancer (L4) — regional traffic distribution

- - Azure Application Gateway (L7) — zone-redundant HTTP/S load balancing with WAF

- - Azure Traffic Manager (DNS) — cross-region failover and weighted routing

- - Azure Front Door — global anycast with automatic failover

- ### Scalability

- - VMSS (Virtual Machine Scale Sets) — VM-based horizontal scaling

- - Azure Kubernetes Service (KEDA, HPA) — pod and node autoscaling

- - Azure App Service autoscale — rule-based and metric-based scaling

- - Azure Functions consumption plan — event-driven serverless scaling

- ### Data Resilience

- - Azure SQL Business Critical — 2 readable secondaries, zone-redundant by default

- - Cosmos DB — multi-region writes, configurable consistency (strong/bounded-staleness)

- - Azure Storage GRS/GZRS — geo-redundant and geo-zone-redundant replication

- - Azure Backup — VM, SQL, and file share backup with retention policies

- - Azure Site Recovery (ASR) — VM replication and orchestrated failover

- ### Health Modeling

- - Azure Monitor — metrics, logs, and alerting platform

- - Application Insights — distributed tracing, availability tests, failure analysis

- - Azure Service Health alerts — planned maintenance, outage notifications, advisories

- - Resource Health API — per-resource health signal for automated remediation

- ### Chaos Engineering

- - Azure Chaos Studio — inject faults: VM availability zone failure, AKS pod failure, network latency, dependency unavailability

- ### Deployment Safety

- - App Service deployment slots — blue/green with slot swap and auto-swap

- - Azure Deployment Environments — consistent, governed environment templates

- - Traffic Manager weighted routing — canary deployment with percentage-based traffic split

- ## Azure SLA Key Facts

- - Availability Zones: **99.99%** SLA for VMs when using ≥2 VMs across ≥2 AZs

- - Azure SQL Business Critical + zones: **99.995%**

- - Cosmos DB multi-region writes: **99.999%**

- - Single VM with Premium SSD: **99.9%** — NOT suitable for production HA

- - Traffic Manager: **99.99%**

+ # Azure WAF Reliability

- ## Assessment Questions

+ ## Purpose

- - What are the availability and reliability targets for the workload?

- - How do you ensure the workload can operate during a zone or region outage?

- - How do you implement health monitoring and proactive alerting?

- - How do you manage dependencies and limit blast radius of failures?

- - How do you test resilience and validate recovery procedures?

- - How do you design for graceful degradation under load or partial failure?

- - How do you implement safe deployment practices to minimize rollback risk?

+ Act as a ruthless Azure reviewer for azure waf reliability work. Stop broad, vague, or unverified recommendations before they become production risk.

- ## Validation Checklist

+ ## Lean operating rules

- - [ ] SLOs defined with measurable SLIs monitored via Azure Monitor

- - [ ] All stateful services (VMs, databases) deployed across ≥2 Availability Zones

- - [ ] Azure Service Health alerts configured for all services in use

- - [ ] Autoscaling enabled for stateless compute (VMSS, App Service, AKS node pools)

- - [ ] Azure SQL or Cosmos DB multi-region replication configured for mission-critical data

- - [ ] Azure Backup or ASR configured for VMs, SQL databases, and critical storage

- - [ ] Deployment slots or Traffic Manager canary routing used for production deployments

- - [ ] Azure Chaos Studio experiments conducted to validate AZ failure recovery

- - [ ] Circuit breaker and retry patterns implemented for external service calls

- - [ ] RTO/RPO targets documented and validated via DR drill in the last 12 months

+ - Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when available, then sanitized user evidence.

+ - Separate confirmed facts from inference. If state was not queried or shown, say so.

+ - Challenge broad access, broad scope, destructive changes, billing-impacting actions, and hand-wavy production claims.

+ - Keep the answer scoped, reversible where possible, least-privilege, and explicit about blockers or unknowns.

+ - Never ask the user to paste credentials, tokens, secrets, tenant IDs, subscription IDs, resource IDs, customer data, private keys, or raw incident payloads.

- ## Response Shape

+ ## References

- Availability targets review → AZ/region topology → health monitoring → failure tolerance → data resilience → deployment safety → chaos testing status → recommendations → open risks

+ Load these only when needed:

- ## Official Documentation

+ - [Azure WAF Reliability Operations](references/waf-reliability-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.

+ - [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.

+ - [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.

+ - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.

+ - [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.

- - https://learn.microsoft.com/azure/well-architected/reliability/

- - https://learn.microsoft.com/azure/reliability/availability-zones-overview

+ ## Response minimum

- ## Security Notes

+ Return, at minimum:

- Read-only advisory. Do not modify autoscaling policies, backup schedules, or Azure Site Recovery configurations without explicit approval.

+ - the scoped target and evidence level,

+ - the main risks or control gaps,

+ - the safest next actions,

+ - the assumptions or blockers that prevent stronger conclusions.