Shared VPC, Peering, Private Service Connect and Central Observability

What it is

Once workloads live in many projects, two things must still be shared: the network they talk over and the view operators use to watch them. This page covers both.

For networking, the choice is between Shared VPC, VPC Network Peering and Private Service Connect. For observability, it is metrics scopes for Cloud Monitoring and aggregated sinks with central log buckets for Cloud Logging.

How it works

Shared VPC

Shared VPC lets one host project own a VPC network while service projects create VMs, GKE clusters and other resources in its subnets. The network team controls subnets, routes and firewall rules centrally; application teams control their own resources.

gcloud compute shared-vpc enable net-host-prod
gcloud compute shared-vpc associated-projects add shop-web-prod \
  --host-project=net-host-prod

Billing for VMs stays with the service project, which keeps costs per team visible. Use separate host projects for production and non-production so a network change in test cannot affect production.

VPC Network Peering

VPC Network Peering connects two VPC networks, in the same or different organizations, using internal IP addresses. Both sides must create the peering, and subnet ranges must not overlap.

Peering is not transitive: if A peers with B and B peers with C, A cannot reach C through B. Each network keeps its own administration and firewall rules.

Private Service Connect

Private Service Connect (PSC) exposes a single service, not a whole network. A producer publishes a service through a service attachment; a consumer creates an endpoint with an internal IP address in its own VPC that reaches it.

PSC endpoints can also reach Google APIs privately. Because only the service is exposed, overlapping IP ranges between producer and consumer do not matter.

Multi-project monitoring

Cloud Monitoring reads metrics through a metrics scope. Every project has one; adding other projects to a scoping project's metrics scope lets dashboards and alert policies in that project see metrics from all of them.

Create a dedicated monitoring project per environment, add the application projects to its metrics scope, and keep dashboards and alerting there. Grant operators roles/monitoring.viewer on that scoping project.

Multi-project logging

Logs are stored in the project that produced them unless a sink routes them elsewhere. An aggregated sink at the organization or folder routes logs from every child project.

gcloud logging sinks create org-audit \
  logging.googleapis.com/projects/central-logs/locations/europe-west1/buckets/org-audit \
  --organization=123456789012 --include-children \
  --log-filter='logName:"cloudaudit.googleapis.com"'

The sink has a writer identity (a service account); grant it Logs Bucket Writer on the destination. Use log views on the central bucket to give each team access to only its own projects' logs, and upgrade the bucket for Log Analytics to query with SQL.

A worked example

A company runs 25 application projects under prod and nonprod folders. Each environment gets a Shared VPC host project, and service projects attach to it; developers receive Compute Network User only on their team's subnet.

An aggregated sink on each folder sends logs to a central log bucket in a logging project, with log views per team. A monitoring project per environment has all its application projects in its metrics scope, and on-call alerting lives there.

How the exam asks about this

• "A central network team must control subnets and firewall rules while application teams manage their own VMs in separate projects." Use Shared VPC with a host project and service projects.
• "The SRE team needs one dashboard and one set of alerts covering 30 projects." Add the projects to a scoping project's metrics scope.
• "Security needs every audit log from every current and future project in one place." Create an aggregated sink at the organization with --include-children to a central log bucket.