VPC FAQ

Connect different VPCs for resource access

Use a peering connection or Cloud Enterprise Network (CEN) to connect VPCs across accounts and regions. Compare these options in VPC connections.

How do I troubleshoot a failing peering connection?

Follow this checklist to troubleshoot the issue. You can also use the Path Analysis tool of Network Intelligence Service to diagnose the issue.

1. Check routes:

   • Ensure the peering connection is in the Activated state.

   • Check the route tables of the vSwitches at both ends. Ensure that routes point to the CIDR block of the peer VPC and that the next hop is the peering connection instance.

2. Check security groups and network ACLs:

   • Check the security group and network ACL rules for the source and destination ECS instances (or other services such as RDS).

   • Ensure the inbound rules of the security group and network ACL for the destination allow traffic from the source VPC's CIDR block (or specific source IP address) to access the required service port.

   • Ensure the outbound rules of the security group and network ACL for the source do not restrict outbound traffic.

3. Check for CIDR block conflicts:

   • Check whether the CIDR blocks of the two VPCs overlap. Use non-overlapping CIDR blocks for VPCs connected by a peering connection.

   • Check whether Docker or Kubernetes container CIDR blocks on ECS instances conflict with the peer VPC CIDR block. This is a common but often overlooked cause of connectivity issues — if a conflict exists, the connection fails even if routes, security groups, and network ACLs are correct.

Resolve CIDR conflicts in peering connections

If the CIDR blocks of two VPCs that you want to connect overlap, choose one of the following solutions:

1. Replan your network (recommended): Migrate resources to a new VPC with a non-overlapping CIDR block.

2. Use CEN and a VPC NAT gateway: For complex conflicts, use CEN with a VPC NAT gateway's private NAT feature to map one VPC's address space to another. This approach is more complex and costly. Use a VPC NAT gateway to resolve address conflicts.

Troubleshoot inaccessible IPs in peering connections

This issue is usually caused by more specific routes or security group rules.

• Route issue: Check the route tables at both ends. A more specific route with a higher priority, based on the longest prefix match rule, might be directing traffic elsewhere, such as a default route pointing to a NAT gateway.

• Security group issue: Check the inbound rules of the destination security group to see if access is allowed only from specific source IP addresses.

• Network ACL issue: Check whether the network ACL allows traffic only from specific subnets.

One-way connectivity in peering connections

Asymmetric configuration typically causes this. Check security group and network ACL rules at both ends to ensure bidirectional traffic is allowed.

Non-transitive peering connections

Peering connections are not transitive.

This means that if you create a peering connection between VPC A and VPC B, and another one between VPC B and VPC C, VPC A and VPC C cannot communicate with each other through VPC B.

To enable full connectivity among multiple VPCs, for example, to build a star or mesh topology, use CEN.

Access cloud services over peering connections

This issue is similar to a connectivity failure with an ECS instance, but you must also check the access control settings of the cloud service itself.

1. Perform a basic connectivity check: Follow the checklist in How do I troubleshoot a failing peering connection? to check the routes, CIDR blocks, security groups, and network ACLs to ensure the network link is active.

2. Check the IP address whitelist of the cloud service: Database and cache services (RDS, Redis, MongoDB) use IP whitelists. Add the source ECS instance's private IP or the vSwitch CIDR block to the destination service's whitelist.

Cross-account and cross-region peering connections

Yes. Cross-region peering connections incur outbound traffic fees through Cloud Data Transfer (CDT).

Note: Cross-site connections are not supported. For example, VPCs on the China and international websites cannot be connected.

Internet access after deleting an IPv4 gateway

The most common reason is that you selected Private Network Mode instead of Public Network Mode when you deleted the IPv4 gateway. If you delete the IPv4 gateway in private network mode, all resources in the VPC lose internet connectivity.

To restore internet access, create a new IPv4 gateway and delete it using Public Network Mode. IPv4 gateways.

Communication between primary and secondary CIDR blocks

Yes. Instances in both primary and secondary CIDR blocks belong to the same VPC. They can communicate with each other if allowed by security group and network ACL rules.

ClassicLink compatibility with secondary CIDR blocks

No. The ClassicLink feature is not compatible with secondary CIDR blocks.

Troubleshoot HaVip failover issues

A common HaVip configuration issue is the failure of a virtual IP address (VIP) to fail over to a secondary node when the primary node fails. The possible causes are as follows:

