Azure Application Gateway

About Azure Application Gateway

Azure Application Gateway is Microsoft Azure's regional application delivery service for web traffic. It is built around HTTP and HTTPS routing, backend health, TLS handling, autoscaling and optional Web Application Firewall protection. Application Gateway v2 is the current production generation after Application Gateway v1 retired on April 28, 2026. It is a strong fit when an application needs regional Layer 7 routing close to Azure workloads, while Azure Front Door is usually the better fit for global edge delivery and Azure Load Balancer for general Layer 4 TCP or UDP balancing.

What is Azure Application Gateway used for?

Azure Application Gateway sits in front of web applications and distributes incoming requests across healthy backend targets. Microsoft documents backend support for Azure virtual machines, virtual machine scale sets, Azure App Service and reachable on-premises or external servers. The service can use public or private frontend addresses, so it can protect internet-facing applications or serve internal application traffic inside a virtual network.

The main difference from a traditional network load balancer is that Application Gateway understands application-layer request information. It can route by host name or URL path, redirect requests, terminate TLS, preserve end-to-end TLS to backends and use cookie-based session affinity when an application needs it. These features make it useful for regional websites, APIs, multi-site hosting and applications that need a web-aware routing layer before the backend.

What is the current Application Gateway generation?

Application Gateway v2 is the current production generation. Microsoft states that Application Gateway v1 retired on April 28, 2026 and is no longer supported. Existing v1 customers should migrate to v2 rather than extending the retired architecture.

The v2 generation adds important operational improvements over v1, including autoscaling, zone redundancy, static virtual IP addresses, faster provisioning and configuration updates, header rewrite support and current Web Application Firewall capabilities. Microsoft also documents TCP and TLS proxy support in v2 for selected scenarios, although the product remains primarily positioned as an application delivery controller for web traffic. New deployments should be designed against current v2 documentation rather than older v1 sizing or pricing guidance.

How do listeners, routing rules and backend pools work?

An Application Gateway configuration connects a frontend address to listeners, routing rules, backend pools, backend settings and health probes. A listener accepts incoming traffic for a defined protocol, port and optional host name. Routing rules then decide which backend pool should receive the request. URL path routing can send different parts of one site to different backends, while multisite hosting can route several host names through one gateway.

Health probes determine whether a backend is available for new requests. Production teams should configure probes around the actual application health endpoint rather than only checking whether a port is open. Application Gateway does not make a failing application healthy by itself. Resilience still depends on multiple backend instances, zone or region design, database availability and tested failover behavior.

How do TLS termination and Web Application Firewall work?

Application Gateway can terminate TLS at the gateway and send traffic to backends over HTTP or HTTPS according to the design. It also supports end-to-end TLS so traffic can remain encrypted between the gateway and backend. This can simplify certificate management at the frontend while preserving encrypted backend communication where required.

The WAF_v2 option integrates Azure Web Application Firewall with Application Gateway. Microsoft documents managed rules, custom rules and protection for common web attacks, while the current pricing documentation states that WAF Policy and WAF rules do not add a separate charge when using the WAF or WAF_v2 Application Gateway SKU. WAF still requires policy tuning, monitoring and application testing. Teams should review blocked requests and false positives instead of assuming the default rules require no operational ownership.

How do autoscaling and zone redundancy work?

Application Gateway v2 supports autoscaling so gateway capacity can expand and contract with traffic rather than requiring a fixed instance size. Microsoft also documents zone redundancy, and the current portal quickstart states that Application Gateways are zone-redundant by default in regions that support multiple availability zones.

Autoscaling reduces manual capacity planning but does not remove all performance planning. Backend capacity, connection patterns, TLS workload, WAF processing, large responses and sudden traffic changes can still affect application behavior. Teams should monitor gateway and backend metrics together. A gateway that scales successfully can still overwhelm an undersized application or database behind it.

How does Azure Application Gateway pricing work?

Azure Application Gateway does not have one universal monthly price. Microsoft's current pricing page bills Application Gateway v2 using a fixed gateway-hour component plus capacity-unit usage. Capacity units reflect compute, persistent connections and throughput. Outbound data transfer from Azure is charged separately under standard data-transfer rates, while inbound transfer is listed as free.

Pricing was checked on August 26, 2026. Microsoft also lists a Basic Application Gateway preview and Application Gateway for Containers as separate options with different billing models. Because rates vary by region, agreement, traffic profile, WAF choice and capacity consumption, buyers should estimate the exact architecture in the Azure pricing calculator rather than using one sample monthly amount. A low-traffic gateway can still have baseline cost because the service remains provisioned.

How does Application Gateway compare with Load Balancer and Front Door?

Azure Load Balancer is the better starting point for regional Layer 4 TCP or UDP distribution when the application does not need HTTP-aware routing, TLS termination or web application firewall functions. Azure Application Gateway is the regional Layer 7 option for web applications that need host routing, URL path routing, TLS handling, session affinity or WAF close to the workload.

Azure Front Door is a global edge service. It is designed for globally distributed HTTP and HTTPS applications that benefit from edge routing, CDN caching, acceleration, global failover and edge security. Large architectures can use these services together, but buyers should avoid layering them without a clear requirement because every additional hop adds cost, configuration and troubleshooting complexity.

What are the main limitations and migration considerations?

Application Gateway is a dedicated deployment in an Azure virtual network and requires its own subnet. That creates more networking design than a simple application-hosting service. Teams need to plan frontend addresses, DNS, subnet capacity, backend reachability, certificates, probes, routing rules, WAF policy, logging and application behavior. Configuration changes can also require time to propagate.

Organizations migrating from v1 need to treat the change as a real platform migration because v1 retired on April 28, 2026. Microsoft provides migration guidance and scripts, but teams remain responsible for traffic cutover, validation and any feature differences. Older TLS assumptions should also be removed from designs because Microsoft retired TLS 1.0 and 1.1 support on Application Gateway on August 31, 2025.

Who should choose something else?

Choose Azure Load Balancer when the main requirement is high-performance TCP or UDP distribution without application-layer routing. Choose Azure Front Door when users are geographically distributed and the application needs a global edge entry point, CDN caching or global failover. Teams running Kubernetes should also evaluate whether native ingress, Gateway API options or Application Gateway for Containers better match their platform architecture.

Azure Application Gateway is strongest for regional HTTP and HTTPS applications that need application-aware routing, TLS termination, autoscaling, zone redundancy and optional WAF protection near the workload. Buyers should choose it when those regional Layer 7 controls solve a concrete application-delivery problem rather than because every Azure web application needs an additional gateway.