Virtual Private Cloud (VPC) Network Overview

A Virtual Private Cloud (VPC) is a global private isolated virtual network partition that provides managed networking functionality for your Google Cloud Platform (GCP) resources. A Google VPC has the following properties:

  • VPC provides a global private communications space.
  • VPC supports multi-tenancy deployments via shared VPC for your organization. A shared VPC network can be shared by different autonomously administered GCP projects.
  • VPC networks can be privately peered, even with networks in other organizations.
  • VPC provides private communication between compute resources you create, and you can also enable private communication to Google managed services like Google Cloud Storage, Spanner, big data and analytics, and Machine Learning.
  • VPC configuration access can be secured using Identity and Access Management (IAM). VPC ingress and egress traffic connections can be restricted using firewall rules.
  • VPC can be extended privately across hybrid environments.

This page describes Virtual Private Cloud (VPC) networks. For information on legacy (non-subnetted) networks, see the Legacy Network Overview.

VPC networks and subnets

A VPC network is a virtual version of the traditional physical networks that exist within and between physical data centers. A VPC network provides connectivity for your Compute Engine virtual machine (VM) instances, Kubernetes Engine containers, App Engine Flex instances, and other network-related resources.

Each GCP project contains one or more VPC networks. Each VPC network is a global entity spanning all GCP regions. This global VPC network allows VM instances and other resources to communicate with each other via internal, private IP addresses.

Each VPC network is subdivided into subnets, and each subnet is contained within a single region. You can have more than one subnet in a region for a given VPC network. Each subnet has a contiguous private RFC1918 IP space. You create instances, containers, and the like in these subnets. When you create an instance, you must create it in a subnet, and the instance draws its primary internal IP address from that subnet.

Virtual machine (VM) instances in a VPC network can communicate with instances in other subnets of the same VPC network using RFC 1918 private IP addresses, provided that firewall rules allow such communication. You can also isolate instances in different subnets using firewall rules. Refer to the firewall rules section for more detail.

Subnets vs. subnetworks

The term "subnet" is a shortening of the term "subnetwork." The two terms are synonymous. In some places in the gcloud command line tool and in the REST API, you will see the term "subnetwork" instead of "subnet," but the two terms mean the same thing.

Types of VPC networks

There are two types of VPC networks:

  • When an auto mode VPC network is created, one subnet from each region is automatically created within it. These automatically created subnets use a set of predefined IP ranges. If new regions become available, new subnets in those regions are automatically added to auto mode networks. In addition to the automatically created subnets, you may manually add more subnets to auto mode networks, in regions you choose and using IP ranges you specify.

  • When a custom mode VPC network is created, no subnets are automatically created. This type of network provides you with complete control over its subnets. You decide which subnets to create, in regions you choose, and using IP ranges you specify.

You can switch a VPC network from auto mode to custom mode. This conversion is one-way; custom mode networks cannot be changed to auto mode networks. Carefully review the considerations for auto mode networks to help you decide which type of network meets your needs.

Considerations for auto mode networks

Auto mode VPC networks are easy to set up and use, and they are well suited for use cases with these attributes:

  • Having subnets automatically created in each region is useful.

  • The predefined IP ranges do not overlap with IP ranges you would use for different purposes (for example, Cloud VPN connections to on-premises resources).

However, custom mode networks are more flexible and are better suited to production. The following attributes highlight use cases where custom mode VPC networks are recommended or required:

  • Having one subnet automatically created in each region isn't necessary.

  • Having new subnets automatically created as new regions become available could overlap with IP addresses used by manually created subnets or static routes, or could interfere with your overall network planning.

  • You need complete control over the subnets created in your VPC network, including regions and IP address ranges used.

  • You plan to connect VPC networks using VPC Network Peering or Cloud VPN. Because the subnets of every auto mode network use the same predefined range of IP addresses, you cannot connect auto mode networks to one another.

Auto mode VPC network IP ranges

Auto mode VPC network IP ranges
Region IP range Default gateway

Manually created subnet IP ranges

Manually created subnets can use any valid RFC1918 IP range. Ranges do not have to be contiguous between subnets. For example, some subnets can use ranges from while others use ranges from the space. Ranges must be unique and non-overlapping within the network. The minimum subnet size that can be used is /29.

Reserved IP addresses in every subnet