• The Keepalived service is not running: For example, on CentOS 7.9, run the systemctl status keepalived command to check the service status. If it is not running, run the systemctl start keepalived command to start it.

• Incorrect Keepalived configuration: Check for errors in the keepalived.conf file. For example:

  • The virtual_router_id values for the primary and secondary nodes do not match.

  • The authentication settings for the primary and secondary nodes do not match.

  • The peer IP address specified in unicast_peer is incorrect.

  • The VIP specified in virtual_ipaddress is not the HaVip address.

• Blocked by a security group or network ACL: Check whether security group or network ACL rules are blocking traffic from the source IP address.

• Instance-level firewall: Check whether the firewall on the ECS instance, such as firewalld or iptables, blocks traffic from the source IP address.

Troubleshoot connectivity after adding a route

Adding the correct route is only one prerequisite for network connectivity. If the connection still fails, systematically check the following items:

1. Bidirectional routing: Ensure that routes for both the request and response paths are correctly configured. For example, a peering connection requires routes to be configured at both ends.

2. Security group rules: Check the security groups of the source and destination ECS instances to ensure they allow traffic on the corresponding protocols and ports. For example, the ping command requires the ICMP protocol to be allowed.

3. Network ACL rules: If you have configured a network ACL, check its inbound and outbound rules to ensure the related traffic is allowed.

4. ECS internal firewall: Check whether the firewall within the ECS instance's operating system, such as iptables or firewalld on Linux, or the Windows Firewall, is blocking traffic.

5. CIDR block conflict: Check for network address conflicts, such as a conflict between the Docker network on the ECS instance and the CIDR block of the peer VPC.

6. Use a path analysis tool: Use the Path Analysis tool of Network Intelligence Service in the console to visually diagnose the network connectivity between two points.

Troubleshoot internet access with an EIP

Perform the following checks:

1. IPv4 gateway and VPC route table: If an IPv4 gateway is enabled for the VPC, check the route table of the vSwitch where the ECS instance resides. Ensure that a default route (0.0.0.0/0) points to the IPv4 gateway.

2. Security group rules: Check the outbound rules of the security group to which the ECS instance belongs. By default, all outbound traffic is permitted (0.0.0.0/0). Ensure that outbound access is not incorrectly restricted.

3. Network ACL rules: If you have configured a network ACL for the vSwitch, check its outbound rules to ensure that outbound traffic is allowed.

4. Overdue payments: Check whether your Alibaba Cloud account has overdue payments. An overdue payment may render the EIP unavailable.

5. ECS internal network configuration: Verify that gateway and DNS settings in the OS are correct. These are typically obtained via DHCP.

Default network access for VPC instances

VPCs provide network isolation by default. An ECS instance in a VPC receives only a private IP address and cannot access the internet unless explicitly configured.

To enable internet access, bind an EIP or configure an Internet NAT gateway. Internet access.

Does VPC support multicast?

VPC itself does not support multicast. However, you can use VPC with CEN to implement multicast management.

Using public CIDR blocks for private communication

Some organizations use public CIDR blocks such as 30.0.0.0/16 for on-premises data centers or VPCs. These are outside the RFC 1918 private ranges. By default, VPC treats addresses outside RFC 1918 as public — if resources have internet access, traffic to 30.0.0.0/16 is routed to the internet even if a route entry points to the data center or peer VPC.

You can use one of the following methods to use a public CIDR block for private communication:

• Method 1: Use an IPv4 gateway.

  An IPv4 gateway centrally controls internet access for your VPC, ensuring traffic to 30.0.0.0/16 is routed to other VPCs or your data center first. Use an IPv4 gateway to enable private communication over a public CIDR block.

• Method 2: Use a user CIDR block.

  To forward requests from the VPC to 30.0.0.0/16 based on the route table instead of to the internet, call the CreateVpc API operation and set the UserCidr parameter to specify a user CIDR block for the VPC. After you specify a user CIDR block, requests from the VPC to an address in the user CIDR block are forwarded based on the route table.

  1. You can specify a user CIDR block only by calling the API. This feature is not available in the console. You cannot modify a user CIDR block after it is created.

  2. When you specify only the IPv4 CIDR block for a VPC, if you select a custom address range outside the standard RFC 1918 private CIDR blocks (192.168.0.0/16, 172.16.0.0/12, and 10.0.0.0/8) and their subnets, the system by default sets the primary CIDR block as a user CIDR block.

VPC vs. classic network

