AWS Security Groups vs Network ACLs Explained: A Beginner's Guide

AWS Security Groups and Network ACLs are two networking security features that control which traffic can enter and leave resources inside an Amazon VPC.

Although both help protect your AWS infrastructure, they work differently.

A Security Group acts as a firewall for a resource's network interface, while a Network ACL acts as a traffic filter at the subnet boundary.

The most important difference is that Security Groups are stateful, meaning they recognize response traffic from allowed connections. Network ACLs are stateless, meaning inbound and outbound packets must be permitted independently.

If you're just starting with AWS, these terms may seem confusing. Let's understand them using everyday examples before exploring how they work in a real cloud architecture.

By the end of this article, you'll understand why both features exist, how their rules are evaluated, and how to identify common configuration mistakes.

1. Why Does AWS Need Network Security?

Imagine you deploy a website on an Amazon EC2 instance.

Your server has a public IP address, and visitors can open your website over HTTPS.

But think about these questions:

• Should everyone on the internet be able to connect to your server using SSH?

• Should a visitor be able to connect directly to your PostgreSQL database?

• Should your backend API accept requests from any unknown server?

• What happens if an unwanted IP address repeatedly tries to connect to your application?

A publicly reachable server can receive connection attempts from many sources.

We need a way to control which connections are permitted.

That's what network security controls are for.

For example, we might want to allow:

• HTTPS requests from website visitors.

• SSH connections only from trusted administrators.

• Database connections only from authorized backend servers.

At the same time, we want to reject unnecessary or unauthorized traffic.

AWS provides Security Groups and Network ACLs to help enforce these requirements.

But before understanding their differences, let's review a few basic networking concepts.

2. Understanding VPCs, Subnets, IP Addresses, and Ports

Before learning about AWS network security, it helps to understand how a VPC, subnet, and IP address work together. If you're unfamiliar with these concepts, read our AWS VPC Explained for Beginners: Subnets, CIDR, Routing, and Gateways guide for a detailed explanation with examples.

Suppose we create an AWS VPC with the following address range:

10.0.0.0/16

Inside this VPC, we create three subnets.

We then place one server in each subnet.

These are illustrative addresses.

All three servers belong to the same VPC, but they perform different jobs.

The web server handles incoming website traffic.

The API server processes application requests.

The database stores information.

Now imagine a visitor opens your website.

The request reaches the web server on TCP port 443.

The web server then makes a request to the backend API on port 3000.

The backend API communicates with PostgreSQL on port 5432.

This gives us three different types of communication:

We want to allow these required connections while blocking unnecessary ones.

What is a port?

An IP address identifies a network endpoint.

A port identifies a specific communication endpoint for an application or service.

For example:

10.0.2.20:3000

Here:

• 10.0.2.20 identifies the API server.

• 3000 is the port where the API application listens.

Some familiar TCP ports are:

Security Groups and Network ACLs can filter traffic based on network protocols, IP addresses, and ports.

That is how we control which connections are allowed.

3. What Is an AWS Security Group?

A Security Group (SG) is a virtual firewall used to control permitted inbound and outbound traffic for AWS resources.

For EC2 instances, Security Groups are associated with Elastic Network Interfaces (ENIs).

To better understand how EC2 instances receive private and public IP addresses, how network interfaces work, and how Security Groups relate to EC2 connectivity, explore our AWS EC2 Networking Explained: Private IP, Public IP, Elastic IP, and Security Groups guide.

You can think of a Security Group as a security guard assigned to a particular office.

The guard checks whether a visitor is permitted to enter or whether a connection is allowed to leave.

Unlike a Network ACL, the Security Group doesn't apply automatically to every resource merely because it is in the same subnet.

Resources can have different Security Groups even when they are located in the same subnet.

Example: Security Group for a web server

Suppose our web server has:

Private IP: 10.0.1.10

It hosts a website available over HTTPS.

We want visitors to access the website, but we don't want everyone to connect using SSH.

Its Security Group could have these inbound rules:

The SSH source is a documentation-only example address representing a trusted administrator.

Let's understand these rules.

