Default vs Custom VPC Networks in GCP

Simple explanation

The default network is a pre-built auto mode VPC that Google creates in every new GCP project without you asking for it. It arrives complete with subnets in every region and four firewall rules that allow common management traffic from anywhere on the internet. It exists so that new users can launch a VM and SSH into it immediately, without understanding networking first.

Auto mode is a VPC configuration where GCP creates one subnet per region automatically when the network is created. You do not choose IP ranges. Google assigns them from the 10.128.0.0/9 block, using a fixed mapping of one /20 subnet per region. The default network is an auto mode network, but you can also create your own auto mode VPCs.

Custom mode is a VPC configuration where GCP creates no subnets at all. You define each subnet yourself: which region it covers, what IP range it uses, and what it is called. Nothing exists until you create it.

The default network exists because convenience matters when learning. Many teams delete or avoid it in practice because its firewall rules allow SSH (port 22) and RDP (port 3389) from 0.0.0.0/0, meaning any VM with an external IP is reachable on those ports by anyone on the internet. Beyond the security concern, the fixed IP ranges make the default network incompatible with VPC peering and awkward to work around as infrastructure grows.

How it works

When Google activates a new project, it automatically creates a VPC called default using —subnet-mode=auto. GCP then creates one /20 subnet in each available region, carved out of the 10.128.0.0/9 address block. Alongside the subnets, four firewall rules are attached to the network:

• default-allow-internal: allows all traffic between VMs in the same network
• default-allow-ssh: allows TCP port 22 from all source IPs (0.0.0.0/0)
• default-allow-rdp: allows TCP port 3389 from all source IPs
• default-allow-icmp: allows ICMP (ping) from all source IPs

How auto mode assigns subnets: Auto mode uses a fixed mapping between regions and IP ranges. Every auto mode VPC in the world uses the same assignments. For example, us-central1 always gets 10.128.0.0/20 and europe-west1 always gets 10.132.0.0/20. This is predictable, which is exactly the problem. Two auto mode VPCs will always have identical, overlapping subnets. VPC peering requires non-overlapping CIDRs, so two auto mode VPCs can never be peered.

# List subnets in an auto mode network (one entry per region)
gcloud compute networks subnets list \
  --network=default \
  --sort-by=region

How custom mode handles subnets: A custom mode VPC starts completely empty. No subnets are created until you define them. Each subnet requires a name, a region, and a CIDR range that you choose. You create subnets only in the regions you need, using IP ranges that fit your broader address plan. For guidance on planning those ranges correctly, see Subnets in GCP.

# Create a custom mode VPC
gcloud compute networks create production-vpc \
  --subnet-mode=custom

# Add a subnet in a specific region with your chosen CIDR
gcloud compute networks subnets create prod-subnet-uc1 \
  --network=production-vpc \
  --region=us-central1 \
  --range=10.0.1.0/24

# Add another subnet in a different region
gcloud compute networks subnets create prod-subnet-ew1 \
  --network=production-vpc \
  --region=europe-west1 \
  --range=10.0.2.0/24

Firewall behaviour: A custom mode VPC you create yourself has no firewall rules. The implicit GCP behaviour is deny all ingress and allow all egress. No VM in a new custom VPC can receive inbound connections until you explicitly allow them. That is a much safer starting point than inheriting the open rules attached to the default network. For a complete guide to building firewall rules, see Firewall Rules Explained.

Why IP planning matters from the start: Subnet CIDR ranges cannot be changed or shrunk once created. If you pick a range that overlaps with another VPC or an on-premises network, you will face a conflict with no clean solution other than migrating to a new subnet. The right time to plan your address space is before you create a single subnet. Resources connected to the network through routes also depend on the underlying CIDR structure, so changes later ripple outward. See Routes in GCP for how routing ties into subnet design.

Comparing network types

The three network types serve different purposes. The table below shows the key differences across the attributes that matter most in practice.

The rule of thumb: use a custom mode VPC for any project where you care about security, cost control, or future connectivity. That covers virtually every production workload.

When to use each network type

