Cloud Load Balancing release notes

Managed workload identity for backend mTLS is generally available for the following Application Load Balancers:

• Global external Application Load Balancers
• Regional external Application Load Balancers
• Cross-region internal Application Load Balancers
• Regional internal Application Load Balancers

The key benefits are as follows:

• Streamline certificate management: Automated certificate and trust management for backend mTLS through seamless integration with Certificate Authority Service and Certificate Manager.

• Eliminate operational toil: Certificates are automatically rotated based on the workload identity pool's configuration, removing the complexity and manual bottleneck of private key provisioning and maintenance.

• Improve visibility and governance: Gain visibility into communication between distributed services and proactively apply governance to workloads across environments.

For more information, see Backend mTLS with managed workload identity overview

For regional external passthrough Network Load Balancers, reserving specific or automatically allocated bring your own IP (BYOIP) IPv6 addresses before creating a load balancer, and promoting an ephemeral BYOIP IPv6 address in use by a load balancer to a reserved static IP address, is generally available (GA).

For more information, see the following documentation:

• Set up a regional external passthrough Network Load Balancer with a backend service.
• Set up a regional external passthrough Network Load Balancer for multiple IP protocols
• Set up a regional external passthrough Network Load Balancer with zonal NEGs

SSL policy cross-project referencing is now available for Application Load Balancers and proxy Network Load Balancers in Preview. You can use cross-project referencing to define and maintain a central SSL policy in an administrative project and reference it from target HTTPS proxies or target SSL proxies in different projects.

Cross-project referencing is supported for global and regional SSL policies. You can use cross-project referencing with the following load balancers:

• Global external Application Load Balancer
• Regional external Application Load Balancer
• Cross-region internal Application Load Balancer
• Regional internal Application Load Balancer
• Global external proxy Network Load Balancer

For more information, see Cross-project SSL policy referencing.

Global Front End combines global external Application Load Balancers, Google Cloud Armor, Cloud CDN, and Service Extensions into one solution to help deliver, scale, and secure your internet-facing applications.

For more information, see Global Front End.

This feature is available in Preview.

Regular expression URL rewrites (regexRewrite) for route rules in URL maps are now available for Application Load Balancers. You can use regular expression pattern rewrite actions to rewrite URL paths by substituting or removing URL path components before forwarding requests to your backends.

For more information, see Regular expression URL rewrites for route rules.

This feature is in Preview.

Cloud Load Balancing introduces a new version of the Network Load Balancer—the global external passthrough Network Load Balancer, which is the global variant of the regional external passthrough Network Load Balancer. The load balancer is available in Preview.

This load balancer variant solves use cases for Security Service Edge (SSE), DNS hosting, Adtech (real-time bidding), real-time communications (RTC), live streaming, and online gaming, among others.

Global external passthrough Network Load Balancers are Layer 4 passthrough load balancers that distribute external traffic among backends (instance groups or network endpoint groups) that can reside in multiple Google Cloud regions. By using Google's global anycast IP routing, the global external passthrough Network Load Balancer steers user traffic to the closest region with healthy backends and available capacity, delivering ultra-low latency and dynamic cross-region failover to ensure resilience to regional outages.

The load balancer provides you with two external IP addresses, each served by a disjoint and isolated global load balancing control and data plane server infrastructure (also known as an availability group) to provide high availability.

The load balancer supports TCP, UDP, ESP, GRE, ICMP, and ICMPv6 traffic and can handle both IPv4 and IPv6 traffic. You can deploy your backends in any of the following Google Cloud regions:

• North America: us-west1, us-west4, us-east4, us-east5
• Europe: europe-west2, europe-west3
• Asia: asia-southeast1, asia-south1, asia-northeast1
• South America: southamerica-east1
• Africa: africa-south1
• Australia: australia-southeast1

Note that this release doesn't support GKE backends for the global external passthrough Network Load Balancer.

For details on the new load balancer, see Global external passthrough Network Load Balancer overview.

