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