Google Cloud Landing Zone Series – Part 8: Network Blueprints

Table of Contents:


In our network posts of this series, we first introduced hybrid connectivity between on-premises and the Google Cloud and then further explained a typical network topology.

In the last blog post, we have discussed aspects of network design within a Google Cloud Landing Zone and introduced concepts like Private Google Access, Private Google Access for on-premises hosts, Private Service Access or Private Service Connect.

Now it’s time to further dive into network designs, however this time with more end-to-end scenarios. The following are examples of typical scenarios.

Calling a private Cloud Function from on-premises

Many customers would like to use Cloud Functions, but also wants to call them from on-premises.

Diagram illustrating a Google Cloud landing zone setup. The diagram shows a "Consumer organization" which contains a "Consumer project" and within it, a "Consumer VPC." Inside the Consumer VPC, "Clients" are connected to an "Endpoint." This endpoint uses "Private Service Connect" to securely connect to "Google APIs." The visual representation highlights the secure and private connection between the consumer's infrastructure and Google Cloud services.

For this scenario, one way to achieve that, would be to create a Private Service Connect endpoint. If you use VPC Service Controls, and are deploying your function allowing internal traffic only, you can secure your HTTP functions by allowing them to be called only by resources in the same Google Cloud project or VPC Service Controls service perimeter. As we are using PSC, the function can also be called from on-prem.

Hybrid connectivity to on-premises services through PSC and Network Endpoint Groups (NEG)

PSC can also be used to call on-premises services. For that use case, NEGs are used. A network endpoint group (NEG) is a configuration object that specifies a group of backend endpoints or services. With NEGs, Google Cloud load balancers can serve virtual machine (VM) instance group-based workloads, serverless workloads, and containerized workloads. A hybrid NEG can be described as one or more endpoints that resolve to on-premises services, server applications in another cloud, and other internet-reachable services outside Google Cloud. Setting up NEGs and hybrid load balancing also enables you to bring the benefits of Cloud Load Balancing’s networking capabilities to services running on your existing infrastructure outside of Google Cloud.

The setup is also suitable, if you run an application in a Kubernetes cluster and wants to access on-premises resources and need a firewall for a dedicated IP instead of  a whole range, which would be needed for GKE nodes (as their IPs are always chaning when nodes are updated or replaced).

The following picture shows such a scenario:

Diagram of a Google Cloud internal application load balancing setup in region us-west1. The diagram shows an "Internal client VM" in us-west1 connected to an "Internal forwarding rule." This leads to an "Internal Application Load Balancer," which includes a "Regional target HTTP(S) proxy" and a "Regional URL map." These connect to either a "Regional backend service (GCP backends)" or a "Regional backend service (Non-GCP backends)." The GCP backend connects to a "Zonal NEG backend" in us-west1-a with multiple GCE_VM_IP_PORT endpoints, while the non-GCP backend connects to a "Hybrid connectivity NEG backend" in us-west1-a with multiple NON_GCP_PRIVATE_IP_PORT endpoints. The setup includes hybrid connectivity options via Cloud VPN or Cloud Interconnect to an on-premise datacenter in California.

Multi-regional high-availability and disaster recovery

As enterprises move workloads on to the public cloud, they need to translate their understanding of building resilient on-premises systems to the hyperscale infrastructure of cloud providers like Google Cloud. Industry standard concepts around disaster recovery such as RTO (Recovery Time Objective) and RPO (Recovery Point Objective) are often mentioned.

Google Cloud is already designed for resilience, however not every service is high-available. While for example, Big Query can store its data in multiple regions and hence support replication, this might not be the case with other services like Compute Engine. For such use cases network design must be implemented properly. In the following, we show a sample architecture for a microservices workload . However, bear in mind, that the architecture is not suitable for all use cases.

Diagram of a multi-region Google Cloud Platform architecture. The diagram shows mobile devices connecting to "Cloud Load Balancing," which distributes traffic between "Region 1" and "Region 2." Each region contains two zones (Zone a and Zone b). Within each region, there are "Regional Clusters" running on "Google Kubernetes Engine" (GKE). Below GKE, "Cloud Spanner" is configured for multi-region replication between the regions. Each region also includes "BigQuery" for data analytics. The architecture highlights redundancy, load balancing, and data replication across multiple regions for high availability and resilience.

Secure Internet-facing applications

For such applications, the objective is to securely expose an application to the internet while protecting it against threats and ensuring controlled access. The following components can be used:

  1. Cloud Armor: A DDoS protection and web application firewall (WAF) service that helps safeguard your applications against distributed denial-of-service (DDoS) attacks and other threats.
  2. Identity-Aware Proxy (IAP): Provides granular access control to your application by verifying user identity and context before allowing access.
  3. Cloud Load Balancing: Distributes incoming traffic across multiple instances or backend services to ensure high availability and reliability.
  4. Firewall Rules: Network-level security controls to define what traffic is allowed or denied to your application.

The following picture shows a sample architecture:

Diagram of a Google Cloud architecture showcasing a global load balancing setup. Users access services protected by "Google Cloud Armor" and then routed through a "Cloud Load Balancer." The traffic is directed to an "Anycast IP," which then applies a "Global Forwarding Rule" to reach a "Target Proxy." The target proxy directs the traffic according to a defined "URL Map" to the appropriate "Backend Service," which performs "Health Checks."

The backend service connects to managed instance groups in two regions: "us-east1" and "europe-west1." Each region's subnet hosts a "Managed Instance Group" running on Google Compute Engine. These instance groups connect to the internet through "Cloud NAT." The network configuration includes "Cloud Firewall Rules" and is part of a "Virtual Private Cloud" (VPC) named "oneclick-vpc." This architecture ensures global load balancing, security, and efficient routing of user traffic across multiple regions.

That’s it for today. In the next blog post, we will talk about DNS.


Dr. Guido Söldner


Guido Söldner ist Geschäftsführer und Principal Consultant bei Söldner Consult. Sein Themenfeld umfasst Cloud Infrastruktur, Automatisierung und DevOps, Kubernetes, Machine Learning und Enterprise Programmierung mit Spring.