---
cuppy_hub: gcp
cuppy_path: reference/networking/vpc.md
cuppy_section: docs
cuppy_doc: NRQV-H34Y
cuppy_doc_uuid: da4eee2e-6829-4d44-959f-b2c70d7f1412
cuppy_permalink: https://cuppy.io/gcp/d/NRQV-H34Y
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/networking/vpc
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 612cefe7e797a5329d274d84b95a15d9becbca6d99ecc1516aba82b4bf94d9fc
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# VPC

## 1. The fact to internalise first

> VPC networks are **"global resources"**; **"subnets are regional resources."**

Nothing else in Google Cloud networking makes sense until that is settled, and it is the single biggest
structural difference from AWS and Azure, where the network object itself is regional. Consequences:

- **one VPC network can span every region**, with one subnet per region inside it;
- routing between two regions' subnets in the same VPC is **internal by default** — there is no peering,
  gateway or transit object between them;
- a multi-region Google Cloud estate often has **one** network where the same estate on AWS or Azure has one
  per region.

For a migration estimate this is a **re-modelling**, not a count conversion. `guides/parity/networking.md` §2
sets out what to do with a per-region network inventory arriving from either of the other clouds.

## 2. Two subnet modes

| Mode | What it does |
|---|---|
| **auto mode** | creates one subnet per region automatically, from predefined IPv4 ranges within `10.128.0.0/9` |
| **custom mode** | you create every subnet, choosing its range and region |

**Use custom mode for anything you will connect to something else.** Auto mode's predefined ranges are the
same predefined ranges everyone else's auto-mode network has, which is how two networks end up unable to peer.
The `10.128.0.0/9` range is also a real constraint on an on-premises address plan.

## 3. Firewall rules and the two implied rules

Rules apply to "packets sent to and from VM instances". The implied defaults:

| Direction | Implied rule |
|---|---|
| **ingress** | **implied deny** |
| **egress** | **implied allow** |

So a new network drops unsolicited inbound traffic and permits all outbound. **Egress is open until you close
it** — that is the opposite of some on-premises postures and it is where data-exfiltration controls have to be
added deliberately (see also VPC Service Controls, not covered in this release).

The **default** network additionally ships `default-allow-internal`, which permits instance-to-instance
traffic. A hardened design does not keep the default network.

## 4. Peering is not transitive

VPC Network Peering connects exactly two networks. **A peered to B and B peered to C does not give A to C.**
The hub-and-spoke topology that an engineer draws by habit therefore does not route on peering alone, and the
answers are Network Connectivity Center, a routing appliance, or
**Private Service Connect** (`reference/networking/private-service-connect.md`) for service access
specifically.

This is the commonest Google Cloud networking design error, and it is also true of AWS VPC peering — so it
transfers as a shared property rather than a surprise, *unless* the source design used an AWS Transit Gateway
or an Azure Virtual WAN, in which case there is a real gap to fill.

## 5. Shared VPC, in one line

The network lives in a **host project**, and authorized principals in other **service projects** create
resources using its subnets. One network team, many application projects, no peering.

That is the shape most Google Cloud landing zones use, and it is the one that makes the global-VPC property
pay: a single Shared VPC can serve every project in an organization, in every region.

Next: `reference/networking/cloud-load-balancing.md`, `reference/networking/cloud-nat.md`,
`reference/networking/errors.md`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->