Google Cloud networking in depth: Cloud Load Balancing deconstructed

With global load balancing, you get cross-region failover and overflow. Global LB’s traffic distribution algorithm automatically directs traffic to the next closest instance with available capacity in the event of failure of or lack of capacity for instances in the region closest to end user.

Global LB delivers first class support for both VMs and containers. For containers, we built an abstraction called Network Endpoint Groups (NEG), which is essentially a group of IP address and port pairs. NEGs enable you to directly specify a container endpoint as opposed to first directing traffic to the node on which it resides and then redirecting to the container using kube-proxy. As a result, you can deliver lower latency, greater throughput and higher fidelity health checks for your services using NEGs.

Secure the edge
To secure your service, we recommend taking a defense-in-depth approach. We also recommend that you deploy TLS for data privacy and integrity purposes. We do not charge extra for encrypted vs. unencrypted traffic. We offer HTTPS and SSL proxy in our global load-balancing family. We also offer Managed Certificates to reduce the work of procuring certs and managing their lifecycle. With SSL policies you can specify the minimum TLS version and SSL features that you wish to enable on your HTTP(S) and SSL proxy load balancers. We also offer multiple pre-configured profiles, including a custom one that lets you allows specify the ciphers and SSL features you want to use.

With Google’s global network and global load-balancing, Google is able to mitigate and dissipate layer-3 and layer-4 volumetric attacks. To protect against application layer attacks, we recommend using Cloud Armor attached to your Global HTTP(S) load balancer. Use this in concert with Identity Aware Proxy to authenticate users and authorize access to your backend services.

Optimize for latency and cost

Make the web faster
We spend a lot of time at Google working to make the web faster. QUIC is a UDP-based encrypted transport optimized for HTTPS and HTTP/2 is foundational for gRPC support. Google cloud load balancing supports QUIC traffic to the load balancer and supports multiplexed streams of HTTP/2 to the load balancer, followed by load balancing these multiple HTTP/2 streams to the backend.

Google Cloud CDN runs on our globally distributed edge points, so you can reduce network latency when serving website content, offload content origins and reduce serving costs. Just set up HTTP(S) Load Balancing and then enable CDN by clicking a single checkbox.

Optimize for performance or cost with Network Tiers
With Network Tiers, you can optimize your workload for performance with Premium Tier, which takes advantage of Google’s performant network, or optimize for cost with Standard Tier, where your return traffic travels over regular ISP networks like other public clouds but incurs lower egress costs.

Internal Load Balancing for private services
Many Google Cloud customers have private workloads that need to be protected from the public internet. Those services need to scale and grow behind a private VIP that is accessible only by internal instances. For such users we offer regional layer-4 Internal Load Balancing based on our Andromeda network virtualization stack. Similar to our HTTP(S) Load Balancer and Network Load Balancer, Internal L4 Load Balancing is neither a hardware appliance nor an instance-based solution, and can support as many connections per second as you need since there’s no load balancer in the path between your client and backend instances.