URL maps for routing in GCP - Step-by-Step Execution

Process Flow - URL maps for routing

Client sends HTTP request

↓

Load Balancer receives request

↓

URL Map checks request URL

↓

Match path rule 1

↓

Route to backend 1

↓

Backend serves response

↓

Response sent to client

The URL map receives the request URL from the load balancer and matches it against defined path rules to route traffic to the correct backend service.

Execution Sample

GCP

urlMap:
  defaultService: backendServiceA
  hostRules:
  - hosts: ["example.com"]
    pathMatcher: pathMatcher1
  pathMatchers:
  - name: pathMatcher1
    defaultService: backendServiceA
    pathRules:
    - paths: ["/images/*"]
      service: backendServiceImages
    - paths: ["/videos/*"]
      service: backendServiceVideos

This URL map routes requests for example.com. Requests to /images/* go to backendServiceImages, /videos/* to backendServiceVideos, and all others to backendServiceA.

Process Table

Step	Request URL	Matched Host	Matched Path Rule	Routed Backend Service	Action
1	http://example.com/images/cat.png	example.com	/images/*	backendServiceImages	Route to images backend
2	http://example.com/videos/movie.mp4	example.com	/videos/*	backendServiceVideos	Route to videos backend
3	http://example.com/about	example.com	default	backendServiceA	Route to default backend
4	http://other.com/home	no match	no match	defaultService (backendServiceA)	Route to default backend because host not matched

💡 Routing completes after matching host and path rules or falls back to default service.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4
Request URL	none	http://example.com/images/cat.png	http://example.com/videos/movie.mp4	http://example.com/about	http://other.com/home
Matched Host	none	example.com	example.com	example.com	no match
Matched Path Rule	none	/images/*	/videos/*	default	no match
Routed Backend Service	none	backendServiceImages	backendServiceVideos	backendServiceA	backendServiceA

Key Moments - 2 Insights

What happens if the request host does not match any host rule?

If the host does not match any host rule (see step 4 in execution_table), the URL map routes the request to the defaultService backend.

How does the URL map decide which backend to route to when multiple path rules exist?

The URL map checks path rules in order and routes to the backend of the first matching path pattern (see steps 1 and 2). If none match, it uses the defaultService.

Visual Quiz - 3 Questions

Look at the execution_table, which backend service handles the request to 'http://example.com/videos/movie.mp4'?

A backendServiceA

B backendServiceImages

C backendServiceVideos

D No backend matched

💡 Hint

Check row 2 under 'Routed Backend Service' in execution_table.

At which step does the URL map route to the default backend because no path rule matched?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at the 'Matched Path Rule' column for 'default' in execution_table.

If the host 'other.com' was added to hostRules with a pathMatcher, how would step 4 change?

A Request would be rejected

B Matched Host would be 'other.com' and routing would follow path rules

C Matched Host remains 'no match' and routes to defaultService

D Routing would fail with error

💡 Hint

Refer to variable_tracker for 'Matched Host' changes and execution_table step 4.

Concept Snapshot

URL maps route incoming requests based on host and path.
Define hostRules to match domains.
Use pathMatchers with pathRules to route paths.
Requests not matching any rule go to defaultService.
This controls traffic flow in GCP load balancing.

Full Transcript

URL maps in GCP load balancing receive client requests and check the URL's host and path. First, the load balancer passes the request to the URL map. The URL map looks for a host rule matching the request's domain. If found, it uses the associated path matcher to check path rules. If a path matches, the request routes to the specified backend service. If no path matches, it routes to the default backend service. If no host matches, the request also routes to the default backend. This process ensures requests go to the right backend based on URL patterns.

Practice

1. What is the main purpose of a URL map in Google Cloud Platform's load balancing?

easy

A. To store user data for web applications

B. To create virtual machines automatically

C. To route incoming web traffic to different backend services based on URL paths or hosts

D. To monitor network traffic usage

Solution

1. Step 1: Understand URL map role

   A URL map directs web traffic to backend services depending on URL patterns.

2. Step 2: Identify correct function

   Routing based on URL paths or hosts matches the description of URL maps.

3. Final Answer:

   To route incoming web traffic to different backend services based on URL paths or hosts -> Option C

4. Quick Check:

   URL maps route traffic = B [OK]

Hint: URL maps decide backend by URL pattern [OK]

Common Mistakes:

• Confusing URL maps with storage or VM services
• Thinking URL maps monitor traffic instead of routing
• Assuming URL maps create resources automatically

2. Which of the following is the correct syntax to define a path matcher in a GCP URL map configuration?

easy

A. "pathMatcher": {"name": "pm1", "defaultService": "backend1"}

B. "pathMatchers": [{"name": "pm1", "defaultService": "backend1"}]

C. "pathMatchers": {"name": "pm1", "defaultService": "backend1"}

D. "pathMatcher": [{"name": "pm1", "defaultService": "backend1"}]

Solution

1. Step 1: Identify correct key for multiple path matchers

   The key for multiple path matchers is plural: "pathMatchers" with an array value.

2. Step 2: Confirm value type

   The value must be an array of objects, so square brackets [] are needed.

3. Final Answer:

   "pathMatchers": [{"name": "pm1", "defaultService": "backend1"}] -> Option B

4. Quick Check:

   Multiple path matchers use "pathMatchers" array = A [OK]

Hint: Use plural "pathMatchers" with array brackets [OK]

Common Mistakes:

• Using singular "pathMatcher" for multiple entries
• Using object instead of array for pathMatchers
• Mixing singular/plural keys incorrectly

3. Given this URL map snippet, which backend service will handle the request to https://example.com/images/logo.png?

{
  "defaultService": "backend-default",
  "pathMatchers": [
    {
      "name": "pm-images",
      "defaultService": "backend-images",
      "pathRules": [
        {"paths": ["/images/*"], "service": "backend-images"}
      ]
    }
  ]
}

medium

A. backend-images

B. No backend matches, request fails

C. backend-logo

D. backend-default

Solution

1. Step 1: Check path rules for "/images/*"

   The path matcher "pm-images" has a path rule matching "/images/*" directing to "backend-images".

2. Step 2: Match request URL path

   The request path "/images/logo.png" matches the "/images/*" pattern, so it routes to "backend-images".

3. Final Answer:

   backend-images -> Option A

4. Quick Check:

   Path "/images/*" matches request = backend-images [OK]

Hint: Match URL path to pathRules first, else defaultService [OK]

Common Mistakes:

• Choosing defaultService without checking pathRules
• Assuming no match causes failure instead of default routing
• Confusing path patterns with exact matches

4. You have this URL map configuration snippet:

{
  "defaultService": "backend-default",
  "pathMatchers": [
    {
      "name": "pm1",
      "defaultService": "backend1",
      "pathRules": [
        {"paths": ["/app/*"], "service": "backend-app"}
      ]
    }
  ]
}

Why does a request to https://example.com/app go to backend-default instead of backend-app?

medium

A. The defaultService overrides all pathRules

B. The path matcher name "pm1" is invalid

C. The backend service "backend-app" is not defined

D. The path "/app" does not match the pattern "/app/*" which requires a trailing slash

Solution

1. Step 1: Understand path pattern matching

   The pattern "/app/*" matches paths starting with "/app/" but not "/app" exactly.

2. Step 2: Check request path against pattern

   The request path "/app" lacks the trailing slash, so it does not match "/app/*" and falls back to defaultService.

3. Final Answer:

   The path "/app" does not match the pattern "/app/*" which requires a trailing slash -> Option D

4. Quick Check:

   Trailing slash matters in path patterns = C [OK]

Hint: Path patterns with * need trailing slash to match [OK]

Common Mistakes:

• Assuming "/app" matches "/app/*" without slash
• Thinking defaultService always overrides pathRules
• Believing backend service must be explicitly defined to route

5. You want to route requests to https://example.com/api/v1/users to backend-v1 and requests to https://example.com/api/v2/users to backend-v2. Which URL map configuration correctly achieves this?

hard

A. {
"defaultService": "backend-default",
"pathMatchers": [
{
"name": "pm-api",
"defaultService": "backend-default",
"pathRules": [
{"paths": ["/api/v1/*"], "service": "backend-v1"},
{"paths": ["/api/v2/*"], "service": "backend-v2"}
]
}
]
}

B. {
"defaultService": "backend-default",
"pathMatchers": [
{
"name": "pm-api",
"defaultService": "backend-v1",
"pathRules": [
{"paths": ["/api/v1/*"], "service": "backend-v1"},
{"paths": ["/api/v2/*"], "service": "backend-v2"}
]
}
]
}

C. {
"defaultService": "backend-default",
"pathMatchers": [
{
"name": "pm-api",
"defaultService": "backend-v2",
"pathRules": [
{"paths": ["/api/v1/*"], "service": "backend-v1"}
]
}
]
}

D. {
"defaultService": "backend-default",
"pathMatchers": [
{
"name": "pm-api",
"defaultService": "backend-default",
"pathRules": [
{"paths": ["/api/*"], "service": "backend-v1"},
{"paths": ["/api/*"], "service": "backend-v2"}
]
}
]
}

Solution

1. Step 1: Check path rules for specific version routing

   { "defaultService": "backend-default", "pathMatchers": [ { "name": "pm-api", "defaultService": "backend-default", "pathRules": [ {"paths": ["/api/v1/*"], "service": "backend-v1"}, {"paths": ["/api/v2/*"], "service": "backend-v2"} ] } ] } defines two distinct path rules: "/api/v1/*" to "backend-v1" and "/api/v2/*" to "backend-v2" which matches requirements.

2. Step 2: Verify defaultService and pathRules consistency

   { "defaultService": "backend-default", "pathMatchers": [ { "name": "pm-api", "defaultService": "backend-default", "pathRules": [ {"paths": ["/api/v1/*"], "service": "backend-v1"}, {"paths": ["/api/v2/*"], "service": "backend-v2"} ] } ] } uses "backend-default" as defaultService, so unmatched paths go there, which is correct.

3. Step 3: Identify issues in other options

   { "defaultService": "backend-default", "pathMatchers": [ { "name": "pm-api", "defaultService": "backend-v1", "pathRules": [ {"paths": ["/api/v1/*"], "service": "backend-v1"}, {"paths": ["/api/v2/*"], "service": "backend-v2"} ] } ] } sets defaultService to "backend-v1" which may misroute unmatched paths. { "defaultService": "backend-default", "pathMatchers": [ { "name": "pm-api", "defaultService": "backend-v2", "pathRules": [ {"paths": ["/api/v1/*"], "service": "backend-v1"} ] } ] } misses "/api/v2/*" pathRule. { "defaultService": "backend-default", "pathMatchers": [ { "name": "pm-api", "defaultService": "backend-default", "pathRules": [ {"paths": ["/api/*"], "service": "backend-v1"}, {"paths": ["/api/*"], "service": "backend-v2"} ] } ] } duplicates "/api/*" paths causing conflict.

4. Final Answer:

   Option A correctly routes /api/v1/* and /api/v2/* to respective backends -> Option A

5. Quick Check:

   Distinct pathRules for versions = A [OK]

Hint: Use distinct pathRules for each version prefix [OK]

Common Mistakes:

• Setting defaultService to one version backend
• Missing pathRule for one version
• Duplicating same path pattern causing conflicts