A security group is a virtual firewall that controls inbound and outbound traffic for ECS instances, isolating resources into security domains by trust level.
How it works
Each ECS instance must belong to at least one security group. Rules from all associated groups are evaluated by priority to allow or deny traffic.
Rules take effect immediately. Each rule specifies source (inbound) or destination (outbound), port range, protocol, policy (Allow/Deny), and priority. See Security group rules.
Rules apply to the primary elastic network interface (ENI) by default. For secondary ENIs attached to an instance in a VPC, you can assign different security groups to implement fine-grained traffic control.
Constraints:
Security groups are regional and VPC-specific. The vSwitch and security group must belong to the same VPC.
An instance or ENI must belong to at least one security group. See Limits for group quotas.
If no security group is specified during launch, the instance uses the VPC's default security group. See Default security groups.
In the following figure, a VPC contains ECS 1 and ECS 2. Both use the primary ENI and belong to Security Group 1. Security Group 1 is a basic security group with default intra-group connectivity. ECS 1 and ECS 2 can communicate over the internal network by default. Custom rules govern inbound and outbound access. For example, if inbound rules allow ICMP, any IP can ping these instances. If no outbound rules exist, all outgoing traffic is allowed.
Security group types
Basic and advanced security groups
Security groups are classified as basic or advanced. Both are free. In the API, the SecurityGroupType parameter is Basic (normal) and Advanced (enterprise).
Basic security group: Instances communicate by default (intra-group connectivity). Rules can reference other security group IDs (e.g., sg-123) as source/destination. Supports fewer private IP addresses.
Advanced security group: No implicit intra-group connectivity. Rules must use IP addresses or CIDR blocks (e.g., 10.0.0.0/24). Supports more private IP addresses.
An ENI's associated security groups must all be the same type. See Basic and advanced security groups.
Custom and managed security groups
Security groups are also classified as custom or managed. Both can be basic or advanced.
Custom security group: Created and managed by you via the ECS console or API. You control rules and lifecycle. The default security group is a custom security group. See Create a security group.
Managed security group: Created by cloud services and read-only. See Managed security groups.
To identify a managed security group, check whether ServiceManaged returns True in the DescribeSecurityGroups API, or the console shows a Managed by Cloud Service banner.
Best practices
Follow these guidelines to secure your ECS instances:
Establish a naming convention
Use clear names and tags for security groups. Consistent tagging simplifies filtering and management at scale.
Treat security groups as whitelists
Deny all access by default. Only add rules that explicitly authorize traffic for specific ports and source IPs.
Principle of Least Privilege (PoLP)
Grant only the minimum access required. For example, restrict port 22 (SSH) to your office CIDR or bastion host IP instead of
0.0.0.0/0.Follow the principle of least privilege
If instances in a basic security group do not need internal communication, set the intra-group policy to internal isolation.
Keep rules simple
Group rules by purpose into separate security groups. Too many rules in one group increases management complexity. Use the health check feature to remove unused rules.
Isolate instances by application role
Place public-facing instances in a security group that only opens ports 80/443. Place database instances (MySQL, Redis) in a separate group that blocks public internet access and only accepts traffic from the application tier.
Never modify a production security group directly
Clone the group to a staging environment, apply and validate changes, then apply to production.