Rule 1: HTTPS from 0.0.0.0/0

This allows inbound HTTPS connections from any IPv4 address that can reach the instance.

Rule 2: SSH from 198.51.100.25/32

This allows SSH connections from one specified IPv4 address.

Other source addresses do not match this SSH rule.

What does /32 mean?

In IPv4 CIDR notation, /32 identifies a single IP address.

So:

198.51.100.25/32

means only that specific address.

By comparison:

0.0.0.0/0

represents every possible IPv4 address.

This is why you should avoid allowing unrestricted SSH access from 0.0.0.0/0 unless there is a specific, justified requirement.

Do Security Groups have deny rules?

No.

Security Groups support allow rules only.

If a new connection does not match an applicable allow rule, it is not permitted.

For example, if a Security Group allows only TCP port 443, an unsolicited connection to port 3306 will not be allowed through that Security Group.

You do not need to create a separate deny rule for port 3306.

This is called an implicit deny.

Do Security Group rules have priority numbers?

No.

AWS evaluates the applicable Security Group rules as a combined set of permissions.

If any applicable rule allows the traffic, the Security Group permits it.

There is no first-match rule-number system like the one used by Network ACLs.

4. What Are Inbound and Outbound Rules?

Both Security Groups and Network ACLs distinguish between inbound and outbound traffic.

These terms describe the direction of network communication relative to the resource or subnet being protected.

Inbound traffic

Inbound traffic travels toward your resource.

Examples:

• A visitor connecting to your website.

• An administrator connecting through SSH.

• A frontend server sending a request to your backend API.

Outbound traffic

Outbound traffic travels away from your resource.

Examples:

• An EC2 instance downloading software updates.

• A backend server calling an external API.

• An application server initiating a connection to PostgreSQL.

An important point is that a request and its response travel in opposite directions.

If a user sends a request to your web server, the request arrives inbound.

The server's response leaves outbound.

However, Security Groups do not necessarily require you to configure separate rules for both directions of an already permitted connection.

That brings us to the concept of stateful firewalls.

5. What Does Stateful Mean?

This is one of the most important concepts in AWS networking.

Stateful means the firewall remembers information about network connections.

Let's use a simple real-world example.

Imagine you are visiting an office building.

At the entrance, the security guard checks your identification and allows you inside.

Later, when you leave, the guard recognizes that you were already permitted to enter.

You don't need to request a completely new entry authorization just to leave.

A stateful firewall works similarly.

It tracks connection information and recognizes packets that belong to permitted traffic flows.

Example: A visitor opens your website

Suppose a user connects to your web server using HTTPS.

The request looks like this:

Client → Web Server

198.51.100.25:53000 → 10.0.1.10:443

The client uses source port 53000.

The web server receives the request on destination port 443.

The web server's Security Group contains an inbound rule allowing TCP port 443.

Therefore, the request is permitted, assuming the network route and other controls also allow it.

Now the web server sends its response.

Web Server → Client

10.0.1.10:443 → 198.51.100.25:53000

Notice that the traffic is now traveling in the opposite direction.

Because the Security Group tracks the allowed connection, the corresponding response traffic is normally permitted automatically.

You don't need a separate outbound Security Group rule allowing destination port 53000 for that tracked response.

This behavior is called stateful connection tracking.

What if the EC2 instance initiates an outbound request?

The same general principle applies in reverse.

Suppose your backend server calls an external HTTPS API.

The outbound Security Group rules permit the request.

The response can return as part of that permitted connection without requiring a separate inbound rule for the response.

Remember: A stateful Security Group normally recognizes response traffic from an allowed connection.

AWS connection tracking has specific exceptions and resource limitations, but this is the correct mental model for ordinary tracked EC2 connections.

For the technical details, see Amazon EC2 Security Group connection tracking.

6. What Is a Network ACL?

A Network Access Control List (NACL) is a set of rules that controls inbound and outbound traffic at the subnet boundary.

Unlike a Security Group, which is associated with resource network interfaces, a Network ACL is associated with a subnet.

Let's return to the office analogy.

Imagine an office building with multiple departments.

