Security groups
A security group is a stateful firewall attached to a network interface. It is the primary access control in a VPC.
What it attaches to
Section titled “What it attaches to”Security groups attach to elastic network interfaces, and therefore to anything that has one:
- EC2 instances
- Load balancers
- RDS instances
- Interface VPC endpoints
- Lambda functions with VPC access
- ECS tasks in
awsvpcmode
A security group is not associated with a subnet, a VPN, an Availability Zone or a Region. It applies at the interface, wherever that interface happens to be. The subnet-level equivalent is a network ACL.
An interface can carry several security groups; their rules are combined, and traffic matching any of them is allowed.
Security groups belong to a VPC. One cannot be used in another VPC or Region, and a rule in one VPC cannot reference a security group in another — except across a peering connection or between accounts sharing a VPC, where referencing is supported in the same Region.
- Allow rules only. There is no deny. To block a specific address range, use a network ACL.
- Stateful. Return traffic for an allowed connection is permitted automatically, whichever direction the connection was initiated in. Ephemeral ports do not need rules.
- All rules are evaluated, and traffic is allowed if any rule permits it. There is no ordering and no first-match.
- Rules may specify protocol, port range and either an IP range, a managed prefix list, or another security group.
- By default, a new security group denies all inbound traffic and allows all outbound.
Referencing another security group
Section titled “Referencing another security group”A rule whose source is another security group — “allow TCP 5432 from sg-app” — is what makes security groups scale. The rule stays correct as instances are launched and terminated, and it expresses the intent (the application tier may reach the database) rather than an address list that has to be maintained.
Prefer this over CIDR-based rules for traffic between tiers. Reserve CIDR rules for traffic from outside the VPC.
Security groups and network ACLs together
Section titled “Security groups and network ACLs together”| Security group | Network ACL | |
|---|---|---|
| Level | Network interface | Subnet |
| State | Stateful | Stateless |
| Rules | Allow only | Allow and deny |
| Evaluation | All rules | Ordered, first match wins |
| Sources | CIDR, prefix list, or another security group | CIDR only |
Use security groups for the working policy and network ACLs as a coarse subnet backstop.
Practice
Section titled “Practice”- Default to denying inbound and opening only what is needed.
- Tighten the default outbound rule where the workload’s egress is predictable —
0.0.0.0/0outbound is a data exfiltration path. - Name and tag security groups by role, not by instance, so a rule referencing them reads as intent.
- Watch the quota on rules per security group and security groups per interface; a design that needs many rules per group is usually one that should be referencing groups instead of addresses.