VPC networks

A Virtual Private Cloud (VPC) network is a virtual version of a physical network that isimplemented inside of Google's production network by usingAndromeda.

A VPC network does the following:

• Provides connectivity for yourCompute Engine virtual machine (VM) instances.
• Offers native internal passthrough Network Load Balancers and proxy systems forinternal Application Load Balancers.
• Connects to on-premises networks by using Cloud VPN tunnels andVLAN attachments for Cloud Interconnect.
• Distributes traffic from Google Cloud external load balancers tobackends.

Projects can contain multiple VPC networks. Unless you createan organizational policy that prohibits it, new projects start with adefault network (an auto mode VPC network) that has onesubnetwork (subnet) in each region.

Important: This page describesVPC networks, which aredifferent fromlegacy networks. Legacy networks can nolonger be created and arenot recommended for production because they do notsupport advanced networking features. You canconvert a legacynetwork to a VPCnetwork. To view your existing network's type, seeViewnetworks.

Networks and subnets

The termssubnet andsubnetwork are synonymous. They are usedinterchangeably in the Google Cloud console,gcloud commands, and APIdocumentation.

A subnet isnot the same thing as a (VPC) network.Networks and subnets aredifferent types of resources in Google Cloud.

For more information, seeSubnets.

Virtual machine instances

A Compute Engine virtual machine (VM) instance is a virtual machine that ishosted on Google's infrastructure. The termsCompute Engine instance,VM instance, andVM are synonymous. They are used interchangeably in theGoogle Cloud console, the Google Cloud CLI reference, and the API documentation.

VM instances includeGoogle Kubernetes Engine (GKE) clusters,App Engine flexible environment instances,and other Google Cloud products built onCompute Engine VMs.

For more information, seeVirtual machine instancesin the Compute Engine documentation.

Specifications

VPC networks have the following properties:

• VPC networks, including their associated routes and firewallrules, areglobal resources.They arenot associated with any particular region or zone.

• Subnets areregional resources.

• Each subnet defines the following IP address ranges:

  • IPv4-only and dual-stack subnets both define a range of IPv4 addresses,while dual-stack subnets also define a range of IPv6 addresses.
  • IPv6-only subnets define a range of IPv6 addresses.

  For more information, seeTypes of subnets.

• Traffic to and from instances can be controlled with networkfirewallrules. Rules are implemented on the VMs themselves, sotraffic can only be controlled and logged as it leaves or arrives at a VM.

• Resources within a VPC network can communicate with one anotherby using internal IPv4 addresses, internal IPv6 addresses, or external IPv6addresses, subject to applicable network firewall rules. For more information,seecommunication within the network.

• Instances with internal IPv4 or IPv6 addresses can communicate withGoogleAPIs and services. For moreinformation, seePrivate access options forservices.

• Network administration can be secured by usingIdentity and Access Management (IAM) roles.

• Anorganizationcan useShared VPC to keep aVPC network in a common host project. AuthorizedIAM principals from other projects in the same organization cancreate resources that use subnets of the Shared VPC network.

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

• VPC networks can be connected to on-premises networksor other cloud providers by usingCloud VPN orCloud Interconnect.

• VPC networks support version 0 of theGRE protocol with thefollowing limitations:

  • Cloud NAT doesn't support GRE.
  • Application Load Balancers and proxy Network Load Balancers don't support GRE.
  • Passthrough Network Load Balancers and protocol forwarding support GRE when usingtheL3_DEFAULT forwarding rule protocol. For more information, seeInternal passthrough Network Load Balancer overview,Backend service-based external passthrough Network Load Balanceroverview, andProtocol forwarding overview.
  • Cloud Customer Care doesn't provideconfiguration or troubleshooting assistance for overlay networks.

• VPC networks support IPv4 and IPv6unicast addresses.VPC networks donot supportbroadcastormulticastaddresseswithin the network.

  For more information about IPv6 subnet ranges, seeSubnets.

VPC network example

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

• Subnet1 is defined as10.240.0.0/24 in the us-west1 region.
  • Two VM instances in the us-west1-a zone are in this subnet. Their IPaddresses both come from the available range of addresses insubnet1.
• Subnet2 is defined as192.168.1.0/24 in the us-east1 region.
  • Two VM instances in the us-east1-b zone are in this subnet. Their IPaddresses both come from the available range of addresses insubnet2.
• Subnet3 is defined as10.2.0.0/16, also in the us-east1 region.
  • One VM instance in the us-east1-b zone and a second instance in theus-east1-c zone are insubnet3, each receiving an IP address from itsavailable range. Because subnets are regional resources, instances canhave their network interfaces associated with any subnet in the sameregion that contains their zones.

Organization policy constraints

