Network ACLs overview in AWS - Deep Dive

Overview - Network ACLs overview

What is it?

Network ACLs (Access Control Lists) are rules that control traffic going in and out of a network in the cloud. They act like a security guard at the entrance of a neighborhood, deciding who can come in or leave based on simple yes or no rules. These rules apply to all devices in a network segment, helping protect the network from unwanted access. They work alongside other security tools to keep cloud networks safe.

Why it matters

Without Network ACLs, cloud networks would be open to any traffic, including harmful or unwanted data. This could lead to security breaches, data loss, or service interruptions. Network ACLs help prevent these problems by filtering traffic early, reducing risks and keeping cloud resources safe. They provide a basic but important layer of defense that helps maintain trust and reliability in cloud services.

Where it fits

Before learning about Network ACLs, you should understand basic networking concepts like IP addresses and traffic flow. After this, you can learn about more detailed security tools like Security Groups and firewall rules. Network ACLs fit into the bigger picture of cloud network security and management.

Mental Model

Core Idea

Network ACLs are simple, rule-based filters that allow or block traffic entering or leaving a cloud network segment.

Think of it like...

Network ACLs are like a neighborhood gatekeeper who checks each visitor's ID against a list of allowed or blocked people before letting them in or out.

┌─────────────────────────────┐
│       Network ACL Rules      │
├─────────────┬───────────────┤
│   Rule #    │   Action      │
├─────────────┼───────────────┤
│  100 Allow  │ Allow traffic │
│  110 Deny   │ Block traffic │
│  120 Allow  │ Allow traffic │
└─────────────┴───────────────┘

Traffic Flow:
Inbound Traffic ──> [Network ACL] ──> Network
Outbound Traffic <── [Network ACL] <── Network

Build-Up - 7 Steps

1

Foundation

What is a Network ACL?

Concept: Introduce the basic idea of Network ACLs as traffic filters.

Network ACLs are sets of rules that control which data packets can enter or leave a cloud network. They work at the subnet level, meaning they apply to all devices inside that subnet. Each rule either allows or denies traffic based on IP addresses, ports, and protocols.

Result

You understand that Network ACLs act as simple gatekeepers for network traffic in cloud environments.

Knowing that Network ACLs filter traffic at the subnet level helps you see their broad impact on network security.

2

Foundation

How Network ACL Rules Work

Concept: Explain the structure and order of rules in a Network ACL.

Each Network ACL has numbered rules. Rules are checked in order from lowest to highest number. When a rule matches the traffic, its action (allow or deny) is applied immediately. If no rule matches, the default action is to deny the traffic. Rules specify source/destination IP, protocol (like TCP), and port ranges.

Result

You can predict how traffic is allowed or blocked based on the rules' order and content.

Understanding rule order is key to controlling traffic precisely and avoiding unexpected blocks or allows.

3

Intermediate

Inbound vs Outbound Rules

🤔Before reading on: Do you think inbound and outbound traffic use the same rules or separate ones? Commit to your answer.

Concept: Network ACLs have separate rule sets for incoming and outgoing traffic.

Network ACLs have two sets of rules: one for inbound traffic entering the subnet and one for outbound traffic leaving it. Both sets work independently, so you must configure rules carefully on both sides to allow desired communication.

Result

You realize that allowing traffic in one direction does not automatically allow it in the other.

Knowing inbound and outbound rules are separate prevents common mistakes where traffic is blocked unexpectedly.

4

Intermediate

Stateless Nature of Network ACLs

🤔Before reading on: Do you think Network ACLs remember past traffic to allow responses automatically? Commit to yes or no.

Concept: Network ACLs do not track connection state; each packet is checked independently.

Unlike some security tools, Network ACLs are stateless. This means they do not remember if a connection was allowed before. So, you must create rules to allow both request and response traffic explicitly. For example, if you allow inbound web traffic, you must also allow outbound response traffic.

Result

You understand why Network ACLs require rules for both directions of traffic.

Recognizing statelessness helps you design complete rules that avoid accidental traffic blocks.

5

Intermediate

Default Network ACL Behavior

Concept: Explain the default settings and how they affect traffic.

Every subnet has a default Network ACL that allows all inbound and outbound IPv4 traffic and allows all IPv6 traffic. This default is open and permissive. When you create custom Network ACLs, the default rule is to deny all traffic unless explicitly allowed.

Result

You know that custom Network ACLs start with a deny-all baseline, requiring explicit rules to allow traffic.

Understanding defaults helps avoid surprises when custom rules block traffic unexpectedly.

6

Advanced

Using Network ACLs with Security Groups

🤔Before reading on: Do you think Network ACLs and Security Groups serve the same purpose or different roles? Commit to your answer.

Concept: Network ACLs and Security Groups work together but have different scopes and behaviors.

Security Groups act as virtual firewalls for individual cloud resources, tracking connection state and applying rules per resource. Network ACLs apply at the subnet level and are stateless. Using both together provides layered security: Network ACLs filter broad traffic, while Security Groups provide fine-grained control.

Result

You see how combining these tools strengthens cloud network security.

Knowing the complementary roles of Network ACLs and Security Groups helps design robust, layered defenses.

7

Expert

Advanced Rule Ordering and Performance

🤔Before reading on: Do you think rule order affects performance or just correctness? Commit to your answer.

Concept: Rule order impacts both traffic filtering correctness and network performance.

Network ACL rules are processed in order, so placing frequently matched rules early improves efficiency. Complex or overlapping rules can cause unexpected behavior if order is wrong. Also, large rule sets can slow traffic processing. Experts carefully order and minimize rules to balance security and performance.

Result

You appreciate that rule design affects not just security but also network speed and reliability.

Understanding rule order's impact on performance helps optimize large-scale cloud networks.

Under the Hood

Network ACLs operate at the subnet boundary within the cloud provider's network infrastructure. Each packet entering or leaving the subnet is checked against the ACL's ordered rules. The system compares packet details like source/destination IP, protocol, and port to each rule until a match is found. Because ACLs are stateless, each packet is evaluated independently without memory of previous packets. This filtering happens before packets reach individual resources, providing a broad security layer.

Why designed this way?

Network ACLs were designed as simple, fast filters to provide a first line of defense at the subnet level. Their stateless design keeps processing lightweight and scalable across many packets. Stateful filtering was left to Security Groups to allow more detailed control per resource. This separation balances performance and flexibility, allowing cloud providers to efficiently secure large networks while giving users fine-grained options.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Inbound Packets│──────▶│ Network ACL   │──────▶│ Subnet Devices│
│ (Source IP,   │       │ (Rule Check)  │       │ (EC2, etc.)   │
│  Dest IP, etc)│       └───────────────┘       └───────────────┘

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Outbound Packets│◀────│ Network ACL   │◀────│ Subnet Devices│
│ (Source IP,   │       │ (Rule Check)  │       │ (EC2, etc.)   │
│  Dest IP, etc)│       └───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do Network ACLs remember past traffic to allow return packets automatically? Commit to yes or no.

Common Belief: Network ACLs are stateful and automatically allow return traffic once a connection is established.

Reality: Network ACLs are stateless and require explicit rules for both inbound and outbound traffic directions.

Why it matters: Assuming statefulness can cause blocked responses and broken communication, leading to hard-to-debug network issues.

Quick: Do you think Network ACLs replace Security Groups completely? Commit to yes or no.

Common Belief: Network ACLs provide all necessary network security, so Security Groups are redundant.

Reality: Network ACLs and Security Groups serve different purposes and work best together for layered security.

Why it matters: Relying only on Network ACLs can leave resources exposed or improperly protected at the instance level.

Quick: Do you think the order of Network ACL rules does not affect traffic filtering? Commit to yes or no.

Common Belief: Rule order in Network ACLs is not important; all rules are checked equally.

Reality: Rules are evaluated in order, and the first matching rule determines the action, so order is critical.

Why it matters: Ignoring rule order can cause unexpected traffic blocks or allows, compromising security or connectivity.

Quick: Do you think the default Network ACL denies all traffic by default? Commit to yes or no.

Common Belief: The default Network ACL blocks all traffic unless rules are added.

Reality: The default Network ACL allows all inbound and outbound IPv4 traffic by default.

Why it matters: Misunderstanding defaults can lead to false confidence in security or unnecessary rule changes.

Expert Zone

1

Network ACLs can be used to quickly block entire IP ranges before traffic reaches Security Groups, reducing load on instance-level firewalls.

2

Because Network ACLs are stateless, they can be used to block spoofed packets that try to bypass stateful firewalls by sending unexpected return traffic.

3

In large environments, carefully ordering and minimizing Network ACL rules improves both security clarity and network performance, which is often overlooked.

When NOT to use

Network ACLs are not suitable for fine-grained, resource-level security or for protocols requiring stateful inspection. In those cases, use Security Groups or dedicated firewalls that track connection state and provide detailed logging and alerts.

Production Patterns

In production, Network ACLs are often used to enforce broad network boundaries, such as blocking known malicious IPs or restricting traffic between subnets. Security Groups handle detailed access control per instance. Teams automate Network ACL management with infrastructure-as-code tools to maintain consistency and auditability.

Connections

Firewall Rules

Network ACLs are a type of firewall rule applied at the subnet level.

Understanding Network ACLs helps grasp how firewalls filter traffic at different network layers and scopes.

Stateful vs Stateless Systems

Network ACLs are stateless filters, unlike stateful firewalls or Security Groups.

Knowing the difference between stateless and stateful systems clarifies why some traffic must be explicitly allowed both ways.

Airport Security Checkpoints

Network ACLs function like security checkpoints controlling who enters or leaves a secure area.

This connection to physical security highlights the importance of layered checks and clear rules to maintain safety.

Common Pitfalls

#1 Forgetting to allow outbound response traffic after allowing inbound requests.

Wrong approach:

Inbound rule: Allow TCP port 80
Outbound rule: Deny all traffic

Correct approach:

Inbound rule: Allow TCP port 80
Outbound rule: Allow ephemeral ports (1024-65535) for responses

Root cause:

Misunderstanding that Network ACLs are stateless and require explicit rules for both directions.

#2 Placing deny rules before allow rules that should match first.

Wrong approach:

Rule 100: Deny all traffic
Rule 110: Allow traffic from trusted IP

Correct approach:

Rule 100: Allow traffic from trusted IP
Rule 110: Deny all traffic

Root cause:

Not realizing that rules are processed in order and the first match applies.

#3 Assuming default Network ACL blocks all traffic and adding unnecessary allow rules.

Wrong approach:

Creating custom Network ACL with no rules, expecting all traffic blocked.

Correct approach:

Using default Network ACL which allows all IPv4 traffic unless custom rules are added.

Root cause:

Confusing default Network ACL behavior with custom ACL defaults.

Key Takeaways

Network ACLs are simple, stateless filters that control traffic at the subnet level in cloud networks.

They require explicit rules for both inbound and outbound traffic because they do not remember past connections.

Rule order matters: the first matching rule determines whether traffic is allowed or denied.

Network ACLs complement Security Groups by providing broad network-level filtering alongside resource-level controls.

Understanding Network ACLs helps build layered, effective cloud network security that balances performance and protection.