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 subnets with the following stack types. A single VPC network can contain any combination of these subnets.

When you create a subnet, you specify which stack type to use. You can also change the stack type of a subnet in the following scenarios:

• If the subnet is IPv4-only, you can change it to dual-stack.
• If the subnet is dual-stack and has an external IPv6 address range, you can change it to IPv4-only.

Subnets with IPv6 address ranges are supported on custom mode VPC networks only. Subnets with IPv6 address ranges aren't supported on auto mode VPC networks or legacy networks.

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

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

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 VPC 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.

Limitations for naming subnets

Subnet names have the following limitations:

• Within a Google Cloud project, a subnet cannot have the same name as a VPC network unless it is a member of that network. Within a project, subnets in the same region must have unique names. For example, a network named production can have multiple subnets also named production as long as each of those subnets is in a unique region.

• You cannot change the name or region of a subnet after you create it. However, you can delete a subnet and replace it as long as no resources are using it.

IPv4 subnet ranges

Each IPv4-only or dual-stack subnet must have a primary IPv4 address range. When a subnet's purpose is PRIVATE or NONE, the primary IPv4 range can be used by the following:

• Primary internal IPv4 addresses of Compute Engine VM network interfaces, including GKE nodes.
• Alias IP ranges of VM network interfaces.
• Forwarding rules used by internal protocol forwarding.
• Forwarding rules used by internal Application Load Balancers, internal proxy Network Load Balancers, and internal passthrough Network Load Balancers.
• Cloud DNS inbound server policy entry points.
• Private Service Connect endpoints for published services.

Subnets can optionally have one or more secondary IPv4 address ranges, which can only be used by alias IP ranges. An alias IP range can come from either the primary IPv4 range or a secondary IPv4 range of a subnet.

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. However, the primary range of a subnet can be 10.0.0.0/24, while the primary range of another subnet in the same network can be 192.168.0.0/16.

Limitations for IPv4 subnet ranges

IPv4 subnet ranges have the following limitations:

• Each primary or secondary IPv4 range for all subnets in a VPC network must be a unique valid CIDR block.

• The number of secondary IP address ranges you can define is described in per network limits.

• After you create a subnet, the primary IPv4 range for the subnet can be expanded but not replaced or shrunk.

• You can remove and replace a subnet's secondary IPv4 address range only if no instances are using that range.

• The minimum primary or secondary range size is eight IPv4 addresses. In other words, the longest subnet mask that you can use is /29.

• The shortest subnet mask that you can use is /4. However, for most /4 IP address ranges, additional validations prevent you from creating a subnet that is this large. For example, a subnet range cannot overlap with a private IPv4 range or other reserved range. To minimize the chance of choosing an invalid subnet range, we recommend that you limit your maximum subnet size to /8.

• You can't create primary and secondary ranges for subnets that overlap with any allocated range, any primary or secondary range of another subnet in the same network, or any IPv4 ranges of subnets in peered networks. Google Cloud prevents the creation of overlapping subnet ranges in these scenarios.

• Google Cloud creates corresponding subnet routes for both primary and secondary IP ranges. Subnet routes, and therefore subnet IP ranges, must have the most specific IP ranges by definition.

  • Ensure that primary and secondary ranges don't conflict with on-premises IP ranges if you have connected your VPC network to another network with Cloud VPN, Dedicated Interconnect, or Partner Interconnect. For more information, see Check overlapping subnet ranges.

  • Subnet IPv4 ranges cannot conflict with destinations for static routes.

  • Avoid using IPv4 addresses from the 10.128.0.0/9 block for a subnet's primary or secondary IPv4 ranges. Automatically created subnets in auto mode VPC networks use IPv4 addresses from this block. If you use IP addresses in the 10.128.0.0/9 block, you cannot connect your network to an auto mode VPC network using VPC Network Peering or with Cloud VPN tunnels.

• 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.

Valid IPv4 ranges

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

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.

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.

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.

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 create a subnet with an IPv6 address range or enable IPv6 on an existing 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

Subnets with IPv6 address ranges are available in all regions, supporting both internal and external IPv6 subnet ranges:

• IPv6 subnet ranges are always automatically assigned by Google Cloud.
• IPv6 subnet ranges are always /64 ranges.

Subnets with IPv6 address ranges have the following limitations:

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

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

• You cannot change a dual-stack or IPv4-only subnet to IPv6-only (Preview). Conversely, you cannot change an IPv6-only subnet to IPv4-only or dual-stack.

Internal IPv6 specifications

Internal IPv6 ranges are 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.

Before you can create subnets with internal IPv6 ranges, you first assign a /48 ULA IPv6 range to the VPC network. Keep the following in mind when assigning a /48 ULA IPv6 range to a VPC network:

• The /48 ULA IPv6 range for each VPC network must be unique with Google Cloud. This eliminates the possibility of overlapping IPv6 subnet ranges when using VPC Network Peering.

• You can let Google Cloud assign the VPC network's /48 ULA IPv6 range automatically, or you can provide a /48 ULA IPv6 range to use. If the /48 ULA IPv6 range you provide is already used by another Google Cloud VPC network, you receive an error.

• The option to provide a /48 ULA IPv6 range is useful to avoid conflicts between your VPC network and connected on-premises networks or networks in other cloud providers.

• After a VPC network has been assigned a /48 ULA IPv6 range, you can't remove or change the /48 ULA IPv6 range.

When you create a subnet with an internal IPv6 range, Google Cloud automatically selects an unused /64 IPv6 range from the VPC network's /48 ULA IPv6 range. Subnet internal /64 IPv6 ranges can be used by the following:

• Internal /96 IPv6 address ranges of VM network interfaces

• Internal /96 IPv6 address ranges of forwarding rules for internal protocol forwarding or internal passthrough Network Load Balancers

You can also reserve static regional internal IPv6 /96 address ranges.

External IPv6 specifications

External IPv6 address ranges are global unicast addresses (GUAs). External IPv6 addresses are available only in Premium Tier.

When you create a subnet with an external IPv6 address range, Google Cloud automatically selects an unused /64 IPv6 range. Subnet external /64 IPv6 address ranges can be used by the following:

• External /96 IPv6 address ranges of VM network interfaces

• External /96 IPv6 address ranges of forwarding rules for external protocol forwarding or backend service-based external passthrough Network Load Balancers

You can also reserve static regional external IPv6 /96 address ranges.

IPv6 range assignment

IPv6 address ranges are assigned to networks, subnets, virtual machine instances (VMs), and forwarding rules.

What's next

• Learn more about Geography and regions

• Create VPC networks

• Assign an internal IPv6 range for a VPC network

• Create a subnet