When using virtual private cloud (VPC) to deploy your services, you must plan networks for your VPC based on your current needs and potential expansion. This ensures that your services run as expected and allows business growth.
Consider secure isolation, disaster recovery, and O&M costs to ensure stability and scalability. Improperly designed networks may bring unexpected risks to your business. When the network architecture does not keep pace with business expansion and scaling requirements, rebuilding it would be both costly and disruptive. That is why it is essential to design your networks from multiple levels and dimensions. 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 work as expected. Instances within the same zone has lower latency, leading to faster access. Plan regions and zones based on the following information.
Item | Description |
Latency | Shorter distances between users and resource locations mean lower latency and better performance. |
Supported regions and zones | Different Alibaba Cloud services are available in different regions and zones and their inventory vary. Select a zone and a region based on your services. |
Cost | The price of a cloud service may vary by region. We recommend selecting a region based on your budget. |
High availability and disaster recovery | For services requiring high disaster recovery capabilities, deploy your services across zones within the same region. You can also deploy your services in multiple regions to realize inter-region disaster recovery. |
Compliance | 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. To deploy your services across regions, you must create a VPC in each region and use VPC peering connections or Cloud Enterprise Network (CEN) to enable inter-VPC communication. vSwitches are zone-level resources. vSwitches are zone-level resources. Take note of the following:
If you select multiple zones due to the Elastic Compute Service (ECS) inventory limit, reserve sufficient CIDR blocks and note that latency increases when traffic detours between zones.
Some regions have only one zone, such as China (Nanjing - Local Region) Closing Down. If you have intra-region disaster recovery needs, we recommend careful consideration before selecting these regions.
Account and VPC planning
After planning the regions and zones, you can start creating VPC. Consider your business scale and security isolation when planning accounts, VPC, and vSwitch to enhance resource usage and reduce costs.
Account planning
For smaller businesses, use one Alibaba Cloud account or RAM accounts to manage resources. In this case, you can skip this section. When your scale increases, you must plan accounts based on permissions and security isolation requirements.
Item | Description |
Permission isolation | Create individual accounts for each department to isolate resources, costs, and permissions. For large projects or applications with special requirements, use separate accounts for better control. |
System isolation | For systems requiring strict isolation, such as production and test environments, use dedicated accounts to reduce cross-environment risks. |
Security compliance | For enhanced security compliance, maintain sensitive data and workloads in separate, isolated accounts. |
Bill management | Use multiple accounts to isolate resources. This facilitates cost tracking and billing management. |
Logs and O&M | Use an independent account to store log data of all accounts to facilitate security auditing. |
The network complexity increases with the numbers of VPCs and accounts. Use the Shared VPC feature to reduce complexity while maintaining network security and stability.
VPC planning
VPC provides a secure and flexible network environment in the cloud where VPCs are isolated from each other and instance in a VPC can communicate with each other. Plan the number of your VPCs according to your needs.
Scenarios | |
One VPC |
 |
