Cloud Load Balancing release notes

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:

• Forwarding rules overview
• IPv6 for Application Load Balancers and proxy Network Load Balancers
• Convert Application Load Balancer to IPv6
• Convert Proxy Network Load Balancer to IPv6
• Proxy-only subnets for Envoy-based load balancers

Application Load Balancers now support the configuration of a traffic duration setting when you add backends to backend services. You can configure this setting as SHORT or LONG based on the response time needed by backends to complete HTTP requests.

Application Load Balancers also support the use of the in-flight balancing mode that lets you configure the load balancer's traffic distribution to supported backends when requests take more than a second to complete.

This feature is in General availability.

Zonal affinity, which was previously available in Preview, is generally available (GA).

For more information, see Zonal affinity for internal passthrough Network Load Balancers.

Google tag gateway for advertisers lets website owners host and deploy Google tags through Google Cloud. You can use a global external Application Load Balancer to route measurement traffic on your website through your domain for improved measurement data accuracy. This provides more reliable data for advertising campaign optimization.

For more information, see Google tag gateway for advertisers.

You can use three new variables in custom request and response headers for Application Load Balancers:

• asn: The Autonomous System Number (ASN) associated with the client's IP address.

• cloud_trace_id: The trace ID extracted (or generated) from the HTTP request header.

• hostname: The original hostname specified by the client in the Host HTTP request header. This allows preservation of the original host header (equivalent to X-Forwarded-Host).

These variables are available for both global external Application Load Balancers and classic Application Load Balancers.

For more information, see Create custom headers in backend services.

Backend Cloud Storage buckets are available for regional external Application Load Balancers and regional internal Application Load Balancers.

For more information, see:

• Set up a regional external Application Load Balancer with Cloud Storage buckets
• Set up a regional internal Application Load Balancer with Cloud Storage buckets
• Set up a regional external Application Load Balancer with Cloud Storage buckets in a Shared VPC environment
• Set up a regional internal Application Load Balancer with Cloud Storage buckets in a Shared VPC environment

This feature is in General availability.

A new quota system governing the configuration size of Application Load Balancer is now available in Preview. This update increases the individual URL map size limit from 64 KB and 128 KB to 1 MB. For more information, see URL map size and quota units.

Key aspects of this feature include:

• Complexity-based quota: Quota units reflect URL map complexity (number of rules, hostnames, and path matchers).
• Scoped measurement: Quota is measured and enforced on a per-project, per-region, or per-VPC depending on Application Load Balancer type.
• Active consumption: Only URL maps currently referenced by forwarding rules contribute to quota usage.
• New URL map size limit: Projects enabled for the new quota have a new URL map size limit increased to 1 MB for global and regional external and internal Application Load Balancers. Classic Application Load Balancer remain restricted to 64 KB.

For more information on increasing your limit or to participate in the preview, please contact Google Cloud Support.

Policy profiles in authorization policies let you define the type of authorization being performed at the load balancer. This feature is available in Preview.

You can choose from the following profile types:

• Request authorization profile (REQUEST_AUTHZ): Evaluates access based on HTTP request headers. Authorization decisions can be made directly or delegated to custom services. This is the default profile.

• Content authorization profile (CONTENT_AUTHZ): Enables deep inspection of application payloads (headers, body, and trailers). This is used for content-based security, such as blocking prompt injection attacks and preventing sensitive data leaks. Authorization decisions are always delegated.

Policy profiles are supported for the following Google Cloud services:

• Regional external Application Load Balancers
• Regional internal Application Load Balancers
• Agent Gateway (Preview)
• Secure Web Proxy

To learn more about policy profiles, see Authorization policy overview.

Published service backends let you configure supported load balancers or regional Cloud Service Mesh to route traffic to published services through Private Service Connect endpoints.

For more information, see Published service backends.

This feature is in Preview.

Certificate Manager certificates are available in Google Cloud console while provisioning a load balancer.

You can select a certificate map for the following load balancers:

• Global external Application Load Balancers
• Classic Application Load Balancers
• Global external proxy Network Load Balancers
• Classic proxy Network Load Balancers

You can select a Certificate Manager certificate for the following load balancers:

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

This feature is in General availability.

SNI-based routing for proxy Network Load Balancers is now available in Preview.

