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:
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:
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:
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:
> Click here for Part 8: Network Blueprints
