You can see the latest product updates for all of Trusted Cloud by S3NS on the Trusted Cloud page, browse and filter all release notes in the Trusted Cloud console, or programmatically access release notes in BigQuery.
To get the latest product updates delivered to you, add the URL of this page to your feed reader, or add the feed URL directly.
February 20, 2025
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.
February 19, 2025
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).
February 18, 2025
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.
January 24, 2025
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:
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.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.
November 20, 2024
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_PORTendpoints)
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.
November 19, 2024
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.
November 12, 2024
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:
This feature is available in General Availability.
November 04, 2024
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.
October 31, 2024
Support for IPv6 static routes with a next hop internal passthrough Network Load Balancer (next-hop-ilb) is available in Preview.
October 30, 2024
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.
October 29, 2024
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.
October 28, 2024
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.
October 24, 2024
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_PORTendpoints)
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.
October 21, 2024
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.
October 18, 2024
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.
Previously, the classic external Application Load Balancer had lenient HTTP/2 request parsing that did not reject requests containing certain invalid characters in the request path. The same requests would have been rejected if they had arrived over HTTP/1 or HTTP/3.
Now, all HTTP requests, including HTTP/2 requests, are rejected if the path contains a character that isn't one of the following:
An allowed ASCII character specified in RFC 3986, sections 3.3 and 3.4.
One of the following special allowed characters:
[ ] { } | ^
All other characters must be properly URL encoded.
You can identify rejected requests in the proxy logs by looking for the following:
responseCode: 400response_code_details:invalid_http2_client_request_path
September 30, 2024
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.
September 16, 2024
Envoy-based Application Load Balancers now support authorization policies that let you establish access control checks for incoming traffic. For details, see Authorization policy.
This feature is available in Preview.
August 28, 2024
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.
August 05, 2024
Regional external Application Load Balancer, regional internal Application Load Balancer, and cross-region internal Application Load Balancer 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 to validate the client certificate's chain of trust.
For details, see the following:
- Mutual TLS authentication
- Set up mutual TLS with user-provided certificates
- Set up mutual TLS with a private CA
This capability is in General Availability.
The global external Application Load Balancer and the classic Application Load Balancer already support frontend mTLS (General Availability).
July 31, 2024
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 Preview.
July 29, 2024
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.
July 19, 2024
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.
July 15, 2024
Cloud Load Balancing introduces advanced cost, latency, and resiliency optimizations for your global external Application Load Balancers. These include the following capabilities:
- You can use a service load balancing policy to customize the parameters that influence how traffic is distributed within the backends associated with a backend service (for example, load balancing algorithm and auto-capacity draining).
- You can designate specific backends as preferred backends.
For details, see Advanced load balancing optimizations.
This feature is in General Availability.