sdlc.dev

AWS fundamentals path · The network · Topic 6 of 18

Security groups and network ACLs

Not started

AWS gives you two packet filters in a VPC. A **security group** is attached to network interfaces (instances, tasks, load balancers, databases) and is stateful: it tracks connections, so you write rules only for who may start them. A **network ACL** is attached to subnets, is stateless, evaluates numbered allow and deny rules in order, and judges every packet in both directions on its own.

Why it matters: Security groups are the firewall you will use every day. Network ACLs are a blunter second layer, and mixing them up is a classic cause of connections that hang for no visible reason.

  1. 1Security groups are stateful

    If inbound traffic is allowed, the reply is allowed automatically. You only write rules for who may start a connection.

  2. 2They only allow

    A security group has no deny rules. Traffic matching no rule is dropped.

  3. 3Reference groups, not addresses

    Allow the database's port from the app's security group, and any instance in that group can connect, whatever its IP.

  4. 4NACLs are stateless and ordered

    A network ACL is checked at the subnet boundary in rule-number order, both ways, so return traffic needs its own rule.

1

How it works

The explanation, with examples you can run.

Side by side

Security groupNetwork ACL
Attached toNetwork interfaces (per resource)Subnets
RulesAllow onlyAllow and deny, numbered
EvaluationAll rules considered togetherLowest number first; the first match wins
Return trafficAllowed automatically (stateful)Needs its own rule (stateless)
DefaultNew groups: no inbound, all outboundDefault NACL: allow everything both ways

Security groups, in practice

alb-sg   inbound  443 from 0.0.0.0/0, ::/0app-sg   inbound  8080 from alb-sgdb-sg    inbound  5432 from app-sg

Each tier only admits the tier in front of it, by security group reference rather than by IP range. When the app scales from 3 to 30 tasks, nothing changes: anything with app-sg attached may reach the database, and nothing else may. A resource can have several groups; their rules add up.

Things that catch people out:

  • Because groups only allow, you cannot block a single bad address with one. That is a job for a NACL or AWS WAF.
  • Changing rules affects existing connections differently depending on tracking; the safest assumption is that removing a rule may not cut a connection that is already open.
  • Groups are per VPC. A default group exists in every VPC; avoid using it, so permissions stay explicit.
  • Opening 0.0.0.0/0 on SSH, RDP or a database port is the most common finding in any security review. Use Systems Manager Session Manager instead of open SSH.

Network ACLs, when you need them

The default NACL allows all traffic, and many teams never change it. Custom NACLs are useful as a coarse, subnet-wide backstop: deny a range at the edge of a data subnet, or meet a rule that requires explicit deny lists. Because they are stateless, an inbound allow for port 443 also needs an outbound allow for the ephemeral ports the replies go to, and an outbound call to an API needs an inbound allow for its replies. Forgetting that produces connections that open and then hang, which looks like an application problem.

The AWS guidance is to rely on security groups for fine-grained control and use NACLs sparingly for stateless, coarse rules.

2

Check yourself

3 questions. Get them all right to finish this topic.

  1. 1.A security group allows inbound TCP 443 from anywhere and has no outbound rules. Can clients get responses?
  2. 2.You add a NACL rule allowing inbound 443, but HTTPS connections now hang. A likely cause?
  3. 3.How should a database's security group admit the application servers?

0 of 3 right so far. Get all three to finish this topic.

Go deeper