Virtual Private Cloud:VPC FAQ

How do I connect different VPCs so that resources in different VPCs can access each other?

You can use VPC peering connections or Cloud Enterprise Network (CEN) to connect VPCs within the same account or across accounts, in the same region or across regions. For the differences between the two options, see Connect VPCs.

How do I troubleshoot a VPC peering connection that does not work?

Use the following troubleshooting steps. The Network Intelligence Service - Path Analysis tool can help with diagnostics.

1. Check routes:

   • Ensure that the peering connection status is Activated.

   • Check whether the route tables of the vSwitches on both ends have routes that point to the peer VPC CIDR block, with the peering connection instance as the next hop.

2. Check security groups and network ACLs:

   • Check the security group and network ACL rules of the source ECS and destination ECS (or RDS) instances.

   • Ensure that the inbound rules of the destination security group and network ACL allow traffic from the source VPC CIDR block (or specific source IPs) to access the required service ports.

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

3. Check for CIDR conflicts:

   • Check whether the CIDR blocks of the two VPCs overlap. When you use VPC peering, we recommend that the CIDR blocks of the two VPCs do not overlap.

   • Pay special attention to the Docker/K8s container CIDR blocks on ECS instances, which may conflict with the peer VPC CIDR block. This is a very common and easily overlooked cause. If a conflict exists, the network is unreachable even if routes, security groups, and network ACLs are all correct.

How do I resolve CIDR block conflicts when configuring a peering connection?

If the CIDR blocks of the two VPCs that need to communicate conflict, you have the following options:

1. Re-plan your network (recommended): migrate resources from one VPC to a new VPC whose CIDR block does not conflict. This is the most thorough solution.

2. Use CEN and a VPC NAT gateway: for more complex CIDR conflict scenarios, use CEN together with the private NAT feature of a VPC NAT gateway to map addresses from one VPC to another CIDR block before communication. This solution involves a more complex architecture and higher costs. For more information, see Use a VPC NAT gateway to resolve IP address conflicts.

How do I troubleshoot the issue where some IPs are unreachable after a peering connection is added?

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

• Routing issue: check the route tables on both ends. A more specific route with a higher priority (longest prefix match rule) may direct traffic elsewhere, such as a default route pointing to a NAT gateway.

• Security group issue: check whether the inbound rules of the destination security group allow access from only some source IPs.

• Network ACL issue: check whether the network ACL allows traffic from only some subnets.

Why can the initiator ping the receiver in a peering connection, but the reverse ping fails?

One-way connectivity is typically caused by asymmetric configurations. Focus on checking whether the security group and network ACL rules on both ECS instances allow outbound and inbound traffic.

I created VPC peering connections from A to B and from B to C. Why can't A and C communicate?

VPC peering connections are not transitive.

This means: if VPC-A has a peering connection with VPC-B, and VPC-B has a peering connection with VPC-C, VPC-A and VPC-C cannot communicate through VPC-B.

If you need full connectivity between multiple VPCs (for example, to build a star or mesh network topology), use the Cloud Enterprise Network (CEN) product.

Why can't I access the peer's RDS, Redis, and other cloud services after a VPC peering connection is established?

This issue is similar to ECS connectivity issues, but you must also pay attention to the access control of the cloud service itself.

1. Complete basic connectivity troubleshooting: use the checklist in VPC peering connection troubleshooting to check routes, CIDR blocks, security groups, and network ACLs to ensure the network path is reachable.

2. Check the IP whitelist of the cloud service: most database and cache services (such as RDS, Redis, and MongoDB) provide IP whitelist features. You must add the private IP address or CIDR block of the ECS instance that initiates access to the whitelist of the target cloud service.

Does VPC peering support cross-account and cross-region connections?

Yes. Note that cross-region usage incurs traffic transmission fees charged by Cloud Data Transfer (CDT) based on outbound traffic.

Note that cross-site connections are not supported. For example, VPCs in the China site and the international site cannot connect to each other.

