Help Center/ Virtual Private Cloud/ User Guide/ VPC and Subnet/ VPC Network Planning Suggestions
Updated on 2025-09-24 GMT+08:00
View PDF

VPC Network Planning Suggestions

When deploying services in a VPC, to design a multi-layered network plan that meets current needs and supports future growth, consider the following:

Planning Regions and AZs

AZs in a region are isolated but can be interconnected through the private network. If one AZ is faulty, other AZs can still work properly. The network latency between instances in the same AZ is low, enabling faster access. You can consider the factors in Table 1 when planning regions and AZs.

Table 1 Region and AZ planning description

Key Considerations

Description

Latency

Generally, deploying services closer to users reduces latency and accelerates access. Currently, Huawei Cloud provides cloud services in a wide range of regions around the world. You can select a region based on service requirements.

Budget

Resource prices may vary by region. You can select a region based on your budget to control costs.

Regions where services are available

Some VPC functions, such as traffic mirroring, are available only in specific regions. Ensure your selected region supports the required function.

DR

If your service has high requirements on DR, you can deploy the service in different regions or in different AZs of the same region.

Compliance

When selecting a region, you need to fully consider the local laws, regulations, and compliance requirements.

Planning Accounts

After planning the regions and AZs, you can create VPC resources. During this process, you need to plan accounts based on the service size and security isolation requirements.
  • For small-size services, resources can be managed with a single account or a master-member setup. You may skip this section.
  • To manage VPC resources precisely, use IAM to create IAM user accounts and assign access permissions. Table 2 describes the account planning suggestions.
    Table 2 Account planning description

    Key Considerations

    Description

    Service organization

    Create IAM user accounts according to the service organization structure to ensure that resource access and costs of different service units are clear and controllable.

    Responsibility

    Grant only the minimum permissions required for users to perform a given task.

    Security compliance

    Create separate accounts for sensitive data or work content to ensure information security.

    Entrusted O&M

    Create a dedicated account for the O&M engineers and delegate VPC resources to them. O&M engineers perform routine O&M operations within the preset permissions of the account.

    Creating multiple accounts increases VPCs and network complexity. To balance security isolation, system stability, and network O&M complexity, you can use the VPC sharing function to simplify network configuration, improve resource management and control efficiency, and reduce O&M costs. For details, see VPC Sharing Overview.

Planning the Number of Required VPCs

You can plan the number of VPCs and subnets to maximize resource utilization and control costs.

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.

    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.

Planning the Number of Required Subnets

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.

Planning CIDR Blocks of VPCs and Subnets

Once created, the CIDR block of a VPC or subnet cannot be modified. To ensure smooth service expansion and O&M, plan your VPC and subnet CIDR blocks carefully based on 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 enough 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.

The IPv4 CIDR block you specify when you create a VPC is the primary one. The primary CIDR block cannot be changed after the VPC is created. If IP addresses in the primary CIDR block are insufficient, you can add a secondary IPv4 CIDR block to the VPC. For details, see Adding or Removing a Secondary IPv4 CIDR Block from a VPC.

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 3.
Table 3 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 these 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 4 must be excluded:
Table 4 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
  • Subnet mask planning: A subnet CIDR block must be within its VPC CIDR block. Each subnet CIDR block in a VPC must be unique. A subnet mask can be between the netmask of its VPC CIDR block and the /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 the CIDR block size: After a subnet is created, the CIDR block cannot be changed. You need to plan the CIDR block in advance based on the number of IP addresses required by your service.
    • The subnet CIDR block 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 from the VPC available for new subnets, which can be a problem when you want to scale out services.
  • Avoiding subnet CIDR block conflicts: If you need to connect two VPCs or connect a VPC to an on-premises data center, there cannot be any CIDR block conflicts.

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

Planning the Number of Required Route Tables

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 information presented here.

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

Planning Cross-VPC and Hybrid Cloud Networks

If you need to deploy a cross-VPC network or hybrid cloud network, ensure that their CIDR blocks do not conflict. The following provides typical network planning examples.

Connecting VPCs in the same region: In Figure 6, there are three VPCs (VPC-A, VPC-B, and VPC-X) in region A. 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
In Figure 7, 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 7 Connecting a VPC to an on-premises data center

Planning Network Security

You can isolate services, resources, or networks to improve VPC security. Here are some security planning suggestions based on different network architectures.

  • Intra-VPC network: If you need to deploy multiple services in the same VPC, you can create different subnets in the VPC and use security groups and network ACLs for isolation.
    As shown in Figure 8, if you need to deploy web applications that provide services for the public network, you can create two subnets. You can deploy web applications on the ECSs in Subnet-A01 that can directly communicate with the public network, and deploy internal applications such as databases in Subnet-A02 that is isolated from the public network. You can also configure different security group and network ACL rules for the two subnets to control the traffic entering and leaving the subnets.
    Figure 8 Building a secure and private cloud network
  • Cross-VPC network: If you have multiple services, you can deploy them in different VPCs for isolation. By default, VPCs are isolated from each other.

    As shown in Figure 9, if service A and service B need to be isolated, you can deploy service A in VPC-A and service B in VPC-B. By default, VPCs are isolated from each other, so resources in different VPCs cannot communicate with each other.

    Figure 9 Building a cloud network for isolating services

Planning Network DR

To plan DR capabilities for enhanced data security and stable service running, consider the following:

  • If your services have high requirements on DR, you can deploy VPCs in different regions and plan subnets in different AZs for cross-region and cross-AZ backup and DR.
    As shown in Figure 10, if your services are in multiple cities, you can use VPCs, enterprise routers, and a Cloud Connect central network to build a cross-region cloud network. Deploying services in different regions can enhance disaster recovery capabilities and ensure service availability and continuity.
    Figure 10 Building a cross-region DR network
  • If your services require high availability, you can use the following methods:
    • Use a virtual IP address and Keepalived to build a high-availability web cluster. Specifically, you can bind a virtual IP address to multiple cloud servers and use high-availability software (such as Keepalived) to build a high-availability active/standby cluster. If you want to improve service availability and eliminate single points of failure, you can deploy cloud servers in the active/standby pair or deploy one cloud server and multiple standby cloud servers. In this arrangement, the cloud servers all use the same virtual IP address. If the active cloud server goes down, the standby cloud server becomes the active one and continues to provide services.
    • To handle a large number of concurrent requests from the Internet, you can deploy multiple ECSs in a VPC and use ELB to distribute requests across these ECSs to improve service stability and availability.
      Figure 11 Building a high-availability load balancing network
  • You can use VPN or Direct Connect to connect your on-premises data center to a VPC, or connect VPCs in different regions. This helps build a high-speed and stable network connection, enabling data synchronization and DR switchover. As shown in Figure 12, you can use multiple Direct Connect connections to connect your on-premises data center to a VPC. These connections work in load balancing or active/standby mode to prevent single points of failure from affecting services.
    Figure 12 Dynamic selection and switchover between Direct Connect connections

Based on service size, expansion needs, and factors like security isolation, highly available DR, and cost, you can determine the number of required VPCs and subnets and the CIDR blocks allocated to them before creating VPCs.

Helpful Links

  • 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