When deploying your services in a virtual private cloud (VPC), plan your network based on your current needs and future growth projections. This ensures your network meets current demands while supporting business growth.
To plan your network, consider secure isolation, disaster recovery, and O&M costs. A forward-looking plan ensures business stability and network scalability, while a network design that lacks foresight may hinder future expansion and introduce unforeseen risks. Re-building an existing network is costly and disruptive. Therefore, a comprehensive, multi-faceted network plan is crucial.
Perform the following steps to plan your VPC:
Plan regions and zones
Within a region, all zones communicate over the internal network. Each zone is isolated from failures in other zones. If one zone fails, the others continue to operate normally. Instances deployed within the same zone have lower network latency for faster user access.
Consideration | Description |
Latency | Deploying resources closer to your end-users reduces network latency and improves access speed. |
Service availability | Alibaba Cloud services vary in availability across regions and zones. Ensure that your required cloud services are available in the selected regions and zones. |
Cost | The price of a cloud service may vary by region. We recommend selecting a region that fits your budget. |
High availability and disaster recovery | For services requiring high disaster recovery capabilities, deploy them across zones within the same region. You can also deploy your services across regions for inter-region disaster recovery. |
Compliance | Select a region that complies with the data localization and operational filing policies of your country or region. |
A VPC cannot be deployed across regions. To deploy your services across regions, create a VPC in each region and connect them using VPC peering connections or Cloud Enterprise Network (CEN). A vSwitch is a zonal resource. Note of the following:
If you use multiple zones due to cloud service availability, reserve sufficient CIDR blocks and consider the potential increased latency caused by inter-zone traffic.
Some regions offer only one zone, such as China (Nanjing - Local Region, Closing Down). If you require intra-region disaster recovery, carefully consider whether to select such a region.
Plan accounts and VPCs
After planning the regions and zones, you can start creating VPC. Consider your business scale and security isolation to enhance resource usage and reduce costs.
Plan your accounts
If your business is small and you can manage all resources with a single account or a primary account with RAM users, you can skip this section.
When your business scale increases, you may need to delegate permissions and enforce security isolation between environments. In this case, design a unified multi-account architecture.
Consideration | Description |
Permission isolation | Create separate accounts for different business units to isolate resources, costs, and permissions for easier management. 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 the risk of interference. |
Security compliance | For enhanced security compliance, maintain sensitive data and workloads in separate, isolated accounts. |
Cost 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 for security auditing. |
The network complexity increases with the numbers of VPCs and accounts. Use the VPC sharing feature to reduce complexity while maintaining network security and stability.
Plan your VPC
A VPC provides a secure and flexible network environment. Different VPCs are completely isolated from each other, while resources within the same VPC can communicate over the private network. Plan the number of VPCs that fits your needs.
VPC count | Use cases |
One |
 |
