VPC
A Virtual Private Cloud (VPC) is your private network on Google Cloud — the perimeter inside which your VMs, containers, and managed services talk to each other and to the outside world. Every project gets a default VPC; production systems should never use it.
Google Cloud's VPC has one architectural detail that catches engineers from AWS off guard: the VPC is global, the subnets are regional. A single VPC spans every region. AWS does it the other way — VPCs are regional, subnets are zonal. This sounds like a small distinction, but it shapes nearly every networking decision that follows.
Global VPC, Regional Subnets
10.0.0.0/16
VM 10.0.0.410.1.0.0/16
VM 10.1.0.710.2.0.0/16
VM 10.2.0.3When VMs in different regions sit in the same VPC, they communicate over Google's private backbone using internal IPs — no peering, no transit gateway, no inter-region VPN required. The AWS equivalent needs Transit Gateway or peering between regional VPCs. Subnets, in contrast, are regional: a subnet lives in one region and spans all its zones. Plan your IP ranges per region, not per zone.
Auto Mode vs Custom Mode
An auto-mode VPC creates subnets in every region automatically using a fixed CIDR block per region (for example 10.128.0.0/20 for us-central1). It is convenient for prototypes, and the default network ships in this mode. For production, always use custom mode: you define each subnet, its region, and its CIDR range explicitly. The default network is auto-mode with a permissive default-allow-internal firewall rule — leaving it in place for production is one of the most common security mistakes on Google Cloud.
Routes and Forwarding
Google Cloud auto-creates system routes for the default internet gateway and for each subnet you create. Custom routes route traffic by destination CIDR — through a VPN tunnel, a NAT instance, or a third-party appliance. Routes are global resources but can be scoped to specific instances via network tags. Priority resolves overlapping routes — lower priority value wins. Most production VPCs need a few custom routes and a careful tag strategy; over-using custom routes makes traffic flow hard to reason about.
Firewall Rules
VPC firewall rules are stateful and applied at the VPC level, not the subnet level. Default behavior is deny ingress, allow egress. Rules match by source or destination CIDR, network tags, or service accounts, with allow or deny actions and a priority. Stateful means a request triggers an automatic return path — you do not need separate inbound and outbound rules for the same flow. This is simpler than AWS, where Security Groups are stateful but per-instance, and NACLs are stateless but per-subnet.
Hierarchical firewall policies apply rules at the organization or folder level and are evaluated before VPC-level rules. Use them for guardrails — for example, "no port 22 from the public internet, anywhere in the org" — so individual project owners cannot accidentally weaken security baselines. VPC-level rules then handle application-specific allow lists.
Shared VPC vs VPC Peering
There are two ways to extend VPC connectivity beyond a single project. The choice between them shapes how networking and product teams collaborate.
Shared VPC centralizes the network in a host project that one team owns. Other projects (service projects) attach their workloads to subnets in the host VPC. Use it when one networking team manages connectivity for many product teams in an org — the standard pattern for medium and large companies.
VPC Peering connects two independent VPCs in the same project, different projects, or even different organizations. Routes propagate between them, but peering is not transitive: if A is peered with B and B is peered with C, A cannot reach C. Use it for bilateral, ad-hoc connections — typically between two orgs or for cross-project access where Shared VPC is overkill.
Private Google Access and Private Service Connect
Workloads on subnets with Private Google Access enabled can reach Google APIs — Cloud Storage, BigQuery, and the rest — over internal IPs, with no public IP on the VM required. Private Service Connect goes further: it exposes managed services (your own internal services or partner services) over private IPs in your VPC, with finer-grained access control than peering. Use these features to keep VMs off the public internet entirely.
VPC Flow Logs
Flow Logs record sampled network flows — 5-tuple, byte counts, timestamps — to Cloud Logging. They are invaluable for security investigations, debugging connectivity issues, and traffic analysis. Cost depends on the sampling rate: 100% captures every flow but is expensive at scale; 0.5 to 1% on production subnets balances visibility against the bill. Enable Flow Logs before you need them. When an incident hits, you cannot enable them retroactively for the past.
- Using the default auto-mode network for production — the firewall is permissive, the CIDR layout is fixed, and you do not control its evolution.
- Overlapping CIDR ranges across VPCs that you later want to peer or connect to on-prem — peering refuses to establish, and there is no way to fix it without renumbering one side.
- Leaving the
default-allow-internalfirewall rule in place after going to production — any compromised workload can reach every other workload inside the VPC. - Expecting VPC Peering to be transitive — A peered with B and B peered with C does not give you A to C connectivity.
- Treating firewall rules like AWS NACLs and writing separate return-path rules — Google Cloud rules are stateful, so a single ingress allow covers the response automatically.
- Not enabling Flow Logs on production subnets until an incident forces you to wish you had them for the past week.
- Giving every VM a public IP by default — Cloud NAT and Private Google Access remove the need in almost every case.
- Use custom-mode VPC for any production environment. Treat the default network as disposable.
- Plan IP space across the entire organization early. CIDR collisions are cheap to avoid up front and expensive to fix later.
- Use hierarchical firewall policies for org-wide guardrails; reserve VPC-level rules for application specifics.
- Enable Flow Logs at a low sampling rate (0.5 to 1%) on production subnets. Raise the rate temporarily during incidents.
- Choose Shared VPC for centralized network governance; reach for VPC Peering only for bilateral, ad-hoc connections.
- Enable Private Google Access on subnets whose VMs do not need public internet outbound — most production workloads qualify.
- Default to no public IPs on VMs. Route outbound traffic through Cloud NAT or a proxy.
Knowledge Check
What scope does a VPC have in Google Cloud?
- Regional — a VPC lives in one region, like in AWS
- Zonal — a VPC is isolated to a single zone
- Global — a single VPC spans every region, with regional subnets inside it
- Per project — a VPC is scoped to a single project and cannot be shared across projects under any configuration
Why should you avoid using the default network for production workloads?
- The default network does not support adding new subnets at all
- It is in auto mode with a permissive default-allow-internal firewall rule, and you do not control its CIDR layout
- The default network does not support IPv6 traffic
- Default networks are shared across multiple Google Cloud customers in the same region, breaking tenant isolation for production workloads
If VPC A is peered with VPC B, and VPC B is peered with VPC C, can VPC A reach VPC C?
- Yes — peering routes propagate transitively, so B automatically re-advertises C's subnet routes to A
- Yes, but only for ingress traffic; egress requires an explicit route
- No — VPC peering is not transitive; you would need direct A↔C peering
- Only if all three VPCs share an overlapping CIDR range
What is the default behavior of a VPC firewall in Google Cloud?
- Deny both ingress and egress until explicit allow rules are added
- Allow both ingress and egress by default — secure-by-default is opt-in
- Deny ingress, allow egress
- Allow ingress from any other VPC in the same project, deny everything else
What is the practical trade-off of the VPC Flow Logs sampling rate?
- A higher sampling rate captures more flows but adds data-plane latency by inspecting each packet inline on the wire
- A higher sampling rate captures more flows but costs more in Cloud Logging ingestion and storage
- A lower sampling rate requires manual aggregation in BigQuery to read
- Sampling rate affects retention duration, not cost
You got correct