Help Center/ Virtual Private Cloud/ User Guide/ VPC and Subnet/ VPC and Subnet Planning
Updated on 2024-08-07 GMT+08:00
View PDF
Share

VPC and Subnet Planning

Before using VPCs and subnets to build cloud networks, determine how many VPCs and subnets do you need and plan the necessary CIDR blocks and connectivity options. If you need to connect different VPCs or connect a VPC to an on-premises data center, ensure that their CIDR blocks do not conflict. Properly plan your VPCs and subnets based on the guidelines provided here to avoid CIDR block conflicts, which will make future network expansion easier.

How Do I Determine How Many VPCs I Need?

VPCs are region-specific. Cloud resources, such as ECSs, CCEs, and RDS instances, in a VPC must be in the same region as the VPC. By default, different VPCs are isolated from each other, but the subnets in a VPC can communicate with each other.

If your services are deployed in one region and do not have to handle a lot of traffic, you may not need network isolation. In this case, a single VPC should be enough.

You can create multiple subnets in a VPC for workloads with different requirements and associate route tables with these subnets to control traffic in and out of the subnets. In Figure 1, services are deployed on different subnets in a VPC (VPC-A in this example).

Figure 1 Planning a single VPC

You need to plan multiple VPCs if you have:

  • Services that need to be deployed in different regions

    VPC is a region-specific service, so services cannot be deployed across regions in a VPC. If your services are deployed in multiple regions, plan at least one VPC in each region.

    VPCs are isolated from each other. You can use:

    In Figure 2, some services are deployed in VPC-A in region A, and some are deployed in VPC-B in region B. A cloud connection is used to connect VPC-A and VPC-B.

    Figure 2 Planning multiple VPCs
  • Services that are deployed in the same region but need network isolation.
    If your services are deployed in the same region but need network isolation, you need to plan multiple VPCs in this region. Different VPCs are isolated from each other, so you can deploy different services in different VPCs, as shown in Figure 3. In the figure, some services are deployed in VPC-A, and some are deployed in VPC-B. The two VPCs are isolated from each other.
    Figure 3 Planning multiple VPCs

By default, you can create a maximum of five VPCs in each region. If this cannot meet your service requirements, request a quota increase.

How Do I Determine How Many Subnets I Need?

A subnet is a unique CIDR block with a range of IP addresses in a VPC. All cloud resources in a VPC must be deployed on subnets.

You can create different subnets for different services in a VPC. For example, you can create three subnets in a VPC, one subnet for web services, one for management services, and the third one for data services. Additionally, you can use network ACLs to control access to each subnet.

Note the following when selecting subnets and AZs for your resources:
  • All instances in different subnets of the same VPC can communicate with each other by default, and the subnets can be located in different AZs. If you have a VPC with two subnets in it and they are located in different AZs, they can communicate with each other by default.
  • A cloud resource can be in a different AZ from its subnet. For example, a cloud server in AZ 1 can be in a subnet in AZ 3. If AZ 3 becomes faulty, cloud servers in AZ 1 can still use the subnet in AZ 3, and your services are not interrupted.

By default, you can create a maximum of 100 subnets in each region. If this cannot meet your service requirements, request a quota increase.

How Do I Plan CIDR Blocks for VPCs and Subnets?

After VPCs and subnets are created, their CIDR blocks cannot be changed. To ensure smooth service expansion and O&M, properly plan VPC and subnet CIDR blocks that best suit your service size and communication requirements.

Both IPv4 and IPv6 CIDR blocks can be assigned to a subnet. You can customize IPv4 CIDR blocks but not IPv6 CIDR blocks. The system assigns an IPv6 CIDR block with a 64-bit mask to each subnet, for example, 2407:c080:802:1b32::/64.

When creating a VPC, you need to specify an IPv4 CIDR block for it. Consider the following when selecting a CIDR block:
  • Reserve sufficient IP addresses for subsequent service expansion.
  • Avoid CIDR block conflicts. To enable communications between VPCs or between a VPC and an on-premises data center, ensure their CIDR blocks do not overlap.

When you create a VPC, you specify a primary IPv4 CIDR block for the VPC, which cannot be changed. You can add a secondary IPv4 CIDR block to the VPC if required.

When you create a VPC, we recommend that you use the private IPv4 address ranges specified in RFC 1918 as the CIDR block, as described in Table 1.
Table 1 VPC CIDR blocks (RFC 1918)

VPC CIDR Block

IP Address Range

Netmask

Example CIDR Block

10.0.0.0/8-24

10.0.0.0–10.255.255.255

8-24

10.0.0.0/8

172.16.0.0/12-24

172.16.0.0–172.31.255.255

12-24

172.30.0.0/16

192.168.0.0/16-24

192.168.0.0–192.168.255.255

16-24

192.168.0.0/24
In addition to the preceding addresses, you can create a VPC with a publicly routable CIDR block that falls outside of the private IPv4 address ranges specified in RFC 1918. However, the reserved system and public CIDR blocks listed in Table 2 must be excluded:
Table 2 Reserved system and public CIDR blocks

Reserved System CIDR Blocks

