Before you can use cloud resources in a virtual private cloud (VPC), you must create a VPC and a vSwitch. You can create more than one vSwitch to divide a VPC into multiple subnets. By default, the subnets in a VPC can communicate with each other.

VPCs and vSwitches

A VPC is a private network dedicated for your use.

Note You cannot directly deploy cloud resources in a VPC. You must deploy cloud resources in vSwitches of a VPC.
vSwitches are basic components of VPCs and are used to connect different cloud resources. You can deploy a VPC only in one region and cannot deploy a VPC across regions. However, a VPC covers all zones of the region to which the VPC belongs. You can create one or more vSwitches in a zone to divide a VPC into multiple subnets. VPCs and vSwitches

CIDR blocks and IP addresses

VPCs support both IPv4 and IPv6. By default, VPCs use IPv4. You can enable IPv6 based on your business requirements.

VPCs support the dual-stack mode. In dual-stack mode, resources in a VPC can communicate through both IPv4 and IPv6 addresses. IPv4 and IPv6 addresses are independent of each other. Therefore, you must configure routes and security groups for both IPv4 and IPv6 addresses.

The following table lists the differences between IPv4 and IPv6 addresses.
IPv4 VPC IPv6 VPC
An IPv4 address is 32 bits in length and contains four groups. Each group consists of at most three decimal digits. An IPv6 address is 128 bits in length and contains eight groups. Each group consists of four hexadecimal digits.
By default, IPv4 is enabled. You can enable IPv6.
The subnet mask of a VPC CIDR block can range from /8 to /24. The subnet mask of a VPC CIDR block is /56.
The subnet mask of a vSwitch CIDR block can range from /16 to /29. The subnet mask of a vSwitch CIDR block is /64.
You can specify an IPv4 CIDR block. You cannot specify an IPv6 CIDR block. The system automatically assigns an IPv6 CIDR block to your VPC from the IPv6 address pool.
Supported by all instance types. Not supported by specific instance types.

For more information, see Instance families.

ClassicLink connections are supported. ClassicLink connections are not supported.
IPv4 elastic IP addresses (EIPs) are supported. IPv6 EIPs are not supported.
VPN gateways and NAT gateways are supported. VPN gateways and NAT gateways are not supported.

By default, IPv4 and IPv6 addresses provided for VPCs support only communication over private networks. Cloud resources deployed in different vSwitches that belong to the same VPC can communicate with each other over private networks. To connect a VPC to another VPC or a data center, you can use Smart Access Gateway (SAG), Express Connect, or VPN Gateway. For more information, see Connect a data center to a VPC.

To enable cloud resources in a VPC to communicate with the Internet, configure the following items:
  • IPv4 addresses

    You can configure NAT gateways or associate EIPs with Elastic Compute Service (ECS) instances in a VPC. This way, the ECS instances can communicate with the Internet through IPv4 addresses.

    For more information, see Associate an EIP with a cloud resource and Use SNAT to enable Internet access.

  • IPv6 addresses

    To enable cloud resources in a VPC to communicate with the Internet through IPv6 addresses, you must purchase an IPv6 Internet bandwidth plan. You can configure egress-only rules for IPv6 addresses. This allows cloud resources in the VPC to access the Internet through IPv6 addresses. However, IPv6 clients cannot access the cloud resources over the Internet.

Routes

The system automatically creates a system route table and adds system route entries to control the traffic of the VPC. A VPC has only one system route table. You cannot create or delete a system route table. System route tables
You can create and associate custom route tables with vSwitches to facilitate network management. A vSwitch can be associated with only one route table. For more information, see Work with route tables. Custom route tables

If multiple route entries match the destination IP address, the route entry with the longest subnet mask prevails and is used to determine the next hop. This ensures that the traffic is routed to the most precise destination. You can also add a custom route entry to route traffic to a specified destination. For more information, see Create and delete route entries.