Cloud Load Balancing release notes

Feature

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.

Security

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.

Change

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.

Feature

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:

This feature is available in General Availability.

Feature

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

This capability is in Preview.

Security

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.

Feature

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.

Feature

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:

Deprecated

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:

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.
Review your backend service and URL map headerAction configuration to remove any references to connection-specific hop-by-hop headers.

Announcement

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.

Feature

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.

Feature

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.

Feature

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.

Feature

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.

Feature

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:

This feature is available in General Availability.

Feature

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 available in Preview.

Feature

You can now use the Google Cloud Console to create the following load balancers in Premium Tier:

Regional external Application Load Balancer
Regional external proxy Network Load Balancer

Previously, only Standard Tier support was available in the Console.

Feature

The regional external Application Load Balancers, cross-region internal Application Load Balancers, regional internal Application Load Balancers, now support a configurable client HTTP keepalive timeout. The client HTTP keepalive timeout represents the maximum amount of time that a TCP connection can be idle between the (downstream) client and the target HTTP(S) proxy.

For details, see

External Application Load Balancers: Client HTTP keepalive timeout
Internal Application Load Balancers: Client HTTP keepalive timeout

This capability is available in General Availability.

Deprecated

The Global external Application Load Balancer and the Classic Application Load Balancer will no longer support TLS sessionID resumption. They continue to support modern forms of TLS resumption.

The TLS protocol supports an optimization which allows a client reconnecting to a server with which it has communicated before to perform a cheaper abbreviated handshake. This optimization is available in several modes, which include the modern PSK and ticket mechanisms, as well as the long-obsolete sessionID mechanism.

The Global external Application Load Balancer and the Classic Application Load Balancer are the only Google Cloud products that currently support the obsolete sessionID mechanism.

This sessionID mechanism is going to be disabled over the next 4-5 weeks. Clients that currently make use of sessionID will transparently fall back to full TLS handshakes. To recover the performance optimization gains, we recommend that you upgrade clients to modern TLS libraries which support the PSK or ticket mechanisms.

Feature

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 response header of the initial HTTP request.

For details, see Stateful cookie-based session affinity.

This capability is in Preview.

Feature

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 support IPv4 and IPv6 (dual-stack) backends.

Ingress IPv4 traffic can now be proxied over an IPv4 or IPv6 connection to the IPv4 and IPv6 (dual-stack) backends.

The following backends support dual stack:

VM instance group
Zonal NEGs (GCE_VM_IP_PORT)

You can now convert the load balancers from IPv4 based deployments to dual stack (IPv4 and IPv6) deployments.

For details, see:

This feature is available in Preview.

Feature

Bring your own IP lets you bring your own public IPv6 addresses to Google Cloud. IPv6 BYOIP addresses can be used with external passthrough Network Load Balancers. Bring your own IP for IPv6 addresses is available in General Availability.

Feature

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

VM instance group
Zonal NEGs (GCE_VM_IP_PORT)

You can now convert the load balancer from IPv4 based deployments to dual stack (IPv4 and IPv6) deployments.

For details, see:

This feature is available in Preview.

Feature

Application Load Balancers now support Certificate Manager allowlisted certificates. For more information, see Mutual TLS authentication.

This capability is in General Availability.

Feature

The cross-region internal proxy Network Load Balancer supports backends in multiple regions, provides seamless cross-region failover, and is globally accessible by clients from any Google Cloud region, on premise, or other clouds.

For details, see the Internal proxy Network Load Balancer overview.

To set up a cross-region internal proxy Network Load Balancer, see the following pages:

This capability is in General Availability.

Feature

You can now configure advanced traffic management using flexible pattern matching. This feature allows you to use wildcard syntax anywhere in your path matcher configuration. You can use this feature to customize origin routing for different types of traffic and request and response behaviors. In addition, you can now use results from your pattern matching to rewrite the path that is sent to the origin.

Pattern matching with wildcards is now supported for the following products:

Global external Application Load Balancer (launched previously)
Regional external Application Load Balancer
Cross-region internal Application Load Balancer
Regional internal Application Load Balancer
Traffic Director

For details, see URL maps overview: Wildcards and pattern matching operators in path templates for route rules.

