Control internal network access between ECS instances with security group rules and micro-segmentation.
Security risks
By default, all ECS instances in the same VPC have full network connectivity. This creates security risks such as lateral movement and unauthorized access. For example, a compromised instance can spread threats to other instances on the same network. Internal services often have weak authentication and authorization, making them easy targets.
Security groups can isolate service clusters and block lateral access between instances to mitigate these risks.
Best practices
Isolate service clusters with security groups
Consider two ECS instance clusters: a database cluster and a web server cluster. Instances in the database cluster need to communicate with each other, but those in the web server cluster do not. The goal is to allow the web server cluster to access only the service ports of the database cluster.
Assume the database cluster uses 10.1.0.0/24 and the web server cluster uses 10.2.0.0/24. The service port is 5432 (PostgreSQL default). The goal is to allow only the web server cluster to access port 5432 on the database cluster, and deny all other access. A possible configuration:
-
Create Security Group A. Add an inbound rule to allow traffic from 10.2.0.0/24 to destination port 5432 with priority 1. Attach the database cluster instances to Security Group A.
-
Create Security Group B. Attach the web server cluster instances to Security Group B.
Note: By default, a security group denies all inbound traffic not explicitly allowed and allows all outbound traffic not explicitly denied. No additional deny rule is needed for Security Group A, and no allow rule is needed for Security Group B.
You can use tags to batch-attach ECS instances to a security group. For example, add the tag cluster:PostgreSQL to all database cluster instances and to Security Group A, then run the ACS-ECS-CorrectSecurityGroupInstancesByTags OOS template with the tag value as a parameter. See Use tags to find ECS instances and add them to a security group with the same tag.
Isolate instances within a security group
In the previous example, web server instances do not need to communicate with each other, and the database cluster needs only a few ports for synchronization and management. Allowing all internal communication is unnecessary and increases lateral movement risk.
Micro-segmentation blocks all communication between instances in a security group by default. You must explicitly allow specific ports.
-
Enterprise security groups: Internal isolation is enforced and cannot be modified.
-
Basic security groups: By default, instances can communicate with each other. The system adds a hidden allow rule with the highest priority, and custom rules apply only to external traffic. To disable internal communication, change the internal connectivity policy to internal isolation on the security group product page.
Then, explicitly allow traffic on required internal ports. For example, if the database cluster (10.1.0.0/24) requires port 2379 for internal communication, add a rule to Security Group A to allow inbound traffic from 10.1.0.0/24 to destination port 2379 with priority 1.
Note: If an instance belongs to multiple security groups where one allows internal traffic and another enforces isolation, the combined effect is to allow internal traffic.
Review the combined effect of multiple security groups
An instance can belong to multiple security groups. Rules from all groups are combined and applied by priority. To avoid unexpected results, review the final combined rules on the security group page for the instance.
On the instance details page, click the Security Groups tab, and then select the All Inbound Rules on Intranet subtab. Here, you can view the consolidated list of rules from all associated security groups. The list includes columns such as Priority, Action, Protocol, Port Range, and Source.
Compliance
Check for overly permissive rules
Analyze communication patterns with VPC flow logs to identify overly permissive security group rules and tighten permissions.