You can now route TLS traffic based on Server Name Indication (SNI) hostnames by using the new TLSRoute resource. The load balancer inspects the initial unencrypted ClientHello message to extract the SNI hostname and route connections to the appropriate backend service. This feature provides pure TLS passthrough without terminating the connection at the load balancer. Key benefits include:

• End-to-end encryption: Clients can establish secure mTLS or TLS sessions directly with origin servers.
• Role-oriented management: The TLSRoute API lets platform administrators to manage frontend infrastructure while service owners manage their own routes and backends independently.
• Simplified IP management: Consolidate multiple services behind a single Private Service Connect (PSC) endpoint, reducing IPv4 address exhaustion.

This feature is available for regional and cross-region proxy Network Load Balancers.

For more information, see:

• Create a regional external proxy Network Load Balancer load balancer with TLS routes
• Create a regional internal proxy Network Load Balancer load balancer with TLS routes
• Create a cross-region internal proxy Network Load Balancer load balancer with TLS routes

Backend Cloud Storage buckets are available for regional external Application Load Balancers, regional internal Application Load Balancers, and cross-region internal Application Load Balancers in a Shared VPC environment.

Support for this feature is available in Preview for regional external Application Load Balancers and regional internal Application Load Balancers and in General availability for cross-region internal Application Load Balancers. For more information, see:

• Set up a regional external Application Load Balancer with Cloud Storage buckets in a Shared VPC environment
• Set up a regional internal Application Load Balancer with Cloud Storage buckets in a Shared VPC environment
• Set up a cross-region internal Application Load Balancer with Cloud Storage buckets in a Shared VPC environment

Backend mutual TLS (mTLS) and backend authenticated TLS is now Generally available for cross-region internal Application Load Balancers.

This update complements existing support for global and regional Application Load Balancers, allowing you to enforce bidirectional identity verification across your regional deployments.

For details, see the following:

• Backend mTLS overview
• Set up backend authenticated TLS
• Set up backend mTLS

To enhance security and help meet stringent compliance requirements like FedRAMP, you can now apply a FIPS-compliant SSL policy to your Application Load Balancers and proxy Network Load Balancers. This update also introduces the ability to enforce TLS 1.3 as the minimum protocol version.

New FIPS_202205 profile

The new FIPS_202205 profile, available as a predefined SSL policy, restricts the load balancer to use only FIPS 140-2/140-3 validated cryptographic modules and ciphers.

When this profile is selected, the load balancer:

• Enforces strict TLS settings, negotiating connections only using TLS 1.2 or TLS 1.3.
• Uses a limited set of approved cipher suites for TLS 1.2, such as the cipher suites in ECDHE-RSA-AES-GCM and ECDHE-ECDSA-AES-GCM families.
• Excludes non-FIPS ciphers for TLS 1.3, such as TLS_CHACHA20_POLY1305_SHA256.

Minimum TLS 1.3 Enforcement

You can now specify TLS 1.3 as the minimum version for your SSL policy, which must be paired with the RESTRICTED profile. If you mandate TLS 1.3 as the minimum version, any clients attempting to connect via TLS 1.2 or lower will be rejected. Ensure your client ecosystem supports TLS 1.3 before enforcing this minimum TLS version.

For more information, see the following:

• SSL policies overview
• Use SSL policies

This feature is in General availability.

Application Load Balancers now support the configuration of a traffic duration setting when you add backends to the backend services. You can configure this setting as SHORT or LONG based on the response time needed by backends to complete HTTP requests.

Application Load Balancers also support the use of a new in-flight balancing mode that lets you configure the load balancer's traffic distribution to supported backends when requests take more than a second to complete.

This feature is available in Preview.

Backend buckets are available for regional external Application Load Balancers and regional internal Application Load Balancers.

This feature enables to serve static content (such as images, video, and CSS) confined to a specific region, helping you meet strict data residency and compliance requirements for regulated workloads. This update ensures backend bucket availability across the entire Application Load Balancers portfolio.

For more information, see the following:

• Set up a regional external Application Load Balancer with Cloud Storage buckets
• Set up a regional internal Application Load Balancer with Cloud Storage buckets

This feature is in Preview.

Managed workload identity is available for backend mutual TLS (mTLS) in global external Application Load Balancers.

This feature allows to:

• Streamline certificate management: Managed workload identity enables 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

This feature is in Preview.

