Well-Architected Framework

The Azure Well-Architected Framework

The Azure Well-Architected Framework (WAF) is a comprehensive set of guiding principles and best practices for building high-quality cloud workloads. It is organized around five pillars, each representing a critical dimension of architecture quality. The framework is not prescriptive. It recognizes that every workload involves trade-offs between pillars. The key is making those trade-offs deliberately rather than accidentally.

Whether you are designing a new system, reviewing an existing one, or preparing for an architecture assessment, the WAF provides a structured, repeatable approach to identifying risks and improvement opportunities. This guide summarizes each pillar, explains the key design principles, provides actionable recommendations with real examples, and shows how the pillars connect to specific Azure services and configurations.

The Five Pillars at a Glance

Pillar 1: Reliability

Reliability ensures a workload performs its intended function correctly and consistently when it is needed. This encompasses high availability (minimizing downtime), disaster recovery (recovering from catastrophic failures), and resilience (gracefully handling partial failures). Reliability is often the most important pillar because the other four pillars are irrelevant if the system is down.

Key Design Principles

• Design for failure: Assume every component can fail at any time. Use redundancy across availability zones, implement retry logic with exponential backoff, deploy circuit breakers to prevent cascading failures, and use health endpoints to detect unhealthy instances.
• Define reliability targets: Establish Service Level Objectives (SLOs) for availability and latency. Calculate composite SLAs to understand end-to-end reliability. Your SLO should be slightly higher than your SLA commitment to customers to provide a buffer.
• Test failure scenarios regularly: Practice chaos engineering. Regularly test failover, backup restoration, and disaster recovery procedures. An untested DR plan is not a plan; it is a hope.
• Use managed services: Azure-managed services (Azure SQL Database, Cosmos DB, App Service) handle much of the reliability burden including patching, replication, and failover. Prefer them over self-managed alternatives on VMs.

Composite SLA Calculations

Serial dependency (all components must be up):
  App Service (99.95%) -> SQL Database (99.99%) -> Storage (99.9%)
  Composite SLA = 0.9995 x 0.9999 x 0.999 = 0.9984 = 99.84%
  Maximum expected downtime: ~84 minutes per year

Adding redundancy at the weakest link (Storage):
  Two storage accounts in active-active:
  Storage combined = 1 - (1 - 0.999)^2 = 0.999999 = 99.9999%
  New composite = 0.9995 x 0.9999 x 0.999999 = 0.9994 = 99.94%

Multi-region with Traffic Manager (99.99%):
  Region 1: App Service (99.95%) -> SQL (99.99%)
  Region 2: App Service (99.95%) -> SQL (99.99%)
  Region composite = 0.9995 x 0.9999 = 0.9994
  Multi-region = 1 - (1 - 0.9994)^2 = 0.99999964
  With Traffic Manager: 0.99999964 x 0.9999 = 0.9999 = ~99.99%

Key insight: Adding a second region has far more impact than
upgrading any single component within one region.

Reliability Patterns in Azure

Pillar 2: Security

Security protects the confidentiality, integrity, and availability of your workload and the data it processes. In cloud environments, security is a shared responsibility between Microsoft (infrastructure security) and you (workload security). The security pillar spans identity management, network protection, data encryption, application security, and threat detection.

Zero Trust Principles

The Well-Architected Framework strongly advocates for a Zero Trust security model:

• Verify explicitly: Always authenticate and authorize based on all available data points including user identity, location, device health, service or workload, data classification, and anomalies.
• Use least privileged access: Limit user access with Just-In-Time (JIT) and Just-Enough-Access (JEA). Use risk-based adaptive policies and data protection to secure both data and productivity.
• Assume breach: Minimize blast radius and segment access. Verify end-to-end encryption, use analytics to drive threat detection, and improve defenses.

Security Layering (Defense in Depth)

Layer 1: Identity & Access
  - Azure AD / Entra ID for authentication
  - RBAC with least privilege roles
  - Conditional Access policies
  - Managed identities (no stored credentials)
  - PIM for just-in-time privileged access

Layer 2: Network
  - Hub-spoke VNet architecture
  - NSGs on every subnet
  - Azure Firewall for centralized inspection
  - Private Endpoints for PaaS services
  - DDoS Protection Standard

Layer 3: Compute
  - Defender for Cloud on all resources
  - No public IPs on VMs
  - Azure Bastion for management access
  - Regular OS patching (Update Manager)
  - Container image scanning (Defender for Containers)