Multiple |
Plan multiple VPCs in the following use cases:
|
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.
Plan your vSwitch
A vSwitch is a zonal resource. All cloud resources in a VPC are deployed within vSwitches. Creating vSwitches helps you properly plan IP addresses. All vSwitches in a VPC can communicate with each other by default.
Consideration | 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 | When using a VPC, create at least two vSwitches and deploy them across zones for disaster recovery. Centrally configure and manage security rules, which significantly improves high availability and disaster recovery. |
Business scale and division | Create vSwitches by business modules. For example, for a standard web application architecture, create multiple vSwitches to host the web, logic, and data layers. |
Plan your vSwitches by referring to the following principles:
Create at least two vSwitches and deploy them across zones for failover. When one vSwitch is down, the other takes over and provides disaster recovery.
Note that the network latency may increase due to the complex network topology and cross-zone calls. We recommend enhancing your architecture to balance both high availability and low latency.
The number of vSwitches depends on your system scale and architecture. Typically, Switches are created by business modules. For example, deploy Internet-facing services in a public vSwitch, while other services are grouped into different vSwitches by their types. This helps to simplify the configuration and lets you manage security rules centrally.
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.
Plan CIDR blocks
When creating a VPC and vSwitch, you must specify the VPC and vSwitch CIDR blocks. The size of the CIDR block determines the number of resources that can be deployed. Proper CIDR block planning avoids address conflicts and ensures scalability, whereas improper planning may cause high reconstruction costs.
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 it. 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 VPC address space, add secondary CIDR blocks.
If you deploy your services in one VPC, reserve sufficient addresses by specifying a smaller prefix length.
Avoid CIDR block overlaps when you create multiple VPCs for your business.
Avoid CIDR block overlaps when you create multiple zones for disaster recovery.
As the network scale increases, CIDR block planning becomes more complex. Use IP Address Manager (IPAM) to automatically assign IP addresses and detect potential 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 IPAM pools for different environments, such as development and production environments.
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 VPC CIDR blocks and address usage in the IPAM console.
Plan VPC CIDR block
Use private IPv4 addresses specified in the RFC 1918 standard for the secondary IPv4 CIDR blocks. The recommended mask length is from /16 to /28, for example, 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 | IP address range |
|
|
|
|
|
|
When you specify CIDR blocks for VPCs, note the following rules:
If you have only one VPC and the VPC does not need to communicate with a data center, 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, avoid CIDR block conflicts between VPCs, or between a VPC and the data center.
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.The choice of a VPC CIDR block also depends on whether you use the classic network. If you use the classic network and plan to connect ECS instances from 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. View the address usage of a VPC by using IPAM.
Plan vSwitch CIDR blocks
The CIDR block of a vSwitch must be a subset of the VPC CIDR block. For example, if the VPC CIDR block 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.
The vSwitch CIDR block cannot be the same as the VPC CIDR block.
vSwitch CIDR block planning must account for the number of ECS instances and other cloud resources it will contain. Choose a CIDR block large enough to reserve sufficient IP addresses for later use. However, do not allocate an overly large CIDR block, as this may hinder future network segmentation.
If you create a VPC with the CIDR block
10.0.0.0/16, it supports 65,536 IP addresses. Considering that you need to deploy resources like ECS and RDS within vSwitches, plan a/24mask for your vSwitches, with each vSwitch supporting 256 IP addresses. A VPC with the CIDR block10.0.0.0/16can be divided into a maximum of 256 vSwitches with a/24mask. Adjust this if necessary.The first address and the last three addresses of each vSwitch's IPv4 CIDR block are reserved by the system. The first address and the last nine addresses of each vSwitch's IPv6 CIDR block are reserved by the system. For example:
IP version
vSwitch CIDR
Reserved IP addresses
IPv4
192.168.1.0/24192.168.1.0192.168.1.253192.168.1.254192.168.1.255IPv6
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 a 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 VPC CIDR block 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.
Plan route tables
Each entry in a route table is a route, which consists of a destination CIDR block, a next hop type, and a next hop. A route directs traffic for a CIDR block to its next hop. Each VPC can have up to 10 route tables, including the system route table. Refer to the following recommendations to plan the route tables.
Use one route table
If there are no significant differences in traffic routing among the vSwitches in your VPC, a single route table is sufficient. When you create a VPC, the system automatically creates a system route table and adds system routes to it to manage the VPC traffic. You cannot create or delete the system route table, but you can add custom routes to it to direct traffic for a destination CIDR block.
Use multiple route tables
If the traffic paths of vSwitches are significantly different, for example, restrict certain cloud services from accessing the internet, you can use multiple route tables. You can deploy public and private vSwitches. Instances in private vSwitches can access the Internet by using an Internet NAT gateway, which allows for 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.
Plan network connectivity
Alibaba Cloud provides a securely isolated and elastically scalable cloud network and supports fast connections between the cloud and data centers. 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 when your applications need to access the internet or be accessed from it:
Configure a public IP for the ECS instance, which can either be a static public IP or an elastic IP address (EIP). We recommend using an EIP.
If only one ECS instance is used to provide services over the Internet, a single point of failure (SPOF) may occur, affecting 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 the number of VPCs is no more than five, use VPC peering connections to create connections between each pair.
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 VPN gateway to establish a secure connection between two VPCs, but the network latency is high.
Hybrid cloud
Use the following services to connect a data center to a VPC.
If you require high security and low latency, use Express Connect circuits.
If you want to reduce costs, use VPN gateway.
What are the requirements for 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. Follow these allocation principles in order of priority:
Unique VPC CIDRs. Assign a unique, non-overlapping CIDR block to each VPC. Using subnets of standard RFC 1918 ranges increases the number of available CIDRs.
Unique vSwitch CIDRs. If you cannot ensure unique VPC CIDR blocks, ensure that the vSwitch CIDR blocks within the communicating VPCs do not overlap.
Unique CIDR for communicating vSwitches. If even vSwitch CIDR blocks overlap, ensure that the vSwitches that need to communicate with each other have non-overlapping CIDR blocks. Network communication will fail otherwise.
Imagine you have three VPCs in different regions, VPC1 in China (Hangzhou), VPC2 in China (Beijing), and VPC3 in China (Shenzhen). You also have an on-premises data center in China (Hangzhou).
VPC1 needs to connect to VPC2 using a VPC peering connection.
VPC1 needs to connect to the on-premises data center using Express Connect.
VPC3 does not need to connect to anything now, but may need to connect to other VPCs
IP Address Manager (IPAM) can help you manage it. Create separate pools in IPAM for each region to ensure proper IP allocation. 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.
Plan security capabilities
Security isolation includes service, resource, and network isolation. You need to consider security isolation requirements when you plan regions, zones, accounts, and CIDR blocks. Separating accounts achieves resource isolation, while segmenting VPCs achieves network isolation. Both are methods for achieving business isolation. Plan your security capabilities by combining network connection scenarios with a layered security approach.
Security layer | Suggestion |
Within VPC | If you deploy multiple services in a VPC, create a vSwitch for each service and use security groups and network ACLs. |
VPC boundary |
|
Use flow log and traffic mirror 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. |
Plan disaster recovery capabilities
Plan disaster recovery capabilities that fit your 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.
Use Express Connect circuits to connect your data centers to VPCs through fast and stable connections. 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 highly-available architecture. This ensures that service IP remain unchanged during switchover.
Cconsider the disaster recovery capabilities inherent in the cloud services themselves. For example, RDS High-availability Edition Active uses a classic high-availability architecture with one primary and one standby node. The primary and standby nodes can be deployed in the same or different zones within the same region.
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 you have considered 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.