Why security groups matter in AWS - See It in Action

Why Security Groups Matter

📖 Scenario: You are setting up a simple web server on AWS. To keep it safe, you need to control who can connect to it. AWS Security Groups act like a virtual firewall that controls traffic to your server.In this project, you will create a security group, add rules to allow web traffic, and then attach it to an EC2 instance.

🎯 Goal: Build an AWS security group that allows HTTP and SSH access, then attach it to an EC2 instance to protect your server from unwanted traffic.

📋 What You'll Learn

Create a security group named web-sg with a description Allow HTTP and SSH

Add an inbound rule to allow TCP traffic on port 80 from anywhere

Add an inbound rule to allow TCP traffic on port 22 from a specific IP 203.0.113.5/32

Create an EC2 instance named web-server and attach the web-sg security group

💡 Why This Matters

🌍 Real World

Security groups are essential to protect cloud servers from unauthorized access, just like locks on doors protect your home.

💼 Career

Understanding security groups is a fundamental skill for cloud engineers and system administrators to secure cloud infrastructure.

1

Create the security group

Create a security group named web-sg with the description Allow HTTP and SSH using AWS CLI syntax.

AWS

# Create security group web-sg with description
# Your code here

Hint

Use aws ec2 create-security-group command with --group-name and --description options.

2

Add inbound rules to the security group

Add an inbound rule to the web-sg security group to allow TCP traffic on port 80 from anywhere (0.0.0.0/0), and another inbound rule to allow TCP traffic on port 22 from IP 203.0.113.5/32.

AWS

aws ec2 create-security-group --group-name web-sg --description "Allow HTTP and SSH"
# Add inbound rule for HTTP port 80 from anywhere
# Add inbound rule for SSH port 22 from 203.0.113.5/32
# Your code here

Hint

Use aws ec2 authorize-security-group-ingress twice, once for port 80 and once for port 22 with the specified CIDRs.

3

Launch an EC2 instance with the security group

Launch an EC2 instance named web-server using the Amazon Linux 2 AMI, t2.micro instance type, and attach the web-sg security group by specifying its group name.

AWS

aws ec2 create-security-group --group-name web-sg --description "Allow HTTP and SSH"
aws ec2 authorize-security-group-ingress --group-name web-sg --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-name web-sg --protocol tcp --port 22 --cidr 203.0.113.5/32
# Launch EC2 instance web-server with security group web-sg
# Your code here

Hint

Use aws ec2 run-instances with --security-groups web-sg and add a tag with Name=web-server.

4

Verify the security group attachment

Write the AWS CLI command to describe the EC2 instance named web-server and confirm it has the web-sg security group attached.

AWS

aws ec2 create-security-group --group-name web-sg --description "Allow HTTP and SSH"
aws ec2 authorize-security-group-ingress --group-name web-sg --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-name web-sg --protocol tcp --port 22 --cidr 203.0.113.5/32
aws ec2 run-instances --image-id ami-0c02fb55956c7d316 --count 1 --instance-type t2.micro --security-groups web-sg --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-server}]'
# Describe the instance web-server to check security groups
# Your code here

Hint

Use aws ec2 describe-instances with a filter for the tag Name=web-server and query the SecurityGroups field.

Practice

1. What is the main purpose of a security group in AWS?

easy

A. To control inbound and outbound network traffic to resources

B. To store data securely in the cloud

C. To manage user permissions for AWS services

D. To monitor the health of AWS resources

Solution

1. Step 1: Understand what security groups do

   Security groups act like virtual firewalls that control network traffic to and from AWS resources.

2. Step 2: Identify the main function

   The main function is to allow or block inbound and outbound traffic based on rules.

3. Final Answer:

   To control inbound and outbound network traffic to resources -> Option A

4. Quick Check:

   Security groups control traffic = A [OK]

Hint: Security groups control traffic flow to resources [OK]

Common Mistakes:

• Confusing security groups with data storage
• Thinking security groups manage user permissions
• Assuming security groups monitor resource health

2. Which of the following is the correct way to allow HTTP traffic on port 80 in a security group rule?