Layer 4: Application
  - Web Application Firewall (WAF) on Front Door
  - Input validation and output encoding
  - HTTPS everywhere (TLS 1.2+)
  - Security headers (CSP, HSTS, X-Frame-Options)
  - Dependency vulnerability scanning

Layer 5: Data
  - Encryption at rest (AES-256, default)
  - Encryption in transit (TLS 1.2+)
  - Customer-managed keys for sensitive data
  - Azure Key Vault for secrets management
  - Immutability policies for compliance data

Pillar 3: Cost Optimization

Cost Optimization is about maximizing the value delivered by your cloud investment, not simply reducing spending. The goal is achieving business outcomes at the lowest possible cost without sacrificing the reliability, security, or performance requirements of your workload. Over-optimization that causes outages or security gaps is worse than slight overspending.

High-Impact Cost Strategies

• Right-size resources: Use Azure Advisor to identify underutilized VMs and databases. A VM running at 10% CPU is wasting 90% of its cost. Downsize or switch to burstable B-series.
• Committed-use discounts: Purchase Reserved Instances (up to 72% savings) or Azure Savings Plans (up to 65% savings) for stable workloads. Right-size first, then commit.
• Spot VMs for fault-tolerant workloads: Batch processing, CI/CD agents, and dev/test environments can use Spot VMs for up to 90% savings.
• Auto-scaling and scheduling: Scale in during low demand. Shut down dev/test environments outside business hours (potential 65% savings on compute).
• Storage lifecycle management: Automatically tier cold data to Cool, Cold, and Archive tiers. Most organizations can save 40-60% on storage costs.
• PaaS over IaaS: Replacing self-managed VMs with App Service, Azure SQL Database, or managed Kubernetes reduces both compute cost and operational overhead.

# Get Azure Advisor cost recommendations
az advisor recommendation list --category Cost --output table

# Find underutilized VMs (Azure Advisor)
az advisor recommendation list \
  --category Cost \
  --query "[?shortDescription.solution=='Right-size or shutdown underutilized virtual machines']" \
  --output table

# Find unattached managed disks (orphaned resources)
az disk list \
  --query "[?managedBy==null].{Name:name, RG:resourceGroup, SizeGB:diskSizeGb, SKU:sku.name}" \
  --output table

# Find unused public IPs
az network public-ip list \
  --query "[?ipConfiguration==null].{Name:name, RG:resourceGroup}" \
  --output table

# Check reservation utilization
az consumption reservation summary list \
  --reservation-order-id <order-id> \
  --grain monthly \
  --output table

Pillar 4: Operational Excellence

Operational Excellence covers the practices that keep a workload running reliably in production. It encompasses infrastructure as code, deployment automation, comprehensive monitoring, incident response procedures, and continuous improvement. A workload can have a perfect architecture on paper, but without operational excellence, it will degrade over time.

Core Practices

• Infrastructure as Code (IaC): Define all infrastructure in Bicep or Terraform. Never make manual portal changes to production. IaC provides reproducibility, auditability, and the ability to recreate environments from scratch.
• CI/CD pipelines: Automate build, test, and deployment. Use deployment slots, blue-green deployments, or canary releases to minimize deployment risk. Automate rollback on failure detection.
• Full-stack monitoring: Use Azure Monitor, Application Insights, and Log Analytics for observability at every layer: infrastructure metrics, application traces, custom business metrics, and security logs.
• Incident management: Define clear incident response procedures with escalation paths. Use Azure Monitor alerts and Action Groups to notify the right people. Conduct blameless post-mortems after every incident.
• Runbook documentation: Create operational runbooks for common scenarios: scaling procedures, failover steps, secret rotation, certificate renewal, and recovery from common failure modes.

Monitoring Architecture

param location string = resourceGroup().location

// Log Analytics workspace (central data store)
resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
  name: 'myapp-logs'
  location: location
  properties: {
    sku: { name: 'PerGB2018' }
    retentionInDays: 90
    features: {
      enableLogAccessUsingOnlyResourcePermissions: true
    }
  }
}

// Application Insights (connected to Log Analytics)
resource appInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: 'myapp-insights'
  location: location
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: logAnalytics.id
    RetentionInDays: 90
  }
}