This capability is available in General availability.

Feature

The global external Proxy Network Load Balancer is implemented on globally distributed GFEs and supports advanced traffic management capabilities. This load balancer can be configured to handle either TCP or SSL traffic by using either a target TCP proxy or a target SSL proxy respectively. Global external proxy Network Load Balancers support backends such as instance groups, hybrid NEGs, and Private Service Connect NEGs. For details, see the External proxy Network Load Balancer overview.

To set up a global external Proxy Network Load Balancer, see the following pages:

This capability is in General Availability.

Feature

The following regional load balancers can now be configured in either Premium or Standard Network Service Tier:

Regional internal Application Load Balancers
Regional external Application Load Balancers
Regional internal proxy Network Load Balancers
Regional external proxy Network Load Balancers

For more information about Network Service Tiers, see the Network Service Tiers overview.

This feature is available in General Availability.

Feature

Forwarding rules used with Application Load Balancers now let you specify any single port from1-65535.

For more information, see the following:

This feature is available in General Availability.

Feature

Service Extensions callouts are available for Google Cloud Application Load Balancers, excluding Classic.

By using this feature, you can direct your load balancers to make gRPC calls to user-managed or partner-hosted applications from within the Cloud Load Balancing data processing path. These applications can then apply various policies or functions, such as header or payload manipulation, security screening, or custom logging on the traffic before returning the traffic to the load balancer for further processing.

For details, see the following topics in the Service Extensions documentation:

Service Extensions is in Preview.

Feature

Cloud Load Balancing introduces the global external Proxy Network Load Balancer. The global external Proxy Network Load Balancer is implemented on globally distributed GFEs and supports advanced traffic management capabilities. This load balancer can be configured to handle either TCP or SSL traffic by using either a target TCP proxy or a target SSL proxy respectively. Global external proxy Network Load Balancers support backends such as instance groups, hybrid NEGs, and Private Service Connect NEGs.

Load balancers that are already deployed in the classic mode are renamed as classic Proxy Network Load Balancer in the console.

For details, see the External proxy Network Load Balancer overview.

To set up a global external Proxy Network Load Balancer, see the following pages:

This capability is in Preview.

With the launch of global external Proxy Network Load Balancer, we now support three deployment modes with the external Proxy Network Load Balancer—classic (General Availability), Regional (General Availability) and global (Preview). No changes have been made to the API.

For details, see the External proxy Network Load Balancer overview.

Feature

Typically with HTTPS communication, the authentication works only one way: the client verifies the identity of the server. For applications that require the load balancer to authenticate the identity of clients that connect to it, both a global external Application Load Balancer and a global external Application Load Balancer (classic) support mutual TLS (mTLS).

With mTLS, the load balancer requests that the client send a certificate to authenticate itself during the TLS handshake with the load balancer. You can configure a trust store that the load balancer uses to validate the client certificate's chain of trust.

For details, see the following:

This capability is in General Availability.

Change

The following changes have been made to the Google Cloud console:

Firewall rules has moved to Network security > Firewall policies.
SSL policies has moved to Network services > SSL policies.

Feature

Cloud Load Balancing introduces the cross-region internal Application Load Balancer.

The cross-region internal Application Load Balancer supports backends in multiple regions, provides seamless cross-region failover, and is globally accessible by clients from any Google Cloud region, on premise, or other clouds.

For details, see the Internal Application Load Balancer overview.

To set up a cross-region internal Application Load Balancer, see the following pages:

This capability is in Preview.

With the launch of cross-region internal Application Load Balancer, we now support two deployment modes with the internal Application Load Balancer—regional (General Availability) and cross-region (Preview). In the regional mode, you configure the Internal Application Load Balancer in a specific region, and associate it with backends only in the load balancer's region. Load balancers deployed in the regional mode are renamed as regional internal Application Load Balancer in the console. No changes have been made to the API.

For details, see the Internal Application Load Balancer overview.

Feature

The Cloud Load Balancing Console now allows you to see the equivalent API code for actions you take in the Console. When you create or update a load balancer, before you click Create or Update, you can click Equivalent Code to view the load balancer API resources that will be created, updated, or deleted.

This capability is in General Availability.

Feature

