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.

You can also customize a security group or use the default one. The system provides a default security group for you, which permits all outbound traffic and denies inbound traffic. ECSs in a security group are accessible to each other. For details about the default security group, see Default Security Groups and Rules.

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

• 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.

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.

Recommendations

• Instances in a security group deny all external access requests by default, but you can add rules to allow specific requests.
• When adding a security group rule, grant the minimum permissions possible. For example, if remote login to an ECS over port 22 is allowed, only allow specific IP addresses to log in to the ECS. Do not use 0.0.0.0/0 (all IP addresses).
• Keep your configurations simple. There should be a different reason for each security group. If you use the same security group for all your different instances, the rules in the security group will likely be redundant and complex. It will make it much harder to maintain and manage.
• You can add instances to different security groups based on their functions. For example, if you want to provide website services accessible from the Internet, you can add the web servers to a security group configured for that specific purpose and only allow external access over specific ports, such as 80 and 443. By default, other external access requests are denied. Do not run internal services, such as MySQL or Redis, on web servers that provide services accessible from the Internet. Deploy internal services on servers that do not need to connect to the Internet and associate these servers with security groups specifically configured for that purpose.
• If you have multiple IP addresses with the same security requirements, you can add them to an IP address group and select this IP address group when you configure a rule, to help you manage them in an easier way. When an IP address changes, you only need to change the IP address in the IP address group. Then, the rules in the IP address group change accordingly. You do not need to modify the rules in the security group one by one. This simplifies security group management and improves efficiency. For details, see Using IP Address Groups to Reduce the Number of Security Group Rules.
• Do not directly modify security group rules for active services. Before you modify security group rules used by a service, you can clone the security group and modify the security group rules in the test environment to ensure that the modified rules work. For details, see Cloning a Security Group.
• After you add instances to or modify rules of a security group, the security group rules are applied automatically. There is no need to restart the instances.

  If a security group rule does not take effect after being configured, see Why Are My Security Group Rules Not Working?