Each subnet has the following reserved addresses:

  • Network address (first address in the CIDR range)
  • Default gateway address (second address in the CIDR range)
  • Reserved address (second-to-last address in the CIDR range)
  • Broadcast address (last address in the CIDR range)

VPC network example

The figure below shows a VPC network. A new instance takes its IP address from the given subnet's prefix. Subnet1 is in region 1 and has all of its private IPs allocated from (instance IPs and, and Subnet2 in region 2 has all of its private IPs allocated from (instance IPs and You can also see that Subnet3 crosses zones within a region.

Diagram of a VPC network (click to enlarge)
Diagram of a VPC network (click to enlarge)

VPC networks and projects

Each project starts with a default network that is an auto mode VPC network. There is a quota of five networks per project, including the default network. You can keep the default network and create four more, or delete it and create five of your own.

Affiliated resources


When you create a VPC network, the following static routes are automatically associated with it:

  • A default internet gateway route, which provides outgoing connectivity from instances in all of its subnets. Combined with the default firewall rule allowing egress traffic, this route lets instances send traffic to destinations outside of the VPC network.

  • A virtual network route for each subnet. These allow for communication among instances or resources in different subnets of the network, subject to applicable firewall rules. Auto mode networks create a virtual network route for each of their automatically created subnets. Custom mode networks create one for each subnet you define.

Route names are automatically generated and will be different for each network. You can list the routes for a network by using gcloud:

gcloud compute routes list

Auto mode VPC networks, including the default network, have routes like the following:

NAME                           NETWORK   DEST_RANGE    NEXT_HOP                 PRIORITY
default-route-02a98b9a14f7edc4 default                          1000
default-route-081fa300345dd52a default     default-internet-gateway 1000
default-route-93a38d78c77eac66 default                          1000
default-route-999664b72dd247e7 default                          1000
default-route-a1f15d0858cd51e1 default                          1000

For more information, see Routes Overview.

Routing for hybrid networks

Hybrid network solutions extend an on-premises network to a VPC network. For example, you might use Cloud VPN or Dedicated Interconnect to create hybrid networks so that your on-premises hosts can reach instances in a GCP network. For these scenarios, you can use Cloud Router to dynamically exchange routes. Through the Border Gateway Protocol (BGP), Cloud Router dynamically learns about on-premises routes and advertise routes in the VPC network. You don't need to create static routes and update them when your topology changes. For more information, see Static versus dynamic routing in the Cloud Router documentation.

The subnets that a Cloud Router can advertise depends on the VPC network's dynamic routing mode. The dynamic routing mode determines whether Cloud Routers advertise subnets in the region where the router is configured (regional) or all subnets in the VPC network (global). Also, when Cloud Router learns about on-premises routes, the dynamic routing mode determines whether Cloud Router propagates the routes regionally or globally.

The dynamic routing mode is an option that you can specify when creating or editing a VPC network. By default, the mode is regional. All Cloud Routers in a VPC network use the dynamic routing mode of that network. Because this is a network-wide configuration, you might interrupt existing connections or enable unintended routes when you change the routing mode.

For more information, see Dynamic routing mode in the Cloud Router documentation. To configure the routing mode of a new VPC network, see Using VPC Networks.

Firewall rules

Each network has a set of firewall rules controlling access to and from instances in its subnets.

All ingress traffic to instances, even from other instances, is blocked unless firewall rules are created to allow it.

The default network has automatically created firewall rules that are shown in default firewall rules. No manually created network has automatically created firewall rules except for a default "allow" rule for outgoing traffic and a default "deny" for incoming traffic. For all networks except the default network, you must create any firewall rules you need.

Quotas and limits

VPC networks only support IPv4 unicast traffic. IPv4 broadcast and IPv4 multicast are not supported. VPC networks do not support IPv6 at all within the network. Global load balancer IPs and the App Engine standard environment do support IPv6.

A VPC network can have a maximum of 7000 virtual machine instances. This number is not a quota and cannot be increased on the Quotas page. If you attempt to exceed the maximum, GCP returns the following error message:

You cannot create any more instances in the network, as the limit of 7000.0 is reached.

There is no per-subnet maximum, only a maximum for the entire network.

If you need more than 7000 VM instances, you can create additional networks or contact your customer sales engineer.

For a list of other resources and their quotas, like the number of networks per project, visit the Quotas page. Many of these quotas can be increased upon request via the Edit quotas button on that page.

What's next

  • See Using VPC for instructions on creating and modifying VPC networks.

Send feedback about...