Azure Well-Architected Framework and Production Readiness Review
The Azure Well-Architected Framework reviews workloads across Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency. A production readiness review converts those principles into evidence: requirements, diagrams, tests, policies, runbooks, dashboards, owners, accepted risks, and a decision about whether the workload can safely launch.
Method note: A production readiness review is a human governance decision supported by evidence, not a resource that Portal, CLI, or IaC can deploy equivalently. Azure Advisor and automated checks inform the review but cannot replace ownership and approval.
What does each pillar ask?
Pillars trade off. Active-active regions can improve reliability but increase cost and operational complexity. Record tradeoffs rather than claiming every pillar is maximized.
What evidence should exist before production?
Architecture and ownership
- Current context/container/component/deployment/data-flow diagrams.
- Resource inventory, data classification, and dependency map.
- Service owners, on-call, vendors, and escalation contacts.
- SLOs, RTO/RPO, capacity assumptions, and cost forecast.
Security
- Threat model and abuse cases, including AI-specific threats.
- Entra/RBAC review, privileged access, workload identities.
- Private/public exposure inventory and firewall/WAF policy.
- Encryption/key/certificate/secret lifecycle.
- Vulnerability, supply-chain, and policy compliance evidence.
- Incident runbooks and tested kill switches.
Reliability and performance
- Zone/region failure behavior and dependency alignment.
- Load, stress, soak, and failover tests.
- Retry/timeouts/circuit breakers and idempotency.
- Backup/restore results and measured recovery time/data loss.
- Quota/capacity headroom and scaling limits.
Operations and delivery
- IaC with reviewed plans and drift detection.
- Immutable build provenance and deployment strategy.
- Application/database rollback or roll-forward plan.
- Dashboards, alerts, SLO burn-rate, and runbooks.
- Change, access, log retention, and evidence policy.
AI-specific evidence
- Model/prompt/retrieval version registry.
- Evaluation dataset and release results.
- Grounding, citation, access-filter, injection, and safety tests.
- Token/tool/time/cost limits.
- Human approval for consequential actions.
- Model outage/quota fallback and data-governance process.
How do you run the review?
- Define scope and critical user journeys.
- Complete Azure Well-Architected Review with the real team.
- Collect evidence instead of yes/no claims.
- Rank findings by user/business risk and effort.
- Assign owner, due date, and verification method.
- Block launch on explicit critical criteria.
- Record accepted risks with approver and expiry.
- Revisit after material architecture, model, scale, or regulatory change.
What should block launch?
Examples:
- No tested restore for authoritative data.
- Publicly reachable sensitive data service without approved control.
- Production depends on a single personal account or secret.
- No alerting for critical user journey.
- Unknown model/search quota at expected load.
- Cross-tenant RAG test failure.
- Destructive database deployment without recovery plan.
- Unowned critical security recommendation.
How does Azure Advisor help?
Advisor provides recommendations across cost, security, reliability, performance, and operational excellence. Validate each against workload context. Automate review and track accepted/dismissed recommendations with reasons. Advisor complements—not replaces—the architecture review.
The final production decision
The accountable owner signs one of three outcomes: ready; conditionally ready with explicit time-bound risks; or not ready. Keep the evidence in the system of record. After launch, compare assumptions with real SLO, incident, cost, capacity, and user data.
Official references