If you are a cloud engineer building a Google Cloud foundation in Terraform, the network is one of the first modules you write and one of the last you will want to change. My argument is that every VPC network in your foundation should be custom mode from the first apply, and new projects should not get a default network at all. This post covers why, which settings carry the decision, and where auto mode is still fine.
Why the mode matters more than it looks
Google’s best practices guide for VPC design (last reviewed January 30, 2025) asks you to make network design an early part of your organizational setup. Changing fundamentals such as segmentation or workload location later can be disruptive. I’d treat subnet creation mode as part of that early decision and choose custom mode up front, rather than starting in auto mode and fixing it later.
According to the VPC networks documentation, an auto mode network creates one subnet in every region from predefined IPv4 ranges that fit within 10.128.0.0/9. It also adds a subnet in each new region as Google makes that region available. That is convenient for a single project. For an organization, the design guide documents three problems:
- Overlap. Every auto mode network uses the same set of internal ranges, so those ranges might overlap with your on-premises corporate network once you connect it.
- No peering. You can’t connect two auto mode networks with VPC Network Peering, because their subnets use identical primary IP ranges.
- Unrequested growth. A new region means a new subnet you never asked for. The guide flags this for both sovereignty and IP address management reasons.
There is also a smaller cost. Auto mode subnets all share the network’s name, while custom mode lets you give each subnet a unique, descriptive one. If your naming scheme encodes business unit, region and environment, auto mode undercuts it.
Custom mode reverses all of this. No subnets are created for you, and you choose the regions and the ranges. In Terraform, I’d turn that control into a workflow: declare each subnet explicitly, review it in a plan before it is applied, and map its range to an entry in your address plan.
What I would put in the foundation
Turn off default network creation. Unless an organization policy prohibits it, every new project starts with a default network. That network is auto mode and comes with pre-populated IPv4 firewall rules. The documentation names the constraint that stops this: compute.skipDefaultNetworkCreation. Projects that inherit it get no default network. I’d set it at the organization node in the same Terraform stack that creates your folders, before the first workload project exists.
Delete the default networks that already exist. The design guide says you can delete the default network if it has no resources. It also says you can’t delete a network until everything that depends on it, VM instances included, has been removed. So this is easy now and harder with every resource that lands there. If a project has an empty default network today, remove it.
Don’t treat conversion as the plan. The documentation says you can switch an auto mode network to custom mode, and that the switch is one-way. That makes it a repair, not a plan.
Make fewer, larger subnets. Once you are in custom mode, it is tempting to carve many small ranges the way a traditional enterprise network might. The guide recommends the opposite. It says to group applications of the same type into fewer subnets with larger ranges, because Google Cloud’s software-defined network provides a full mesh of reachability across the VPC, and the number of subnets does not affect routing. Routing policies and firewall rules can target service accounts or network tags instead of subnet addresses.
Add a subnet when you need different settings for a feature that is configured per subnet. The guide lists these as Cloud NAT, Private Google Access, VPC Flow Logs and alias IP ranges. Keep in mind that subnets are regional resources, while the network and its routes and firewall rules are global. Regional choices belong in your subnets, and the network is shared everywhere.
When auto mode is fine
The guide says auto mode networks can be useful for early exploration. A throwaway sandbox project is a reasonable place for one, as long as you have no plan to peer it or connect it to on-premises. Those are the two cases where auto mode hurts. You can’t peer it with another auto mode network, and if you connect it to your corporate network, its ranges might overlap with what you already run there. I’d treat an auto mode network in a sandbox as disposable and never promote it into the foundation.
The decision
Before you write your first workload module, do four things:
- Settle your address plan.
- Set the default-network constraint at the organization.
- Delete the empty default networks you already have.
- Create every VPC in custom mode with a small number of deliberately sized subnets.
Choose your ranges and regions deliberately now, while no workload depends on them.