• Each new project starts with adefault VPCnetwork. You can disable the creation of default networks bycreating an organization policywith thecompute.skipDefaultNetworkCreation constraint.Projects that inherit this policy won't have a default network.

• You can control the following IPv6 configurations usingorganizationpolicies:

  • Disable VPC External IPv6 usage: If set to true, theconstraints/compute.disableVpcExternalIpv6 constraint prevents you fromconfiguring subnets with external IPv6 ranges.

  • Disable VPC Internal IPv6 usage: If set to true, theconstraints/compute.disableVpcInternalIpv6 constraint prevents you fromconfiguring subnets with internal IPv6 ranges.

  • Disable All IPv6 usage: If set to true, theconstraints/compute.disableAllIpv6 constraint disables the creation of, orupdate to, any subnets or other networking resources involved inIPv6 usage.

For more information about constraints, seeOrganization policyconstraints.

Subnet creation mode

Google Cloud offers two types of VPC networks, determinedby theirsubnet creation mode:

• When anauto mode VPC network iscreated, one subnet from each regionis automatically created within it. These automatically created subnets use aset ofpredefined IPv4 ranges that fit withinthe10.128.0.0/9CIDR block. As new Google Cloud regions become available, new subnets inthose regions are automatically added to auto mode VPC networksby using an IP range from that block. In addition to the automatically createdsubnets, you canadd more subnetsmanuallyto auto mode VPC networks in regions that you choose by usingIP ranges outside of10.128.0.0/9.

• When acustom mode VPC network iscreated, no subnets areautomatically created. This type of network provides you with complete controlover its subnets and IP ranges. You decide which subnets to create in regionsthat you choose by using IP ranges that you specify.

You canswitch a VPC network from auto mode to custommode.This is a one-way conversion; custom mode VPC networks cannot bechanged to auto mode VPC networks. To help you decide whichtype of network meets your needs, seethe considerations for auto mode VPC networks.

Default network

Unless you choose todisable it, each new project starts witha default network. The default network is an auto mode VPCnetwork withpre-populated IPv4 firewall rules.The default network does not have pre-populated IPv6 firewall rules.

Considerations for auto mode VPC networks

Auto mode VPC networks are easy to set up and use, and they arewell 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 IPranges 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 arebetter suited to production. The following attributes highlight use cases wherecustom 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 availablecould overlap with IP addresses used by manually created subnets or staticroutes, or could interfere with your overall network planning.

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

• You plan to connect your VPC network to another network:

  • Because the subnets of every auto mode VPC network use thesame predefined range of IP addresses, you can't connect auto modeVPC networks to one another by using VPC Network Peeringor Cloud VPN.

  • Because the auto mode10.128.0.0/9 CIDR range is part of the commonly usedRFC 1918address space, networks outside of Google Cloud might use anoverlapping CIDR range.

• You want to create subnets with IPv6 ranges. Auto mode VPCnetworks don't support subnets with IPv6 ranges.

Important: Production networks should be planned in advance. We recommend thatyou use custom mode VPC networks in production.

IPv4 subnet ranges

Each subnet has aprimary IPv4 address range. The primary internal addressesfor the following resources come from the subnet's primary range: VM instances,internal load balancers, and internal protocol forwarding. You can optionallyaddsecondary IP address ranges to a subnet, which are only used byalias IPranges. However, you can configure alias IP ranges forinstances from the primary or secondary range of a subnet.

Each primary or secondary IPv4 range for all subnets in a VPCnetwork must be a uniquevalid CIDR block. Refer to thepernetwork limits for the number of secondary IPranges you can define.

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

When you create a subnet in a custom mode VPC network, you choosewhat IPv4 range to use. For more information, seevalidranges,prohibited subnetranges, andLimitations for IPv4 subnetranges.

There are four unusable IP addresses in every primary IPv4 subnet range. Formore information, seeUnusable addresses in IPv4 subnet ranges.

Auto mode VPC networks are created with one subnet per region atcreation time and automatically receive new subnets in new regions. The subnetshave IPv4 ranges only, and all subnet ranges fit inside the10.128.0.0/9 CIDRblock. Unused portions of10.128.0.0/9 are reserved for futureGoogle Cloud use. For information about what IPv4 range is used in whichregion, seeAuto mode IPv4 subnet ranges.

IPv6 subnet ranges

When you create a subnet with an IPv6 range in a custom mode VPCnetwork, you choose whether the subnet is configured with an internal IPv6subnet range or an external IPv6 subnet range.

• Internal IPv6 subnet ranges are used for VM-to-VM communication withinVPC networks. They can't be reached from the internet andaren't publicly routable.
• External IPv6 subnet ranges can be used for VM-to-VM communication, andthey are also publicly routable.

