Application Gateway (Layer 7) in Azure - Step-by-Step Execution

Process Flow - Application Gateway (Layer 7)

Client sends HTTP/HTTPS request

↓

Application Gateway receives request

↓

Inspect request at Layer 7 (HTTP)

↓

Apply routing rules based on URL/path/headers

↓

Forward request to appropriate backend pool

↓

Backend pool processes request and sends response

↓

Application Gateway forwards response to client

The Application Gateway receives client requests, inspects them at the web layer, applies routing rules, and forwards them to backend servers, then returns responses.

Execution Sample

Azure

az network application-gateway create \
  --name myAppGateway \
  --resource-group myResourceGroup \
  --location eastus \
  --sku Standard_v2 \
  --frontend-port 80 \
  --http-settings-cookie-based-affinity Enabled \
  --routing-rule-type PathBasedRouting

This command creates an Application Gateway that listens on port 80 and routes requests based on URL paths.

Process Table

Step	Action	Request Detail	Routing Decision	Backend Pool Selected	Response
1	Client sends HTTP GET	GET /images/logo.png	Match path /images/*	BackendPool1 (Image Servers)	Response from Image Server
2	Client sends HTTP GET	GET /api/data	Match path /api/*	BackendPool2 (API Servers)	Response from API Server
3	Client sends HTTP GET	GET /home	Default routing rule	BackendPool3 (Web Servers)	Response from Web Server
4	Client sends HTTPS POST	POST /api/upload	Match path /api/*	BackendPool2 (API Servers)	Response from API Server
5	Client sends HTTP GET	GET /unknownpath	Default routing rule	BackendPool3 (Web Servers)	Response from Web Server
6	Request with no matching rule	GET /no-match	Default routing rule	BackendPool3 (Web Servers)	Response from Web Server
7	End of requests	-	-	-	-

💡 All requests processed and routed according to path-based rules or default rule.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	Final
Request Path	-	/images/logo.png	/api/data	/home	/api/upload	/unknownpath	/no-match
Routing Rule Matched	-	/images/*	/api/*	default	/api/*	default	default
Backend Pool	-	BackendPool1	BackendPool2	BackendPool3	BackendPool2	BackendPool3	BackendPool3
Response	-	Image Server	API Server	Web Server	API Server	Web Server	Web Server

Key Moments - 3 Insights

Why does a request to /unknownpath go to the default backend pool?

Because /unknownpath does not match any specific path-based routing rule, the Application Gateway uses the default routing rule as shown in execution_table row 5.

How does the Application Gateway decide which backend pool to send the request to?

It inspects the HTTP request path and matches it against configured routing rules. The matched rule determines the backend pool, as seen in execution_table rows 1-4.

What happens if no routing rule matches the request path?

The Application Gateway forwards the request to the default backend pool, ensuring the request is still handled, as shown in execution_table rows 5 and 6.

Visual Quiz - 3 Questions

Look at the execution table, which backend pool handles the request for GET /api/data?

A BackendPool1 (Image Servers)

B BackendPool2 (API Servers)

C BackendPool3 (Web Servers)

D No backend pool

💡 Hint

Check execution_table row 2 under 'Backend Pool Selected'

At which step does the Application Gateway use the default routing rule for the first time?

A Step 1

B Step 3

C Step 5

D Step 2

💡 Hint

Look at execution_table rows and find where 'Routing Decision' is 'Default routing rule'

If a new path-based rule for /blog/* is added, how would the routing change for GET /blog/post1?

A It would route to BackendPool1

B It would route to BackendPool2

C It would route to a new backend pool for blog

D It would still route to the default backend pool

💡 Hint

Adding a new path-based rule directs matching requests to its specific backend pool instead of default

Concept Snapshot

Application Gateway (Layer 7) routes web traffic based on HTTP details like URL paths.
It inspects requests, applies routing rules, and forwards to backend pools.
Supports path-based routing, cookie affinity, and SSL termination.
Default rule handles unmatched requests.
Configured via Azure CLI or portal with frontend, backend pools, and routing rules.

Full Transcript

An Azure Application Gateway works at Layer 7, the web layer, to route client HTTP/HTTPS requests. When a client sends a request, the gateway inspects the URL path and other HTTP details. It matches the request against routing rules configured to direct traffic to specific backend pools. For example, requests to /images/* go to image servers, /api/* to API servers, and others to a default web server pool. If no specific rule matches, the default backend pool handles the request. This ensures all requests are served appropriately. The gateway then forwards the backend response back to the client. This process allows flexible, secure, and efficient web traffic management.

Practice

1. What is the main function of an Azure Application Gateway at Layer 7?

easy

A. It stores data in a scalable database.

B. It manages virtual machines in a subnet.

C. It routes web traffic based on URL paths and content.

D. It provides DNS resolution for domain names.

Solution

1. Step 1: Understand Layer 7 role

   Layer 7 means the application layer, which handles web traffic content like URLs.

2. Step 2: Identify Application Gateway function

   Application Gateway routes traffic based on URL paths and content, unlike DNS or VM management.

3. Final Answer:

   It routes web traffic based on URL paths and content. -> Option C

4. Quick Check:

   Layer 7 routing = URL-based traffic routing [OK]

Hint: Layer 7 means web content routing, not VM or DNS tasks [OK]

Common Mistakes:

• Confusing Application Gateway with DNS or VM services
• Thinking it works at network layer instead of application layer
• Assuming it stores data like a database

2. Which of the following is the correct way to define a frontend IP configuration for an Azure Application Gateway in ARM template JSON?

easy

A. {\"name\": \"appGatewayFrontendIP\", \"properties\": {\"publicIPAddress\": {\"id\": \"/subscriptions/.../publicIPAddresses/myPublicIP\"}}}

B. {\"name\": \"appGatewayFrontendIP\", \"location\": \"eastus\"}

C. {\"frontendIP\": \"myPublicIP\"}

D. {\"ipConfig\": {\"publicIP\": \"myPublicIP\"}}

Solution

1. Step 1: Review ARM template frontend IP syntax

   The frontend IP config requires a name and properties including a reference to a public IP resource by its ID.

2. Step 2: Match correct JSON structure

   {\"name\": \"appGatewayFrontendIP\", \"properties\": {\"publicIPAddress\": {\"id\": \"/subscriptions/.../publicIPAddresses/myPublicIP\"}}} correctly uses "name" and "properties" with "publicIPAddress" and its "id" field, matching ARM schema.

3. Final Answer:

   {"name": "appGatewayFrontendIP", "properties": {"publicIPAddress": {"id": "/subscriptions/.../publicIPAddresses/myPublicIP"}}} -> Option A

4. Quick Check:

   Frontend IP config needs name + publicIPAddress id [OK]

Hint: Look for 'properties' with 'publicIPAddress' and 'id' fields [OK]

Common Mistakes:

• Missing 'properties' wrapper around publicIPAddress
• Using 'location' inside frontend IP config incorrectly
• Incorrect field names like 'frontendIP' or 'ipConfig'

3. Given this simplified ARM snippet for an Application Gateway backend HTTP settings, what will be the effect of setting "pickHostNameFromBackendAddress" to true?

{
  "name": "appGatewayBackendHttpSettings",
  "properties": {
    "port": 80,
    "protocol": "Http",
    "pickHostNameFromBackendAddress": true
  }
}

medium

A. The backend hostname is taken from the backend pool IP or FQDN instead of the HTTP settings.

B. The Application Gateway ignores the backend pool and uses the frontend hostname.

C. The backend HTTP settings port is ignored and defaults to 443.

D. The Application Gateway disables SSL termination.

Solution

1. Step 1: Understand 'pickHostNameFromBackendAddress'

   This setting tells the gateway to use the hostname from the backend pool's address (IP or FQDN) for HTTP requests.

2. Step 2: Analyze effect on backend requests

   When true, the hostname in HTTP headers matches backend pool address, not the HTTP settings hostname.

3. Final Answer:

   The backend hostname is taken from the backend pool IP or FQDN instead of the HTTP settings. -> Option A

4. Quick Check:

   pickHostNameFromBackendAddress true = use backend pool hostname [OK]

Hint: True means use backend pool hostname, not HTTP settings hostname [OK]

Common Mistakes:

• Thinking it changes port or protocol
• Confusing frontend hostname with backend hostname
• Assuming it disables SSL termination

4. You deployed an Application Gateway but it fails to route traffic to backend servers. The backend pool uses IP addresses, but the health probes always fail. What is a likely cause?

medium

A. The Application Gateway subnet is too large.

B. The backend HTTP settings have 'pickHostNameFromBackendAddress' set to true but backend IPs lack proper DNS names.

C. The frontend IP configuration is missing a public IP address.

D. The backend pool uses FQDNs instead of IP addresses.

Solution

1. Step 1: Understand health probe failure with IP backend pool

   If 'pickHostNameFromBackendAddress' is true, the gateway uses backend hostname from IP, which fails if no DNS name exists.

2. Step 2: Identify mismatch causing probe failure

   Backend IPs lack DNS names, so probes fail when hostname is required but missing.

3. Final Answer:

   The backend HTTP settings have 'pickHostNameFromBackendAddress' set to true but backend IPs lack proper DNS names. -> Option B

4. Quick Check:

   IP backend + pickHostNameFromBackendAddress true = probe fails [OK]

Hint: Check if backend IPs have DNS names when pickHostNameFromBackendAddress is true [OK]

Common Mistakes:

• Blaming subnet size for routing issues
• Assuming frontend IP config missing public IP causes backend probe failure
• Confusing backend pool IPs with FQDNs

5. You want to configure an Azure Application Gateway to route requests to different backend pools based on URL paths: /images/* to an image server pool and /api/* to an API server pool. Which configuration step is essential to achieve this?

hard

A. Configure the backend HTTP settings to use HTTPS only.

B. Assign multiple public IP addresses to the frontend configuration.

C. Use multiple frontend ports with the same backend pool.

D. Create path-based routing rules with URL path maps specifying backend pools for each path.

Solution

1. Step 1: Understand URL-based routing requirement

   Routing based on URL paths requires path-based routing rules with URL path maps.

2. Step 2: Configure path-based rules

   Define URL path maps that link specific URL patterns like '/images/*' and '/api/*' to their respective backend pools.

3. Final Answer:

   Create path-based routing rules with URL path maps specifying backend pools for each path. -> Option D

4. Quick Check:

   URL path routing = path-based rules with URL maps [OK]

Hint: Use path-based routing rules with URL maps for URL path routing [OK]

Common Mistakes:

• Thinking multiple public IPs are needed for URL routing
• Using multiple frontend ports without path rules
• Assuming backend HTTP settings control URL routing