// CPU alert for virtual machines
resource cpuAlert 'Microsoft.Insights/metricAlerts@2018-03-01' = {
  name: 'high-cpu-alert'
  location: 'global'
  properties: {
    severity: 2
    enabled: true
    evaluationFrequency: 'PT5M'
    windowSize: 'PT15M'
    criteria: {
      'odata.type': 'Microsoft.Azure.Monitor.SingleResourceMultipleMetricCriteria'
      allOf: [
        {
          name: 'HighCPU'
          metricName: 'Percentage CPU'
          operator: 'GreaterThan'
          threshold: 85
          timeAggregation: 'Average'
        }
      ]
    }
    actions: [
      { actionGroupId: actionGroup.id }
    ]
    scopes: [
      virtualMachine.id
    ]
  }
}

// Action group for notifications
resource actionGroup 'Microsoft.Insights/actionGroups@2023-01-01' = {
  name: 'ops-team-alerts'
  location: 'global'
  properties: {
    groupShortName: 'OpsAlerts'
    enabled: true
    emailReceivers: [
      {
        name: 'ops-team'
        emailAddress: 'ops@company.com'
        useCommonAlertSchema: true
      }
    ]
  }
}

Pillar 5: Performance Efficiency

Performance Efficiency is the ability of a workload to scale to meet demand placed on it by users in an efficient manner. It covers selecting the right resource sizes, implementing caching strategies, optimizing data access patterns, and managing capacity. The goal is not raw speed; it is matching resource consumption to actual demand while maintaining acceptable user experience.

Key Strategies

• Scale horizontally over vertically: Design stateless services that scale out with multiple instances rather than requiring larger single instances. Horizontal scaling provides both better performance and better reliability (no single point of failure).
• Use caching aggressively: Azure Cache for Redis for application data, Azure CDN or Front Door for static content, and application-level caching for computed results. Caching dramatically reduces latency and backend load.
• Choose the right database for the access pattern: Relational (Azure SQL) for transactional workloads with complex queries, document (Cosmos DB) for flexible schemas with global distribution, key-value (Redis) for session state and caching, and columnar (Synapse) for analytical queries.
• Optimize data access: Use read replicas to offload read traffic, partition data for parallel processing, implement connection pooling, and minimize round trips with batch operations.
• Load test regularly: Use Azure Load Testing to validate performance under expected and peak loads before deploying to production. Identify bottlenecks before they affect users.

Auto-Scaling Patterns

Trade-offs Between Pillars

The five pillars often create tension with each other. The art of architecture is making deliberate trade-offs based on your workload's priorities rather than optimizing for one pillar at the expense of others.

Running a Well-Architected Review

A Well-Architected Review is a structured assessment of your workload against the five pillars. Microsoft provides tooling, but you can also conduct reviews internally using the framework as a checklist.

Review Process

1. Scope the workload: Define which application, system, or service you are reviewing. Include all dependent components (databases, caches, queues, external APIs).
2. Gather stakeholders: Include the application architect, lead developers, SRE/operations team, and a security representative. Each pillar needs domain expertise.
3. Complete the assessment: Use the Azure Well-Architected Review tool or walk through each pillar's checklist. Be honest about current state. The value is in identifying gaps, not in getting a perfect score.
4. Prioritize findings: Rank recommendations by impact (severity of risk) and effort (implementation cost). Focus on high-impact, low-effort items first.
5. Create an action plan: Turn findings into backlog items with clear ownership, timelines, and success criteria. Track progress in sprint planning.
6. Repeat quarterly: Cloud architectures evolve rapidly. Regular reviews catch drift, incorporate new Azure features, and validate that previous improvements are still effective.

# Get all Azure Advisor recommendations (across all categories)
az advisor recommendation list --output table

# Filter by category
az advisor recommendation list --category Reliability --output table
az advisor recommendation list --category Security --output table
az advisor recommendation list --category Cost --output table
az advisor recommendation list --category Performance --output table
az advisor recommendation list --category OperationalExcellence --output table

# Get Defender for Cloud secure score
az security secure-score-controls list --output table

# Check resource compliance against Azure Policy
az policy state summarize --output table

# List non-compliant resources
az policy state list \
  --filter "complianceState eq 'NonCompliant'" \
  --query "[].{Resource:resourceId, Policy:policyAssignmentName}" \
  --output table

Applying the Framework to Common Architectures

Let's apply the five pillars to two common Azure architectures to see how the framework translates into concrete decisions.

Web Application Architecture

Event-Driven Microservices Architecture