Global external Application Load Balancers now support outlier detection for serverless NEG backends. Outlier detection analysis identifies unhealthy serverless NEGs based on their HTTP response patterns, and reduces the error rate by routing some of the new requests from unhealthy services to healthy services. For more details, see the following topics:

Announcement

We're announcing the rebranding of Cloud Load Balancing into two main types of load balancers: Application Load Balancers and Network Load Balancers.

Over the past few years, we've undertaken several initiatives to bring greater consistency across all flavors of Cloud Load Balancing - for example, by making Envoy proxy the consistent data plane for all new load balancing features. Now, to further help our users understand the different features available with Cloud Load Balancing, and help them quickly identify the best type of load balancer for their use-case, we're adopting a new naming convention.

What is the new naming convention?

Cloud Load Balancing now offers two types of load balancers: Application Load Balancers and Network Load Balancers. As a general rule, you'd choose an Application Load Balancer when you need a Layer 7 load balancer for your applications with HTTP(S) traffic. You'd choose a Network Load Balancer when you need a Layer 4 (TCP) load balancer that supports TLS offloading (with a proxy load balancer) or you need support for additional IP protocols such as UDP (with a passthrough load balancer).

Application and Network Load Balancers can be configured in various deployment modes, for example, internal (private networks) or external (internet facing), global or regional.

For more details, see the following topics:

The Google Cloud Console has also been updated to reflect these changes. No changes have been made to the API.

Feature

The global external HTTP(S) load balancer now supports a configurable client HTTP Keepalive Timeout. The client HTTP keepalive timeout represents the maximum amount of time that a TCP connection can be idle between the (downstream) client and the target HTTP/S proxy.

For details, see

This capability is available in Preview.

Feature

The global external HTTP(S) load balancer now supports advanced traffic management using flexible pattern matching. This allows you to use wildcards anywhere in your path matcher. You can use this to customize origin routing for different types of traffic and request and response behaviors. In addition, you can now use results from your pattern matching to rewrite the path that is sent to the origin.

For details, see URL maps overview: Wildcards and pattern matching operators in path templates for route rules.

This capability is available in General availability.

Feature

Cloud Load Balancing introduces the external regional TCP proxy load balancer. This is an Envoy proxy-based regional layer 4 load balancer that enables you to run and scale your TCP service traffic in a single region behind an external regional IP address. External regional TCP proxy load balancer will load-balance external TCP traffic from the internet to backends in the same region.

For details, see the External Regional TCP Proxy Load Balancing overview

To set up an external regional TCP proxy load balancer, see the following pages:

This capability is in General Availability.

Change

If you're using hybrid NEGs with distributed Envoy health checks, you can't configure the same NON_GCP_PRIVATE_IP_PORT network endpoint in multiple hybrid NEGs. This configuration does not work with Envoy-based load balancers such as the regional external HTTP(S) load balancer, the internal HTTP(S) load balancer, and the internal TCP proxy load balancer.

Feature

Regional external and regional internal HTTP(S) load balancers now support using Cloud Run services as backends for the load balancer. This is configured using a serverless network endpoint group (NEG).

For details, see:

This feature is available in General availability.

Feature

Internal HTTP(S) load balancers and internal TCP proxy load balancers now support global access. By default, clients for these load balancers must be in the same region as the load balancer. With global access enabled, clients can access the load balancer from any region. They still must be in the same VPC network as the load balancer or in a VPC network that's connected to the load balancer's VPC network by using VPC Network Peering.

For instructions, see the following:

This capability is in General availability.

Feature

Network Load Balancing logging and Internal TCP/UDP Load Balancing logging are now available in General availability.

Feature

The global external HTTP(S) load balancer now supports advanced traffic management using flexible pattern matching. This allows you to use wildcards anywhere in your path matcher. You can use this to customize origin routing for different types of traffic and request and response behaviors. In addition, you can now use results from your pattern matching to rewrite the path that is sent to the origin.

For details, see URL maps overview: Wildcards and pattern matching operators in path templates for route rules.

This capability is available in Preview.

Feature