Starting December 17, 2025, requests with request methods that aren't compliant with RFC 9110, Section 5.6.2 will be rejected by a first-layer Google Front End (GFE) before reaching your load balancer or its backends. Previously, such non-compliant requests would have been rejected by the load balancer or its backends with a variety of error codes. With the GFE now handling such requests, you might observe a small decrease in error rates.

This change applies only to global external Application Load Balancers and classic Application Load Balancers.

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 Application Load Balancer. 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.

This feature is available for the following load balancers:

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

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

This feature is in Preview.

Backend mutual TLS (mTLS) and backend authenticated TLS are now Generally available for the following regional Application Load Balancers:

• Regional external Application Load Balancers
• Regional internal Application Load Balancers

This update complements existing support for global external Application Load Balancers, allowing you to enforce bidirectional identity verification across your regional deployments.

For details, see the following:

• Backend mTLS overview
• Set up backend authenticated TLS
• Set up backend mTLS

GRPC_WITH_TLS health checks are used for health checking gRPC backends with TLS enabled. For more information, see the following:

• Success criteria for gRPC
• Create health checks

This feature is in General availability.

The global and classic external Application Load Balancers implemented on Google Front-Ends (GFEs) now reject TLS connections when the client and the load balancer support ALPN (Application-Layer Protocol Negotiation), but don't share common ALPN protocols.

Previously, if a client proposed a list of application protocols during the TLS handshake using the ALPN extension and none were supported by the load balancer, ALPN would be deactivated and the connection would default to using HTTP/1 as the default application protocol. After this update, the GFE instead returns an SSL_TLSEXT_ERR_ALERT_FATAL response which causes the load balancer to terminate the TLS handshake, and the connection to close. This change ensures that an application-layer protocol is always explicitly negotiated between the clients and the load balancers that support ALPN.

You can specify a custom ephemeral /96 IPv6 address range when creating a regional IPv6 forwarding rule. For more information, see the following:

• Internal passthrough Network Load Balancer overview
• Backend service-based external passthrough Network Load Balancer overview
• Protocol forwarding overview

This feature is in General availability.

Both internal passthrough Network Load Balancers and external passthrough Network Load Balancers support load balancing to managed instance groups (MIGs) comprised of IPv6-only VM instances.

For more details, see the following pages:

• Set up an external passthrough Network Load Balancer with a backend service
• Set up an internal passthrough Network Load Balancer with VM instance group backends

This feature is in General availability.

Application Load Balancers support authorization policies that let you establish access control checks for incoming traffic.

For details, see Authorization policy overview.

This feature is in General availability.

Percentage-based request mirroring is now supported for the global and regional external Application Load Balancers (classic is not supported). By default, the mirrored backend service receives all requests, even if the original traffic is being split between multiple weighted backend services. You can now configure the mirrored backend service to receive only a percentage of the requests by using the mirrorPercent flag to specify the percentage of requests to be mirrored, expressed as a value between 0 and 100.0.

For an example, see Set up traffic management for regional external Application Load Balancers.

This feature is available in General availability.

A security fix was made which changes the behavior of requests and responses sent with the Transfer-Encoding: Chunked header to be more RFC 9112 compliant. The RFC states that both the chunked_body and the last-chunk fields must end in CRLF. This is now enforced.

The global and classic external Application Load Balancers implemented on Google Front-Ends (GFEs) now support HTTP/1.0 explicitly as a protocol during ALPN (Application-Layer Protocol Negotiation) negotiation.

Previously, when the GFEs didn't support HTTP/1.0 explicitly, the GFE would return an SSL_TLSEXT_ERR_NOACK response, disable ALPN, and fall back to using HTTP/1 (which includes HTTP/1.0 and HTTP/1.1) as the default application protocol. After this change, GFEs will instead return HTTP/1.0, which provides clients with positive confirmation that their advertised HTTP/1.0 was accepted.

You are not expected to make any changes with this update. If a TLS handshake with HTTP/1.0 is unsuccessful, please contact support.

The internal and external passthrough Network Load Balancers now support load balancing to unmanaged instance groups comprised of IPv6-only VM instances.

Protocol forwarding also supports IPv6-only target instances.

For more details, see the following pages:

• Protocol forwarding overview
• Backend service-based external passthrough Network Load Balancer overview
• Internal passthrough Network Load Balancer overview
• Set up an internal passthrough Network Load Balancer with IPv6-only subnets and backends

