If you want to use Virtual Private Cloud (VPC) to deploy your services, you need to plan networks for your VPC based on your current business requirements and expected expansion in the future. This ensures that your current services can run as expected and allows business growth.
To ensure service stability and network scalability, you need to consider security isolation, disaster recovery, and O&M costs. Improperly designed networks are not suitable for future business growth and may even bring unexpected risks. If the existing network architecture does not meet your business growth requirements, network reconstruction will cause high costs and may affect your current business. Therefore, it is essential to properly design your networks from multiple levels and dimensions. To ensure network stability and scalability, you can perform the following steps to plan your VPC.
Region and zone planning
Instances in different zones within a region can communicate with each other. Even if one zone is down, other zones can work as expected. The network latency between instances in the same zone is low. You can plan regions and zones based on the following information.
Item | Description |
Latency requirement | If user locations are close to the regions where the resources are deployed, the network latency is low and the access is fast. |
Supported regions and zones | Different Alibaba Cloud services are supported by different regions and zones. You can select a zone and a region based on the service that you require. |
Cost | The price of a cloud service may vary with the region. We recommend that you select a region based on your requirements. |
High availability and disaster recovery | If your services require high disaster recovery capabilities, you can deploy your services in different zones within the same region. You can also deploy your services in multiple regions to implement inter-region disaster recovery. |
Compliance | You need to select a region that meets the data compliance requirements and business filing policies of your country or region. |
A VPC cannot be deployed across regions. If you want to deploy your services across regions, you must create a VPC in each region. You can use VPC peering connections or Cloud Enterprise Network (CEN) to enable communication among VPCs in different regions. vSwitches are zone-level resources. When you use vSwitches, take note of the following information:
If you select multiple zones due to the Elastic Compute Service (ECS) inventory factor, you need to reserve sufficient CIDR blocks in advance and take into account the latency increase caused by traffic detours between zones.
Some regions provide only one zone, such as China (Nanjing - Local Region). If you have requirements for intra-region disaster recovery, we recommend that you cautiously consider selecting this region.
Account and VPC planning
After you plan the regions and zones, you can create VPC resources. In this process, you need to consider your business scale and security isolation requirements for account planning, VPC planning, and vSwitch planning. This optimizes resource usage and reduces costs.
Account planning
If your business scale is small, you can use one Alibaba Cloud account or one RAM user to manage resources. In this case, you can skip this section. When your business scale increases, you need to plan accounts based on the user permissions and security isolation requirements.
Item | Description |
Department isolation | We recommend that you create independent accounts for different business departments to facilitate management for resources, costs, and permissions. If your project requires specific resources and permissions, we recommend that you create an independent account for the project. |
System isolation | If your business has isolation requirements, such as isolation between the production environment and staging environment, you can create independent accounts. |
Security compliance | To meet specific security compliance requirements, we recommend that you keep sensitive data or workloads to independent accounts. |
Bill management | You can use multiple accounts to isolate resources. This facilitates cost tracking and billing management. |
Log management and O&M | You can use an independent account to store log data of all accounts. This facilitates security auditing. |
The network complexity increases as the numbers of VPCs and accounts increase. You can use the VPC sharing feature to reduce network complexity while maintaining network security and stability.
VPC quantity planning
VPC provides a secure and flexible network environment in the cloud. Different VPCs are isolated from each other. Instances in a VPC can communicate with each other. You can plan the number of your VPCs based on your business requirements.
Scenarios | |
One VPC |
 |