Each department has its own security controls.

A Security Group is like a guard protecting access to a particular office.

A Network ACL is like a checkpoint at the entrance to an entire department.

Traffic entering or leaving that subnet must pass the subnet's Network ACL rules.

Example: Public subnet with two servers

Suppose we have:

Subnet: 10.0.1.0/24

Inside it are two EC2 instances:

• Web Server A: 10.0.1.10

• Web Server B: 10.0.1.20

Both servers share the same subnet.

Therefore, traffic crossing that subnet boundary is evaluated against the same associated Network ACL.

However, Server A and Server B can still have different Security Groups.

This is the main distinction:

Security Groups provide resource-level permissions. Network ACLs provide subnet-boundary permissions.

Does every subnet have a Network ACL?

Yes.

Every AWS VPC subnet is associated with a Network ACL.

If you don't explicitly select a custom Network ACL, the subnet is associated with the VPC's default Network ACL.

A Network ACL can be associated with multiple subnets.

However, one subnet can have only one associated Network ACL at a time.

Do Network ACLs support deny rules?

Yes.

Network ACLs support both:

• ALLOW

• DENY

This is different from Security Groups.

For example, a Network ACL can explicitly reject traffic from a particular IPv4 address range, even if a Security Group would otherwise allow that traffic.

This makes Network ACLs useful for additional subnet-wide restrictions.

7. What Does Stateless Mean?

A Network ACL is stateless.

This means it does not remember previously permitted connections.

Every packet crossing the subnet boundary is evaluated against the applicable inbound or outbound rules.

Let's use the same HTTPS example to make the difference clear.

A visitor sends a request:

198.51.100.25:53000 → 10.0.1.10:443

The request enters the web server's subnet.

The Network ACL checks its inbound rules.

If TCP port 443 is allowed from the visitor's address, the packet can enter the subnet.

The Security Group must also allow the connection.

Now the web server sends a response:

10.0.1.10:443 → 198.51.100.25:53000

The response leaves the subnet.

Because the Network ACL is stateless, it does not automatically permit the response simply because the original request was allowed.

The Network ACL's outbound rules must also permit traffic to the client's destination port 53000.

If outbound traffic to that port is blocked, the response cannot leave the subnet.

The website connection may therefore fail even though inbound HTTPS was allowed.

Why is the response going to port 53000 instead of 443?

This is where another important networking concept becomes useful.

The client selected a temporary source port when initiating the connection.

That port is called an ephemeral port.

The server received the request on port 443, but the client's source port was 53000.

When the server responds, the destination becomes the client's original source port.

In other words:

Request: Client port 53000 → Server port 443

Response: Server port 443 → Client port 53000

This behavior explains why custom Network ACLs must account for return traffic.

8. What Are Ephemeral Ports?

An ephemeral port is a temporary port selected by a device when it initiates a network connection.

For example, when a browser opens an HTTPS website, the destination is typically TCP port 443.

However, the browser's operating system also selects a local source port for the connection.

A possible connection is:

198.51.100.25:53000 → 10.0.1.10:443

Here:

• 198.51.100.25 is the client address.

• 53000 is the client's temporary source port.

• 10.0.1.10 is the server's private IP.

• 443 is the server's HTTPS port.

The chosen ephemeral port varies depending on the operating system and networking configuration.

Some common ranges documented by AWS include:

These are common ranges, not guarantees for every host or configuration.

Why do ephemeral ports matter for NACLs?

Suppose your subnet's Network ACL allows inbound HTTPS on TCP 443.

But its outbound rules allow only TCP 443.

This does not necessarily permit the response to return to a client using ephemeral port 53000.

The outbound Network ACL needs to allow the appropriate client destination port range.

For a simple conceptual example, allowing outbound TCP destination ports 1024–65535 can cover a broad range of possible client ephemeral ports.

However, the exact range and source or destination restrictions should be based on the workloads involved.

Similarly, when an EC2 instance initiates an outbound connection, the return traffic may require an inbound Network ACL rule permitting the instance's ephemeral destination port.

This additional rule planning is one reason custom Network ACLs can be more complicated than Security Groups.

