VPC network overview

A Virtual Private Cloud (VPC) network is a virtual version of a physical network, such as a data center network. It provides connectivity for your Compute Engine virtual machine (VM) instances, Google Kubernetes Engine (GKE) clusters, App Engine flexible environment instances, and other resources in your project.

Projects can contain multiple VPC networks. Unless you create an organizational policy that prohibits it, new projects start with a default network that has one subnetwork (subnet) in each region (an auto mode 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.

  • Traffic to and from instances can be controlled with network firewall rules.

  • Resources within a VPC network can communicate with one another by 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 for services.

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

  • An organization can use Shared VPC to keep a VPC network in a common host project. Authorized Cloud 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 by 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; VMs in the VPC network can only send to IPv4 destinations and only receive traffic from IPv4 sources. However, it is possible to create an IPv6 address for a global load balancer.

Network and subnet terminology

The terms subnet and subnetwork are synonymous. They are used interchangeably in the Google Cloud Console, gcloud commands, and API documentation.

A subnet is not the same thing as a (VPC) network. Networks and subnets are different types of objects in Google Cloud.

Networks and subnets

Each VPC network consists of one or more useful IP range partitions called subnets. Each subnet is associated with a region. VPC networks do not have any IP address ranges associated with them. IP ranges are defined for the subnets.

A network must have at least one subnet before you can use it. Auto mode VPC networks create subnets in each region automatically. Custom mode VPC networks start with no subnets, giving you full control over subnet creation. You can create more than one subnet per region. For information about the differences between auto mode and custom mode VPC networks, see types of VPC networks.

When you create a resource in Google Cloud, 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 that you select for a resource determines the subnets that 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. Google Cloud 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 resources. The process of creating an instance template involves selecting a network and a subnet. If you select an auto mode VPC network, you can choose to use auto subnets to defer subnet selection to one that is available in the selected region of any managed instance group that would use the template. Auto mode VPC 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.

Subnet creation mode

Google Cloud offers two types of VPC networks, determined by their subnet creation mode:

  • 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 that fit within the 10.128.0.0/9 CIDR block. As new Google Cloud regions become available, new subnets in those regions are automatically added to auto mode VPC networks by using an IP range from that block. In addition to the automatically created subnets, you can add more subnets manually to auto mode VPC networks in regions that you choose by using IP ranges outside of 10.128.0.0/9.

  • 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 that you choose by using IP ranges that you specify.

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

Default network

Unless you choose to disable it, each new project starts with a default network. The default network is an auto mode VPC network with pre-populated firewall rules.

You can disable the creation of default networks by creating an organization policy with the compute.skipDefaultNetworkCreation constraint. Projects that inherit this policy won't have a default network.

Considerations for auto mode VPC 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 of the subnets do not overlap with IP ranges that you would use for different purposes (for example, Cloud VPN connections to on-premises resources).

However, custom mode VPC 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 by using VPC Network Peering or Cloud VPN. Because the subnets of every auto mode VPC network use the same predefined range of IP addresses, you cannot connect auto mode VPC networks to one another.

Subnets and IP ranges

When you create a subnet, you must define a primary IP address range. You can optionally define secondary IP address ranges:

  • Primary IP address range: You can choose any private RFC 1918 CIDR block for the primary IP address range of the subnet. These IP addresses can be used for VM primary internal IP addresses, VM alias IP addresses, and the IP addresses of internal load balancers.

  • Secondary IP address ranges: You can define one or more secondary IP address ranges, which are separate RFC 1918 CIDR blocks. These IP address ranges are used only for alias IP addresses. The per network limits describe the maximum number of secondary ranges that you can define for each subnet.

Your subnets don't need to form a predefined contiguous CIDR block, but you can do that if desired. For example, auto mode VPC networks do create subnets that fit within a predefined auto mode IP range.

For more information, see working with subnets.

Reserved IPs

Every subnet has four reserved IP addresses in its primary IP range. There are no reserved IP addresses in the secondary IP ranges.

Reserved IP 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 address Second-to-last address in the primary IP range for the subnet that is reserved by Google Cloud for potential future use 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

Auto mode IP ranges

This table lists the IP ranges for the automatically created subnets in an auto mode VPC 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 automatically receive new subnets in new regions. Unused portions of 10.128.0.0/9 are reserved for future Google Cloud 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-northeast2 10.174.0.0/20 10.174.0.1 10.174.0.2 to 10.174.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
europe-west6 10.172.0.0/20 10.172.0.1 10.172.0.2 to 10.172.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 Google Cloud are divided into two categories: system-generated and custom.

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. 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. You cannot remove subnet routes manually.

Custom routes are either static routes that you create manually or dynamic routes maintained automatically by one or more of your Cloud Routers. For more information, see custom routes.

For complete details about routing in Google Cloud, see the routes overview.

Dynamic routing mode

Each VPC network has an associated dynamic routing mode that controls the behavior of all of 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 by using a Cloud VPN tunnel that uses dynamic routing, or by using 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 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.

For information about how the set of routes shared by a Cloud Router can be customized, see custom advertisements.

The dynamic routing mode can be set when you create or modify a VPC network. You can change the dynamic routing mode from regional to global and vice-versa without restriction. For instructions, see 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, including communication among VM instances.

Every VPC network has two implied firewall rules. One implied rule allows most egress traffic, and the other denies all ingress traffic. You cannot delete the implied rules, but you can override them with your own. Google Cloud always blocks some traffic, regardless of firewall rules; for more information, see blocked traffic.

To monitor which firewall rule allowed or denied a particular connection, see Firewall Rules Logging.

Communications and access

Communication within the network

The system-generated subnet routes define the paths for sending traffic among instances within the network by 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 several 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 such as RDP and SSH.

Rules that come with the default network are also presented as options for you to apply to new auto mode VPC networks that you create by using the Cloud 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 defines the path to the internet. For more information, see 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 address can be assigned to an instance when it is created or after it has been created.

    • The instance must be able to use Cloud NAT or an instance-based proxy that is the target for a static 0.0.0.0/0 route.

Communications and access for App Engine

VPC firewall rules apply to resources running in the VPC network, such as Compute Engine VMs. For App Engine instances, firewall rules work as follows:

  • App Engine standard environment: Only App Engine firewall rules apply to ingress traffic. Because App Engine standard environment instances do not run inside your VPC network, VPC firewall rules do not apply to them.

  • App Engine flexible environment: Both App Engine and VPC firewall rules apply to ingress traffic. Inbound traffic is only permitted if it is allowed by both types of firewall rules. For outbound traffic, VPC firewall rules apply.

For more information about how to control access to App Engine instances, see App security.

Traceroute to internet-bound destinations

For internal reasons, Google Cloud increases the TTL counter of packets leaving Compute Engine instances for the internet. Tools like traceroute might provide incomplete results because the TTL doesn't expire on some of the hops. Hops that are inside and outside of Google's network might be hidden.

The number of hidden hops varies based on the instance's Network Service Tiers, region, and other factors. If there are only a few hops, it's possible for all of them to be hidden. Missing hops from a traceroute result don't mean that outbound traffic is dropped.

There is no workaround for this behavior.

VPC network example

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

VPC network example (click to enlarge)
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 address 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

Var denne siden nyttig? Si fra hva du synes:

Send tilbakemelding om ...