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 services, 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.
Except for the
default network, you can switch a network from auto mode to
custom mode. This conversion is one-way; custom
mode networks cannot be changed (back) 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.
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
IP range. Ranges do not have to be contiguous between subnets. For
example, some subnets can use ranges from
10.0.0.0/8 while others use
ranges from the
192.168.0.0/16 space. Ranges must be unique and
non-overlapping within the network. The minimum subnet size that can be used
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
10.240.0.0/24 (instance IPs
10.240.0.3), and Subnet2 in region 2 has all of its private IPs allocated from
192.168.1.0/24 (instance IPs
192.168.1.3). You can
also see that Subnet3 crosses zones within a region.
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,
default network. You can keep the
default network and create
four more, or delete it and create five of your own.
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 compute routes list
Auto mode VPC networks, including the
default network, have routes like the
NAME NETWORK DEST_RANGE NEXT_HOP PRIORITY default-route-02a98b9a14f7edc4 default 10.128.0.0/20 1000 default-route-081fa300345dd52a default 0.0.0.0/0 default-internet-gateway 1000 default-route-93a38d78c77eac66 default 10.132.0.0/20 1000 default-route-999664b72dd247e7 default 10.140.0.0/20 1000 default-route-a1f15d0858cd51e1 default 10.142.0.0/20 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.
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.
default network has automatically created firewall rules that are
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
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 resources other than the number of VM instances and their quotas, visit the Quotas page. Many of these quotas can be increased upon request via the Request increase button on that page.
- See Using VPC for instructions on creating and modifying VPC networks.