This feature is available in General Availability.

Cross-region internal Application Load Balancers can now route requests for static content to Cloud Storage buckets.

For more information, see Set up a cross-region internal Application Load Balancer with Cloud Storage buckets.

This capability is now in General Availability.

Starting October 15, 2025, the global and classic external Application Load Balancers are improving HTTP header handling for headers with obs-fold values to comply with the RFC 9112 standard

Previously, these load balancers would forward HTTP headers with obs-fold values (those split across multiple lines, with subsequent lines starting with a space or a tab) without any changes. Starting October 15, 2025, each obs-fold will be replaced with one or more space characters (SP octets) before forwarding the message upstream. This ensures that the header is correctly interpreted as a single line, as required by the HTTP specification.

What you need to do

Review your current client applications and backend services before October 15, 2025 and ensure that they generate HTTP headers with obs-fold values in a single-line format when communicating with these load balancers.

Because the obs-fold header fields have been deprecated in RFC 9112, compliant clients and servers should already avoid using this format. However, there is a possibility that services that specifically rely on the old, non-compliant multi-line format of headers with obs-fold values might experience unexpected behavior. You should proactively check your backend service logs for any errors originating from your services due to the modified obs-fold headers.

For more information on the HTTP specification regarding headers with obs-fold values, review RFC 9112, Section 5.2: Obsolete Line Folding.

Global external Application Load Balancers now support the JA4 fingerprint. The JA4 fingerprint can be added to a custom request header using the tls_ja4_fingerprint variable.

This capability is now in General Availability.

Application Load Balancers and Proxy Network Load Balancers now support TLS certificates with large key sizes. Previously, these load balancers supported only certificates with RSA-2048 or ECDSA P-256 key types. With this update, you can now use self-managed certificates with RSA-3072, RSA-4096, and ECDSA P-384 keys.

Key details:

• Supported key types (for self-managed certificates): RSA-2048, RSA-3072, RSA-4096, ECDSA P-256, and ECDSA P-384

• Load balancing coverage for self managed certificates:

  • Certificate Manager SSL certificates: Global and regional load balancing

  • Compute Engine SSL Certificates: Regional load balancing

• Pricing: An additional charge of $0.45 per 1 million connections applies with certificates that use RSA-3072 and RSA-4096 key types. There are no per-connection charges for certificates that use RSA-2048, ECDSA P-256, or ECDSA P-384 key types.

For more information, see the documentation for Supported key types.

This capability is now in General Availability.

Zonal affinity, configured on the backend service of an internal passthrough Network Load Balancer, lets you limit cross-zone traffic, reduce latency, and improve performance, all while maintaining the benefits of a multi-zonal architecture.

Internal passthrough Network Load Balancers support three zonal affinity options that offer varying degrees of preference for routing new connections to eligible backends that are in the same zone as a supported client.

For more information, see Zonal affinity for internal passthrough Network Load Balancers.

This feature is in Preview.

In typical HTTPS communication, neither the load balancer nor the backend verify each other's identity, assuming that they are within a secure perimeter and can be trusted. However, when perimeter security needs reinforcement or communication extends beyond the perimeter, backend mTLS becomes essential. Backend mTLS ensures secure communication by requiring both the load balancer and the backend to mutually verify their identities.

With backend authenticated TLS, the load balancer verifies the backend server's certificate by checking its chain of trust, thereby confirming the backend's identity. Conversely, with backend mTLS, the backend server verifies the client certificate presented by the load balancer. Together, these mechanisms enable backend mTLS, ensuring that both parties validate each other's identity.

Backend mTLS complements frontend mTLS, which is already generally available (GA).

For details, see the following:

• Backend mTLS overview
• Set up backend authenticated TLS
• Set up backend mTLS

This capability is in General Availability for global external Application Load Balancers.

Cloud Load Balancing supports load balancing to multi-NIC instances that use Dynamic NICs.

This capability is in Preview.

Cleartext HTTP/2 over TCP, also known as H2C, lets you use HTTP/2 without TLS. H2C is supported by internal and external Application Load Balancers for both of the following connections:

• Connections between clients and the load balancer. No special configuration is required. Support for this capability is already in General Availability.

• Connections between the load balancer and its backends. Support for this capability is now in General Availability.

  To configure H2C for connections between the load balancer and its backends, you set the backend service protocol to H2C.

