Subnets

Virtual Private Cloud (VPC) networks are global resources. Each VPC network consists of one or more IP address ranges called subnets. Subnets are regional resources, and have IP address ranges associated with them.

In Google Cloud, the terms subnet and subnetwork are synonymous. They are used interchangeably in the Google Cloud console, Google Cloud CLI commands, and API documentation.

Networks and 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:

• When you create an instance, you select a zone for the instance. If you don't select a network for the VM, the default VPC network is used, which has a subnet in every region. If you do select a network for the VM, you must select a network that contains a subnet in the selected zone's parent region.

• When you create a managed instance group, you select a zone or region, depending on the group type, and an instance template. The instance template defines which VPC network to use. Therefore, when you create a managed instance group, you must select an instance template with an appropriate configuration; the template must specify a VPC network that has subnets in the selected zone or region. Auto mode VPC networks always have a subnet in every region.

• The process of creating a Kubernetes container cluster involves selecting a zone or region (depending on the cluster type), a network, and a subnet. You must select a subnet that is available in the selected zone or region.

Types of subnets

VPC networks support the following subnet types:

• IPv4 only (single-stack) subnets, with only IPv4 subnet ranges

• IPv4 and IPv6 (dual-stack) subnets, with both IPv4 and IPv6 subnet ranges

A single VPC network can contain any combination of these subnet types.

When you create a subnet, you specify which stack type to use. You can also update an existing IPv4 only subnet to configure it as a dual stack subnet.

Dual-stack subnets are supported on custom mode VPC networks only. Dual-stack subnets are not supported on auto mode VPC networks or legacy networks.

Note: If you want to create dual-stack networks in an auto mode VPC network, you must first convert the auto mode network to custom mode.

When you create an IPv4 subnet range, you provide the following information:

Subnet setting	Valid values	Details
IPv4 range	A valid range that you choose	Required
Secondary IPv4 range	A valid range that you choose	Optional

When you create an IPv6 subnet range, you provide the following information:

Subnet setting	Valid values	Details
IPv6 access type	Internal External	A /64 IPv6 address range is automatically assigned to the subnet. Internal IPv6 ranges are assigned from the VPC network's internal range, which uses unique local addresses (ULAs) External IPv6 ranges use global unicast addresses (GUAs)

Purposes of subnets

Subnets can be used for different purposes:

• Regular subnets: This is the default subnet type. Regular subnets are created by users or automatically created in auto mode networks to be used with VM instances. Regular subnets have a purpose of PRIVATE in the gcloud CLI or API. The purpose is None in the Google Cloud console.
• Private Service Connect subnets: A subnet to use to publish a managed service by using Private Service Connect.
• Proxy-only subnets: A proxy-only subnet to use with regional Envoy-based load balancers.
• Private NAT subnets: A subnet that is reserved for use as the source range for Private NAT. This subnet is set to --purpose=PRIVATE_NAT.

In most cases, you cannot change the purpose of a subnet after it has been created. For more information, see the gcloud compute networks subnets update command reference.

IPv4 subnet ranges

Each subnet has a primary IPv4 address range. The primary internal addresses for the following resources come from the subnet's primary range: VM instances, internal load balancers, and internal protocol forwarding. You can optionally add secondary IP address ranges to a subnet, which are only used by alias IP ranges. However, you can configure alias IP ranges for instances from the primary or secondary range of a subnet.

Each primary or secondary IPv4 range for all subnets in a VPC network must be a unique valid CIDR block. Refer to the per network limits for the number of secondary IP address ranges you can define.

Your IPv4 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 Work with subnets.

Valid IPv4 ranges

A subnet's primary and secondary IPv4 address ranges are regional internal IPv4 addresses. The following table describes valid ranges.

Range	Description
Private IPv4 address ranges
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16	Private IP addresses RFC 1918 For information about using 172.17.0.0/16, see Additional considerations.
100.64.0.0/10	Shared address space RFC 6598
192.0.0.0/24	IETF protocol assignments RFC 6890
192.0.2.0/24 (TEST-NET-1) 198.51.100.0/24 (TEST-NET-2) 203.0.113.0/24 (TEST-NET-3)	Documentation RFC 5737
192.88.99.0/24	IPv6 to IPv4 relay (deprecated) RFC 7526
198.18.0.0/15	Benchmark testing RFC 2544
240.0.0.0/4	Reserved for future use (Class E) as noted in RFC 5735 and RFC 1112. Some operating systems do not support the use of this range, so verify that your OS supports it before creating subnets that use this range.
Privately used public IP address ranges
Privately used public IPv4 addresses	Privately used public IPv4 addresses: Are IPv4 addresses that are normally routable on the internet, but that are used privately in a VPC network Cannot belong to a prohibited subnet range When you use these addresses as subnet ranges, Google Cloud does not announce these routes to the internet and does not route traffic from the internet to them. If you have imported public IP addresses to Google using Bring your own IP (BYOIP), your BYOIP ranges and privately used public IP address ranges in the same VPC network must not overlap. For VPC Network Peering, subnet routes for public IP addresses are not automatically exchanged. The subnet routes are automatically exported by default, but peer networks must be explicitly configured to import them in order to use them.

