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 that allows ICMP traffic, so ping requests are allowed from your PC to ECS-A. However, the security group does not have rules that allow SSH traffic, so you cannot remotely log in to ECS-A from your PC.
ECS-A has an EIP bound and the outbound rule of Sg-A allows all outbound traffic from ECS-A, so ECS-A can access the Internet.

Figure 1 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 Group 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 by devices to communicate data transmission errors in a network. For example, ping can be used to test 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 that use 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 specific IP addresses to access instances in a security group, or allow access from another security group to enable communications between instances in different groups. You can add security group rules to flexibly control the traffic in and out of a network to ensure network security. Here are 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 types of 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 the ECSs in Sg-A over SSH port 22 for remotely logging in to these Linux ECSs.
Inbound rule A02 of Sg-A allows the ECSs in this security group to communicate with each other using any protocol and port. That is, ECSs in Subnet-A can communicate with each other.
Inbound rule B01 of Sg-B allows the ECSs in Sg-A to access the ECSs in Sg-B over 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 specific IP addresses or 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 communication 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 need to:

Add rule A01 to Sg-A. The rule has Source set to Sg-B to allow ECSs in Sg-B to access ECSs in Sg-A.
Add rule B01 to Sg-B. The rule has Source set 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 rules of a security group, 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. Excess rules will not take effect. IPv4 and IPv6 security group rules are counted separately, with up to 120 rules allowed for each.

For outbound rules of a security group, the sum of rules with Destination set to Security group, of the rules with Destination set to IP address group, and of the rules with inconsecutive ports, cannot exceed 120. Excess rules will not take effect.

For example, to add inbound IPv4 rules to a security group (Sg-A), you can refer to Table 3 for rules that meet the constraints. Of these rules, rule A02 uses inconsecutive ports and also specifies a security group 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 ports 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 limited 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.