Microsoft Azure — Application Gateway & WAF

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers application gateway & waf with production-ready configurations, best practices, and hands-on examples.

Why Azure Application Gateway and WAF Matter in Production

In production, you need a reverse proxy that can handle HTTP/S traffic at scale while protecting your backends from common exploits. Azure Application Gateway is a layer-7 load balancer that offers SSL termination, URL-based routing, and session affinity. When paired with the Web Application Firewall (WAF), it blocks SQL injection, XSS, and other OWASP Top-10 attacks before they reach your application. Many teams start with a basic load balancer and later realize they need WAF after an incident. Don't be that team. Deploy Application Gateway with WAF from day one. The cost difference is minimal compared to the cost of a breach. In production, you'll also need to plan for scaling, health probes, and logging. This article walks through a real-world setup with Terraform, covering everything from basic routing to advanced WAF tuning.

resource "azurerm_application_gateway" "example" {
  name                = "example-appgw"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location

  sku {
    name     = "WAF_v2"
    tier     = "WAF_v2"
    capacity = 2
  }

  gateway_ip_configuration {
    name      = "gateway-ip-config"
    subnet_id = azurerm_subnet.frontend.id
  }

  frontend_port {
    name = "http-port"
    port = 80
  }

  frontend_ip_configuration {
    name                 = "frontend-ip"
    public_ip_address_id = azurerm_public_ip.example.id
  }

  backend_address_pool {
    name = "backend-pool"
  }

  backend_http_settings {
    name                  = "http-settings"
    cookie_based_affinity = "Disabled"
    port                  = 80
    protocol              = "Http"
    request_timeout       = 20
  }

  http_listener {
    name                           = "http-listener"
    frontend_ip_configuration_name = "frontend-ip"
    frontend_port_name             = "http-port"
    protocol                       = "Http"
  }

  request_routing_rule {
    name                       = "rule-1"
    rule_type                  = "Basic"
    http_listener_name         = "http-listener"
    backend_address_pool_name  = "backend-pool"
    backend_http_settings_name = "http-settings"
  }
}

Designing a Multi-Site Routing Architecture

In production, you rarely have a single backend. You might have multiple microservices, each exposed under different hostnames or paths. Application Gateway supports multi-site listeners, allowing you to route traffic based on the Host header or URL path. For example, api.example.com goes to one backend pool, while app.example.com goes to another. This is critical for zero-downtime deployments and canary releases. When designing routing, keep it simple: use path-based routing for internal services and host-based routing for external facing ones. Avoid complex rewrite rules unless absolutely necessary—they add latency and debugging complexity. Always use HTTPS listeners with SSL termination at the gateway. This offloads CPU work from your backends and centralizes certificate management. In production, you'll also want to set up a custom domain with Azure Key Vault for certificate storage.

resource "azurerm_application_gateway" "example" {
  # ... previous configuration ...

  http_listener {
    name                           = "api-listener"
    frontend_ip_configuration_name = "frontend-ip"
    frontend_port_name             = "https-port"
    protocol                       = "Https"
    ssl_certificate_name           = "api-cert"
    host_name                      = "api.example.com"
  }

  http_listener {
    name                           = "app-listener"
    frontend_ip_configuration_name = "frontend-ip"
    frontend_port_name             = "https-port"
    protocol                       = "Https"
    ssl_certificate_name           = "app-cert"
    host_name                      = "app.example.com"
  }

  request_routing_rule {
    name                       = "api-rule"
    rule_type                  = "Basic"
    http_listener_name         = "api-listener"
    backend_address_pool_name  = "api-backend"
    backend_http_settings_name = "http-settings"
  }

  request_routing_rule {
    name                       = "app-rule"
    rule_type                  = "Basic"
    http_listener_name         = "app-listener"
    backend_address_pool_name  = "app-backend"
    backend_http_settings_name = "http-settings"
  }
}

Configuring Health Probes for Reliable Backend Detection

