In our last lesson, we launched our first EC2 instance, exploring the hardware (instance types) and secure access methods (key pairs). We noted that a Security Group acts as a virtual firewall for the instance, but we only touched on its default settings. Today, we delve deep into the network security of your AWS environment.
This lesson focuses on mastering the two fundamental firewall layers in a Virtual Private Cloud (VPC): Security Groups (SGs) and Network Access Control Lists (NACLs). Understanding how to configure these is non-negotiable for building secure, scalable systems. For your goal of working in a FAANG-level environment, proficiency here is an absolute baseline expectation, as it forms the core of a "defense in depth" security posture.
Two Layers of Network Defense
In AWS, network traffic must pass through multiple checkpoints before reaching your application. The two most important checkpoints are the NACL and the Security Group. Think of it this way: a NACL is the border control for an entire neighborhood (a subnet), while a Security Group is the dedicated security guard for a specific building (an EC2 instance).
A great way to remember the distinction comes from the "Go Cloud Architects" channel: "Network ACLs keep traffic out of the subnet; Security Groups keep traffic out of an instance."
While both filter traffic, they operate on fundamentally different principles. Let's explore these differences.
How to Understand Security Groups vs Network ACLs - OneUptime
This article from OneUptime provides a clear, concise breakdown of the core differences between Security Groups and NACLs. It is an excellent foundation for understanding their distinct roles.
As you read, focus on the following key comparisons: Stateful vs. Stateless: This is the most crucial difference. Pay close attention to the example of response traffic. Scope: Note where each is applied—the instance vs. the subnet. Rule Evaluation: Understand how SGs process all rules simultaneously, while NACLs process them in numerical order. Allow vs. Deny Rules: This highlights a key functional difference. Finally, review the comparison table to solidify your understanding of these points.
Security Groups: The Stateful Instance Firewall
As you've just read, Security Groups are your primary, fine-grained firewall. They are stateful, which is a powerful feature. This means that if you allow an outbound connection from your instance (e.g., to download a software package), the Security Group automatically allows the return traffic for that connection, without you needing to create a specific inbound rule.
By default, a new Security Group:
- Denies all inbound traffic. You must explicitly add rules to allow traffic in.
- Allows all outbound traffic. Your instance can initiate connections to anywhere.
The following practical demonstration from Abhishek.Veeramalla shows exactly what happens when an application is blocked by default and how to fix it by configuring an inbound rule.
Day-5 | AWS Security Group and NACL | Theory + Practical | AWS FREE COURSE by Abhishek |#devops #aws
Watch this segment to see the default "deny all inbound" behavior of a Security Group in action and how to correctly configure it.
Focus on the demonstration from this section. The instructor launches a simple Python web server on port 8000, shows that it's inaccessible by default, and then adds an inbound rule to the Security Group to allow traffic on that port.
Best Practice: Referencing Other Security Groups
One of the most powerful features of Security Groups is the ability to use another SG as the source or destination in a rule, rather than an IP address range (CIDR block). This is fundamental to building secure, multi-tier applications.
For example, you can create a rule in your database's Security Group (db-sg) that allows traffic on the database port (e.g., 5432 for PostgreSQL) only from your application's Security Group (app-sg). This means any EC2 instance in app-sg can connect to the database, regardless of its IP address. If your application scales up or down, you don't need to update any IP-based firewall rules. This creates a dynamic and tightly-controlled security boundary between your application tiers.
Network ACLs: The Stateless Subnet Gatekeeper
NACLs are your first line of defense, operating at the subnet boundary. They are stateless, meaning they inspect every packet in isolation, without any context of previous packets. This has a critical implication: you must create explicit rules for both inbound and outbound traffic.
If you allow inbound traffic on port 443 (HTTPS) to your web server, the server's response will be blocked unless you also have an outbound rule that allows traffic destined for the high-numbered ephemeral ports (typically 1024-65535) on the client's machine. Your networking background will tell you that this is how TCP/IP connections manage response traffic, and NACLs force you to account for this explicitly.
The main use cases for NACLs are:
- Blocking specific IPs: Since SGs only have
allowrules, NACLs are your tool for blacklisting known malicious IP addresses or ranges. - Enforcing broad policies: You can set a baseline for an entire subnet, for example, by ensuring that no traffic is allowed on sensitive ports like SSH (22) or RDP (3389) from the internet, regardless of how individual Security Groups are configured. This serves as a critical safety net.
The ordered, stateless nature of NACLs makes them powerful but also requires careful configuration. The video below demonstrates how a NACL rule can block traffic even if the Security Group allows it, and why the rule numbering is so important.
Day-5 | AWS Security Group and NACL | Theory + Practical | AWS FREE COURSE by Abhishek |#devops #aws
This segment demonstrates the power and precedence of NACLs, including the critical importance of rule order.
Watch the demonstration from this section. The instructor first adds a deny rule in the NACL for port 8000, showing how it blocks traffic despite the Security Group allowing it. Then, they demonstrate how changing the rule number (priority) can change the outcome, as NACL rules are processed in ascending order.
A Practical Scenario: Understanding Stateful vs. Stateless
To truly grasp the difference, let's walk through two scenarios with a practical example.
AWS VPC — Security Groups Vs NACLs
This Medium post provides a fantastic, hands-on demonstration of both SG and NACL behavior using AWS CLI commands and a real-world setup.
First, read the section on Security Groups and then follow the practical test under the heading "To test this scenario". The author shows that an EC2 instance can fetch data from an external API (curl command) even with no inbound rules. This is a perfect illustration of the stateful nature of SGs—the outbound request is allowed, and the response is automatically let back in. Next, jump to the section "Explore Network ACL Scenario" and read through the setup. Then, pay close attention to the explanation of ephemeral ports from this paragraph. This demonstrates the complexity of stateless NACLs, where you must manually account for the return traffic on these high-numbered ports.
Synthesis: Defense in Depth
Security Groups and Network ACLs are not an "either/or" choice; they are designed to be used together to create a layered security model.
Here is a common and effective strategy:
- Security Groups: Use them as your primary tool for fine-grained access control. Define specific rules for each application tier, referencing other SGs whenever possible to create tight, dynamic, and IP-independent policies.
- Network ACLs: Use them as a blunt instrument and a safety net. Keep the default NACL (which allows all traffic) for most subnets, and create custom NACLs only when you need to:
- Statelessly block a range of known bad IP addresses.
- Enforce a broad, static rule for an entire subnet (e.g., a public subnet should only ever allow inbound traffic on ports 80 and 443).
When troubleshooting network connectivity, always remember to check both layers. Traffic being blocked could be the result of a missing SG rule, a restrictive NACL rule, or both.
Conclusion
In this lesson, we've dissected the two pillars of network security within an AWS VPC. Mastering their distinct functions is essential for any DevOps professional responsible for building and maintaining secure infrastructure.
Key Takeaways:
- Defense in Depth: SGs and NACLs provide two layers of firewall protection. SGs are close to the instance, while NACLs guard the entire subnet.
- Stateful vs. Stateless: Security Groups are stateful, automatically allowing return traffic. Network ACLs are stateless, requiring explicit allow rules for both inbound and outbound traffic, including ephemeral ports.
- Rule Types and Evaluation: Security Groups only support
allowrules and evaluate them all at once. NACLs support bothallowanddenyrules and process them in numerical order, stopping at the first match. - Best Practice: Use Security Groups for specific, dynamic application-level permissions and Network ACLs for broad, static subnet-level rules and blacklisting.
Now that we've covered compute instances (EC2) and their network security controls (SGs and NACLs), our next lesson will put all the pieces together. We will design and build a custom VPC from the ground up, including public and private subnets, route tables, and the gateways needed to connect your network to the internet and other AWS services.