Shared VPC for a Regulated Data Team
Your company runs a single GCP organization with folders for Platform, Analytics, and Payments. The Payments team must launch workloads into a network owned by the Platform team, but should not be able to change firewall rules, subnets, or routes. The Platform team manages billing and wants all network egress logged centrally. Analytics already has its own standalone VPC and must not be affected. You need to decide between a Shared VPC, VPC peering, and per-team standalone VPCs. There are 14 projects in Payments, 6 in Analytics, and 3 in Platform. A junior engineer proposes giving the Payments service accounts the Compute Network Admin role on the host project so they can self-serve subnet creation.
1. Which networking model should you choose, and how would you structure roles and projects to meet the constraints?
Read the worked answer
Use a Shared VPC. The Platform project becomes the host project; each Payments project is attached as a service project. Analytics stays standalone so its existing VPC is untouched.
Role split:
- Platform network admins get
compute.networkAdminon the host project. - Payments service accounts get
compute.networkUseron the host project (scoped to the specific subnets they need, not the whole host). - Payments developers get no host-project network write roles.
Why not the alternatives:
- Peering does not give centralized control of firewall policy from one owner and multiplies routes as projects grow (14 Payments projects).
- Standalone VPCs per team would fragment firewall and logging policy.
The junior engineer's proposal is wrong: compute.networkAdmin on the host would let Payments create and delete subnets, routes, and firewalls, violating the constraint. networkUser is the least-privilege role for consuming shared subnets.
2. How do you satisfy the centralized egress logging requirement without changing application code?
Read the worked answer
Enable VPC Flow Logs on the shared subnets in the host project, and configure an aggregated sink at the organization or folder level that routes logs to a central logging project. Because flow logs are a subnet-level setting owned by the host project, the Platform team controls them, and Payments cannot disable them.
Steps:
- Turn on flow logs on each shared subnet with an appropriate aggregation interval and metadata setting.
- Create a log sink at the folder containing Payments projects (or the org) with destination a BigQuery dataset or Cloud Storage bucket in the central logging project.
- Grant the sink's writer identity permission on the destination.
- Optionally add a firewall rule logging policy for egress rules.
This meets the requirement with no application changes and keeps control with the network owner.