Health probes are the backbone of reliable traffic routing. Application Gateway uses probes to determine if a backend is healthy. If a probe fails, the gateway stops sending traffic to that backend. In production, you must configure custom probes that match your application's health endpoint. The default probe only checks if the TCP port is open, which is useless for most apps. A proper health endpoint should return 200 OK within a short timeout and include a lightweight check (e.g., database connectivity). Set the probe interval to 30 seconds and the unhealthy threshold to 3 failures. This gives your app time to recover from transient issues without being removed prematurely. Also, configure the backend HTTP settings to use the same probe. In production, we've seen probes that are too aggressive cause cascading failures during deployments.

resource "azurerm_application_gateway" "example" {
  # ... previous configuration ...

  probe {
    name                = "health-probe"
    protocol            = "Http"
    path                = "/health"
    interval            = 30
    timeout             = 10
    unhealthy_threshold = 3
    healthy_threshold   = 1
  }

  backend_http_settings {
    name                  = "http-settings"
    cookie_based_affinity = "Disabled"
    port                  = 80
    protocol              = "Http"
    request_timeout       = 20
    probe_name            = "health-probe"
  }
}

Enabling WAF with OWASP Rules and Custom Rules

WAF is your first line of defense against web attacks. Azure WAF comes with a managed rule set based on OWASP 3.2 (or 3.1). In production, you should enable the OWASP rules and then tune them to reduce false positives. Start in Detection mode to log violations without blocking traffic. After a week, review the logs and disable rules that cause false positives. Then switch to Prevention mode. You can also add custom rules for application-specific threats, like blocking requests from certain IP ranges or enforcing a maximum request body size. Be careful with custom rules—they can easily block legitimate traffic if not tested. In production, we recommend using managed rules as a baseline and only adding custom rules for known attack patterns. Also, enable WAF logs to Azure Monitor or a SIEM for analysis.

resource "azurerm_application_gateway" "example" {
  # ... previous configuration ...

  waf_configuration {
    enabled          = true
    firewall_mode    = "Detection"
    rule_set_type    = "OWASP"
    rule_set_version = "3.2"

    disabled_rule_group {
      rule_group_name = "REQUEST-942-APPLICATION-ATTACK-SQLI"
      rules           = [942100, 942110]
    }
  }
}

SSL Termination and Certificate Management with Key Vault

SSL termination at the gateway offloads encryption from backends and centralizes certificate management. In production, store certificates in Azure Key Vault and reference them in the Application Gateway configuration. This allows automatic renewal and rotation without downtime. Never store certificates in the gateway configuration directly—they expire and cause outages. Use managed identities to grant the gateway access to Key Vault. When setting up SSL, use TLS 1.2 or higher and disable older protocols. Also, consider using Azure Front Door for global SSL termination if you have multiple regions. In production, we've seen outages caused by expired certificates that were not monitored. Set up alerts for certificate expiration at least 30 days before expiry.

resource "azurerm_key_vault_certificate" "example" {
  name         = "example-cert"
  key_vault_id = azurerm_key_vault.example.id

  certificate_policy {
    issuer_parameters {
      name = "Self"
    }

    key_properties {
      exportable = true
      key_size   = 2048
      key_type   = "RSA"
      reuse_key  = true
    }

    secret_properties {
      content_type = "application/x-pkcs12"
    }

    x509_certificate_properties {
      key_usage = [
        "cRLSign",
        "dataEncipherment",
        "digitalSignature",
        "keyAgreement",
        "keyCertSign",
        "keyEncipherment",
      ]
      subject            = "CN=example.com"
      validity_in_months = 12
    }
  }
}

resource "azurerm_application_gateway" "example" {
  # ... previous configuration ...

  ssl_certificate {
    name                = "example-cert"
    key_vault_secret_id = azurerm_key_vault_certificate.example.secret_id
  }
}

Scaling and Performance Tuning for High Traffic