Why can't the public network be accessed after an IPv4 gateway is deleted?

The most common reason is that Private Mode was selected instead of Public Mode when the IPv4 gateway was deleted. After deletion in Private Mode, all resources in the VPC cannot communicate with the public network.

If you want to restore the VPC to a state without an IPv4 gateway but with public network access, create an IPv4 gateway again and then delete it in Public Mode. For details, see IPv4 gateway.

Can ECS instances in the primary CIDR block communicate with ECS instances in an additional CIDR block in the same VPC?

ECS instances in the primary CIDR block and additional CIDR block are all instances in the same VPC. They can communicate with each other if the security group and network ACL rules allow the traffic.

After ClassicLink is enabled for a VPC, can classic network ECS instances communicate with cloud resources in the additional CIDR block of the VPC?

No. Additional CIDR blocks are not compatible with the ClassicLink feature.

Why does the VIP fail to float over after HaVip is bound?

When the primary node fails, the VIP cannot automatically float to the standby node. This is the most common issue in HaVip configurations. The causes are typically as follows:

• Keepalived is not running: take CentOS 7.9 as an example. Run systemctl status keepalived to check the service status. If it is not running, run systemctl start keepalived to start Keepalived.

• Keepalived configuration error: check the keepalived.conf configuration file for errors. For example:

  • The virtual_router_id of the primary and standby nodes are different.

  • The authentication of the primary and standby nodes are different.

  • The peer IP address specified in unicast_peer is incorrect.

  • The virtual IP address specified in virtual_ipaddress is not the HaVip address.

• Blocked by security group or network ACL: check whether the security group or network ACL rules block the relevant traffic from the source IP.

• In-instance firewall: check whether the firewall in the ECS instance (such as firewalld or iptables) blocks the relevant traffic from the source IP.

Why is the network still unreachable after a route is added?

Adding the correct route is only one prerequisite for network connectivity. If the network is unreachable, follow these steps to troubleshoot:

1. Two-way route check: ensure that routes are correctly configured in both the request and response directions. For example, a VPC peering connection requires routes on both ends.

2. Security group rules: check whether the security groups of the source and destination ECS instances allow traffic for the required protocols and ports (for example, ping requires ICMP).

3. Network ACL rules: if you have configured network ACLs, check whether their outbound and inbound rules allow the relevant traffic.

4. In-ECS firewall: check whether the firewall in the ECS operating system (such as iptables/firewalld on Linux, or Windows Firewall) blocks traffic.

5. CIDR conflict: check for network address conflicts, such as a Docker CIDR block on an ECS instance conflicting with the peer VPC CIDR block.

6. Use the Path Analysis tool: use the Network Intelligence Service - Path Analysis tool in the console to visually diagnose the network connectivity between two points.

What should I do if an ECS instance with an EIP bound cannot access the public network?

Check the following:

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

2. Security group rules: check the outbound rules of the security group of the ECS instance. By default, all outbound traffic is allowed (0.0.0.0/0). Confirm that outbound access is not incorrectly restricted.

3. Network ACL rules: if you have configured network ACLs for the vSwitch, check whether the outbound rules allow traffic to leave.

4. Overdue payments: check whether your Alibaba Cloud account has overdue payments, which may cause the EIP to be unavailable.

5. In-ECS network configuration: ensure that the network configuration (such as gateway and DNS) in the ECS operating system is correct. These settings are typically obtained automatically through DHCP.

Why doesn't an ECS instance in a VPC have a public IP address?

VPCs are designed for network isolation and security. By default, an ECS instance created in a VPC is assigned only a private IP address for internal VPC communication, and it cannot access the internet. This is one of the core security features of VPC.

If you want the instance to access the public network, you must explicitly configure public network access for it, such as binding an EIP or configuring a NAT gateway, as described in Internet access.