Application Load Balancers now support the use of custom metrics that let you configure your load balancer's traffic distribution behavior to be based on metrics specific to your application or infrastructure requirements, rather than Google Cloud's standard utilization or rate-based metrics. Defining custom metrics for your load balancer gives you the flexibility to route application requests to the backend instances and endpoints that are most optimal for your workload.

For more information, see Custom metrics for Application Load Balancers.

This capability is in General availability.

To take advantage of the new features of the global external Application Load Balancer, you can now migrate your classic Application Load Balancer resources to the global external Application Load Balancer infrastructure.

To migrate to the global external Application Load Balancer, you change the load balancing scheme of your load balancing resources—specifically, the backend services and forwarding rules—from EXTERNAL to EXTERNAL_MANAGED. You can also rollback resources to the classic Application Load Balancer infrastructure, as long as you do so within 90 days of changing the load balancing scheme.

Cloud Console support is also available to help you complete the migration process.

For more details on the migration process, see the following pages:

• Migration overview
• Migrate resources from classic to global external Application Load Balancer
• Roll back migrated resources to classic Application Load Balancer

This capability is available in General availability.

A security vulnerability was detected in the classic Application Load Balancer service prior to April 26, 2025.

CVE-2025-4600 allowed attackers to smuggle requests to classic Application Load Balancers due to incorrect parsing of oversized chunk bodies. This vulnerability was addressed within the classic Application Load Balancer service on April 26, 2025 through improved input validation and parsing logic.

No action is needed. For more information, see the GCP-2025-027 security bulletin.

Global and cross-region load balancers now support enabling traffic isolation on the service load balancing policy. By default, these load balancers use the WATERFALL_BY_REGION algorithm which allows traffic overflow to other regions when backends in the region closest to the user are either full or unhealthy. Enabling traffic isolation lets the load balancer route traffic only to the region closest to the user, even if all the backends in that region are running at their configured capacity limit. You can also choose to prevent traffic overflow entirely by enabling this feature in STRICT mode.

For details, see Traffic isolation.

This feature is in Preview.

Global external Application Load Balancers that use HTTPS as the backend service protocol can now negotiate TLS 1.3 for the connection from the load balancer to the backend.

For more details, see TLS support.

This capability is available in General Availability.

All Application and Proxy Network Load Balancers now support deployments where the load balancer frontend and the load balancer backend use different VPC networks. This is supported without the use of a Shared VPC deployment.

For regional and cross-region load balancers, connectivity between the load balancer's VPC network and the backend VPC network must be configured using either VPC Network Peering, Cloud VPN tunnels, Cloud Interconnect VLAN attachments, or a Network Connectivity Center framework.

For global and classic load balancers, the different VPC networks don't need to be connected using VPC Network Peering because GFEs communicate directly with backends in their respective VPC networks.

For more details, see the following pages:

• External Application Load Balancer overview
• Internal Application Load Balancer overview
• External Proxy Network Load Balancer overview
• Internal Proxy Network Load Balancer overview

Starting April 28, 2025, the Global external Application Load Balancer and the Classic Application Load Balancer will no longer allow the use of custom request headers that reference connection-specific hop-by-hop headers.

This change applies only to HTTP/1.1 traffic. Connection-specific hop-by-hop headers are already disallowed by the HTTP/2 and HTTP/3 protocols.

This change is in accordance with RFC 2616 which states that these connection-specific hop-by-hop headers headers are meaningful only for a single transport-level connection and should not be forwarded by proxies.

The impacted hop-by-hop headers are: Connection, Keep-Alive, TE, Trailer, Transfer-Encoding, and Upgrade.

Starting April 28, 2025, connection-specific hop-by-hop headers that were configured by using custom headers will no longer be applied. These headers will only be set by the load balancer during normal connection handling.

Starting June 30, 2025, any configuration changes that reference the connection-specific hop-by-hop custom headers will no longer be accepted.

What you need to do

If you are an HTTP/1.1 user affected by this change, complete the following steps:

1. Determine if your application depends on the values of any hop-by-hop headers configured as custom headers. If any dependencies are found, replace them with an allowed custom header and modify your application accordingly.

2. Review your backend service and URL map headerAction configuration to remove any references to connection-specific hop-by-hop headers.