Multiple VPCs |
We recommend using multiple VPCs in the following scenarios:
|
By default, you can create at most 10 VPCs in each region. To request a quota increase, go to the Quota Management page or Quota Center page.
vSwitch planning
vSwitches are zone-level resources that host all cloud services within a VPC. Creating vSwitches helps you properly plan IP addresses. All 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 creating at least two vSwitches in a VPC and deploy the vSwitches across zones for cross-zone disaster recovery. You can deploy services in multiple zones and centrally configure security rules. This enhances the system availability and disaster recovery. |
Business scale and division | Create vSwitches by business modules. For example, you can deploy the web layer, logic layer, and data layer in different vSwitches to create a standard web architecture. |
Plan your vSwitches based on the following information:
Create at least two vSwitches and deploy them across zones for failover capability. When one vSwitch is down, the other takes over and realizes cross-zone disaster recovery.
The latency between zones in the same region is theoretically low. However, the actual latency needs to be verified. The network latency may increase due to the complex network topology and cross-zone calls. We recommend enhancing and validating your architecture to balance both high availability and low latency.
The number of vSwitches required depends on your system scale and architecture design. Typically, create vSwitches based on business modules. For example, deploy public-facing services in a public vSwitch. Deploying services across zones facilitates centralized security policy configuration and governance.
By default, you can create at most 150 vSwitches in each VPC. To request a quota increase, go to the Quota Management page or Quota Center page.
CIDR block planning
When you create a VPC and vSwitch, you must specify the VPC and 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 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, add secondary CIDR blocks to expand the address space. You cannot modify secondary CIDR blocks.
Take note of the following when planning CIDR blocks:
Use private IPv4 CIDR blocks defined by RFC 1918 with a mask length of 16. To expand the address space for a VPC, add secondary CIDR blocks.
If you deploy your services in one VPC, use a large network mask to reserve sufficient addresses.
Avoid CIDR block overlap when you create multiple VPCs for your business.
Avoid CIDR block overlap when you create multiple 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, and thus improving the efficiency of CIDR block planning. For more information, see IPAM.
Take note of the following when using IPAM:
Design different IPAM pools for different environments, such as development environment and production environment.
When you use IPAM pools to allocate private CIDR blocks to VPCs, make sure the VPC CIDR blocks do not overlap with each other.
View the information about VPC CIDR blocks and address usage in the IPAM console.
VPC CIDR block planning
We recommend using private IPv4 addresses specified in the RFC 1918 standard for the secondary IPv4 CIDR blocks, with subnet masks of 16 to 28 bits, such as 10.0.0.0/16, 172.16.0.0/16, 192.168.0.0/16. You can also specify custom VPC CIDR blocks.
VPC CIDR block | IP address range |
|
|
|
|
|
|
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 planning the network properly before creation. Make sure that the CIDR blocks of different VPCs or those 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 nine 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 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. To increase the quota, go to the Quota Management or Quota Center page.
Network connection planning
Alibaba Cloud provides a securely isolated and elastically scalable cloud network and supports fast connections between the cloud and data centers. You can use a VPC to access the Internet, another VPC, and a data center. Combine VPC with other services for network connectivity tailored to your business.
Internet access
Take note of the following suggestions on communication with the Internet:
If your service deployed in an ECS instance needs to access the Internet, 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 will affect the system availability. 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, use the SNAT feature of an Internet NAT gateway to allow the ECS instances to share EIPs and access the Internet. This saves public IP addresses.
If your ECS instances provide services over the Internet, use the IPv4 gateway or IPv6 gateway to manage Internet access for the ECS instances in a unified manner.
Cross-VPC connection
You can use the following services to enable connectivity among VPCs.
If you use a small number of VPCs (generally no more than five), use VPC peering connections to enable connectivity between VPCs.
If your network architecture is complex with many VPCs, use CEN to efficiently manage VPCs, facilitate O&M and ensure secure data transfer.
When you access an Alibaba Cloud service such as Object Storage Service (OSS) over the Internet, sensitive data may be leaked. Use PrivateLink to connect the VPC where the endpoint resides and the VPC where the endpoint service resides, reducing security risks.
Use a VPN gateway to establish a secure connection between two VPCs, but the network latency is high.
Hybrid cloud
You can use the following services to connect a data center to a VPC, building a hybrid cloud.
If you require high security and low latency, use Express Connect circuits to connect your data center to a VPC.
If you want to reduce costs, 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?
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 the VPC peering connection. VPC3 currently has no connection requirements but may need to connect with VPC2 in the future. Additionally, a data center in China (Hangzhou) connects to VPC1 in the same region through an Express Connect circuit. Although VPC3 does not require cross-VPC connectivity, we recommend maintaining non-overlapping CIDR blocks across all VPCs to accommodate future expansion.
You can create three regional pools in an IPAM pool to ensure that sufficient IP addresses can be assigned in each region. Create a custom allocation and allocate 10.0.2.0/24 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 mirror feature to monitor VPCs and troubleshoot issues. This improves the system stability and reliability.
Metric | Description |
Flow log | Collect traffic data and analyze traffic logs to optimize bandwidth and remove network bottlenecks. |
Traffic mirror | Mirror specific packets that go through ENIs 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, deploy VPCs across regions and deploy vSwitches across zones for disaster recovery.
If your service requires fast response, high concurrency, and enhanced data security, use SLB to implement cluster recovery, session persistence, and cross-zone deployment.
If you need to connect your data centers to VPCs through fast and stable connections, Express Connect circuits. This ensures data synchronization, prevents SPOFs, and improves service availability.
If you have high requirements for service availability, use the high-availability virtual IP address (HaVip) feature together with Keepalived or Heartbeat to create a high-availability architecture. This ensures that service IP addresses remain unchanged during switchover and improves availability.
You can achieve the disaster recovery capability of cloud services. For example, RDS uses the active/standby architecture. Active and standby endpoints can be deployed in the same zone or different zones in a region. To improve availability and disaster recovery, you can deploy endpoints across zones.
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.