See AWS documentation on custom Network ACLs and ephemeral ports.

9. How Network ACL Rule Numbers Work

Security Groups do not use rule priorities.

Network ACLs do.

Every custom Network ACL rule has a rule number.

AWS evaluates rules starting with the lowest number.

When a packet matches a rule, AWS applies that rule and stops evaluating additional rules in that direction.

This is called first-match evaluation.

Example: Allow HTTPS but block a specific IP range

Suppose our Network ACL has the following inbound rules:

The example IP range 203.0.113.0/24 is reserved for documentation.

Let's examine three connections.

Example A: Request from 203.0.113.25

The request attempts to connect to TCP port 443.

AWS checks rule 100 first.

The source address belongs to 203.0.113.0/24.

The rule matches.

Action: DENY

AWS does not continue to rule 200.

Example B: Request from 198.51.100.25

The request also targets TCP port 443.

AWS checks rule 100.

The source address does not match the blocked range.

AWS moves to rule 200.

Rule 200 permits TCP 443 from any IPv4 address.

Action: ALLOW

The packet can pass this inbound Network ACL check.

It must still satisfy other applicable security and routing requirements.

Example C: Request on port 3306

Suppose a request arrives on TCP port 3306.

It does not match rule 100 or rule 200, because both rules specify port 443.

The packet reaches the final * rule.

Action: DENY

Why does the order matter?

Imagine we reverse the first two rules:

Now an HTTPS request from 203.0.113.25 matches rule 100 first.

It is allowed before AWS ever reaches rule 200.

Therefore, rule 200 cannot block those requests.

The important lesson: In Network ACLs, a lower rule number is evaluated first.

When planning custom NACLs, AWS recommends leaving gaps between rule numbers, such as 100, 200, and 300, so new rules can be inserted later.

10. Default Network ACL vs Custom Network ACL

This is another detail beginners should understand.

When you create a VPC, AWS provides a default Network ACL.

The default Network ACL normally allows all inbound and outbound traffic.

For IPv4, its rules conceptually look like this:

The default rule number may be familiar if you've explored the VPC console.

The * rule acts as a final deny rule for traffic that did not match an earlier rule.

What happens when you create a custom Network ACL?

A newly created custom Network ACL starts by denying all inbound and outbound traffic through its final deny rules.

You must add the necessary ALLOW rules before using it for workloads that require network connectivity.

This difference is important.

Suppose your EC2 application is working normally.

You replace the subnet's default Network ACL with a new custom Network ACL that has no ALLOW rules.

Traffic crossing the subnet boundary may suddenly stop working.

The EC2 instance might still be running, and its Security Group might still allow HTTPS.

But the Network ACL prevents the packets from crossing the subnet boundary.

This is why custom Network ACL changes should be planned carefully.

11. Default Security Group vs Custom Security Group

Security Groups have a similar naming distinction, but their defaults work differently.

Default Security Group

Every VPC has a default Security Group.

By default, it normally permits inbound traffic from resources associated with that same Security Group.

It also normally allows all outbound traffic.

This does not mean it permits unrestricted incoming connections from the public internet.

Newly Created Custom Security Group

When you create a new custom Security Group, it normally starts with:

• No inbound allow rules.

• An outbound rule that allows all traffic.

You add inbound rules according to your application's needs.

For example, a public web server might allow TCP 443, while a database server permits TCP 5432 only from the backend application's Security Group.

For beginners, it is often easier to understand and maintain purpose-specific Security Groups than to rely on one broadly shared default group.

12. Security Groups vs Network ACLs: Side-by-Side Comparison

Now that we've explored both concepts, let's compare them directly.

The simplest way to remember this comparison is:

Security Group = Who is allowed to communicate with this resource?

Network ACL = Which traffic is allowed to cross this subnet boundary?

Both controls may apply to the same connection.

13. What Happens When Both a Security Group and a Network ACL Apply?

Consider a public web server.

VPC: 10.0.0.0/16

Subnet: 10.0.1.0/24

EC2 private IP: 10.0.1.10

The web server also has a correctly configured public IPv4 endpoint.