Currently, health check probes for hybrid NEGs originate from Google's centralized health checking mechanism. If you cannot allow traffic that originates from the Google health check ranges to reach your hybrid endpoints and would prefer to have the health check probes originate from your own private IP addresses instead, speak to your Google account representative to get your project allowlisted for distributed Envoy health checks.

This feature is available in Preview for allowlisted projects only.

Feature

External TCP and SSL proxy load balancers now allow you to specify a forwarding rule with a global anycast IP address and any port from 1-65535. The target TCP or SSL proxy terminates IPv4 or IPv6 client traffic at the specified port and then proxies the traffic to backend instances.

For more information, see the following:

This feature is available in General Availability.

Feature

Cloud Load Balancing introduces the internal regional TCP proxy load balancer. This is an Envoy proxy-based regional layer 4 load balancer that enables you to run and scale your TCP service traffic behind an internal regional IP address that is accessible only to clients in the same VPC network or clients connected to your VPC network.

The internal regional TCP proxy load balancer distributes TCP traffic to backends hosted on Google Cloud, on-premises, or other cloud environments.

For details, see the following:

Internal TCP Proxy Load Balancing overview
Set up an internal TCP proxy load balancer:

This capability is in Preview.

Feature

Regional internal HTTP(S) load balancers and regional external HTTP(S) load balancers now support a combination of zonal NEGs (of type GCE_VM_IP_PORT) and hybrid NEGs (of type NON_GCP_PRIVATE_IP_PORT) in a single backend service. For all supported backend combinations, see the table at Backend services.

This feature is available in General Availability.

Feature

Cloud Load Balancing introduces a new version of the external HTTP(S) load balancer. The new global external HTTP(S) load balancer with advanced traffic management capabilities contains many of the features of our existing classic HTTP(S) load balancer, but with an ever-growing list of traffic management capabilities such as weighted traffic splitting, request mirroring, outlier detection, fault injection, and so on.

For details on the new load balancer, see:

This load balancer is available in General Availability.

Feature

Regional external and regional internal HTTP(S) load balancers now support using Cloud Run services as backends for the load balancer. This is configured using a serverless network endpoint group (NEG).

For details, see:

This feature is available in Preview.

Feature

Regional external HTTP(S) load balancers now support Shared VPC configurations where the load balancer's forwarding rule, target proxy, and URL map, can be created in a host or service project, while the backend services and backends can be distributed across multiple service projects in the Shared VPC environment. This is referred to as cross-project service referencing. Cross-project backend services can be referenced from a single URL map.

Cross-project service referencing gives service developers and admins autonomy over the exposure of their services through the centrally managed load balancer.

For details, see:

This feature is available in Preview.

Announcement

Starting October 1, 2022, we'll apply an outbound data processing charge of $0.008 - $0.012 per GB (based on region) to all Cloud Load Balancing products in order to maintain consistency and alignment with the variable costs of the services across our Cloud Load Balancing portfolio. The charge will be called Outbound data processed by load balancer and the price will mirror the existing price for the Inbound data processed by load balancer charge.

If you are on an existing contract, your prices will not change for the lifetime of the contract, or until renewal.

The current internal HTTP(S) load balancer pricing already includes this charge, so no changes are being made there.

To learn more about this change, see the Google Cloud Blog post: Unlock more choice with updates to Google Cloud's infrastructure capabilities and pricing.

Feature

Backend subsetting for internal TCP/UDP load balancers lets you scale your internal TCP/UDP load balancer to support a larger number of backend VM instances per internal backend service.

This feature is in General availability.

Feature

You can now use a combination of zonal NEGs (of type GCE_VM_IP_PORT) and hybrid NEGs (of type NON_GCP_PRIVATE_IP_PORT) as backends for your global external HTTP(S) load balancers. For all supported backend combinations, see the table at Backend services.

Feature

Network Load Balancing introduces a new monitoring resource type loadbalancing.googleapis.com/ExternalNetworkLoadBalancerRule that lets you monitor all the supported protocols including TCP, UDP, ESP, and ICMP.

For details, see Monitoring Network Load Balancing.

This feature is available in General Availability.

Feature

Network Load Balancing now supports load-balancing ESP (Encapsulating Security Payload) and ICMP (Internet Control Message Protocol) traffic. To handle these protocols, you specify the new L3_DEFAULT protocol on the load balancer's forwarding rule.

