Azure Application Gateway is a managed web traffic load balancer for Azure. It operates at the application layer, making routing decisions using details such as the HTTP host name, URL path, and TLS connection—not just the destination IP address and port.

That makes Application Gateway a useful front door for web applications running on Azure App Service, virtual machines, virtual machine scale sets, and other back-end services. It can provide a single public entry point while keeping the application back ends private, centralising routing rules, and giving us a place to manage web traffic policies.

This is the first post in a series about designing, deploying, and operating Azure Application Gateway.

What is Application Gateway?

Application Gateway is an Azure-managed Layer 7 load balancer. A client connects to the gateway, and the gateway evaluates the request before forwarding it to a healthy back-end target.

At a high level, a gateway configuration contains:

• Front-end IP configurations — the public or private address clients connect to.
• Listeners — the protocol, port, host name, and TLS settings accepted by the gateway.
• Routing rules — the rules that connect listeners to back-end pools and HTTP settings.
• Back-end pools — the App Services, virtual machines, IP addresses, or other targets that receive traffic.
• HTTP settings — the back-end protocol, port, host name, cookie-based affinity, connection draining, and health probe behaviour.
• Health probes — checks that determine whether a back-end target can receive traffic.

For example, app.example.com and api.example.com can share one gateway while routing to different back-end pools. Likewise, /images and /api can be sent to separate services using path-based routing.

Why use Application Gateway?

Layer 7 routing

Unlike a basic network load balancer, Application Gateway understands HTTP and HTTPS requests. Host-based and URL path-based routing allow multiple applications or services to share a gateway and a public IP address.

TLS termination

The gateway can terminate TLS connections from clients before forwarding requests to the back end. This can simplify certificate management at the application layer and gives us a central place to configure HTTPS listeners. End-to-end TLS is also possible when the connection from the gateway to the back end must remain encrypted.

TLS configuration and certificate management will be covered in part four.

Web Application Firewall

The Web Application Firewall (WAF) capability helps protect web applications from common attacks described by the Open Web Application Security Project (OWASP). It supports managed rule sets as well as custom rules for requirements specific to an application.

WAF is not a replacement for secure application development, identity controls, or network segmentation. It is one layer in a broader defence-in-depth strategy.

Private back ends

Application Gateway can expose a controlled public endpoint while the application back ends remain on a virtual network or use private connectivity. This reduces the number of services that need to be directly reachable from the internet.

Centralised traffic management

Routing, probes, redirects, rewrite rules, TLS policies, and WAF policies can be managed in one service. This is particularly useful when several applications need consistent ingress behaviour without each application implementing its own edge configuration.

Application Gateway versions

There are two current generations to understand when planning a deployment:

Application Gateway v2

Application Gateway v2 is the recommended generation for new deployments. It provides the modern feature set, including autoscaling, zone redundancy where supported, static public IP support, improved performance, and private front-end IP support.

The v2 family includes:

• Standard_v2 — application delivery and Layer 7 load-balancing features.
• WAF_v2 — the same core capabilities with Web Application Firewall functionality.

v2 instances can scale based on traffic, which avoids choosing a fixed instance count for the entire lifetime of an application. The minimum instance count still matters, particularly for availability, cost, and whether the gateway is deployed across availability zones.

Application Gateway v1

The original v1 generation includes Standard and WAF SKUs. It uses a fixed instance model and does not provide the newer v2 capabilities such as autoscaling and zone redundancy.

For new solutions, v2 should normally be the starting point. Existing v1 gateways may still need to be assessed and migrated rather than replaced without planning. Before choosing a SKU, check the current Azure documentation for regional availability, feature support, pricing, and migration guidance.

Application Gateway and other Azure edge services

Application Gateway is not interchangeable with every Azure traffic service. The right choice depends on where traffic originates and what kind of routing is required.

These services can also be combined. For example, Azure Front Door can provide global entry and Application Gateway can provide regional routing, private back-end access, and WAF policy enforcement. That design introduces additional complexity, so it should be driven by a clear requirement such as global failover, multi-region delivery, or a specific security boundary.

Considerations before deploying

Application Gateway is powerful, but it is not automatically the best choice for every application. Before deploying one, consider:

• Traffic scope: Is the application regional, or does it need global entry and failover?
• Back-end connectivity: Can the gateway reach the target over the required network path, DNS name, and port?
• Health probes: Does the probe use the correct host name, path, status codes, and TLS settings?
• TLS ownership: Where should certificates be stored, renewed, and rotated?
• Availability: Do the region and SKU support zone redundancy, and what minimum capacity is appropriate?
• Cost: Will autoscaling, WAF processing, public IPs, and data transfer affect the design?
• Operations: How will access logs, performance metrics, WAF events, and alerts be monitored?

Many Application Gateway issues are caused by a mismatch between the listener, routing rule, HTTP setting, probe, and back-end host name. Treat those components as one request flow when designing and troubleshooting the gateway.

The series

This series will build an Application Gateway configuration in stages:

1. Introduction — what Application Gateway is, why to use it, and how the versions compare.
2. Deploying with infrastructure as code — create a repeatable gateway deployment using IaC.
3. Example configurations — route traffic to Azure App Service and virtual machine back ends.
4. TLS configuration and certificate management — configure HTTPS, certificates, renewal, and end-to-end TLS.
5. Application Gateway with Azure Front Door — understand when and how to combine regional and global ingress services.

Conclusion

Azure Application Gateway is a strong fit when an application needs managed regional Layer 7 ingress, host or path-based routing, centralised TLS handling, or an optional WAF. Application Gateway v2 is generally the right generation for new deployments, but the surrounding architecture still matters: back-end connectivity, health probes, certificates, availability, monitoring, and cost all need to be designed together.

In the next post, we will move from concepts to a repeatable Application Gateway deployment using infrastructure as code.

References

• Azure Application Gateway overview
• What is Azure Application Gateway v2?
• Azure Application Gateway pricing
• Azure Application Gateway frequently asked questions