A visitor attempts to connect over HTTPS.

The network route must first provide a valid path to the destination.

The subnet's Network ACL determines whether the request is allowed across the subnet boundary.

The web server's Security Group determines whether the request is permitted to reach its network interface.

The server must also be listening on the expected port.

Scenario A: Both controls allow traffic

Network ACL inbound rule:

TCP 443 → ALLOW

Security Group inbound rule:

TCP 443 → ALLOW

The request is permitted by both network security controls.

The connection can succeed if the route, return path, and application configuration are also correct.

Scenario B: Security Group allows, Network ACL denies

Network ACL inbound rule:

TCP 443 → DENY

Security Group inbound rule:

TCP 443 → ALLOW

The request is blocked by the Network ACL.

The Security Group cannot override that decision.

Scenario C: Network ACL allows, Security Group doesn't

Network ACL inbound rule:

TCP 443 → ALLOW

Security Group has no inbound rule allowing TCP 443.

The request is blocked by the Security Group.

A Network ACL ALLOW rule does not bypass Security Group restrictions.

Scenario D: Both allow incoming HTTPS, but the NACL blocks the response

Network ACL inbound:

TCP 443 → ALLOW

Security Group inbound:

TCP 443 → ALLOW

Network ACL outbound:

No applicable ALLOW rule for the client's ephemeral destination port.

The inbound request can pass, but its response is blocked when leaving the subnet.

The connection may appear to hang or fail.

This example is important because the EC2 instance, application, and inbound rules may all appear correct.

For traffic subject to both controls, an allow decision at one layer does not cancel a deny at the other.

14. A Detail Many Beginners Miss: Traffic Within the Same Subnet

A Network ACL is evaluated when traffic enters or leaves a subnet.

It is not evaluated for ordinary traffic between two EC2 instances communicating within the same subnet.

Suppose:

• EC2 A: 10.0.1.10

• EC2 B: 10.0.1.20

• Both belong to 10.0.1.0/24

Their traffic does not cross that subnet's boundary.

Therefore, the Network ACL is not used to filter that same-subnet communication.

However, their Security Groups still matter.

If EC2 A wants to connect to EC2 B on TCP port 3000, EC2 B's Security Group must permit the connection.

If the connection isn't permitted, it can be blocked even though both instances are in the same subnet.

This is one reason Security Groups are essential for resource-level security.

What if the instances are in different subnets?

Now suppose:

• EC2 A: 10.0.1.10

• EC2 B: 10.0.2.20

They are in different subnets.

The traffic crosses subnet boundaries, so the applicable Network ACL rules are evaluated along with Security Group permissions.

A successful connection may require compatible rules on both subnet boundaries and resource network interfaces.

This distinction is worth remembering:

Same subnet: Security Groups still apply; the subnet's NACL does not filter traffic staying within that subnet.

Different subnets: Security Groups and the applicable subnet NACL rules can both affect communication.

15. A Real-World Example: Protecting a Full-Stack Application

Let's use a familiar application architecture.

Our application has three components:

• Next.js web server

• Node.js backend API

• PostgreSQL database

All resources are inside one VPC.

Assume the web server is the public-facing endpoint, while the API and database remain private.

Web Server Security Group

Name: web-sg

Inbound permission:

This allows IPv4 HTTPS connections from clients with a valid network path.

If the server also needs administrative access, that can be handled through a restricted management path rather than exposing SSH broadly.

API Server Security Group

Name: api-sg

Inbound permission:

The API accepts connections from resources associated with the web server's Security Group.

It does not need to expose TCP 3000 to the public internet.

Database Security Group

Name: db-sg

Inbound permission:

The database accepts PostgreSQL connections from the API tier.

This creates a controlled connection path:

Visitor → Web Server → API Server → Database

The web server can request data from the API.

The API can query the database.

But an arbitrary internet visitor cannot directly connect to the database through this design.

These permissions assume suitable outbound rules and normal VPC routing.

Where do Network ACLs fit?

Each subnet also has an associated Network ACL.

For many straightforward applications, the default Network ACL can remain open while Security Groups enforce resource-specific permissions.