Application Gateway v2 supports autoscaling, but you must configure minimum and maximum instance counts. In production, set a minimum of 2 instances for high availability and a maximum based on your expected peak traffic. The gateway scales based on CPU and throughput metrics. However, scaling is not instantaneous—it can take 5-10 minutes. To handle traffic spikes, pre-warm the gateway by setting a higher minimum during known high-traffic periods. Also, tune the request timeout and connection draining settings. Connection draining ensures in-flight requests complete before a backend is removed. Set the drain timeout to 30 seconds. In production, we've seen gateways overwhelmed by too many concurrent connections. Use keep-alive connections and reduce the timeout to free up resources.

resource "azurerm_application_gateway" "example" {
  # ... previous configuration ...

  sku {
    name     = "WAF_v2"
    tier     = "WAF_v2"
    capacity = 2
  }

  autoscale_configuration {
    min_capacity = 2
    max_capacity = 10
  }

  backend_http_settings {
    name                  = "http-settings"
    cookie_based_affinity = "Disabled"
    port                  = 80
    protocol              = "Http"
    request_timeout       = 30
    connection_draining {
      enabled           = true
      drain_timeout_sec = 30
    }
  }
}

Logging, Monitoring, and Alerting for Production

You can't fix what you can't see. In production, enable all diagnostic logs: Access Logs, Performance Logs, Firewall Logs, and Health Probe Logs. Send them to Log Analytics for querying. Create dashboards for key metrics like throughput, latency, and failure rates. Set up alerts for backend health degradation, high CPU, and WAF blocked requests. Use Azure Monitor alerts with action groups to notify the on-call team. Also, enable network watcher for connection troubleshoot. In production, we've seen teams miss slow degradation because they only monitored at the VM level. Monitor the gateway itself. A common mistake is not logging WAF false positives—you need those logs to tune rules. Set up a weekly review of WAF logs to adjust rules.

resource "azurerm_monitor_diagnostic_setting" "example" {
  name               = "appgw-diagnostics"
  target_resource_id = azurerm_application_gateway.example.id
  log_analytics_workspace_id = azurerm_log_analytics_workspace.example.id

  log {
    category = "ApplicationGatewayAccessLog"
    enabled  = true
  }

  log {
    category = "ApplicationGatewayPerformanceLog"
    enabled  = true
  }

  log {
    category = "ApplicationGatewayFirewallLog"
    enabled  = true
  }

  metric {
    category = "AllMetrics"
    enabled  = true
  }
}

Zero-Downtime Deployments with Application Gateway

Updating backends without downtime requires careful orchestration. Application Gateway supports rolling updates via backend pools. When deploying a new version, add the new instances to a separate backend pool, update the routing rule to point to the new pool, and then remove the old pool. Use the gateway's connection draining to allow in-flight requests to complete. For blue-green deployments, you can have two listeners pointing to different pools and switch traffic by updating the DNS or using a weighted rule. In production, automate this with Terraform or Azure DevOps. Avoid making changes directly in the portal—they are error-prone. Also, test the new backend pool with a small percentage of traffic before full cutover. We've seen deployments fail because the new backend didn't pass health checks.

resource "azurerm_application_gateway" "example" {
  # ... previous configuration ...

  backend_address_pool {
    name = "backend-blue"
  }

  backend_address_pool {
    name = "backend-green"
  }

  request_routing_rule {
    name                       = "blue-rule"
    rule_type                  = "Basic"
    http_listener_name         = "http-listener"
    backend_address_pool_name  = "backend-blue"
    backend_http_settings_name = "http-settings"
  }

  # During deployment, update the rule to point to green
  # Then remove blue pool after drain
}

Cost Optimization and Right-Sizing

