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