A VPC network, sometimes just called a “network,” is a virtual version of a physical network, like a data center network. It provides connectivity for your Compute Engine virtual machine (VM) instances, Kubernetes Engine clusters, App Engine Flex instances, and other resources in your project.
Projects can contain multiple VPC networks. New projects start with a
network that has one subnet in each region (an auto mode VPC
VPC networks have the following properties:
VPC networks, including their associated routes and firewall rules, are global resources. They are not associated with any particular region or zone.
Subnets are regional resources. They must be created in VPC networks to define sets of usable IP ranges. For more information about networks and subnets, see the networks and subnets section.
Traffic to and from instances can be controlled with network firewall rules.
Resources within a VPC network can communicate with one another using internal (private) IPv4 addresses, subject to applicable network firewall rules. For more information, see the communication within the network section.
VPC administration can be secured using Identity and Access Management (IAM) roles.
You can share a VPC network from one project to instances in another project within the same organization using shared VPC. Shared VPC enables multi-tenancy deployments and delegated instance administration while separately maintaining network administrative controls.
VPC networks can be connected to other GCP VPC networks from different projects or organizations by using VPC peering.
VPC networks only support IPv4 unicast traffic. They do not support broadcast, multicast, or IPv6 traffic within the network. However, IPv6 can be used to reach resources in the VPC network. For example, IPv6 addresses can be assigned to a global load balancer, and the App Engine standard environment supports IPv6.
Networks and subnets
Each VPC network is divided into useful partitions called subnetworks or subnets. Each subnet is associated with a region. Networks can contain one or more subnets in any given region. Auto mode networks create subnets in each region automatically. Custom mode networks start with no subnets, giving you full control over subnet creation. For information about the differences between auto and custom mode networks, see the types of VPC networks section.
A subnet has a primary IP address range defined as a contiguous private RFC 1918 CIDR block. IP address ranges used for subnets do not need to belong to a larger contiguous block, but there are some restrictions discussed in the subnets and IP ranges section.
When you create a resource in GCP, you choose a network and subnet for it. For resources other than instance templates, you also select a zone or a region. Selecting a zone implicitly selects its parent region. Because subnets are regional objects, the region you select for a resource determines the subnets you can select when you create it:
The process of creating an instance involves selecting a zone, a network, and a subnet. The subnets available for selection are restricted to those in the selected region. GCP assigns the instance an IP address from the range of available addresses in the subnet.
The process of creating a managed instance group involves selecting a zone or region, depending on the group type, and an instance template. The instance templates available for selection are restricted to those whose defined subnets are in the same region selected for the managed instance group.
- Instance templates are global resouces. The process of creating an instance template involves selecting a network and a subnet. If you select an auto mode network, you can choose “auto subnet” to defer subnet selection to one that is available in the selected region of any managed instance group that would use the template, because auto mode networks have a subnet in every region by definition.
The process of creating a Kubernetes container cluster involves selecting a zone or region (depending on the cluster type), a network, and a subnet. The subnets available for selection are restricted to those in the selected region.
Optionally, a subnet may have one or more secondary IP address ranges associated with it, which can be used for IP aliasing.
Network and subnet terminology
The term “subnet” is a shortening of the word “subnetwork,” and they mean the
same thing with respect to GCP. These two terms are used interchangeably in the
gcloud commands, and API documentation.
Quotas and limits
The following resource quotas and limits are applicable to VPC networks. Quotas can be changed upon request, and you can view current quota usage on the quotas page in the GCP Console. Limits cannot be increased.
|Item||Quota or Limit||Amount||Notes|
|VPC Networks per Project||Quota||5||Network count includes the
|VM Instances per VPC Network||Limit||7000||This is a fixed maximum number of instances per network, not a quota. You cannot have more than 7000 instances per network; however, you can create additional networks.|
|VM Instances per Subnet||No separate limit||There is no limitation on the number of instances per subnet as long as the total number of instances per network is 7000 or fewer.|
|Secondary IP Ranges per Subnet||Limit||5||This is a fixed maximum number of secondary IP ranges per subnet, not a quota. You cannot have more than 5 secondary IP ranges per subnet; however, you can create additional subnets.|
|Subnets per VPC||Quota||100||Default limit, can be raised with quota request.|
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 which fit within the
10.128.0.0/9CIDR block. As new GCP regions become available, new subnets in those regions are automatically added to auto mode networks using an IP range from that block. In addition to the automatically created subnets, you can add more subnets manually to auto mode networks, in regions you choose, using IP ranges outside of
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 and IP ranges. You decide which subnets to create, in regions you choose, and using IP ranges you specify.
Each project starts with a
default auto mode network.
You can switch a 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.
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.
Subnets and IP ranges
IP ranges can be assigned to subnets you create according to these rules:
Each subnet must have a primary address range, which is a valid RFC 1918 CIDR block.
Subnets in the same network must use unique IP ranges. Subnets in different networks, even in the same project, can re-use the same IP address ranges.
When you create a subnet manually, you can use any RFC 1918 CIDR range subject to these restrictions:
- Subnets in the same GCP network must have unique IP ranges.
- IP ranges for all subnets must be unique among VPC networks that are connected to one another by VPC Network Peering.
- IP ranges for on-premises networks cannot conflict with the GCP ranges if you use Cloud VPN or Dedicated Interconnect for hybrid connectivity.
- IP ranges used by subnets cannot otherwise conflict with ones referenced by a static route.
- When creating additional subnets in an auto mode
network, your manually-created subnets must use an IP range outside
10.128.0.0/9CIDR block. That block is reserved for the primary IP ranges of automatically created subnets.
You can assign one or more secondary IP ranges to a subnet. These secondary ranges are reserved for VM instances in the subnet that are configured with IP aliases. Secondary ranges can be any RFC 1918 CIDR block subject to the same restrictions discussed in the previous point.
IP ranges do not need to be contiguous from subnet to subnet in the same network.
IP ranges for subnets in the same network do not have to be a member of a larger contiguous CIDR block. For example, one subnet can use
10.0.0.0/8while another subnet in the same network can use
The minimum CIDR size for a subnet is
Every subnet has four reserved IP addresses in its primary IP range:
|Network||First address in the primary IP range for the subnet|
|Default Gateway||Second address in the primary IP range for the subnet|
|Second-to-last Reservation||Second-to-last address in the primary IP range for the subnet|
|Broadcast||Last address in the primary IP range for the subnet|
Auto mode IP ranges
This table lists the IP ranges for the automatically created subnets in an
auto mode network. IP ranges for these subnets fit inside the
10.128.0.0/9 CIDR block. Auto mode VPC networks are built with one subnet per
region at creation time, and will automatically
receive new subnets in new regions. Hence, unused portions of
reserved for future GCP use.
|Region||IP Range (CIDR)||Default Gateway||Usable Addresses (Inclusive)|
|northamerica-northeast1||10.162.0.0/20||10.162.0.1||10.162.0.2 to 10.162.15.253|
|us-central1||10.128.0.0/20||10.128.0.1||10.128.0.2 to 10.128.15.253|
|us-east1||10.142.0.0/20||10.142.0.1||10.142.0.2 to 10.142.15.253|
|us-east4||10.150.0.0/20||10.150.0.1||10.150.0.2 to 10.150.15.253|
|us-west1||10.138.0.0/20||10.138.0.1||10.138.0.2 to 10.138.15.253|
|southamerica-east1||10.158.0.0/20||10.158.0.1||10.158.0.2 to 10.158.15.253|
|europe-west1||10.132.0.0/20||10.132.0.1||10.132.0.2 to 10.132.15.253|
|europe-west2||10.154.0.0/20||10.154.0.1||10.154.0.2 to 10.154.15.253|
|europe-west3||10.156.0.0/20||10.156.0.1||10.156.0.2 to 10.156.15.253|
|europe-west4||10.164.0.0/20||10.164.0.1||10.164.0.2 to 10.164.15.253|
|asia-south1||10.160.0.0/20||10.160.0.1||10.160.0.2 to 10.160.15.253|
|asia-east1||10.140.0.0/20||10.140.0.1||10.140.0.2 to 10.140.15.253|
|asia-northeast1||10.146.0.0/20||10.146.0.1||10.146.0.2 to 10.146.15.253|
|asia-southeast1||10.148.0.0/20||10.148.0.1||10.148.0.2 to 10.148.15.253|
|australia-southeast1||10.152.0.0/20||10.152.0.1||10.152.0.2 to 10.152.15.253|
Routes and firewall rules
When you create a VPC network, the following default routes are automatically created and managed within it:
A route whose next hop is the default internet gateway, which defines the path for Internet access. This route can be deleted if you want to completely isolate the network from the Internet or if you want to configure a custom path for Internet access. This route only defines the path to the Internet; instances must also meet Internet access requirements if they need to send traffic to the Internet.
For each subnet, a route is created to define a path to its resources. These subnet routes show a next hop of virtual network in the GCP Console, and each defines a communication path to and from the resources for the associated subnet. Whether communication is permitted or not depends on the firewall rules defined for the VPC network. For more details about instance to instance communication, refer to communication within the network.
Auto mode networks create a subnet route for each of their automatically created subnets.
Regardless of the network type, when you create a subnet manually, a corresponding subnet route is created.
You can't delete a subnet route unless the subnet is deleted. When you delete a subnet, the associated route is automatically removed.
Each default route has a name that begins with
default-route-. Routes are
presented in the Routes section of the
GCP Console, and they can be
Routes are discussed in more detail on the routes overview
Dynamic routes are applied to a VPC network by one or more Cloud Router objects managing routes for Cloud VPN or managing routes for Dedicated Interconnect. Subject to applicable firewall rules, dynamic routes allow instances to communicate with on-premises resources and vice versa. In this way, dynamic routes allow you to create a hybrid network solution.
Each VPC network has an associated dynamic routing mode:
Regional dynamic routing is the default. In this mode, routes to on-premises resources learned by a given Cloud Router in the network only apply to the subnets in the same region as the Cloud Router. Similarly, each Cloud Router only shares the routes to subnets in its region with its on-premises counterpart.
Global dynamic routing changes the behavior of all Cloud Routers in the network such that the routes to on-premises resources that they learn are usable by all of subnets in the network, regardless of region. Each Cloud Router shares all routes for its subnets with its on-premises counterpart.
For more information about how Cloud Router advertises the VPC routes to an on-premises router, refer to the Cloud Router overview.
The dynamic routing mode can be set when you create a VPC network or modify it. You can change the dynamic routing mode from regional to global and vice-versa without restriction. Refer to using VPC networks for more information.
Firewall rules apply to outgoing (egress) traffic from instances and incoming (ingress) traffic to instances in the network. Egress and ingress traffic are controlled even if the traffic stays within the network (for example, instance-to-instance communication). When you create firewall rules, you create them within a VPC network.
Every VPC network has two implied firewall rules. One implied rule allows all egress traffic, and the other denies all ingress traffic. These implied rules cannot be deleted, but they can be overridden by higher priority rules.
default network has additional firewall
rules, including the
default-allow-internal rule, which permits communication among instances in
the network. This network also comes with ingress rules allowing protocols like
RDP and SSH. Rules that come with the
default network are also presented as
options for you to apply to new auto mode networks that you create using the
Communication within the network
The virtual network routes created for each subnet define the paths for sending traffic among instances within the network using private IP addresses. For one instance to be able to communicate with another, appropriate firewall rules must also be configured because every VPC network has an implied deny firewall rule for ingress traffic.
Except for the
default network, you must explicitly create higher priority
ingress firewall rules to allow instances to
communicate with one another. The
default network includes a number of
firewall rules in addition to the implied
ones, including the
rule, which permits instance-to-instance communication within the network.
Internet access requirements
The following criteria must be satisfied for an instance to have outgoing Internet access:
The network must have a valid default Internet gateway route or custom route whose destination IP range is the most general (
0.0.0.0/0). This route simply defines the path to the Internet.
Firewall rules must allow egress traffic from the instance. Unless overridden by a higher priority rule, the implied allow rule for egress traffic applies to all instances in the network.
One of the following must be true:
VPC network example
The following example illustrates custom mode VPC network with three subnets in two regions:
- Subnet1 is defined as
10.240.0.0/24in the us-west1 region.
- Two VM instances in the us-west1-a zone are in this subnet. Their IP addresses both come from the available range of addresses in subnet1.
- Subnet2 is defined as
192.168.1.0/24in the us-east1 region.
- Two VM instances in the us-east1-a zone are in this subnet. Their IP addresses both come from the available range of addresses in subnet2.
- Subnet3 is defined as
10.2.0.0/16, also in the us-east1 region.
- One VM instance in the us-east1-a zone and a second instance in the us-east1-b zone are in subnet3, each receiving an IP addresses from its available range. Because subnets are regional resources, instances can have their network interfaces associated with any subnet in the same region that contains their zones.
- See Using VPC for instructions on creating and modifying VPC networks.