Application Gateway and WAF concepts

Overview

Azure Application Gateway is a regional reverse proxy and web traffic load balancer. It operates primarily at Layer 7, understands HTTP and HTTPS requests, and can route traffic by hostname, URL path, and other application-level attributes.

A typical request flow is:

1. A client connects to a public or private frontend IP.
2. A listener accepts traffic that matches its protocol, port, hostname, and frontend.
3. A routing rule selects a backend pool and backend settings.
4. Web Application Firewall, or WAF, rules inspect the request when WAF is enabled.
5. Application Gateway forwards allowed traffic to a healthy backend.
6. The response returns through the gateway to the client.

Application Gateway is commonly used for:

• Publishing regional web applications.
• TLS termination or end-to-end TLS.
• Host-based and path-based routing.
• Load balancing across healthy application instances.
• Protecting web workloads with WAF.
• Exposing private backends through a controlled entry point.
• Consolidating multiple sites behind one gateway.

Azure WAF on Application Gateway provides centralized protection against common HTTP attacks and protocol anomalies. It uses managed rule sets, custom rules, exclusions, request-size controls, and bot protection capabilities. WAF reduces risk, but it does not replace secure coding, authentication, authorization, patching, DDoS protection, or application monitoring.

For interviews, candidates should be able to:

• Explain each Application Gateway component and the request path.
• Distinguish Application Gateway from Azure Load Balancer, Azure Front Door, Azure API Management, and Azure Firewall.
• Describe TLS termination, end-to-end TLS, backend health probes, and common 502 failures.
• Explain WAF detection and prevention modes.
• Distinguish managed rules, custom rules, exclusions, and disabled rules.
• Discuss safe WAF tuning without creating broad security gaps.
• Design a highly available, observable, and privately connected deployment.

Core Concepts

Regional Layer 7 Reverse Proxy

Application Gateway is a regional service. It accepts client connections and creates separate connections to backend servers. Because it proxies HTTP traffic, it can make decisions using:

• Host headers.
• URL paths.
• HTTP methods.
• Listener configuration.
• Backend health.
• Redirect and rewrite rules.

This differs from a Layer 4 load balancer, which primarily distributes TCP or UDP flows using IP addresses and ports without understanding HTTP routes.

Application Gateway can be internet-facing, private, or configured with both public and private frontends where supported by the selected deployment configuration. A private frontend is useful for internal applications reached through peering, VPN, ExpressRoute, or connected virtual networks.

Frontend IP Configuration

The frontend IP is the address clients use to reach the gateway. It can be associated with:

• A public IP for internet-facing applications.
• A private IP from the Application Gateway subnet for internal applications.
• Public and private frontends for workloads that need both entry paths.

DNS records should normally point application hostnames to the gateway frontend. Clients should use the intended hostname rather than depending directly on an IP address because listeners, certificates, and routing often depend on hostnames.

Listeners

A listener accepts traffic that matches configured connection properties:

• Frontend IP.
• Port.
• Protocol.
• Hostname or hostnames.
• TLS certificate for HTTPS listeners.

A basic listener handles traffic without hostname-specific matching. A multi-site listener uses hostnames to publish multiple sites on the same gateway.

For example:

shop.example.com  -> commerce backend pool
admin.example.com -> administration backend pool

Listener specificity and routing-rule priority matter when wildcard and exact hostnames overlap. Configuration should make the intended match deterministic.

Routing Rules and URL Path Maps

A request routing rule connects:

• A listener.
• A backend pool or redirect.
• Backend settings.
• Optionally, a URL path map or rewrite set.

A basic rule sends all matching listener traffic to one backend pool. A path-based rule selects a backend based on URL path patterns.