IPv4 subnet ranges have the following constraints:

• Subnet ranges cannot match, be narrower, or be broader than a restricted range. For example, 169.0.0.0/8 is not a valid subnet range because it overlaps with the link-local range 169.254.0.0/16 (RFC 3927), which is a restricted range.

• Subnet ranges cannot span an RFC range (described in the previous table) and a privately used public IP address range. For example, 172.0.0.0/10 is not a valid subnet range because it includes both the 172.16.0.0/12 private IP address range and public IP addresses.

• Subnet ranges cannot span multiple RFC ranges. For example, 192.0.0.0/8 isn't a valid subnet range because it includes both 192.168.0.0/16 (from RFC 1918) and 192.0.0.0/24 (from RFC 6890). However, you can create two subnets with different primary ranges, one with 192.168.0.0/16 and one with 192.0.0.0/24. Or, you could use both of these ranges on the same subnet if you make one of them a secondary range.

Prohibited IPv4 subnet ranges

Prohibited subnet ranges include Google public IP addresses and commonly reserved RFC ranges, as described in the following table. These ranges cannot be used for subnet ranges.

Range	Description
Public IP addresses for Google APIs and services, including Google Cloud netblocks.	You can find these IP addresses at https://gstatic.com/ipranges/goog.txt.
199.36.153.4/30 and 199.36.153.8/30	Private Google Access-specific virtual IP addresses
0.0.0.0/8	Current (local) network RFC 1122
127.0.0.0/8	Local host RFC 1122
169.254.0.0/16	Link-local RFC 3927
224.0.0.0/4	Multicast (Class D) RFC 5771
255.255.255.255/32	Limited broadcast destination address RFC 8190 and RFC 919

Unusable addresses in IPv4 subnet ranges

Google Cloud uses the first two and last two IPv4 addresses in each subnet primary IPv4 address range to host the subnet. Google Cloud lets you use all addresses in secondary IPv4 ranges.

Unusable IPv4 address	Description	Example
Network address	First address in the primary IPv4 range	10.1.2.0 from range 10.1.2.0/24
Default gateway address	Second address in the primary IPv4 range	10.1.2.1 from range 10.1.2.0/24
Second-to-last address	Second-to-last address in the primary IPv4 range This range is reserved by Google Cloud for potential future use.	10.1.2.254 from range 10.1.2.0/24
Broadcast address	Last address in the primary IPv4 range	10.1.2.255 from range 10.1.2.0/24

Note: Google Cloud software-defined networking reserves a virtual gateway IP address for the primary IP ranges of each subnet in a VPC network. However, virtual gateways do not respond to ICMP traffic or decrement IP TTL headers.

Subnet secondary IP ranges don't have a reserved virtual gateway IP address. Thus, a default gateway doesn't respond to ping and doesn't appear when you run traceroute from a VM instance.

Tools that ping the gateway IP address as a connectivity test must be configured so that they don't consider the inability to ping a virtual gateway to be a failure condition.

Auto mode IPv4 ranges

This table lists the IPv4 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)
africa-south1	10.218.0.0/20	10.218.0.1	10.218.0.2 to 10.218.15.253
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-northeast3	10.178.0.0/20	10.178.0.1	10.178.0.2 to 10.178.15.253
asia-south1	10.160.0.0/20	10.160.0.1	10.160.0.2 to 10.160.15.253
asia-south2	10.190.0.0/20	10.190.0.1	10.190.0.2 to 10.190.15.253
asia-southeast1	10.148.0.0/20	10.148.0.1	10.148.0.2 to 10.148.15.253
asia-southeast2	10.184.0.0/20	10.184.0.1	10.184.0.2 to 10.184.15.253
australia-southeast1	10.152.0.0/20	10.152.0.1	10.152.0.2 to 10.152.15.253
australia-southeast2	10.192.0.0/20	10.192.0.1	10.192.0.2 to 10.192.15.253
europe-central2	10.186.0.0/20	10.186.0.1	10.186.0.2 to 10.186.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
europe-west8	10.198.0.0/20	10.198.0.1	10.198.0.2 to 10.198.15.253
europe-west9	10.200.0.0/20	10.200.0.1	10.200.0.2 to 10.200.15.253
europe-west10	10.214.0.0/20	10.214.0.1	10.214.0.2 to 10.214.15.253
europe-west12	10.210.0.0/20	10.210.0.1	10.210.0.2 to 10.210.15.253
europe-southwest1	10.204.0.0/20	10.204.0.1	10.204.0.2 to 10.204.15.253
me-central1	10.212.0.0/20	10.212.0.1	10.212.0.2 to 10.212.15.253
me-central2	10.216.0.0/20	10.216.0.1	10.216.0.2 to 10.216.15.253
me-west1	10.208.0.0/20	10.208.0.1	10.208.0.2 to 10.208.15.253
northamerica-northeast1	10.162.0.0/20	10.162.0.1	10.162.0.2 to 10.162.15.253
northamerica-northeast2	10.188.0.0/20	10.188.0.1	10.188.0.2 to 10.188.15.253
southamerica-east1	10.158.0.0/20	10.158.0.1	10.158.0.2 to 10.158.15.253
southamerica-west1	10.194.0.0/20	10.194.0.1	10.194.0.2 to 10.194.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-east5	10.202.0.0/20	10.202.0.1	10.202.0.2 to 10.202.15.253
us-south1	10.206.0.0/20	10.206.0.1	10.206.0.2 to 10.206.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
us-west3	10.180.0.0/20	10.180.0.1	10.180.0.2 to 10.180.15.253
us-west4	10.182.0.0/20	10.182.0.1	10.182.0.2 to 10.182.15.253

