Google Cloud Landing Zone Series – Part 7: Network Design

Table of Contents:

Tags:

In the last blog post, we have shown how to establish connectivity between the on-premises network and the Google Cloud Landing Zone. Now it is time to talk about some network concepts. Networking is at the core of a Landing Zone, hence that’s there is plenty to discuss. We will split that topic into two different blog posts. In this blog post we will first introduce the most important network concepts and in the second blog post we will introduce various architectural designs for different scenarios. We will assume that you have a basic understanding about cloud networking.

In detail, this blog post, will introduce the following networking components:

  • Private Google Access
  • Private Google Access for on-premises hosts
  • Private Service Access
  • Private Service Connect

Private Google Access

Private Google Access (PGA) allows instances in a Virtual Private Cloud (VPC) network to connect to Google APIs and services through internal IP addresses rather than using external IP addresses. This capability ensures secure and private communication between your Google Cloud resources and Google APIs and services without the need for public IP addresses or NAT (Network Address Translation) gateways.

Why should we use it:

1. Security and Privacy: By using internal IP addresses, traffic remains within Google’s network, enhancing security and privacy. For example, applications running on Google Cloud can securely access Google services like Cloud Storage, BigQuery, or Pub/Sub.

2. No Public IP Required: Instances without public IP addresses can still access Google APIs and services.

3. Cost-Effective: Helps in reducing costs associated with managing and securing public IP addresses. This helps allows by reducing reliance on NAT gateways.

The following picture shows an implementation of Private Google Access:

The image shows a network diagram depicting the Google Cloud Platform (GCP) architecture for a "Landing Zone."

At the top, the Internet is connected to Google APIs and Services via public IP addresses. Below that is the main project with a VPC network that includes an Internet Gateway and VPC Routing.

The VPC network consists of two regions: us-west1 and us-east1.

In the us-west1 region, there are two virtual machines (VMs) in subnet-a, where Private Google Access is enabled. VM A1 has the IP address 10.240.0.2, and VM A2 has the IP address 10.240.0.3 with a public IP.
In the us-east1 region, there are two virtual machines (VMs) in subnet-b, where Private Google Access is disabled. VM B1 has the IP address 192.168.1.2, and VM B2 has the IP address 192.168.1.3 with a public IP.
The diagram uses colored lines to indicate traffic paths: green for traffic to Google APIs and Services, and yellow for traffic to the Internet.

Private Google Access for on-premises hosts

Private Google Access for on-premises hosts extends the capability of Private Google Access to on-premises environments. This feature allows on-premises hosts to access Google APIs and services privately, over internal IP addresses, without exposing the traffic to the public internet.

Why should we use it?

1. Secure and Private Access: On-premises hosts can securely access Google Cloud services via internal IP addresses.

2. No Public IPs Required: Similar to PGA for VPC networks, it eliminates the need for public IP addresses for on-premises hosts.

3. Hybrid Cloud Integration: Facilitates seamless integration between on-premises data centers and Google Cloud services.

How does it work?

In order to configure Private Google Access for on-premises hosts, a couple of steps have to be done:

1. Establish a Secure Connection: Use Cloud Interconnect or VPN to connect your on-premises network to your Google Cloud VPC network.

2. Configure DNS: Ensure that DNS queries for Google APIs resolve to private IP addresses.

3. Enable Private Google Access: Make sure Private Google Access is enabled on the relevant VPC subnets in Google Cloud.

4. Update Routing: Configure routing to direct traffic from on-premises hosts to Google Cloud services via the secure connection.

The following picture show the implementation:

The image depicts a network architecture diagram for a Google Cloud Platform (GCP) landing zone with an on-premises network.

At the top, the on-premises network includes subnets and resources connected to an on-premises VPN Gateway with an external IP (BGP IP: 169.254.1.2). A VPN tunnel carries encrypted traffic to the Internet.

Below, within the GCP project "my-project," there is a VPC network with an Internet Gateway connected to VPC Routing and a Routing Table. In the us-east1 region, a Cloud VPN Gateway with a regional external IP is connected to a Cloud Router (169.254.1.1). This setup communicates with the on-premises VPN Gateway via the VPN tunnel.

