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. For details about how security group rules work, see How Security Groups Work.

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.

A security group has inbound and outbound rules to control traffic that is allowed to reach or leave the instances associated with the security group.

Inbound rules: control traffic to the instances in a security group.
Outbound rules: control traffic from the instances in a security group to access external networks.

You can specify protocol, port, and source or destination for a security group rule. For details, see Table 1.

**Table 1** Key parameters in a security group rule
Parameter	Description
Action	Allow or deny. If the protocol, port, and source or destination of the traffic matches a security group rule, the traffic will be allowed or denied.
Priority	The value range is from 1 to 100. A smaller value indicates a higher priority. Security group rules are matched by priority and then by action. Deny rules take precedence over allow rules. To learn more, see Security Group and Security Group Rule Overview.
Type	IPv4 or IPv6.
Protocol & Port	Network protocol type and port range. Protocol: the protocol that is used to match traffic. The protocol can be TCP, UDP, ICMP, or GRE. TCP is ideal for applications that require reliable connections and high data integrity, such as remote login, web browsing, email, and file transfers. UDP is ideal for applications demanding high speed and low latency, such as online gaming and video meetings. ICMP is used to communicate data transmission problems. For example, the ping command can be used to check the connectivity between network devices, error reports can be generated for O&M, and diagnosis information can be transmitted for network analysis and optimization. GRE is widely used and enables communications between networks using different protocols by encapsulating one protocol within another, for example, encapsulating IP packets. Port: the port range that is used to match traffic. The value range is from 1 to 65535.
Source/Destination	Source address of traffic in the inbound direction or destination address of traffic in the outbound direction. The source or destination can be an IP address, security group, or IP address group. IP address: an IPv4/IPv6 address or IPv4/IPv6 CIDR block. for example, 192.168.10.10/32 (IPv4 address), 192.168.1.0/24 (IPv4 CIDR block), or 2407:c080:802:469::/64 (IPv6 CIDR block). Security group: If the selected security group and the current security group are in the same region, traffic headed to the private IP addresses of all instances in the selected security group is either allowed or denied. For example, if there is instance A in security group A and instance B in security group B, and the inbound rule of security group A allows traffic from security group B, traffic is allowed from instance B to instance A. IP address group: You can add multiple IP addresses with the same security requirements to an IP address group and select this IP address group when you configure a rule.

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.

Security Group Configuration Examples lists more security group rule configuration examples.

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

Security Group Configuration Guide

If you use security groups for the first time, you are advised to perform the following operations.

**Table 2** Security group configuration guide
Scenario	Description	Reference
Creating a security group	If the default security group and existing custom security groups do not meet service requirements, you can create a security group.	Creating a Security Group NOTE: When creating an ECS, you can use templates to quickly create security groups. For details, see Creating a Security Group.
Configuring security group rules	After a security group is created, if the rules in the security group cannot meet service requirements, you can add or delete inbound and outbound rules, and modify the action, priority, protocol & port of the existing security group rules as required.	Configuring Security Group Rules
Associating an ECS with a security group	When creating an ECS, associate it with at least one security group. The inbound and outbound traffic of the ECS is protected by the security group. If the security group does not meet service requirements, you can change the security group associated with the ECS.	Adding ECSs to One or More Security Groups Removing Instances from One or More Security Groups Changing a Security Group

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 3 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 3** 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

If you specify an IP address group or inconsecutive ports for a security group rule, the rule is only applied for certain ECSs. For details, see Table 4.

**Table 4** Scenarios that security group rules do not take effect
Rule Configuration	ECS Type
Source or Destination is set to IP address group.	The following x86 ECS types are not supported: General computing (S1, C1, and C2 ECSs) Memory-optimized (M1 ECSs) High-performance computing (H1 ECSs) Disk-intensive (D1 ECSs) GPU-accelerated (G1 and G2 ECSs) Large-memory (E1, E2, and ET2 ECSs)
Port is set to non-consecutive ports.	The following x86 ECS types are not supported: General computing (S1, C1, and C2 ECSs) Memory-optimized (M1 ECSs) High-performance computing (H1 ECSs) Disk-intensive (D1 ECSs) GPU-accelerated (G1 and G2 ECSs) Large-memory (E1, E2, and ET2 ECSs)
Port is set to non-consecutive ports.	Kai1 Kunpeng ECSs do not support inconsecutive ports. If you use inconsecutive port numbers in a security group rule of a Kai1 Kunpeng ECS, this rule and rules configured after this one do not take effect. If you configure security group rule A with inconsecutive ports 22,24 and then configure security group rule B with port 9096, both rule A and rule B do not take effect.

For details about x86 ECSs, see ECS Specifications (x86).
For details about Kunpeng ECSs, see ECS Specifications (Kunpeng).

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?