> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Security Groups Demo
> This lesson explores securing AWS resources using Security Groups and Network ACLs, covering EC2 instance launch, traffic control, and best practices for network security.
In this lesson, we’ll explore how to secure AWS resources using Security Groups and Network ACLs (NACLs). You’ll learn to:
* Launch an EC2 instance
* Configure Security Groups to control inbound/outbound traffic
* Demonstrate stateful behavior
* Split and reuse groups for modular access control
* Reference Security Groups in other rules
By the end, you’ll have hands-on experience with AWS best practices for network security.
## Launching the EC2 Instance
Start by launching an EC2 instance named **server-one** with the default Amazon Linux 2 AMI.
On the **Networking** page, choose your VPC. AWS automatically creates a default Security Group allowing inbound SSH (TCP 22) from `0.0.0.0/0`. You can restrict this later.
Review your settings and click **Launch**.
## Verifying Initial Connectivity
Once **server-one** is in the **running** state, select it and open the **Security** tab. You should see:
* Inbound: SSH (TCP 22) from `0.0.0.0/0`
* Outbound: All traffic to `0.0.0.0/0`
Connect via SSH to confirm:
```bash theme={null}
ssh -i main.pem ec2-user@
```
If you see the EC2 prompt, SSH is working.
## Blocking All Inbound Traffic
To illustrate rule enforcement, remove SSH access:
1. Go to **Security Groups** → select the default group.
2. Click **Edit inbound rules**.
3. Delete the SSH (22) rule and **Save**.
By removing all inbound rules, you will lose SSH access to your instance. Be prepared to re-attach a group that allows SSH.
Now SSH attempts will time out:
```bash theme={null}
ssh -i main.pem ec2-user@
# (connection times out)
```
## Creating a Web Server Security Group
Next, create **web-server-sg** in the same VPC (Description: “Security group for web applications”):
* Inbound:\
• SSH (TCP 22) from `0.0.0.0/0`
* Outbound: All traffic to `0.0.0.0/0`
## Attaching the Security Group
Attach **web-server-sg** to **server-one**:
1. Select the instance.
2. **Actions → Security → Change security groups**.
3. Remove the old group and add **web-server-sg**.
4. Save.
Now SSH will succeed again.
## Installing and Testing Nginx
SSH into **server-one** and run:
```bash theme={null}
sudo yum install nginx -y
sudo systemctl start nginx
```
Verify locally:
```bash theme={null}
curl localhost
```
You should see the Nginx welcome page HTML.
## Allowing HTTP and HTTPS Access
By default, HTTP (80) and HTTPS (443) are blocked. Update **web-server-sg**:
1. Edit inbound rules.
2. Add:\
• HTTP (TCP 80) from `0.0.0.0/0`\
• HTTPS (TCP 443) from `0.0.0.0/0`
3. Save.
Visiting the instance’s public IP in a browser now displays the Nginx welcome page.
## Demonstrating Stateful Behavior
Security Groups are stateful: return traffic is automatically allowed, even if outbound rules are removed.
1. Remove all outbound rules.
2. Refresh the Nginx page in your browser—it still loads.
3. From the instance, try an outbound ping:
```bash theme={null}
ping 8.8.8.8
# 100% packet loss
```
4. Re-add “All traffic” outbound rule and retry:
```bash theme={null}
ping 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=1.58 ms
```
## Splitting Rules into Multiple Security Groups
For modularity, create two groups:
* **allow-ssh-sg**\
• Inbound: SSH (TCP 22) from `0.0.0.0/0`
* **allow-http-sg**\
• Inbound: HTTP (TCP 80) from `0.0.0.0/0`
Detach **web-server-sg** and attach both **allow-ssh-sg** and **allow-http-sg** to **server-one**. You now have combined SSH + HTTP access.
## Reusing Security Groups Across Instances
Apply **allow-ssh-sg** and **allow-http-sg** to **server-two** to grant identical access controls.
## Referencing Security Groups as Rule Sources
For database connectivity, create **db-sg**:
* Inbound: PostgreSQL (TCP 5432)\
• Source: **allow-http-sg**
This ensures any instance with **allow-http-sg** can connect on port 5432.
By referencing another group, new web servers automatically gain DB access as soon as they attach **allow-http-sg**.
Subnet-level filtering with NACLs provides an additional control layer for stateless, rule-based traffic filtering.
## Summary of Security Groups
| Security Group | Description | Inbound Rules | Outbound Rules |
| -------------- | -------------------------------- | ---------------------------------------- | -------------- |
| web-server-sg | Web application servers | SSH (22), HTTP (80), HTTPS (443) | All traffic |
| allow-ssh-sg | Modular SSH access | SSH (22) | All traffic |
| allow-http-sg | Modular HTTP access | HTTP (80) | All traffic |
| db-sg | Database access from web servers | PostgreSQL (5432) from **allow-http-sg** | All traffic |
## Links and References
* [AWS Security Groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)
* [AWS Network ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)
* [Amazon EC2 Documentation](https://docs.aws.amazon.com/ec2/)
* [Nginx Official Site](https://nginx.org/)