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? 🚀