What Is Network ACL in Networking?

Imagine you live in a gated community with several streets (subnets). At the main gate, there is a security guard (the Network ACL) who checks every car that wants to enter or leave. The guard has a list of rules written on a clipboard. For example, one rule might say 'allow cars from the mail company between 8 AM and 6 PM' and another might say 'block any car that does not have a valid visitor pass'. This guard does not remember which cars have already been inside – every single car is checked from scratch each time. That is what stateless means: the guard treats each car as if it is the first time they are arriving.

In a cloud network like Amazon Web Services (AWS), a Network ACL works exactly like that guard. It is a list of numbered rules that either allow or deny traffic based on the IP address, the port number (like a specific door number on a building), and the protocol (like TCP or UDP). The rules are evaluated in order, starting from the lowest number. Once a rule matches, the action is taken – either allow or deny – and no further rules are checked.

This is different from a Security Group, which is like a guard who keeps a notebook of who they have already let in. That guard remembers that if a car came in earlier, they can leave without being checked again. That is stateful behavior. A Network ACL is stateless, so it needs separate rules for inbound and outbound traffic, even for the same conversation. For example, if a request comes in from the internet, the Network ACL must have a rule allowing inbound traffic (the request) and a separate rule allowing outbound traffic (the response). If the outbound rule is missing, the response gets blocked, and the connection fails.

In practice, Network ACLs are used to add an extra layer of security at the subnet boundary. They are useful for blocking specific IP addresses or entire ranges of addresses that are known to be malicious. Because they are stateless, they are very efficient for handling large amounts of traffic, but they require careful configuration to make sure responses are not accidentally dropped. When studying for IT certification exams, it is important to remember that Network ACLs are always evaluated before Security Groups when traffic enters a subnet, and they apply to all instances within that subnet automatically.

A Network Access Control List (Network ACL) is an optional layer of security for your Virtual Private Cloud (VPC) that acts as a stateless firewall for controlling traffic in and out of one or more subnets. In Amazon Web Services (AWS), the Network ACL is defined at the VPC level and can be associated with multiple subnets, but each subnet can only be associated with one Network ACL at a time. By default, each VPC comes with a default Network ACL that allows all inbound and outbound traffic. When you create a custom Network ACL, it initially denies all inbound and outbound traffic until you explicitly add rules.

The fundamental characteristic of a Network ACL is that it is stateless. This means that the ACL does not track the state of network connections. Each packet is evaluated independently without any context of previous packets. As a result, you must define separate rules for inbound and outbound traffic. For example, if you allow inbound HTTP traffic (port 80) from the internet, you must also explicitly allow outbound traffic from the subnet back to the internet on ephemeral ports (typically ports 1024-65535) so that the web server can send responses. Failure to do so will result in broken connections.

Network ACL rules are processed in numerical order, starting with the lowest rule number. Each rule consists of a rule number (e.g., 100, 200, 300), a protocol (TCP, UDP, ICMP, or all), a port range, a source or destination IP address in CIDR notation, and an action (allow or deny). Once a rule matches the traffic, the action is applied immediately, and no further rules are evaluated. For this reason, it is common practice to add allow rules at lower numbers (e.g., 100) and deny rules at higher numbers (e.g., 32766) to ensure that legitimate traffic is matched first. AWS recommends incrementing rules by 100 to leave room for inserting new rules later.

The maximum number of rules per Network ACL is 20 per direction (inbound + outbound) by default, but this can be increased by requesting a limit increase from AWS Support. Each rule is evaluated against every packet. If no rule matches, the default deny rule at the end of the list (rule number *) applies, which denies all traffic.

In terms of standards, Network ACLs operate at Layer 3 (Network layer) and Layer 4 (Transport layer) of the OSI model. They filter based on IP addresses and port numbers, but they do not inspect the contents of the packet payload. For deeper inspection, you would need a Web Application Firewall (WAF) or a Network Firewall appliance.

Real IT implementation of Network ACLs is common in multi-tier architectures. For example, you might put your web servers in a public subnet with a Network ACL that allows HTTP and HTTPS inbound from the internet, and allows all outbound traffic to the internet and to the application servers. The application servers might be in a private subnet with a Network ACL that only allows inbound traffic from the web subnet, and denies all inbound traffic from the internet.

When troubleshooting connectivity issues, one of the first checks is to examine the Network ACL rules. Because it is stateless, a common issue is that the outbound rule for response traffic is missing. For instance, if you ping an EC2 instance from the internet, you need both an inbound rule allowing ICMP echo request and an outbound rule allowing ICMP echo reply. If either is missing, the ping fails.

In exam contexts, especially for AWS Certified Solutions Architect - Associate (SAA) and AWS Certified Cloud Practitioner, you need to understand the difference between Network ACLs (stateless) and Security Groups (stateful). You also need to know that Network ACLs support allow and deny rules (whereas Security Groups only support allow rules), and that Network ACLs are applied at the subnet level, while Security Groups are applied at the instance (or elastic network interface) level.

Network ACLs matter in real-world IT because they provide a critical layer of defense at the perimeter of your network. In cloud environments like AWS, Azure, and Google Cloud, subnet-level filtering is often the first line of defense against unwanted traffic. For example, if you have a public subnet hosting a web server, you can use a Network ACL to block all traffic from countries or IP ranges that you do not do business with. This reduces the attack surface significantly.

Another practical reason is that Network ACLs are applied to all instances in a subnet automatically. This means you can enforce a baseline security policy without having to configure each individual instance's firewall. For example, if you want to block SSH access (port 22) from the entire internet, you can add a deny rule in the Network ACL, and every instance in that subnet is protected immediately.

Network ACLs are also important for compliance. Many regulatory frameworks require network segmentation and access control at the subnet level. By using Network ACLs, you can demonstrate that you have implemented controls to restrict traffic between different tiers of your application (web, application, database).

because Network ACLs are stateless, they are very fast. They do not need to maintain a state table, so they can handle high volumes of traffic with minimal latency. This makes them suitable for high-throughput environments like data streaming or real-time analytics.

However, the stateless nature also introduces complexity. IT professionals must carefully design rules to ensure that legitimate traffic flows in both directions. A common mistake is to only allow inbound traffic and forget to allow outbound responses. This can cause frustrating connectivity issues that are hard to debug unless you are familiar with how stateless filtering works.

Network ACL questions on exams usually fall into three main patterns: scenario-based, configuration-based, and comparison-based.

In scenario-based questions, you are given a description of a network environment where traffic is not flowing as expected. For example, you might have a web server in a public subnet with a Security Group that allows HTTP and HTTPS inbound from 0.0.0.0/0. The web server is running but clients cannot access it. The question will list several possible causes, and one of them is that the Network ACL does not have an inbound rule allowing HTTP and HTTPS, or the outbound rule for response traffic is missing. The correct answer is often that the Network ACL's outbound rule does not allow ephemeral ports for responses.

Another scenario might involve a database server in a private subnet that is unreachable from an application server in a public subnet. The Security Groups are correctly configured, but the Network ACL on the private subnet is blocking inbound traffic from the application server's subnet. The question will ask you to identify the root cause.

Configuration-based questions often require you to select a set of rules from multiple choices. For instance, 'Which Network ACL rules would allow HTTPS traffic from the internet to your EC2 instance?' The answer will include an inbound rule with protocol TCP, port 443, source 0.0.0.0/0, and an outbound rule with protocol TCP, port range 1024-65535, destination 0.0.0.0/0.

Comparison-based questions explicitly ask you to identify differences. For example, 'Which of the following is a characteristic of a Network ACL but not a Security Group?' The answer could be 'It supports both allow and deny rules' or 'It is stateless.'

In multi-cloud exam questions, you might be asked to compare AWS Network ACL with Azure NSG. The key difference to remember is that Azure NSGs are stateful by default, while AWS Network ACLs are stateless.

Troubleshooting questions on the CCNA exam often involve a router with an ACL applied to an interface, and you need to determine why a certain host cannot ping another host. You must examine the ACL entries in order and see which rule matches first.

For the CompTIA Security+ exam, you might be asked to recommend a security control for a network segment. If the requirement is to allow only HTTP traffic from a specific IP range, a Network ACL would be an appropriate answer because it supports both allow and deny rules and operates at the subnet level.

A Network ACL is a powerful tool for network segmentation and traffic filtering in the cloud, but it requires a solid understanding of stateless filtering to use effectively. When you design a VPC architecture, you should plan your Network ACL rules early, because changing them after deployment can affect all instances in the subnet.

First, decide on the principle of least privilege. Start with a custom Network ACL that denies all inbound and outbound traffic by default. Then, add only the rules you need. For a public web server subnet, you might add inbound rules for HTTP (port 80) and HTTPS (port 443) from 0.0.0.0/0, and outbound rules for ephemeral ports to 0.0.0.0/0 so that responses can go back. If you need to allow SSH access for administrators, add a specific inbound rule with your company's public IP range as the source, not 0.0.0.0/0.

One common real-world scenario is to use a Network ACL to block traffic from known malicious IP addresses. For example, if you see repeated brute-force attempts from an IP block, you can add a deny rule at a low number (e.g., Rule 10) to block that IP range. This is faster than blocking at the Security Group level because the traffic is filtered before it reaches the instance, reducing load on the instance's network stack.

Another practical use is to isolate different tiers of an application. For instance, you can put database instances in a private subnet with a Network ACL that only allows inbound traffic from the web server subnet's CIDR on port 3306 (MySQL). This ensures that even if an attacker compromises a web server, they cannot directly access the database from the internet.

However, professionals should be aware of the limitations. Network ACLs do not inspect packet payloads, so they cannot block application-layer attacks like SQL injection. For that, you need a WAF. Also, managing many rules can become complex. AWS recommends using rule numbers that allow for future insertions (e.g., 100, 200, 300). If you fill up rules too tightly, you may need to renumber them, which can be tedious.

What can go wrong? The most common issue is when an engineer modifies the Network ACL and accidentally removes an outbound rule, causing all responses to be dropped. This can cause a complete outage for applications in that subnet. Therefore, always make changes during a maintenance window and test thoroughly.

In exams, you might be asked to design a Network ACL configuration for a three-tier application. The correct approach is to create separate subnets for each tier, associate each subnet with a tailored Network ACL, and ensure that the outbound rules allow responses to come back. Remember: inbound traffic to the web tier from the internet, outbound responses from the web tier, inbound from web to app tier, and outbound responses from app tier back to web tier.

A Network Access Control List (Network ACL) is a virtual firewall that operates at the subnet level in an Amazon Virtual Private Cloud (VPC). Unlike security groups, which are stateful and operate at the instance level, Network ACLs are stateless, meaning they evaluate each packet independently without regard to previous traffic. This distinction is critical for cloud practitioners and network engineers, as it impacts how inbound and outbound rules must be configured. Every subnet in a VPC must be associated with a Network ACL; if no custom ACL is specified, the VPC's default Network ACL is used, which allows all inbound and outbound traffic. Custom Network ACLs, however, start with a default deny-all rule, forcing administrators to explicitly define allowed traffic. This behavior is tested heavily in exams like AWS Cloud Practitioner and AWS SAA, where understanding the stateless nature versus security group statefulness is a common trap question.

Network ACLs support both allow and deny rules, ordered by rule number (from 1 to 32766). Rules are evaluated in ascending order, and the first matching rule determines whether traffic is permitted or denied. This is different from security groups, which only have allow rules. The ability to explicitly deny traffic makes Network ACLs a powerful tool for blocking specific IP addresses or ranges at the subnet boundary, a feature often used in distributed denial of service (DDoS) mitigation or when implementing compliance requirements. For example, to block a known malicious IP range, you would add a deny rule with a low rule number before any allow rules. This ordering concept is frequently tested in advanced networking exams such as CCNA and Network+.

