Elastic Compute Service:Security group guidelines and use cases

Security group guidelines

1. Identify needs and plan security groups

Define your business needs and specific security requirements. For example, determine which services must be publicly accessible and which must be restricted to internal access.

• Isolate servers for public and internal services in different security groups

  Exposing unnecessary service ports can create security vulnerabilities. Apply the strictest rules to the security groups for your ECS instances. Adopt a default-deny policy, which closes all ports and protocols by default and opens only the specific ports that your services require.

  A security group for public-facing servers should have a clear and simple purpose. Avoid running other services, such as MySQL or Redis, on the same server. We recommend that you install these backend services on an ECS instance that does not have a public IP address. Then, grant access by creating a security group rule that authorizes access from another security group.

• Use different security groups for different applications

  In a production environment, servers with different operating systems or applications typically do not belong to the same group for load balancing. Different services require different ports to be opened or closed. Assign resources with different roles to different security groups.

  For example, a Linux instance may require TCP port 22 for SSH access, while a Windows instance may require TCP port 3389 for Remote Desktop connections.

  Even if instances use the same image type but provide different services, you should assign them to different security groups if they do not need to communicate over the internal network. This approach decouples your services, simplifies future rule changes, and ensures each security group has a single responsibility.

  When you plan and add new applications, you should plan your security groups just as you plan your subnets with vSwitches. Use both CIDR blocks and security groups to define clear boundaries between service providers and consumers.

• Use separate security groups for production and test environments

  To better isolate systems, you might build multiple test environments and one production environment. To properly isolate your networks, configure different security policies for each environment. This prevents changes in a test environment from accidentally affecting the stability of your production environment.

  By creating different security groups, you can restrict application access domains and prevent communication between production and test environments. You can also assign different security groups to multiple test environments to prevent them from interfering with each other, which improves development efficiency.

• Do not assign public IP addresses to resources that do not require public access

  Connect to an ECS instance by using methods that do not require a public IP address, such as Workbench, Session Manager, or a jump server, to minimize public exposure. To directly access a service deployed in a private network, you can use the port forwarding feature. For more information, see Use port forwarding of Session Manager CLI to access instances that do not have public IP addresses.

  In a distributed application, resources are often separated into different tiers and groups. For an ECS instance that does not provide public services, do not assign a public IP address. If you have multiple servers that provide public access, use SLB to distribute public traffic. This improves system availability and prevents single points of failure. For more information, see .

  Within a VPC, if an ECS instance without a public IP address needs to access the internet, use a NAT gateway. It acts as a proxy for internet access. You only need to configure SNAT rules for a specific CIDR block or subnet to enable public access. This prevents you from exposing services to the internet by assigning a public IP address (or elastic IP address) when only outbound internet access is required. For more information, see Create and manage SNAT entries.

• Use security groups as whitelists

  A security group should function as a whitelist. By default, it denies all access. You can add allow rules to permit traffic on specific port ranges from authorized sources. Open as few ports and assign as few public IP addresses as possible. Associating an elastic IP address is a convenient way to access a production machine for troubleshooting, but it exposes the entire machine to the internet.

2. Configure security group rules

A security group acts as a virtual firewall that controls inbound and outbound traffic for an ECS instance. You should open only necessary communication ports and restrict source IP address ranges as much as possible.

In a VPC, a single security group rule can control both public and private network access. This means you can configure one rule to restrict or allow traffic from both the internet and your internal network.

• Default policies differ between basic and advanced security groups

  By default, both basic security groups and advanced security groups deny all inbound traffic. However, their outbound policies differ: a basic security group allows all outbound traffic, whereas an advanced security group denies it.

• Internal connectivity differs across security groups and security group types

  Even if they belong to the same account, ECS instances in different security groups are isolated from each other over the internal network. By default, instances within the same basic security group can communicate with each other, while instances within the same advanced security group are isolated from each other.