For more information about IPv6 subnet ranges, seeSubnets.

Networks that support subnets with IPv6 address ranges

You can create subnets with IPv6 address rangesin a custom mode VPC network. For more information, seeWork with subnets.

Subnets with IPv6 address ranges aren't supported in the following:

• Auto mode VPC networks, including the default network
• Legacy networks

If you have an auto mode VPC network that you would like to addsubnets with IPv6 address ranges to, you can do the following:

1. Convert the auto mode network to custommode.

2. Create newdual-stackorIPv6-onlysubnets. You can alsoconvert existing IPv4-only subnets to dual-stack.

Routes and firewall rules

Routes

Routes define paths for packets leaving instances (egress traffic). For detailsabout Google Cloud route types, seeRoutes.

Dynamic routing mode

Each VPC network has an associateddynamic routing mode thatcontrols the behavior of all of itsCloud Routers.Cloud Routers manage BGP sessions forGoogle Cloud products that use Cloud Router.

For a description of dynamic routing mode options, seeDynamic routing modein the Cloud Router documentation.

Route advertisements and internal IP addresses

The following IP addresses are advertised within a VPC network:

• Regional internal IPv4 addresses

  Used for primary and secondaryIPv4 subnet addressranges

• Regional internal and external IPv6 addresses

  Used for internal and externalIPv6 subnet addressranges

• Global internal IPv4 addresses

  Used forPrivate Service Connect endpoints for GoogleAPIs

If you connect VPC networks using VPC Network Peering, subnetranges using private IPv4 addresses are always exchanged. You can control whethersubnet ranges using privately used public IPv4 addresses are exchanged and whetherinternal and external IPv6 subnet ranges are exchanged. Global internal IPv4addresses are never exchanged using peering. For additional details, seethe VPC Network Peering documentation.

When you connect a VPC network to another network, such asan on-premises network, using a Google Cloud connectivity product likeCloud VPN, Cloud Interconnect, or Router appliance:

• You can advertise the VPC network's internal IP addresses toanother network (such as an on-premises network).
• Though connectivity between a VPC network and another network(such as an on-premises network) can use private routing provided by aGoogle Cloud connectivity product, the other network's IP addressesmight also be publicly routable. Keep this in mind if an on-premises networkuses publicly routable IP addresses.
• VM instances in a VPC network containing subnet ranges withprivately used public IP addresses are not able to connect to externalresources which use those same public IP addresses.
• Take extra care when advertising privately used public IP addresses toanother network (such as an on-premises network), especially when the othernetwork can advertise those public IP addresses to the internet.

Firewall rules

Bothhierarchical firewall policies andVPC firewall rules apply to packets sentto and from VM instances (and resources that depend on VMs, such asGoogle Kubernetes Engine nodes). Both types of firewalls control traffic even if it isbetween VMs in the same VPC network.

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

Communications and access

Communication within the network

The system-generated subnet routes define the paths for sending traffic amonginstances within the network by using internal IP addresses. For oneinstance to be able to communicate with another, appropriate firewall rules mustalso be configured because every network has an implied deny firewallrule for ingress traffic.

Except for the default network, you must explicitly create higher priorityingress firewall rulesto allow instances to communicate with one another. The default network includesseveral firewall rules in addition to the implied ones,including thedefault-allow-internal rule, which permits instance-to-instancecommunication within the network. The default network also comes with ingressrules allowing protocols such as RDP and SSH.

Rules that come with the default network are also presented as options for youto apply to new auto mode VPC networks that you create by usingthe Google Cloud console.

Internet access requirements

The following criteria must be satisfied for an instance to have outgoinginternet access:

• The network must have a validdefault internet gateway route or custom routewhose destination IP range is the most general (0.0.0.0/0 for IPv4,::/0 for IPv6). This route defines the path to the internet. For moreinformation, seeRoute types.

• Firewall rules must allow egress traffic from the instance. Unless overriddenby a higher priority rule, the implied allow rule for egress traffic permitsoutbound traffic from all instances.

• One of the following must be true:

  • The instance must have an external IP address. An external IP address canbe assigned to an instancewhen it iscreatedorafter it has beencreated.

  • The instance must be able to useCloud NAT or aninstance-based proxy that is the target for a static0.0.0.0/0or::/0 route.

Communications and access for App Engine

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

• App Engine standard environment:Only App Engine firewall rules apply to ingress traffic. BecauseApp Engine standard environment instances do not run insideyour VPC network, VPC firewall rules do notapply to them.

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

For more information about how to control access to App Engineinstances, seeApp security.

Traceroute to external IP addresses

