Basic Concepts

The Virtual Private Cloud (VPC) service allows you to plan networks as required for the services you plan to deploy. A default VPC and subnet are created in each region. You can plan your networks based on service scenarios and plan for future service changes. By default, different VPCs are isolated from each other, but you can use VPC peering connections to connect VPCs in the same region.

The Virtual Private Cloud (VPC) service enables you to provision logically isolated virtual private networks for cloud resources, such cloud servers, containers, and databases. You can customize subnets, security groups, network ACLs, route tables, and assign EIPs and bandwidths as needed. If you need to connect your VPC to an on-premises data center to build a hybrid cloud network, you can use Direct Connect or VPN. Learn More

Figure 1 VPC architecture

A subnet is a unique CIDR block with a range of IP addresses in a VPC. You can deploy cloud servers with different functions in different subnets.

All cloud resources (such as servers, containers, and databases) in a VPC must be deployed in subnets. A subnet provides IP address management and DNS resolution functions for the resources deployed in it.

All subnets in the same VPC can communicate with each other by default. Learn More

Figure 2 Subnets

A route table contains a set of routes that are used to control the traffic in and out of your subnets in a VPC. A default route table automatically comes with a VPC. Subnets in the VPC are automatically associated with the default route table. You can create a custom route table and associate subnets in the VPC with the custom route table. Then, the default route table controls inbound traffic of the subnets, and the custom route table controls outbound traffic of the subnets.

You can add, modify, and delete routes in both default and custom route tables. The next hop type of a route can be an ECS, an extension NIC, a NAT gateway, a VPC peering connection, or a virtual IP address. Learn More

Figure 3 Route tables

A security group is a collection of access control rules for instances, such as cloud servers, containers, and databases, that have the same security requirements and that are mutually trusted within a VPC. You can define different access control rules for a security group, and these rules are then applied to all the instances added to this security group. Learn More

A security group can have inbound and outbound rules. You need to specify the source, port, and protocol for each inbound rule and specify the destination, port, and protocol for each outbound rule to control the inbound and outbound traffic to and from the instances in the security group. As shown in Figure 4, there is a VPC (VPC-A) with a subnet (Subnet-A) in region A. An ECS (ECS-A) is running in Subnet-A and associated with security group Sg-A.

Security group Sg-A has a custom inbound rule to allow ICMP traffic to ECS-A from your PC over all ports. However, the security group does not have rules that allow SSH traffic to ECS-A so you cannot remotely log in to ECS-A from your PC.
If ECS-A needs to access the Internet through an EIP, the outbound rule of Sg-A must allow all traffic from ECS-A to the Internet.

Figure 4 A security group architecture

Note the following when using default security group rules:

Inbound rules control incoming traffic to instances in the default security group. The instances can communicate with each other but cannot be accessed from external networks.
Outbound rules allow all traffic from the instances in the default security group to external networks.

If the default security group does not meet your requirements, you can modify security group rules or create a custom group.

Figure 5 Default security group

A network ACL is an optional layer of security for your subnets. After you add inbound and outbound rules to a network ACL and associate subnets with it, you can control traffic in and out of the subnets.

A network ACL is different from a security group. A security group protects the instances in it, such as ECSs, databases, and containers, while a network ACL protects the entire subnet. Security groups are a mandatory layer of protection but network ACLs are optional. Network ACLs and security groups can be used together for fine-grained access control. Learn More

You need to specify the protocol, source port and address, and destination port and address for each inbound and outbound rule of the network ACL. Suppose you have two subnets in VPC-X in region A, as shown in Figure 6. Subnet-X01 is associated with network ACL Fw-A, and ECSs deployed in this subnet provide web services accessible from the Internet. Subnet-X02 is associated with network ACL Fw-B. Subnet-X02 and Subnet-Y01 are connected through a VPC peering connection, which allows ECS-C01 in Subnet-Y01 to remotely log in to ECSs in Subnet-X02.

Inbound and outbound rules on Fw-A:
Custom inbound rule A01 allows any IP address to access the ECSs in Subnet-X01 through port 80 over TCP or HTTP. If the traffic does not match custom rule A01, the default rule is applied and the traffic is denied to flow into the subnet.

Stateful network ACLs allow responses to inbound requests to leave the subnet without being controlled by rules. The responses from ECSs in Subnet-X01 can go out of the subnet. Other outbound traffic is not allowed to leave Subnet-X01, because the default rule is applied.
Inbound and outbound rules on Fw-B:
Custom inbound rule B01 allows ECS-C01 in Subnet-Y01 to use access the ECSs in Subnet-X02 through port 22 over TCP or SSH.

Custom outbound rule B02 allows all ICMP traffic over any port. The ping traffic from ECSs in Subnet-X02 to ECS-C01 in Subnet-Y01 can be routed successfully to test the network connectivity.