Default VPC and subnets in GCP - Deep Dive

Overview - Default VPC and subnets

What is it?

A Default VPC is a ready-made network in Google Cloud that automatically exists in each region of your project. It includes default subnets, which are smaller network sections inside the VPC, each covering a specific region. These default networks let you start using cloud resources without setting up networking from scratch. They come pre-configured with basic settings to help your resources communicate securely and easily.

Why it matters

Without Default VPCs and subnets, beginners would need to manually create and configure networks before launching any cloud resources, which can be confusing and error-prone. This setup saves time and reduces mistakes, allowing users to focus on building their applications. It also ensures that resources can connect and communicate safely right away, avoiding common network problems.

Where it fits

Before learning about Default VPCs, you should understand basic cloud concepts like projects and regions. After this, you can explore custom VPCs, firewall rules, and advanced networking features like VPNs and peering. This topic is an early step in mastering cloud networking.

Mental Model

Core Idea

A Default VPC is like a pre-built neighborhood with ready roads (subnets) in every city (region) so your cloud resources can move and talk without building roads yourself.

Think of it like...

Imagine moving into a new town where every neighborhood already has streets, streetlights, and mailboxes set up. You don’t have to build anything to start living there. The Default VPC is that neighborhood, and subnets are the streets connecting houses (resources).

┌─────────────────────────────┐
│        Default VPC          │
│  ┌───────────────┐          │
│  │ Subnet (us)   │          │
│  ├───────────────┤          │
│  │ Subnet (eu)   │          │
│  ├───────────────┤          │
│  │ Subnet (asia) │          │
│  └───────────────┘          │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is a VPC in GCP

Concept: Introduce the idea of a Virtual Private Cloud as a private network in the cloud.

A VPC is like your own private space in the cloud where your resources can connect securely. It controls how your cloud machines talk to each other and to the internet. Think of it as a fenced yard where you decide who can enter and what paths they can take.

Result

You understand that a VPC is a private network container for cloud resources.

Understanding VPCs is key because all cloud resources need a network to communicate safely and efficiently.

2

Foundation

Understanding Subnets Basics

Concept: Explain subnets as smaller parts of a VPC that organize resources by region.

Subnets divide a VPC into sections, each covering a specific geographic area called a region. This helps manage traffic and security by grouping resources close to each other. Each subnet has its own range of IP addresses for resources inside it.

Result

You know that subnets help organize and control where resources live inside a VPC.

Knowing subnets helps you plan how resources connect and stay secure across different locations.

3

Intermediate

Default VPC Creation and Features

🤔Before reading on: Do you think Default VPCs are created automatically or must be manually set up? Commit to your answer.

Concept: Explain that Google Cloud creates a Default VPC automatically with default subnets in every region.

When you create a new Google Cloud project, a Default VPC is automatically created. It includes one subnet per region with predefined IP ranges. It also has default firewall rules allowing basic communication and internet access. This setup lets you launch resources immediately without network setup.

Result

You realize Default VPCs save time by providing ready-to-use networks.

Knowing Default VPCs exist by default helps beginners avoid unnecessary setup and focus on using cloud resources.

4

Intermediate

Default Subnets and IP Ranges

🤔Before reading on: Do you think all default subnets share the same IP range or have unique ranges per region? Commit to your answer.

Concept: Describe how each default subnet has a unique IP range assigned automatically per region.

Each default subnet covers a different region and has a unique block of IP addresses. These ranges are chosen to avoid conflicts and allow resources in different regions to communicate without overlap. For example, the us-central1 subnet might use 10.128.0.0/20, while europe-west1 uses 10.132.0.0/20.

Result

You understand how IP ranges keep networks organized and prevent address conflicts.

Recognizing unique IP ranges per subnet is crucial for planning resource communication and avoiding network errors.

5

Intermediate

Default Firewall Rules Explained

🤔Before reading on: Do you think default firewall rules block all traffic or allow some by default? Commit to your answer.

Concept: Explain that Default VPC comes with firewall rules that allow basic traffic like SSH and ICMP inside the network and internet access out.

The Default VPC includes firewall rules that let resources talk to each other inside the network and connect to the internet. For example, rules allow SSH (port 22) and ping (ICMP) between resources. This helps users connect to their machines without extra setup.

Result

You see that default firewall rules simplify initial connectivity and security.

Knowing default firewall rules prevents confusion about why some connections work immediately while others need configuration.

6

Advanced

Modifying and Deleting Default VPC

🤔Before reading on: Can you delete the Default VPC without any impact on your project? Commit to your answer.

Concept: Discuss how you can change or remove the Default VPC but must understand consequences and recreate it if needed.

You can delete the Default VPC if you want a custom network setup. However, deleting it removes all default subnets and firewall rules, so resources lose network connectivity until you create new networks. Google Cloud allows recreating the Default VPC later with a command if needed.

Result

You learn the risks and recovery options when changing the Default VPC.

Understanding the impact of deleting Default VPC helps avoid accidental downtime and guides safe network customization.

7

Expert

Default VPC Internals and Limitations

🤔Before reading on: Do you think Default VPC supports custom routing and advanced network features out of the box? Commit to your answer.

Concept: Reveal the internal design of Default VPC and its limits compared to custom VPCs.

The Default VPC is designed for simplicity and quick start. It uses automatic subnet creation and basic firewall rules but lacks advanced routing, custom IP ranges, or private Google access by default. Experts often replace it with custom VPCs for fine control, security, and scalability. Default VPC also uses legacy network mode, which has some limitations compared to newer modes.

Result

You grasp why Default VPC is good for beginners but not for complex production setups.

