Virtual Private Cloud (VPC)

A VPC is a virtual network. Resources placed in it can communicate using private addresses, isolated from other customers and from the public internet unless you deliberately allow it.

One property makes Google Cloud's VPC distinctive and it changes how you design: the network itself is global. A single VPC spans every region, with subnets belonging to specific regions inside it. Resources in different regions on the same VPC can reach each other privately without any peering or gateway configuration.

The network is where most security boundaries actually live. Identity controls who can change a resource; the network controls what can reach it. Both are needed, and a permissive network quietly undermines careful identity work.

It is also where a large share of production incidents originate. A missing firewall rule, an overlapping address range that blocks a future connection, or a route that sends traffic somewhere unexpected are all common, and all much cheaper to prevent than to diagnose.

• VPC network — the global container. Auto mode creates subnets in every region automatically; custom mode gives you full control and is what production estates use.
• Subnet — a regional IP range. Resources take addresses from the subnet in their region. Ranges can be expanded later but not shrunk, and they must not overlap with networks you may connect to.
• Route — determines where traffic for a destination is sent. Default routes handle internal traffic and the internet gateway; custom routes send traffic through appliances or VPN tunnels.
• Firewall rule — allows or denies traffic based on direction, protocol, port, and source or destination. Rules are stateful, so return traffic for an allowed connection is permitted automatically.
• Priority — firewall rules are evaluated in priority order, lowest number first, and the first match wins. A permissive rule at priority 100 defeats a restrictive rule at priority 1000.
• Network tags and service accounts — the two ways to target firewall rules at specific instances. Service accounts are the more secure choice because tags can be applied by anyone who can edit an instance.
• Shared VPC — one host project owns the network; service projects attach to it. The standard enterprise pattern, letting a central team control networking while application teams manage their own resources.
• VPC peering — connects two VPCs privately. Address ranges must not overlap, and peering is not transitive: if A peers with B and B peers with C, A cannot reach C.
• Private Google Access and Private Service Connect — reach managed services privately, without instances needing public addresses.
• Cloud NAT — lets instances without public addresses make outbound connections. Outbound only; it does not permit inbound connections.

This is the decision that is hardest to change later and the one most often made carelessly. Ranges that overlap prevent peering, VPN connections and future acquisitions from working, and fixing it means renumbering live systems.

• Allocate ranges from a documented plan covering every environment and region you might ever need, not just the current one.
• Leave room to expand — subnet ranges can grow, so start smaller within a reserved larger block.
• Check against on-premises ranges before allocating anything, including ranges other teams have reserved but not yet used.
• Remember that managed services often need their own reserved ranges for private connectivity.
• Avoid the most common corporate ranges if you may ever need to connect to a partner or acquired company using them.

• A shared VPC where a platform team owns networking and application teams deploy into service projects.
• Private subnets with Cloud NAT so application servers reach the internet but nothing reaches them.
• Firewall rules targeting service accounts so only the web tier can reach the database tier.
• Peering to a partner's network for private data exchange without traversing the internet.
• Hybrid connectivity from an on-premises data centre through VPN or interconnect.