If additional subnet-level controls are required, custom Network ACL rules may be introduced.

For example, an organization might explicitly deny an unwanted source address range at the public subnet boundary.

But such restrictions must be planned carefully, because they apply broadly to traffic crossing that subnet boundary.

A practical principle is to use Security Groups for normal workload access control and Network ACLs when there is a clear reason for an additional subnet-wide restriction.

16. When Should You Use Security Groups and When Should You Use NACLs?

You do not need a complex custom Network ACL for every application.

AWS recommends Security Groups as the primary mechanism for controlling access to resources.

Security Groups are generally easier to maintain because:

• They support stateful connection tracking.

• They can reference other Security Groups.

• They can be tailored to individual application roles.

• They don't require manually permitting ordinary response traffic.

Network ACLs become useful when you need subnet-level controls that Security Groups cannot provide directly.

For example:

Use a Security Group when:

• A database should accept connections only from application servers.

• An API should accept traffic only from the web tier.

• A web server should permit public HTTPS.

• Administrative access should be limited to trusted sources.

Consider a custom Network ACL when:

• You need an explicit deny rule for a particular IP range.

• Your organization requires a subnet-wide access-control policy.

• You want additional network restrictions independent of individual resource Security Groups.

• A documented security requirement specifically calls for subnet-boundary filtering.

Custom Network ACLs are not automatically more secure than leaving the default NACL in place.

Poorly designed rules can create outages, especially when ephemeral response ports are overlooked.

The goal should be appropriate security controls, not simply the largest number of firewall rules.

17. Common Mistakes and Misunderstandings

Mistake 1: Thinking a Security Group can explicitly deny traffic

Security Groups support allow rules only.

Traffic without applicable permission is implicitly denied, but there are no explicit Security Group DENY rules.

Use a suitable Network ACL or another supported network security control when explicit deny behavior is required.

Mistake 2: Thinking Network ACLs automatically allow responses

They don't.

NACLs are stateless.

The request and response must independently satisfy the applicable directional rules.

Mistake 3: Allowing port 443 inbound but forgetting ephemeral ports

A custom Network ACL might allow a web request to enter the subnet but block its response.

The outbound destination port for the response is normally the client's ephemeral source port, not port 443.

Mistake 4: Putting the broad ALLOW rule before a specific DENY rule

Network ACL rules are evaluated by ascending rule number.

The first matching rule determines the result.

An earlier broad ALLOW can prevent a later DENY from ever taking effect.

Mistake 5: Assuming an open Security Group overrides a restrictive NACL

It doesn't.

Both security layers must permit the traffic they evaluate.

Mistake 6: Assuming a restrictive NACL controls two instances inside the same subnet

NACLs don't filter ordinary traffic that stays within the same subnet.

Use Security Groups for resource-level controls.

Mistake 7: Replacing the default NACL without understanding its behavior

A newly created custom Network ACL initially denies inbound and outbound traffic.

Associating it with an active subnet before creating the necessary rules can disrupt connectivity.

Mistake 8: Assuming firewalls replace authentication

Security Groups and NACLs are network-level controls.

They do not replace application authentication, authorization, database credentials, operating system security, or HTTPS encryption.

For example, allowing access to an API on TCP 443 does not prove that every incoming request is authorized to view customer information.

Your application must still enforce its own access rules.

18. How to Think About AWS Network Security When Troubleshooting

Suppose an EC2 web server is running, but you cannot reach the website.

Instead of randomly opening ports, examine the network path.

First: Is there a valid route?

Does the destination have the required network path?

For a public IPv4 EC2 endpoint, this may involve a public address and an Internet Gateway route.

For a private service, this may involve local VPC routes or other appropriate connectivity.

Second: Does the Security Group allow the connection?

Check:

• Inbound protocol and destination port.

• Allowed source IP or Security Group.

• Outbound rules for connections initiated by the resource.

For example, a web server that should accept HTTPS needs the applicable TCP 443 inbound permission.

Third: Does the Network ACL allow both directions?

Check:

• Inbound rules.

• Outbound rules.

