{
	"id": "5ec3a549-2749-41b5-8a97-51108b0033f5",
	"created_at": "2026-04-06T00:07:51.134251Z",
	"updated_at": "2026-04-10T13:12:20.874792Z",
	"deleted_at": null,
	"sha1_hash": "1a9a7b3a387c5873e04f477e5f5c467bb0ca0b03",
	"title": "VPC networks",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 136910,
	"plain_text": "VPC networks\r\nArchived: 2026-04-05 18:13:24 UTC\r\nVPC networks Stay organized with collections Save and categorize content based\r\non your preferences.\r\nA Virtual Private Cloud (VPC) network is a virtual version of a physical network that is implemented inside of\r\nGoogle's production network by using Andromeda.\r\nA VPC network does the following:\r\nProvides connectivity for your Compute Engine virtual machine (VM) instances.\r\nOffers native internal passthrough Network Load Balancers and proxy systems for internal Application\r\nLoad Balancers.\r\nConnects to on-premises networks by using Cloud VPN tunnels and VLAN attachments for Cloud\r\nInterconnect.\r\nDistributes traffic from Google Cloud external load balancers to backends.\r\nProjects can contain multiple VPC networks. Unless you create an organizational policy that prohibits it, new\r\nprojects start with a default network (an auto mode VPC network) that has one subnetwork (subnet) in each\r\nregion.\r\nNetworks and subnets\r\nThe terms subnet and subnetwork are synonymous. They are used interchangeably in the Google Cloud console,\r\ngcloud commands, and API documentation.\r\nA subnet is not the same thing as a (VPC) network. Networks and subnets are different types of resources in\r\nGoogle Cloud.\r\nFor more information, see Subnets.\r\nVirtual machine instances\r\nA Compute Engine virtual machine (VM) instance is a virtual machine that is hosted on Google's infrastructure.\r\nThe terms Compute Engine instance, VM instance, and VM are synonymous. They are used interchangeably in the\r\nGoogle Cloud console, the Google Cloud CLI reference, and the API documentation.\r\nVM instances include Google Kubernetes Engine (GKE) clusters, App Engine flexible environment instances, and\r\nother Google Cloud products built on Compute Engine VMs.\r\nFor more information, see Virtual machine instances in the Compute Engine documentation.\r\nhttps://cloud.google.com/vpc/docs/vpc\r\nPage 1 of 10\n\nSpecifications\r\nVPC networks have the following properties:\r\nVPC networks, including their associated routes and firewall rules, are global resources. They are not\r\nassociated with any particular region or zone.\r\nSubnets are regional resources.\r\nEach subnet defines the following IP address ranges:\r\nIPv4-only and dual-stack subnets both define a range of IPv4 addresses, while dual-stack subnets\r\nalso define a range of IPv6 addresses.\r\nIPv6-only subnets define a range of IPv6 addresses.\r\nFor more information, see Types of subnets.\r\nTraffic to and from instances can be controlled with network firewall rules. Rules are implemented on the\r\nVMs themselves, so traffic can only be controlled and logged as it leaves or arrives at a VM.\r\nResources within a VPC network can communicate with one another by using internal IPv4 addresses,\r\ninternal IPv6 addresses, or external IPv6 addresses, subject to applicable network firewall rules. For more\r\ninformation, see communication within the network.\r\nInstances with internal IPv4 or IPv6 addresses can communicate with Google APIs and services. For more\r\ninformation, see Private access options for services.\r\nNetwork administration can be secured by using Identity and Access Management (IAM) roles.\r\nAn organization can use Shared VPC to keep a VPC network in a common host project. Authorized IAM\r\nprincipals from other projects in the same organization can create resources that use subnets of the Shared\r\nVPC network.\r\nVPC networks can be connected to other VPC networks in different projects or organizations by using\r\nVPC Network Peering.\r\nVPC networks can be connected to on-premises networks or other cloud providers by using Cloud VPN or\r\nCloud Interconnect.\r\nVPC networks support version 0 of the GRE protocol with the following limitations:\r\nCloud NAT doesn't support GRE.\r\nApplication Load Balancers and proxy Network Load Balancers don't support GRE.\r\nPassthrough Network Load Balancers and protocol forwarding support GRE when using the\r\nL3_DEFAULT forwarding rule protocol. For more information, see Internal passthrough Network\r\nLoad Balancer overview, Backend service-based external passthrough Network Load Balancer\r\noverview, and Protocol forwarding overview.\r\nhttps://cloud.google.com/vpc/docs/vpc\r\nPage 2 of 10\n\nCloud Customer Care doesn't provide configuration or troubleshooting assistance for overlay\r\nnetworks.\r\nVPC networks support IPv4 and IPv6 unicast addresses. VPC networks do not support broadcast or\r\nmulticast addresses within the network.\r\nFor more information about IPv6 subnet ranges, see Subnets.\r\nVPC network example\r\nThe following example illustrates a custom mode VPC network with three subnets in two regions:\r\nVPC network example.\r\nVPC network example (click to enlarge).\r\nSubnet1 is defined as 10.240.0.0/24 in the us-west1 region.\r\nTwo VM instances in the us-west1-a zone are in this subnet. Their IP addresses both come from the\r\navailable range of addresses in subnet1.\r\nSubnet2 is defined as 192.168.1.0/24 in the us-east1 region.\r\nTwo VM instances in the us-east1-b zone are in this subnet. Their IP addresses both come from the\r\navailable range of addresses in subnet2.\r\nSubnet3 is defined as 10.2.0.0/16 , also in the us-east1 region.\r\nOne VM instance in the us-east1-b zone and a second instance in the us-east1-c zone are in subnet3,\r\neach receiving an IP address from its available range. Because subnets are regional resources,\r\ninstances can have their network interfaces associated with any subnet in the same region that\r\ncontains their zones.\r\nOrganization policy constraints\r\nEach new project starts with a default VPC network. You can disable the creation of default networks by\r\ncreating an organization policy with the compute.skipDefaultNetworkCreation constraint. Projects that\r\ninherit this policy won't have a default network.\r\nYou can control the following IPv6 configurations using organization policies:\r\nDisable VPC External IPv6 usage: If set to true, the\r\nconstraints/compute.disableVpcExternalIpv6 constraint prevents you from configuring subnets\r\nwith external IPv6 ranges.\r\nDisable VPC Internal IPv6 usage: If set to true, the\r\nconstraints/compute.disableVpcInternalIpv6 constraint prevents you from configuring subnets\r\nwith internal IPv6 ranges.\r\nDisable All IPv6 usage: If set to true, the constraints/compute.disableAllIpv6 constraint\r\ndisables the creation of, or update to, any subnets or other networking resources involved in IPv6\r\nusage.\r\nhttps://cloud.google.com/vpc/docs/vpc\r\nPage 3 of 10\n\nFor more information about constraints, see Organization policy constraints.\r\nSubnet creation mode\r\nGoogle Cloud offers two types of VPC networks, determined by their subnet creation mode:\r\nWhen an auto mode VPC network is created, one subnet from each region is automatically created within\r\nit. These automatically created subnets use a set of predefined IPv4 ranges that fit within the\r\n10.128.0.0/9 CIDR block. As new Google Cloud regions become available, new subnets in those\r\nregions are automatically added to auto mode VPC networks by using an IP range from that block. In\r\naddition to the automatically created subnets, you can add more subnets manually to auto mode VPC\r\nnetworks in regions that you choose by using IP ranges outside of 10.128.0.0/9 .\r\nWhen a custom mode VPC network is created, no subnets are automatically created. This type of network\r\nprovides you with complete control over its subnets and IP ranges. You decide which subnets to create in\r\nregions that you choose by using IP ranges that you specify.\r\nYou can switch a VPC network from auto mode to custom mode. This is a one-way conversion; custom mode\r\nVPC networks cannot be changed to auto mode VPC networks. To help you decide which type of network meets\r\nyour needs, see the considerations for auto mode VPC networks.\r\nDefault network\r\nUnless you choose to disable it, each new project starts with a default network. The default network is an auto\r\nmode VPC network with pre-populated IPv4 firewall rules. The default network does not have pre-populated IPv6\r\nfirewall rules.\r\nConsiderations for auto mode VPC networks\r\nAuto mode VPC networks are easy to set up and use, and they are well suited for use cases with these attributes:\r\nHaving subnets automatically created in each region is useful.\r\nThe predefined IP ranges of the subnets do not overlap with IP ranges that you would use for different\r\npurposes (for example, Cloud VPN connections to on-premises resources).\r\nHowever, custom mode VPC networks are more flexible and are better suited to production. The following\r\nattributes highlight use cases where custom mode VPC networks are recommended or required:\r\nHaving one subnet automatically created in each region isn't necessary.\r\nHaving new subnets automatically created as new regions become available could overlap with IP\r\naddresses used by manually created subnets or static routes, or could interfere with your overall network\r\nplanning.\r\nYou need complete control over the subnets created in your VPC network, including regions and IP address\r\nranges used.\r\nhttps://cloud.google.com/vpc/docs/vpc\r\nPage 4 of 10\n\nYou plan to connect your VPC network to another network:\r\nBecause the subnets of every auto mode VPC network use the same predefined range of IP\r\naddresses, you can't connect auto mode VPC networks to one another by using VPC Network\r\nPeering or Cloud VPN.\r\nBecause the auto mode 10.128.0.0/9 CIDR range is part of the commonly used RFC 1918\r\naddress space, networks outside of Google Cloud might use an overlapping CIDR range.\r\nYou want to create subnets with IPv6 ranges. Auto mode VPC networks don't support subnets with IPv6\r\nranges.\r\nIPv4 subnet ranges\r\nEach subnet has a primary IPv4 address range. The primary internal addresses for the following resources come\r\nfrom the subnet's primary range: VM instances, internal load balancers, and internal protocol forwarding. You can\r\noptionally add secondary IP address ranges to a subnet, which are only used by alias IP ranges. However, you can\r\nconfigure alias IP ranges for instances from the primary or secondary range of a subnet.\r\nEach primary or secondary IPv4 range for all subnets in a VPC network must be a unique valid CIDR block. Refer\r\nto the per network limits for the number of secondary IP ranges you can define.\r\nYour IPv4 subnets don't need to form a predefined contiguous CIDR block, but you can do that if desired. For\r\nexample, auto mode VPC networks do create subnets that fit within a predefined auto mode IP range.\r\nWhen you create a subnet in a custom mode VPC network, you choose what IPv4 range to use. For more\r\ninformation, see valid ranges, prohibited subnet ranges, and Limitations for IPv4 subnet ranges.\r\nThere are four unusable IP addresses in every primary IPv4 subnet range. For more information, see Unusable\r\naddresses in IPv4 subnet ranges.\r\nAuto mode VPC networks are created with one subnet per region at creation time and automatically receive new\r\nsubnets in new regions. The subnets have IPv4 ranges only, and all subnet ranges fit inside the 10.128.0.0/9\r\nCIDR block. Unused portions of 10.128.0.0/9 are reserved for future Google Cloud use. For information about\r\nwhat IPv4 range is used in which region, see Auto mode IPv4 subnet ranges.\r\nIPv6 subnet ranges\r\nWhen you create a subnet with an IPv6 range in a custom mode VPC network, you choose whether the subnet is\r\nconfigured with an internal IPv6 subnet range or an external IPv6 subnet range.\r\nInternal IPv6 subnet ranges are used for VM-to-VM communication within VPC networks. They can't be\r\nreached from the internet and aren't publicly routable.\r\nExternal IPv6 subnet ranges can be used for VM-to-VM communication, and they are also publicly\r\nroutable.\r\nFor more information about IPv6 subnet ranges, see Subnets.\r\nhttps://cloud.google.com/vpc/docs/vpc\r\nPage 5 of 10\n\nNetworks that support subnets with IPv6 address ranges\r\nYou can create subnets with IPv6 address ranges in a custom mode VPC network. For more information, see Work\r\nwith subnets.\r\nSubnets with IPv6 address ranges aren't supported in the following:\r\nAuto mode VPC networks, including the default network\r\nLegacy networks\r\nIf you have an auto mode VPC network that you would like to add subnets with IPv6 address ranges to, you can\r\ndo the following:\r\n1. Convert the auto mode network to custom mode.\r\n2. Create new dual-stack or IPv6-only subnets. You can also convert existing IPv4-only subnets to dual-stack.\r\nRoutes and firewall rules\r\nRoutes\r\nRoutes define paths for packets leaving instances (egress traffic). For details about Google Cloud route types, see\r\nRoutes.\r\nDynamic routing mode\r\nEach VPC network has an associated dynamic routing mode that controls the behavior of all of its Cloud Routers.\r\nCloud Routers manage BGP sessions for Google Cloud products that use Cloud Router.\r\nFor a description of dynamic routing mode options, see Dynamic routing mode in the Cloud Router\r\ndocumentation.\r\nRoute advertisements and internal IP addresses\r\nThe following IP addresses are advertised within a VPC network:\r\nRegional internal IPv4 addresses\r\nUsed for primary and secondary IPv4 subnet address ranges\r\nRegional internal and external IPv6 addresses\r\nUsed for internal and external IPv6 subnet address ranges\r\nGlobal internal IPv4 addresses\r\nUsed for Private Service Connect endpoints for Google APIs\r\nhttps://cloud.google.com/vpc/docs/vpc\r\nPage 6 of 10\n\nIf you connect VPC networks using VPC Network Peering, subnet ranges using private IPv4 addresses are always\r\nexchanged. You can control whether subnet ranges using privately used public IPv4 addresses are exchanged and\r\nwhether internal and external IPv6 subnet ranges are exchanged. Global internal IPv4 addresses are never\r\nexchanged using peering. For additional details, see the VPC Network Peering documentation.\r\nWhen you connect a VPC network to another network, such as an on-premises network, using a Google Cloud\r\nconnectivity product like Cloud VPN, Cloud Interconnect, or Router appliance:\r\nYou can advertise the VPC network's internal IP addresses to another network (such as an on-premises\r\nnetwork).\r\nThough connectivity between a VPC network and another network (such as an on-premises network) can\r\nuse private routing provided by a Google Cloud connectivity product, the other network's IP addresses\r\nmight also be publicly routable. Keep this in mind if an on-premises network uses publicly routable IP\r\naddresses.\r\nVM instances in a VPC network containing subnet ranges with privately used public IP addresses are not\r\nable to connect to external resources which use those same public IP addresses.\r\nTake extra care when advertising privately used public IP addresses to another network (such as an on-premises network), especially when the other network can advertise those public IP addresses to the\r\ninternet.\r\nFirewall rules\r\nBoth hierarchical firewall policies and VPC firewall rules apply to packets sent to and from VM instances (and\r\nresources that depend on VMs, such as Google Kubernetes Engine nodes). Both types of firewalls control traffic\r\neven if it is between VMs in the same VPC network.\r\nTo monitor which firewall rule allowed or denied a particular connection, see Firewall Rules Logging.\r\nCommunications and access\r\nCommunication within the network\r\nThe system-generated subnet routes define the paths for sending traffic among instances within the network by\r\nusing internal IP addresses. For one instance to be able to communicate with another, appropriate firewall rules\r\nmust also be configured because every network has an implied deny firewall rule for ingress traffic.\r\nExcept for the default network, you must explicitly create higher priority ingress firewall rules to allow instances\r\nto communicate with one another. The default network includes several firewall rules in addition to the implied\r\nones, including the default-allow-internal rule, which permits instance-to-instance communication within the\r\nnetwork. The default network also comes with ingress rules allowing protocols such as RDP and SSH.\r\nRules that come with the default network are also presented as options for you to apply to new auto mode VPC\r\nnetworks that you create by using the Google Cloud console.\r\nInternet access requirements\r\nhttps://cloud.google.com/vpc/docs/vpc\r\nPage 7 of 10\n\nThe following criteria must be satisfied for an instance to have outgoing internet access:\r\nThe network must have a valid default internet gateway route or custom route whose destination IP range\r\nis the most general ( 0.0.0.0/0 for IPv4, ::/0 for IPv6). This route defines the path to the internet. For\r\nmore information, see Route types.\r\nFirewall rules must allow egress traffic from the instance. Unless overridden by a higher priority rule, the\r\nimplied allow rule for egress traffic permits outbound traffic from all instances.\r\nOne of the following must be true:\r\nThe instance must have an external IP address. An external IP address can be assigned to an instance\r\nwhen it is created or after it has been created.\r\nThe instance must be able to use Cloud NAT or an instance-based proxy that is the target for a static\r\n0.0.0.0/0 or ::/0 route.\r\nCommunications and access for App Engine\r\nVPC firewall rules apply to resources running in the VPC network, such as Compute Engine VMs. For App\r\nEngine instances, firewall rules work as follows:\r\nApp Engine standard environment: Only App Engine firewall rules apply to ingress traffic. Because App\r\nEngine standard environment instances do not run inside your VPC network, VPC firewall rules do not\r\napply to them.\r\nApp Engine flexible environment: Both App Engine and VPC firewall rules apply to ingress traffic.\r\nInbound traffic is only permitted if it is allowed by both types of firewall rules. For outbound traffic, VPC\r\nfirewall rules apply.\r\nFor more information about how to control access to App Engine instances, see App security.\r\nTraceroute to external IP addresses\r\nFor internal reasons, Google Cloud increases the TTL counter of packets that traverse next hops in Google's\r\nnetwork. Tools like traceroute and mtr might provide incomplete results because the TTL doesn't expire on\r\nsome of the hops. Hops that are inside of Google's network might be hidden when you send packets from\r\nCompute Engine instances to destinations on the internet.\r\nThe number of hidden hops varies based on the instance's Network Service Tiers, region, and other factors. If\r\nthere are only a few hops, it's possible for all of them to be hidden. Missing hops from a traceroute or mtr\r\nresult don't mean that outbound traffic is dropped.\r\nThere is no workaround for this behavior. You must take it into account if you configure third-party monitoring\r\nthat connects to an external IP address associated with a VM.\r\nEgress throughput limits\r\nhttps://cloud.google.com/vpc/docs/vpc\r\nPage 8 of 10\n\nNetwork throughput information is available on the Network bandwidth page in the Compute Engine\r\ndocumentation.\r\nPacket size\r\nYou can find information about packet size in Maximum transmission unit.\r\nMaximum transmission unit\r\nFor more information about the maximum transmission unit (MTU) setting for a VPC network and its connected\r\nVMs, see Maximum transmission unit.\r\nFor information about changing the MTU of a VPC network, or migrating VMs between VPC networks with\r\ndifferent MTU settings, see Change the MTU setting of a VPC network.\r\nSupported protocols\r\nGoogle Cloud supports only the following protocols and extension headers:\r\nIPv4 data packets between VMs: all IPv4 protocols.\r\nIPv4 data packets between VMs and the internet: the ICMP, IPIP, TCP, UDP, GRE, ESP, AH, and SCTP\r\nprotocols.\r\nIPv6 data packets between VMs and between VMs and the internet: the AH, ESP, GRE, ICMP,\r\nICMPv6, IPIP, SCTP, TCP, and UDP protocols and the Destination Options and Fragments extension\r\nheaders. However, placing the Destination Options header after the Fragment header in an IPv6 data packet\r\nis not supported.\r\nProtocol forwarding: the AH, ESP, GRE, ICMP, ICMPv6, SCTP, TCP, and UDP protocols\r\nTo allow data packets of the supported protocols, you need to configure firewall rules or protocol forwarding rules\r\nbased on your requirements.\r\nNetwork profiles for specific use cases\r\nGoogle Cloud uses the network profile resource to pre-configure certain properties in a VPC network for a\r\nspecific use case. You can optionally specify a network profile provided by Google Cloud when you create your\r\nnetwork.\r\nThe use case supported by network profiles is running AI workloads on machines with network interfaces (NICs)\r\nthat support remote direct memory access (RDMA). Google Cloud provides RDMA network profiles that let you\r\ncreate Virtual Private Cloud (VPC) networks that support RDMA connectivity.\r\nFor more information, see the network profiles overview.\r\nFor more information about running AI workloads in Google Cloud, see the AI Hypercomputer documentation.\r\nNetwork performance\r\nhttps://cloud.google.com/vpc/docs/vpc\r\nPage 9 of 10\n\nLatency\r\nThe measured inter-region latency for Google Cloud networks can be found in our live dashboard. The dashboard\r\nshows Google Cloud's median inter-region latency and throughput performance metrics and methodology to\r\nreproduce these results using PerfKit Benchmarker.\r\nGoogle Cloud typically measures round-trip latencies less than 55 μs at the 50th percentile and tail latencies less\r\nthan 80μs at the 99th percentile between c2-standard-4 VM instances in the same zone.\r\nGoogle Cloud typically measures round-trip latencies less than 45μs at the 50th percentile and tail latencies less\r\nthan 60μs at the 99th percentile between c2-standard-4 VM instances in the same low-latency network (\"compact\"\r\nplacement policy). A compact placement policy lowers the network latency by ensuring that the VMs are located\r\nphysically within the same low-latency network.\r\nMethodology: Intra-zone latency is monitored via a blackbox prober that constantly runs netperf TCP_RR\r\nbenchmark between a pair of c2-types VMs in every zone c2 instances are available. It collects P50 and P99\r\nresults for setup with and without compact placement policy. TCP_RR benchmark measures request/response\r\nperformance by measuring the transaction rate. If your applications require best possible latency, c2 instances are\r\nrecommended.\r\nPacket loss\r\nGoogle Cloud tracks cross-region packet loss by regularly measuring round-trip loss between all regions. We\r\ntarget the global average of those measurements to be lower than 0.01% .\r\nMethodology: A blackbox vm-to-vm prober monitors the packet loss for every zone pair using pings and\r\naggregates the results into one global loss metric. This metric is tracked with a one-day window.\r\nWhat's next\r\nTo learn about using VPC networks and subnets, see Create, modify, or delete VPC networks and subnets.\r\nTo learn about best practices for deploying VPC networks, see Best practices and reference architectures\r\nfor VPC design.\r\nTo learn about deploying VPC networks as part of Cross-Cloud Network, see Cross-Cloud Network for\r\ndistributed applications.\r\nTry it for yourself\r\nIf you're new to Google Cloud, create an account to evaluate how VPC performs in real-world scenarios. New\r\ncustomers also get $300 in free credits to run, test, and deploy workloads.\r\nTry VPC free\r\nSource: https://cloud.google.com/vpc/docs/vpc\r\nhttps://cloud.google.com/vpc/docs/vpc\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://cloud.google.com/vpc/docs/vpc"
	],
	"report_names": [
		"vpc"
	],
	"threat_actors": [],
	"ts_created_at": 1775434071,
	"ts_updated_at": 1775826740,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1a9a7b3a387c5873e04f477e5f5c467bb0ca0b03.pdf",
		"text": "https://archive.orkl.eu/1a9a7b3a387c5873e04f477e5f5c467bb0ca0b03.txt",
		"img": "https://archive.orkl.eu/1a9a7b3a387c5873e04f477e5f5c467bb0ca0b03.jpg"
	}
}