The classic network is a legacy network type that does not communicate with VPCs by default. Alibaba Cloud is phasing it out — deploy all new resources in a VPC.

Connect a VPC to a classic network

Use ClassicLink to connect a classic network to a VPC.

Connect a VPC to external networks

Connect a VPC to an on-premises data center or another cloud.

Handle CIDR block overlaps

Solutions:

• Use a VPC NAT gateway to resolve address conflicts.

• Use a VPC NAT gateway with Express Connect to connect an on-premises data center to the cloud.

• Use a VPC NAT gateway with a VPN Gateway to enable private communication between the cloud and on-premises environments.

Enable internet access for an ECS instance

Select a public IP address type.

Share a public IP for multiple ECS instances

Options:

• Use a NAT gateway to centralize outbound internet traffic.

• Use a peering connection to allow multiple VPCs to share an Internet NAT gateway.

• Use a transit router to allow multiple VPCs to share a NAT gateway.

IPv4 gateway vs. Internet NAT gateway

An IPv4 gateway and an Internet NAT gateway serve different purposes and can be used together. Internet access.

Using public and private IP addresses

An ECS instance with a bound EIP has both a public IP address and a private IP address. You do not need to manually switch between them.

• Intra-VPC communication: When other ECS instances within the VPC access this instance, they must always use its private IP address. Traffic flows entirely within the VPC, which is fast and free of charge.

• Internet communication: When users or devices on the internet access this ECS instance, or when this instance accesses the internet, its public IP address (EIP) must be used.

Access OSS over the internal network

Access cloud services over a private connection.

Access control: IP filtering and security groups

Access control.

Enable communication between security groups

Basic security groups support using another security group as an authorization object. Enterprise security groups do not. Use a security group as an authorization object (ECS documentation).

When configuring rules for a basic security group, you can set the source to another basic security group. This is more flexible than authorizing a CIDR block — new instances added to the group or instances whose IP addresses change automatically gain access without rule changes.

Troubleshoot ineffective security group rules

1. Rule priority: Check for conflicts with a rule that has a higher priority.

2. Incorrect direction: Check whether the rule is configured for inbound or outbound traffic. Accessing an ECS instance is inbound traffic, while the ECS instance accessing an external resource is outbound traffic.

3. Incorrect target: Ensure that the security group is correctly applied to the elastic network interface of the target ECS instance.

4. Blocked by a network ACL: Check if the vSwitch where the ECS instance resides is associated with a network ACL, and if the rules of the network ACL deny the traffic.

5. ECS internal firewall: Check the firewall settings on the operating system.

6. Routing issues: Ensure that traffic routes correctly to the ECS instance.

Migrate an ECS instance to another VPC

Change the VPC of an ECS instance.

Use a custom DNS server in a VPC

Yes. Use a DHCP options set to point the VPC's DNS to a self-managed server, an on-premises DNS server, or a third-party public DNS. The server must be reachable from the VPC. Use a self-managed DNS service.

Peering connections between China and international sites

No.

Due to cross-account compliance requirements, peering connections cannot connect VPCs belonging to accounts on the China and international websites.

Do peering connections support cross-border private connectivity?

Yes.

For cross-border peering connections, Cloud Data Transfer (CDT) charges a data transfer fee based on outbound traffic. To use the cross-border feature of CDT, you must first complete cross-border compliance certification. Submit your information on the China Unicom Cross-border Cloud Leased Line Application page to apply for cross-border business qualification.

Network latency of peering connections

• Intra-region peering connection: Network latency is low, typically in the millisecond range.

• Cross-region peering connection: Latency is higher due to physical distance and network conditions between regions. Use the network performance monitoring tool to check average latency between regions and select an appropriate link type.

What is a CIDR block?

Classless Inter-Domain Routing (CIDR) is a method for allocating IP addresses and aggregating routes, improving network management efficiency and simplifying route tables.

CIDR uses slash notation, such as 192.168.1.0/24:

• The part before the slash is the network address, which is the first IP address in the address range.

• The number after the slash is the prefix length, which indicates the number of consecutive leading 1s in the subnet mask. The remaining bits are used for host addresses.

A CIDR block is a collection of IP addresses sharing the same network prefix and prefix length. Dividing a large CIDR block into smaller ones is called subnetting — this is the foundation of VPC and vSwitch network planning.

Examples:

