You can see the latest product updates for all of Google Cloud on the Google Cloud page, browse and filter all release notes in the Google 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.
For regional external passthrough Network Load Balancers, you can reserve specific or automatically allocated bring your own IP (BYOIP) IPv6 addresses before creating a load balancer, so that the IPv6 address persists independently of the load balancer's lifecycle. You can also promote an ephemeral BYOIP IPv6 address that is in use by a load balancer to a reserved static IP address.
For more information, see the following documentation:
This feature is in Preview.
TLS post-quantum key exchange support is now available for
Application Load Balancers and external proxy Network Load Balancers.
Post-quantum key exchange is
essential for protecting today's traffic from future quantum computing
decryption risks (harvest now, decrypt later attacks).
With post-quantum key exchange enabled, the
load balancer uses post-quantum key exchange with clients that support TLS
1.3 and X25519MLKEM768 key exchange.
This feature is rolling out in three phases:
Phase 1 (Until October 2026): Post-quantum key exchange is not enabled by default. Customers can elect to opt in and enable it using their SSL policy.
Phase 2 (October 2026 through October 2027): The feature is enabled by default. Customers can elect to defer (opt out) if required.
Phase 3 (After October 2027): The feature is enabled by default, and options to defer are no longer effective.
We strongly encourage you to enable post-quantum key exchange now, even before it is turned on by default. The opportunity to test this today will help you verify that clients and any intermediate network devices can properly negotiate post-quantum key exchange.
For more information, see Post-quantum key exchange.
A modernized, component-centric interface for Cloud Load Balancing is available in Preview. This inaugural release provides an expanded perspective of load balancing infrastructure, offering enhanced transparency into individual component configurations.
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.
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.
Global and cross-region load balancers now support enabling traffic isolation on the service load balancing policy. By default, these load balancers use the WATERFALL_BY_REGION algorithm which allows traffic overflow to other regions when backends in the region closest to the user are either full or unhealthy. Enabling traffic isolation lets the load balancer route traffic only to the region closest to the user, even if all the backends in that region are running at their configured capacity limit. You can also choose to prevent traffic overflow entirely by enabling this feature in STRICT mode.
For details, see Traffic isolation.
This feature is in Preview.
Global external Application Load Balancers that use HTTPS as the backend service protocol can now negotiate TLS 1.3 for the connection from the load balancer to the backend.
For more details, see TLS support.
This capability is available in General Availability.
All Application and Proxy Network Load Balancers now support deployments where the load balancer frontend and the load balancer backend use different VPC networks. This is supported without the use of a Shared VPC deployment.
For regional and cross-region load balancers, connectivity between the load balancer's VPC network and the backend VPC network must be configured using either VPC Network Peering, Cloud VPN tunnels, Cloud Interconnect VLAN attachments, or a Network Connectivity Center framework.
For global and classic load balancers, the different VPC networks don't need to be connected using VPC Network Peering because GFEs communicate directly with backends in their respective VPC networks.
For more details, see the following pages:
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.
Google Cloud periodically renews Google-managed certificates by requesting them from certificate authorities (CAs). Certificate authorities verify domain control by checking DNS settings of the domain and in case of load balancer authorization attempting to contact the server behind the domain's IP address. The CAs that Google Cloud works with have introduced a verification method called Multi-Perspective Issuance Corroboration, that is becoming mandatory for all public CAs and that consists in performing the verification from multiple locations in the world. As a result, if DNS settings do not correctly and consistently resolve from all locations, the validation fails and Google-managed certificates will fail to renew.
To learn more about preventing multi-perspective domain validation failures for misconfigured DNS records, see Multi-perspective domain validation.
Cross-region internal Application Load Balancers can now route requests for static content to Cloud Storage buckets.
For more information, see Set up a cross-region internal Application Load Balancer with Cloud Storage buckets.
This capability is in Preview.
Application Load Balancers now support the use of custom metrics that let you configure your load balancer's traffic distribution behavior to be based on metrics specific to your application or infrastructure requirements, rather than Google Cloud's standard utilization or rate-based metrics. Defining custom metrics for your load balancer gives you the flexibility to route application requests to the backend instances and endpoints that are most optimal for your workload.
For more information, see Custom metrics for Application Load Balancers.
This capability is in Preview.
In typical HTTPS communication, neither the load balancer nor the backend verify each other's identity, assuming that they are within a secure perimeter and can be trusted. However, when perimeter security needs reinforcement or communication extends beyond the perimeter, backend mTLS becomes essential. Backend mTLS ensures secure communication by requiring both the load balancer and the backend to mutually verify their identities.
With backend authenticated TLS, the load balancer verifies the backend server's certificate by checking its chain of trust, thereby confirming the backend's identity. Conversely, with backend mTLS, the backend server verifies the client certificate presented by the load balancer. Together, these mechanisms enable backend mTLS, ensuring that both parties validate each other's identity.
Backend mTLS complements frontend mTLS, which is already generally available (GA).
For details, see the following:
This capability is in Preview for global external Application Load Balancers.
Cleartext HTTP/2 over TCP, also known as H2C, lets you use HTTP/2 without TLS. H2C is supported by internal and external Application Load Balancers for both of the following connections:
Connections between clients and the load balancer. No special configuration is required. Support for this capability is in General Availability.
Connections between the load balancer and its backends. Support for this capability is in Preview.
To configure H2C for connections between the load balancer and its backends, you set the backend service protocol to H2C.
Internal and external passthrough Network Load Balancers now support connection draining for UDP and other non-TCP protocol traffic. For details, see Enable connection draining.
This feature is now generally available (GA).
TLS 1.3 early data is now supported on the target HTTPS proxy of global external Application Load Balancers and classic Application Load Balancers.
TLS 1.3 early data, also known as zero-round-trip time (0-RTT) data, can improve application performance for resumed connections by 30 to 50%.
For details, see TLS 1.3 early data support.
This feature is available in General Availability.
Changes to RSA certificate requirements coming April 28, 2025
We're changing how Application Load Balancers establish TLS connections to backends. This change fixes a problem where the keyUsage extension of RSA certificates is not being validated consistently and might allow a certificate that should have been rejected based on the keyUsage configuration.
What you need to do
Starting April 28, 2025, RSA certificates that don't meet the keyUsage configuration requirements will no longer be considered valid for establishing TLS connections. We recommend that you check whether your backends' RSA certificates are invalid, and replace them with valid certificates if needed.
A valid RSA certificate is one that has the X509v3 Key Usage extension and includes both the Digital Signature and Key Encipherment parameters.
To identify an invalid RSA certificate, perform the following steps:
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.
Cloud Load Balancing now supports failover for global, classic, and regional external Application Load Balancers. Failover is handled by creating two or more regional external Application Load Balancers in the regions where you want the traffic to failover to. Only regional external Application Load Balancers can be used as failover backup load balancers.
For details, see Failover for external Application Load Balancers.
This feature is available in General availability.
Regional external Application Load Balancers, cross-region internal Application Load Balancers, regional internal Application Load Balancers, regional internal proxy Network Load Balancers, cross-region internal proxy Network Load Balancers, and regional external proxy Network Load Balancers now support IPv4 and IPv6 (dual-stack) backends.
The following backends have dual-stack support:
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.
Percentage-based request mirroring is now supported for the cross-region and regional internal Application Load Balancers. By default, the mirrored backend service receives all requests, even if the
original traffic is being split between multiple weighted backend services. You
can now configure the mirrored backend service to receive only a percentage of the
requests by using the mirrorPercent flag to specify the percentage of
requests to be mirrored expressed as a value between 0 and 100.0.
For an example, see Set up traffic management for regional internal Application Load Balancers.
This capability is available in Preview.
Cloud Load Balancing resources now let you use custom constraints to define your own restrictions on Google Cloud services. To learn about which load balancing resources support custom constraints, and some sample use cases, see Manage Cloud Load Balancing resources using custom constraints.
For more information about custom constraints, see the following:
This feature is available in General Availability.
Percentage-based request mirroring is now supported for the global and regional external Application Load Balancers (classic is not supported). By default, the mirrored backend service receives all requests, even if the
original traffic is being split between multiple weighted backend services. You
can now configure the mirrored backend service to receive only a percentage of the
requests by using the mirrorPercent flag to specify the percentage of
requests to be mirrored expressed as a value between 0 and 100.0.
For an example, see Set up traffic management for regional external Application Load Balancers.
This capability is available in Preview.
Support for IPv6 static routes with a next hop internal passthrough Network Load Balancer (next-hop-ilb) is available in Preview.
Service Extensions plugins are available for Google Cloud Application Load Balancers, excluding Classic, in Preview.
Service Extensions plugins help you insert WebAssembly (Wasm) plugins in a fully managed serverless environment directly into the data path of Application Load Balancers.
For details, see Plugins for Cloud Load Balancing.
All the Application Load Balancers, except the classic Application Load Balancer, now support stateful cookie-based session affinity. When you use stateful cookie-based affinity, the load balancer includes an HTTP cookie in the Set-Cookie header in response to the initial HTTP request. With stateful session affinity, customers can preserve stickiness to the selected backend.
For details, see Stateful cookie-based session affinity.
This capability is in General Availability.
To take advantage of the new features of the global external Application Load Balancer, you can now migrate your classic Application Load Balancer resources to the global external Application Load Balancer infrastructure.
To migrate to the global external Application Load Balancer, you change the load balancing scheme of your load balancing resources—specifically, the backend services and forwarding rules—from EXTERNAL to EXTERNAL_MANAGED. You can also rollback resources to the classic Application Load Balancer infrastructure, as long as you do so within 90 days of changing the load balancing scheme.
For more details on the migration process, see the following pages:
This capability is available in Preview.
Global external Application Load Balancers and global external proxy Network Load Balancers can now load balance IPv6 traffic. The following backends have dual-stack support:
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.
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.
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_pathYou can now use the Google Cloud Console to create the following load balancers in Premium Tier:
Previously, only Standard Tier support was available in the Console.
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
This capability is available in General Availability.
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.
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.
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:
This capability is in General Availability.
The global external Application Load Balancer and the classic Application Load Balancer already support frontend mTLS (General Availability).
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.
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.
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:
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.
Cloud Load Balancing introduces advanced cost, latency, and resiliency optimizations for your global external Application Load Balancers. These include the following capabilities:
For details, see Advanced load balancing optimizations.
This feature is in General Availability.
You can now access backend services residing in different projects than the external or internal Application Load Balancers with cross-project service referencing.
For details, see:
Set up a global external Application Load Balancer with Shared VPC
Set up regional external Application Load Balancers with Shared VPC
Set up an internal Application Load Balancer with Shared VPC
This feature is available in General Availability.
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.
Global external Application Load Balancers and global external proxy Network Load Balancers can now load balance IPv6 traffic. The following backends support dual stack:
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.
Internal passthrough Network Load Balancer now supports load-balancing for TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, and GRE protocols. To handle multiple protocol traffic, you set the load balancer's forwarding rule protocol to L3_DEFAULT and set the backend service protocol to UNSPECIFIED.
For details, see:
This feature is available in General Availability.
Application Load Balancers now support Certificate Manager allowlisted certificates. For more information, see Mutual TLS authentication.
This capability is in General Availability.
The cross-region internal Application Load Balancer supports backends in multiple regions, provides seamless cross-region failover using Cloud DNS routing policies, and is globally accessible by clients from any Google Cloud region, on premise, or other clouds. Supports Google-managed certificates using Cloud Certificate Manager and Certificate Authority Service.
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 General Availability.
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.
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:
For details, see URL maps overview: Wildcards and pattern matching operators in path templates for route rules.
This capability is available in General availability.
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, 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 that the load balancer uses to validate the client certificate's chain of trust.
For details, see the following:
This capability is in Preview.
Global external Application Load Balancer and global external Application Load Balancer (classic) already support frontend mTLS(General Availability).
The Google Cloud Console has launched a new wizard experience to walk you through the process of selecting a new load balancer. The new wizard walks you through all the available options (internal or internet-facing, proxy or passthrough, global or regional) and guides you to the appropriate load balancer for your use-case.
Try out the new wizard in the Google Cloud Console at Create a 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. 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.
Regional external Application Load Balancers and regional internal Application Load Balancers now support Certificate Manager certificates. For more information, see Certificates and Google Cloud load balancers.
This capability is in General Availability.
Global external Application Load Balancers now let you customize your own error responses when an HTTP error status code (4xx and
5xx) is generated. You can customize error responses for errors generated by
both the load balancer and the backend instances. You can also customize error
responses for error response codes that are generated when traffic is denied by
Cloud Armor.
For more information, see the following pages:
This feature is available in Preview.
External passthrough Network Load balancers now support zonal NEGs with GCE_VM_IP endpoints. This also lets you add any network interface of a VM as an endpoint for a zonal NEG backend, as long as the network interface belongs to the same subnetwork as the NEG. In comparison, you can only attach the nic0 of a VM to an instance group backend.
For more details, see the following pages:
The following regional load balancers can now be configured in either Premium or Standard Network Service Tier:
For more information about Network Service Tiers, see the Network Service Tiers overview.
This feature is available in General Availability.
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.
Regional Application Load Balancers and regional proxy Network Load Balancers now support load balancing traffic to external backends outside Google Cloud. To define an external backend for a load balancer, you use a regional internet network endpoint group (NEG).
For details, see the following:
This capability is in General Availability.
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.
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.
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.
Regional external HTTP(S), internal HTTP(S), and the regional internal TCP proxy load balancers now use distributed Envoy health checks instead of Google's centralized health checking mechanism. Envoy health check probes originate from the proxy-only subnet associated with the load balancer.
For more details, see the Hybrid NEG documentation: Distributed Envoy health checks.
This feature is available in General availability.
Cloud Load Balancing is introducing new advanced cost, latency, and resiliency optimizations for your global external Application Load Balancer. These include the following capabilities:
For details, see Advanced load balancing optimizations.
This feature is in Preview.
Internal passthrough Network Load Balancers can now be configured to handle private IPv6 traffic within your VPC. To enable this, you must configure your dual-stack subnet, backend VMs, health checks, and the forwarding rules to handle IPv6 traffic.
For details, see:
This feature is available in General Availability.
The following changes have been made to the Google Cloud console:
Regional Application Load Balancers and regional proxy Network Load Balancers now support load balancing traffic to external backends outside Google Cloud. To define an external backend for a load balancer, you use a regional internet network endpoint group (NEG).
For details, see the following:
This capability is in Preview.
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.
The global external Application 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 General Availability.
Internal passthrough Network Load Balancer now supports load-balancing for TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, and GRE protocols. To handle multiple protocol traffic, you set the load balancer's forwarding rule protocol to L3_DEFAULT and set the backend service protocol to UNSPECIFIED.
For details, see:
This feature is available in Preview.
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.
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:
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.
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.
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.
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.
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.
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 HTTP(S) load balancer and a global external HTTP(S) 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 Preview.
Global external HTTP(S) load balancers now support proxying traffic to external backends outside Google Cloud. To define an external backend for a load balancer, you use a global resource called an internet network endpoint group (NEG).
For details, see the following:
This capability is in Preview.
We have added new fields in the logging support available for Regional external HTTP(S) load balancer and Internal HTTP(S) Load Balancer:
proxyStatus a string that specifies why the load balancer returned an error response
tls specifies the tls metadata for the connection between the client and the load balancer
For details, see
This enhancement is available in General availability.
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.
Forwarding rules for external TCP/UDP network load balancers can now be configured to direct traffic coming from a specific range of source IP addresses to a specific backend service (or target instance). This is called traffic steering.
For details, see:
This capability is in General availability.
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.
Network Load Balancing now supports user-specified weights on the backend service. This allows you to manage the backend load distribution of your load balancer and avoid overloading them.
For details, see:
This feature is in General Availability.
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 Preview.
Network Load Balancing logging and Internal TCP/UDP Load Balancing logging are now available in General availability.
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.
Internal TCP/UDP load balancers can now be configured to handle private IPv6 traffic within your VPC. To enable this, you must configure your dual-stack subnet, backend VMs, health checks, and the forwarding rules to handle IPv6 traffic.
For details, see:
This feature is available in Preview.
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.
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 Preview.
We're introducing a change in behavior for custom headers used with Global external HTTP(S) load balancers.
This change doesn't affect projects that have any traffic using custom headers before November 14, 2022. Only projects that aren't currently using any custom headers (with either backend services or URL maps) are affected. If you are using custom headers as of November 14, 2022, you'll still see the behavior in the Before column.
The following tables describe changes in behavior applicable only to the global external HTTP(S) load balancers with advanced traffic management. The classic external HTTP(S) load balancers already behave this way when you configure custom headers on backend services. Configuring custom headers on URL maps isn't supported by the classic external HTTP(S) load balancers.
Custom headers configured on backend services
| Before | After |
|---|---|
| Custom request header values are appended to headers on incoming requests. | Custom request header values replace headers on incoming requests. |
| If a custom request header value resolves to an empty string, it is ignored. | If a custom request header value resolves to an empty string, it is added to the headers, and replaces the existing header value for this header name. |
For example, if this is your backend service configuration:
customRequestHeaders: 'x-special-custom-header:'
customRequestHeaders: 'x-resolvable-custom-header:{client_city}'
And this is the incoming client request:
curl your-domain.com \
-H "x-special-custom-header:client-value" \
-H "x-resolvable-custom-header: NorthPole"
-H "extra-header: some-content"
Before the change, this would be the request sent to the backend with the custom header appended to the client header:
Host: your-domain.com
x-special-custom-header: client-value
x-resolvable-custom-header: NorthPole,ActualClientCity
extra-header: some-content
After the change, this is the request sent to the backend with the custom header replacing the client header:
Host: your-domain.com
x-special-custom-header:
x-resolvable-custom-header: ActualClientCity
extra-header: some-content
Custom headers configured on URL maps
| Before | After |
|---|---|
If a headerValue in requestHeadersToAdd cannot be resolved or resolves to an empty string, the header is ignored. |
If a headerValue in requestHeadersToAdd cannot be resolved or resolves to an empty string, the header is added, either replacing or appending to existing values based on the replace field. |
When custom header variables are present, requestHeaderToAdd always defaults to replace: false. |
When custom header variables are present, requestHeaderToAdd now defaults to replace: true. |
For example, if this is your URL map configuration:
requestHeadersToAdd:
- headerName: 'x-special-custom-header'
headerValue: ''
And this is the incoming client request:
curl your-domain.com \
-H "x-special-custom-header:client-value"
Before the change, requestHeaderToAdd defaults to replace: false, so the custom header does not override the client value. The following is the request sent to the backend:
Host: your-domain.com
x-special-custom-header: client-value
After the change, requestHeaderToAdd defaults to replace: true, so the custom header value replaces the client value. The following is the request sent to the backend:
Host: your-domain.com
x-special-custom-header:
Regional external and regional internal HTTP(S) load balancers now support regional SSL policies. SSL policies give you the ability to control the features of SSL that your Google Cloud load balancers negotiate with clients.
For details, see:
This feature is in General Availability.
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:
This capability is in General Availability.
Regional internal and 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:
You can use organization policy constraints to limit how Shared VPC is used across a project, folder, or organization. For details, see Organization policy constraints for Cloud Load Balancing.
This feature is available in General Availability.
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.
Network Load Balancing logging and Internal TCP/UDP Load Balancing logging are now available in Preview.
External TCP/UDP network load balancers can now be configured to handle IPv6 traffic from clients. To enable this, you must configure your subnet, backend VMs, and the forwarding rules to handle IPv6 traffic.
This feature is only available for backend service-based network load balancers.
For details, see:
This feature is available in General Availability.
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:
This capability is in Preview.
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.
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 classic external HTTP(S) 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 General Availability.
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.
External TCP/UDP Network Load Balancing now supports load-balancing GRE traffic. To handle GRE protocol traffic, you set the load balancer's forwarding rule protocol to L3_DEFAULT and set the backend service protocol to UNSPECIFIED.
For details, see:
This feature is available in General Availability.
Forwarding rules for external TCP/UDP network load balancers can now be configured to direct traffic coming from a specific range of source IP addresses to a specific backend service (or target instance). This is called traffic steering.
For details, see:
This capability is in Preview.
Regional external and regional internal HTTP(S) load balancers now support regional SSL policies. SSL policies give you the ability to control the features of SSL that your Google Cloud load balancers negotiate with clients.
For details, see:
This feature is in Preview.
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.
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.
Backend subsetting for internal HTTP(S) load balancers improves performance and scalability by assigning a subset of backends to each of the proxy instances.
This feature is in Preview.
TCP Proxy and SSL Proxy load balancers now support Google Cloud Armor. For more information, see the Cloud Armor security policy overview.
This feature is available in Preview.
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.
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.
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.
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.
Internal TCP/UDP Load Balancing now supports source-IP address session affinity (CLIENT_IP_NO_DESTINATION) in Public Preview.
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.
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.
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 Preview.
Internal HTTP(S) Load Balancing now supports Shared VPC configurations where the load balancer's frontend 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 in 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.
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.
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:
To learn about how connection tracking works, see Traffic distribution.
This feature is available in General Availability.
When you make an internal TCP/UDP load balancer the next hop of a static route, the route can have instance tags (also called network tags).
In addition, there are two different ways to specify the next hop:
This feature is now available in General availability.
For more information, see the following pages:
Note that this feature isn't supported in the Console. To configure the route with network tags, use gcloud or the API.
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.
Cloud Load Balancing announces a significant increase in the URL map limits for External and Internal HTTP(S) Load Balancing. The new limits let you scale to a much higher number of services behind a single load balancer.
For example, URL maps for external HTTP(S) load balancers can now support up to 1000 host rules. The total size of the URL map is constrained to 64KB for External HTTP(S) Load Balancing and 128KB for Internal HTTP(S) Load Balancing
For the updated list of limits see, URL map limits
Cloud Load Balancing now supports load-balancing traffic to endpoints that extend beyond Google Cloud, such as on-premises data centers and other public clouds that you can reach using hybrid connectivity.
Hybrid load balancing is supported by the following load balancers:
For details, see Hybrid load balancing overview.
This feature is available in General Availability.
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.
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:
To learn about how connection tracking works, see Traffic distribution.
This feature is available in Preview.
Cloud Load Balancing now supports load-balancing traffic to endpoints that extend beyond Google Cloud, such as on-premises data centers and other public clouds that you can reach using hybrid connectivity.
Hybrid load balancing is supported by the following load balancers:
For details, see Hybrid load balancing overview.
This feature is available in Preview.
Added Terraform examples to automate load balancer configuration:
Cloud Monitoring now provides a new predefined dashboard called External HTTP(S) Load Balancers. The new dashboard provides powerful visualizations to help you understand and troubleshoot connectivity issues on your external HTTP(S) load balancers.
For details, see HTTP(S) Load Balancing logging and monitoring.
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:
For more information, see the following pages:
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.
External HTTP(S) Load Balancing and Cloud CDN now support HTTP/3. HTTP/3 is based on the IETF QUIC transport protocol. Compared to HTTP/2, it reduces request latency, improves throughput, and mitigates head-of-line blocking. HTTP/3 is already supported on most major web browsers.
To learn how to enable HTTP/3 on your external HTTP(S) load balancer, visit the documentation.
Symmetric hashing for internal TCP/UDP load balancers as next hops—When load balancing to multiple NICs on the backends, you no longer need to use source network address translation (SNAT). SNAT isn't required because Google Cloud uses symmetric hashing. This means that when packets belong to the same flow, Google Cloud calculates the same hash. In other words, the hash doesn't change when the source IP address:port is swapped with the destination IP address:port.
This feature is in General Availability.
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.
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.
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.
Internal TCP/UDP Load Balancing now supports session affinity for the UDP protocol. This feature is available in General Availability.
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.
Cloud CDN, external HTTP(S) Load Balancing and Cloud Storage customers are not affected by the recent OpenSSL security advisory that relates to CA certificate checks (CVE-2021-3450) and TLS renegotiation (CVE-2021-3449).
These services use BoringSSL and are not affected by these OpenSSL-specific bugs.
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.
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.
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.
Identity-Aware Proxy (IAP) is supported with Internal HTTP(S) Load Balancing. This support is available in General Availability.
For internal TCP/UDP load balancers, you can create multiple forwarding rules with the same IP address. The forwarding rules can have different protocols and ports. This feature is available in General Availability.
Health check logging is now available in General Availability.
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.
For HTTP requests, the httpRequest.remoteIp and httpRequest.serverIp fields can include port information. For example 10.0.0.1:80.
External HTTP(S) Load Balancing is now supported for App Engine, Cloud Functions, and Cloud Run services. To configure this, you will need to use a new type of network endpoint group (NEG) called a Serverless NEG.
This feature is now available in General Availability.
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.
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.
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.
Added a new tutorial: Faster web performance and improved web protection for load balancing.
Google Cloud internal HTTP(S) load balancers have native support for the WebSocket protocol when you use HTTP or HTTPS as the protocol to the backend. The load balancer does not need any configuration to proxy WebSocket connections.
The Organization policy constraint for restricting Cloud Load Balancing creation is now available in General Availability.
Setting up Internal HTTP(S) Load Balancing in a Shared VPC service project is now available in General Availability.
The introductory period during which you could use Internal HTTP(S) Load Balancing without charge has ended. Starting July 25, 2020, your usage of Internal HTTP(S) Load Balancing will be billed to your project.
The Organization Policy for restricting load balancer creation has launched into Beta.
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.
External HTTP(S) Load Balancing is now supported for App Engine, Cloud Functions, and Cloud Run services. To configure this, you will need to use a new type of network endpoint group (NEG) called a Serverless NEG.
This feature is available in Beta.
You can now create an internal HTTP(S) load balancer in a Shared VPC service project.
This feature is available in Alpha. Please contact your Google account team to get access to this feature.
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.
HTTP(S) Load Balancing logging is now available in General Availability.
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.
For internal TCP/UDP load balancers, you can create multiple forwarding rules with the same IP address. The forwarding rules can have different protocols and ports. This feature is available in Beta.
Google-managed SSL certificates are available in General Availability.
External HTTP(S) load balancers now support header-based routing and query parameter-based routing.
These features are available in General Availability.
Internal TCP/UDP Load Balancing with failover groups is available in General Availability.
External HTTP(S) load balancers now support URL rewrites and redirects.
URL rewrites allow you to decouple the URLs that your external users use from those that your services use.
With URL redirects, you can redirect client requests from one URL to another URL.
These features are available in General Availability.
Backend services documentation is updated through the Cloud Load Balancing doc set.
TLS v1.3 is now enabled by default for all external HTTPS load balancers, SSL proxy load balancers, and Cloud CDN. Note that this change doesn't apply to internal HTTPS load balancers or Traffic Director.
TLS v1.3 supports modern ciphers with forward-secrecy as a baseline and, critically, reduces the number of round trips required to establish a TLS session, which directly improves performance seen by your end-users.
Clients that support TLS v1.3 include Chrome, Chromium-based browsers, and Android. These clients automatically negotiate TLS v1.3 without requiring any changes. Clients that do not support TLS v1.3 are unaffected.
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.
To help you get started quickly, added two new examples for external HTTP(S) Load Balancing:
Health check logging is now available in Beta.
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.
Internal HTTP(S) Load Balancing now supports configurable idle timeouts.
Internal HTTP(S) Load Balancing now supports accessing your load balancer from a connected network through VPC Peering, Cloud VPN, and Cloud Interconnect.
Updated and reorganized documentation for SSL certificates.
For Internal TCP/UDP Load Balancing, load balancing to multiple NICs on a single backend VM instance is now available in General Availability.
Global access for Internal TCP/UDP Load Balancing is now available in General Availability.
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 Beta.
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.
Network Load Balancing monitoring is now available in General Availability.
Improved documentation for Adding backend buckets to load balancers.
Added load balancer feature tables.
Internal TCP/UDP Load Balancing with global access is available in Beta.
Internal TCP/UDP Load Balancing as next hop is available in General Availability..
Internal HTTP(S) Load Balancing is available in General Availability.
Multiple domains for Google-managed SSL certificates is now available in Beta.
For Internal TCP/UDP Load Balancing, load balancing to multiple NICs on a single backend VM instance is now available in Beta.
Added information about TCP and UDP request and return packets for Internal TCP/UDP Load Balancing.
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.
Expanded information about the probe IP ranges for backend health checks.
HTTP(S) Load Balancing logging is now available in Beta.
Documentation update: Creation of new load balancing tutorial that is both content-based and cross-regional.
Internal TCP/UDP Load Balancing as next hop is available in Beta.
External HTTP(S) load balancers validate protocol selection during ALPN negotiation. For more information, see RFC 7301.
Creating user-defined request headers is published. The information is removed from the backend services documentation
Internal HTTP(S) Load Balancing is available in Beta.
HTTP/2 between the load balancer and backends is available in General Availability.
HTTP/2 health checking is available in General Availability.
The user-defined request header feature is available in General Availability.
Network endpoint groups in load balancing is available in General Availability.
Documentation update: The quotas and limits for load balancing resources are now documented. See Load Balancing Resource Quotas.
Documentation update: The global forwarding rules page (previously at /load-balancing/docs/https/global-forwarding-rules) is combined with Forwarding rule concepts.
Traffic Director is available in Beta.
Internal TCP/UDP Load Balancing with failover groups is available in Beta.
Internal TCP/UDP Load Balancing support for all ports is in General Availability.
Documentation updates for Internal TCP/UDP Load Balancing – The following documents have been updated or added:
DNS-based service discovery for your internally load-balanced services is available in General Availability.
The HTTP(S) load balancer now supports sending an HTTP DELETE with a body to the load balancer.
Content-based HTTP(S) health checking is now available in General Availability.
HTTP/2 and gRPC to backend VMs is now available in Beta.
Content-based HTTP(S) health checking is now available in Beta.
QUIC support for HTTPS Load Balancing is now available in General Availability.
SSL Policies configuration for HTTPS and SSL Proxy Load Balancing is now available in General Availability.
QUIC support for HTTPS Load Balancing is now available in Beta.
User-defined request headers for HTTP(S) Load Balancing is now available in Beta.
SSL Policies for HTTPS and SSL Proxy Load Balancing is now available in Beta.
Internal Load Balancing access across VPN or Interconnect is now available in General Availability.
Internal Load Balancing access across VPN or Interconnect is now available in Beta.
IPv6 Termination for HTTP(S), SSL Proxy, and TCP Proxy Load Balancing is now available in General Availability.
Multiple SSL certificate support is now available in General Availability.
Regional instance groups for Internal Load Balancing is now available in General Availability.
TCP Proxy Load Balancing is now available in General Availability.
IPv6 Termination for HTTP(S), SSL Proxy, and TCP Proxy Load Balancing is now available in Beta.
Websocket support for HTTP(S) Load Balancing is now available in General Availability.
TCP Proxy Load Balancing is now available in Beta.
Google Cloud Storage support for HTTP(S) Load Balancing is now available in General Availability.
IPv6 Termination for HTTP(S), SSL Proxy, and TCP Proxy Load Balancing is now available in Alpha.
Internal Load Balancing is now available in General Availability.
Internal Load Balancing is now available in Beta.
Session Affinity for HTTP(S) Load Balancing is now available in General Availability.
SSL Proxy Load Balancing is now available in General Availability.
SSL Proxy Load Balancing is now available in Beta.
HTTP(S) Load Balancing is now available in General Availability.
HTTPS Load Balancing is now available in Beta.
HTTP Load Balancing is now available in Beta.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2026-07-27 UTC.