For internal reasons, Google Cloud increases the TTL counter of packetsthat traverse next hops in Google's network. Tools liketraceroute andmtrmight provide incomplete results because the TTL doesn't expire on some of thehops. Hops that are inside of Google's network might be hidden when you sendpackets from Compute Engine instances to destinations on the internet.

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 allof them to be hidden. Missing hops from atraceroute ormtr result don'tmean that outbound traffic is dropped.

There is no workaround for this behavior. You must take it into account if youconfigure third-party monitoring that connects to an external IP addressassociated with a VM.

Important: Probe loss statistics are a component of traceroute tests, but caremust be taken when analyzing test results.traceroute andmtr by defaultutilize ICMP-based probing. ICMP probe response generation is typicallyrate-limited (or disabled) in routers that reside in the network path of yourprobing and can result in missing probe responses. When this behavior occurs,you may see probe loss in intermediate routing hops, but this should not reflectend-to-end performance. If looking for packet loss, the only hop thatgenerally matters is the destination hop.

Egress throughput limits

Network throughput information is available on theNetwork bandwidth page in the Compute Enginedocumentation.

Packet size

You can find information about packet size inMaximum transmission unit.

Maximum transmission unit

For more information about the maximum transmission unit (MTU) setting for aVPC network and its connected VMs, seeMaximum transmission unit.

For information about changing the MTU of a VPC network, ormigrating VMs between VPC networks with different MTU settings,seeChange the MTU setting of a VPCnetwork.

Supported protocols

Google Cloud supports only the following protocols and extension headers:

• IPv4 data packets between VMs: all IPv4 protocols.
• IPv4 data packets between VMs and the internet: the ICMP, IPIP, TCP, UDP, GRE,ESP, AH, and SCTP protocols.
• IPv6 data packets between VMsand between VMs and the internet: the AH,ESP, GRE, ICMP, ICMPv6, IPIP, SCTP, TCP, and UDP protocols and the Destination Optionsand Fragments extension headers. However, placing the Destination Options header afterthe Fragment header in an IPv6 data packet is not supported.
• Protocol forwarding: the AH, ESP, GRE, ICMP, ICMPv6, SCTP, TCP, and UDPprotocols

To allow data packets of the supported protocols, you need to configurefirewall rules orprotocol forwarding rulesbased on your requirements.

Network profiles for specific use cases

Google Cloud uses the network profile resource to pre-configure certainproperties in a VPC network for a specific use case. You canoptionally specify a network profile provided by Google Cloud when youcreate your network.

The use case supported by network profiles is running AI workloads on machineswith network interfaces (NICs) that support remote direct memory access (RDMA).Google Cloud providesRDMA network profilesthat let you create Virtual Private Cloud (VPC) networks that support RDMAconnectivity.

For more information, see thenetwork profiles overview.

For more information about running AI workloads in Google Cloud,see theAI Hypercomputerdocumentation.

Network performance

Latency

The measured inter-region latency for Google Cloud networks can be foundin our livedashboard.The dashboard shows Google Cloud's median inter-region latency andthroughput performance metrics and methodology to reproduce these results usingPerfKit Benchmarker.

Google Cloud typically measures round-trip latencies less than 55 μs atthe 50th percentile and tail latencies less than 80μs at the 99th percentile between c2-standard-4 VM instances in the same zone.

Google Cloud typically measures round-trip latencies less than 45μs at the50th percentile and tail latencies less than 60μs at the 99th percentilebetween c2-standard-4 VM instances in the same low-latency network ("compact" placement policy).Acompact placement policy lowers the network latency by ensuring that the VMs are located physicallywithin the same low-latency network.

Methodology: Intra-zone latency is monitored via a blackbox proberthat constantly runsnetperf TCP_RR benchmark between a pair of c2-types VMs in every zonec2 instances are available. It collects P50 and P99 results for setup withand without compact placement policy. TCP_RR benchmark measuresrequest/response performance by measuring the transaction rate. If yourapplications require best possible latency, c2 instances are recommended.

Packet loss

Google Cloud tracks cross-region packet loss by regularly measuringround-trip loss between all regions. We target the global average of thosemeasurements to be lower than 0.01% .

Methodology: A blackbox vm-to-vm prober monitors the packet loss forevery zone pair using pings and aggregates the results into one global lossmetric. This metric is tracked with a one-day window.

What's next

• To learn about using VPC networks and subnets, seeCreate, modify, or delete VPC networks and subnets.
• To learn about best practices for deploying VPC networks, seeBest practices and reference architectures for VPC design.
• To learn about deploying VPC networks as part ofCross-Cloud Network, seeCross-Cloud Network for distributed applications.

Try it for yourself

If you're new to Google Cloud, create an account to evaluate how VPC performs in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Try VPC free