• Add rules based on the principle of least privilege

  For example, when you open port 22 on a Linux instance for remote login, allow access only from specific IP addresses.

  Warning

  Authorizing access from 0.0.0.0/0 allows all IP addresses to access the instance, which exposes all ports. This is highly insecure. The correct practice is to deny access to all ports by default. For example, if you need to expose web services, you should open only common TCP ports such as 80, 8080, and 443, and keep all other ports closed.

  Configure security group rules based on your business needs and the principle of least privilege. Avoid opening all ports (use ::/0 or 0.0.0.0/0 with extreme caution) to prevent security risks. For more information about the types of authorization objects, see Security group rules.

• Isolate instances within a group based on the principle of least privilege

  If instances in a basic security group do not need to communicate with each other, set the internal access policy for the security group to isolate the instances.

• Keep the purpose of rules within a single security group consistent

  Organize rules into multiple security groups based on their purpose and associate instances with the relevant groups. A single security group with too many rules increases management complexity.

• Choose authorization objects carefully

  The authorization object for a security group rule can be an IP address, another security group, or a CIDR block.

  If you want to enable network communication between resources in different security groups, you should authorize access by security group. For example, for a distributed application, you may use different security groups for different components. If these security groups cannot communicate with each other, you should not authorize access by IP address or CIDR block. Instead, you should directly authorize access from all resources in the other security group. For instance, if you created separate security groups for the web and database components of your application, sg-web and sg-database, you can add a rule to sg-database. This rule authorizes all resources in the sg-web security group to access the MySQL (3306) port.

  For internal network access, authorize a source security group instead of a CIDR block.

• Typical applications use default ports

  Applications use specific server ports to communicate with external services. For more information, see Common ports.

3. Continuously review and optimize rules

As your business evolves, your existing security groups and rules may become outdated. Regularly review your architecture and make adjustments based on the latest security conditions. Before you modify a security group in a production environment, first clone it and test the rules in a test environment to ensure traffic flows correctly. Then, apply the changes to the production security group. This practice helps prevent service interruptions caused by incorrect modifications.

Use cases

Control inbound traffic to ECS instances

Inbound traffic is traffic from external resources to your ECS instances. You can configure inbound security group rules to allow specified users to access services deployed on your ECS instances. By default, all inbound traffic is denied, so you need to configure only Allow rules for the traffic you want to permit. Relevant use cases include:

• Case 1: Provide web services from a website deployed on an ECS instance

• Case 2: Allow remote access for specific users to an ECS instance

• Case 3: Implement security policies for databases deployed on ECS instances

• Case 4: Allow access for only specific protocols

• Case 5: Enable internal communication between instances in different security groups

Control outbound traffic from ECS instances

Outbound traffic is traffic from your ECS instances to external resources. You can configure outbound security group rules to deny access from your ECS instances to specified external resources. For a basic security group, all outbound traffic is allowed by default, so you need to add only Deny rules for traffic you want to block. A relevant use case includes:

• Case 6: Restrict outbound access from an ECS instance to external websites

Case 1: Provide web services

Case 2: Allow remote access

Case 3: Configure database security

Case 4: Allow specific protocols

Case 5: Enable internal communication

• Scenario 1: Security groups in the same account

  If Security Group A and Security Group B belong to the same account, set the authorization object to the ID of the source security group. The following table shows an example of this security group rule configuration.

  Rule direction	Action	Priority	Protocol type	Port range	Authorization object
  Inbound	Allow	1	Custom TCP	21/21	sg-bp1hv6wvmegs036****

  Note

  Replace the example security group ID with your actual value.

• Scenario 2: Security groups in different accounts

  If Security Group A and Security Group B belong to different accounts, set the authorization object to the ID of the source Alibaba Cloud account and the ID of the source security group. The following table shows an example of this security group rule configuration.

  Rule direction	Action	Priority	Protocol type	Port range	Authorization object
  Inbound	Allow	1	Custom TCP	21/21	160998252992****/sg-bp174yoe2ib1sqj5****

  Note

  Replace the example Alibaba Cloud account ID and security group ID with your actual values.

Case 6: Restrict outbound access