# ✅ 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

| Feature | Security Groups | NACLs |
| --- | --- | --- |
| Level | Instance | Subnet |
| Stateful/Stateless | Stateful | Stateless |
| Allow/Deny | Only allow | Allow & Deny |
| Evaluation | All rules | Rule number order (lowest →) |
| Use Case | App/service-level filtering | Broad subnet-level filtering |

---

## 🎯 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:

```plaintext
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!
