✅ Day 12 of My Cloud Journey ☁ – Mastering AWS Security Groups vs. Network ACLs 🔐

Today’s focus was on one of the most critical parts of AWS networking and cloud security: understanding Security Groups (SGs) and Network ACLs (NACLs) in an AWS VPC.

Security is the backbone of the cloud, and today I took a deep dive into how AWS provides multiple layers of network protection — starting from the instance level (Security Groups) to the subnet level (NACLs).

---

🔍 What Are Security Groups?

A Security Group in AWS is like a virtual firewall for your EC2 instances. It controls inbound and outbound traffic and is associated with instances, not subnets.

🔐 Key Properties of Security Groups:

• Stateful: This means if you allow an inbound rule, the response is automatically allowed outbound.

• Applied at the instance level (not subnet).

• Rules are configured based on:

  • Protocol (TCP, UDP, ICMP)

  • Port range (22, 80, 443, etc.)

  • Source/Destination (IP address, CIDR block, SG ID)

• Default behavior:

  • All inbound traffic is denied

  • All outbound traffic is allowed

---

🔐 What Are Network ACLs (NACLs)?

A Network ACL is an optional firewall for your subnets, providing stateless filtering. You need to define both inbound and outbound rules, as return traffic is not automatically allowed.

🔑 Key Characteristics:

• Stateless: Responses must be explicitly allowed.

• Works at the subnet level

• Rules evaluated in order, from lowest to highest number

• Allows both allow and deny rules

• Default NACL allows all traffic (inbound/outbound)

---

🏛️ Architectural Scenario

Let’s say you have:

• One Public Subnet with a web server (Apache)

• One Private Subnet hosting a database (MySQL)

• Security Group attached to EC2 instances

• Custom NACL applied to subnets

---

✅ Hands-On: Security Groups

📌 Task: Allow HTTP and SSH access to EC2 instance

1. Security Group Inbound Rules:

   • Type: SSH | Protocol: TCP | Port: 22 | Source: My IP

   • Type: HTTP | Protocol: TCP | Port: 80 | Source: 0.0.0.0/0

2. Outbound Rules:

   • Leave default (All traffic allowed)

🧪 Test:

• SSH into EC2 ✅

• Open http://<ec2-public-ip> in browser ✅

---

✅ Hands-On: Network ACLs

📌 Task: Restrict HTTP to EC2 only and block pings (ICMP)

1. Inbound NACL Rules:

   | Rule # | Type | Protocol | Port | Source | Allow/Deny | | --- | --- | --- | --- | --- | --- | | 100 | HTTP | TCP | 80 | 0.0.0.0/0 | ALLOW | | 101 | SSH | TCP | 22 | My IP | ALLOW | | 102 | ICMP | ICMP | ALL | 0.0.0.0/0 | DENY | | * | ALL | ALL | ALL | 0.0.0.0/0 | DENY |

2. Outbound NACL Rules (Keep default or adjust similarly)

🧪 Test:

• Can SSH and browse HTTP ✅

• Can’t ping the instance ❌

---

⚖️ Security Groups vs. NACLs: Comparison Table

---

🎯 Best Practices

• Use Security Groups to control traffic to/from instances

• Use NACLs for blacklisting IPs, subnet-wide restrictions

• Monitor with VPC Flow Logs

• Document your rules

• Follow least privilege principle: only allow required ports/protocols

---

🧠 What I Learned:

• Security Groups are simpler and more intuitive for most cases

• NACLs provide additional layer of protection and control

• Real-world cloud security means using both together

• AWS CLI can be used to manage SGs & NACLs via aws ec2 commands

---

🧪 Bonus CLI Commands:

bashCopyEdit# List all security groups
aws ec2 describe-security-groups

# Add a rule to SG
aws ec2 authorize-security-group-ingress \
    --group-id sg-xxxxxxxx \
    --protocol tcp --port 80 \
    --cidr 0.0.0.0/0

# Create custom NACL
aws ec2 create-network-acl --vpc-id vpc-xxxxxxxx

---

🚀 What’s Next?

Tomorrow (Day 13), I’ll explore VPC Peering — how to connect two separate VPCs together to allow internal communication across accounts or regions!