# Azure Application Gateway

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/azure-application-gateway

## Quick definition

Azure Application Gateway is a service in Microsoft Azure that distributes incoming web traffic to multiple servers. It acts like a smart traffic cop for your website or web application. It can route users to different parts of your application based on the web address they request and can also provide protection against common web attacks.

## Simple meaning

Imagine you own a large mall with many different stores. You have a single main entrance where all customers arrive. Without any guidance, customers would wander around aimlessly, causing congestion and confusion. An Azure Application Gateway is like a smart information desk at that entrance. When a customer walks in and says they want to buy electronics, the desk directs them straight to the electronics section on the second floor. If another customer wants to find a restaurant, they are sent to the food court on the third floor. This is web traffic routing.


Now, imagine your mall also has security guards at the information desk. Before a customer is allowed in, the guard checks to see if they are carrying anything dangerous or if they look suspicious. The guard can also block anyone who is known to cause trouble. This is the security feature of the Application Gateway. It can inspect web traffic for malicious code or attack patterns, blocking them before they reach your actual website servers.


Let's tie this back to the internet. Your website might have multiple parts, a main homepage, a product catalog, a customer login page, and a payment processing page. These might all be hosted on different servers or in different parts of the cloud. When a user types your website address into their browser, their request goes to the internet and eventually hits your Azure Application Gateway. The Gateway looks at the specific URL the user typed. If they typed “yourstore.com/products,” the Gateway sends them to the server that hosts your product catalog. If they type “yourstore.com/login,” they are sent to the secure server that handles logins.


This is incredibly useful because it means your entire application can be accessed through one single web address, even though the behind-the-scenes parts are spread out. It also protects your backend servers from direct exposure to the internet. The backend servers can be hidden inside a secure network, only trusting traffic that comes from the Application Gateway. This makes your entire application infrastructure more secure and easier to manage.

## Technical definition

Azure Application Gateway is a Layer 7 (application layer) load balancer, operating at the HTTP/HTTPS protocol level. Unlike a basic Layer 4 load balancer which only forwards traffic based on IP address and TCP/UDP port, an Application Gateway can make intelligent routing decisions based on the content of the HTTP request, including the URL path, host headers, query strings, and HTTP method. This capability is known as application-level routing.


At its core, the Application Gateway consists of several key components. The front-end IP configuration defines the public or private IP address where the gateway listens for incoming traffic. Listener configurations define the protocol (HTTP or HTTPS) and port (80 or 443) for traffic. Listeners are the entry points into the Application Gateway. Once a listener receives a request, it passes the request to a routing rule. These rules define how to handle the request, primarily by linking a listener to a target (the backend pool) and optionally setting conditions for URL path-based routing.


Backend pools define the group of servers, virtual machines, or other resources that will actually serve the web content. These can be Azure virtual machines, Azure App Service instances, on-premises servers, or even external endpoints. The Application Gateway uses health probes to monitor the availability of these backend resources. A health probe is a simple request (like a GET request to a specific URL path) sent to each backend server at regular intervals. If a server fails to respond correctly, the Gateway removes it from rotation and stops sending traffic to it until it becomes healthy again.


