Day 2 of 100 Days of Cloud (AWS): Creating an EC2 Security Group
Learning how AWS controls inbound and outbound network traffic around EC2 resources.
Day 2 of my 100 Days of Cloud (AWS) journey focused on one of the most important building blocks of EC2 security: Security Groups.
On Day 1, I created an EC2 key pair for secure authentication. Today, I moved one step further by controlling which network traffic would actually be allowed to reach an EC2 instance.
Objective
Create a Security Group named:
xfusion-sg
and configure it to allow:
HTTP traffic on TCP port
80SSH traffic on TCP port
22
The Security Group also needed to be associated with the required VPC.
What I Configured
From the Amazon EC2 Console, I navigated to:
Network & Security → Security Groups → Create security group
I configured the basic details as follows:
Security Group name:
xfusion-sgDescription:
Security group for Nautilus App ServersVPC: Selected the required VPC
Next, I configured the inbound rules.
HTTP Rule
Type: HTTP
Protocol: TCP
Port:
80Source:
0.0.0.0/0
SSH Rule
Type: SSH
Protocol: TCP
Port:
22Source:
0.0.0.0/0
After reviewing the configuration, I created the Security Group and confirmed that xfusion-sg appeared successfully in the Security Groups list.
What Exactly Is a Security Group?
An AWS Security Group acts as a virtual firewall around resources such as EC2 instances.
It controls which traffic is permitted based on criteria such as:
Protocol
Port
Source or destination
For example, allowing TCP port 22 permits SSH connections, while allowing TCP port 80 permits standard HTTP traffic.
One important characteristic is that Security Groups are stateful.
If an inbound connection is permitted, AWS automatically allows the response traffic associated with that connection. You do not need to create a separate outbound rule just to permit the reply.
A Security Lesson From This Lab
Both inbound rules used:
0.0.0.0/0
This means traffic can originate from any IPv4 address.
For HTTP on port 80, allowing public internet access may be intentional when hosting a public website.
For SSH on port 22, however, allowing access from anywhere would usually be a poor security practice in a production environment.
A safer configuration would restrict SSH to something such as:
My trusted public IP → Port 22
or use controlled administrative access through a bastion host or another secure access method.
The lab configuration helped me understand an important principle:
Just because AWS allows a configuration does not mean it is the configuration you should use in production.
What I Learned
Today's exercise helped me understand that launching an EC2 instance is only part of the job.
I also have to decide:
Who should be able to reach it? Which services should be exposed? Which ports actually need to be open?
Security Groups give me that control.
Another important takeaway was the principle of least privilege: only allow the network access that a workload genuinely requires.