/api/*    -> API backend pool
/images/* -> static-content backend pool
/*        -> web frontend pool

Every path map needs a sensible default backend. Paths should be tested for ordering, wildcard behavior, trailing slashes, URL encoding, and unexpected routes.

Application Gateway routing is useful for infrastructure-level dispatch. Complex business routing, authorization decisions, and workflow logic belong in the application or a purpose-built API gateway.

Backend Pools

A backend pool is a collection of destinations that can serve requests. Members can include:

• Virtual machine network interfaces.
• Virtual machine scale sets.
• Private IP addresses.
• Public IP addresses.
• Fully qualified domain names.
• Supported multitenant services such as App Service or Container Apps.
• Reachable on-premises or external servers.

Application Gateway requires network reachability and working DNS resolution for the selected backend members. A backend pool does not by itself define how to connect; backend settings provide protocol, port, host behavior, timeout, and related options.

Backend Settings

Backend settings control the gateway-to-backend connection. Important settings include:

• HTTP or HTTPS.
• Backend port.
• Request timeout.
• Hostname selection or override.
• Cookie-based affinity.
• Connection draining.
• Trusted root certificates or certificate validation behavior.
• Associated health probe.

The host header is especially important for multitenant backends. App Service and similar platforms often require a hostname that matches the application binding. An incorrect host override can cause redirects, certificate mismatch, authentication failure, or an unhealthy probe.

Health Probes

Application Gateway sends health probes to decide which backend members can receive traffic. Unhealthy members are temporarily removed from load balancing and restored after successful probes.

Custom probes can define:

• Protocol and port.
• Host header.
• Request path.
• Probe interval.
• Timeout.
• Failure threshold.
• Accepted status-code range.
• Optional response-body matching.

A good health endpoint checks whether an instance can safely serve traffic. It should be:

• Fast.
• Unauthenticated or accessible only through an appropriate probe path.
• Free of side effects.
• Representative without depending on every downstream service.

A probe that always returns success can route traffic to a broken instance. A probe that checks every dependency can remove all instances during a downstream outage and amplify the failure. Many systems separate liveness from readiness and use a readiness-style endpoint for load-balancer routing.

TLS Termination and End-to-End TLS

With TLS termination, the client establishes HTTPS to Application Gateway, and the gateway decrypts the request. The backend connection can then use HTTP or HTTPS.

Benefits include:

• Central certificate management.
• Reduced TLS processing on application servers.
• WAF inspection of decrypted HTTP content.
• Consistent TLS policy at the entry point.

If the backend connection uses HTTP, traffic is unencrypted between the gateway and backend. This may violate security or compliance requirements even when traffic stays on a private network.

End-to-end TLS uses:

Client --HTTPS--> Application Gateway --HTTPS--> Backend

The gateway still terminates the client-side connection and establishes a new TLS connection to the backend. Backend certificate validation, hostname configuration, certificate rotation, and trust chains must be planned carefully.

Certificate and TLS Operations

Certificate operations should include:

• Automated renewal where possible.
• Expiration alerts.
• Secure storage, commonly through Key Vault integration where supported.
• Explicit ownership for certificate and DNS changes.
• Testing of certificate chains and hostname bindings.
• Controlled TLS policy updates.

A certificate can be valid but still fail because the hostname sent to the backend does not match the certificate, an intermediate certificate is missing, or the gateway does not trust the issuer.

Autoscaling, Capacity, and Zone Redundancy

The v2 SKU supports autoscaling and zone-redundant deployment options. Autoscaling adjusts capacity to changing traffic, but it is not instantaneous and does not make a poorly designed backend resilient.

Capacity planning should consider:

• Request rate.
• Concurrent connections.
• TLS processing.
• Response size.
• WAF inspection cost.
• Long-lived WebSocket connections.
• Minimum instance capacity.
• Sudden traffic spikes.

A nonzero minimum capacity can reduce scale-from-low-capacity risk. Zone redundancy improves resilience to zonal failures, while backend pools should also span failure domains. A redundant gateway cannot compensate for a single-instance backend.

Connection Draining and Session Affinity

Connection draining stops sending new requests to a backend member while allowing existing requests to finish for a configured period. It is useful during rolling deployments and planned scale-in.

Cookie-based affinity keeps a client associated with one backend instance. It can support legacy applications with in-memory session state, but it introduces trade-offs:

• Uneven load distribution.
• Session loss when an instance fails.
• Harder deployments and scaling.
• More stateful application behavior.

Prefer stateless application instances with shared or external session storage when practical.

Redirects and Rewrites

Application Gateway can:

• Redirect HTTP to HTTPS.
• Redirect between listeners or external locations.
• Rewrite request and response headers.
• Rewrite URL paths and query strings.
• Add security-related headers.
• Remove headers that reveal backend implementation details.

Rewrites are appropriate for infrastructure concerns and compatibility. They should not become hidden application logic. Document and test rewrites because a gateway-level change can affect every request before application logs are produced.

Application Gateway WAF

WAF inspects HTTP traffic passing through Application Gateway. It is designed to reduce exposure to common web attacks such as:

• SQL injection.
• Cross-site scripting.
• Command injection.
• Remote file inclusion.
• Request smuggling patterns.
• Protocol violations and malformed requests.
• Known malicious bots and scanners when bot rules are enabled.

WAF evaluates request attributes such as headers, cookies, query parameters, paths, and supported request bodies. Inspection is constrained by configured request-body and file-upload limits.

WAF is not a vulnerability scanner and does not understand application intent. It cannot determine whether an authenticated user is allowed to access another user's order or whether a transfer amount violates business rules.

WAF Policies

A WAF policy contains:

• Policy mode.
• Managed rule sets.
• Managed-rule overrides.
• Custom rules.
• Exclusions.
• Request body and size settings.
• File upload limits.
• Bot protection configuration where used.

A policy can be associated at different scopes, including:

• An entire Application Gateway.
• A listener or site.
• A path-based rule.

Per-site or per-path policies are useful when applications have different risk profiles or payload formats. Excessive policy fragmentation increases operational overhead and can cause inconsistent protection.

Detection and Prevention Modes

In detection mode, WAF evaluates traffic and logs matches but does not block requests based on those managed-rule detections. Detection mode is useful for:

• Initial deployment.
• Rule-set upgrades.
• Learning normal traffic.
• Identifying false positives.
• Testing exclusions and custom rules.

In prevention mode, WAF blocks traffic when configured rule behavior determines it is malicious. Blocked requests normally return an HTTP error such as 403 and are recorded in WAF logs.

A safe rollout is:

1. Enable diagnostics.
2. Deploy in detection mode.
3. Observe representative production traffic.
4. Investigate matches.
5. Add narrow, justified tuning.
6. Test critical user journeys.
7. Switch to prevention mode.
8. Alert on blocking changes and anomalies.

Detection mode should be a controlled rollout phase, not an indefinite substitute for enforcement.

Managed Rule Sets and Anomaly Scoring

Managed rule sets provide Microsoft-maintained protections based on common attack patterns. Rules are grouped by attack category and have identifiers that can be tuned individually.

Modern rule sets can use anomaly scoring. Multiple rule matches contribute scores based on severity. In prevention mode, a request is blocked when the accumulated score reaches the blocking threshold.

Anomaly scoring reduces dependence on a single low-confidence match, but teams must still inspect the complete set of matched rules. Disabling only the final blocking rule does not necessarily address the underlying matches correctly.

Managed rule-set versions should be treated like production dependencies:

• Review release changes.
• Test upgrades.
• Monitor false positives and new detections.
• Keep an inventory of overrides and their reasons.
• Remove temporary exceptions after application fixes.

Custom Rules

Custom rules evaluate before managed rules and use an explicit priority. They can match attributes such as:

• Source IP.
• Geographic location.
• Request URI.
• Headers.
• Cookies.
• Query parameters.
• Request method.

Typical uses include:

• Blocking known hostile IP ranges.
• Restricting an administration route.
• Applying geo-based policy where legally and operationally appropriate.
• Rejecting unexpected methods on a path.
• Allowing a narrowly identified trusted integration.

An allow rule is powerful because rule processing can stop after a match. A broad allow condition can bypass managed-rule inspection for traffic that should still be inspected. Prefer precise conditions and review custom-rule precedence.

Exclusions and False Positives

An exclusion tells WAF not to inspect a specific request attribute under defined conditions. It may be needed when legitimate content resembles an attack signature, such as encoded tokens, rich text, or generated identifiers.

Safe tuning follows least privilege:

• Exclude a specific parameter, cookie, or header rather than the entire request body.
• Scope the exclusion to the affected rule or rule group when possible.
• Avoid disabling a complete managed rule group for one endpoint.
• Record the false-positive evidence and business owner.
• Add regression tests for both legitimate and malicious inputs.
• Review exceptions periodically.

WAF exclusions reduce inspection. They should be treated as security-sensitive changes, not routine application configuration.

WAF, DDoS Protection, and Secure Coding

These controls solve different problems:

• WAF: Inspects application-layer HTTP requests for malicious patterns.
• Azure DDoS Protection: Helps protect network resources from volumetric and protocol-level attacks.
• Application rate limiting: Controls abusive or excessive operations using application or identity context.
• Secure code: Prevents vulnerabilities at their source.
• Authentication and authorization: Establish and enforce caller permissions.

WAF can provide virtual-patch protection while an application fix is developed, but the underlying vulnerability should still be corrected.

Logging and Observability

Important telemetry includes:

• Access logs.
• Performance metrics.
• WAF logs.
• Backend health.
• Failed request counts.
• Response status distribution.
• Capacity and connection metrics.
• TLS and certificate alerts.

Useful alerts include:

• Increase in 502 responses.
• Sudden WAF blocks after a deployment.
• Repeated attacks against a sensitive route.
• All members of a backend pool becoming unhealthy.
• Capacity approaching expected limits.
• Certificate expiration.

Logs should include enough context to correlate a gateway request with backend application telemetry. Sensitive headers, tokens, or request bodies must not be exposed carelessly in diagnostic data.

Troubleshooting 502 and Backend Health Failures

Application Gateway commonly returns 502 when it cannot successfully communicate with a healthy backend. Investigation should check:

1. Backend health status and probe error.
2. DNS resolution from the gateway environment.
3. NSG, route table, firewall, and backend access restrictions.
4. Backend port and protocol.
5. Host header and probe hostname.
6. TLS trust, certificate chain, and hostname match.
7. Request timeout and backend response time.
8. Application process health and listening address.

Changing the probe to accept every response may hide the symptom while leaving the backend broken. Diagnose the failed layer rather than weakening health checks.

Comparing Related Azure Services

Services can be combined. For example, Front Door can provide a global edge while Application Gateway provides regional ingress to private backends. Every additional proxy increases cost, latency, certificate ownership, logging complexity, and troubleshooting paths, so each layer needs a clear responsibility.

Common Mistakes

Common design and operational mistakes include:

• Treating WAF as a replacement for secure coding.
• Switching immediately to prevention mode without observing legitimate traffic.
• Creating broad exclusions or allow rules to fix one false positive.
• Using an incorrect backend host header.
• Relying on default probes for an application with a custom health path.
• Terminating TLS and sending sensitive traffic to backends over HTTP without evaluating risk.
• Deploying a redundant gateway in front of a single backend instance.
• Assuming autoscaling handles instantaneous traffic spikes.
• Failing to enable WAF and access diagnostics before an incident.
• Mixing Application Gateway routing with extensive business logic.
• Exposing backends publicly even though all normal traffic should enter through the gateway.

Best-Practice Design Checklist

A production design should normally:

• Prefer the current v2 SKU for new supported deployments.
• Use explicit hostnames and HTTPS listeners.
• Automate certificate renewal and expiration monitoring.
• Encrypt backend traffic when required by the threat model.
• Configure representative custom health probes.
• Spread gateway and backend capacity across failure domains.
• Restrict backend ingress so clients cannot bypass the gateway.
• Start WAF in detection mode, tune narrowly, then enforce prevention.
• Store WAF policies and gateway configuration as infrastructure as code.
• Review managed rule-set versions and exceptions regularly.
• Enable access, WAF, health, and performance telemetry.
• Load-test routing, TLS, WAF, scaling, and failure behavior before production.