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.
]]>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:
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:
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.
]]>