What should I do if the error "IncorrectBusinessStatus.VpcPeer" or a prompt about overdue payments or abnormal status appears when I create or accept a cross-region or cross-border peering connection?

If this error occurs when you create or accept a peering connection, troubleshoot by following these steps:

• Check for overdue payments: ensure that neither the initiator account nor the receiver account has overdue payments. If an account has overdue payments and the instance is locked (FinancialLocked), recharge the account and retry after the account returns to normal.

• Enable the CDT service: traffic billing for cross-region peering connections depends on the Cloud Data Transfer (CDT) service. Ensure that the CDT service is enabled for both the initiator account and the receiver account. Otherwise, cross-region peering connections cannot be created or used.

Does VPC support multicast?

VPC does not support multicast. However, VPC can work with Cloud Enterprise Network (CEN) to implement Manage multicast.

How do I implement private use of public IP addresses in a VPC?

Some enterprises use non-RFC 1918 private CIDR blocks in their on-premises data centers or VPCs, such as 30.0.0.0/16. When establishing network connections with other VPCs or on-premises data centers, VPC treats IP addresses outside RFC 1918 as public IP addresses. After cloud resources in the VPC obtain public network access capabilities, even if routes pointing to 30.0.0.0/16 are configured to point to an on-premises data center or another VPC, traffic is still forwarded to the public network and cannot reach the target VPC or on-premises data center.

You can implement private use of public IP addresses in the following ways:

• Method 1: IPv4 gateway.

  You can use an IPv4 gateway to centrally control public network access behavior of the VPC. When accessing 30.0.0.0/16, traffic is preferentially routed to another VPC or on-premises data center. For details, see Use IPv4 gateway to route traffic from Internet to private network.

• Method 2: user CIDR block.

  If you want requests to 30.0.0.0/16 to be forwarded based on the route table instead of directly to the public network, you can specify a user CIDR block for the VPC by calling the CreateVpc operation and passing in the UserCidr parameter when you create the VPC. After you set the user CIDR block, requests from the VPC to addresses within the user CIDR block are forwarded based on the route table.

  1. The user CIDR block can be set only through API operations, not in the console. After a user CIDR block is created, it cannot be modified.

  2. If you specify only the IPv4 CIDR block of the VPC and choose a custom CIDR block that is not one of the three standard RFC private CIDR blocks (192.168.0.0/16, 172.16.0.0/12, or 10.0.0.0/8) or their subnets, the system automatically sets the primary CIDR block as the user CIDR block.

What are the differences between VPC and the classic network?

The classic network was the early network model of Alibaba Cloud and is not interconnected with VPCs by default. It is being phased out and is not recommended. All purchased resources should be deployed in VPCs.

How do I enable communication between a VPC and the classic network?

For more information, see Use ClassicLink to connect a classic network and a VPC.

How do I connect an Alibaba Cloud VPC to an on-premises data center network? How do I connect an Alibaba Cloud VPC to AWS or Tencent Cloud?

For more information, see Connect a VPC to a data center or another cloud.

Can VPCs communicate when the CIDR blocks conflict with those of other VPCs or on-premises networks?

For more information, see:

• Use a VPC NAT gateway to resolve IP address conflicts.

• Connect a data center and VPC with a VPC NAT gateway and Express Connect.

• Private network access via NAT and VPN Gateways.

How do I enable an ECS instance to access the public network? How do I enable an ECS instance to access the public network over an IPv6 address?

For more information, see Choose a public IP address type.

How do I use a unified public egress IP for multiple ECS instances?

For more information, see:

• Use a NAT gateway as a unified Internet egress.

• Create VPC peering connections to enable multiple VPCs to use the same Internet NAT gateway.

• Use a transit router to share an Internet NAT gateway across multiple VPCs.

What are the differences between an IPv4 gateway and a NAT gateway?

The features of IPv4 gateways and NAT gateways do not overlap. The two can be used together. For more information about the relationships between network components, see Internet access.

How do I switch between public IP and private IP?

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

