Security Groups Demo

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:

ssh -i main.pem ec2-user@<Public-IP>

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.

Now SSH attempts will time out:

ssh -i main.pem ec2-user@<Public-IP>
# (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:

sudo yum install nginx -y
sudo systemctl start nginx

Verify locally:

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:

ping 8.8.8.8
# 100% packet loss

4. Re-add “All traffic” outbound rule and retry:

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

Links and References

• AWS Security Groups
• AWS Network ACLs
• Amazon EC2 Documentation
• Nginx Official Site