Multiple VPCs |
We recommend that you use multiple VPCs in the following scenarios:
|
By default, you can create at most 10 VPCs in each region. You can go to the Quota Management page or Quota Center page to request a quota increase.
vSwitch quantity planning
vSwitches are zone-level resources. All instances in VPCs are deployed in vSwitches. vSwitch division helps you properly plan IP addresses. vSwitches in a VPC can communicate with each other by default.
Item | Description |
Latency | The latency between zones in the same region is low. However, complex system calls and cross-zone calls may increase the latency. |
High availability and disaster recovery | We recommend that you create at least two vSwitches in a VPC and deploy the vSwitches in different zones to implement cross-zone disaster recovery. You can deploy services in multiple zones and configure security rules in a unified manner. This improves the system availability and disaster recovery capability. |
Business scale and division | Typically, you can deploy different service modules in different vSwitches. For example, you can deploy the web layer, logic layer, and data layer in different vSwitches to create a standard web architecture. |
You can plan vSwitches based on the following information:
When you use a VPC, we recommend that you deploy at least two vSwitches in different zones. This way, when one vSwitch is down, the other vSwitch in another zone can take over, which implements cross-zone disaster recovery.
The latency between zones in the same region is low. However, the latency needs to be adapted and verified by the business system. The network latency may be increased due to the complex network topology. We recommend that you optimize and adapt the system to meet your requirements for high availability and low latency.
In addition, the scale and planning of your service system must also be taken into consideration when you determine the number of vSwitches to be created. In normal cases, you can plan vSwitches based on your business attributes. For example, Internet services need to deployed in a public vSwitch, and other services can be deployed accordingly. After your services are deployed in multiple zones, you can configure security policies in a unified manner.
By default, you can create at most 150 vSwitches in each VPC. You can go to the Quota Management page or Quota Center page to request a quota increase.
CIDR block planning
When you create a VPC and vSwitch, you need to specify the VPC CIDR block and the vSwitch CIDR block. The size of the CIDR block determines the amount of resources that can be deployed. Proper CIDR block planning avoids address conflicts and ensures the network scalability, whereas improper planning may cause high costs for network reconstruction.
After you specify a vSwitch CIDR block, you cannot modify it.
If the address space is insufficient due to improper planning, you can add secondary CIDR blocks to expand the address space. You cannot modify secondary CIDR blocks.
We provide the following suggestions for planning VPC CIDR blocks and vSwitch CIDR blocks:
We recommend that you use private IPv4 CIDR blocks defined by RFC 1918 and use the /16 network mask for VPC. To expand a VPC address space, we recommend that you add secondary CIDR blocks to the VPC.
If you deploy your services in one VPC, we recommend that you use a large-size network mask to reserve sufficient addresses for later use.
We recommend that you avoid CIDR block overlap when you plan CIDR blocks for VPCs.
We also recommend that you avoid CIDR block overlap when you plan zones for disaster recovery.
As the network scale increases, CIDR block planning becomes more complex and difficult. You can use IP Address Manager (IPAM) to automatically assign IP addresses and detect potential IP address conflicts. This improves the efficiency of CIDR block planning. For more information, see IP Address Manager (IPAM).
We provide the following suggestions on using IPAM:
Design different IPAM pools for different environments, such as the development environment, and the production environment.
When you use IPAM pools to allocate private CIDR blocks to VPCs, make sure that the CIDR blocks do not overlap with each other.
You can view the information about VPC CIDR blocks and address usage by using IPAM.
VPC CIDR block planning
You can use the standard RFC CIDR blocks: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, or their subsets as the VPC CIDR blocks. You can also specify custom VPC CIDR blocks.
VPC CIDR block | IP address range | Mask range | VPC CIDR block example |
|
| 8 to 24 |
|
|
| 12 to 24 |
|
|
| 16 to 24 |
|
When you specify CIDR blocks for VPCs, take note of the following rules:
If you have only one VPC and the VPC does not need to communicate with a data center, you can specify one of the RFC CIDR blocks or their subsets as the VPC CIDR block.
If you have multiple VPCs or want to set up a hybrid cloud environment between a VPC and your data center, we recommend that you specify the subsets of the RFC CIDR blocks for your VPCs. In this case, we recommend that you set the subnet mask length to 16 bits or less. Make sure that the CIDR blocks of the VPCs and your data center do not overlap.
You cannot specify
100.64.0.0/10,224.0.0.0/4,127.0.0.0/8,169.254.0.0/16, or one of their subsets as the custom CIDR block.You must check whether a classic network is used before you specify a CIDR block for your VPC. If the classic network is used and you want to connect ECS instances in the classic network to your VPC, do not specify
10.0.0.0/8as the VPC CIDR block because the CIDR block of the classic network is10.0.0.0/8.You can use IPAM to plan pools and specify a default network mask for allocations. You can also view the address usage of a VPC by using IPAM.
vSwitch CIDR block planning
The CIDR block of a vSwitch must be a subset of the CIDR block of the VPC to which the vSwitch belongs. For example, if the CIDR block of the VPC is 192.168.0.0/24, the network mask of vSwitches in the VPC must be /25 to /29.
When you specify CIDR blocks for vSwitches, take note of the following limits:
The network mask of the IPv4 CIDR block for a vSwitch must be /16 to /29, which can provide 8 to 65,536 IP addresses.
Make sure that the vSwitch CIDR block is different from the VPC CIDR block.
When you plan the CIDR block of a vSwitch, you need to consider the number of ECS instances and other cloud resources that can be allocated to the vSwitch. We recommend that you specify a large CIDR block to reserve sufficient IP addresses for later use. However, if the CIDR block is too large, you cannot expand it. If a VPC CIDR block is
10.0.0.0/16, the VPC supports 65,536 IP addresses. Because ECS instances and ApsaraDB RDS instances need to be deployed in vSwitches, we recommend that you specify/24as the vSwitch network mask, which supports 256 IP addresses. A VPC with a CIDR block of10.0.0.0/16can be divided into at most 256 vSwitches with a mask of /24. You can make appropriate adjustments based on the preceding suggestions.If a vSwitch is assigned an IPv4 CIDR block, the first IPv4 address and last three IPv4 addresses are reserved by the system. If a vSwitch is assigned an IPv6 CIDR block, the first IPv6 address and last three IPv6 addresses are reserved by the system. The following table provides an example.
vSwitch CIDR block
Reserved IP addresses
IPv4 CIDR block
192.168.1.0/24192.168.1.0192.168.1.253192.168.1.254192.168.1.255IPv6 CIDR block
2001:XXXX:XXXX:1a00/642001:XXXX:XXXX:1a00::2001:XXXX:XXXX:1a00:ffff:ffff:ffff:fff72001:XXXX:XXXX:1a00:ffff:ffff:ffff:fff82001:XXXX:XXXX:1a00:ffff:ffff:ffff:fff92001:XXXX:XXXX:1a00:ffff:ffff:ffff:fffa2001:XXXX:XXXX:1a00:ffff:ffff:ffff:fffb2001:XXXX:XXXX:1a00:ffff:ffff:ffff:fffc2001:XXXX:XXXX:1a00:ffff:ffff:ffff:fffd2001:XXXX:XXXX:1a00:ffff:ffff:ffff:fffe2001:XXXX:XXXX:1a00:ffff:ffff:ffff:ffffIf multiple VPCs are deployed and a vSwitch needs to communicate with another vSwitch in a different VPC or a data center, make sure that the vSwitch CIDR block does not overlap with the peer CIDR block. Otherwise, communication fails.
The ClassicLink feature allows ECS instances in the classic network to communicate with ECS instances in a VPC whose CIDR block is
10.0.0.0/8,172.16.0.0/12, or192.168.0.0/16. If the CIDR block of the VPC to communicate with the classic network is10.0.0.0/8, the CIDR block of the vSwitch that belongs to the VPC must be10.111.0.0/16. For more information, see Overview of ClassicLink.
Route table planning
A route table consists of routes. A route consists of the destination CIDR block, next hop type, and next hop. Routes are used to forward traffic to specific destinations. Each VPC can contain a maximum of 10 route tables, including the system route table. You can refer to the following suggestions to plan the number of route tables.
Use one route table
If the traffic paths of vSwitches are not significantly different, you can use one route table. After you create a VPC, the system automatically creates a system route table and adds system routes to the table. You cannot create or delete a system route table. However, you can create custom routes in a system route table to route traffic to specific destinations.
Use multiple route tables
If the traffic paths of vSwitches are significantly different, for example, you need to control Internet access for some instances, you can use multiple route tables. You can deploy public vSwitches and private vSwitches. Instances in private vSwitches can use an Internet NAT gateway to access the Internet. This ensures unified control for Internet access and meets isolation requirements.
Each VPC supports at most nine custom route tables. You can go to the Quota Management or Quota Center page to request a quota increase.
Network connection planning
Alibaba Cloud provides a secure and scalable cloud network and supports high-speed and secure connections between the cloud and data centers. You can use a VPC to access the Internet, another VPC, and a data center. You can use VPC and other services for networking based on your requirements.
Internet access
We provide the following suggestions on communication with the Internet:
If your service deployed in an ECS instance needs to communicate with the Internet, you need to configure a public IP address for the ECS instance. The public IP address can be a static public IP address or an elastic IP address (EIP). We recommend that you associate an EIP with the ECS instance.
If only one ECS instance is used to provide services over the Internet, a single point of failure (SPOF) may occur, which affects the system availability. In actual scenarios, we recommend that you use a Server Load Balancer (SLB) instance as the unified Internet traffic ingress and associate multiple ECS instances with the SLB instance. This prevents SPOFs and improves service availability.
If multiple ECS instances need to access the Internet, you can use the SNAT feature of an Internet NAT gateway to allow the ECS instances share EIPs to access the Internet. This saves public IP address resources.
If your ECS instances provide services over the Internet, you can use IPv4 gateways and IPv6 gateways to manage Internet access for the ECS instances in a unified manner.
Cross-VPC connection
You can use the following services to enable communication among VPCs.
If you use a small number of VPCs (generally no more than five), you can use VPC peering connections to enable communication between VPCs.
If your network architecture is complex and use many VPCs, you can use CEN to manage VPCs in a efficient and unified way. This facilitates O&M and ensures secure data transmission.
When you access an Alibaba Cloud service such as Object Storage Service (OSS) through the Internet, sensitive data may be leaked. To prevent data leakage, you can use PrivateLink to connect the VPC where the endpoint resides to the VPC where the endpoint service resides. This minimizes security risks when you access services over the Internet.
You can also use a VPN gateway to establish a secure connection between two VPCs, but the network latency is high.
Hybrid cloud deployment
You can use the following services to connect a data center to a VPC to build a hybrid cloud.
If you require high security and low latency, you can use Express Connect circuits to connect your data center to a VPC.
If you want to reduce costs, you can use a VPN gateway to connect your data center to a VPC through an encrypted tunnel.
What are the requirements for cross-VPC connections and hybrid cloud deployment?
If you want to connect a VPC to another VPC or a data center, make sure that the CIDR blocks do not overlap with each other. Take note of the following rules when you plan CIDR blocks:
You can use subnets of standard CIDR blocks to increase the available number of CIDR blocks supported by a VPC. We recommend that you specify non-overlapping CIDR blocks for different VPCs.
If you cannot ensure non-overlapping CIDR blocks for different VPCs, we recommend that you configure non-overlapping CIDR blocks for vSwitches in different VPCs.
If you cannot ensure non-overlapping CIDR blocks for vSwitches in different VPCs, we recommend that you configure non-overlapping CIDR blocks for vSwitches that need to communicate with each other.
The following figure describes a scenario where VPC1, VPC2, and VPC3 are deployed in the China (Hangzhou), China (Beijing), and China (Shenzhen) regions. VPC1 and VPC2 communicate with each other through VPC peering connections. Currently, VPC3 does not need to communicate with other VPCs. However, VPC3 may need to communicate with VPC2 in the future. In addition, a data center in China (Hangzhou) needs to communicate with VPC1 in the same region through Express Connect circuits. Currently, VPC3 does not need to communicate with other VPCs. However, we still recommend that you configure non-overlapping CIDR blocks for each VPC for further business expansion.
You can create three regional pools in an IPAM pool to ensure that sufficient IP addresses can be assigned in each region. You need to create a custom allocation and mark that 10.0.2.0/24 is dedicated to the data center. This prevents IP address conflicts and ensures that the IP addresses will not be misused.
Security planning
Security isolation includes service isolation, resource isolation, and network isolation. You need to consider security isolation requirements when you plan regions, zones, accounts, and CIDR blocks. Creating RAM users can isolate resources and creating vSwitches for a VPC can isolate networks. Resource isolation and network isolation are methods to implement service isolation. You can implement isolation based on your requirements.
Security layer | Suggestion |
Within VPC | If you deploy multiple services in a VPC, we recommend that you create a vSwitch for each service and use security groups and network ACLs to implement security isolation. |
VPC border |
|
You can use the flow log feature and the traffic mirroring feature to monitor VPCs and troubleshoot issues. This improves the system stability and reliability.
Monitoring information | Description |
Flow log | You can use the flow log feature to collect traffic data and analyze traffic logs to optimize bandwidth and reduce network bottlenecks. |
Traffic mirroring | The traffic mirroring feature can mirror specific packets that go through ENIs and can be used for content inspection, threat monitoring, and troubleshooting. |
Disaster recovery planning
You can plan disaster recovery based on your service architecture to ensure data security and service availability.
If you have high requirements for disaster recovery, you can deploy VPCs in different regions and deploy vSwitches in different zones. This implements cross-region and cross-zone disaster recovery.
If your service requires fast response, high concurrency, and enhanced data security, you can use SLB to implement cluster recovery, session persistence, and cross-zone deployment.
If you need to connect your data centers to VPCs through high-speed and stable connections, you can use Express Connect circuits. This ensures data synchronization, prevents SPOFs, and improves service availability.
If you have high requirements for service availability, you can use the high-availability virtual IP address (HAVIP) feature together with Keepalived or Heartbeat to create a high-availability network architecture. This ensures that service IP addresses remain unchanged during switchover and improves service availability.
You can focus on the disaster recovery capability of cloud services. For example, ApsaraDB RDS uses the active/standby architecture. Active endpoints and standby endpoints can be deployed in the same zone or different zones in a region. If you want to improve service availability, you can deploy endpoints in different zones to implement cross-zone disaster recovery.
The following figure shows how to upgrade a single-zone architecture to an active/standby architecture, which provides higher security and availability.
Before you create a VPC, make sure that you take the following items into account: current business scale and future expansion, security isolation, service availability and disaster recovery, costs, numbers of VPCs and vSwitches, and CIDR blocks allocated to VPCs and vSwitches. For more information, see Create and manage a VPC.