Google Cloud Core Networking: Connect Applications, Control Access, and Reach Services Privately (Part 4)

A cloud application needs more than servers. Its components must communicate with each other, access Google APIs, connect to external services, and remain protected from unwanted traffic.

Google Cloud provides different networking capabilities for these needs. Understanding their differences helps you choose the right connection instead of adding unnecessary complexity.

Topic	Main purpose	Practical example
VPC	Provide the network foundation for workloads	Connect application VMs through internal IP addresses
Shared VPC	Share centrally managed networking across projects	Let application teams use approved subnets
VPC Network Peering	Connect separate VPC networks privately	Connect application and shared-services networks
Private Service Connect	Provide private access to supported services	Consume a published API through a private endpoint
Private Google Access	Let eligible internal-only VMs reach Google APIs	Access Cloud Storage without a VM external IP
Cloud NAT	Translate addresses for supported outbound connections	Let internal-only VMs download updates
Network Service Tiers	Choose supported internet traffic delivery paths	Evaluate Premium versus Standard Tier

The following examples are illustrative architectures.

1. Virtual Private Cloud — Build your network foundation

A VPC is a virtual network for Google Cloud resources. It provides internal connectivity, routes, and firewall controls.

An important Google Cloud distinction is that VPC networks are global, while subnets are regional. A regional subnet can serve VMs in multiple zones within its region. Custom-mode networks let you explicitly choose subnet locations and address ranges.

Practical example: application and processing workloads

Suggested hands-on exercise

1. Create a custom-mode VPC.
2. Create a regional subnet with a planned CIDR range.
3. Deploy two demo VMs without external IP addresses.
4. Configure an approved administrative access path.
5. Allow the required application port between the VMs.
6. Verify connectivity and inspect failures.

Interview question: Does placing resources in different subnets isolate them?

Subnets organize addressing. Isolation requires appropriate firewall policies and access controls; different subnet membership alone is not a security boundary.

Common mistake: Planning CIDR ranges without considering future peering, on-premises networks, and Kubernetes address requirements.

2. Shared VPC — Separate application ownership from network ownership

Shared VPC lets a host project provide network resources to attached service projects in the same organization. Authorized application teams deploy resources using the shared subnets, while the network team manages the network centrally.

Practical example: centralized enterprise networking

Why an organization uses it

• Central management of IP ranges and firewall rules.
• Separate application projects and permissions.
• Controlled delegation of subnet usage.
• Consistent network standards across teams.

Suggested setup flow

1. Select the host project.
2. Enable Shared VPC.
3. Attach eligible service projects.
4. Grant necessary subnet-use permissions.
5. Deploy a test resource from a service project.
6. Verify its network attachment and access.

Interview question: How does Shared VPC differ from peering?

Shared VPC lets resources in multiple projects use one centrally managed network. Peering connects two separate networks.

Common mistake: Assuming project attachment grants every developer permission to use every subnet.

3. VPC Network Peering — Connect independent networks

VPC Network Peering provides private connectivity between separate VPC networks, including networks in different projects or organizations.

Peering requires compatible, non-overlapping subnet ranges. It does not merge the networks, exchange their firewall rules, or provide transitive connectivity.

Practical example: application and shared-services networks

In this topology, Application VPC does not automatically gain connectivity to Reporting VPC through Shared-services VPC.

Suggested setup flow

1. Check IP-range overlap.
2. Configure peering on both networks.
3. Verify the connection is active.
4. Inspect imported routes.
5. Configure firewall permissions independently.
6. Test the required destination and port.

Interview question: Peering is active, but connections fail. What do you check?

I check routes, firewall rules, destination IP and port, whether the application is listening, and DNS if the client uses a hostname.

Common mistake: Assuming an active peering connection guarantees that application traffic is allowed.

4. Private Service Connect — Connect to a service through a private endpoint

Private Service Connect supports private access to Google APIs, supported managed services, and services published by producers.

For the endpoint pattern, a consumer accesses a service through an internal endpoint in its VPC. This focuses connectivity on the published service rather than exposing the producer’s entire network.

Practical example: consume an internal risk-scoring API

Suggested exercise

1. Publish a supported producer service.
2. Configure its service attachment and consumer acceptance.
3. Create the consumer endpoint.
4. Configure DNS to resolve the service name appropriately.
5. Verify connection status.
6. Test the API.