• 192.168.0.0/16: The first 16 bits are for the network and the last 16 bits are for hosts, which in theory includes 2¹⁶ IP addresses. This CIDR block includes subnets such as 192.168.1.0/24 and 192.168.2.0/26.

• 10.0.0.0/8: The first 8 bits are for the network and the last 24 bits are for hosts, which in theory includes 2²⁴ IP addresses. This CIDR block includes subnets such as 10.1.0.0/16 and 10.2.0.0/24.

• 172.16.0.0/12: The first 12 bits are for the network and the last 20 bits are for hosts, which in theory includes 2²⁰ IP addresses. This CIDR block includes subnets such as 172.17.0.0/16 and 172.18.0.0/24.

When you create a VPC and a vSwitch, you need to specify a CIDR block for them. Note that the actual number of available IP addresses is less than the theoretical number because a vSwitch has system-reserved addresses.

Modify the CIDR block of a VPC

• Adjust the primary CIDR block:

  The IPv4 CIDR block specified at VPC creation is its primary CIDR block. You cannot modify it in the console, but you can call the ModifyVpcAttribute API operation to expand or shrink it via the CidrBlock parameter. When shrinking, ensure the new block covers all IPs in use.

  You cannot modify the IPv6 CIDR block assigned to a VPC after you enable IPv6.

• Use a secondary CIDR block: You can use a secondary CIDR block to expand the address space of a VPC. A secondary CIDR block is active at the same time as the primary CIDR block and can be used to create vSwitches and deploy cloud resources such as ECS instances.

Modify the CIDR block of a vSwitch

You cannot modify the IPv4 or IPv6 CIDR block of a vSwitch after it is created.

To change the CIDR block, delete the vSwitch and create a new one. Before deletion, release or migrate all resources (ECS, SLB, RDS instances). This is a high-risk operation — ensure you have a data backup and service migration plan.

Choose a CIDR block for a VPC

Follow these principles when choosing a VPC CIDR block:

• Use standard private CIDR blocks: Use RFC 1918 private blocks such as 10.0.0.0/16, 172.16.0.0/16, and 192.168.0.0/16. You cannot use 100.64.0.0/10, 224.0.0.0/4, 127.0.0.0/8, or 169.254.0.0/16 as the VPC CIDR block.

• Avoid conflicts with connected networks: If you plan to connect the VPC to on-premises networks, other VPCs, or other clouds, ensure the VPC CIDR block does not overlap with those networks.

• Reserve sufficient address space: Estimate future IP requirements and select a large enough CIDR block to avoid complex network modifications later.

• Avoid container network conflicts: If you plan to use Docker or Kubernetes, avoid default container CIDR blocks such as 172.17.0.0/16 to prevent communication failures.

Assign IPv6 and access the internet

After you enable IPv6 for a VPC and vSwitch, the system creates an IPv6 gateway and assigns an IPv6 CIDR block. This supports private communication only by default. To access the internet over IPv6, enable public bandwidth for an IPv6 address. Enable or disable IPv6.

Can I create an IPv6-only VPC?

No. VPC currently supports IPv4-only and dual-stack (IPv4 and IPv6) configurations, but not IPv6-only.

Assign a specific private IP to an instance

Modify the primary private IPv4 address of the primary elastic network interface of an existing instance.

Docker network conflicts with VPC CIDR blocks

When the Docker or Kubernetes pod network on an ECS instance overlaps with a vSwitch CIDR block or a peer VPC CIDR block, a route conflict occurs and communication fails.

• Cause: If the Docker CIDR block is 172.17.0.0/16 and vSwitch B uses 172.17.0.0/24, traffic from a container to an address in vSwitch B is incorrectly routed to the local docker0 bridge instead of the VPC route table.

• Solutions:

  1. Modify the Docker/K8s network configuration: Edit the Docker daemon config file (/etc/docker/daemon.json) to specify a private CIDR block that does not conflict with your cloud network environment, including all connected VPCs and on-premises data centers.

  2. Avoid conflicts when you plan VPC CIDR blocks: When you plan VPC and vSwitch CIDR blocks, avoid CIDR blocks that are commonly used by K8s, such as 172.17.0.0/16 and parts of 10.0.0.0/8.

Use IPAM to avoid CIDR conflicts

1. Before you enable IPAM, comprehensively review all network environments that you need to interconnect, including on-premises data centers, office networks, and other clouds. Record all CIDR blocks that are in use.

2. When you provision a CIDR block for an IPAM pool, ensure that it includes these CIDR blocks that are in use.