URL path-based routing is a primary feature. For example, you can configure rules so that traffic to “/api/*” is sent to a pool of compute-intensive virtual machines, while traffic to “/images/*” is sent to a content delivery network (CDN) or a separate storage backend. This allows for fine-grained traffic management and microservices architecture support.


Another critical feature is the Web Application Firewall (WAF). When enabled, the WAF integrates with the Application Gateway to inspect incoming web traffic for common exploits and vulnerabilities, such as SQL injection attacks, cross-site scripting (XSS), and HTTP request smuggling. It uses a set of rules defined by the Open Web Application Security Project (OWASP) core rule set. The WAF can be configured to block malicious requests, log them, or just alert administrators, providing a crucial layer of defense.


SSL/TLS termination is also a standard capability. In this configuration, the Application Gateway handles the encryption and decryption of HTTPS traffic. The backend servers then receive unencrypted HTTP traffic, which offloads the computational overhead of encryption from the backend servers. This improves backend server performance and simplifies certificate management, as the certificate only needs to be installed on the Gateway, not on every backend server.


Traffic is distributed using various algorithms, including round-robin and least outstanding requests. HTTP session persistence, or affinity, can also be enabled using a cookie-based mechanism. This ensures that requests from a particular user session are always sent to the same backend server, which is important for applications that store session data locally on the server.


The Application Gateway is a regional service, meaning it is deployed within a specific Azure region. For high availability, it can be deployed across multiple Availability Zones within that region. It can also be configured as a global service in conjunction with Azure Traffic Manager, which handles DNS-level routing across different regions.


In terms of scaling, the Application Gateway supports autoscaling in its v2 SKU, automatically adjusting capacity based on traffic patterns. It also supports static VIP or domain name, ensuring that the endpoint address does not change even as the underlying infrastructure scales. The v2 SKU also provides improved performance with up to 125 SSL transactions per second per capacity unit.

## Real-life example

Think of Azure Application Gateway like a modern airport control tower, but for your website. The airport has many runways (your backend servers) and many different airlines (different parts of your web application, like the store, the blog, and the support center). Passengers (web users) are arriving from all over the world, and each one has a destination (the specific URL they want to visit).


The control tower (the Application Gateway) has a single, well-known frequency and location that all planes (web requests) fly to first. The tower doesn’t just say “land anywhere.” It listens to the pilot’s specific request. On the radio, a pilot for “Flight 101 from NY to Blog” says “Requesting landing for Blog area.” The tower looks at a big board showing which runways are free, which ones have been closed for maintenance (unhealthy servers), and which are for specific types of planes. The tower then directs “Flight 101” to land on Runway 3, which is the runway designated for all “Blog” traffic.


Another pilot, “Flight 202 from London to Payments,” calls in. The tower sees that this is a high-security flight. So, before giving landing clearance, the tower checks a security database. Is this flight on any no-fly list? Does it have any suspicious cargo? The tower’s security system (the Web Application Firewall) scans the flight’s manifest (the HTTP request headers and body). If it finds a report of “SQL Injection tools” on board, the tower immediately denies landing and diverts the flight to a holding pattern or turns it away completely.


If a healthy flight lands, the tower ensures it parks at the correct gate. The passengers disembark directly into the correct terminal for their airline (e.g., the “Blog” server or the “Payments” server). The tower also makes sure that if one runway is completely blocked (server crash), no new flights are sent there. All incoming traffic is evenly distributed among the remaining open runways.


Finally, the tower can make the landing process faster. Instead of requiring every single passenger to go through a full security check and baggage claim at the gate (which is slow), the tower handles the complex security and encrypted communication checks right at the tower level. The back-end gates receive passengers who are already cleared and ready to go. This is the SSL/TLS termination offloading. It makes the whole airport-and your web application-run much more smoothly and efficiently.

## Why it matters

In a modern IT environment, web applications are rarely simple, single-server setups. They are complex, multi-tiered systems that might include a front-end web server, a back-end API server, a database server, and a content hosting service. Managing traffic to all these components from a single, user-friendly URL is a fundamental requirement. This is where Azure Application Gateway becomes critically important. It provides a single point of entry for the entire application, simplifying the user experience and simplifying the administrator's job of managing traffic distribution.


From a security perspective, the Application Gateway is a vital component of a defense-in-depth strategy. By placing the Gateway in front of your web servers, you effectively hide the IP addresses and internal network structure of your backend servers from the public internet. This reduces the attack surface. The built-in Web Application Firewall provides an additional layer of security that actively blocks common web attacks. This is often a compliance requirement for applications that handle sensitive data, such as financial or healthcare information.


Performance is another key factor. Offloading SSL/TLS encryption to the Gateway frees up computational resources on your backend servers. These servers can then dedicate more CPU and memory to processing actual application logic and serving content, leading to faster response times for end users. The health probe feature automatically removes failing servers, ensuring that users are only sent to healthy instances, which directly improves application availability and reliability.


For DevOps and platform engineering teams, the Application Gateway integrates deeply with other Azure services. It works with Azure Kubernetes Service (AKS) for ingress control, with Azure App Service as a front-end, and with Azure Traffic Manager for global load balancing. This integration makes it a cornerstone of cloud-native application architectures. It allows teams to implement complex routing rules, A/B testing, and canary deployments without altering the application code itself, providing immense operational flexibility.

## Why it matters in exams

Azure Application Gateway is a high-frequency topic across several major certification exams, particularly the Microsoft Azure role-based certifications. For the AZ-104 (Microsoft Azure Administrator) exam, candidates are expected to understand the core functionality of load balancers, including the difference between Azure Load Balancer (Layer 4) and Azure Application Gateway (Layer 7). You may be asked to select the correct service for a scenario involving URL-based routing or when a Web Application Firewall is required. Question types often include case studies where you must choose between Load Balancer, Application Gateway, Traffic Manager, or Front Door.


For the AZ-305 (Designing Microsoft Azure Infrastructure Solutions) exam, the focus shifts to high-level design and architecture. You will need to justify the use of an Application Gateway in a global or regional application architecture. You might be asked about redundancy patterns, such as using Application Gateway with Availability Zones, or combining it with Traffic Manager for cross-region failover. Design scenarios involving multi-tier applications and microservices will heavily rely on your understanding of path-based routing and backend pooling.


In the Azure Fundamentals (AZ-900) exam, you don’t need deep configuration knowledge, but you must recognize Azure Application Gateway as a core networking product for load balancing. You should know its primary use cases, its Layer 7 capability, and its integration with WAF. Expect a single multiple-choice question asking which Azure service provides URL-based routing.


Beyond Azure-specific exams, this term appears in the Security+ (SY0-601) exam objectives. Here, the WAF feature of the Application Gateway is relevant when discussing web application security and network security controls. You may encounter a question about a technology that can inspect and block HTTP traffic for XSS or SQL injection, with the Application Gateway being a correct, cloud-native example.


The Cloud+ (CV0-003) exam also touches on load balancing concepts, including application load balancers. You should understand the difference between layer 4 and layer 7, and when to use each. The Application Gateway is a prime example of a layer 7 load balancer in a public cloud context.

## How it appears in exam questions

In Microsoft Azure certification exams, questions about Azure Application Gateway typically fall into three categories: scenario-based selection, configuration logic, and troubleshooting diagnosis. In scenario-based questions, you are presented with a business requirement. For example: “A company has a web application that consists of a public website and a backend API, both hosted on different virtual machine scale sets. They need a single endpoint for users and want to route traffic based on the URL path. Which Azure service should they use?” The correct answer here is Azure Application Gateway because it supports URL path-based routing. A common distractor might be Azure Load Balancer, which operates at Layer 4 and cannot inspect URLs.


Configuration logic questions test your understanding of how to set up the Gateway. For instance: “You are configuring an Application Gateway for an HTTPS application. You need to ensure that the backend servers do not handle SSL decryption. What should you do?” The answer involves enabling SSL termination on the gateway and ensuring the listeners are configured for HTTPS, while the backend pool is set to receive HTTP traffic. You might also be asked about health probe configuration, such as setting the correct probe path to a simple “/health” endpoint on the backend server.


Troubleshooting questions often present a failure mode. For example: “Users report that they are intermittently receiving a 502 Bad Gateway error when accessing the application. The Application Gateway has a health probe configured. What is the most likely cause?” The answer would likely point to a backend server not responding correctly to the health probe, or the health probe path being incorrect. Another troubleshooting scenario might involve SSL certificate issues: users get a certificate error. The question would ask you to identify that the SSL certificate on the Application Gateway’s listener might be expired or misconfigured.


You may also encounter questions about scaling and SKUs. For example: “An application requires autoscaling for the Application Gateway. Which SKU should you use?” The answer is the Standard v2 or WAF v2 SKU, as they support autoscaling, unlike the v1 SKUs. These questions are designed to test your practical, operational knowledge rather than just rote memorization.

## Example scenario

Your company runs an e-commerce website called ShopNow. The website has three main parts: a public storefront, a customer account portal, and an admin panel for employees. The storefront and account portal are hosted on a set of Azure virtual machines in a scale set. The admin panel is hosted on a separate, more secure set of virtual machines. All three parts need to be accessible to users through a single, easy-to-remember URL: www.shopnow.com.


Your manager asks you to design the network architecture. You decide to use an Azure Application Gateway. You create a single public IP address for the Gateway. You then configure three listeners, one for each part of the application, but they all listen on the same IP and port (80 and 443). You create three backend pools: PoolA for the storefront, PoolB for the account portal, and PoolC for the admin panel. You configure URL path-based routing rules so that requests to www.shopnow.com/* go to PoolA, requests to www.shopnow.com/account/* go to PoolB, and requests to www.shopnow.com/admin/* go to PoolC.


You also enable the Web Application Firewall to protect the entire site from SQL injection and cross-site scripting attacks. For security, you enable SSL termination on the Gateway, using a wildcard certificate for *.shopnow.com. The backend pools receive HTTP traffic, which means the load of encryption is off from the virtual machines. You also configure health probes for each pool, checking a simple “/index.html” file every 30 seconds.


A week later, the admin panel server experiences a software crash. The health probe fails, and the Application Gateway automatically stops sending traffic to the failed server. Users of the storefront and account portal continue to work without any interruption. The IT team is alerted, fixes the server, and the health probe immediately recognizes it as healthy again, automatically resuming traffic. This scenario demonstrates how the Application Gateway provides high availability, security, and intelligent routing, all from a single, manageable component.

## Common mistakes

- **Mistake:** Thinking Azure Application Gateway is the same as Azure Load Balancer.
  - Why it is wrong: Azure Load Balancer operates at Layer 4 (transport layer) and can only distribute traffic based on IP address and port. It cannot see the URL path or HTTP headers, so it cannot perform URL-based routing, SSL offloading, or WAF inspection. Application Gateway operates at Layer 7 and can do all these things.
  - Fix: Remember: If you need to route based on URL, host headers, or need a web firewall, pick Application Gateway. If you just need to spread TCP/UDP traffic evenly across servers, pick Load Balancer.
- **Mistake:** Forgetting to configure a health probe for the backend pool.
  - Why it is wrong: Without a health probe, the Application Gateway does not know if a backend server is alive. It will blindly send traffic to a downed server, causing errors (502 Bad Gateway) for users. Health probes are essential for high availability.
  - Fix: Always define a health probe for every backend pool. Point the probe to a simple, static path on your backend server that always returns a 200 OK response.
- **Mistake:** Placing the Application Gateway in the same subnet as the backend servers.
  - Why it is wrong: Best practice dictates that the Application Gateway should be in its own dedicated subnet (e.g., 10.0.1.0/24) and the backend servers in a separate subnet (e.g., 10.0.2.0/24). This provides network segmentation and security. Placing them together is poor architecture and can create security risks.
  - Fix: Create two separate subnets in your virtual network. One for the Application Gateway and one for your backend resources.
- **Mistake:** Disabling SSL/TLS termination but expecting backend servers to receive encrypted traffic without proper certificates.
  - Why it is wrong: If SSL termination is disabled on the Gateway, it means the Gateway will pass the encrypted HTTPS traffic directly to the backend servers. The backend servers must then be configured to handle the SSL encryption themselves, which requires installing the SSL certificate on each backend server. This can be complex and defeats the purpose of offloading.
  - Fix: Either enable SSL termination on the Gateway to offload the encryption work, or if you must pass encrypted traffic through, ensure all backend servers have a valid SSL certificate installed and the gateway is configured to pass HTTPS traffic.
- **Mistake:** Assuming Azure Application Gateway can handle non-HTTP/HTTPS traffic like SSH or FTP.
  - Why it is wrong: Application Gateway is strictly an HTTP/HTTPS load balancer. It cannot handle SSH, FTP, SMTP, or other non-web protocols. For those, you need Azure Load Balancer or another network virtual appliance.
  - Fix: Use the right tool for the job. Application Gateway for web applications. Azure Load Balancer for all other TCP/UDP traffic.
- **Mistake:** Configuring the Web Application Firewall (WAF) to “Prevention” mode without first testing in “Detection” mode.
  - Why it is wrong: Setting WAF to Prevention mode immediately can block legitimate user traffic if the rules are too strict or if your application has specific patterns that trigger the rules. This can break the application for real users.
  - Fix: First, configure WAF in Detection mode. Monitor the logs for false positives. Adjust the WAF rules or create exclusions for your application. Then, switch to Prevention mode.

## Exam trap

{"trap":"A question asks: “A company needs to load balance HTTP traffic to a web app that also hosts subdomains like blog.contoso.com and shop.contoso.com. They want a single public IP. Should they use Azure Application Gateway or Azure Traffic Manager?”","why_learners_choose_it":"Learners often confuse traffic distribution methods. They hear “single public IP” and “different subdomains” and think of Traffic Manager, which is DNS-based and can route based on hostname. However, Traffic Manager is for global routing across regions, not for routing within a single region or application based on the full URL path.","how_to_avoid_it":"The key is “single IP” and “routing within a single application based on subdomain/path”. Traffic Manager uses DNS to point users to different regional endpoints (different public IPs). Application Gateway can listen on a single IP and route to different backends inside the same region based on the host header (subdomain) or URL path. The correct answer here is Azure Application Gateway with multi-site listeners."}

## Commonly confused with

- **Azure Application Gateway vs Azure Load Balancer:** Azure Load Balancer operates at Layer 4 (transport layer). It distributes TCP or UDP traffic based solely on a 5-tuple (source IP, source port, destination IP, destination port, protocol). It cannot inspect HTTP headers or URLs. Azure Application Gateway operates at Layer 7 (application layer) and can route based on URL path, host headers, and other HTTP attributes, and provides WAF capabilities. (Example: Load Balancer just sends all traffic to the same group of servers. Application Gateway can send “/login” requests to one group of servers and “/gallery” requests to another.)
- **Azure Application Gateway vs Azure Traffic Manager:** Azure Traffic Manager is a DNS-based traffic load balancer. It operates at Layer 3/4 and uses DNS queries to direct users to the most appropriate regional endpoint. It does not handle the actual HTTP request; it just tells the browser “go to this IP.” Application Gateway is a regional HTTP proxy that can inspect the actual request content. Traffic Manager is for global load balancing, while Application Gateway is for regional, application-layer load balancing. (Example: Traffic Manager sends users in Europe to a European IP address and users in the US to a US IP address. Application Gateway then manages the specific web traffic once it reaches that regional endpoint.)
- **Azure Application Gateway vs Azure Front Door:** Azure Front Door is a global, scalable entry point that combines features of Traffic Manager and Application Gateway. It provides global HTTP load balancing with acceleration and a WAF. While Application Gateway is a regional service, Front Door is a global service. Front Door can also perform URL path-based routing and SSL offloading, but at a global scale. For some scenarios, Front Door is used in front of an Application Gateway as a global/regional hierarchical architecture. (Example: Front Door acts like a global air traffic control system that sends a plane to the best airport (region), while Application Gateway acts like the control tower at that specific airport, directing the plane to the correct runway (backend pool).)
- **Azure Application Gateway vs Azure Web Application Firewall (WAF) Policy:** A WAF Policy is the set of rules and configurations that define how to filter and block web traffic. It is a separate Azure resource that is attached to an Application Gateway or Front Door. The Application Gateway is the infrastructure that hosts the WAF engine. You cannot have a standalone WAF Policy without a Gateway or Front Door to apply it to. (Example: The Application Gateway is the security checkpoint building. The WAF Policy is the rulebook written for the guards inside that building.)
- **Azure Application Gateway vs Azure API Management:** Azure API Management is a service for creating, publishing, and managing APIs. It includes features like rate limiting, API versioning, and developer portals. While it can proxy HTTP requests, its primary purpose is API lifecycle management, not simple load balancing. Application Gateway focuses on traffic distribution and security for web applications. (Example: API Management is a publishing house that formats and controls access to magazines (APIs). Application Gateway is a postal sorting office that simply routes the mail to the correct building.)

## Step-by-step breakdown

1. **Create the Application Gateway Resource** — In the Azure portal, you begin by creating a new Application Gateway resource. You choose your subscription and resource group, give it a name, and select the region. You also choose the tier (Standard v2 or WAF v2) and the SKU size (you can start with autoscaling). This is the top-level container for all other configurations.
2. **Configure the Virtual Network and Subnet** — You specify the virtual network where the Application Gateway will live. It requires its own dedicated subnet, with a minimum of /27 or larger. This subnet is used for the Gateway instances. You cannot share this subnet with any other resources (like VMs or databases).
3. **Define the Front-end IP Configuration** — You set up the public (or private) IP address that users will connect to. For a public-facing web app, you create a new public IP address resource and assign it to the front-end configuration. This is the single entry point for all your web traffic.
4. **Create Backend Pools** — You define the backend servers that will host your application. A backend pool can contain Azure virtual machines, scale sets, App Services, or even external on-premises servers. You can have multiple backend pools for different parts of your application (e.g., one pool for the storefront, one for the admin panel).
5. **Define Health Probes** — You configure custom health probes for each backend pool. The probe specifies a path (e.g., /health), a protocol (HTTP/HTTPS), and a timeout interval. The Gateway will periodically send requests to this path. A 200-399 response means the server is healthy. A failing server is removed from the pool.
6. **Configure Listeners and Rules** — You create listeners for HTTP (port 80) and HTTPS (port 443). For HTTPS, you upload an SSL certificate. Then, you create routing rules that link a listener to a backend pool. For URL path-based routing, you add multiple path-based rules within a rule, such as /api/* routing to PoolA and /* routing to PoolB.
7. **Enable the Web Application Firewall (WAF) (Optional)** — If you chose the WAF tier, you can enable the firewall and configure the policy. You can choose between Detection (log only) and Prevention (block) modes. You also select the OWASP rule set version. This step adds a critical layer of security against common web attacks.
8. **Enable SSL Termination (Optional)** — For HTTPS traffic, you can configure SSL termination on the listener. The Gateway decrypts the incoming HTTPS traffic and sends unencrypted HTTP traffic to the backend servers. This offloads CPU-intensive encryption from the backend servers and simplifies certificate management.
9. **Test and Deploy** — After all configurations are set, you review and create the resource. The deployment takes a few minutes. Once it is ready, you point your domain’s DNS record to the public IP address of the Application Gateway. You can then test the end-to-end connectivity by visiting your application’s URL and verifying traffic is routed correctly.

## Practical mini-lesson

As an IT professional working with Azure, understanding the practical deployment considerations of Azure Application Gateway is critical for building secure and scalable architectures. First, always consider the subnet size. The Gateway instances will each take an IP from that subnet. For a high-availability setup spanning multiple zones, you need at least 3 to 5 IPs. Plan for a subnet mask of /24 or /25 to allow for future scaling.


Second, certificate management is a key operational task. When using SSL termination, you must upload the SSL certificate to the Application Gateway. You can use certificates from Azure Key Vault for better security and centralized management. When the certificate expires, you must update it on the Gateway. Failure to do so will result in users receiving SSL certificate errors.


Third, health probes are not optional. A common scenario is that you configure a health probe to the root path (“/”) but your application returns a different status code (like 302 redirect or 401 unauthorized) at that path. This will cause the Gateway to mark the server as unhealthy. Always check what your application returns for the health probe path. Many developers create a dedicated health endpoint, such as /health, which returns a simple 200 OK.


Fourth, when using URL path-based routing, the order of rules matters. The Gateway processes the path rules in the order they are defined and uses the first match. If you have a catch-all rule (like /*) at the top, more specific rules (like /api/*) below it will never be triggered. Always list the most specific paths first.


Fifth, monitoring is essential. Enable Azure Monitor diagnostics for the Application Gateway to capture logs for access, performance, and firewall events. The WAF logs are invaluable for understanding traffic patterns and potential attacks. You can also set up alerts for specific conditions, such as a backend pool being unhealthy or the number of HTTP 5xx errors exceeding a threshold.


In a real production environment, you would likely deploy a multi-tier architecture. You might place a global Azure Front Door in front of the Application Gateway for CDN capabilities and cross-region routing. The combination of Front Door (global) and Application Gateway (regional) is a best practice for mission-critical applications. You might also associate the Application Gateway with an Azure Kubernetes Service (AKS) cluster as an ingress controller, using an Application Gateway Ingress Controller (AGIC) add-on. This allows you to manage routing rules from within Kubernetes YAML, providing excellent flexibility for containerized applications.


Finally, cost is a factor. The v2 SKU is autoscaling but costs more than the manually scaled v1 SKU. For small, predictable workloads, v1 might be cheaper. However, for anything production, v2 is recommended for its performance and availability features. Always calculate costs based on data processed (processed data) and capacity units, not just the hourly rate.

## Commands

```
az network application-gateway create --name myAppGateway --resource-group myRG --capacity 2 --sku WAF_v2 --vnet-name myVNet --subnet mySubnet --http-settings-port 80 --http-settings-protocol Http --frontend-port 80 --public-ip-address myPublicIP
```
Creates an Azure Application Gateway with WAF v2 SKU, 2 instance capacity, and basic HTTP settings.

*Exam note: Exams test knowledge of SKU tiers (Standard_v2, WAF_v2) and capacity settings. Questions often ask which SKU supports Web Application Firewall (WAF) features.*

```
az network application-gateway probe create --gateway-name myAppGateway --resource-group myRG --name myProbe --protocol Http --path /health --interval 30 --timeout 10 --threshold 3
```
Adds a custom health probe to an existing gateway, checking /health endpoint every 30 seconds.

*Exam note: Custom probes are frequently tested for backend health monitoring. Exams ask about probe intervals, timeouts, and how unhealthy instances are removed from rotation.*

```
az network application-gateway http-listener create --gateway-name myAppGateway --resource-group myRG --name myListener --frontend-port 443 --protocol Https --ssl-cert myCert --host-name www.example.com
```
Creates an HTTPS listener with SSL termination for hostname-based routing.

*Exam note: Multi-site listeners and SSL termination are core exam topics. Questions test the difference between basic and multi-site listeners, and SSL certificate requirements.*

```
az network application-gateway url-path-map create --gateway-name myAppGateway --resource-group myRG --name myPathMap --paths /images/* --backend-address-pool imagesPool --backend-http-settings imagesSettings
```
Creates a URL path map rule routing /images/* to a specific backend pool.

*Exam note: Path-based routing rules are common in exam scenarios. Look for questions requiring redirection of specific URL patterns to different backends.*

```
az network application-gateway waf-config set --enabled true --gateway-name myAppGateway --resource-group myRG --firewall-mode Prevention --rule-set-type OWASP --rule-set-version 3.2
```
Enables WAF on an existing gateway in Prevention mode with OWASP 3.2 ruleset.

*Exam note: WAF modes (Detection vs Prevention), OWASP rule set versions, and enabling WAF on v2 SKUs are frequently tested. Know that Standard SKU does not support WAF.*

```
az network application-gateway rewrite-rule set create --gateway-name myAppGateway --resource-group myRG --name myRewriteSet --rewrite-rules '[{"name":"addHeader","actionSet":{"requestHeaderConfigurations":[{"headerName":"X-Custom","headerValue":"myValue"}]},"conditions":[]}]'
```
Creates a rewrite rule set to add a custom HTTP header to requests.

*Exam note: Rewrite rules for headers and URLs are emerging in exams. Questions may ask how to modify request/response headers without changing the backend application.*

```
az network application-gateway private-link add --gateway-name myAppGateway --resource-group myRG --name myPrivateLink --subnet /subscriptions/.../subnets/mySubnet --frontend-ip-configuration appGwFrontendIP
```
Associates a Private Link with the Application Gateway for private connectivity.

*Exam note: Private Link integration is a newer exam topic. It tests understanding of securing traffic within a virtual network and avoiding public exposure.*

## Troubleshooting clues

- **Backend health probe fails with 502 Bad Gateway** — symptom: Application Gateway returns 502 errors; backend pool shows 'Unhealthy' for all targets. Health probes are not reaching the backend, or the backend is not responding within the timeout. Could be firewall blocking, incorrect probe path, or backend service down. (Exam clue: Exams present symptoms of 502 errors and ask to identify probe configuration mismatches, like mismatched protocol or incorrect path.)
- **SSL certificate mismatch on listener** — symptom: Users get SSL errors when connecting to the gateway; listener shows 'Certificate not valid'. The certificate installed on the HTTP listener does not match the hostname or is expired. Application Gateway requires a valid certificate for SSL termination. (Exam clue: Questions test SSL certificate requirements, including wildcard certificates and SNI. Look for scenarios with multiple hostnames needing separate certs.)
- **WAF blocking legitimate traffic** — symptom: Valid requests are blocked with 403 Forbidden; WAF logs show 'Matched anomaly'. WAF rules in Prevention mode are too strict. False positives occur when OWASP rules match normal traffic patterns like SQL-like strings in comments. (Exam clue: Exams ask how to differentiate between WAF Detection vs Prevention mode, and how to create custom exclusions for false positives.)
- **Path-based routing not working** — symptom: Requests to /images/ go to the default backend pool instead of the images pool. The URL path map rule might not be properly linked to the listener, or the path pattern is incorrect (e.g., missing trailing slash or wildcard). (Exam clue: Tested via scenario: user configures path rules but traffic ignores them. Answer often involves verifying path map association with the HTTP listener.)
- **Gateway cannot scale up** — symptom: Capacity setting stuck at current instances; auto-scale not increasing despite high load. Autoscale is only available on v2 SKU. Standard SKU has fixed capacity. Also, subnet size may limit scale-out. (Exam clue: Know the differences between Standard_v2 vs WAF_v2, and that autoscale is a v2 feature. Questions test when to choose autoscale vs manual.)
- **Session affinity not persisting** — symptom: User requests are routed to different backend servers, breaking session state. Session affinity (sticky sessions) is not enabled or the Application Cookie-based affinity is misconfigured. Requires setting 'enable-cookie-based-affinity' to true. (Exam clue: Exams ask about cookie-based affinity and when to use it (e.g., shopping cart). Common distractor: ARRAffinity is for Azure App Service, not gateway.)
- **High latency and timeout for backend requests** — symptom: Slow response times; gateway logs show requests timing out after 30 seconds. Backend request timeout default is 20-30 seconds. Can be increased via HTTP settings. Also check backend performance and network latency. (Exam clue: Questions present a scenario where mobile app requests timeout. The solution often involves adjusting the 'request-timeout' setting in backend HTTP settings.)
- **Rewrite rule not applied** — symptom: Headers or URL not modified despite rewrite rule set configuration. Redirect rule sets must be associated with a routing rule. Common oversight: rule set not linked to a listener or path rule. (Exam clue: Exams test that rewrite rules require association with a rule (e.g., 'az network application-gateway rule update --rewrite-rule-set'). Without that, no effect.)

## Memory tip

Think of “AGW”: Application Gateway for Web traffic. It’s the clever “gate” that knows “who” (host header) and “where” (URL path) to send visitors. Remember the three W’s: Web traffic, WAF security, and URL path-based routing.

## FAQ

**What is the main difference between Azure Application Gateway and Azure Load Balancer?**

Azure Load Balancer works at Layer 4 (IP and port) and just spreads traffic evenly. Azure Application Gateway works at Layer 7 (HTTP/HTTPS) and can route traffic based on the URL path, host headers, and can also act as a web firewall.

**Is the Web Application Firewall mandatory for an Application Gateway?**

No, it is optional. You can choose the Standard v2 tier without WAF. However, for any public-facing web application, it is highly recommended for security.

**Can I use Azure Application Gateway for non-HTTP traffic like RDP or SSH?**

No. Application Gateway is designed specifically for HTTP/HTTPS traffic. For RDP, SSH, or other TCP/UDP protocols, you must use Azure Load Balancer or a VPN.

**Do I need to install SSL certificates on my backend servers if I use Application Gateway?**

It depends. If you enable SSL termination on the Gateway, the backend servers receive unencrypted HTTP traffic, so no certificate is needed on them. If you disable termination, you must install certificates on each backend server.

**What is a health probe and why is it important?**

A health probe is a simple check the Application Gateway sends to your backend servers to see if they are alive and working correctly. If a server fails the health check, the Gateway stops sending traffic to it. This is essential for keeping your application available.

**Can I have multiple websites on the same Application Gateway?**

Yes. You can configure multiple listeners on the same Gateway, each for a different host name (e.g., blog.contoso.com and shop.contoso.com), and route them to different backend pools. This is called multi-site hosting.

**What happens when a backend server fails?**

If a backend server fails a health probe, the Application Gateway automatically removes it from the backend pool and stops sending new requests to it. Traffic is redirected to healthy servers in the pool. When the failed server recovers and passes the health probe, it is automatically added back.

**Does Azure Application Gateway support autoscaling?**

Yes, the Standard v2 and WAF v2 SKUs support autoscaling. They automatically scale up or down based on the volume of incoming traffic, so you do not have to manually manage capacity.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/azure-application-gateway