When configuring a Network ACL, you must consider both inbound and outbound rules separately. Since it is stateless, if you allow inbound traffic on port 80 from the internet, you must also allow outbound ephemeral traffic (typically ports 1024-65535) for the return response. Misconfiguring this asymmetry is one of the most common causes of connectivity issues in AWS environments. In exams like the Google ACE and AZ-104, scenarios often present a web server that is unreachable despite allowing inbound HTTP, and the correct answer involves adding the appropriate outbound rule to the Network ACL. Understanding this stateless behavior is foundational for cloud architects and network administrators alike, as it directly impacts security posture and troubleshooting efficiency.

The default Network ACL in a VPC allows all inbound and outbound traffic, which may seem overly permissive, but it serves as a baseline to ensure connectivity is not broken inadvertently. However, best practices for production environments mandate creating custom Network ACLs with the principle of least privilege. For example, a web application subnet should allow inbound TCP ports 80 and 443 from 0.0.0.0/0, and outbound ephemeral ports to 0.0.0.0/0. A database subnet should only allow inbound traffic from the web subnet on the database port (e.g., 3306 for MySQL) and deny all other inbound traffic. This layered security approach is a key concept in the Security+ and CCNA exams, where multi-tier architecture security is emphasized. Network ACLs, when combined with security groups, provide defense in depth: the Network ACL acts as a coarse filter at the subnet perimeter, while security groups provide finer-grained control at the instance level.

In practice, Network ACLs are applied to subnets, not to individual instances. This means all instances within a subnet inherit the same Network ACL rules. This is both an advantage (simplifies management) and a limitation (reduces flexibility). For scenarios requiring per-instance rules, security groups must be used. Many exam questions test this distinction by asking which construct to use when a specific set of instances needs different rules than others in the same subnet. The correct answer is always security groups. Network ACLs are also used to create DMZ subnets, where public-facing resources are isolated from internal subnets. By defining strict inbound and outbound rules, administrators can control traffic flow between tiers. Understanding how to design these tiers using Network ACLs is a core objective for the AWS SAA and Google ACE certifications, where VPC design is a major domain.

Advanced topics include using Network ACLs with VPC endpoints or AWS Transit Gateway. In such cases, the ACL rules must account for the IP ranges used by these services, which are often documented in AWS service-specific prefixes. For example, when using a VPC interface endpoint for Amazon S3, you need to add allow rules for the endpoint's IP addresses in the ACL. Neglecting this can result in unexpected connectivity failures, a scenario that appears in AZ-104 and Network+ troubleshooting questions. Network ACLs support rule metrics via Amazon CloudWatch, but only for the number of packets that match each rule. This can help identify traffic patterns or blocked attempts, but it does not provide detailed logs like VPC Flow Logs. The combination of Network ACLs, security groups, and Flow Logs forms a comprehensive monitoring and security framework, a topic that appears across all major cloud and networking certifications.

The stateless nature of Network ACLs is one of the most important concepts to grasp for anyone working with AWS networking or preparing for certification exams. Unlike security groups, which automatically track connection state and allow return traffic, Network ACLs treat each packet as an independent entity. This means that when an instance initiates a connection to an external host, the outbound packet is evaluated against the outbound rules, and the corresponding inbound response packet must also be explicitly allowed by inbound rules. This is why ephemeral ports become critical. Ephemeral ports are temporary ports used by the client side of a TCP or UDP connection, typically in the range 1024-65535. When an instance sends a request, it uses a random high-numbered port as the source port, and the target server responds to that port. Therefore, the Network ACL's inbound rules must allow traffic on these ephemeral ports from the destination's IP range.