Additional considerations

Ensure that all subnet primary and secondary IPv4 address ranges don't conflict with the IPv4 address ranges that software running within your VMs needs to use. Some Google and third-party products use 172.17.0.0/16 for routing within the guest operating system. For example, the default Docker bridge network uses this range. If you depend on a product that uses 172.17.0.0/16, do not use it as any subnet primary and secondary IPv4 address range.

IPv6 subnet ranges

When you enable IPv6 on a subnet in a VPC network, you choose an IPv6 access type for the subnet. The IPv6 access type determines whether the subnet is configured with internal IPv6 addresses or external IPv6 addresses.

• Internal IPv6 addresses are used for VM to VM communication within VPC networks. They can only be routed within the scope of VPC networks and cannot be routed to the internet.

• External IPv6 addresses can be used for VM to VM communication within VPC networks, and are also routable on the internet.

If a VM interface is connected to a subnet that has an IPv6 subnet range, you can configure IPv6 addresses on the VM. The IPv6 access type of the subnet determines whether the VM is assigned an internal IPv6 address or an external IPv6 address.

IPv6 specifications

• IPv6 subnet ranges are regional resources.

• Internal and external IPv6 subnet ranges are available in all regions.

• IPv6 subnet ranges are automatically assigned /64 ranges.

• You cannot change the IPv6 access type (internal or external) of a subnet.

• You cannot change a dual-stack subnet to single-stack, if the IPv6 access type is internal.

Internal IPv6 specifications

• Internal IPv6 ranges use unique local addresses (ULAs).

• ULAs for IPv6 are analogous to RFC 1918 addresses for IPv4. ULAs cannot be reached from the internet, and are not publicly routable.

• To create subnets with internal IPv6 ranges, you first assign an internal IPv6 range to the VPC network. A /48 IPv6 range is assigned. When you create a subnet with an internal IPv6 range, the subnet's /64 range is assigned from the VPC network's range.

  • A VPC network's internal IPv6 range is unique within Google Cloud.

  • You can let Google assign the VPC network internal IPv6 range, or you can select a specific range. If your VPC network connects to networks outside of Google Cloud, you can choose a range that does not overlap with the ranges used in those environments.

• The assignment of a VPC network's /48 internal IPv6 range is permanent. You cannot disable it or change it later.

• You can reserve static regional internal IPv6 addresses.

No other VPC networks can use the same range, which eliminates the possibility of overlapping IPv6 subnet ranges when using VPC Network Peering.

External IPv6 specifications

• External IPv6 address ranges use global unicast addresses (GUAs).

• External IPv6 addresses can be used for VM to VM communication within VPC networks, and are also routable on the internet. To control egress to and ingress from the internet, configure firewall rules or hierarchical firewall policies. To disable IPv6 routing to the internet completely, delete the IPv6 default route in the VPC network.

• External IPv6 addresses are available only in Premium Tier.

• You can reserve static regional external IPv6 addresses.

IPv6 range assignment

IPv6 ranges can be assigned to networks, subnets, and virtual machine instances (VMs).

Resource type	Range size	Details
VPC network	/48	To enable internal IPv6 on a subnet, you must first assign an internal IPv6 range on the VPC network. A /48 ULA range from within fd20::/20 is assigned to the network. All internal IPv6 subnet ranges in the network are assigned from this /48 range. The /48 range can be automatically assigned, or you can select a specific range from within fd20::/20.
Subnet	/64	The IPv6 access type setting controls whether the IPv6 addresses are internal or external. A subnet can have either internal or external IPv6 addresses, but not both. When you enable IPv6, the following occurs: If you enable internal IPv6 on a subnet, an /64 range of internal ULAs is assigned from your VPC network's /48 range. If you enable external IPv6 on a subnet, a /64 range of external GUAs is assigned.
Virtual machine instance (VM)	/96	When you enable IPv6 on a VM, the VM is assigned a /96 range from the subnet that it is connected to. The first IP address in that range is assigned to the primary interface using DHCPv6. You don't configure whether a VM gets internal or external IPv6 addresses. The VM inherits the IPv6 access type from the subnet that it is connected to.

What's next

• Create VPC networks

• Create an IPv4 only subnet

• Assign an internal IPv6 range for a VPC network

• Create a dual-stack subnet.

Try it for yourself

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

Try Cloud NAT free