A security group in AWS is a stateful firewall that controls inbound and outbound network traffic to and from Amazon EC2 instances. It operates at the instance level and enforces rules based on protocol, port, and source/destination IP address. Each rule specifies whether traffic is allowed or denied.
Security groups are stateful, meaning if outbound traffic is allowed, return traffic is automatically permitted-even if no explicit rule exists for it. This behavior differs from traditional firewalls, which are often stateless. Rules are evaluated in order, and the first matching rule determines the action.
Each EC2 instance can be assigned multiple security groups. Traffic is allowed only if it passes through at least one rule in each applied group. This allows fine-grained control across complex workloads. For example, a web server might have one group allowing HTTP (port 80) from anywhere and another restricting SSH (port 22) to a specific IP range.
When a packet reaches an EC2 instance, AWS checks all security groups assigned to that instance. The packet must match at least one rule in each group to be accepted. If any group denies the traffic, the packet is dropped.
Rules are processed in priority order. While AWS doesn't expose rule ordering explicitly, it evaluates rules based on their configuration. A rule allowing port 22 from 0.0.0.0/0 (anywhere) takes precedence over a deny rule unless the deny rule is more specific. Misconfigurations often arise when overlapping rules create unexpected access.
For example, if a security group allows SSH from 192.0.2.0/24 and another allows SSH from 0.0.0.0/0, both apply. The instance remains accessible via SSH from any IP. However, if a deny rule exists for 192.0.2.0/24, it overrides the allow rule only if it's more specific and correctly ordered.
Security groups support two rule types: inbound and outbound. Inbound rules govern traffic entering the instance; outbound rules govern traffic leaving it. Both are required for full communication, even if one direction is restricted.
Each rule includes:
Using a security group ID as a source enables inter-group communication. For example, a database instance can allow inbound MySQL traffic (port 3306) only from a security group assigned to application servers. This creates a trusted zone between services.
| Rule Type | Direction | Common Protocol | Typical Port | Use Case |
|---|---|---|---|---|
| Inbound | Into instance | TCP | 80, 443 | Web traffic |
| Inbound | Into instance | TCP | 22 | SSH access |
| Outbound | From instance | TCP | 443 | HTTPS calls to external APIs |
| Outbound | From instance | ICMP | - | Ping tests |
Amazon recommends using security groups instead of NACLs (Network Access Control Lists) for most scenarios because they're easier to manage and integrate with other AWS services. NACLs operate at the subnet level and are stateless, requiring explicit rules for return traffic.
Many users assume that security groups are static or that rules are evaluated alphabetically. They are not. Rules are evaluated based on their configuration, not order. AWS processes rules in the order they were created, but this is not likely to be consistent across regions or during updates.
A frequent mistake is assuming that a deny rule at the end of a group blocks all traffic. If a preceding allow rule matches, the traffic is still permitted. Deny rules only take effect if no prior allow rule applies.
Another error is using 0.0.0.0/0 for inbound access to sensitive ports. For example, allowing SSH (port 22) from 0.0.0.0/0 exposes the instance to public internet scanning. The correct practice is to restrict access to known IPs or use a bastion host behind a private subnet.
During a deployment audit, we discovered a production instance had SSH access open to the entire internet due to a misconfigured rule. The team had assumed that a later deny rule would override the earlier allow rule. It did not. Only removing the allow rule resolved the exposure.
Use security groups to enforce least privilege. Allow only the minimum necessary ports and sources. Avoid broad ranges like 0.0.0.0/0 unless absolutely required.
Group rules by function. Name groups: e.g., "web-servers-http", "db-prod-mysql". This improves readability and reduces errors during audits.
Integrate with AWS Network Firewall or AWS WAF for additional protection. While security groups handle basic filtering, WAF protects against application-layer attacks like SQL injection and cross-site scripting.
Use AWS Security Hub to monitor compliance across accounts. Security Hub collects findings from multiple services, including GuardDuty and Config, and flags misconfigured security groups. For example, it detects when a group allows unrestricted access to port 22 or 3389 (RDP).
When managing multiple environments, use AWS Organizations and Service Control Policies (SCPs) to enforce security group standards. You can require that all new security groups include at least one deny rule or limit the number of open ports.
For automated enforcement, pair security groups with AWS Config rules. A custom rule can flag any security group that allows port 22 from 0.0.0.0/0 and trigger a notification or remediation action.
A security group in AWS is a stateful firewall that controls network access to EC2 instances. It uses allow/deny rules based on protocol, port, and source/destination. Rules are evaluated across all assigned groups, and traffic must pass all rules to be accepted.