Application Gateway WAF_v2 is not cheap. In production, you need to balance cost with performance. Start with the minimum capacity that meets your baseline traffic and let autoscaling handle spikes. Use reserved instances if you have predictable traffic. Also, consider using Azure Front Door for global traffic and Application Gateway for regional routing—this can reduce the number of gateways needed. Monitor your gateway's throughput and CPU metrics to right-size. If you see consistently low utilization, reduce the minimum capacity. Conversely, if you see throttling, increase the maximum. In production, we've seen teams over-provision out of fear, wasting thousands per month. Use Azure Cost Management to track spending. Also, consider using the Basic tier for non-production environments, but never for production.

resource "azurerm_application_gateway" "example" {
  # ... previous configuration ...

  sku {
    name     = "WAF_v2"
    tier     = "WAF_v2"
    capacity = 2
  }

  autoscale_configuration {
    min_capacity = 2
    max_capacity = 5
  }
}

Disaster Recovery and Multi-Region Failover

For critical applications, you need a disaster recovery plan. Application Gateway is regional, so if a region goes down, your gateway goes with it. To achieve multi-region failover, use Azure Front Door or Traffic Manager in front of Application Gateways in different regions. Front Door provides global load balancing with automatic failover. Configure health probes on each gateway and set up a failover priority. In production, test your failover regularly. We've seen teams configure DR but never test it, only to find out during an actual outage that the secondary gateway was misconfigured. Also, ensure your backends are replicated across regions. Use Azure SQL geo-replication or Cosmos DB multi-region writes. For stateless apps, this is straightforward. For stateful apps, plan for session persistence.

resource "azurerm_frontdoor" "example" {
  name                = "example-fd"
  resource_group_name = azurerm_resource_group.example.name

  routing_rule {
    name               = "primary-rule"
    accepted_protocols = ["Http", "Https"]
    patterns_to_match  = ["/*"]
    frontend_endpoints = ["example-fd"]
    forwarding_configuration {
      backend_pool_name = "primary-backend"
    }
  }

  backend_pool {
    name = "primary-backend"
    backend {
      address     = azurerm_public_ip.primary.fqdn
      http_port   = 80
      https_port  = 443
      priority    = 1
      weight      = 50
    }
    backend {
      address     = azurerm_public_ip.secondary.fqdn
      http_port   = 80
      https_port  = 443
      priority    = 2
      weight      = 50
    }
    health_probe_name = "health-probe"
  }

  health_probe {
    name              = "health-probe"
    path              = "/health"
    protocol          = "Http"
    interval_in_seconds = 30
  }
}

Security Hardening Beyond WAF

WAF is not a silver bullet. In production, you need defense in depth. Start by restricting access to the gateway's frontend IP using NSGs or Azure Firewall. Only allow traffic from known sources (e.g., Cloudflare IPs if you use a CDN). Enable DDoS Protection Standard on the virtual network. Use private IPs for backend communication—never expose backends to the internet. Also, enforce HTTPS only by redirecting HTTP to HTTPS at the gateway level. Set up a custom error page for 403 and 502 errors to avoid leaking information. In production, we've seen attacks that bypass WAF by targeting the backend directly. Always place backends in a private subnet with no public IP. Use service endpoints or Private Link for Azure services.

resource "azurerm_network_security_group" "example" {
  name                = "appgw-nsg"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location

  security_rule {
    name                       = "Allow-HTTP"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "80"
    source_address_prefixes    = ["Internet"]
    destination_address_prefix = "*"
  }

  security_rule {
    name                       = "Allow-HTTPS"
    priority                   = 101
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "443"
    source_address_prefixes    = ["Internet"]
    destination_address_prefix = "*"
  }

  security_rule {
    name                       = "Deny-All"
    priority                   = 200
    direction                  = "Inbound"
    access                     = "Deny"
    protocol                   = "*"
    source_port_range          = "*"
    destination_port_range     = "*"
    source_address_prefixes    = ["*"]
    destination_address_prefix = "*"
  }
}

Troubleshooting Common Production Issues

