Help Center> Virtual Private Cloud> Best Practices> Using Access Control to Protect Your Resources
Updated on 2024-04-30 GMT+08:00
View PDF

Using Access Control to Protect Your Resources

A VPC is your private network on the cloud. You can configure security groups and network ACL rules to ensure the security of instances, such as ECSs, databases, and containers, running in a VPC.
  • A security group protects the instances in it.
  • A network ACL protects associated subnets and all the resources in the subnets.

As shown in Figure 1, security groups A and B protect the network security of ECSs. Network ACLs A and B add an additional layer of defense to ECSs in subnets 1 and 2.

Figure 1 Security groups and network ACLs
Here are some common access control configuration examples:

Allowing Traffic from Given IP Addresses or a Security Group

You can add inbound rules to allow traffic from specific IP addresses and other security groups. As you can see in Figure 2, there are two subnets (Subnet-A and Subnet-B) in VPC-X. ECSs in Subnet-A are associated with security group Sg-A, and ECSs in Subnet-B are associated with security group Sg-B.
  • Add inbound rule A01 to Sg-A to allow traffic from IP addresses in 172.16.0.0/24 to access SSH port 22 on the ECSs in Sg-A for remotely logging in to these ECSs.
  • Add inbound rule B01 to Sg-B to allow the ECSs in Sg-A to access SSH port 22 on the ECSs in Sg-B for remotely logging in to the ECSs in Subnet-B.
Figure 2 Security group examples (allowing traffic from given IP addresses and security groups)

Allowing Traffic from a Virtual IP Address

You can add inbound rules to allow traffic from virtual IP addresses and other security groups. In Figure 3, there are two subnets (Subnet-A and Subnet-B) in VPC-X. ECSs in Subnet-A are associated with security group Sg-A, and ECSs in Subnet-B are associated with security group Sg-B.
  • Add inbound rule A01 to Sg-A to allow the ECSs in Sg-B to access the ECSs in Sg-A using private IP addresses.
  • Add inbound rule B01 to Sg-B to allow traffic from virtual IP address 192.168.0.21 to the ECSs in Sg-B using any protocol over any port. You can also set the source to the CIDR block of Subnet-A (192.168.0.0/24).

    Do not add rules like rule B02. This rule allows the ECSs in Sg-A to access the ECSs in Sg-B using private IP addresses but not virtual IP address 192.168.0.21.

Figure 3 Security group examples (allowing traffic from a virtual IP address)

Allowing Communications Between Instances in Two VPCs Connected by a VPC Peering Connection

In Figure 4, VPC-A and VPC-B are connected by VPC peering connection peering-AB. To allow ECSs in Sg-A and Sg-B to communicate with each other, you can add the following rules:
  • Rule A01 with Source to Sg-B to allow ECSs in Sg-B to access ECSs in Sg-A.
  • Rule B01 with Source to Sg-A to allow ECSs in Sg-A to access ECSs in Sg-B.
Figure 4 Security group examples (allowing communications between ECSs in two VPCs connected by a VPC peering connection )

Allowing Traffic from Specific IP Addresses to the Instances in a Subnet

A network ACL controls traffic in and out of a subnet. If both security group and network ACL rules are configured, traffic matches network ACL rules first and then security group rules. You can configure network ACL rules to add an additional layer of protection to your instances.
  • Inbound rule A01 of security group Sg-A allows traffic from any IP address to the ECSs in Sg-A over SSH port 22.
  • To enhance security, add inbound rule A01 to network ACL Fw-A to allow traffic from 10.0.1.0/24 to the ECSs in Subnet-A over SSH port 22.

The default inbound rule of Fw-A denies all traffic to the ECSs in Subnet-A. So you need to add custom rules to allow access from specific IP addresses. If you associate Subnet-A with Fw-A, the instances in Subnet-A can still communicate with each other.

Figure 5 Network ACL examples (allowing traffic from specific IP addresses to the instances in a subnet)