How Security Groups Filter Traffic

A security group (SG) is a virtual firewall that attaches directly to an elastic network interface (ENI) on a resource such as an EC2 instance, an RDS database, or a load balancer. It controls inbound and outbound traffic at the resource level rather than at the network boundary, so two instances in the same subnet can have very different rules.

Security groups contain allow rules only. There is no way to write an explicit deny. Any traffic that does not match an allow rule is simply dropped. This means you build access by adding the permits you want, and the implicit default is to block everything else.

A brand-new security group denies all inbound traffic and allows all outbound traffic. You open inbound access deliberately, port by port, while egress stays wide open unless you tighten it. Exam scenarios often hinge on remembering that outbound is permissive by default.

Each rule defines a protocol (TCP, UDP, ICMP), a port range, and a source (for inbound) or destination (for outbound). The source can be a CIDR block such as 10.0.0.0/16 or another security group ID, letting you reference groups instead of fixed IPs.

Setting the source to another security group ID creates dynamic, identity-based access. For example, a database SG can allow port 5432 only from the application tier SG. As app servers scale up and down, no IP edits are needed because membership in the referenced group governs access.

Security groups are stateful. When you allow an inbound request, the response is automatically allowed back out regardless of outbound rules, and vice versa. The connection is tracked, so you never write a matching return rule. This is the single biggest behavioral difference from network ACLs.

A single ENI can have several security groups attached at once. Their rules are combined as a union: if any attached group allows the traffic, it is permitted. There is no rule ordering or priority, so you cannot use one group to override another with a deny.

Apply least privilege by opening only the exact ports each tier needs. A web tier might allow 443 from the internet; an app tier allows 8080 only from the web SG; a data tier allows 3306 only from the app SG. This tiered chaining limits lateral movement after a breach.

The most dangerous misconfiguration is allowing 0.0.0.0/0 on port 22 or 3389, exposing SSH or RDP to the whole internet. GuardDuty and Security Hub flag these. Prefer no inbound admin ports at all, using Session Manager instead, which the SSM course covers.

Security groups themselves do not log allowed or denied packets. To see what traffic actually flowed, you rely on VPC Flow Logs, which record the accept or reject decision per connection. Pair SG design with Flow Logs to verify your rules behave as intended.

Security groups are your first and most granular line of network defense inside a VPC, working at the instance level. They complement subnet-wide network ACLs and application-layer tools like WAF. Mastering their stateful, allow-only, union behavior is essential for the SCS-C02 exam.

Test your grasp of security group behavior.

Security groups are stateful, allow-only virtual firewalls attached at the resource ENI. New groups deny all inbound, allow all outbound. Rules specify protocol, port, and a source that can be a CIDR or another group ID. Multiple groups combine as a union with no deny or ordering. Avoid open admin ports, and use Flow Logs to observe traffic since SGs do not log.