A URL rewrite is a traffic action where the Application Load Balancer modifies the host, path, or both in an incoming request before forwarding it to the backend service or backend bucket. This action separates the external URL that users see from the internal URL used by your services. The load balancer reads the incoming request URL and replaces its components based on rules defined in the URL map. For example, a request for www.mydomain.com/static/images/someimage.jpg can be rewritten to www.myorigin.com/august_snapshot/images/someimage.jpg before being sent to an external backend. Rewrites are path prefix rewrites where you can prepend a new path but cannot perform a full path replacement such as changing resource1 to resource2. You apply a rewrite action at three levels within a URL map: on a specific pathRule, on a pathMatcher for unmatched paths, or on the entire urlMap for unmatched hosts.
A URL redirect is a traffic action where the load balancer sends an HTTP 3xx response code back to the client, instructing the browser to make a new request to a different URL. This is used for HTTP-to-HTTPS enforcement, URL shortening, preventing broken links, and consolidating domain names. The load balancer can modify the host, path, or both in the redirect response and can choose to strip or retain query parameters. Redirects configured at the load balancer reduce latency compared to backend-implemented redirects and improve security by handling protocol upgrades at the edge. Supported redirect response codes are 301 (MOVED_PERMANENTLY_DEFAULT), 302 (FOUND), 303 (SEE_OTHER), 307 (TEMPORARY_REDIRECT), and 308 (PERMANENT_REDIRECT), with codes 307 and 308 retaining the original request method.
You configure rewrites and redirects by editing the URL map resource, which defines the routing rules for the Application Load Balancer. The load balancer's primary actions are mutually exclusive: it either routes a request to a backend service or performs a redirect. A rewrite action is applied before routing to a backend. The configuration uses either simple pathRules where order does not matter, or advanced routeRules which are evaluated in order and can match on URL path, HTTP headers, and query parameters. You choose between these two mutually exclusive modes for each URL map. The decision to use a rewrite versus a redirect depends on the goal: use a rewrite to transparently map user-friendly URLs to internal resource paths, and use a redirect to explicitly change the client's destination such as enforcing HTTPS or migrating to a new domain.
Traffic mirroring replicates network traffic from specified sources and forwards the mirrored packets to collector backends for security inspection, threat analysis, and operational troubleshooting without disrupting live production workloads. In Google Cloud, out-of-band traffic mirroring uses Network Security Integration deployment groups, internal passthrough Network Load Balancers, and specialized VPC network configurations. Traffic mirroring architectures require a custom Virtual Private Cloud network tailored to handle encapsulated inspection traffic alongside regular workload packets. Because mirrored packets use Generic Network Virtualization Encapsulation (GENEVE), the VPC network maximum transmission unit must be increased to 1856 bytes to accommodate the standard 1460-byte Google Cloud packet payload plus the 396-byte GENEVE encapsulation overhead. Network administrators establish a custom subnet within the target region to host the collection endpoints and routing paths.
Collector backends for mirrored traffic are structured behind an internal passthrough Network Load Balancer deployed in the inspection VPC network. The forwarding architecture consists of an unmanaged instance group or backend instances located in a specific zone, which receive traffic forwarded from the internal load balancer. Administrators define a mirroring deployment group with the purpose set to NSI out-of-band and create a mirroring deployment linked to the internal load balancer. The load balancer delivers the mirrored UDP packets directly to the security instances without modifying payload contents or terminating original client sessions.
Network firewall policies control the flow of encapsulated mirrored packets, health check probes, and administrative connections into the collector backends. A dedicated ingress firewall rule must allow UDP traffic on port 6081, the standard GENEVE port, sourced from the VPC subnet gateway IP address. Additional ingress firewall rules must permit Google Cloud health checks on TCP port 80 from the source IP ranges 35.191.0.0/16 and 130.211.0.0/22 to confirm instance availability. For secure administrative access, firewall policies must also permit SSH traffic on TCP port 22 from the Google Cloud Identity-Aware Proxy IPv4 range 35.235.240.0/20.
Traffic splitting in Google Kubernetes Engine is an explicit, weight-based traffic distribution mechanism that lets administrators allocate a specific percentage of requests to different backend services. When you configure traffic splitting on a Gateway resource, the GKE Gateway controller translates those weights into routing rules on the underlying Application Load Balancer, ensuring that each backend receives its designated share of traffic. This capability is particularly valuable for canary deployments where a new version of an application receives a small percentage of production traffic before a full rollout. Traffic splitting works across multiple GKE clusters or multiple regions through multi-cluster load balancing, allowing you to distribute traffic geographically while maintaining control over the split percentages. The GKE Gateway API supports traffic splitting through the HTTPRoute resource where you define weighted backends by specifying a percentage value for each destination service.
Weighted routing on Google Cloud Application Load Balancers allows you to distribute traffic across multiple backend services or backend pools based on weights you assign, giving you fine-grained control over how requests flow through your infrastructure. Both external and internal Application Load Balancers support weight-based routing, with the internal Application Load Balancer specifically supporting advanced traffic management capabilities such as weight-based traffic splitting for traffic originating from VPC networks and on-premises connections. When implementing weighted routing, you configure weights on each backend service or backend bucket, and the load balancer uses those weights to determine the probability that any given request goes to each destination. The weight-based routing works in conjunction with other traffic management features including host-based routing, path-based routing, and traffic mirroring, allowing you to build sophisticated routing policies that direct traffic based on multiple criteria. For canary deployments, you might route 90% of traffic to the stable backend and 10% to the canary version, then gradually increase the canary weight as confidence grows.
Session affinity works alongside traffic splitting to ensure that requests from the same user or client session are directed to the same backend service, maintaining user state during traffic shifts. When you combine session affinity with weighted routing, the load balancer first evaluates the affinity configuration to identify the target backend, then applies the weight-based routing logic for new or unaffinitized requests. This is critical for applications that store session state server-side such as shopping carts or authenticated sessions, because redirecting an established session to a different backend could result in lost state or authentication failures. Application Load Balancers support several session affinity options including client IP affinity, generated cookie affinity, and header-based affinity, each of which determines how the load balancer identifies a client session. During canary deployments or A/B tests, enabling session affinity ensures that users who begin interacting with the canary version continue using that version throughout their session.
GKE Gateway Service Extensions extend traffic splitting capabilities by injecting custom logic for advanced traffic control beyond simple weight-based distribution. Service Extensions let you modify headers and payloads for HTTP requests and responses, implement custom routing logic to control traffic flow, and integrate with external services for functions like authorization. These extensions operate at the Gateway level, meaning they can apply transformations or decisions before traffic reaches your backend services. The second-level gateway pattern, where a Cloud Service Mesh-configured edge proxy sits behind a Google Cloud-managed load balancer, provides another layer of traffic management flexibility. In this architecture, the first-level load balancer applies initial policies such as Cloud Armor protection, while the second-level edge proxy applies advanced traffic management including weight-based traffic splitting with regular expressions applied to HTTP headers.
Google Cloud Application Load Balancers can distribute traffic based on custom metrics beyond standard load balancing, enabling traffic management decisions informed by application-specific signals like GPU utilization, queue length, or business KPIs. Custom metrics are reported using the Open Request Cost Aggregation standard, which allows your application to communicate its current load or capacity to the load balancer. This approach provides a more accurate view of workload performance compared to traditional connection-based or request-rate-based distribution, particularly for workloads with variable resource usage patterns. In GKE, you configure custom metrics-based traffic management through the GKE Gateway API using the GCPBackendPolicy resource, which provides precise control over how backend services distribute traffic to their backends. This capability is particularly useful for generative AI inference workloads where GPU utilization varies significantly between requests, or for real-time gaming servers where player count and session characteristics determine optimal backend selection.
A URL rewrite modifies the request on the load balancer before forwarding it to the backend—the client never sees the change. A URL redirect sends an HTTP 3xx response back to the client, which then makes a new request to the different URL shown in the response.
Use traffic mirroring when you need to analyze actual production traffic for security analysis, threat detection, or debugging without affecting live users. Regular monitoring collects metrics but cannot inspect full packet contents the way mirroring does.
When session affinity is enabled, existing user sessions continue to their original backend even after you change the traffic split weights. New sessions follow the updated weight configuration, so users who started with the canary version continue using it while new traffic is distributed according to the new weights.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts