Security Groups and Network ACLs

What we're doing: See a security group referencing another security group as its source, instead of a hardcoded IP range.

{
  "IpPermissions": [
    { "IpProtocol": "tcp", "FromPort": 443, "ToPort": 443,
      "UserIdGroupPairs": [{ "GroupId": "sg-0alb456" }] }
  ]
}

3

The source is another security group (sg-0alb456, the load balancer's), not a CIDR block.

4

Any instance later added to sg-0alb456 automatically gets this access — nothing on the app side needs to change.

Why this works: Referencing a security group instead of a fixed IP range means the rule stays correct automatically as instances behind the load balancer scale up, down, or get replaced — a hardcoded IP range would need updating every time.

What we're doing: See how rule order changes the outcome for the exact same two rules.

# Order A — DENY evaluated first
Rule 50:  DENY  TCP 443 from 203.0.113.0/24
Rule 100: ALLOW TCP 443 from 0.0.0.0/0
# result: 203.0.113.5 is blocked, everyone else allowed

# Order B — ALLOW evaluated first
Rule 50:  ALLOW TCP 443 from 0.0.0.0/0
Rule 100: DENY  TCP 443 from 203.0.113.0/24
# result: 203.0.113.5 is allowed — rule 50 already matched, rule 100 never evaluated

2

A lower rule number is evaluated first — this DENY at 50 catches the specific range before the broader ALLOW at 100 is reached.

7

With numbers swapped, the broad ALLOW at 50 now matches first for everyone, including 203.0.113.5 — the DENY at 100 never gets a chance to apply.

Why this works: Unlike a security group (where all matching allow rules simply apply, order irrelevant), a network ACL stops at the first matching rule — the same two rules produce opposite results depending purely on their assigned numbers.

What we're doing: Match three different real requirements to the layer that actually solves each one.

# "The app tier should only accept traffic from the load balancer."
→ security group, source = load balancer's security group

# "Block this entire subnet from a known-bad IP range, no exceptions."
→ network ACL, explicit DENY rule

# "Block SQL-injection-looking payloads in incoming HTTP requests."
→ AWS WAF, a rule inspecting the request body/query string

2

This is source-and-port filtering — exactly what a security group is built for, and the simplest layer that solves it.

5

A network ACL's explicit DENY applies subnet-wide with no per-resource exceptions needed — a security group has no deny to express this with.

8

Neither a security group nor a NACL can look inside a request's payload — that needs a layer that actually inspects content.

Why this works: Each requirement names its own natural layer once framed as "what does this rule actually need to know" — source/port, a subnet-wide deny, or the request's content. Reaching for the wrong layer either cannot express the rule at all, or over-complicates a simple one.

What we're doing: See how the same misconfiguration behaves differently with one layer versus three.

# Single layer: security group only, in a public subnet
security group rule accidentally opens 0.0.0.0/0 on port 5432
→ database is immediately internet-reachable

# Layered: private subnet + security group + NACL
security group rule accidentally opens 0.0.0.0/0 on port 5432
→ subnet has no route to an internet gateway, so nothing external can reach it anyway

2

With only one layer, this single mistake is immediately and fully exploitable from the internet.

6

The identical mistake is contained — the private subnet's lack of a route to an internet gateway means there is no path in from outside, regardless of what the security group allows.

Why this works: The security group mistake is identical in both scenarios — what changes is whether any other layer was in a position to limit the damage. Layered design assumes any single layer will eventually be misconfigured, and asks what still holds when it is.

What we're doing: See the NACL rules a server subnet actually needs to both accept requests and let its replies leave.

Inbound:
  100  ALLOW  TCP 443       from 0.0.0.0/0     # the actual request

Outbound:
  100  ALLOW  TCP 1024-65535 to 0.0.0.0/0      # the reply, to the client's ephemeral port

2

This rule alone lets requests reach the server on port 443.

5

Without this rule, the server can receive requests but its replies have nowhere to go — the connection hangs from the client's side.

Why this works: A NACL has no memory of the inbound request when evaluating the outbound reply — the ephemeral port range has to be explicitly allowed outbound, or the request appears to succeed at the server while the client never sees a response.