Module 14 — Reference Architectures & Best Practices¶

1 — WAF Architecture Decision Tree¶

Choosing the right Azure WAF deployment starts with understanding your application's traffic pattern, audience, and infrastructure. The following decision tree guides you through the key questions:

flowchart TD
    A[Is the application<br>public-facing?] -->|Yes| B[Does it serve a<br>global audience?]
    A -->|No| C[Internal / private<br>application]
    B -->|Yes| D[Azure Front Door<br>Premium + WAF]
    B -->|Regional only| E[Application Gateway<br>WAF v2]
    C --> F{What compute<br>platform?}
    F -->|VMs / VMSS| G[Application Gateway<br>WAF v2 — private frontend]
    F -->|AKS / Kubernetes| H{Need advanced<br>L7 routing?}
    H -->|Yes| I[Application Gateway<br>for Containers]
    H -->|No| G
    D --> J{Also need regional<br>L7 features?}
    J -->|Yes| K[Front Door + AppGW<br>Layered Architecture]
    J -->|No| D
    E --> L{Need global failover<br>or CDN?}
    L -->|Yes| K
    L -->|No| E

Decision Summary¶

2 — Reference Architecture: Public Web Application¶

The most common pattern: a public-facing web application protected by Front Door with WAF, backed by an App Service integrated into a VNet with a private endpoint.

flowchart LR
    A[Internet Users] --> B[Azure Front Door<br>Premium + WAF Policy]
    B -->|Private Link<br>Origin| C[App Service<br>VNet Integrated]
    C --> D[Azure SQL<br>Private Endpoint]

    subgraph Security Controls
        E[WAF Managed Rules<br>DRS 2.1]
        F[Bot Protection]
        G[Rate Limiting]
        H[Geo-Filtering]
    end

    B --- E & F & G & H

Key Design Decisions¶

Origin Lockdown is critical in this architecture. Without it, attackers can bypass Front Door by sending requests directly to the App Service's public URL. Implement origin lockdown by:

1. Private Link Origin (recommended) — Front Door Premium connects to App Service via Private Link. The App Service has no public endpoint at all.
2. Access Restrictions — If Private Link is not feasible, configure App Service access restrictions to allow only Front Door's service tag (AzureFrontDoor.Backend) and validate the X-Azure-FDID header matches your Front Door instance ID.

# Configure access restriction to allow only Front Door
az webapp config access-restriction add \
  --resource-group "rg-waf-workshop" \
  --name "app-workshop" \
  --priority 100 \
  --service-tag AzureFrontDoor.Backend \
  --http-header x-azure-fdid=<your-front-door-id>

3 — Reference Architecture: Internal Application¶

Internal applications serve corporate users who connect through ExpressRoute, VPN, or Azure Virtual Desktop. The WAF still provides value by protecting against insider threats, compromised devices, and lateral movement.

flowchart LR
    A[Corporate Network] -->|ExpressRoute /<br>VPN Gateway| B[Hub VNet]
    B --> C[Application Gateway<br>WAF v2 — Private Frontend]
    C --> D[Spoke VNet]
    D --> E[VM Scale Set /<br>AKS Cluster]
    E --> F[Azure SQL<br>Private Endpoint]

    subgraph WAF Configuration
        G[Managed Rules —<br>Detection Mode]
        H[Custom Rules —<br>IP Allow-List]
    end

    C --- G & H

Key Design Decisions¶

• Private Frontend IP — Application Gateway is deployed in a dedicated subnet within the hub VNet with only a private frontend IP. No public IP is assigned.
• Detection Mode First — Internal applications typically have more complex, non-standard request patterns. Start in Detection mode, analyze logs for 2–4 weeks, create exclusions, then switch to Prevention.
• IP Allow-Listing — Use custom rules to restrict access to known corporate IP ranges, adding a network-layer access control on top of the L7 WAF inspection.
• NSG Integration — Network Security Groups on the Application Gateway subnet must allow the required management traffic (GatewayManager service tag, health probes).

4 — Reference Architecture: API Protection¶

APIs require a different WAF strategy than web applications. They typically accept JSON payloads (not HTML forms), use authentication tokens, and have well-defined request schemas.

flowchart LR
    A[API Consumers] --> B[Azure Front Door<br>Premium + WAF Policy]
    B --> C[API Management<br>Premium / VNet Integrated]
    C --> D[Backend APIs<br>AKS / Functions / App Service]

    subgraph WAF Layer
        E[Managed Rules<br>— JSON-tuned exclusions]
        F[Rate Limiting<br>— per API key]
        G[Custom Rules<br>— header validation]
    end

    subgraph APIM Layer
        H[JWT Validation]
        I[Quota / Throttling]
        J[Request Schema Validation]
    end

    B --- E & F & G
    C --- H & I & J

How WAF and APIM Complement Each Other¶

Control	WAF	APIM
SQL Injection / XSS	Managed rules inspect payloads	No inspection
Rate Limiting	Per-IP rate limits at edge	Per-subscription/key throttling
Authentication	Not a WAF concern	JWT validation, OAuth flows
Schema Validation	Rules are pattern-based	OpenAPI schema enforcement
Bot Protection	Bot manager rules	No built-in bot detection
IP Filtering	Geo and IP custom rules	IP filter policies