For details, see:

This feature is available in General Availability.

Feature

External TCP/UDP Network Load Balancing now allows you to configure a connection tracking policy. A connection tracking policy introduces the following new properties to let you customize your load balancer's connection tracking behavior:

To learn about how connection tracking works, see Backend selection and connection tracking.

To learn how to configure a connection tracking policy, see Configure a connection tracking policy.

This feature is available in General Availability.

Change

The default behavior for HTTP/3 and Google QUIC is changing for global external HTTP(S) load balancers. The default setting of quicOverride=NONE will now advertise support for HTTP/3 to your clients. This change is currently rolling out globally.

If you don't want this behavior to change, you can disable HTTP/3 by setting quicOverride to DISABLE. For instructions, see Configuring HTTP/3.

Feature

Internal TCP/UDP Load Balancing now allows you to configure a connection tracking policy for the load balancer's backend service. A connection tracking policy introduces the following new properties to let you customize your load balancer's connection tracking behavior:

Tracking mode
Connection persistence on unhealthy backends
Idle timeout

To learn about how connection tracking works, see Traffic distribution.

This feature is available in General Availability.

Feature

Cloud Load Balancing introduces a new version of the external HTTP(S) load balancer. The new global external HTTP(S) load balancer with advanced traffic management capabilities contains many of the features of our existing classic HTTP(S) load balancer, but with an ever-growing list of traffic management capabilities such as weighted traffic splitting, request mirroring, outlier detection, fault injection, and so on.

For details on the new load balancer, see:

This load balancer is available in Public Preview.

Feature

External HTTP(S) Load Balancing is now available in a regional mode. The new regional external HTTP(S) load balancer contains many of the features of our existing global load balancer, but with an ever-growing list of advanced traffic management capabilities. You can use this load balancer for workloads with jurisdictional compliance requirements or to access the Standard Network Tier.

For details, see:

This load balancer is available in Public Preview.

Feature

Internal TCP/UDP Load Balancing now allows you to configure a connection tracking policy for the load balancer's backend service. A connection tracking policy introduces the following new properties to let you customize your load balancer's connection tracking behavior:

Tracking mode
Connection persistence on unhealthy backends
Idle timeout

To learn about how connection tracking works, see Traffic distribution.

This feature is available in Preview.

Feature

When you make an internal TCP/UDP load balancer the next hop of a static route, the route can now have instance tags (also called network tags).

In addition, you now have two different ways to specify the next hop:

Forwarding rule's name and the load balancer's region
Internal IP address of the forwarding rule

For more information, see the following pages:

Feature

External TCP/UDP Network Load Balancing now allows you to configure a connection tracking policy. A connection tracking policy introduces the following new properties to let you customize your load balancer's connection tracking behavior:

To learn about how connection tracking works, see Backend selection and connection tracking.

To learn how to configure a connection tracking policy, see Configure a connection tracking policy.

This feature is available in Preview.

Feature

Network Load Balancing now supports load-balancing ESP (Encapsulating Security Payload) and ICMP (Internet Control Message Protocol) traffic. To handle these protocols, you specify the new L3_DEFAULT protocol on the load balancer's forwarding rule.

For details, see:

This feature is available in Preview.

Announcement

Starting May 15, 2021, a newly-created custom static route using a next hop forwarding rule of an internal TCP/UDP load balancer will forward all protocol traffic, not just TCP and UDP traffic.

If a route created before May 15, 2021 is still in operation on August 14, 2021, it will automatically be migrated to forward all protocol traffic starting August 15, 2021. If you don't want to wait until then, you can enable forwarding of traffic for all protocols by creating new routes and deleting the old ones.

For more information, see Processing of TCP, UDP, and other protocol traffic.

Feature

Zonal NEGs (with GCE_VM_IP network endpoints) can now be used as backends for internal TCP/UDP load balancers. For more information on this type of zonal NEG, see Zonal NEGs overview. For instructions on how to set up an internal TCP/UDP load balancer with a zonal NEG backend, see Setting up Internal TCP/UDP Load Balancing with zonal NEGs

This feature is in General Availability.

Feature