easy

A. Allow inbound TCP traffic on port 80

B. Allow outbound UDP traffic on port 80

C. Allow inbound TCP traffic on port 22

D. Allow inbound ICMP traffic on port 80

Solution

1. Step 1: Identify the protocol and port for HTTP

   HTTP uses TCP protocol on port 80.

2. Step 2: Match the correct rule

   Allowing inbound TCP traffic on port 80 correctly allows HTTP requests.

3. Final Answer:

   Allow inbound TCP traffic on port 80 -> Option A

4. Quick Check:

   HTTP = TCP port 80 inbound [OK]

Hint: HTTP uses TCP port 80 inbound [OK]

Common Mistakes:

• Allowing wrong protocol like UDP or ICMP for HTTP
• Allowing outbound instead of inbound traffic
• Using wrong port number like 22 (SSH)

3. Given a security group with these inbound rules:
- Allow TCP port 22 from 0.0.0.0/0
- Allow TCP port 80 from 192.168.1.0/24
Which IP address can access port 80?

medium

A. 10.0.0.5

B. 0.0.0.0

C. 192.168.1.15

D. 172.16.0.1

Solution

1. Step 1: Understand the CIDR block for port 80

   The rule allows TCP port 80 only from IPs in 192.168.1.0/24 range, which means 192.168.1.0 to 192.168.1.255.

2. Step 2: Check which IP fits the range

   192.168.1.15 is inside the allowed range, others are not.

3. Final Answer:

   192.168.1.15 -> Option C

4. Quick Check:

   192.168.1.0/24 includes 192.168.1.15 [OK]

Hint: Check if IP fits CIDR range for allowed port [OK]

Common Mistakes:

• Confusing 0.0.0.0/0 with specific ranges
• Assuming all IPs can access port 80
• Mixing up port 22 and port 80 rules

4. You created a security group rule to allow inbound SSH (port 22) from your office IP, but you still cannot connect. What is the most likely mistake?

medium

A. The rule allows outbound traffic instead of inbound

B. The office IP is not in the allowed CIDR range

C. The rule uses UDP instead of TCP for port 22

D. The security group is attached to the wrong resource

Solution

1. Step 1: Check rule direction and protocol

   Inbound SSH requires TCP on port 22 inbound; if rule is correct, this is fine.

2. Step 2: Verify security group attachment

   If the security group is not attached to the resource (like EC2 instance), rules won't apply.

3. Final Answer:

   The security group is attached to the wrong resource -> Option D

4. Quick Check:

   Security group must be attached to resource [OK]

Hint: Check if security group is attached to your resource [OK]

Common Mistakes:

• Ignoring security group attachment
• Confusing inbound and outbound rules
• Using wrong protocol for SSH

5. You want to secure a web server so only your company's office IP range (203.0.113.0/24) can access HTTP (port 80), but allow SSH (port 22) from anywhere for remote admins. Which security group rules should you create?

hard

A. Allow inbound TCP port 80 from 0.0.0.0/0 and inbound TCP port 22 from 203.0.113.0/24

B. Allow inbound TCP port 80 from 203.0.113.0/24 and inbound TCP port 22 from 0.0.0.0/0

C. Allow inbound TCP port 80 and 22 both from 203.0.113.0/24 only

D. Allow inbound TCP port 80 and 22 both from 0.0.0.0/0 only

Solution

1. Step 1: Match HTTP access to office IP range

   HTTP (port 80) should be allowed only from 203.0.113.0/24 to restrict access to office IPs.

2. Step 2: Allow SSH from anywhere

   SSH (port 22) should be open to 0.0.0.0/0 to allow remote admins from any IP.

3. Final Answer:

   Allow inbound TCP port 80 from 203.0.113.0/24 and inbound TCP port 22 from 0.0.0.0/0 -> Option B

4. Quick Check:

   HTTP restricted, SSH open = A [OK]

Hint: Restrict HTTP, open SSH from anywhere [OK]

Common Mistakes:

• Reversing IP ranges for ports
• Opening HTTP to all IPs
• Restricting SSH too much