• Intra-VPC communication: when other ECS instances in the same VPC access this ECS instance, they always use its private IP. Traffic stays within the VPC, which is fast and free.

• Accessed from the public network or accessing the public network: when users or devices on the internet access this ECS instance, or when this ECS instance accesses the internet, its public IP (EIP) must be used.

How do I enable an ECS instance to access OSS over the VPC internal network?

For more information, see VPC private access to Alibaba Cloud services.

How do I allow only specific IPs to access an ECS instance? What are the differences between network ACLs and security groups?

For more information, see Access control.

How do I enable communication between different security groups?

Basic security groups support using security groups as authorization objects. Enterprise security groups do not. For details, see ECS documentation - Security group as authorization object.

When you configure inbound or outbound rules for a basic security group, you can set the source to another basic security group. This approach is more flexible than authorizing CIDR blocks. When new ECS instances are added to the security group or instance IPs change, you do not need to modify the security group rules. They automatically have access.

How do I troubleshoot security group rules that do not take effect?

1. Rule priority: check whether the rule conflicts with a higher-priority rule.

2. Direction error: check whether the rule is configured as inbound or outbound. Access to an ECS instance is inbound. ECS accessing the external network is outbound.

3. Target object error: confirm that the security group is correctly applied to the elastic network interface of the target ECS instance.

4. Blocked by network ACL: check whether the vSwitch where the ECS instance resides is associated with a network ACL, and whether the ACL rules reject the traffic.

5. In-ECS firewall: check the firewall settings in the operating system.

6. Routing: ensure that traffic can be correctly routed to the ECS instance.

How do I migrate an ECS instance to another VPC?

For more information, see Change VPC for instance.

Can I configure a custom DNS server in a VPC?

Yes. By using the DHCP options set feature, you can change the default DNS server of the VPC to a self-built DNS server on an ECS instance, a DNS server in an on-premises data center, or a third-party public DNS service (network connectivity required). For more information, see Use a self-managed DNS service.

Can a VPC peering connection connect VPCs under China site and international site accounts?

No.

Based on cross-account compliance requirements, peering connections do not support private network connectivity between VPCs under China site accounts and international site accounts.

Does VPC peering support cross-border private network connectivity?

Yes.

Cross-border peering connections incur traffic transmission fees charged by Cloud Data Transfer (CDT) based on outbound traffic. To use the CDT cross-border feature, ensure that the current account has completed enterprise real-name registration.

What is the network latency of VPC peering connections?

• Same-region peering connections: low network latency, typically at the millisecond level.

• Cross-region peering connections: latency is relatively higher due to data transmission between different regions. The specific latency depends on the physical distance and network conditions between the two regions. You can use the Cloud Network Performance Observer to view the average network latency between regions as a reference and choose a link type that better suits your business.

Why is a newly created vSwitch not displayed in the configuration pages of ECS, NLB, RDS, and other cloud products?

If a newly created vSwitch is not found in the configuration pages of other cloud products, the following reasons may apply:

• VPC mismatch: the VPC where the vSwitch resides and the VPC of the cloud product being configured (such as NLB or RDS) must be exactly the same. Otherwise, the vSwitch is not displayed.

• Zone mismatch: the vSwitch and the target cloud product instance must be in the same zone. If the zones are different, create a vSwitch in the zone where the target instance resides.

• Console cache delay: after a vSwitch is created, there may be a brief display delay. We recommend that you log out of the console and log back in, or refresh the page and try again.

• NLB multi-zone requirement: even if backend ECS instances are concentrated in a single zone, NLB requires you to select at least two zones and their corresponding vSwitches. Ensure that each selected zone has a valid vSwitch.

How do I quickly configure a VPC and a vSwitch? Is the vSwitch automatically created when an ECS instance is unsubscribed retained?

• New account configuration recommendations: if you do not have specific private IP planning requirements, you can directly use the default VPC and default vSwitch. This does not affect server operation. The default VPC and default vSwitch do not count against the quota allocated by Alibaba Cloud.

