StartingDecember 17, 2025, requests with request methods that aren'tcompliant withRFC 9110, Section5.6.2 will berejected by a first-layer Google Front End (GFE) before reaching your loadbalancer or its backends. Previously, such non-compliant requests would havebeen rejected by the load balancer or its backends with a variety of errorcodes. With the GFE now handling such requests, you might observe a smalldecrease 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 precisetraffic routing rules within URL maps for Application Load Balancer. This featurelets you leverage the power of RE2 syntax for matching on:

• Route rules: WithinpathMatchers, thematchRules array now supports aregexMatch field to validate the URL path against a specified regex pattern.
• Header matches: WithinmatchRules, theheaderMatches array nowsupports aregexMatch field for pattern matching against HTTP header values.
• Query parameter matches: WithinmatchRules, thequeryParameterMatchesarray now supports aregexMatch field for pattern matching against HTTPquery parameters values.

This feature is available for the following load balancers:

• Regional internal Application Load Balancer
• Cross-region internal Application Load Balancer
• Regional external Application Load Balancer

For more details on usage and syntax, seeURL map concepts: Regular expressionsmatchers in host and routerules.

This feature is inPreview.

Backend mutual TLS (mTLS) and backend authenticated TLS are nowGenerally available for the following regional Application Load Balancers:

• Regional external Application Load Balancers
• Regional internal Application Load Balancers

This update complements existing support for global external Application Load Balancers,allowing you to enforce bidirectional identity verificationacross your regional deployments.

For details, see the following:

• Backend mTLS overview
• Set up backend authenticated TLS
• Set up backend mTLS

GRPC_WITH_TLS health checks are used for health checking gRPC backendswith TLS enabled. For more information, see the following:

• Success criteria for gRPC
• Create health checks

This feature is inGeneral availability.

The global and classic external Application Load Balancers implemented onGoogle Front-Ends (GFEs) now reject TLS connections when the client and the loadbalancer support ALPN (Application-Layer Protocol Negotiation), but don't sharecommon ALPN protocols.

Previously, if a client proposed a list of application protocols during the TLShandshake 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 asthe default application protocol. After this update, the GFE instead returnsanSSL_TLSEXT_ERR_ALERT_FATAL response which causes the load balancer toterminate the TLS handshake, and the connection to close. This change ensuresthat an application-layer protocol is always explicitly negotiated between theclients and the load balancers that support ALPN.

You can specify a custom ephemeral/96 IPv6 address range when creating aregional IPv6 forwarding rule. For more information, see the following:

• Internal passthrough Network Load Balancer overview
• Backend service-based external passthrough Network Load Balancer overview
• Protocol forwarding overview

This feature is inGeneral availability.

Application Load Balancers support authorization policies that let youestablish access control checks for incoming traffic.

For details, seeAuthorization policy overview.

This feature is inGeneral availability.

Both internal passthrough Network Load Balancers and external passthrough Network Load Balancers support load balancing to managedinstance groups (MIGs) comprised of IPv6-only VM instances.

For more details, see the following pages:

• Set up an external passthrough Network Load Balancer with a backend service
• Set up an internal passthrough Network Load Balancer with VM instance group backends

This feature is inGeneral 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. Youcan now configure the mirrored backend service to receive only a percentage of therequests by using themirrorPercent flag to specify the percentage ofrequests to be mirrored, expressed as a value between 0 and 100.0.

For an example, seeSet up traffic management for regional external Application Load Balancers.

This feature is available inGeneral availability.

A security fix was made which changes the behavior of requests and responses sent with theTransfer-Encoding: Chunked header to be more RFC 9112 compliant. TheRFC states that both thechunked_body and thelast-chunk fields must end inCRLF. 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 anSSL_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 returnHTTP/1.0, which provides clients with positive confirmation that their advertisedHTTP/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 contactsupport.

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:

• Protocol forwarding overview
• Backend service-based external passthrough Network Load Balancer overview
• Internal passthrough Network Load Balancer overview
• Set up an internal passthrough Network Load Balancer with IPv6-only subnets and backends

This feature is available inGeneral Availability.

Cross-region internal Application Load Balancers can now route requests for static content to Cloud Storage buckets.

For more information, seeSet up a cross-region internal Application Load Balancer with Cloud Storage buckets.

This capability is now inGeneral 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 theRFC 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, reviewRFC 9112, Section 5.2: Obsolete Line Folding.

Global external Application Load Balancers now support theJA4 fingerprint. The JA4 fingerprint can be added to acustom request header using thetls_ja4_fingerprint variable.

This capability is now inGeneral 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 forSupported key types.

This capability is now inGeneral 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, seeZonal affinity for internal passthrough Network Load Balancers.

This feature is inPreview.

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.

Withbackend authenticated TLS, the load balancer verifies the backend server's certificate by checking its chain of trust, thereby confirming the backend's identity. Conversely, withbackend 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:

• Backend mTLS overview
• Set up backend authenticated TLS
• Set up backend mTLS

This capability is inGeneral Availability for global external Application Load Balancers.

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

This capability is inPreview.

Application Load Balancers now support the use ofcustom 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, seeCustom metrics for Application Load Balancers.

This capability is inGeneral availability.

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 inGeneral Availability.

• Connections between the load balancer and its backends. Support for this capability is now inGeneral Availability.

  To configure H2C for connections between the load balancer and its backends, you set the backend service protocol toH2C.

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—fromEXTERNAL toEXTERNAL_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:

• Migration overview
• Migrate resources from classic to global external Application Load Balancer
• Roll back migrated resources to classic Application Load Balancer

This capability is available inGeneral 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 theGCP-2025-027 security bulletin.

Global and cross-region load balancers now support enablingtraffic isolation on the service load balancing policy. By default, these load balancers use theWATERFALL_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 inSTRICT mode.

For details, seeTraffic isolation.

This feature is inPreview.

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, seeTLS support.

This capability is available inGeneral 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 aShared 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:

• External Application Load Balancer overview
• Internal Application Load Balancer overview
• External Proxy Network Load Balancer overview
• Internal Proxy Network Load Balancer overview

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 withRFC 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, andUpgrade.

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:

1. 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.

2. Review your backend service and URL mapheaderAction 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 ofload 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 calledMulti-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, seeMulti-perspective domain validation.

Cross-region internal Application Load Balancers can now route requests for static content to Cloud Storage buckets.

For more information, seeSet up a cross-region internal Application Load Balancer with Cloud Storage buckets.

This capability is inPreview.

Application Load Balancers now support the use ofcustom 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, seeCustom metrics for Application Load Balancers.

This capability is inPreview.

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.

Withbackend authenticated TLS, the load balancer verifies the backend server's certificate by checking its chain of trust, thereby confirming the backend's identity. Conversely, withbackend 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:

• Backend mTLS overview
• Set up backend authenticated TLS
• Set up backend mTLS

This capability is inPreview 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 inGeneral Availability.

• Connections between the load balancer and its backends. Support for this capability is inPreview.

  To configure H2C for connections between the load balancer and its backends, you set the backend service protocol toH2C.

Internal and external passthrough Network Load Balancers now support connection draining for UDP and other non-TCP protocol traffic. For details, seeEnable connection draining.

This feature is nowgenerally 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 aszero-round-trip time (0-RTT) data, can improve application performance for resumed connections by 30 to 50%.

For details, seeTLS 1.3 early data support.

This feature is available inGeneral 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:

1. 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 outputrsaEncryption. If it is a non-RSA certificate (for example, EC), you don't need to take any more action at this time.

2. 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 isDigital 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, seeRFC 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, seeFailover for external Application Load Balancers.

This feature is available inGeneral 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:

• VM instance groups
• Zonal NEGs (GCE_VM_IP_PORT endpoints)

You can also convert your existing single-stack load balancers from IPv4-only to dual stack (IPv4 and IPv6) deployments.

For details, see the following pages:

• IPv6 overview
• Convert your existing Application Load Balancer to IPv6
• Convert your existing proxy Network Load Balancer to IPv6

This feature is available inGeneral 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 theoriginal traffic is being split between multiple weighted backend services. Youcan now configure the mirrored backend service to receive only a percentage of therequests by using themirrorPercent flag to specify the percentage ofrequests to be mirrored expressed as a value between 0 and 100.0.

For an example, seeSet up traffic management for regional internal Application Load Balancers.

This capability is available inPreview.

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, seeManage Cloud Load Balancing resources using custom constraints.

For more information about custom constraints, see the following:

• Custom organization policies
• Custom constraint supported services

This feature is available inGeneral 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 theoriginal traffic is being split between multiple weighted backend services. Youcan now configure the mirrored backend service to receive only a percentage of therequests by using themirrorPercent flag to specify the percentage ofrequests to be mirrored expressed as a value between 0 and 100.0.

For an example, seeSet up traffic management for regional external Application Load Balancers.

This capability is available inPreview.

Support forIPv6 static routes with a next hop internal passthrough Network Load Balancer (next-hop-ilb) is available inPreview.

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

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, seePlugins 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 theSet-Cookie header in response to the initial HTTP request. With stateful session affinity, customers can preserve stickiness to the selected backend.

For details, seeStateful cookie-based session affinity.

This capability is inGeneral 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—fromEXTERNAL toEXTERNAL_MANAGED. You can also rollback resources to the classic Application Load Balancer infrastructure, as long as you do so within 90 days of changing the load balancing scheme.

For more details on the migration process, see the following pages:

• Migration overview
• Migrate resources from classic to global external Application Load Balancer
• Roll back migrated resources to classic Application Load Balancer

This capability is available inPreview.

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

• VM instance groups
• Zonal NEGs (GCE_VM_IP_PORT endpoints)

You can also convert your existing single-stack load balancers from IPv4-only to dual stack (IPv4 and IPv6) deployments.

For details, see the following pages:

• IPv6 overview
• Convert your existing Application Load Balancer to IPv6
• Convert your existing proxy Network Load Balancer to IPv6

This feature is available inGeneral Availability.

Internal and external passthrough Network Load Balancers now support connection draining for UDP and other non-TCP protocol traffic.

For details, seeEnable connection draining.

This feature is available inPreview.

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

• Regional external Application Load Balancer
• Regional external proxy Network Load Balancer

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

Previously, the classic external Application Load Balancer had lenient HTTP/2 request parsing that did not reject requests containing certain invalid characters in the request path. The same requests would have been rejected if they had arrived over HTTP/1 or HTTP/3.

Now, all HTTP requests, including HTTP/2 requests, are rejected if the path contains a character that isn't one of the following:

• An allowed ASCII character specified inRFC 3986, sections 3.3 and 3.4.

• One of the following special allowed characters:[ ] { } | ^

All other characters must be properlyURL encoded.

You can identify rejected requests in the proxy logs by looking for the following:

• responseCode: 400
• response_code_details:invalid_http2_client_request_path

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

For details, see

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

This capability is available inGeneral Availability.

Envoy-based Application Load Balancers now support authorization policies that let you establish access control checks for incoming traffic. For details, seeAuthorization policy.

This feature is available inPreview.

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 cheaperabbreviated handshake. This optimization is available in several modes, which include the modernPSK andticket mechanisms, as well as the long-obsoletesessionID 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:

• Mutual TLS authentication
• Set up mutual TLS with user-provided certificates
• Set up mutual TLS with a private CA

This capability is inGeneral 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, seeFailover for external Application Load Balancers.

This feature is available inPreview.

All the Application Load Balancers, except the classic Application Load Balancer, now supportstateful cookie-based session affinity. When you use stateful cookie-based affinity, the load balancer includes an HTTP cookie in theSet-Cookie response header of the initial HTTP request.

For details, seeStateful cookie-based session affinity.

This capability is inPreview.

Regional external Application Load Balancers, cross-region internal Application Load Balancers, regional internal Application Load Balancers, regional internal proxy Network Load Balancers, cross-region internal proxy Network Load Balancers, and regional external proxy Network Load Balancers support IPv4 and IPv6 (dual-stack) backends.

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

The following backends support dual stack:

• VM instance group
• Zonal NEGs (GCE_VM_IP_PORT)

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

For details, see:

• IPv6 overview

• Convert Application Load Balancer to IPv6

• Convert proxy Network Load Balancer to IPv6

This feature is available inPreview.

Cloud Load Balancing introduces advanced cost, latency, and resiliency optimizations for your global external Application Load Balancers. These include the following capabilities:

• You can use aservice load balancing policy to customize the parameters that influence how traffic is distributed within the backends associated with a backend service (for example, load balancing algorithm and auto-capacity draining).
• You can designate specific backends aspreferred backends.

For details, seeAdvanced load balancing optimizations.

This feature is inGeneral 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 inGeneral Availability.

Bring your own IP lets youbring your own public IPv6 addresses to Google Cloud. IPv6 BYOIP addresses can be used withexternal passthrough Network Load Balancers. Bring your own IP for IPv6 addresses is available inGeneral 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:

• VM instance group
• Zonal NEGs (GCE_VM_IP_PORT)

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

For details, see:

• IPv6

• Convert Application Load Balancer to IPv6

• Convert proxy Network Load Balancer to IPv6

This feature is available inPreview.

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 toL3_DEFAULT and set the backend service protocol toUNSPECIFIED.

For details, see:

Set up an internal passthrough Network Load Balancer with VM instance group backends for multiple protocols

This feature is available inGeneral Availability.

Application Load Balancers now support Certificate Managerallowlisted certificates. For more information, seeMutual TLS authentication.

This capability is inGeneral 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 theInternal proxy Network Load Balancer overview.

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

• Instance group backends

• Mixed zonal and hybrid connectivity NEG backends

This capability is inGeneral 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 theInternal Application Load Balancer overview.

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

• Instance group backends

• Mixed zonal and hybrid connectivity NEG backends

• Cloud Run backends

This capability is inGeneral Availability.

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

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

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

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

This capability is available inGeneral 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:

• Mutual TLS authentication
• Set up mutual TLS with user-provided certificates
• Set up mutual TLS with a private CA

This capability is inPreview.

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 atCreate a load balancer.

Regional external Application Load Balancers and regional internal Application Load Balancers now support Certificate Manager certificates. For more information, seeCertificates and Google Cloud load balancers.

This capability is inGeneral Availability.

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 theExternal proxy Network Load Balancer overview.

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

• Instance group backends with SSL
• Instance group backends with TCP

This capability is inGeneral Availability.

Global external Application Load Balancers now let you customize your own error responses when an HTTP error status code (4xx and5xx) is generated. You can customize error responses for errors generated byboth the load balancer and the backend instances. You can also customize errorresponses for error response codes that are generated when traffic is denied byCloud Armor.

For more information, see the following pages:

• Custom error responses overview
• Configure custom error responses

This feature is available inPreview.

External passthrough Network Load balancers now support zonal NEGs withGCE_VM_IP endpoints. This also lets you addany 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 thenic0 of a VM to an instance group backend.

For more details, see the following pages:

• External passthrough Network Load Balancer overview: Backends
• Zonal NEGs overview
• Set up an external passthrough Network Load Balancer with a GCE_VM_IP zonal NEG

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

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

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

This feature is available inGeneral Availability.

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

For more information, see the following:

• Summary of load balancer types
• External Application Load Balancer overview
• Internal Application Load Balancer overview

This feature is available inGeneral 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 aregional internet network endpoint group (NEG).

For details, see the following:

• Internet NEG concepts
• Set up a regional external Application Load Balancer with an external backend
• Set up a regional internal Application Load Balancer with an external backend
• Set up a regional internal proxy Network Load Balancer with an external backend
• Set up a regional external proxy Network Load Balancer with an external backend

This capability is inGeneral 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:

• Cloud Load Balancing extensions overview
• Configure a callout extension

Service Extensions is inPreview.

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 theExternal proxy Network Load Balancer overview.

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

• Instance group backends with SSL
• Instance group backends with TCP

This capability is inPreview.

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 theExternal 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:

• Mutual TLS authentication
• Set up mutual TLS with signed certificates
• Set up mutual TLS with a private CA
• Set up mutual TLS for a global external Application Load Balancer (classic)
• Set up mutual TLS for a global external Application Load Balancer

This capability is inGeneral Availability.

Regional external HTTP(S), internal HTTP(S), and the regional internal TCP proxy load balancers now usedistributed 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 inGeneral 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:

• You can use aservice load balancing policy to customize the parameters that influence how traffic is distributed within the backends associated with a backend service (for example, load balancing algorithm and auto-capacity draining).
• You can designate specific backends aspreferred backends.

For details, seeAdvanced load balancing optimizations.

This feature is inPreview.

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:

• Internal passthrough Network Load Balancer overview

• Set up load balancer with dual-stack subnets

This feature is available inGeneral Availability.

The following changes have been made to theGoogle Cloud console:

• Firewall rules has moved toNetwork security >Firewall policies.
• SSL policies has moved toNetwork services >SSL policies.

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 aregional internet network endpoint group (NEG).

For details, see the following:

• Internet NEG concepts
• Set up a regional internal Application Load Balancer with an external backend
• Set up a regional internal proxy Network Load Balancer with an external backend

This capability is inPreview.

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 theInternal Application Load Balancer overview.

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

• Instance group backends

• Mixed zonal and hybrid connectivity NEG backends

This capability is inPreview.

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 asregional internal Application Load Balancer in the console. No changes have been made to the API.

For details, see theInternal 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

• Client HTTP keepalive timeout
• Update client HTTP keepalive timeout

This capability is available inGeneral 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 toL3_DEFAULT and set the backend service protocol toUNSPECIFIED.

For details, see:

Set up an internal passthrough Network Load Balancer with VM instance group backends for multiple protocols

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 clickCreate orUpdate, you can clickEquivalent Code to view the load balancer API resources that will be created, updated, or deleted.

This capability is inGeneral 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:

• Weighted load balancing
• Configure weighted load balancing

This feature is inGeneral 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 clickCreate orUpdate, you can clickEquivalent Code to view the load balancer API resources that will be created, updated, or deleted.

This capability is inPreview.

Network Load Balancing logging andInternal TCP/UDP Load Balancing logging are now available inGeneral availability.

The global external HTTP(S) load balancer now supportsadvanced 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, seeURL maps overview: Wildcards and pattern matching operators in path templates for route rules.

This capability is available inPreview.

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:

• Internal TCP/UDP Load Balancing overview

• Set up load balancer with dual-stack subnets

This feature is available inPreview.

Cloud Load Balancing introduces a new version of the external HTTP(S) load balancer. The newglobal external HTTP(S) load balancer with advanced traffic management capabilities contains many of the features of our existingclassic 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:

• External HTTPS(S) Load Balancing overview
• Load balancer features (External HTTP(S) > Global)
• Setting up a global external HTTP(S) load balancer
• Traffic management for global external HTTP(S) load balancers

This load balancer is available inGeneral 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 toL3_DEFAULT and set the backend service protocol toUNSPECIFIED.

For details, see:

• Backend service-based external TCP/UDP Network Load Balancing overview

This feature is available inGeneral 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 calledtraffic steering.

For details, see:

• Network load balancer overview: Traffic steering
• Configure traffic steering

This capability is inPreview.

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:

• SSL policies overview
• Using SSL policies

This feature is inPreview.

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:

• Serverless NEG concepts
• Setting up a regional external HTTP(S) load balancer with a Cloud Run backend
• Setting up an internal HTTP(S) load balancer with a Cloud Run backend

This feature is available inPreview.

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 ascross-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:

• Shared VPC architectures
• Setting up a regional external HTTP(S) load balancer with Shared VPC

This feature is available inPreview.

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 inPreview.

TCP Proxy and SSL Proxy load balancers now support Google Cloud Armor. For more information, see theCloud Armor security policy overview.

This feature is available inPreview.

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 calledOutbound data processed by load balancer and the price will mirror the existing price for theInbound 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.

Thecurrent 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.

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 inGeneral availability.

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

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

For details, seeMonitoring Network Load Balancing.

This feature is available inGeneral Availability.

Internal TCP/UDP Load Balancing now supportssource-IP address session affinity (CLIENT_IP_NO_DESTINATION) inPublic Preview.

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 newL3_DEFAULT protocol on the load balancer's forwarding rule.

For details, see:

• Forwarding rule protocols for backend service-based network load balancers
• Setting up Network Load Balancing for multiple protocols

This feature is available inGeneral Availability.

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

• Tracking mode
• Connection persistence on unhealthy backends

To learn about how connection tracking works, seeBackend selection and connection tracking.

To learn how to configure a connection tracking policy, seeConfigure a connection tracking policy.

This feature is available inGeneral Availability.

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

For details, seeMonitoring Network Load Balancing.

This feature is available inPreview.

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 ascross-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:

• Shared VPC architectures
• Setting up Internal HTTP(S) Load Balancing with Shared VPC

This feature is available inPreview.

The default behavior for HTTP/3 and Google QUIC is changing for global external HTTP(S) load balancers. The default setting ofquicOverride=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 settingquicOverride toDISABLE. For instructions, seeConfiguring HTTP/3.

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 inGeneral 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 newL3_DEFAULT protocol on the load balancer's forwarding rule.

For details, see:

• Forwarding rule protocols for backend service-based network load balancers
• Setting up Network Load Balancing for multiple protocols

This feature is available inPreview.

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, seeProcessing of TCP, UDP, and other protocol traffic.

Zonal NEGs (withGCE_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, seeZonal NEGs overview. For instructions on how to set up an internal TCP/UDP load balancer with a zonal NEG backend, seeSetting up Internal TCP/UDP Load Balancing with zonal NEGs

This feature is inGeneral Availability.

Internal TCP/UDP Load Balancing now supportssession affinity for the UDP protocol. This feature is available inGeneral Availability.

Health check logging is now available inGeneral 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:

• Network Load Balancing with backend services
• Setting up a network load balancer with a backend service
• Transitioning a network load balancer from a target pool to a backend service

This feature is available inPreview.

ForHTTP requests, thehttpRequest.remoteIp andhttpRequest.serverIp fields can include port information. For example10.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 aServerless NEG.

This feature is now available inGeneral Availability.

Added a newtutorial 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.

Network endpoint groups (NEGs) now supportglobal, internet endpoints that let you createcustom 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 inGeneral Availability.

Health check logging is now available inBeta.

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

• Setting up a simple external HTTP load balancer
• Setting up a simple external HTTPS load balancer

Internal HTTP(S) Load Balancing now supportsconfigurable idle timeouts.

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

Updated and reorganized documentation forSSL certificates.

Internal HTTP(S) Load Balancing now supportsaccessing your load balancer from a connected network through VPC Peering, Cloud VPN, and Cloud Interconnect.

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

Global access for Internal TCP/UDP Load Balancing is now available inGeneral Availability.

Network endpoint groups (NEGs) now supportglobal, internet endpoints that let you createcustom 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 inBeta.

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

Network Load Balancing monitoring is now available inGeneral Availability.

Improved documentation forAdding backend buckets to load balancers.

Addedload balancer feature tables.

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

Internal TCP/UDP Load Balancing with global access is available inBeta.

Internal HTTP(S) Load Balancing is available inGeneral Availability.

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

For Internal TCP/UDP Load Balancing,load balancing to multiple NICson a single backend VM instance is now available inBeta.

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

For the HTTP(S), TCP proxy, and SSL proxy load balancers, the Stackdriver logging timestamp field in theLogEntry 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.

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

HTTP(S) Load Balancing logging is now available inBeta.

Documentation update: Creation ofnew load balancing tutorial that is both content-based and cross-regional.

• The Content-based load balancing tutorial has been modified to includecross-region functionality.
• The Cross-region load balancing tutorial has been removed.
• Links to both original tutorials now redirect to the combined tutorial.
• Modified fileAdding a Cloud Storage bucket to content-based load balancingto create two buckets and modify the load balancer accordingly.

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

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

Creating user-defined request headers is published. The information is removed from thebackend services documentation

Internal HTTP(S) Load Balancing is available inBeta.

HTTP/2 health checking is available inGeneral Availability.

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

The user-defined request header feature is available inGeneral Availability.

Network endpoint groups in load balancing is available inGeneral Availability.

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

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

Traffic Director is available inBeta.

Internal TCP/UDP Load Balancing with failover groups is available inBeta.

Content-based HTTP(S) health checking is now available inBeta.

HTTP/2 and gRPC to backend VMs is now available inBeta.

QUIC support for HTTPS Load Balancing is now available inGeneral Availability.

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

QUIC support for HTTPS Load Balancing is now available inBeta.

User-defined request headers for HTTP(S) Load Balancing is now available inBeta.

SSL Policies for HTTPS and SSL Proxy Load Balancing is now available inBeta.

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

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

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

Multiple SSL certificate support is now available inGeneral Availability.

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

TCP Proxy Load Balancing is now available inGeneral Availability.

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

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

TCP Proxy Load Balancing is now available inBeta.

Google Cloud Storage support for HTTP(S) Load Balancing is now available inGeneral Availability.

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

HTTP(S) Load Balancing is now available inGeneral Availability.

HTTPS Load Balancing is now available inBeta.