Google Cloud periodically renews Google-managed certificates by requesting them from certificate authorities (CAs). Certificate authorities verify domain control by checking DNS settings of the domain and in case of load balancer authorization attempting to contact the server behind the domain's IP address. The CAs that Google Cloud works with have introduced a verification method called Multi-Perspective Issuance Corroboration, that is becoming mandatory for all public CAs and that consists in performing the verification from multiple locations in the world. As a result, if DNS settings do not correctly and consistently resolve from all locations, the validation fails and Google-managed certificates will fail to renew.

To learn more about preventing multi-perspective domain validation failures for misconfigured DNS records, see Multi-perspective domain validation.

Cross-region internal Application Load Balancers can now route requests for static content to Cloud Storage buckets.

For more information, see Set up a cross-region internal Application Load Balancer with Cloud Storage buckets.

This capability is in Preview.

Application Load Balancers now support the use of custom metrics that let you configure your load balancer's traffic distribution behavior to be based on metrics specific to your application or infrastructure requirements, rather than Google Cloud's standard utilization or rate-based metrics. Defining custom metrics for your load balancer gives you the flexibility to route application requests to the backend instances and endpoints that are most optimal for your workload.

For more information, see Custom metrics for Application Load Balancers.

This capability is in Preview.

In typical HTTPS communication, neither the load balancer nor the backend verify each other's identity, assuming that they are within a secure perimeter and can be trusted. However, when perimeter security needs reinforcement or communication extends beyond the perimeter, backend mTLS becomes essential. Backend mTLS ensures secure communication by requiring both the load balancer and the backend to mutually verify their identities.

With backend authenticated TLS, the load balancer verifies the backend server's certificate by checking its chain of trust, thereby confirming the backend's identity. Conversely, with backend mTLS, the backend server verifies the client certificate presented by the load balancer. Together, these mechanisms enable backend mTLS, ensuring that both parties validate each other's identity.

Backend mTLS complements frontend mTLS, which is already generally available (GA).

For details, see the following:

• Backend mTLS overview
• Set up backend authenticated TLS
• Set up backend mTLS

This capability is in Preview for global external Application Load Balancers.

Cleartext HTTP/2 over TCP, also known as H2C, lets you use HTTP/2 without TLS. H2C is supported by internal and external Application Load Balancers for both of the following connections:

• Connections between clients and the load balancer. No special configuration is required. Support for this capability is in General Availability.

• Connections between the load balancer and its backends. Support for this capability is in Preview.

  To configure H2C for connections between the load balancer and its backends, you set the backend service protocol to H2C.

Internal and external passthrough Network Load Balancers now support connection draining for UDP and other non-TCP protocol traffic. For details, see Enable connection draining.

This feature is now generally available (GA).

TLS 1.3 early data is now supported on the target HTTPS proxy of global external Application Load Balancers and classic Application Load Balancers.

TLS 1.3 early data, also known as zero-round-trip time (0-RTT) data, can improve application performance for resumed connections by 30 to 50%.

For details, see TLS 1.3 early data support.

This feature is available in General Availability.

Changes to RSA certificate requirements coming April 28, 2025

We're changing how Application Load Balancers establish TLS connections to backends. This change fixes a problem where the keyUsage extension of RSA certificates is not being validated consistently and might allow a certificate that should have been rejected based on the keyUsage configuration.

What you need to do

Starting April 28, 2025, RSA certificates that don't meet the keyUsage configuration requirements will no longer be considered valid for establishing TLS connections. We recommend that you check whether your backends' RSA certificates are invalid, and replace them with valid certificates if needed.

A valid RSA certificate is one that has the X509v3 Key Usage extension and includes both the Digital Signature and Key Encipherment parameters.

To identify an invalid RSA certificate, perform the following steps:

1. First confirm that the certificate type is RSA by running the following command.

   openssl x509 -text -in cert.crt | grep "Public Key Algorithm".

   For RSA certificates, this should output rsaEncryption. If it is a non-RSA certificate (for example, EC), you don't need to take any more action at this time.

2. If it is an RSA certificate, examine the Key Usage configuration by running the following command:

   openssl x509 -text -in cert.crt | grep -A1 "X509v3 Key Usage"

   For a valid RSA certificate, the correct value is Digital Signature, Key Encipherment. If either of these values is not present, the RSA certificate is invalid.

