Security Groups vs NACLs and Ephemeral Ports

By the end of this lesson you will be able to

• Explain the two firewall layers of a VPC and where each one sits.
• Write security group rules, including rules that reference other security groups.
• Write network ACL rules, apply “first match wins”, and avoid the custom-NACL and rule-order traps.
• Explain stateful vs stateless filtering and add the ephemeral-port rules that stateless filtering needs.
• Build a complete rule set for a web tier and a database tier, and debug “timeout” vs “connection refused”.

#Two layers of firewall

Every packet that enters or leaves an instance in a VPC can be filtered twice:

• A network ACL (NACL) at the subnet boundary. It checks every packet entering or leaving the subnet.
• A security group (SG) around each instance (strictly, around each network interface). It checks packets entering or leaving that one instance.

Traffic from the internet to a web server passes the subnet’s network ACL first, then the instance’s security group. The reply leaves through the security group and then the network ACL.

#Security groups

A security group is a set of allow rules. Each rule names a protocol, a port range and a source (for inbound) or destination (for outbound). The source can be:

• a CIDR block, for example 0.0.0.0/0 (anyone) or 203.0.113.25/32 (one address);
• another security group, meaning “any network interface that has that security group attached”;
• a managed prefix list (a named list of CIDR blocks).

How security groups behave:

Security groups operate outside the instance: blocked traffic never reaches the operating system, so the instance cannot see it or log it.

#Referencing other security groups

The most powerful feature is using a security group as the source of a rule. Instead of “allow port 3306 from 10.0.1.0/24”, you write “allow port 3306 from sg-web”. Then:

• any instance with sg-web attached can connect, wherever it is in the VPC;
• new web servers launched by an Auto Scaling group are allowed automatically;
• nothing else in the same subnet is allowed, even with a neighbouring address.

This is how tiers are chained: load balancer → web servers → database, each group allowing only the group in front of it. It works within a VPC, and across peered VPCs in the same Region.

#Ports you must recognise

A real example: a WordPress site on one EC2 instance. Everyone must see the site, so the security group allows HTTP (80) and HTTPS (443) from 0.0.0.0/0. You also need SSH (22) to maintain the server, but only from your own home or office address, for example 203.0.113.25/32, never from 0.0.0.0/0. On the exam, port 22 open to 0.0.0.0/0 is always the “bad practice” option.

#Network ACLs

A network ACL is a numbered list of allow and deny rules applied at the subnet boundary.

Network ACLs can only reference CIDR blocks, never security groups.

#Default vs custom network ACLs

This is one of the most frequently tested traps:

• The default NACL (created with every VPC) allows all inbound and all outbound traffic.
• A custom NACL you create denies all inbound and all outbound traffic until you add rules.

#Stateful vs stateless and ephemeral ports

Every TCP connection has two ends, and both use a port:

• The server listens on a well-known port: 80, 443, 3306…
• The client uses a temporary port chosen by its operating system for this one connection: an ephemeral port.

So a browser on 198.51.100.20 might send 198.51.100.20:50105 → 10.0.1.10:80, and the reply travels 10.0.1.10:80 → 198.51.100.20:50105. The reply goes to the client’s ephemeral port.

A stateful security group handles this for you. A stateless network ACL does not: its outbound rules must allow the replies to the clients’ ephemeral ports, and if your servers are the clients (calling a database or an API), its inbound rules must allow the replies coming back to their ephemeral ports.

Ephemeral port ranges differ by system:

Because a public web server’s clients can be anything, the usual rule is TCP 1024–65535, which covers all of them.

#Security groups vs network ACLs

In practice, most designs put precise rules in security groups and keep network ACLs simple (often the default), adding NACL rules for subnet-wide guardrails or to block known bad addresses.

#A complete two-tier rule set

A classic exam scenario: VPC 10.0.0.0/16, a public web subnet 10.0.1.0/24 serving HTTP/HTTPS, and a private database subnet 10.0.2.0/24 running MySQL on port 3306.

Web subnet NACL, inbound

Web subnet NACL, outbound

Database subnet NACL, inbound

Database subnet NACL, outbound

Three things worth noticing in this design:

• Web outbound rule 110 is redundant: rule 100 (1024–65535 to anywhere) already covers 3306 and is checked first. It does no harm and documents intent, but it is not what allows the traffic.
• Rule 50 blocks all traffic, not just port 80. A deny on port 80 alone would still let the attacker in on 443 through rule 110.
• The web servers cannot start outbound connections to the internet on 80/443 (for example, to download updates): outbound only allows high ports. That is fine for a strict design, but updates would then need a proxy, a NAT path with matching rules, or VPC endpoints.

The matching security groups are simpler, because they are stateful and can reference each other:

#Try it yourself

# Security groups: web allows HTTPS from anywhere, db allows MySQL only from the web group
WEB=$(aws ec2 create-security-group --group-name web --description web --vpc-id $VPC --query GroupId --output text)
DB=$(aws ec2 create-security-group --group-name db --description db --vpc-id $VPC --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $WEB --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id $DB --protocol tcp --port 3306 --source-group $WEB

# Network ACL: block one address with a low rule number
aws ec2 create-network-acl-entry --network-acl-id $NACL --ingress --rule-number 50 \
  --protocol -1 --cidr-block 203.0.113.50/32 --rule-action deny

# Debug from a client: timeout vs refused
curl -m 5 http://203.0.113.25/     # "timed out" → firewall; "Connection refused" → no app listening

#Summary

Key takeaways

• A VPC has two filters: network ACLs at the subnet boundary and security groups at each instance.
• Security groups: allow rules only, stateful, all rules evaluated together, can reference other security groups; new groups block all inbound and allow all outbound.
• Network ACLs: allow and deny, stateless, numbered and first match wins, end with a * deny, CIDR blocks only, one per subnet. Use them to block specific IPs.
• Default NACL allows everything; a new custom NACL denies everything.
• Replies go to the client’s ephemeral port. Stateless NACLs need explicit rules for them; 1024–65535 covers every client type (Linux uses 32768–60999, Windows 49152–65535).
• “Request arrives, reply never does” → network ACL. Timeout → a firewall; connection refused → no application listening.
• Chain tiers with security groups that reference each other (sg-db allows 3306 from sg-web); never open a database port to 0.0.0.0/0.

Self-check: security groups and network ACLs32 questions