Service load balancing policies (serviceLbPolicy) are now supported for regional external Application Load Balancers and regional internal Application Load Balancers. This feature enables advanced load balancing optimizations such as custom load balancing algorithms, auto-capacity draining, failover thresholds, and the ability to designate preferred backends for these load balancers.

For more information, see Advanced load balancing optimizations.

This feature is in Preview.

For regional external passthrough Network Load Balancers, you can reserve specific or automatically allocated bring your own IP (BYOIP) IPv6 addresses before creating a load balancer, so that the IPv6 address persists independently of the load balancer's lifecycle. You can also promote an ephemeral BYOIP IPv6 address that is in use by a load balancer to a reserved static IP address.

For more information, see the following documentation:

• Set up a regional external passthrough Network Load Balancer with a backend service.
• Set up a regional external passthrough Network Load Balancer for multiple IP protocols
• Set up a regional external passthrough Network Load Balancer with zonal NEGs

This feature is in Preview.

Regular expressions matchers in host and route rules in URL maps

You can now use regular expressions to configure more flexible and precise traffic routing rules within URL maps for Global external Application Load Balancers.

This feature lets you leverage the power of RE2 syntax for matching on:

• Route rules: Within pathMatchers, the matchRules array now supports a regexMatch field to validate the URL path against a specified regex pattern.
• Header matches: Within matchRules, the headerMatches array now supports a regexMatch field for pattern matching against HTTP header values.
• Query parameter matches: Within matchRules, the queryParameterMatches array now supports a regexMatch field for pattern matching against HTTP query parameters values.

For more details on usage and syntax, see URL map concepts: Regular expressions matchers in host and route rules.

This feature is in Preview.

TLS post-quantum key exchange support is now available for Application Load Balancers and external proxy Network Load Balancers. Post-quantum key exchange is essential for protecting today's traffic from future quantum computing decryption risks (harvest now, decrypt later attacks). With post-quantum key exchange enabled, the load balancer uses post-quantum key exchange with clients that support TLS 1.3 and X25519MLKEM768 key exchange.

This feature is rolling out in three phases:

• Phase 1 (Until October 2026): Post-quantum key exchange is not enabled by default. Customers can elect to opt in and enable it using their SSL policy.

• Phase 2 (October 2026 through October 2027): The feature is enabled by default. Customers can elect to defer (opt out) if required.

• Phase 3 (After October 2027): The feature is enabled by default, and options to defer are no longer effective.

We strongly encourage you to enable post-quantum key exchange now, even before it is turned on by default. The opportunity to test this today will help you verify that clients and any intermediate network devices can properly negotiate post-quantum key exchange.

For more information, see Post-quantum key exchange.

A modernized, component-centric interface for Cloud Load Balancing is available in Preview. This inaugural release provides an expanded perspective of load balancing infrastructure, offering enhanced transparency into individual component configurations.

Go to Cloud Console

The key features of this release include the following:

• Comprehensive resource inventory: A centralized, searchable, and sortable management layer for granular resources—including forwarding rules, target proxies, and TLSRoutes—facilitating detailed monitoring of resource status and interdependencies.

• Interactive resource topology: A contextual visualization tool that maps traffic flow from forwarding rules through proxies to backends, enabling technical teams to efficiently analyze dependencies and accelerate issue resolution.

• Integrated audit logging: Embedded audit logs within the console that offer a unified module for monitoring and tracking historical configuration changes.

For global external Application Load Balancers, you can configure Cloud CDN cache policies at various levels of a URL map. This provides granular control over caching policies based on criteria like hostname, URL path, HTTP headers, and query parameters. This feature is in General availability.

For more information, see Configure a Cloud CDN cache policy.

Frontend configuration for load balancing incoming IPv6 traffic is now supported for the following load balancers:

• Regional external Application Load Balancer
• Regional external proxy Network Load Balancer
• Regional internal Application Load Balancer
• Regional internal proxy Network Load Balancer
• Cross-region internal Application Load Balancer
• Cross-region internal proxy Network Load Balancer

This feature is in Preview.

For more information, see the following documentation: