SSL Proxy Load Balancing supports both IPv4 and
IPv6 addresses for client traffic. Client
IPv6 requests are terminated at the load balancing layer, then proxied
over IPv4 to your backends.

Overview

With SSL (TLS) proxying for your SSL traffic, you can terminate
SSL sessions at the load balancing layer, then forward the
traffic to your virtual machine instances using SSL (recommended) or TCP.

SSL proxy is a load balancing service that can be deployed globally. You can
deploy your instances in multiple regions, and the load balancer automatically
directs traffic to the closest region that has capacity. If the closest region
is at capacity, the load balancer automatically directs new connections to
another region with available capacity. Existing user connections remain
in the current region.

Note that global load balancing requires that you use the Premium Tier of
Network Service Tiers, which is the default tier.
Otherwise, load balancing is handled regionally.

For the best security, use end-to-end encryption for your SSL proxy deployment.
To do this, configure your backend service to accept traffic over SSL.
This ensures that the client traffic decrypted at the SSL proxy layer is
encrypted again before being sent to the backend instances. This end-to-end
encryption requires you to provision certificates and keys on your instances
so they can perform SSL processing.

SSL proxy benefits:

Intelligent routing — the load balancer can route requests to backend
locations where there is capacity. In contrast, an L3/L4 load
balancer must route to regional backends without paying attention to
capacity. The use of smarter routing allows provisioning at N+1 or N+2
instead of x*N.

Better utilization of the virtual machine instances —
SSL processing can be very
CPU intensive if the ciphers used are not CPU efficient. To
maximize CPU performance, use ECDSA SSL certs, TLS 1.2 and prefer the
ECDHE-ECDSA-AES128-GCM-SHA256 cipher suite for SSL between the load
balancer and your instances.

Certificate management — Your customer-facing SSL certificates can be
either certificates that you obtain and manage yourself
(self-managed certificates), or certificates that
Google obtains and manages for you (Google-managed certificates).
You only need to provision certificates on the load balancer itself. On your
virtual machine instances, you can simplify management by using self-signed
certificates.

Security patching — If vulnerabilities arise in the SSL or TCP stack, we
will apply patches at the load balancer automatically in order to keep
your instances safe.

While choosing to send the traffic over unencrypted TCP
between the load balancing layer and instances enables you to offload
SSL processing from your instances, it also comes with
reduced security between the load balancing layer and instances
and is therefore not recommended.

SSL proxy can handle HTTPS, but this is not recommended. You should instead
use HTTPS load balancing for
HTTPS traffic. See the FAQ for details.

Spreads the request load more evenly among instances, providing better
instance utilization. HTTPS load-balances each request separately, whereas
SSL proxy sends all bytes from the same SSL or TCP connection to the
same instance

SSL Proxy Load Balancing for Google Cloud can be used for other protocols that
use SSL, such as Websockets and IMAP over SSL.

Can I view the original IP address of the connection to the load balancing layer?