Overview

Security Group

A security group is a collection of access control rules for ECSs that have the same security protection requirements and that are mutually trusted. After a security group is created, you can create various access rules for the security group, these rules will apply to all ECSs added to this security group.

When creating an ECS, you must associate it with a security group. If no security group has been created yet, a default security group will be automatically created and associated with the ECS. You can also create a security group based on service requirements and associate it with the ECS. An ECS can be associated with multiple security groups, and traffic to and from the ECS is matched by priority in a descending order.

Each security group can have both 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 1, you have 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 1 A security group architecture
Click to enlarge

A security group works only when the network communication is normal. If two ECSs are in the same security group but in different VPCs, the security group does not take effect. You can use a VPC peering connection to connect the two VPCs first. For details, see VPC Connectivity Options.

Security Group Rules

After a security group is created, you can add rules to the security group. A rule applies either to inbound traffic (ingress) or outbound traffic (egress). After ECSs are added to the security group, they are protected by the rules of that group.

Each security group has default rules. For details, see Default Security Groups and Rules. You can also customize security group rules. For details, see Configuring Security Group Rules.

Security Group Examples

You can allow given IP addresses to access instances in a security group, or allow access from another security group to enable instances in different security groups to communicate with each other. You can add security group rules to flexibly control the traffic in and out of a network to ensure network security. The following provides some examples on how security groups can be used.

In Figure 2, there are two subnets (Subnet-A and Subnet-B) in VPC-X. ECSs in Subnet-A are associated with Sg-A because these ECSs are used to run the same services and have the same network communication requirements. Similarly, ECSs in Subnet-B are associated with security group Sg-B.

Inbound rule A01 of Sg-A allows traffic from IP addresses in 172.16.0.0/24 to access SSH port 22 of the ECSs in Sg-A for remotely logging in to these ECSs.
Inbound rule A02 of Sg-A allows the ECSs in this security group to communicate with each other using any protocol and port.
Inbound rule B01 of Sg-B allows the ECSs in Sg-A to access the ECSs in Sg-B SSH port 22. That is, ECSs in Subnet-A can remotely log in to the ECSs in Subnet-B.
Inbound rule B02 of Sg-B allows the ECSs in this security group to communicate with each other using any protocol and port. That is, ECSs in Subnet-B can communicate with each other.
The outbound rules of both security groups allow all traffic from the ECSs in the security groups.

Figure 2 Allowing traffic from given IP addresses and security groups
Click to enlarge

If you use an intermediate network instance to forward traffic between instances in different subnets, setting the source of the inbound rule to the security group associated with the peer instance does not allow the instances to communicate with each other. If you set the source of inbound rules to the security groups associated with the ECSs, the ECSs in the two security groups cannot communicate with each other. To enable communications between them, set the source to the private IP address or subnet CIDR block of the virtual IP address.

In Figure 3, VPC-X has two subnets: Subnet-A and Subnet-B. ECSs in Subnet-A are associated with security group Sg-A, and ECSs in Subnet-B are associated with security group Sg-B. ECS-A01 and ECS-A02 work in active/standby mode, forming a Keepalived HA cluster. The ECSs use a virtual IP address to communicate with external networks.

Inbound rule A01 of Sg-A allows ECSs in Sg-B to access ECSs in Sg-A using any protocol over any port.
Sg-B has the following inbound rules:
- Rule B02: Allows ECSs in Sg-A to use private IP addresses to access ECSs in Sg-B. However, in this network, ECSs in Sg-A are supposed to communicate with ECSs in Sg-B through virtual IP address 192.168.0.21. However, rule B02 does not allow traffic from this virtual IP address.
- Rule B01: Allows traffic from virtual IP address 192.168.0.21 to ECSs in Sg-B using any protocol over port. In this networking, you can also set the source to 192.168.0.0/24, the CIDR block of Subnet-A.

Figure 3 Allowing traffic from a virtual IP address
Click to enlarge

In Figure 4, VPC-A and VPC-B in region A are connected by VPC peering connection peering-AB. After routes are configured for the VPC peering connection, Subnet-A01 and Subnet-B01 can communicate with each other. However, the ECSs in the two subnets are associated with different security groups. 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 Allowing communications between ECSs in two VPCs connected by a VPC peering connection
Click to enlarge

Constraints on Using Security Groups

For better network performance, you are advised to associate an instance with no more than five security groups.
A security group can have no more than 6,000 instances associated, or its performance will deteriorate.

For inbound security group rules, the sum of the rules with Source set to Security group, of the rules with Source set to IP address group, and of the rules with inconsecutive ports, cannot exceed 120. If there are both IPv4 and IPv6 security group rules, up to 120 rules can be added for each type.

The limits on outbound security group rules are the same as those on inbound rules.

For example, to add inbound IPv4 rules to a security group (Sg-A), you can refer to Table 1 for rules that meet the restrictions. Of these rules, rule A02 uses inconsecutive ports (TCP: 22,25,27) and security group Sg-B as the source. In this case, only one quota is occupied.

**Table 1** Inbound security group rules
Rule No.	Action	Type	Protocol & Port	Source
Rule A01	Allow	IPv4	All	Current security group: Sg-A
Rule A02	Allow	IPv4	TCP: 22,25,27	Another security group: Sg-B
Rule A03	Allow	IPv4	TCP: 80-82	IP address group: ipGroup-A
Rule A04	Allow	IPv4	TCP: 22-24,25	IP address: 192.168.0.0/16

Traffic from load balancers is not restricted by network ACL and security group rules if:
Transfer Client IP Address is enabled for the listeners of a load balancer.

The load balancer can still forward traffic to backend servers, even if there is a rule that denies traffic from the load balancer to the backend servers.