5 — Reference Architecture: Multi-Region¶

For applications requiring high availability across Azure regions, Front Door provides global load balancing with WAF at the edge, routing to regional Application Gateways that provide additional L7 capabilities.

flowchart TD
    A[Internet Users] --> B[Azure Front Door<br>Premium + WAF Policy<br>Global]

    B --> C[Region 1 — East US]
    B --> D[Region 2 — West Europe]

    subgraph Region 1 — East US
        C --> E[Application Gateway<br>WAF v2]
        E --> F[AKS Cluster /<br>App Service]
        F --> G[Azure SQL<br>Read-Write]
    end

    subgraph Region 2 — West Europe
        D --> H[Application Gateway<br>WAF v2]
        H --> I[AKS Cluster /<br>App Service]
        I --> J[Azure SQL<br>Read Replica]
    end

    G <-->|Geo-Replication| J

Design Considerations¶

• Single WAF Policy at Front Door — Maintain one global WAF policy at the Front Door level. This ensures consistent security posture across all regions.
• Regional WAF Policies — Application Gateways in each region can have their own WAF policies for region-specific rules (e.g., compliance requirements, regional IP blocks).
• Health Probes — Front Door monitors backend health and automatically fails over. WAF blocks do not affect health probe results (probes bypass WAF).
• Session Affinity — If your application requires sticky sessions, configure Front Door session affinity. WAF does not impact session cookie handling.

6 — WAF Best Practices Summary¶

The following practices are distilled from Microsoft's official guidance, Azure support team experience, and production deployment patterns across enterprise customers.

6.1 Policy and Configuration¶

6.2 Security Features¶

6.3 Operations¶

7 — WAF Limits & Quotas¶

Every Azure resource has platform limits. Designing within these limits avoids runtime surprises. The following table consolidates the most important WAF limits:

Application Gateway WAF v2¶

Front Door WAF¶

8 — Migration Guide¶

8.1 Legacy WAF Config to WAF Policy¶

Older Application Gateway deployments may use the legacy WAF configuration embedded directly in the gateway resource rather than a standalone WAF Policy object.

Why migrate?

• WAF Policies support per-site and per-URI rule customization — legacy config applies globally only.
• WAF Policies support exclusions, custom rules, bot protection — unavailable in legacy config.
• Legacy config is deprecated and will not receive new features.

Migration steps:

1. Export current config — Document your current WAF mode, disabled rules, and any firewall exclusions.
2. Create a WAF Policy — Create a new ApplicationGatewayWebApplicationFirewallPolicies resource with the same mode and rule set version.
3. Recreate disabled rules — In the WAF Policy, override the specific rules that were disabled in legacy config.
4. Add exclusions — Recreate any exclusions in the WAF Policy's exclusion section.
5. Associate the policy — Link the WAF Policy to the Application Gateway.
6. Verify — Monitor logs for 24–48 hours to confirm identical behavior.
7. Remove legacy config — Once confirmed, remove the legacy WAF configuration from the gateway.

# Associate WAF policy with Application Gateway
az network application-gateway update \
  --name "appgw-workshop" \
  --resource-group "rg-waf-workshop" \
  --set firewallPolicy.id="/subscriptions/<sub-id>/resourceGroups/rg-waf-workshop/providers/Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/pol-workshop"

8.2 CRS 3.x to DRS 2.1 Migration¶

DRS 2.1 is the successor to the CRS (OWASP Core Rule Set) versions. Key differences:

Migration steps:

1. Switch to DRS 2.1 in Detection mode — Update the managed rule set version in your WAF Policy to DRS 2.1, keeping the policy in Detection mode.
2. Monitor for 1–2 weeks — DRS 2.1 may trigger on different patterns than CRS 3.x. Review the firewall logs for new detections.
3. Review anomaly scores — DRS 2.1 uses anomaly scoring. Requests accumulate scores across multiple rule matches. Understand the score distribution before setting the threshold.
4. Update exclusions — Some exclusions may need adjustment because rule IDs changed between CRS 3.x and DRS 2.1.
5. Switch to Prevention mode — Once the Detection-mode logs show clean results, switch to Prevention.

9 — WAF as Code¶

Defining WAF configuration as infrastructure code is a best practice that enables version control, automated deployment, peer review, and environment consistency. The following Bicep template defines a complete WAF policy with managed rules, custom rules, and exclusions.

Complete Bicep Template¶

@description('WAF Policy for production web application')
param location string = resourceGroup().location
param policyName string = 'pol-prod-webapp'

