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

• 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.
• You can use security groups free of charge.

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 Group and Rules. You can also customize security group rules. For details, see Configuring Security Group Rules.

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.

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 non-consecutive 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 non-consecutive 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 1 for rules that meet the constraints. Of these rules, rule A02 uses non-consecutive ports and also specifies a security group as the source. In this case, only one quota is used.

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

Security Group Application Guidance

Proper security group rule configuration is vital for cloud service protection. The following provides practical guidance for building a secure and reliable network.

1. Analyzing Service Requirements and Planning Security Groups

   Analyze the service architecture to identify public and internal services, and then define tailored security group rules based on their specific requirements.

   • Use different security groups to isolate public and private cloud servers.

     Associate public and private cloud servers with different security groups for network isolation. The security group rules must follow the principle of least privileged access. By default, all ports and protocols are disabled. Only those required for services are explicitly enabled.

     If you have web servers that are accessible from the Internet, associate these servers with the same security group that only allows traffic over specific ports (such as ports 80 and 443) and denies all other external access requests by default. Do not run internal services, such as MySQL and Redis databases, on web servers that can be accessed from the Internet. Instead, deploy them on ECSs that cannot be accessed from the Internet, associate these ECSs with a dedicated security group, and use security group rules to authorize instances in other security groups to access the databases, minimizing the risk of exposing the internal services to the Internet.

   • Associate cloud servers running different OSs or applications with different security groups.

     Associate cloud servers running different OSs or applications with different security groups for refined access control. For example, open port 22 (SSH) for Linux cloud servers for remote management and port 3389 (RDP) for Windows cloud servers. Even cloud servers with identical system images should be associated with different security groups if they run different applications. This allows stronger isolation and flexible management.

   • Associate cloud servers in different environments with different security groups.

     To ensure stability and security, associate cloud servers in the production and test environments with different security groups. Use the access control function of security groups to isolate networks between different environments and prevent test changes from affecting the production environment. Additionally, associate different security groups with cloud servers in different test environments (such as development and integration test) to avoid cross-environment interference and enhance efficiency.

   • Control public network access and avoid assigning EIPs to cloud servers that do not require it.

     Huawei Cloud provides multiple secure and reliable public network access solutions. Do not assign EIPs to cloud servers unless necessary.

     • If you only need to log in to an ECS, use secure channels such as CBH, CloudShell, or VNC.
     • If your services running on multiple cloud servers need to be accessed from the Internet, use ELB to distribute public traffic. ELB prevents single points of failure, improves service availability, and reduces security risks.
     • If your cloud servers need to access the Internet, use a NAT gateway. A NAT gateway enables cloud servers without EIPs in a VPC to access the Internet by configuring SNAT rules, enabling multiple cloud servers to share an EIP for Internet access.
2. Configuring Security Group Rules
   • Default security group

     If no security group is created, the system automatically generates a default one upon first use. The default security group only allows instances in the security group to communicate with each other but denies all external requests by default. For details, see Default Security Group Overview.

   • Internal network isolation for different security groups by default

     Cloud servers under the same account are isolated by default if they are associated with different security groups.

   • Whitelist principle for security group rules

     Security group rules follow the whitelist principle, which is the basis of a secure system. Instances in a security group deny all external access requests by default, but you can add rules to allow specific requests. You should open only the minimum set of ports required by services.

   • Least privilege principle for security group rules

     When adding a security group rule, grant the minimum permissions possible. For example, only allow specific IP addresses to log in to a cloud server using SSH (port 22) or RDP (port 3389). Do not use 0.0.0.0/0 (all IP addresses).

   • Using IP address groups to reduce the number of security group rules

     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. If an IP address changes, updating it in the group automatically applies the change to all associated rules. This improves efficiency. For details, see Using IP Address Groups to Reduce the Number of Security Group Rules.

   • Typical service ports

     Applications use standard communication ports. You need to allow the corresponding ports in the security group based on your service requirements. For details, see Common ECS Ports.

3. Maintaining Security Groups and Rules

   As services evolve, existing security groups and rules may become outdated. You are advised to periodically review your architecture and update security groups to align with current requirements. To avoid disrupting live services, avoid modifying in-use rules directly. Instead, clone the security group, validate network functionality with the cloned group, and then apply necessary changes. This approach minimizes service impact. For details, see Cloning a Security Group.