# Security Group

Security Groups act as **virtual firewalls** for **EC2 instances, RDS databases, Lambda functions (VPC-connected), and other AWS resources**. They control **inbound and outbound traffic** based on defined rules.

#### **✅ Key Characteristics of Security Groups**

✔ **Stateful:** If an inbound rule allows traffic, the response is automatically allowed.\
✔ **Default Deny:** All inbound traffic is denied unless explicitly allowed.\
✔ **Instance-Level Security:** Rules apply at the instance level, not the subnet level.\
✔ **Supports Allow Rules Only:** No explicit deny rules like Network ACLs.

***

### **📌 Security Group Use Cases & Scenarios**

#### **1️⃣ Web Server Access (Public-Facing Application)**

**Use Case:** SecureCart hosts a public e-commerce website that users access via HTTPS.\
✅ Allow **HTTP (80) and HTTPS (443)** from **anywhere** (0.0.0.0/0).\
✅ Allow SSH (22) access **only from a trusted IP** (e.g., SecureCart’s office network).

**Security Group Rules:**

| **Protocol** | **Port** | **Source**      | **Purpose**               |
| ------------ | -------- | --------------- | ------------------------- |
| HTTP         | 80       | 0.0.0.0/0       | Allow public web traffic  |
| HTTPS        | 443      | 0.0.0.0/0       | Secure web traffic (TLS)  |
| SSH          | 22       | Trusted IP Only | Secure SSH administration |

✅ **Best Practice:**

* Never expose SSH (22) to **0.0.0.0/0**; use **trusted IPs** or AWS Systems Manager Session Manager.

***

#### **2️⃣ Database Access in Private Subnet**

**Use Case:** SecureCart uses an RDS database in a **private subnet** that only backend applications should access.\
✅ Allow inbound traffic only from **application instances** within the VPC.

**Security Group Rules:**

| **Protocol** | **Port** | **Source**    | **Purpose**                       |
| ------------ | -------- | ------------- | --------------------------------- |
| MySQL/Aurora | 3306     | App Server SG | Allow DB connections from the app |
| PostgreSQL   | 5432     | App Server SG | Allow DB connections from the app |

✅ **Best Practice:**

* Use **Security Group references** instead of IP-based rules to allow traffic between instances dynamically.
* **Do not expose database ports to the internet** (0.0.0.0/0).

***

#### **3️⃣ Secure API Gateway with AWS Lambda in a VPC**

**Use Case:** SecureCart runs an API behind API Gateway, triggering a Lambda function that accesses a private RDS instance.\
✅ Ensure API Gateway cannot directly access the database.\
✅ Use security groups to allow Lambda-to-RDS communication.

**Security Group Rules:**

| **Resource**    | **Allowed Traffic**           |
| --------------- | ----------------------------- |
| Lambda Function | Outbound to RDS (3306/5432)   |
| RDS Database    | Inbound from Lambda SG (3306) |

✅ **Best Practice:**

* **Minimize direct access to databases** from the internet.
* Use **VPC Endpoints** instead of public API access when possible.

***

#### **4️⃣ Load Balancer Securing EC2 Instances**

**Use Case:** SecureCart runs its application behind an **Application Load Balancer (ALB)**.\
✅ Allow only traffic from the ALB to the EC2 instances.\
✅ Allow only the public-facing ALB to receive internet traffic.

**Security Group Rules:**

| **Resource**         | **Protocol** | **Port** | **Source** | **Purpose**                 |
| -------------------- | ------------ | -------- | ---------- | --------------------------- |
| ALB (Public)         | HTTP         | 80       | 0.0.0.0/0  | Allow public traffic        |
| ALB (Public)         | HTTPS        | 443      | 0.0.0.0/0  | Secure TLS traffic          |
| App Server (Private) | HTTP         | 80       | ALB SG     | Only allow traffic from ALB |

✅ **Best Practice:**

* **Restrict ALB access** to **specific trusted IPs** if it’s an internal app.
* **Ensure backend instances accept only ALB traffic**, not direct external access.

***

#### **5️⃣ Secure Remote Access with Bastion Host**

**Use Case:** SecureCart’s engineers need secure access to EC2 instances in private subnets.\
✅ Allow SSH only to a **bastion host** in a public subnet.\
✅ Allow private EC2 instances to accept SSH only from the **bastion host**.

**Security Group Rules:**

| **Resource** | **Protocol** | **Port** | **Source**      | **Purpose**               |
| ------------ | ------------ | -------- | --------------- | ------------------------- |
| Bastion Host | SSH          | 22       | Trusted IPs     | Secure engineer access    |
| Private EC2  | SSH          | 22       | Bastion Host SG | Allow only bastion access |

✅ **Best Practice:**

* **Use AWS Session Manager instead of a bastion host** for increased security.
* If using a bastion, **rotate SSH keys** and **enable MFA**.

***

#### **6️⃣ Secure Data Transfers with VPC Peering**

**Use Case:** SecureCart has separate VPCs for **e-commerce services** and **payment processing**.\
✅ Secure cross-VPC communication using **VPC peering** and security groups.

**Security Group Rules:**

| **Resource**               | **Protocol** | **Port** | **Source**            | **Purpose**                  |
| -------------------------- | ------------ | -------- | --------------------- | ---------------------------- |
| E-commerce App (VPC-1)     | HTTPS        | 443      | Payment Processing SG | Secure API calls to payments |
| Payment Processing (VPC-2) | HTTPS        | 443      | E-commerce App SG     | Secure response traffic      |

✅ **Best Practice:**

* **Use private DNS resolution** for seamless inter-VPC communication.
* **Apply security group rules instead of opening entire subnets**.

***

### **📌 Security Group Best Practices**

✅ **Follow the principle of least privilege** – Allow only necessary traffic.\
✅ **Use Security Group references instead of IP addresses** when possible.\
✅ **Regularly audit security groups** for unused or overly permissive rules.\
✅ **Enable AWS Network Firewall or AWS WAF** to add an extra layer of protection.

***

### **📌 Common Mistakes**

❌ **Exposing SSH (22) or RDP (3389) to the internet** – Use VPN or AWS Systems Manager Session Manager.\
❌ **Overly broad security group rules (e.g., allowing 0.0.0.0/0)** – Always restrict to necessary IPs.\
❌ **Not reviewing security group changes** – Implement AWS Config to track changes.\
❌ **Assuming security groups replace NACLs** – Use **NACLs for subnet-level filtering** and security groups for instance-level protection.

***

### **📌 Summary**

🚀 **AWS Security Groups provide fine-grained control over inbound and outbound traffic at the instance level, ensuring workload security and compliance.**\
✔ **Use security groups with ALB to restrict backend instance traffic**.\
✔ **Lock down RDS to allow access only from application servers**.\
✔ **Secure VPC peering by limiting inter-VPC traffic with security groups**.\
✔ **Use AWS best practices to enforce strong security and prevent misconfigurations**.

Would you like a **step-by-step lab guide for implementing security groups in AWS?** 🚀