Internal TCP/UDP Load Balancing now supports session affinity for the UDP protocol. This feature is available in General Availability.

Feature

External TCP/UDP Network Load Balancing is now supported with backend services. Compared to the target pool backend, a backend service gives you more fine-grained control over your load balancer, including access to features such as connection draining, failover policies, and support for managed instance groups as backends.

Network load balancers with a backend service can also use health checks that match the traffic (TCP, SSL, HTTP, HTTPS, or HTTP/2) they are distributing.

To get started, see:

This feature is available in General Availability.

Feature

Subsetting for internal TCP/UDP load balancers lets you scale your internal TCP/UDP load balancer to support a larger number of backend VM instances per internal backend service.

This feature is in Preview.

Feature

You can now use the gcloud compute url-maps validate command to test advanced route configurations such as routing based on headers and query parameters, HTTP to HTTPS redirects, and URL rewrites.

You can also use this command to independently run tests without saving changes to the URL map. This protects live traffic to your production services and prevents any unintended interruptions due to URL map misconfigurations.

This feature is now available in General Availability.

Feature

Zonal NEGs (with GCE_VM_IP network endpoints) can now be used as backends for internal TCP/UDP load balancers. For more information on this type of zonal NEG, see Zonal NEGs overview.

This feature is in Preview.

Feature

Identity-Aware Proxy (IAP) is supported with Internal HTTP(S) Load Balancing. This support is available in General Availability.

Feature

External TCP/UDP Network Load Balancing is now supported with backend services. Compared to the target pool backend, a backend service gives you more fine-grained control over your load balancer, including access to features such as connection draining, failover policies, and support for managed instance groups as backends.

Network load balancers with a backend service can also use health checks that match the traffic (TCP, SSL, HTTP, HTTPS, or HTTP/2) they are distributing.

To get started, see:

This feature is available in Preview.

Feature

For HTTP requests, the httpRequest.remoteIp and httpRequest.serverIp fields can include port information. For example 10.0.0.1:80.

Change

Added a new tutorial for delivering HTTP and HTTPS content over the same hostname when using Cloud CDN. While many browsers enforce the use of Transport Layer Security (TLS) and disallow non-secure content delivery, there are still use cases where non-secure delivery and secure delivery must be allowed over the same hostname.

Feature

Added total latency to external HTTP(S) load balancer Cloud Logging entries. Total latency measures from when the external HTTP(S) load balancer receives the first bytes of the incoming request headers until the external HTTP(S) load balancer finishes proxying the backend's response to the client. This feature is now available in General Availability.

Feature

The External HTTP(S) Load Balancer now supports setting custom response headers on backend buckets and services. This feature is available in Beta.

Custom response headers make it easier to set common web security headers and override response headers from your application at the load balancer.

Feature

The Organization policy constraint for restricting Cloud Load Balancing creation is now available in General Availability.

Feature

Internal TCP/UDP load balancers now support regional health checks. To configure, see Health checks for backend services. This feature is supported in General Availability.

Change

The introductory period during which you can use Internal HTTP(S) Load Balancing without charge is coming to an end. Starting on July 25, 2020, your usage of Internal HTTP(S) Load Balancing will be billed to your project.

Feature

You can now use a custom filter when you list endpoints in a zonal network endpoint group. This feature is available as a Beta release.

Feature

Internal TCP/UDP Load Balancing with failover groups is available in General Availability.

Change

Backend services documentation is updated through the Cloud Load Balancing doc set.

Feature

Network endpoint groups (NEGs) now support global, internet endpoints that let you create custom origins for Cloud CDN and deliver content over Google's high performance, distributed edge caching infrastructure when the content is hosted on-premises or in another cloud. This feature is available in General Availability.

Change

To help you get started quickly, added two new examples for external HTTP(S) Load Balancing:

Feature

Internal HTTP(S) Load Balancing now supports configurable idle timeouts.

Feature

IAM Conditions now supports forwarding rule attributes. You can use these attributes to specify the types of forwarding rules that a member can create. This feature is available in General Availability.

Feature

For Internal TCP/UDP Load Balancing, load balancing to multiple NICs on a single backend VM instance is now available in General Availability.

Feature