• Default VPC and vSwitch creation: when you create an ECS, CLB, or RDS instance in a region where no VPC has been created, the system automatically preselects the default VPC and default vSwitch. Alibaba Cloud creates them when you place the order.

• Resource retention rules: a vSwitch is an independent network resource. Once created, it is persistently retained and is not automatically deleted when an ECS instance is unsubscribed. You must manually manage or delete it.

What is CIDR?

Classless Inter-Domain Routing (CIDR) is a method for IP address allocation and route aggregation. It improves network management efficiency and simplifies route tables.

CIDR uses slash notation (for example, 192.168.1.0/24):

• The part before the slash is the network address, which indicates the starting IP address of the IP address range.

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

A CIDR block is a collection of IP addresses that share the same network prefix and length. A large CIDR block can be divided into smaller CIDR blocks with different network prefixes and lengths. This process is called subnetting. CIDR blocks are the foundation of modern network planning. VPC and vSwitch subnetting are based on this principle.

Examples:

• 192.168.0.0/16: the first 16 bits are the network, and the last 16 bits are for hosts (theoretically including 2¹⁶ IP addresses). This CIDR block includes 192.168.1.0/24 and 192.168.2.0/26.

• 10.0.0.0/8: the first 8 bits are the network, and the last 24 bits are for hosts (theoretically including 2²⁴ IP addresses). This CIDR block includes 10.1.0.0/16 and 10.2.0.0/24.

• 172.16.0.0/12: the first 12 bits are the network, and the last 20 bits are for hosts (theoretically including 2²⁰ IP addresses). This CIDR block includes 172.17.0.0/16 and 172.18.0.0/24.

When you create a VPC and a vSwitch, you must specify their CIDR blocks in CIDR block format. Note that the actual number of available IP addresses is smaller than the theoretical value because vSwitches have System reserved IP addresses.

How do I modify the CIDR block of a VPC?

• Adjust the primary CIDR block:

  When you create a VPC, the IPv4 CIDR block that you specify is the primary CIDR block of the VPC. The console does not support modifying the primary CIDR block of a VPC. However, you can adjust the CidrBlock parameter of the ModifyVpcAttribute operation to enlarge or shrink the CIDR block within the primary CIDR block. Ensure that the shrunken CIDR block contains the IP addresses that are already in use.

  The IPv6 CIDR block assigned after IPv6 is enabled for the VPC cannot be modified.

• Use additional CIDR blocks: you can Secondary CIDR blocks to add additional CIDR blocks to the VPC outside the primary CIDR block. The additional CIDR blocks and the primary CIDR block take effect at the same time. You can use additional CIDR blocks to create vSwitches and deploy cloud resources such as ECS instances.

How do I modify the CIDR block of a vSwitch?

The IPv4 and IPv6 CIDR blocks of a vSwitch cannot be modified after creation.

If you need to change the CIDR block of a vSwitch, you can only delete the vSwitch and create a new one with the desired CIDR block. Before you delete a vSwitch, you must release or migrate all cloud resources in the vSwitch, such as ECS instances, Server Load Balancer (SLB) instances, and RDS instances. This is a high-risk operation. Ensure that you have a data backup and migration plan in place.

Which CIDR block should I choose when I create a VPC?

Choosing a VPC CIDR block is a critical step in network planning. We recommend that you follow these principles:

• Use standard private CIDR blocks: we recommend that you use the standard private CIDR blocks defined in RFC 1918, 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 CIDR block of a VPC.

• Avoid conflicts with on-premises data centers (IDCs) or other network environments: if you plan to connect your VPC to an on-premises network, other VPCs, or other clouds, ensure that the VPC CIDR block does not conflict with the CIDR blocks of these networks.

• Reserve sufficient address space: estimate the number of IP addresses required based on your future business scale, and choose a CIDR block that is large enough. This prevents complex network transformations later due to insufficient addresses.

