Azure Application Gateway overview
Azure Application Gateway sits between clients and your web applications. It accepts HTTP and HTTPS requests, evaluates listener and routing configuration, checks backend health, and forwards traffic only to healthy backend targets. It can also terminate TLS, enforce a Web Application Firewall policy, and rewrite headers or URLs.
What is Azure Application Gateway?
Azure Application Gateway is a managed Layer 7 load balancer and reverse proxy in Microsoft Azure. Unlike a basic network load balancer that only understands IPs, ports, and protocols, Application Gateway understands web traffic patterns such as host headers, URL paths, cookies, and TLS certificates.
What it does well
It routes web traffic to the correct backend using listeners, rules, backend pools, and health probes. It can also protect applications with WAF and simplify certificate handling at the edge.
What it is not
It is not a general TCP or UDP load balancer for any protocol. For non-HTTP or non-HTTPS traffic, Azure Load Balancer is usually the better fit.
Why Azure Application Gateway is used
Teams use Azure Application Gateway when applications need more than simple traffic distribution. It is especially useful when multiple apps share one entry point, when security controls are required, or when routing decisions depend on URLs, hostnames, or web session behavior.
Secure public entry
Publish internet-facing apps through a managed entry layer that supports TLS termination, WAF inspection, and controlled backend exposure.
Smart web routing
Route traffic by domain or path, such as api.example.com to APIs and /images/* to a content service.
Operational simplicity
Centralize web traffic handling rather than configuring TLS, redirects, and path rules separately on every application server.
Azure Application Gateway explained with the 5 Ws + How
This format helps beginners, working engineers, and interview learners quickly understand what the service is, why it exists, and where it fits inside Azure networking.
What
A managed Layer 7 load balancer and reverse proxy for web traffic in Azure.
Why
To securely publish and intelligently route HTTP and HTTPS traffic to one or more backend applications.
When
Use it when you need WAF, TLS termination, URL path routing, host-based routing, header rewrite, or centralized web traffic management.
Where
It is deployed inside an Azure virtual network and usually fronts Azure VMs, VM Scale Sets, AKS ingress targets, App Services behind private endpoints, or internal application tiers.
Who
Cloud engineers, platform engineers, DevOps teams, security teams, and solution architects managing public web entry.
How
Client traffic reaches a frontend listener, is matched against routing rules, checked against probe status, optionally inspected by WAF, and then forwarded to healthy backends.
SKU and deployment modes
Understanding the available modes matters because features, scaling behavior, and best practices depend on the SKU.
Standard_v2
Best for most modern deployments that need autoscaling, better performance, and production-ready application delivery without necessarily turning on WAF.
WAF_v2
Best when you need all the advantages of the v2 platform plus Web Application Firewall capabilities for common web threats.
Public vs private frontend
| Mode | Use case | Typical pattern |
|---|---|---|
| Public frontend IP | Internet-facing applications | Users on the internet access the gateway directly |
| Private frontend IP | Internal-only applications | Used for internal apps, east-west routing, or private enterprise access |
| Dual frontend | Mixed access needs | One gateway serves both internal and external entry requirements |
Core components of Azure Application Gateway
Azure Application Gateway becomes easier to design once you understand its building blocks. Most troubleshooting also comes down to checking one of these components.
Frontend IP
The public or private address where the gateway receives client traffic.
Listener
Defines which protocol, port, hostname, and certificate settings are used to accept traffic.
Backend pool
A collection of targets such as IP addresses, NICs, VMs, or other backend endpoints.
Health probe
Continuously checks backend health so unhealthy instances do not receive production traffic.
Routing rule
Connects a listener to a backend pool and backend HTTP settings, optionally using path maps.
Backend HTTP settings
Controls how the gateway talks to the backend, including protocol, port, timeout, cookie affinity, and host headers.
Path-based rule
Routes requests like /api/* and /images/* to different services.
WAF policy
Adds web application security inspection and threat filtering for common application attacks.
Rewrite rules
Modify headers or URLs to support application behavior, proxies, or security requirements.
How Azure Application Gateway works
The service follows a clear request flow. Once you understand the flow, troubleshooting listener issues, routing problems, certificate mismatches, and unhealthy backends becomes much easier.
Step-by-step request flow
- Client sends HTTP or HTTPS traffic to the gateway frontend IP.
- Listener accepts the request based on protocol, port, hostname, and certificate configuration.
- Optional WAF policy inspects the request.
- Routing rules evaluate the request and choose the right backend target.
- Health probe status is checked to confirm backend availability.
- Traffic is forwarded to a healthy backend using the configured HTTP settings.
- Response returns to the client through the gateway.
Important operational behavior
- Only healthy backends receive traffic.
- TLS can be terminated at the gateway instead of every backend.
- One gateway can host multiple sites with different listeners and rules.
- Path-based routing reduces the need for multiple public entry points.
Architecture diagram
A simple architecture example for Azure Application Gateway serving multiple applications behind one entry layer.
Internet Users
|
v
+-------------------------------+
| Azure Application Gateway |
| - Public Frontend IP |
| - HTTPS Listener |
| - WAF Policy |
| - Path / Host Rules |
+-------------------------------+
| |
| |
v v
/api/* /web/*
| |
v v
+-------------+ +-------------+
| Backend API | | Backend Web |
| App / AKS | | VM / AppSvc |
+-------------+ +-------------+
Health probes continuously verify backend health before traffic is sent.
Real-world Azure Application Gateway use cases
Good pages need practical examples, not only theory. These are the kinds of deployments where Application Gateway makes sense in real environments.
Enterprise web portal
A company hosts HR, payroll, and employee self-service applications under one domain and uses host- and path-based routing to send traffic to the right application stack.
API and UI split
The main website goes to the frontend application, while /api/ traffic is sent to a separate backend API pool
with different health probes and timeout settings.
AKS ingress pattern
Teams running Kubernetes in Azure use Application Gateway as a managed north-south web entry point in front of cluster-hosted services.
Azure Application Gateway vs related Azure services
One of the biggest design mistakes is choosing the wrong entry service. Use this comparison to understand when Azure Application Gateway is the right fit and when another service is better.
| Service | Layer | Best for | When to choose it |
|---|---|---|---|
| Azure Application Gateway | Layer 7 | Web apps, APIs, WAF, URL/host routing | Choose when you need application-aware routing and security inspection |
| Azure Load Balancer | Layer 4 | TCP/UDP balancing | Choose for raw network traffic, not advanced HTTP features |
| Azure Front Door | Layer 7 global edge | Global entry, CDN-like edge acceleration, multi-region | Choose for global distribution and edge-based web acceleration |
| Azure Firewall | Network security | Central network policy and filtering | Do not use as a replacement for Application Gateway web routing |
Application Gateway vs Azure Load Balancer
Use Application Gateway when decisions depend on URLs, host headers, TLS certificates, or WAF. Use Azure Load Balancer when you need simple Layer 4 balancing for any TCP or UDP traffic.
Application Gateway vs Azure Front Door
Use Application Gateway for regional or VNet-integrated application entry. Use Azure Front Door when you want a global entry point closer to end users with cross-region routing and edge presence.
Best practices
These recommendations make Azure Application Gateway designs cleaner, safer, and easier to operate in production.
Use WAF_v2 for internet-facing apps
When applications are public, WAF is usually worth enabling to improve protection against common web threats.
Keep probes realistic
Probe health endpoints that actually represent application readiness instead of only checking that a TCP port is open.
Separate apps with listeners and rules
Use host- and path-based routing carefully so traffic patterns stay predictable and easy to troubleshoot.
Use TLS termination intentionally
Offload certificates at the gateway when it simplifies operations, but document whether backend re-encryption is required.
Review NSGs and routing
The gateway may be healthy while backends remain unreachable because of subnet, route table, or NSG issues.
Plan for observability
Enable logs and metrics so you can trace backend health failures, latency patterns, TLS problems, and WAF blocks.
Common mistakes
These are the problems engineers repeatedly run into when deploying Azure Application Gateway for the first time.
Using it for the wrong protocol
Application Gateway is not the right tool for generic TCP or UDP balancing outside of HTTP and HTTPS needs.
Probe path mismatch
If the health probe path is wrong, the backend appears unhealthy even though the application is actually running.
Ignoring backend settings
Wrong host header, timeout, or protocol settings between gateway and backend often cause hard-to-debug failures.
Confusing it with Front Door
Application Gateway is great regionally, but it is not the same as a global edge routing service.
Weak certificate planning
Teams sometimes deploy quickly without considering certificate rotation, TLS policy consistency, or hostname coverage.
No clear routing documentation
Path maps and listeners become hard to manage when multiple teams keep adding rules without a standard pattern.
Frequently asked questions
These questions target the kind of search intent real users often have around Azure Application Gateway.
Is Azure Application Gateway the same as Azure Load Balancer?
No. Azure Application Gateway is a Layer 7 service for HTTP and HTTPS traffic with smart routing and WAF support. Azure Load Balancer is a Layer 4 service for TCP and UDP balancing.
When should I use Azure Application Gateway instead of Azure Front Door?
Use Application Gateway when you need regional, VNet-aware application entry inside Azure. Use Front Door when you need global edge entry, acceleration, and multi-region routing for internet users.
Can Azure Application Gateway protect web applications?
Yes. With WAF_v2, it can inspect and filter web requests to help protect applications from many common Layer 7 threats.
Does Azure Application Gateway do TLS termination?
Yes. It can terminate HTTPS at the gateway so backends do not always need to manage public-facing certificates individually.
Can one Application Gateway serve multiple sites?
Yes. Multi-site listeners and host-based routing allow one gateway to publish multiple web applications using different domains.