Default network: Acceptable for quick personal experiments, tutorial walkthroughs, and throwaway sandboxes where you do not care about security or IP planning. If you are learning GCP for the first time and just want to launch a VM and SSH into it, the default network will work. It should not survive longer than the session that needed it.

Auto mode VPC (one you create yourself): Occasionally reasonable for isolated development environments or proof-of-concept projects where you are certain peering will never be needed. Creating your own auto mode VPC avoids inheriting the permissive firewall rules from the default network, which is an improvement. However, the same IP range limitations apply. If there is any chance the environment grows, connects to another VPC, or eventually needs hybrid connectivity, start with custom mode instead.

Custom mode VPC: The right choice for any workload you care about: production services, staging environments, multi-team infrastructure, and anything that might eventually connect to other VPCs through VPC peering or Shared VPC, or to on-premises systems through hybrid connectivity.

What most production teams do: Build a custom mode VPC with a deliberate address plan, create explicit and minimal firewall rules, and remove the default network from the project at setup time. Many organisations enforce the compute.skipDefaultNetworkCreation organisation policy at the folder or organisation level so that new projects start clean, without a default network to accidentally use.

Should new projects keep or remove the default network? If you are setting up a project for real work, delete the default network. Its open firewall rules create risk even if you do not intend to use it. An engineer on your team may accidentally attach a VM to the default network rather than your custom VPC, inheriting those rules without realising it. Preventing the issue at source through an organisation policy is more reliable than relying on everyone to remember. The Network Security Best Practices guide covers this alongside other org-level controls.

Default vs custom: what the choice really means

The practical difference between default and custom mode is not just convenience versus control. It is about what problems you encounter in six months when your infrastructure grows.

A default or auto mode network ties you to a fixed IP space. Every subnet occupies a predictable range from 10.128.0.0/9. That makes the network easy to start with, but it causes real problems later. When you want to connect two environments through VPC peering, the connection will fail because the ranges overlap. When you want to connect to an on-premises network, you may find that your cloud IP ranges collide with what the corporate network already uses. These are not edge cases. They are common situations that teams hit when they start with auto mode and grow beyond a single environment.

A custom mode network starts blank. You decide which regions get subnets, which IP ranges those subnets use, and which firewall rules exist. That blank slate takes more planning upfront, but the planning pays off. Ranges can be chosen to avoid conflicts before the conflicts happen. You can implement least-privilege access from day one: no inbound traffic until you explicitly allow it, using specific ports and sources rather than 0.0.0.0/0.

The default network also sits in your project silently if you do not delete it. That matters because it is easy for a misconfigured resource to end up attached to it. Cloud SQL instances, GKE nodes, and Compute Engine VMs can all end up on the default network if someone selects it by accident or if tooling defaults to it. Once a VM is on the default network, it inherits all four permissive firewall rules. That exposure may go unnoticed for a long time. Understanding private vs public IP addresses in GCP helps you assess which resources are externally reachable and through which network they are exposed.

Default mode is convenient. Custom mode scales. The choice is mostly about whether you are optimising for getting started quickly or for building something that can grow without being rebuilt.

Removing the default network

If your project has the default network and you want to enforce clean networking, delete it. Before deleting, check that no resources are attached. VMs, Cloud SQL instances, and other services may be using default subnets, and the deletion will fail if any are.

# Check what is using the default network
gcloud compute instances list --filter="networkInterfaces[].network:default"

# Delete the default network (only works once no resources are attached)
gcloud compute networks delete default

For organisations managing many projects, the better approach is to prevent the default network from being created at all. Apply the compute.skipDefaultNetworkCreation constraint at the organisation or folder level and every new project will start without a default network.

# Apply organisation policy to prevent default network creation
gcloud resource-manager org-policies set-policy \
  --organization=ORG_ID \
  policy.json

The policy JSON sets compute.skipDefaultNetworkCreation to enforced. This is a standard control in security-conscious organisations and should be applied before any project is created, not after. See Organisation Policies for how to structure and apply constraints across your project hierarchy.