For example, consider an EC2 instance in a private subnet that needs to download updates from the internet via a NAT gateway. The instance sends an outbound request to the update server (say, 1.2.3.4) on port 443 (HTTPS). The outbound rule must allow destination port 443. But when the update server responds, it will send packets to the instance's IP address on the ephemeral port that the instance used (e.g., 34567). The Network ACL must have an inbound rule allowing traffic from the update server IP range on ephemeral ports 1024-65535 (or a more restricted range like 32768-65535, which is commonly used by Linux and Windows systems). Failure to include this inbound rule will result in the instance never receiving the response, even though the outbound request is allowed. This asymmetry is a classic exam scenario in the AWS Cloud Practitioner, AWS SAA, and Security+ exams, where candidates must identify why a connection is failing despite seemingly correct rules.

The ephemeral port range used by AWS depends on the operating system. For Amazon Linux, Ubuntu, and most Linux distributions, the range is 32768-60999. For Windows Server, it is typically 49152-65535. To be safe and avoid cross-OS issues, many administrators use 1024-65535 in their Network ACL rules. But for certification purposes, knowing the specific ranges can appear in advanced questions for AWS SAA or Network+. Some Network ACL configurations must account for the fact that a NAT gateway uses specific ephemeral ports. The NAT gateway itself is managed by AWS, but its behavior still requires proper ACL rules in the private subnet. If the private subnet's Network ACL does not allow inbound ephemeral traffic from the NAT gateway's elastic IP addresses (or the internet gateway's IP ranges), traffic will fail. This layered scenario tests deep understanding of how stateless filtering works across multiple components.

In practice, when designing Network ACL rules for internet-facing subnets, you must create symmetric rules. For inbound web traffic, allow source ports ephemeral for the response, but the common pattern is: inbound rules allow specific ports (80, 443) from any source, and outbound rules allow all traffic to any destination. This is considered acceptably secure because the outbound rule allows the instance to respond to any requested connection. However, for more restrictive environments, you might limit outbound traffic to only necessary destinations. For example, an application server that only needs to talk to a database server and the internet for updates would have outbound rules specific to the database's IP and the update server's IP. This precision reduces the attack surface, a concept emphasized in the CompTIA A+ and Security+ curricula.

The stateless behavior also affects how Network ACLs handle ICMP traffic. For ping (ICMP Echo Request and Echo Reply), both the inbound and outbound rules must explicitly allow the ICMP protocol type. Since ICMP does not use ports, the rules must specify the ICMP type and code (type 8 for Echo Request, type 0 for Echo Reply). Many administrators mistakenly only add an inbound rule allowing ICMP, forgetting that the outbound rule also needs to allow the reply. This is a common troubleshooting scenario in CCNA and Network+ labs, where ping works from one direction but not the other. In the AWS world, the same principle applies. Understanding these nuances is essential for passing the AZ-104 exam for Azure administrators transitioning to AWS, as Azure also uses stateless ACLs (NSGs) with similar concepts, though NSGs are stateful by default but can be made stateless via application security groups.

Finally, memorizing the ephemeral port ranges and stateless rule design is not just for exams-it directly impacts real-world deployments. Misconfigurations here are among the top reasons for network troubleshooting tickets in cloud environments. Many cloud engineers have spent hours debugging an issue only to find that the Network ACL was blocking the return traffic. By internalizing the stateless model, administrators can quickly diagnose and resolve such problems. In advanced certifications like AWS DevOps Engineer or Networking Specialty, scenarios often present a VPC peering connection that works intermittently, and the root cause is a missing ephemeral port rule in one of the peer VPC's ACLs. Thus, mastering this concept is both exam-critical and career-critical.

Understanding the differences between Network ACLs and security groups is a cornerstone of AWS networking knowledge, appearing in every major cloud certification exam, including AWS Cloud Practitioner, AWS SAA, Google ACE, and AZ-104. These two constructs serve overlapping but distinct security functions within a VPC, and confusing them is a common source of errors. The most fundamental difference is statefulness: security groups are stateful, meaning they automatically allow return traffic regardless of outbound rules, while Network ACLs are stateless and require explicit rules for both directions. This single difference affects everything from rule complexity to troubleshooting approaches. For example, if you create a security group that allows inbound HTTPS from the internet, you do not need to add an outbound rule for the response; the security group automatically tracks the connection. With a Network ACL, you must add an outbound rule allowing ephemeral ports. This is why security groups are generally recommended for per-instance control, while Network ACLs are better for broader subnet-level filtering.

Another critical difference is rule structure: security groups support only allow rules, while Network ACLs support both allow and deny rules. This means you cannot explicitly block an IP address using a security group; you would instead not include it in the allow rules (implicit deny). With a Network ACL, you can add a deny rule to block specific traffic, which is useful for implementing blacklists or handling compliance requirements. This distinction is frequently tested in Security+ and CCNA exams, where scenarios involve blocking a specific IP range while allowing others. The ability to deny traffic makes Network ACLs a powerful tool for network segmentation and DDoS mitigation at the subnet boundary. However, because security groups are easier to manage and less prone to misconfiguration, they are often the default recommendation for most use cases.

Rule evaluation order also differs. Security groups evaluate all rules together; if a packet matches any allow rule, it is permitted (unless the connection is already tracked). Network ACLs evaluate rules in numeric order, from lowest to highest, and the first match determines the outcome. This means you can deliberately place a deny rule with a low number to block traffic before it reaches an allow rule with a higher number. This ordering is a common exam trap: candidates might think that a higher-numbered allow rule will override a lower-numbered deny rule, but in reality, the first matching rule wins. In the AWS SAA exam, a typical question might present a Network ACL with a deny rule for a specific IP at rule 100 and an allow rule for all traffic at rule 200. The answer is that the IP is blocked because rule 100 is evaluated first. Understanding this nuance is essential for passing both AWS and Azure certification exams (Azure NSGs also have priority-based rules).

Scope of application is another differentiator. Security groups are associated with ENIs (Elastic Network Interfaces) attached to instances, so they operate at the instance level. Network ACLs are associated with subnets, so they apply to all instances within that subnet. This means if you need different rules for different instances in the same subnet, you must use security groups. Conversely, if you want to enforce a uniform policy across all instances in a subnet (e.g., block SSH from the internet), a Network ACL is more efficient. Many organizations use a combination: security groups for granular control, and Network ACLs as a safety net to block obviously malicious traffic. This layered approach is emphasized in the Security+ and CCNA curricula, where defense in depth is a key principle.

Behavior with VPC traffic also differs. Security groups can reference other security groups as sources or destinations, enabling easy cross-tier allow rules (e.g., allow traffic from the web security group to the database security group). Network ACLs cannot use security group references; they only support CIDR blocks, IP addresses, or DNS names. This means ACL rules are less dynamic and require more manual updates when IP addresses change. In the Google ACE exam, this limitation is often highlighted when discussing complex architectures with autoscaling groups where IPs change frequently. Security groups support allow rules for both inbound and outbound, but Network ACLs require separate rule tables for each direction. This duplication can increase management overhead, especially in large VPCs with many subnets.

Finally, performance and default configurations differ. Security groups have a default rule that allows all outbound traffic for new groups, and they deny all inbound traffic unless explicitly allowed. The default Network ACL, on the other hand, allows all inbound and outbound traffic, which is more permissive. Custom Network ACLs start with an implicit deny-all rule. This difference often leads to security misconfigurations when users create a custom ACL and forget to add allow rules, resulting in all traffic being denied. In exams like the AZ-104 and Cloud Practitioner, questions about default behaviors are common, testing whether candidates know that the default ACL is permissive while the default security group is restrictive. Mastering these distinctions is not only exam-critical but vital for real-world secure VPC design.

Network ACL rule numbering is a fundamental concept that governs how traffic is allowed or denied at the subnet level. Each Network ACL rule is assigned a unique number between 1 and 32766, and AWS evaluates rules in ascending order starting from the lowest number. The first rule that matches the traffic determines whether the packet is permitted or denied. If no rule matches, the default implicit deny rule (rule number *) applies, which blocks all traffic. This numeric ordering is a key feature that distinguishes Network ACLs from security groups, where all rules are evaluated simultaneously. Understanding this ordering is essential for designing effective security policies, and it is a frequent topic in exams such as the AWS SAA, Network+, and AZ-104.

Why does this matter? Because the order of rules can either make or break your security posture. For example, suppose you want to allow HTTP (port 80) traffic from the internet to your web servers but block traffic from a specific malicious IP address (1.2.3.4). If you place the allow rule (rule 100: allow 0.0.0.0/0 port 80) before the deny rule (rule 200: deny 1.2.3.4 port 80), the malicious IP's traffic will be allowed because rule 100 matches first. To block the IP, you must place the deny rule with a lower number (e.g., rule 10: deny 1.2.3.4 port 80) and then the allow rule with a higher number (e.g., rule 20: allow 0.0.0.0/0 port 80). This logical placement is exactly how on-premises firewalls work, which is why CCNA and Network+ exams test this ordering principle heavily. In the AWS world, many beginners incorrectly assume that deny rules always override allow rules, but the truth is that the first matching rule wins, regardless of whether it is allow or deny.

Best practices for rule numbering include leaving gaps between rule numbers. This allows you to insert new rules in the future without having to renumber existing ones. For example, use rule numbers like 10, 20, 30, and so on. If you later need to block a new IP, you can add a rule at number 15 without shifting other rules. AWS does not support auto-renumbering, so if you fill all available numbers, you must either delete and recreate rules or manage them via API with manual numbering. This operational aspect is often tested in AWS certification scenarios where candidates must plan for future rule additions without disrupting current traffic.

Another important detail is that Network ACL rules have a star (*) entry as the default rule, which is always implicitly at the end and denies all traffic. You cannot modify or delete this default deny. This means if you remove all custom rules from a Network ACL, all traffic will be denied by default. In contrast, the default Network ACL (which is automatically created for each VPC) has a rule that allows all inbound and outbound traffic. This default ACL is often a confusing point in the Cloud Practitioner exam: the default ACL is permissive, but custom ACLs start with implicit deny. Understanding this subtlety can help answer questions about why a newly created subnet that uses a custom ACL has no connectivity.

Rule numbering also matters when troubleshooting connectivity issues. If traffic is unexpectedly blocked, you can check the Network ACL rule evaluation order by looking at the CloudWatch metrics for each rule. AWS provides a metric called "Packets" for each rule entry, which increments when a packet matches that rule. If you see packets hitting a deny rule, you know exactly which rule is blocking the traffic. Conversely, if packets match an allow rule but the traffic still fails, the issue might be in the corresponding rule for the return direction (statelessness). This metric-based debugging is a skill tested in practical exam scenarios for AWS Networking Specialty and DevOps Engineer.

In multi-tier architectures, rule ordering becomes even more critical. For example, in a web and database tier separated by private subnets, you might have a Network ACL on the database subnet that allows inbound traffic only from the web subnet's IP range on port 3306 (MySQL). The rule number for this specific allow should be lower than any broader allow or deny rules. If you have a catch-all deny rule at a higher number, you must ensure the specific allow rule is placed with a lower number. This is a common pass-or-fail scenario on the SAA exam: a question may describe a database that cannot be reached from the web tier, and the fix is to reorder the ACL rules so that the specific allow rule precedes any general deny.

Finally, note that each Network ACL can have a maximum of 20 inbound rules and 20 outbound rules by default, though this limit can be increased by requesting a quota increase. Rule numbers must be unique within each direction (inbound or outbound). The rule number cannot overlap between inbound and outbound because they are separate lists. When using the AWS Management Console, the interface enforces a step of 10 for rule numbers, but you can set any integer via CLI or SDK. For certification exams, you should remember that the valid range is 1 to 32766 and that lower numbers have higher precedence. By internalizing this ordering logic, you'll be well-prepared for both real-world configurations and exam questions across multiple platforms.