Knowing Default VPC internals and limits helps experts decide when to switch to custom networks for better control and security.

Under the Hood

The Default VPC is automatically created by Google Cloud when a new project starts. It sets up one subnet per region with predefined IP ranges from a reserved private IP space. It also creates default firewall rules that allow internal communication and outbound internet access. Internally, it uses auto mode (not legacy network mode), which means subnets are regional and routing is automatic but less flexible than custom networks in custom mode. The system manages IP allocation and firewall rules centrally to simplify user experience.

Why designed this way?

Google designed Default VPCs to lower the barrier for new users by providing a ready-to-use network environment. This avoids the complexity of manual network setup, which can be confusing and error-prone for beginners. The tradeoff was less flexibility and some legacy design choices, but it ensures immediate usability. Over time, Google introduced custom VPCs for advanced users needing more control.

┌─────────────────────────────┐
│       Google Cloud          │
│  ┌───────────────┐          │
│  │ Default VPC   │          │
│  │  ┌─────────┐  │          │
│  │  │Subnet 1 │  │          │
│  │  ├─────────┤  │          │
│  │  │Subnet 2 │  │          │
│  │  └─────────┘  │          │
│  │ Default FW   │          │
│  │ Rules        │          │
│  └───────────────┘          │
│          │                  │
│          ▼                  │
│   Resources (VMs, etc.)    │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think the Default VPC is the same in every Google Cloud project? Commit to yes or no.

Common Belief: The Default VPC is identical and shared across all projects.

Reality: Each Google Cloud project has its own separate Default VPC created independently.

Why it matters: Assuming the Default VPC is shared can lead to confusion about resource isolation and unexpected network behavior.

Quick: Do you think you must create a VPC before launching any resource? Commit to yes or no.

Common Belief: You must always create a VPC manually before using cloud resources.

Reality: Google Cloud automatically creates a Default VPC with subnets, so you can launch resources immediately without manual network setup.

Why it matters: Believing manual creation is always needed can slow down learning and cause unnecessary work.

Quick: Do you think Default VPC firewall rules block all incoming traffic by default? Commit to yes or no.

Common Belief: Default VPC firewall rules block all traffic unless explicitly allowed.

Reality: Default firewall rules allow some traffic like SSH and ICMP inside the network and outbound internet access by default.

Why it matters: Misunderstanding default firewall behavior can cause confusion about why some connections work immediately and others don’t.

Quick: Do you think Default VPC supports all advanced networking features out of the box? Commit to yes or no.

Common Belief: Default VPC supports all custom routing and advanced features like custom IP ranges and private Google access by default.

Reality: Default VPC is limited and does not support many advanced features without customization or replacement by custom VPCs.

Why it matters: Expecting full features from Default VPC can lead to design mistakes and security gaps in production.

Expert Zone

1

Default VPC uses auto mode, which differs from the legacy network mode and custom mode VPCs in routing and subnet management.

2

Deleting the Default VPC removes all default firewall rules and subnets, which can cause immediate loss of connectivity for resources relying on it.

3

Recreating the Default VPC after deletion uses a special gcloud command that restores the original default setup, which is not obvious to many users.

When NOT to use

Default VPC is not suitable when you need custom IP ranges, private Google access, shared VPCs, or advanced firewall and routing rules. In such cases, create custom VPCs with manual subnet and firewall configuration for full control.

Production Patterns

In production, teams often delete the Default VPC to avoid accidental use and create custom VPCs tailored to their security and network design. They use shared VPCs for multi-project setups and apply strict firewall rules. Default VPC is mainly used for quick testing or learning environments.

Connections

Custom VPC Networks

Builds-on

Understanding Default VPC helps grasp why custom VPCs exist and how they provide more control and flexibility for complex cloud networks.

Firewall Rules

Same pattern

Default VPC’s built-in firewall rules introduce the concept of controlling traffic flow, which is essential for securing any network.

Urban Planning

Analogy from different field

Just like city planners design neighborhoods with roads and zones for safety and efficiency, cloud networking uses VPCs and subnets to organize and secure resources.

Common Pitfalls

#1 Trying to launch resources in a new project without realizing the Default VPC exists and is ready.

Wrong approach:

Manually creating a new VPC and subnets immediately after project creation, duplicating effort.

Correct approach:

Use the existing Default VPC and its subnets to launch resources quickly, then customize if needed.

Root cause:

Lack of awareness that Google Cloud auto-creates Default VPCs for new projects.

#2 Deleting the Default VPC without planning network replacement.

Wrong approach:

gcloud compute networks delete default

Correct approach:

First create a custom VPC and migrate resources before deleting the Default VPC.

Root cause:

Not understanding that deleting Default VPC removes all default subnets and firewall rules, causing connectivity loss.

#3 Assuming default firewall rules block all traffic and trying to open ports unnecessarily.

Wrong approach:

Creating redundant firewall rules to allow SSH and ICMP that are already allowed by default.

Correct approach:

Check existing default firewall rules before adding new ones to avoid conflicts and complexity.

Root cause:

Misunderstanding the default firewall rule set and its allowances.

Key Takeaways

Default VPCs in Google Cloud provide an automatic, ready-to-use network with subnets in every region to simplify resource deployment.

Each default subnet has a unique IP range to organize resources regionally and avoid address conflicts.

Default firewall rules allow basic communication and internet access, reducing initial setup complexity.

While great for beginners, Default VPCs have limitations and are often replaced by custom VPCs for advanced production needs.

Understanding Default VPCs helps avoid common mistakes like unnecessary network creation or accidental deletion causing downtime.