Virtual Private Cloud (VPC) Network Overview

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 default network that has one subnet in each region (an auto mode network).

Important: This page describes VPC networks, which are different from legacy networks. Though you can create legacy networks using the gcloud command line tool or the REST API, they are not recommended for production because they do not support advanced networking features. You cannot convert a legacy network to a VPC network.

Specifications

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. Each subnet defines a range of IP addresses. For more information about networks and subnets, see networks and subnets.

• 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 communication within the network.

• Instances with internal IP addresses can communicate with Google APIs and services. For more information, see Private Access Options.

• Network administration can be secured using Identity and Access Management (IAM) roles.

• An organization can use Shared VPC to keep a VPC network in a common host project. Authorized IAM members from other projects in the same organization can create resources that use subnets of the Shared VPC network.

• VPC networks can be connected to other VPC networks in different projects or organizations by using VPC Network Peering.

• VPC networks can be securely connected in hybrid environments using Cloud VPN or Cloud Interconnect.

• 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 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 consists of one or more useful IP range 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 types of VPC networks.

By themselves, VPC networks do not have any IP address ranges associated with them. When you create a subnet, you must define a primary IP address range. You can optionally define one or more secondary ranges:

• Primary range: You can choose any private RFC 1918 CIDR block for the primary IP address range of the subnet, subject to these rules. Your subnets don't need to form a predefined contiguous CIDR block, but you can do that if desired. For example, auto mode networks do create subnets that fit within a predefined auto mode IP range.

• Secondary ranges: You can define up to five secondary IP address ranges for use with IP aliasing.

When you create a resource in GCP, you choose a network and subnet. 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 it can use:

• 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.

Network and subnet terminology

The terms “subnet” and “subnetwork” are synonymous. They are used interchangeably in the GCP Console, gcloud commands, and API documentation.

Note: A subnet or subnetwork is not the same thing as a (VPC) network. Networks and subnets (subnetworks) are different types of objects in GCP.

Types of VPC networks

There are two types of VPC networks:

• When an auto mode 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/9 CIDR 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 10.128.0.0/9.

• When a custom mode 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 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 of the subnets 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 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.

Important: Production networks should be planned in advance. It's recommended that you use custom mode networks in production.

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 or Cloud VPN.
  • IP ranges for on-premises networks connected via Cloud VPN or Cloud Interconnect should not conflict with IP ranges of any subnet. Subnet routes must have the most specific destination.
  • 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 of the 10.128.0.0/9 CIDR 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/8 while another subnet in the same network can use 192.168.0.0/16.

• The minimum CIDR size for a subnet is /29.

Reserved IPs

Every subnet has four reserved IP addresses in its primary IP range:

Reserved Address	Description	Example
Network	First address in the primary IP range for the subnet	10.1.2.0 in 10.1.2.0/24
Default Gateway	Second address in the primary IP range for the subnet	10.1.2.1 in 10.1.2.0/24
Second-to-last Reservation	Second-to-last address in the primary IP range for the subnet	10.1.2.254 in 10.1.2.0/24
Broadcast	Last address in the primary IP range for the subnet	10.1.2.255 in 10.1.2.0/24

Note: There are no reserved IP addresses in the secondary IP ranges.

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 networks are built with one subnet per region at creation time, and will automatically receive new subnets in new regions. Hence, unused portions of 10.128.0.0/9 are reserved for future GCP use.

Region	IP Range (CIDR)	Default Gateway	Usable Addresses (Inclusive)
asia-east1	10.140.0.0/20	10.140.0.1	10.140.0.2 to 10.140.15.253
asia-east2	10.170.0.0/20	10.170.0.1	10.170.0.2 to 10.170.15.253
asia-northeast1	10.146.0.0/20	10.146.0.1	10.146.0.2 to 10.146.15.253
asia-south1	10.160.0.0/20	10.160.0.1	10.160.0.2 to 10.160.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
europe-north1	10.166.0.0/20	10.166.0.1	10.166.0.2 to 10.166.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
northamerica-northeast1	10.162.0.0/20	10.162.0.1	10.162.0.2 to 10.162.15.253
southamerica-east1	10.158.0.0/20	10.158.0.1	10.158.0.2 to 10.158.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
us-west2	10.168.0.0/20	10.168.0.1	10.168.0.2 to 10.168.15.253

Routes and firewall rules

Routes

Routes define paths for packets leaving instances (egress traffic). Routes in GCP are divided into two categories: system-generated and custom. This section briefly describes the two types of system generated routes. You can create custom routes in your network as well. See the routes overview for complete details about routing in GCP.

Every new network starts with two types of system-generated routes:

• The default route defines a path for traffic to leave the VPC network. It provides general Internet access to VMs that meet the Internet access requirements. It also provides the typical path for Private Google Access.

• A subnet route is created for each of the IP ranges associated with a subnet. Every subnet has at least one subnet route for its primary IP range, and additional subnet routes are created for a subnet if you add secondary IP ranges to it. Subnet routes define paths for traffic to reach VMs that use the subnets.

Important: You cannot remove subnet routes manually. Refer to the subnet routes section of the routes overview for details about how subnet routes are created or deleted.

Dynamic routing mode

Each VPC network has an associated dynamic routing mode that controls the behavior of all if its Cloud Routers. Cloud Routers share routes to your VPC network and learn custom dynamic routes from connected networks when you connect your VPC network to another network with a Cloud VPN tunnel using dynamic routing, Dedicated Interconnect, or Partner Interconnect.

• Regional dynamic routing is the default. In this mode, routes to on-premises resources learned by a given Cloud Router in the VPC network only apply to the subnets in the same region as the Cloud Router. Unless modified by custom advertisements, 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 available in all of subnets in the VPC network, regardless of region. Unless modified by custom advertisements, each Cloud Router shares routes to all subnets in the VPC network with its on-premises counterpart.

See custom advertisements for information about how the set of routes shared by a Cloud Router can be customized.

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 instructions.

Caution: Changing the dynamic routing mode has the potential to interrupt traffic within the network, or enable or disable routes in unexpected ways. Carefully review the role of each Cloud Router before changing the dynamic routing mode.

Firewall rules

Firewall rules apply to both outgoing (egress) and incoming (ingress) traffic in the network. Firewall rules control traffic even if it is entirely within the network, such as instance-to-instance communication.

Every VPC network has two implied firewall rules. One implied rule allows all egress traffic, and the other denies all ingress traffic. You cannot delete the implied rules, but you can override them with your own.

See the firewall rules overview for more information.

You can monitor which firewall rule allowed or denied a particular connection. See Firewall Rules Logging for more information.

Communication within the network

The system-generated subnet routes define the paths for sending traffic among instances within the network using internal (private) IP addresses. For one instance to be able to communicate with another, appropriate firewall rules must also be configured because every 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 default-allow-internal rule, which permits instance-to-instance communication within the network. The default 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 GCP Console.

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. See Routes for more information about routes.

• Firewall rules must allow egress traffic from the instance. Unless overridden by a higher priority rule, the implied allow rule for egress traffic permits outbound traffic from all instances.

• One of the following must be true:

  • The instance must have an external IP address. An external IP can be assigned to an instance when it is created or after it has been created.

  • Another instance in the network must serve as as a NAT gateway.

VPC network example

The following example illustrates custom mode network with three subnets in two regions:

VPC network example (click to enlarge)

• Subnet1 is defined as 10.240.0.0/24 in 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/24 in 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.

What's next

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