In practice, you may have a tendency to place all Elastic Compute Service (ECS) instances within a single security group to reduce initial configuration workloads. However, in the long run, this practice may make business system interactions more complex and less controllable. When you add rules to or remove rules from the security group, you cannot identify the impact scope of the rules. Plan and define security groups properly to make your systems easier to adjust. Sort out the services provided by applications and classify the applications into different levels. We recommend that you plan different security groups for different business and add different rules to the security groups.
Create different security groups
Create different security groups for ECS instances that provide Internet-facing services and those that provide internal network-facing services.
The applications on an ECS instance may be accessible over the Internet regardless of whether the instance provides Internet-facing services, including proactively exposing specific ports (such as ports 80 and 443) for external access and passively providing port forwarding rules (such as NAT port forwarding rules and forwarding rules based on the system-assigned public IP address or elastic IP address of the instance).
In the two preceding scenarios, use the strictest security group rules for the instance. We recommend that you first add a rule to deny access from all protocols on all ports and then add rules to allow access only to ports required by external services, such as ports 80 and 443. The security group contains only Internet-facing ECS instances. It is easy to adjust the rules in the security group.
The security group that contains Internet-facing ECS instances must have clear and simple responsibilities to ensure that the instances provide no services other than primary services. For example, for MySQL and Redis applications, we recommend that you deploy them on ECS instances that do not provide Internet access, and then configure security group rules to allow access from specific security groups to the instances.
Assume that an Internet-facing ECS instance named ECS_WEB_1 and some applications belong to the SG_CURRENT security group. You can perform the following steps to change the security group of the ECS_WEB_1 instance:
Identify the protocols and ports used to provide Internet-facing services, such as ports 80 and 443.
Create a security group named SG_WEB and add a rule with the following attributes to the SG_WEB security group. For more information, see Create a security group.
Action: Allow
Protocol type: All
Port range: 80/80 and 443/443
Authorization object: 0.0.0.0/0
Add a rule with the following attributes to the SG_CURRENT security group to allow access from the SG_WEB security group. For more information, see Add security group rules.
Action: Allow
Protocol type: All
Port range: -1/-1
Authorization object: SG_WEB
Priority: Select a value in the range of 1 to 100 based on your requirements.
Add the ECS_WEB_1 instance to the SG_WEB security group.
Log on to the ECS console.
In the left-side navigation pane, choose .
Find the SG_WEB security group and choose
> Manage Instances in the Actions column. On the ECS Instances tab, click Add Instance to Security Group.
In the Add Instance dialog box, select ECS_WEB_1 from the drop-down list and click OK. Confirm that data can be transferred to or from the ECS_WEB_1 instance and that the network of the instance works normally.
Remove the ECS_WEB_1 instance from the SG_CURRENT security group.
Log on to the ECS console.
In the left-side navigation pane, choose .
Find the SG_CURRENT security group and choose
> Manage Instances in the Actions column. On the ECS Instances tab, select the ECS_WEB_1 instance that you want to remove from the security group and click Remove from Security Group in the lower part of the tab.
In the Remove ECS Instance from Security Group message, click OK.
Check the network connectivity of the instance to ensure that data can be transferred to or from the instance and that the network of the instance works normally.
If the ECS_WEB_1 instance fails the network connectivity check, add the instance back to the SG_CURRENT security group. Then, check whether ports in the SG_WEB security group are exposed as expected. If yes, proceed with security group changes. If no, modify the port settings.
Proceed with security group changes.
Use different security groups for different applications
In most cases, different operating systems in a production environment do not belong to the same application group for load balancing. To provide different services, operating systems must have different ports exposed and blocked. We recommend that you assign different operating systems to different security groups.
For example, for a Linux operating system, you may need to expose TCP port 22 to allow SSH connections. For a Windows operating system, you may need to expose TCP port 3389 to allow Remote Desktop Protocol (RDP) connections.
If instances that use the same image but provide different services do not need to communicate with each other over the internal network, we recommend that you also assign these instances to different security groups. This helps decouple image types from security groups, simplify subsequent changes to security group rules, and ensure that instances have simple responsibilities.
When you plan and add new applications, you must properly plan security groups in addition to using vSwitches to define subnets. Use CIDR blocks and security groups to distinguish yourself as a service provider or a consumer.
For specific change procedures, see the preceding section.
Use different security groups in production and testing environments
To better isolate systems, you may build multiple testing environments and a single production environment in actual development. You may need to configure different security group rules for different environments to properly isolate networks. This way, you can prevent changes made for testing purposes from being uploaded to the production environment and affecting the stability of the production environment.
You can use security groups to confine access domains of applications and avoid communication between production and testing environments. You can also assign different security groups to different testing environments to block traffic between the environments and improve development efficiency.
Only assign public IP addresses to ECS instances that require Internet access
For the classic network or virtual private clouds (VPCs), proper allocation of public IP addresses facilitates Internet access management and reduces the attack surface of systems. In VPCs, we recommend that you allocate ECS instances that require Internet access to several specified vSwitches. This makes it easy to audit and distinguish the instances and helps avoid unexpected exposure of ECS instances for Internet access.
Most distributed applications have different layers and groups. For ECS instances that do not provide Internet access, we recommend that you do not assign public IP addresses. If multiple instances that provide Internet access, we recommend that you configure Server Load Balancer (SLB) to distribute Internet traffic to improve system availability and avoid single points of failure. For more information, visit the Server Load Balancer product page.
For ECS instances that do not need to access the Internet, we recommend that you do not assign public IP addresses. In VPCs, if your ECS instances do not have public IP addresses but do require Internet access, we recommend that you use NAT gateways to provide Internet proxy services for the instances. You need only to configure SNAT entries to provide Internet access for specific CIDR blocks or subnets. This way, you can avoid exposing services to the Internet after public IP addresses are assigned, when only outbound Internet access is required. For more information, see Create and manage SNAT entries.
Principle of least privilege
Security groups are expected to work like whitelists. Therefore, open and expose as few ports as you need and allocate as few public IP addresses as you need. You can associate elastic IP addresses with online ECS instances to allow easy access to the instances for task log queries and troubleshooting. However, this operation exposes the instances to the Internet. We recommend that you use jump servers instead to manage ECS instances to improve security.
Use a jump server
A jump server has much higher permissions. You must use tools to thoroughly record and audit relevant operations. We recommend that you assign the jump server to a dedicated vSwitch in a VPC and then associate the corresponding elastic IP address or NAT port forwarding table with the jump server.
Create a dedicated security group named SG_BRIDGE and open required ports. For example, open TCP port 22 for Linux operating systems and RDP port 3389 for Windows operating systems. To restrict inbound access to the security group, you can allow only specified public IP addresses of your enterprise to access the security group. This way, you can reduce the probability that resources are scanned or accessed.
Add the ECS instance that functions as a jump server to the security group. To allow the jump server to access ECS instances in another security group, you can configure a rule that allows access to that security group for the jump server. For example, you can add a rule to a security group named SG_CURRENT to allow access from the SG_BRIDGE security group to specific protocols and ports.
When you use the jump server for SSH communication, we recommend that you use SSH key pairs to log on to ECS instances. For more information, see Overview.
In summary, proper planning of security groups makes it easy for you to scale applications and improve the security of your system.