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.
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:
This feature is in Preview.
For more information, see the following documentation:
]]>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:
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:
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:
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:
You can select a Certificate Manager certificate for the following 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:
TLSRoute API lets platform administrators
to manage frontend infrastructure while service owners manage their own routes
and backends independently.This feature is available for regional and cross-region proxy Network Load Balancers.
For more information, see:
]]>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:
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:
]]>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:
ECDHE-RSA-AES-GCM
and ECDHE-ECDSA-AES-GCM families.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:
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:
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:
pathMatchers, the matchRules array now supports a
regexMatch field to validate the URL path against a specified regex pattern.matchRules, the headerMatches array now
supports a regexMatch field for pattern matching against HTTP header values.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:
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:
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:
]]>GRPC_WITH_TLS health checks are used for health checking gRPC backends
with TLS enabled. For more information, see the following:
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:
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:
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:
This feature is available in General Availability.
]]>