Even with perfect configuration, things go wrong. Common issues include: 502 Bad Gateway (backend unhealthy or timeout), 403 Forbidden (WAF blocking), and 504 Gateway Timeout (backend too slow). Start troubleshooting by checking the backend health probe status in the portal. If probes are failing, check the backend's health endpoint and network connectivity. For WAF blocks, review the firewall logs to see which rule triggered. For timeouts, increase the request timeout or optimize the backend. Also, check the gateway's performance metrics for CPU or throughput bottlenecks. In production, we've seen a misconfigured NSG block traffic between the gateway and backend. Use Network Watcher's IP flow verify to test connectivity. Always have a rollback plan for configuration changes.

# Check backend health
Get-AzApplicationGatewayBackendHealth -ApplicationGateway $appgw

# View WAF logs
$logs = Get-AzLog -ResourceId $appgw.Id -StartTime (Get-Date).AddHours(-1) -Category "ApplicationGatewayFirewallLog"
$logs | Select-Object -Property *

# Test connectivity
Test-AzNetworkWatcherIPFlow -NetworkWatcher $nw -TargetVirtualMachineId $vm.Id -Direction Outbound -Protocol TCP -LocalPort 80 -RemotePort 80 -RemoteIPAddress $backendIp

URL Rewrite and Redirect Rules: Transforming Requests at the Gateway

Azure Application Gateway supports URL rewrite and redirect rules that transform requests before they reach the backend. URL rewrite allows you to modify the hostname, path, and query string of incoming requests. For example, rewrite all requests from /old-path/ to /new-path/, or strip a version prefix like /v1/api to /api before forwarding to the backend. Redirect rules let you redirect HTTP to HTTPS, redirect from one hostname to another, or redirect specific paths. Both are configured via rewrite rule sets and redirect configurations. In production, redirect HTTP to HTTPS at the gateway level (never at the backend) — this offloads the redirect logic and ensures consistent enforcement. Use URL rewrites for API versioning, legacy URL migration, and path normalization. Combine rewrites with conditions: only rewrite when certain headers or server variables match (e.g., only rewrite /old-path if the User-Agent is not a bot). Rewrite rule sets can also modify request and response headers (e.g., add HSTS headers, remove server version headers). Each rewrite set contains multiple rules with sequence numbers for ordering. Application Gateway for Containers extends rewrite support to the Gateway API and Ingress API. Avoid complex rewrite chains — they add latency and become hard to debug. Test rewrites thoroughly in staging before production deployment.

resource "azurerm_application_gateway" "example" {
  # ... previous configuration ...

  rewrite_rule_set {
    name = "url-rewrite-set"

    rewrite_rule {
      name          = "rewrite-path"
      rule_sequence = 1

      condition {
        variable   = "http_req_Host"
        pattern    = "api.example.com"
        ignore_case = true
      }

      url {
        path         = "/api/"
        query_string = "version=2"
        reroute      = false
      }
    }

    rewrite_rule {
      name          = "add-security-headers"
      rule_sequence = 2

      response_header_configuration {
        header_name  = "Strict-Transport-Security"
        header_value = "max-age=31536000"
      }

      response_header_configuration {
        header_name  = "X-Content-Type-Options"
        header_value = "nosniff"
      }
    }
  }

  # HTTP to HTTPS redirect
  redirect_configuration {
    name = "http-to-https"
    redirect_type = "Permanent"
    target_listener_name = "https-listener"
    include_path = true
    include_query_string = true
  }

  request_routing_rule {
    name                        = "http-redirect-rule"
    rule_type                   = "Basic"
    http_listener_name          = "http-listener"
    redirect_configuration_name = "http-to-https"
  }
}

Custom Error Pages: Branded User Experience for Failures

