# 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?** 🚀 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://awsinpractice.itassist.com/study-group/aws-certified-solutions-architect-associate/domain-1-design-secure-architectures/task-statement-1.2-design-secure-workloads-and-applications/security-group.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.