IAM Conditions now supports forwarding rule attributes. You can use these attributes to specify the types of forwarding rules that a member can create. This feature is available in Beta.

Feature

Internal TCP/UDP Load Balancing as next hop is available in General Availability..

Feature

Multiple domains for Google-managed SSL certificates is now available in Beta.

Change

For the HTTP(S), TCP proxy, and SSL proxy load balancers, the Stackdriver logging timestamp field in the LogEntry now shows the time that requests arrived at the load balancer. Previously, the timestamp showed the time the response was sent by the load balancer back to the client.

Change

Expanded information about the probe IP ranges for backend health checks.

Change

Added information about TCP and UDP request and return packets for Internal TCP/UDP Load Balancing.

Feature

HTTP(S) Load Balancing logging is now available in Beta.

Feature

Internal TCP/UDP Load Balancing as next hop is available in Beta.

Change

External HTTP(S) load balancers validate protocol selection during ALPN negotiation. For more information, see RFC 7301.

Feature

HTTP/2 between the load balancer and backends is available in General Availability.

Feature

The user-defined request header feature is available in General Availability.

Change

Documentation update: The quotas and limits for load balancing resources are now documented. See Load Balancing Resource Quotas.

Change

Documentation update: The global forwarding rules page (previously at /load-balancing/docs/https/global-forwarding-rules) is combined with Forwarding rule concepts.

Feature

Traffic Director is available in Beta.

Feature

QUIC support for HTTPS Load Balancing is now available in General Availability.

Feature

SSL Policies configuration for HTTPS and SSL Proxy Load Balancing is now available in General Availability.

Feature

Internal Load Balancing access across VPN or Interconnect is now available in General Availability.

Feature

Internal Load Balancing access across VPN or Interconnect is now available in Beta.

Feature

IPv6 Termination for HTTP(S), SSL Proxy, and TCP Proxy Load Balancing is now available in General Availability.

Feature

Regional instance groups for Internal Load Balancing is now available in General Availability.

Feature

IPv6 Termination for HTTP(S), SSL Proxy, and TCP Proxy Load Balancing is now available in Beta.

Feature

Websocket support for HTTP(S) Load Balancing is now available in General Availability.

Feature

IPv6 Termination for HTTP(S), SSL Proxy, and TCP Proxy Load Balancing is now available in Alpha.

Feature

Internal Load Balancing is now available in General Availability.

Feature

Internal Load Balancing is now available in Beta.

Feature

SSL Proxy Load Balancing is now available in Beta.

Feature

HTTP(S) Load Balancing is now available in General Availability.

Feature

HTTP Load Balancing is now available in Beta.

Cloud Load Balancing release notes

October 06, 2025

September 17, 2025

September 12, 2025

August 26, 2025

June 13, 2025

May 16, 2025

May 08, 2025

April 29, 2025

April 25, 2025

March 17, 2025

March 06, 2025

March 04, 2025

February 20, 2025

February 18, 2025

October 24, 2024

October 21, 2024

October 18, 2024

September 30, 2024

August 28, 2024

July 29, 2024

July 19, 2024

June 03, 2024

May 21, 2024

April 08, 2024

April 03, 2024

April 01, 2024

March 12, 2024

January 09, 2024

November 17, 2023

October 17, 2023

September 29, 2023

August 16, 2023

August 14, 2023

July 06, 2023

June 28, 2023

June 21, 2023

June 07, 2023

May 30, 2023

May 24, 2023

May 10, 2023

April 06, 2023

April 03, 2023

February 23, 2023

January 31, 2023

December 05, 2022

August 31, 2022

July 25, 2022

July 21, 2022

June 20, 2022

May 09, 2022

May 05, 2022

March 14, 2022

March 03, 2022

February 21, 2022

February 08, 2022

January 19, 2022

December 20, 2021

November 15, 2021

September 29, 2021

September 23, 2021

July 27, 2021

July 07, 2021

June 09, 2021

May 26, 2021

May 04, 2021

April 28, 2021

March 31, 2021

March 24, 2021

March 08, 2021

February 16, 2021

February 03, 2021

November 10, 2020

October 20, 2020

October 01, 2020

September 15, 2020

September 14, 2020

August 19, 2020

July 13, 2020

June 25, 2020