• Avoid conflicts with common container network CIDR blocks: if you plan to use Docker or Kubernetes (K8s) in the VPC, we recommend that you avoid common default container CIDR blocks such as 172.17.0.0/16 to prevent communication failures.

How do I assign an IPv6 CIDR block to a VPC? How do I access the public network over IPv6?

After IPv6 is enabled for a VPC and a vSwitch, the system automatically creates an IPv6 gateway and assigns an IPv6 CIDR block. By default, only private communication is supported. For public network communication, you can enable IPv6 public bandwidth. For detailed operations, see Enable or disable IPv6.

Can a VPC be assigned only an IPv6 CIDR block (IPv6-only)?

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

How do I assign a specific private IP address to an existing ECS instance?

For more information, see Modify the primary private IPv4 address of an existing instance.

Why can't networks communicate when Docker networks conflict with VPC CIDR blocks?

This is a typical issue in cloud network planning. When Docker (or K8s Pod) networks deployed on ECS overlap with other vSwitch CIDR blocks in your VPC or the peer VPC CIDR block in a peering connection, it causes routing conflicts and prevents normal communication.

• Cause: Assume the Docker default CIDR block is 172.17.0.0/16, and a vSwitch B in the VPC has the CIDR block 172.17.0.0/24. When an application inside a Docker container tries to access an IP in vSwitch B, the ECS operating system routes the traffic to the local docker0 bridge based on its own routing table, instead of forwarding through VPC routing, causing communication failure.

• Solutions:

  1. Modify Docker/K8s network configuration: Modify the Docker daemon configuration file (such as /etc/docker/daemon.json) to specify a private CIDR block that does not conflict with your overall cloud network environment (including all interconnected VPCs and on-premises IDCs). This is the most fundamental solution.

  2. Avoid conflicts during VPC planning: When planning VPC and vSwitch CIDR blocks, actively avoid 172.17.0.0/16, 10.0.0.0/8 and some CIDR blocks commonly used by K8s.

How do I configure IPAM pool CIDR blocks to prevent new VPCs from conflicting with existing CIDR blocks in on-premises IDCs or other clouds?

1. Before enabling IPAM, comprehensively review all network environments that need to be interconnected, including on-premises data centers, office networks, and other clouds. Record all CIDR blocks already in use.

2. When predefining CIDR blocks in the IPAM pool, include these already-used CIDR blocks.

3. Create custom allocations in the IPAM pool to reserve these CIDR blocks.

4. Subsequently, all new VPC CIDR blocks are allocated through IPAM. Since IPAM has recorded all used CIDR blocks, the new CIDR blocks it allocates will naturally not conflict with existing ones.

Does HaVip support IPv6?

No. Currently, only IPv4 is supported.

What should I do if I'm prompted about dependent resources when deleting a VPC or vSwitch?

Follow the console instructions to delete the dependent resources, 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.

What should I do if I encounter ENI deletion issues when deleting a VPC?

Elastic network interfaces (ENIs) are one of the most common residual resources when deleting a VPC or vSwitch.

• Primary ENI: The primary ENI is created with the ECS instance and its lifecycle is bound to the ECS instance. It cannot be unbound or deleted separately. You must release the ECS instance first, and the primary ENI will be deleted with it.

• Secondary ENI: If it is a secondary ENI, you must unbind 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 and manage ENIs. You need to go to the corresponding cloud service console to delete the service instance (for example, delete an ACK cluster), and these services will automatically clean up the ENIs they created.

What should I do if deleting a vSwitch fails immediately after releasing an ECS instance?

After you release an ECS instance, the system takes about 1-2 minutes to asynchronously clean up residual resources such as ENIs associated with the instance. Wait 1-2 minutes and retry deleting the vSwitch.

Does CEN/Transit Router (TR) automatically add routes for additional CIDR blocks?

