What are security groups and how do they control access?

Question

Accepted Answer

**Security groups** are virtual firewalls that control **inbound and outbound traffic** to AWS resources (like EC2 instances) — defining which ports, protocols, and sources are allowed. They're fundamental to AWS network security.

## What security groups do

```text
A SECURITY GROUP is a virtual firewall attached to resources (EC2, RDS, etc.):
  → INBOUND rules — what traffic can REACH the resource (port, protocol, source)
  → OUTBOUND rules — what traffic the resource can SEND OUT
  → only ALLOW rules (no explicit deny); everything not allowed is DENIED by default
  → STATEFUL — if inbound is allowed, the response is automatically allowed back
```

## Example rules

```text
Inbound rules for a web server:
  Allow TCP 443 (HTTPS) from 0.0.0.0/0   → anyone can reach HTTPS
  Allow TCP 80  (HTTP)  from 0.0.0.0/0   → anyone can reach HTTP
  Allow TCP 22  (SSH)   from <your IP>/32 → ONLY your IP can SSH (not the whole world!)
→ everything else is blocked (default deny)
```

## A powerful pattern: reference other security groups

```text
Rules can allow traffic from ANOTHER security group (not just IPs):
  → DB security group: allow port 5432 FROM the app-server security group
  → means: only the app servers (whatever their IPs) can reach the database
→ Tiered security: web SG → app SG → db SG (each layer only accepts from the previous)
```

## Security groups vs NACLs

```text
SECURITY GROUPS → at the RESOURCE level; stateful; allow-only; the primary tool
NETWORK ACLs (NACLs) → at the SUBNET level; stateless; allow AND deny rules;
  a secondary, coarser layer
→ Use security groups as the main control; NACLs for subnet-wide rules.
```

## Why it matters

Understanding security groups is important because they're fundamental to **AWS network security** — controlling what traffic can reach your resources — so it's essential practical knowledge for deploying resources securely.

Security groups act as **virtual firewalls** defining which traffic (ports, protocols, sources) is allowed to and from resources, with a secure-by-default model (only allow rules; everything not explicitly allowed is denied) and stateful behavior (responses to allowed traffic are automatically permitted).

Understanding how to configure rules correctly is essential for security — for example, allowing HTTP/HTTPS from anywhere for a web server but **restricting SSH access to specific IPs** (not the whole internet — a common, important practice, since exposing SSH to the world is a security risk).

The **powerful pattern of referencing other security groups** (allowing the database's security group to accept traffic only from the app servers' security group, regardless of their IPs) enables clean **tiered security architectures** (web → app → database, each layer only accepting traffic from the previous) — a best-practice approach that limits exposure and follows least privilege at the network level.

Understanding **security groups vs NACLs** (security groups at the resource level as the primary, stateful, allow-only tool; NACLs at the subnet level as a coarser, stateless secondary layer) clarifies the layered network security model.

Since controlling network access to resources is fundamental to AWS security (misconfigured access — like overly-open ports or world-accessible SSH/databases — causes real vulnerabilities), and since security groups are the primary mechanism for this (with the security-group-referencing pattern enabling secure tiered architectures), understanding security groups is essential, practically-important AWS knowledge for deploying resources securely — a core security topic where proper configuration (restricting access appropriately, using tiered security-group references) directly prevents the network-level exposures that lead to breaches.