For more information about the X.509 certificate format, see RFC 5280 Key Usage.

Cloud Load Balancing now supports failover for global, classic, and regional external Application Load Balancers. Failover is handled by creating two or more regional external Application Load Balancers in the regions where you want the traffic to failover to. Only regional external Application Load Balancers can be used as failover backup load balancers.

For details, see Failover for external Application Load Balancers.

This feature is available in General availability.

Regional external Application Load Balancers, cross-region internal Application Load Balancers, regional internal Application Load Balancers, regional internal proxy Network Load Balancers, cross-region internal proxy Network Load Balancers, and regional external proxy Network Load Balancers now support IPv4 and IPv6 (dual-stack) backends.

The following backends have dual-stack support:

• VM instance groups
• Zonal NEGs (GCE_VM_IP_PORT endpoints)

You can also convert your existing single-stack load balancers from IPv4-only to dual stack (IPv4 and IPv6) deployments.

For details, see the following pages:

• IPv6 overview
• Convert your existing Application Load Balancer to IPv6
• Convert your existing proxy Network Load Balancer to IPv6

This feature is available in General Availability.

Percentage-based request mirroring is now supported for the cross-region and regional internal Application Load Balancers. By default, the mirrored backend service receives all requests, even if the original traffic is being split between multiple weighted backend services. You can now configure the mirrored backend service to receive only a percentage of the requests by using the mirrorPercent flag to specify the percentage of requests to be mirrored expressed as a value between 0 and 100.0.

For an example, see Set up traffic management for regional internal Application Load Balancers.

This capability is available in Preview.

Cloud Load Balancing resources now let you use custom constraints to define your own restrictions on Google Cloud services. To learn about which load balancing resources support custom constraints, and some sample use cases, see Manage Cloud Load Balancing resources using custom constraints.

For more information about custom constraints, see the following:

• Custom organization policies
• Custom constraint supported services

This feature is available in General Availability.

Percentage-based request mirroring is now supported for the global and regional external Application Load Balancers (classic is not supported). By default, the mirrored backend service receives all requests, even if the original traffic is being split between multiple weighted backend services. You can now configure the mirrored backend service to receive only a percentage of the requests by using the mirrorPercent flag to specify the percentage of requests to be mirrored expressed as a value between 0 and 100.0.

For an example, see Set up traffic management for regional external Application Load Balancers.

This capability is available in Preview.

Support for IPv6 static routes with a next hop internal passthrough Network Load Balancer (next-hop-ilb) is available in Preview.

Service Extensions plugins are available for Google Cloud Application Load Balancers, excluding Classic, in Preview.

Service Extensions plugins help you insert WebAssembly (Wasm) plugins in a fully managed serverless environment directly into the data path of Application Load Balancers.

For details, see Plugins for Cloud Load Balancing.

All the Application Load Balancers, except the classic Application Load Balancer, now support stateful cookie-based session affinity. When you use stateful cookie-based affinity, the load balancer includes an HTTP cookie in the Set-Cookie header in response to the initial HTTP request. With stateful session affinity, customers can preserve stickiness to the selected backend.

For details, see Stateful cookie-based session affinity.

This capability is in General Availability.

To take advantage of the new features of the global external Application Load Balancer, you can now migrate your classic Application Load Balancer resources to the global external Application Load Balancer infrastructure.

To migrate to the global external Application Load Balancer, you change the load balancing scheme of your load balancing resources—specifically, the backend services and forwarding rules—from EXTERNAL to EXTERNAL_MANAGED. You can also rollback resources to the classic Application Load Balancer infrastructure, as long as you do so within 90 days of changing the load balancing scheme.

For more details on the migration process, see the following pages:

• Migration overview
• Migrate resources from classic to global external Application Load Balancer
• Roll back migrated resources to classic Application Load Balancer

This capability is available in Preview.

Global external Application Load Balancers and global external proxy Network Load Balancers can now load balance IPv6 traffic. The following backends have dual-stack support:

• VM instance groups
• Zonal NEGs (GCE_VM_IP_PORT endpoints)

You can also convert your existing single-stack load balancers from IPv4-only to dual stack (IPv4 and IPv6) deployments.

For details, see the following pages:

• IPv6 overview
• Convert your existing Application Load Balancer to IPv6
• Convert your existing proxy Network Load Balancer to IPv6

This feature is available in General Availability.