resource wafPolicy 'Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies@2023-11-01' = {
  name: policyName
  location: location
  properties: {

    // Policy Settings
    policySettings: {
      requestBodyCheck: true
      maxRequestBodySizeInKb: 128
      fileUploadLimitInMb: 100
      state: 'Enabled'
      mode: 'Prevention'
      requestBodyInspectLimitInKB: 128
      fileUploadEnforcement: true
      requestBodyEnforcement: true
    }

    // Managed Rules
    managedRules: {
      managedRuleSets: [
        {
          ruleSetType: 'Microsoft_DefaultRuleSet'
          ruleSetVersion: '2.1'
          ruleGroupOverrides: [
            {
              ruleGroupName: 'SQLI'
              rules: [
                {
                  ruleId: '942430'
                  state: 'Enabled'
                  action: 'Log'
                }
              ]
            }
          ]
        }
        {
          ruleSetType: 'Microsoft_BotManagerRuleSet'
          ruleSetVersion: '1.1'
        }
      ]
      exclusions: [
        {
          matchVariable: 'RequestArgNames'
          selectorMatchOperator: 'Equals'
          selector: 'callback'
          exclusionManagedRuleSets: [
            {
              ruleSetType: 'Microsoft_DefaultRuleSet'
              ruleSetVersion: '2.1'
              ruleGroups: [
                {
                  ruleGroupName: 'XSS'
                  rules: [
                    { ruleId: '941100' }
                    { ruleId: '941130' }
                  ]
                }
              ]
            }
          ]
        }
      ]
    }

    // Custom Rules
    customRules: [
      {
        name: 'BlockMaliciousCountries'
        priority: 10
        ruleType: 'MatchRule'
        action: 'Block'
        matchConditions: [
          {
            matchVariables: [
              { variableName: 'RemoteAddr' }
            ]
            operator: 'GeoMatch'
            matchValues: [ 'XX' , 'YY' ]
            negationConditon: false
          }
        ]
      }
      {
        name: 'RateLimitPerIP'
        priority: 20
        ruleType: 'RateLimitRule'
        rateLimitDuration: 'FiveMins'
        rateLimitThreshold: 500
        action: 'Block'
        matchConditions: [
          {
            matchVariables: [
              { variableName: 'RemoteAddr' }
            ]
            operator: 'IPMatch'
            negationConditon: true
            matchValues: [ '10.0.0.0/8' ]
          }
        ]
        groupByUserSession: [
          { groupByVariables: [ { variableName: 'ClientAddr' } ] }
        ]
      }
      {
        name: 'AllowHealthProbes'
        priority: 5
        ruleType: 'MatchRule'
        action: 'Allow'
        matchConditions: [
          {
            matchVariables: [
              { variableName: 'RequestUri' }
            ]
            operator: 'Contains'
            matchValues: [ '/health', '/ready' ]
            negationConditon: false
          }
        ]
      }
    ]
  }

  tags: {
    environment: 'production'
    managedBy: 'bicep'
    lastReviewed: '2024-06-01'
  }
}

output policyId string = wafPolicy.id

Deploying the Template¶

# Deploy WAF policy using Bicep
az deployment group create \
  --resource-group "rg-waf-workshop" \
  --template-file "waf-policy.bicep" \
  --parameters policyName="pol-prod-webapp"

# Verify deployment
az network application-gateway waf-policy show \
  --name "pol-prod-webapp" \
  --resource-group "rg-waf-workshop" \
  --query "{name:name, mode:policySettings.mode, ruleSet:managedRules.managedRuleSets[0].ruleSetType}" \
  --output table

CI/CD Integration¶

Integrate the Bicep template into your CI/CD pipeline to ensure WAF configuration changes go through the same review and approval process as application code:

flowchart LR
    A[Developer updates<br>waf-policy.bicep] --> B[Pull Request<br>+ Code Review]
    B --> C[CI Pipeline:<br>bicep build + what-if]
    C --> D[Approval Gate]
    D --> E[CD Pipeline:<br>az deployment group create]
    E --> F[Post-deploy validation:<br>smoke tests + log check]

# Preview changes before deploying
az deployment group what-if \
  --resource-group "rg-waf-workshop" \
  --template-file "waf-policy.bicep" \
  --parameters policyName="pol-prod-webapp"

Key Takeaways¶

1. Use the decision tree to select the right WAF deployment model — Front Door for global apps, Application Gateway for regional, layered for complex scenarios.
2. Always lock down origins when using Front Door — Private Link origins are the gold standard.
3. WAF + APIM complement each other for API protection — WAF handles attack patterns, APIM handles authentication and schema validation.
4. Follow the Detection → Tune → Prevention workflow — never deploy WAF in Prevention mode on day one.
5. Design within platform limits — 100 custom rules, 128 KB body inspection, 600 IP ranges per condition.
6. Define WAF as code using Bicep or Terraform, deployed through CI/CD with what-if previews and approval gates.
7. Migrate to WAF Policy and DRS 2.1 if you are still on legacy configuration or CRS 3.x.

References¶

• Azure WAF Best Practices — Microsoft Learn
• WAF on Application Gateway — Overview
• WAF on Front Door — Overview
• Application Gateway for Containers
• Front Door Origin Security — Private Link
• WAF Policy Resource — Bicep Reference
• Azure WAF Quotas and Limits
• DRS 2.1 Rule Groups and Rules
• Migrate to WAF Policy