Application Gateway allows you to replace default error pages with custom branded pages for response codes like 502 Bad Gateway, 403 Forbidden, 503 Service Unavailable, and others. This is critical for production user experience — instead of a generic '502 Bad Gateway' page, users see a company-branded maintenance page with support contact information. Custom error pages can be configured at the global level (applied to all listeners) or at the listener level (per-application granularity). Pages must be publicly accessible HTML files (<1 MB) hosted on Azure Blob Storage or any publicly accessible URL. The gateway fetches the page at configuration time and caches it locally — it does not periodically refresh, so trigger a config update to refresh. In production, use custom error pages for at minimum 502 (backend unavailable) and 403 (WAF blocked). Host error pages in Azure Blob Storage with public access enabled. For listener-level pages, configure them per listener for multi-tenant applications. Common use cases: a maintenance page with an ETA when backends are down during deployments, a 'blocked by WAF' page explaining the block with a contact for false positives, and a branded 'something went wrong' page for 500-level errors. Note that 404 is not currently supported for custom error pages.

# Configure global custom error page for 502
$appgw = Get-AzApplicationGateway -Name prod-appgw -ResourceGroupName prod-rg
$updated = Add-AzApplicationGatewayCustomError `
  -ApplicationGateway $appgw `
  -StatusCode HttpStatus502 `
  -CustomErrorPageUrl "https://mystorage.blob.core.windows.net/errors/502.html"
Set-AzApplicationGateway -ApplicationGateway $updated

# Configure listener-level custom error for 403
$listener = Get-AzApplicationGatewayHttpListener `
  -Name api-listener `
  -ApplicationGateway $appgw
$updatedListener = Add-AzApplicationGatewayHttpListenerCustomError `
  -HttpListener $listener `
  -StatusCode HttpStatus403 `
  -CustomErrorPageUrl "https://mystorage.blob.core.windows.net/errors/403.html"
Set-AzApplicationGateway -ApplicationGateway $appgw

Application Gateway Ingress Controller for AKS: Kubernetes Traffic Management

Application Gateway Ingress Controller (AGIC) enables Azure Kubernetes Service (AKS) to use Application Gateway as the ingress controller, routing external traffic to AKS services. AGIC runs as a pod in AKS and watches for Ingress resources, automatically configuring the Application Gateway with the appropriate listeners, routing rules, and backend pools. This eliminates the need for terraform or manual gateway updates when deploying new services. AGIC supports multiple features: SSL termination with certificates from Key Vault, URL rewrites, session affinity, WAF policies, and private IP exposure. In production, use AGIC for AKS clusters that require WAF protection, SSL offloading, or URL-based routing. Deploy AGIC via ARM template, Terraform, or Helm chart. Configure annotations on Ingress resources to control AGIC behavior: appgw.ingress.kubernetes.io/rewrite-rule-set for URL rewrites, appgw.ingress.kubernetes.io/use-private-ip to expose via private IP, and appgw.ingress.kubernetes.io/ssl-certificate for certificate binding. AGIC supports both AGIC v1 (single tenant) and AGIC v2 (multi-tenant with namespace isolation). For production, use AGIC v2 with managed identity for secure communication. Monitor AGIC logs for errors and use the AGIC dashboard in Azure Monitor. A common pitfall: the Application Gateway subnet must have enough IP addresses for both AGIC and the gateway instances — use a /24 or larger.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  namespace: prod
  annotations:
    appgw.ingress.kubernetes.io/rewrite-rule-set: api-rewrite
    appgw.ingress.kubernetes.io/ssl-certificate: api-cert
    appgw.ingress.kubernetes.io/appgw-ssl-profile: tls-1-2
    appgw.ingress.kubernetes.io/use-private-ip: "false"
spec:
  ingressClassName: azure-application-gateway
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1/*
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
---
apiVersion: appgw.ingress.azure.io/v1beta1
kind: AzureApplicationGatewayRewrite
metadata:
  name: api-rewrite
spec:
  rewriteRules:
  - name: strip-v1
    ruleSequence: 1
    conditions:
    - ignoreCase: true
      negate: false
      variable: http_req_Host
      pattern: "api.example.com"
    actions:
      urlConfiguration:
        modifiedPath: "/"
        reroute: false