This guide explains Application Gateway from a practical DevOps perspective: what it is, how a request moves through it, which components matter, when to use it, and where teams commonly get configuration wrong.
Key Takeaways
- Azure Application Gateway is a Layer 7 web traffic load balancer for HTTP and HTTPS applications.
- It can route requests based on URL paths, hostnames, listeners, and routing rules.
- A typical request passes through the frontend IP, listener, optional WAF, routing rule, backend pool, health probe, and backend settings.
- Application Gateway supports TLS termination, end-to-end TLS, Web Application Firewall, autoscaling, zone redundancy, URL rewriting, redirects, and session affinity.
- The current generation is Application Gateway v2, available as Standard_v2 and WAF_v2. Application Gateway v1 retired on April 28, 2026.
- Application Gateway requires a dedicated subnet inside an Azure virtual network.
- It is most useful when traffic needs application-aware routing or web security rather than simple IP-and-port load balancing.
What Is Azure Application Gateway?
Azure Application Gateway is a Layer 7 web traffic load balancer that routes HTTP and HTTPS requests to backend applications based on application-level information such as URL paths and host headers. Unlike a traditional transport-level load balancer, it can inspect the request and make routing decisions before sending traffic to the appropriate backend.
For example, imagine an application with these endpoints:
https://example.com/
https://example.com/api/
https://example.com/images/
You could configure Application Gateway so that:
/ → Web application servers
/api/ → API servers
/images/ → Image/content servers
The client still sees one application endpoint. Application Gateway handles the routing behind the scenes.
Application Gateway is a Layer 7 load balancer designed for intelligent HTTP and HTTPS traffic routing.
That distinction is important because it explains why Application Gateway has features such as listeners, URL path-based routing, host-based routing, TLS termination, WAF integration, and HTTP header rewriting.
Why Is Azure Application Gateway Important?
Azure Application Gateway is important because it lets you control web traffic at the application layer instead of treating every connection only as an IP address and port.
Consider a company running three applications:
www.company.com
api.company.com
admin.company.com
All three applications could use the same Application Gateway while routing traffic to different backend pools.
It can also protect web applications with Azure Web Application Firewall, terminate TLS at the gateway, redirect HTTP traffic to HTTPS, rewrite headers or URLs, and distribute requests among healthy backend servers.
This makes Application Gateway particularly useful when your architecture needs a combination of:
- Application-aware routing
- Web application security
- TLS management
- Backend health monitoring
- High availability
- Autoscaling
- Multiple websites behind one gateway
A useful way to think about it is:
> Azure Load Balancer asks, “Where should this network connection go?” Application Gateway can ask, “What web request is this, and which application should handle it?”
How Does Azure Application Gateway Work?
Azure Application Gateway works by accepting a client request through a listener, optionally inspecting it with WAF, evaluating a routing rule, selecting a healthy backend, and forwarding the request using the configured backend settings.
A practical six-stage model makes the request flow easier to understand:
Stage 1: Reach the frontend IP
The client first resolves the application's DNS name and receives the Application Gateway frontend IP address. An internet-facing gateway uses a public IP, while an internal gateway uses private addressing.
Stage 2: Listener accepts the request
The listener defines what traffic Application Gateway accepts. It uses values such as:
* Frontend IP
* Protocol
* Port
* Host information
For example:
HTTPS
Port: 443
Host: api.example.com
A listener essentially says, “If traffic arrives here and matches these conditions, process it.”
Stage 3: WAF inspects the request
If Web Application Firewall is enabled, Application Gateway can inspect request headers and body content against configured WAF rules.
In Prevention mode , malicious requests can be blocked. In Detection mode , requests are evaluated and logged but continue toward the backend.
This makes WAF useful when an application is exposed to the public internet and needs an additional web security layer.
Stage 4: Routing rule decides where the request goes
The routing rule connects the listener to the backend configuration.
For example:
Host: api.example.com
↓
API backend pool
Or:
URL: /images/*
↓
Image backend pool
Application Gateway supports basic routing, URL path-based routing, and redirects.
Stage 5: Health probes select a healthy backend
Application Gateway does not blindly send requests to every server. Health probes determine which backend servers are considered healthy.
For example:
Backend 1 → /health → 200 OK → Healthy
Backend 2 → /health → 500 → Unhealthy
Backend 3 → /health → 200 OK → Healthy
Traffic can then be sent to the healthy servers.
Stage 6: Backend HTTP settings control the connection
After selecting a backend, Application Gateway creates a connection to it using the configured backend HTTP settings.
These settings can define the backend protocol and port and can control other behavior such as hostname handling and session affinity. They can also determine whether traffic between the gateway and backend remains encrypted.
Health probes decide whether a backend should receive traffic; backend HTTP settings decide how Application Gateway connects to it.
What Are the Main Azure Application Gateway Components?
The main Azure Application Gateway components are the virtual network and subnet, frontend IP, listeners, routing rules, backend pools, backend HTTP settings, and health probes.
Frontend IP
Application Gateway can use a public IP, private IP, or both depending on the architecture. A public frontend is appropriate for internet-facing applications, while a private frontend can be used for internal applications.
Listener
A listener receives incoming traffic and matches properties such as frontend IP, protocol, port, and host.
A common production setup might have:
Listener 1 → www.example.com → HTTPS 443
Listener 2 → api.example.com → HTTPS 443
Listener 3 → admin.example.com → HTTPS 443
Backend pool
A backend pool identifies where Application Gateway can send traffic.
Microsoft supports backend members such as:
* Virtual machines
* Virtual machine scale sets
* IP addresses or FQDNs
* Azure App Service
Backend HTTP settings
Backend HTTP settings define how the gateway connects to the selected backend. For example:
Protocol: HTTPS
Port: 443
Cookie-based affinity: Enabled
The frontend connection and backend connection can therefore be configured independently.
Health probe
Health probes test backend availability. Microsoft recommends custom probes when you need more control over health monitoring.
For example, instead of simply checking the root page:
GET /
you might configure:
GET /health
Expected response: HTTP 200
That is often more meaningful because a server can respond to `/` while the actual API or application dependency is unhealthy.
How Does Application Gateway Route Traffic by URL and Hostname?
Application Gateway can route traffic to different backend pools based on hostnames and URL paths, allowing multiple applications to share one gateway.
For example:
www.example.com/* → Web Pool
api.example.com/* → API Pool
admin.example.com/* → Admin Pool
You can also route by path:
example.com/images/* → Image Pool
example.com/api/* → API Pool
example.com/video/* → Video Pool
This is one of the major differences between Layer 4 and Layer 7 load balancing.
A Layer 4 service primarily works with network information such as IP addresses and ports.
Application Gateway can understand the HTTP request itself.
URL path-based routing lets one Application Gateway expose multiple application services while directing each request to the appropriate backend.
This pattern is particularly useful for microservices architectures.
For example:
Instead of exposing every service directly to the internet, the gateway can provide a controlled entry point.
What Is TLS Termination in Azure Application Gateway?
TLS termination means Application Gateway decrypts HTTPS traffic at the gateway before forwarding the request to the backend.
For example:
Client
|
HTTPS
|
v
Application Gateway
|
| HTTP
v
Backend
This can simplify certificate management and reduce TLS processing requirements on backend applications.
Application Gateway also supports end-to-end TLS:
Client
|
HTTPS
|
v
Application Gateway
|
HTTPS
|
v
Backend
Microsoft documents both SSL/TLS termination and end-to-end TLS as Application Gateway capabilities.
For sensitive applications, keeping encryption between the gateway and backend may be important because traffic remains encrypted beyond the frontend boundary.
What Is Azure Application Gateway WAF?
Azure Application Gateway WAF is a web application firewall capability that inspects HTTP requests and can help protect applications from common web attacks.
The important distinction is that WAF operates at the application layer.
A network firewall might control whether traffic can reach a particular IP address or port. WAF can inspect web requests themselves.
For example:
Internet
|
v
Application Gateway
|
WAF
|
+---- Valid request → Backend
|
+---- Malicious request → Block/Log
Application Gateway WAF is available with the WAF_v2 SKU. Microsoft also documents integration with additional Azure security capabilities such as DDoS Protection, Private Link, Azure Policy, Azure Advisor, and Microsoft Sentinel.
WAF should not be treated as a replacement for secure application development. Authentication, authorization, input validation, secrets management, patching, and application security still belong in the overall security design.
What Are the Main Azure Application Gateway Use Cases?
Azure Application Gateway is commonly used for application-aware routing, web application protection, TLS termination, hosting multiple sites, and distributing traffic across healthy backend instances.
1. Host multiple websites
A company can expose several domains through one gateway:
shop.example.com → E-commerce backend
blog.example.com → CMS backend
api.example.com → API backend
2. Route microservices by URL
A microservices application can use path-based routing:
/api/users/* → User service
/api/orders/* → Order service
/api/catalog/* → Catalog service
3. Protect internet-facing applications
A WAF-enabled Application Gateway can sit between users and backend applications:
Internet
↓
Application Gateway + WAF
↓
Private backend
This can reduce direct exposure of backend services.
4. Centralize TLS termination
Instead of independently managing frontend TLS processing on every backend, Application Gateway can terminate TLS at the edge of the application architecture.
5. Support highly available applications
Application Gateway v2 supports autoscaling and zone redundancy, which can help applications handle changing traffic and improve resiliency.
6. Integrate with AKS
Application Gateway can also integrate with Azure Kubernetes Service through Application Gateway Ingress Controller capabilities, allowing Application Gateway to provide Layer 7 traffic management for AKS workloads.
For a DevOps team already using AKS, this can provide an Azure-native ingress architecture instead of exposing Kubernetes services directly through separate public endpoints.
When Should You Use Azure Application Gateway?
Use Azure Application Gateway when your application needs Layer 7 routing, web security, TLS management, or HTTP-aware traffic control.
Microsoft positions Application Gateway, Load Balancer, Front Door, and Traffic Manager for different networking scenarios, and they can also be combined in larger architectures.
What Is the Difference Between Azure Application Gateway and Azure Load Balancer?
Azure Application Gateway provides Layer 7 HTTP/HTTPS load balancing, while Azure Load Balancer provides transport-level load balancing.
The practical difference is what the service understands.
Application Gateway can understand:
Host
URL path
HTTP/HTTPS
TLS
HTTP headers
Web application requests
A transport-level load balancer operates at a lower layer and is better suited to distributing network traffic without needing HTTP-aware routing.
For example:
Application Gateway:
/api/* → API servers
/images/* → Image servers
versus:
Load Balancer:
TCP :443 → Backend pool
Neither is universally better. They solve different networking problems.
A common Azure architecture may even use multiple services:
Users
↓
Azure Front Door
↓
Application Gateway + WAF
↓
Private application
↓
Backend services
The additional components should only be introduced when their capabilities solve a real architectural requirement.
How Do You Deploy Azure Application Gateway?
You can deploy Azure Application Gateway through the Azure portal, Azure CLI, PowerShell, or infrastructure-as-code tools such as Terraform.
A production-minded deployment usually starts with the network design rather than the gateway itself.
Recommended deployment sequence
1. Create or select the Azure virtual network.
2. Create a dedicated Application Gateway subnet.
3. Decide whether the gateway needs a public IP, private IP, or both.
4. Create the Application Gateway v2 SKU.
5. Configure listeners.
6. Configure backend pools.
7. Configure backend HTTP settings.
8. Configure health probes.
9. Create routing rules.
10. Configure TLS certificates.
11. Enable WAF when required.
12. Configure diagnostics, monitoring, and alerts.
13. Test healthy and unhealthy backend scenarios.
Application Gateway requires its own dedicated subnet, and that subnet cannot contain other resource types.
For infrastructure-as-code environments, Terraform can be particularly useful because the gateway configuration can be reviewed, version-controlled, and reproduced across environments.
A typical DevOps setup might maintain:
What Are Common Azure Application Gateway Mistakes?
The most common Application Gateway mistakes involve incorrect health probes, routing rules, backend settings, DNS, certificates, and subnet design.
Mistake 1: Treating the gateway like a basic load balancer
If you do not understand listeners, routing rules, backend settings, and probes, troubleshooting becomes difficult.
Always trace the request logically:
Frontend IP
→ Listener
→ WAF
→ Routing Rule
→ Backend Pool
→ Health Probe
→ Backend HTTP Settings
→ Application
Mistake 2: Using the wrong health probe
Suppose your application is healthy only when `/health` returns HTTP 200, but the probe checks `/`.
You may get confusing backend health results.
Use a custom probe that represents the actual application health condition. Microsoft recommends custom probes when greater monitoring control is required.
Mistake 3: Forgetting backend protocol differences
Your frontend may use:
HTTPS :443
while your backend uses:
HTTP :8080
That can be valid, but the backend HTTP settings must reflect the actual backend configuration.
If you expect end-to-end TLS, the backend connection must also be configured for HTTPS.
Mistake 4: Ignoring DNS
Application Gateway can use FQDN-based backend targets, so DNS behavior matters.
Incorrect private DNS configuration can cause the gateway to resolve a backend differently from what you expect. Microsoft documents DNS behavior and caching for FQDN-based backend targets.
Mistake 5: Using the wrong subnet design
Application Gateway needs a dedicated subnet. Do not treat its subnet as a general-purpose subnet for unrelated resources.
Mistake 6: Forgetting that v1 is retired
Application Gateway v1 retired on April 28, 2026 . Microsoft no longer supports V1 resources after that date, and remaining workloads can face service disruption as the underlying infrastructure is decommissioned.
For new deployments in 2026, the relevant generation is v2.
How Do You Troubleshoot Azure Application Gateway 502 and 503 Errors?
Troubleshooting Application Gateway errors starts with checking backend health, health probes, routing rules, DNS, ports, network security rules, and backend HTTP settings.
A useful troubleshooting sequence is:
1. Is the frontend reachable?
↓
2. Does the listener match?
↓
3. Does the routing rule match?
↓
4. Is the backend pool correct?
↓
5. Is the backend marked healthy?
↓
6. Does the health probe succeed?
↓
7. Is the backend port correct?
↓
8. Does DNS resolve correctly?
↓
9. Does NSG/UDR/network configuration allow traffic?
↓
10. Does the application actually respond?
For example, suppose the browser returns a 502.
Do not immediately assume the Application Gateway itself is broken.
The backend may be:
Listening on 8080
while Application Gateway is configured for:
Backend port 80
Or the backend may be healthy on `/health` but the configured probe may be checking an incorrect path.
The fastest troubleshooting approach is to trace the request through each Application Gateway component instead of changing several settings at once.
Application Gateway also adds request-tracing headers such as `x-appgw-trace-id`, which can help correlate gateway requests with diagnostic information.
Conclusion
Azure Application Gateway is a Layer 7 load balancer for routing and securing HTTP/HTTPS traffic.
Its core flow is: Client → Listener → WAF → Routing Rule → Backend → Application.
It is ideal for URL-based routing, multiple sites, TLS management, WAF, and health-based routing.
For simple TCP/UDP load balancing, Azure Load Balancer may be a better fit.
For 2026 deployments, use Application Gateway v2, as v1 was retired on April 28, 2026.
The best way to learn it is to build a small gateway and troubleshoot a failed backend yourself.
Frequently Asked Questions (FAQ)
What is Azure Application Gateway in simple terms?
Azure Application Gateway is a Layer 7 load balancer that sits in front of web applications and decides where HTTP or HTTPS requests should go. It can route traffic by hostname or URL path, monitor backend health, terminate TLS, and integrate with WAF for web application security.
Is Azure Application Gateway Layer 4 or Layer 7?
Azure Application Gateway operates at Layer 7 of the OSI model. It understands application-level HTTP and HTTPS information, allowing features such as URL path-based routing, host-based routing, TLS termination, and WAF inspection.
Is Azure Application Gateway a reverse proxy?
Application Gateway functions as a Layer 7 application delivery service that receives client requests and establishes backend connections on their behalf. It can therefore be used in a reverse-proxy architecture between clients and backend web applications.
Does Application Gateway require a subnet?
Yes. Azure Application Gateway requires a dedicated subnet inside its virtual network, and that subnet cannot contain other resource types.
What is the difference between Application Gateway and Load Balancer?
Application Gateway provides Layer 7 HTTP/HTTPS load balancing with application-aware features, while Azure Load Balancer provides transport-level load balancing. Choose between them based on whether your routing decisions need to understand web requests.
What is Application Gateway v2?
Application Gateway v2 is the current generation of Azure Application Gateway and includes the Standard_v2 and WAF_v2 SKUs. Microsoft retired Application Gateway v1 on April 28, 2026.
What does an Application Gateway health probe do?
An Application Gateway health probe checks whether backend servers are healthy enough to receive traffic. Application Gateway can use default health monitoring, while custom probes provide greater control over the health check path and expected behavior.
Can Application Gateway work with AKS?
Yes. Azure Application Gateway can provide Layer 7 traffic management for Azure Kubernetes Service through Application Gateway ingress capabilities. This allows Kubernetes workloads to use Azure Application Gateway for HTTP/HTTPS ingress scenarios.
You may like below blogs
Kubernetes: The Ultimate Guide to Container Orchestration & Scalability
How to Prepare for DevOps Interviews (Complete Guide for DevOps, SRE & Production Engineers)