Interview question: Why choose PSC instead of peering?

I consider PSC when consumers need access to a specific published service. Peering provides broader network connectivity, while PSC can keep the producer and consumer networks more independent.

Common mistake: Confusing PSC with Private Services Access. They are different connectivity mechanisms; use the option supported by the target service.

5. Private Google Access — Reach Google APIs without a VM external IP

Private Google Access is a subnet setting that lets eligible VM interfaces without external IP addresses reach supported Google APIs and services.

It does not provide general internet access. DNS, routes, firewall rules, and API permissions still need to be correct.

Practical example: retrieve a file from Cloud Storage

Suggested hands-on exercise

1. Enable Private Google Access on the demo subnet.
2. Use a VM without an external IP.
3. Grant its identity access to a test bucket.
4. Verify DNS and routing.
5. List or read the permitted object.

Interview question: Does enabling Private Google Access grant access to a bucket?

No. It provides connectivity. IAM permissions separately determine whether the request is authorized.

Common mistake: Expecting Private Google Access to enable access to arbitrary external package repositories.

6. Cloud NAT — Enable outbound access from internal workloads

Cloud NAT provides managed address translation. Public NAT is commonly used for outbound internet access from supported resources without external IP addresses. Private NAT addresses supported private-network translation use cases.

Public NAT permits return traffic for established connections; it does not enable unsolicited inbound connections. A Cloud Router holds the regional NAT configuration but is not a proxy VM that forwards the packets.

Practical example: download application dependencies

Suggested setup flow

1. Create or select a Cloud Router in the required region.
2. Configure Public NAT.
3. Select the applicable subnets and IP ranges.
4. Choose automatic or manually allocated NAT IPs.
5. Verify routes and egress permissions.
6. Test outbound access and inspect NAT metrics.

Interview question: How would you troubleshoot intermittent NAT failures?

I inspect NAT coverage, port allocation and exhaustion, logs, routes, firewall rules, DNS, and destination behavior.

Common mistake: Assuming a NAT IP guarantees access to an external partner. The partner must also permit that IP and the required traffic.

7. Network Service Tiers — Choose supported internet delivery paths

Network Service Tiers provides Premium and Standard options for supported external networking resources.

Premium uses Google’s global network extensively. Standard uses regional entry or exit and relies more on the public internet. Availability and compatibility depend on the resource; this is not a tier selection for every network connection.

Practical comparison

Consideration	Premium Tier	Standard Tier
Network approach	Google’s global backbone extensively	More reliance on internet transit
Evaluation focus	Global delivery and supported global architectures	Regional workloads and cost trade-offs
Decision evidence	Latency, reliability, compatibility, cost	Latency, reliability, compatibility, cost

Illustrative example: Compare delivery performance for a regional demo website and a globally accessed customer portal before selecting supported configurations.

Interview question: Is Premium always faster?

I would not promise that for every request. I evaluate the actual client locations, network paths, resource requirements, and measured performance.

Common mistake: Assuming Network Service Tiers changes IAM or provides application security.

Choose the connection by destination

How the options differ

Capability	Network relationship	Does it replace IAM or firewall controls?
Shared VPC	Multiple projects use a shared network	No
VPC Peering	Separate networks exchange supported routes	No
Private Service Connect	Consumer accesses a supported service	No
Private Google Access	Eligible internal-only VMs reach Google APIs	No
Public NAT	Supported internal resources initiate internet connections	No

A practical demo for your website

Build one internal-only application VM and test three destinations:

Test	Expected mechanism	What to demonstrate
Another VM in the same VPC	Internal routing and firewall rules	Application-port connectivity
A permitted Cloud Storage object	Private Google Access	Connectivity and IAM are separate
An external package repository	Public NAT	Outbound access without a VM external IP

Then introduce one controlled failure at a time—remove a demo firewall allowance, revoke test-bucket access, or exclude the subnet from NAT—and show readers how the error changes.

Interview answer

“I use a VPC as the network foundation and Shared VPC when networking must be centrally managed across projects. I evaluate peering for separate-network connectivity and PSC for specific private services. Private Google Access enables supported Google API access from eligible internal-only VMs, while Public NAT provides outbound internet connectivity. I troubleshoot routing, firewall rules, DNS, and authorization separately.”