Reserved Public CIDR Blocks
  • 100.64.0.0/10
  • 214.0.0.0/7
  • 198.18.0.0/15
  • 169.254.0.0/16
  • 0.0.0.0/8
  • 127.0.0.0/8
  • 240.0.0.0/4
  • 255.255.255.255/32
  • Subnet mask planning: The subnet CIDR block must be within the VPC CIDR block. Subnet CIDR blocks in a VPC must be unique. A subnet mask can be between the netmask of its VPC CIDR block and a /29 netmask. If a VPC CIDR block is 10.0.0.0/16, its subnet mask can be anything from 16 to 29.

    For example, if the CIDR block of a VPC is 10.0.0.0/16, you can specify 10.0.0.0/24 for a subnet in this VPC, 10.0.1.0/24 for the second subnet, and 10.0.2.0/24 for the third subnet.

  • Planning CIDR block size: After a subnet is created, the CIDR block cannot be changed. You need to properly plan the CIDR block in advance based on the number of IP addresses required by your service.
    • The subnet CIDR block size cannot be too small. Ensure that the number of available IP addresses in the subnet meets service requirements. Remember that the first and last three addresses in a subnet CIDR block are reserved for system use. For example, in subnet 10.0.0.0/24, 10.0.0.1 is the gateway address, 10.0.0.253 is the system interface address, 10.0.0.254 is used by DHCP, and 10.0.0.255 is the broadcast address.
    • The subnet CIDR block cannot be too large, either. If you use a CIDR block that is too large, you may not have enough CIDR blocks available later for new subnets, which can be a problem when you want to scale out services.
  • Avoiding subnet CIDR block conflicts: Avoid CIDR block conflicts if you need to connect two VPCs or connect a VPC to an on-premises data center.

    If the subnet CIDR blocks at both ends of the network conflict, create a subnet.

How Do I Plan How Many Route Tables I Need?

A route table contains a set of routes that are used to control the traffic in and out of your subnets in a VPC. You can configure destination, next hop, and other information for each route. A VPC can have multiple route tables. Plan route tables based on the following sections.

If you have the same or similar requirements for controlling the network traffic to and from subnets in a VPC, you can create one route table and associate it with these subnets in this VPC. Each VPC comes with a default route table. If you create a subnet in the VPC, the subnet is associated with the default route table. You can add routes to the default route table to control where the traffic is directed. In Figure 4, VPC-A has only the default route table, and subnets Subnet-A01 and Subnet-A02 are associated with the default route table.
Figure 4 Planning one route table
If you have different requirements for controlling the network traffic to and from subnets in a VPC, the default route table is not enough. You can create one or more custom route tables and associate them with these subnets in this VPC. In Figure 5, VPC-A has three route tables. Subnet-A01 is associated with default route table 1, Subnet-A02 is associated with custom route table 2, and Subnet-A03 is associated with custom route table 3.
Figure 5 Planning multiple route tables

How Do I Connect Two VPC or Connect a VPC to an On-premises Data Center?

If you need to connect two VPCs or connect a VPC to an on-premises data center, ensure that their VPC CIDR blocks do not conflict.

  • Connecting VPCs in the same region: In Figure 6, there are three VPCs in region A: VPC-A, VPC-B, and VPC-X. If you want to connect VPC-A and VPC-B, but isolate VPC-C from other VPCs:
    • Ensure that the CIDR blocks of VPC-A and VPC-B connected by a peering connection (Peering-AB in this example) must be unique.
    • You do not need to worry about VPC CIDR block conflicts because VPC-X does not need to communicate with other VPCs. If VPC-X and VPC-B need to communicate with each other, you can specify different CIDR blocks for the subnets in the two VPCs and create a VPC peering connection to connect the subnets.
    Figure 6 Connecting VPCs in the same region
  • Connecting VPCs in different regions: In Figure 7, services are deployed in four VPCs in different regions: VPC-A, VPC-B, VPC-CA, and VPC-CB. You can use a cloud connection to connect these VPCs in different regions and ensure that the CIDR blocks of the four VPCs do not conflict.
    Figure 7 Connecting VPCs in different regions
In Figure 8, VPC-A and VPC-B in region A need to communicate with each other, and VPC-A needs to connect to on-premises data center IDC-A. In region C, VPC-C needs to connect to on-premises data center IDC-C.
  • In region A, VPC-A and VPC-B have different CIDR blocks and can communicate with each other through a VPC peering connection. VPC-A and IDC-A have different CIDR blocks and are connected through a direct connection.
  • In region C, VPC-C and IDC-C have different CIDR blocks and are connected through a VPC connection.
Figure 8 Connecting a VPC to an on-premises data center

Helpful Link

  • You can create a VPC and an ECS to set up an IPv4 private network on the cloud and then bind an EIP to the ECS to allow the ECS to access the Internet. For details, see Setting Up an IPv4 Network in a VPC.
  • You can create a VPC with an IPv4 and IPv6 CIDR block and create an ECS with both IPv4 and IPv6 addresses in the VPC. You can bind an EIP and add the IPv6 address of the ECS to a shared bandwidth to enable the ECS to communicate with the Internet over both IPv4 and IPv6 networks. For details, see Setting Up an IPv4/IPv6 Dual-Stack Network in a VPC.
Parent Topic: VPC and Subnet