Shared VPCs Across Accounts and Projects

Separating network ownership from workload ownership

Large organisations use many accounts (AWS) or projects (Google Cloud) for billing and blast-radius isolation. Giving every account its own VPC means many CIDR blocks, many NAT gateways and many connections to manage. A shared VPC inverts this: a central network team owns one VPC and lets other accounts or projects launch resources into specific subnets. In Google Cloud this is called Shared VPC, with a host project owning the network and service projects using its subnets. In AWS the same effect comes from sharing subnets through AWS Resource Access Manager (RAM); participants can launch instances into shared subnets but cannot change the VPC's route tables, NACLs or gateways. Benefits are centralised control of routing, egress and inspection, and fewer IP ranges to coordinate. The cost is coupling: subnet capacity, quotas and change windows are now shared, so the central team becomes a dependency for every app team.

A housing society's common gate

Each family owns its flat and furniture, but the society committee owns the gate, the boundary wall and the water connection. Families cannot move the gate; they use it. The network team is the committee; app teams are the flat owners.

Name the owner of every route table

In a shared VPC, app teams sometimes wait days for a route change because they do not know who owns it. Document which team owns subnets, route tables, firewalls and egress, and how to request changes.

त्वरित जाँच: In Google Cloud Shared VPC, which project owns the VPC network and its subnets?

• Every service project owns a copy
• The billing project
• The organisation node itself
• The host project