I Thought My AWS EC2 Was Secure — Until I Checked My Security Groups

Source: Dev.to

Why I Thought My EC2 Instance Was Secure

Like many beginners, I focused on getting things to work:

• The EC2 instance launched successfully
• SSH access worked
• The application was reachable

At that point, I moved on — assuming security was “handled”.
What I didn’t do initially was question the default and convenience‑driven choices I had made while configuring the instance. That’s where the problem started.

The Security Group Configuration I Initially Used

When creating the EC2 instance, I allowed inbound traffic with rules similar to:

• SSH (port 22) → Source: 0.0.0.0/0
• HTTP (port 80) → Source: 0.0.0.0/0

At the time, this felt reasonable:

• I needed to access the instance
• I wanted to test connectivity
• AWS allowed it without warnings

But what this actually meant was something much more serious.

What I Realised After Reviewing Security Groups

Security groups are stateful virtual firewalls that control inbound and outbound traffic to EC2 instances.
By allowing traffic from 0.0.0.0/0, I had effectively said:

“Anyone on the internet can try to connect to my instance.”

This includes:

• Automated scanners
• Bots probing open ports
• Malicious actors looking for misconfigured systems

The EC2 instance itself hadn’t changed — but my understanding had.

The Key Mistakes I Made

1. Overly permissive inbound rules

Allowing SSH from anywhere is one of the most common beginner mistakes. Even if no one attacks you immediately, the risk is always present.

2. Treating security groups as a setup form

I treated the security group configuration as a checkbox exercise instead of a security boundary.

3. No principle of least privilege

I allowed more access than was actually needed — simply for convenience.

What I Changed to Secure My EC2 Instance

Restricted SSH access

• SSH allowed only from my specific IP address
• No global access

Reviewed inbound rules carefully

• Only necessary ports were open
• Removed unused or temporary rules

Treated security groups as living controls

• Regularly reviewed instead of “set and forget”
• Adjusted rules based on actual usage

These changes immediately reduced the exposure of the instance.

The Bigger Lesson: AWS Doesn’t Secure Things For You

One important realisation I had is this: AWS provides the tools — you are responsible for how securely you use them.
EC2 is powerful, but it assumes the user understands:

• Networking basics
• Access control
• Exposure risks

Security groups are not advanced features — they are foundational.

Who This Matters For

This lesson is especially important if you are:

• New to AWS
• Learning cloud through hands‑on projects
• Deploying EC2 for the first time
• Preparing for real‑world cloud roles

Understanding security groups early will save you from bigger problems later.

What I’ll Improve Next

This experience pushed me to think beyond basic setup:

• Using bastion hosts instead of direct SSH
• Automating security checks
• Adding monitoring and logging
• Designing architectures that reduce public exposure entirely

Security is not a one‑time task — it’s an ongoing practice.

Final Thoughts

My EC2 instance wasn’t insecure because AWS failed.
It was insecure because I hadn’t fully understood what I was allowing.

Checking your security groups takes minutes — but it can prevent serious issues.
If you’re learning AWS, start there.