AWS Security Groups and NACLs

# CHAPTER 10

AWS Security Groups and NACLs #

1. Introduction #

In Chapter 9, we built a custom VPC network with Public and Private subnets. However, placing a server in a Public Subnet means anyone on the internet can attempt to connect to it. To defend your infrastructure against continuous automated hacking attempts, AWS provides a rigorous, two-tiered firewall system. In this chapter, we will dissect the differences between the instance-level Security Groups and the subnet-level Network Access Control Lists (NACLs), mastering the flow of inbound and outbound traffic.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Define the function of a Security Group (SG).

• Define the function of a Network Access Control List (NACL).

• Differentiate between Stateful and Stateless firewalls.

• Configure Inbound and Outbound rules based on Ports and IP addresses.

• Architect a defense-in-depth firewall strategy.

3. Beginner-Friendly Explanation #

Imagine a highly secure hotel.

• The NACL (Network ACL): This is the security guard standing at the front gates of the hotel property (The Subnet). The guard holds a list: "Allow everyone in, EXCEPT Bob." If Bob tries to walk onto the property, the guard denies him instantly.

• The Security Group: This is the electronic lock on your specific hotel room door (The EC2 Instance). The door is completely locked by default. You must explicitly program the lock: "Allow Alice to enter." If Charlie walks past the front gate and tries your door, he is denied because he wasn't explicitly allowed.

4. Security Groups (The First Line of Defense) #

Security Groups are firewalls attached directly to the EC2 Instance.

• Default Behavior: They Deny all Inbound traffic, and Allow all Outbound traffic.

• Rule Type: You can ONLY create "Allow" rules. (e.g., "Allow Port 80"). You cannot create a rule that says "Deny IP 198.x.x.x".

• Stateful: Security Groups are *Stateful*. If you send an outbound request from your EC2 server to download a file from Google, the Security Group automatically remembers the connection and allows the file to come back *Inbound*, regardless of the inbound rules.

5. Network ACLs (The Second Line of Defense) #

Network ACLs are firewalls attached to the Subnet. They protect every instance inside that subnet globally.

• Default Behavior: A default NACL allows ALL Inbound and ALL Outbound traffic.

• Rule Type: You can create BOTH "Allow" and "Deny" rules. (e.g., "Deny IP 198.x.x.x"). Rules are evaluated in numerical order (Rule #10 is checked before Rule #20).

• Stateless: NACLs are *Stateless*. If you allow outbound traffic on Port 80 to access Google, the NACL will block Google's response from coming back unless you explicitly write a separate Inbound rule allowing the return traffic!

6. Architectural Use Cases #

Why use both?

• Security Groups are for application logic. "Allow Port 80 for HTTP, Allow Port 22 for SSH."

• NACLs are for blocking specific bad actors. If a hacker at IP address 203.0.113.50 is DDoS attacking your web server, you cannot block them with a Security Group (because SGs only have "Allow" rules). You create a NACL rule: Rule #10: Deny Inbound IP 203.0.113.50. The hacker's traffic is instantly dropped at the edge of the subnet, saving your EC2 instance's CPU.

7. Mini Project: Secure EC2 Infrastructure #

Let's securely chain Security Groups together (a highly professional architectural pattern). Imagine a Web Server (Public) that talks to a Database (Private).

Step-by-Step Conceptual Configuration:

1. 1. Create Web-SG (Security Group for Web Server):

• *Inbound:* Allow HTTP (Port 80) from 0.0.0.0/0 (The whole internet).

1. 2. Create DB-SG (Security Group for Database):

• *Inbound:* Allow MySQL (Port 3306). But from where? You do not type an IP address. You type the ID of the Web-SG (e.g., sg-0abc123)!

• *Result:* The database will physically reject all traffic UNLESS the traffic comes from an EC2 instance wearing the Web-SG security group. This is brilliant because if you launch 50 Web Servers, they all instantly get database access without you updating IPs!

8. Best Practices #

• Never Leave Port 22 (SSH) Open to the World: A Security Group with an inbound rule allowing Port 22 from 0.0.0.0/0 is a massive vulnerability. Always restrict SSH access to your specific personal IP address (e.g., 203.0.113.10/32).

9. Common Mistakes #

• Muddling NACLs: Beginners often try to secure their applications by writing dozens of complex NACL rules. Because NACLs are stateless and require managing complex "Ephemeral Ports" for return traffic, configuring them incorrectly usually breaks the entire subnet. Stick to modifying Security Groups 99% of the time, and only touch NACLs to explicitly block malicious IPs.

10. Exercises #

1. 1. Contrast a Stateful firewall with a Stateless firewall. Which AWS firewall type falls into which category?

1. 2. If an EC2 instance is placed in a Subnet, and the NACL allows Port 80, but the Security Group attached to the instance denies Port 80, can traffic reach the instance? Why?

11. MCQs with Answers #

12. Interview Questions #

• Q: Explain the defense-in-depth architecture of combining Network ACLs and Security Groups. At what physical layer does each operate, and what specific types of rules can you construct with one that you cannot with the other?

• Q: An architect configures an EC2 database security group inbound rule to reference another security group's ID (e.g., allowing traffic from sg-12345) rather than referencing an IP CIDR block. Explain why this is the industry-standard best practice for scalable multi-tier architectures.

13. FAQs #

Q: Can I attach multiple Security Groups to a single EC2 instance? A: Yes! You can attach up to 5 Security Groups to an instance. Their rules are evaluated as a union. For example, you can attach a "Web-SG" (Allows Port 80) and a separate "Admin-SG" (Allows Port 22 from the office IP) to the same server, keeping your rules highly modular and organized.

14. Summary #

In Chapter 10, we fortified our virtual network with a robust, two-tiered firewall architecture. We defined Network ACLs as the stateless, subnet-level border guards capable of explicitly denying malicious traffic. We contrasted them with Security Groups, the stateful, instance-level locks that enforce strict "Allow-only" application logic. Finally, we learned the powerful architectural pattern of chaining Security Groups together by referencing their IDs, ensuring that databases securely trust only authorized backend servers.

15. Next Chapter Recommendation #

Our servers are secure, but a single web server will crash if 10,000 users log on simultaneously. We need to split the traffic. Proceed to Chapter 11: AWS Load Balancers.