If route learning is enabled for the VPC connection on the TR, and the VPC uses an additional CIDR block to create a vSwitch, the TR automatically learns the system route for the vSwitch's additional CIDR block.Route propagation

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

Does VPC have a router?

Each VPC has exactly one router. Each router can maintain multiple route tables.

You can use the VPC console - Route Tables page or the DescribeRouteTables API to query the router ID that owns the route table.

How do I configure routes for a VPC peering connection?

After a VPC peering connection is established and activated, the two VPCs are not connected by default because they do not know how to route traffic to the peer VPC through the peering connection. Therefore, you must add routes pointing to the peering connection in the route tables on both ends.

For steps, see:Configure routes.

What should I enter as the destination CIDR block for a route entry?

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

• Exact match: Enter the specific network range you want traffic to be sent to. For example, to access the peer VPC (192.168.0.0/16), enter 192.168.0.0/16.

• Default route:0.0.0.0/0 represents all IPv4 addresses. Pointing 0.0.0.0/0 traffic to a NAT gateway enables ECS instances without public IPs in the VPC to access the internet through the NAT gateway.

Why do both ends need routes configured for a peering connection?

Network communication is bidirectional. When configuring routes, you must consider not only request traffic (outbound) but also response traffic (inbound). If only one end has routes configured, the network may be unreachable.

Can I use a vSwitch CIDR block as the route destination?

Yes, but not recommended.

Best practice: When configuring routes for VPC peering connections, VPN gateways, etc., the destination should be the peer VPC's entire CIDR block rather than a specific vSwitch CIDR block. This simplifies management, unless you have specific fine-grained access control requirements.

How do I monitor VPC public network traffic?

You can use the VPC Flow Log feature or the Network Intelligence Service - Traffic Analyzer feature to collect traffic information from public network components such as public NAT gateways and IPv4 gateways, enabling public network traffic monitoring. For details, see Flow logs and Traffic Analyzer.

How do I view the VPC network topology?

You can use the Network Intelligence Service - VPC Topology feature to automatically generate a VPC network topology diagram.

A RAM user has been granted AliyunVPCFullAccess. Why can't they access the VPC overview page?

The event statistics panel on the VPC console overview page depends on the ListNisEvent API of the Network Intelligence Service (NIS). With only AliyunVPCFullAccess, basic network management functions such as VPC, vSwitch, and route table work normally, but NIS-related components on the overview page such as event statistics will show a permission error.

You need to grant the RAM user one of the following system policies to access all content on the VPC overview page:

• AliyunNISFullAccess: Full access to the Network Intelligence Service (NIS).

• AliyunNISReadOnlyAccess: Read-only access to the Network Intelligence Service (NIS).

AliyunNISFullAccess (NIS) and AliyunNetanaFullAccess (Netana) are different system policies. AliyunNetanaFullAccesscannot replaceAliyunNISFullAccessfor VPC overview page authorization.

How is VPC billed?

Paid VPC features:

• VPC peering connections

• Flow Log

• Traffic mirroring

VPC features in public beta, currently free during the beta period:

• IP Address Management (IPAM)

• High Availability Virtual IP (HaVip)

Free features:

• VPCs and vSwitches, additional CIDR blocks, reserved CIDR blocks

• DNS hostnames, DHCP options sets

• Route tables, prefix lists

• Shared VPC

• ClassicLink, gateway endpoints

• IPv4 gateways, network ACLs

If you create cloud product resources in a VPC, you need to pay for the cloud product resources you use. For details, see the billing documentation for the corresponding resources.

Is VPC peering connection billed?

• Same region: Within the same region, creating and using VPC peering connections is completely free, whether within the same account or across accounts.

• Cross-region: Cross-region VPC peering connections are billed by Cloud Data Transfer (CDT) based on outbound traffic.

How do I stop VPC peering connection billing to save costs?

• Same-region peering connections are free. Deleting them does not affect costs.

• For cross-region peering connections, you need to delete the peering connection instance to stop the associated traffic fees.