3. Reserve these address ranges by creating a custom allocation in the IPAM pool.

4. Allocate CIDR blocks for all subsequent VPCs from IPAM. Since IPAM has a record of all used CIDR blocks, the new CIDR blocks it allocates will not conflict with existing ones.

Does HaVip support IPv6?

No. Currently, only IPv4 is supported.

Handle deletion failures due to dependent resources

Follow the instructions in the console to delete the dependent resources, and then delete the VPC or vSwitch.

You can view existing resources on the Resource Management tab of the VPC details page, or on the Cloud Resources tab of the vSwitch details page.

Handle ENI deletion issues when deleting a VPC

An elastic network interface (ENI) is a common resource that may prevent you from deleting a VPC or vSwitch.

• Primary ENI: A primary ENI is created with an ECS instance and its lifecycle is tied to the instance. You cannot detach or delete it separately. You must release the ECS instance, and the primary ENI is deleted along with it.

• Secondary ENI: If it is a secondary ENI, you must first detach it from the ECS instance before you can delete it.

• Managed by other cloud services: Services such as ALB, NLB, ACK, and Function Compute automatically create ENIs. Delete the service instance (for example, an ACK cluster) — the service automatically cleans up the ENIs it created.

Route learning for secondary CIDR blocks in CEN

If route learning is enabled for a VPC connection on a transit router (TR) and a vSwitch uses a secondary CIDR block, the TR automatically learns that vSwitch's system route.

TRs only auto-learn VPC system routes. For custom routes, manually publish them from the VPC route table to CEN or add route entries in CEN directly.

Does a VPC have a vRouter?

Each VPC has one and only one vRouter. Each vRouter can maintain multiple route tables.

You can query the ID of the vRouter to which a route table belongs on the Route Tables page in the VPC console or by calling the DescribeRouteTables API operation.

Configure routes for a peering connection

After a peering connection is activated, the two VPCs cannot communicate by default — no route directs traffic to the peering connection. Add a route pointing to the peering connection in both VPC route tables.

Configure routes.

Specify the destination CIDR block for a route

The destination CIDR block defines the destination IP addresses to which this route rule applies.

• Specific network: Specify the specific network range to which you want data packets to be sent. For example, to access a peer VPC (192.168.0.0/16), enter 192.168.0.0/16 as the destination CIDR block.

• Default route: 0.0.0.0/0 represents all IPv4 addresses. By directing traffic destined for 0.0.0.0/0 to a NAT gateway, you can enable ECS instances without public IP addresses in a VPC to access the internet through the NAT gateway.

Bidirectional routing for peering connections

Network communication is bidirectional. If you configure a route for only one end, return traffic cannot reach the source and the connection fails.

Use vSwitch CIDR block as route destination

Yes, but this is not recommended.

Best practice: Set the destination CIDR block to the entire peer VPC CIDR block rather than a specific vSwitch CIDR block. This simplifies management. Use a vSwitch-level CIDR block only for fine-grained access control.

Monitor the internet traffic of a VPC

Use VPC flow logs or the Traffic Analyzer of Network Intelligence Service to collect traffic data from internet-facing components such as Internet NAT gateways and IPv4 gateways. Flow logs and Traffic Analyzer.

View the network topology of a VPC

You can use the VPC Topology feature of Network Intelligence Service to automatically generate a network topology graph for your VPC.

How is VPC billed?

The following VPC features are billable:

• Peering connection

• Flow log

• Traffic mirroring

The following VPC features are in public preview and are free of charge during the preview period:

• IP Address Manager (IPAM)

• High-availability Virtual IP (HaVip)

The following features are free of charge:

• VPC, vSwitch, secondary CIDR block, and reserved CIDR block

• DNS hostname and DHCP options set

• Route table and prefix list

• VPC sharing

• ClassicLink and gateway endpoint

• IPv4 gateway and network ACL

Cloud resources created in a VPC are billed separately. Check the billing documentation for each resource.

Are peering connections a paid service?

• Intra-region: Creating and using peering connections within the same region are free, regardless of whether the connections are within the same account or across different accounts.

• Cross-region: For cross-region peering connections, Cloud Data Transfer (CDT) charges a data transfer fee based on outbound traffic.

Stop billing for a peering connection

• Intra-region peering connections are free of charge. Deleting them does not affect your costs.

• For cross-region peering connections, you must delete the peering connection instance to stop incurring data transfer fees.