There is also a restricted range for Google APIs and Services (199.36.153.4/30) connected within the VPC network. The Cloud Router advertises this range, with the next hop being the Cloud Router (169.254.1.1). DNS CNAME maps *.googleapis.com to restricted.googleapis.com for secure access to Google services. The diagram uses colored lines to indicate different traffic paths: green for internal routing, red for encrypted VPN traffic, and connections to the Internet.

Traffic from on-premises hosts to Google APIs travels through the tunnel to the VPC network. After traffic reaches the VPC network, it is sent through a route that uses the default internet gateway as its next hop. This next hop allows traffic to leave the VPC network and be delivered to restricted.googleapis.com (199.36.153.4/30).

Private Service Access

Private Service Access allows you to connect your Virtual Private Cloud (VPC) networks to Google-managed services such as Cloud SQL, AI Platform, and other Google APIs in a secure and private manner. The connection is made over internal IP addresses, hence ensuring that traffic does not traverse the public internet,

Why should we use it?

1. Private Connectivity: Establishes private connectivity between your VPC network and Google-managed services, avoiding public internet.

2. Enhanced Security: Keeps data traffic secure within the Google Cloud network.

3. Simplified Network Management: Reduces the complexity of managing firewall rules and NAT gateways for service access.

How It Works?

Private Service Access involves setting up private connections from your VPC to Google-managed services using VPC peering.

VPC Peering allows networks to communicate internally using private IP addresses without the need for public IPs or additional firewall rules.

The following picture shows the implementation:

The image depicts a network architecture diagram for a Google Cloud Platform (GCP) landing zone with a customer project and a service producer project.

On the left, the customer project includes a Customer VPC network in the us-central1 region with a virtual machine (VM1) having the IP address 10.1.0.2 in subnet 10.1.0.0/24. There is also an allocated range of 10.240.0.0/16 for private connections.

On the right, the service producer project for the customer includes a Service Producer VPC network. In the us-central1 region, it contains a database instance (DB1) with the IP address 10.240.0.2 in a subnet for Cloud SQL (10.240.0.0/24). In the europe-west1 region, there is another resource with the IP address 10.240.10.2 in a subnet for another service (10.240.10.0/24).

The two projects are connected via VPC Network Peering, allowing private services access traffic between the customer project and the service producer project. The green lines indicate the paths for private services access traffic.

In the diagramm, the customer VPC network allocated the 10.240.0.0/16 address range for Google services and established a private connection that uses the allocated range. Each Google service creates a subnet from the allocated block to provision new resources in a given region, such as Cloud SQL instances.

Private Service Connect

Private Service Connect allows you to securely and privately access Google services, third-party services, and your own services through private IP addresses. It ensures that the traffic between your Virtual Private Cloud (VPC) network and these services does not traverse the public internet, thereby enhancing security and performance.

Why should we use it?

1. Private Connectivity: Establishes private connections using internal IP addresses, avoiding public internet exposure.

2. Enhanced Security: Protects data by keeping it within Google’s network, reducing the risk of external threats.

3. Simplified Network Configuration: Streamlines the process of connecting to Google services, third-party services, and your own services.

4. Service Access Control: Allows granular access control and policy management for services.

5. Load Balancing: Supports integration with Google Cloud’s load balancing services to distribute traffic efficiently.

How It Works?

Private Service Connect creates endpoints in your VPC network that serve as entry points to the service you want to access. These endpoints use internal IP addresses, ensuring that the communication remains within the private network.

The following picture shows this in more detail:

The image depicts a network architecture diagram for a Google Cloud Platform (GCP) landing zone utilizing Private Service Connect.

On the left, the Consumer VPC includes various clients accessing different types of Private Service Connect endpoints:

Endpoint
Backend
Interface
These connect through the central Private Service Connect, represented by a secure lock symbol.

On the right, the Producer VPC offers published services, categorized into:

Google services
Third-party services
Intra-org services
Above, managed services like Google APIs are also accessible via Private Service Connect. The diagram illustrates the secure, private connection paths between consumer clients and various managed and published services within GCP.

Autor

Dr. Guido Söldner

Geschäftsführer

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.