• Rule priority.

• Destination ports for return traffic.

• Whether the traffic crosses a subnet boundary.

Remember that a custom NACL may allow the incoming request but block its response.

Fourth: Is the application actually listening?

Network permissions cannot fix an application that is not running or is listening on the wrong interface or port.

For example, a service listening only on 127.0.0.1 may work locally but not accept connections addressed to the instance's private IP.

Fifth: Are there other relevant controls?

Other factors may include:

• Host-based firewalls.

• Network ACLs on another subnet along the path.

• DNS resolution.

• Load balancer configuration.

• Application-level authentication.

• Route or connection-tracking behavior.

For deeper network analysis, AWS VPC Flow Logs and Reachability Analyzer can help investigate network traffic and connectivity paths.

The important habit is to examine each layer rather than treating all connection failures as Security Group problems.

19. Frequently Asked Questions

What is the main difference between a Security Group and a Network ACL?

A Security Group controls allowed traffic for associated resource network interfaces and is stateful.

A Network ACL controls traffic crossing a subnet boundary and is stateless.

Is a Security Group applied to the entire subnet?

No.

Security Groups are associated with supported resources and their network interfaces.

Different EC2 instances in the same subnet can use different Security Groups.

Can I use Security Groups without custom Network ACLs?

Yes.

This is a normal approach for many AWS applications.

Every subnet still has an associated Network ACL, usually the default one unless you change it.

Can a Network ACL block an IP address?

Yes.

A Network ACL can explicitly deny traffic from a specified IP address or CIDR range.

Which one evaluates rules in order?

Network ACLs.

They use numbered rules and first-match evaluation.

Security Groups evaluate their combined applicable allow rules without rule-order priority.

Why do custom Network ACLs need ephemeral port rules?

Because Network ACLs are stateless.

Return packets must independently match appropriate inbound or outbound rules, and the destination port for a response is often a client's temporary source port.

If two EC2 instances are in the same subnet, does the NACL apply?

Not to ordinary traffic traveling directly between those instances within the same subnet.

Their Security Groups and other applicable controls still matter.

Does allowing HTTPS in a Security Group make an instance publicly accessible?

Not by itself.

The instance must also have a valid network route, appropriate public endpoint configuration when required, and a running application listening for traffic.

Can a Security Group deny traffic allowed by a NACL?

Yes, in the sense that a connection lacking a matching Security Group allow rule is not permitted, even if the NACL allows it.

Security Groups do not have explicit deny rules.

Do Security Groups and NACLs cost extra?

AWS does not separately charge for ordinary use of Security Groups or Network ACLs.

Other networking resources, data transfer, public IPv4 addresses, or additional security services may incur charges.

Conclusion

AWS Security Groups and Network ACLs both help protect network communication, but they have different responsibilities.

Security Groups provide stateful access control for resource network interfaces. They are the primary way to permit only the connections your EC2 instances and other supported resources require.

Network ACLs provide stateless filtering at subnet boundaries. They support both allow and deny rules, evaluated in numerical order.

The most important beginner concepts to remember are:

• Security Groups operate at the resource interface level.

• Network ACLs operate at subnet boundaries.

• Security Groups are stateful; Network ACLs are stateless.

• Security Groups allow traffic through matching permissions.

• Network ACLs support explicit ALLOW and DENY decisions.

• Custom Network ACLs require careful handling of return traffic and ephemeral ports.

• Routes, Security Groups, Network ACLs, and application configuration must work together for a connection to succeed.

You don't need to memorize every rule immediately.

Start by understanding what each security control protects, what happens when a packet reaches it, and how the packet's response travels back.

Once those concepts are clear, AWS network security becomes much easier to design and troubleshoot.

References

• Security Groups in Amazon VPC - AWS Documentation

• Security Group Rules - AWS Documentation

• Security Group Connection Tracking - Amazon EC2

• Network ACLs in Amazon VPC - AWS Documentation

• Custom Network ACLs and Ephemeral Ports - AWS Documentation

• Default Network ACLs - AWS Documentation

• Compare Security Groups and Network ACLs - AWS Documentation