April 4, 2026 · Tim Fraser, Cloud Operations Lead

AWS Security Group Audit: A Checklist for Non-DevOps Teams

If you've been handed responsibility for an AWS account and you're not sure whether your security groups are configured correctly, this checklist will get you through it. Security groups are one of the most important — and most commonly misconfigured — parts of any AWS environment.

The good news: you can audit them in under 30 minutes with no special tools. Here's a step-by-step checklist.

What are security groups?

Security groups are virtual firewalls for your AWS resources. Every EC2 instance, RDS database, and load balancer has at least one security group controlling what traffic can reach it.

Think of them as a bouncer at the door: the security group decides who gets in (inbound rules) and who gets out (outbound rules).

The audit checklist

1. Find all security groups open to the internet

This is the most critical check. Go to EC2 → Security Groups and look for any inbound rule with a source of 0.0.0.0/0 (IPv4) or ::/0 (IPv6). This means "anyone on the internet can reach this port."

• Port 22 (SSH) open to 0.0.0.0/0 — anyone can attempt to log into your servers
• Port 3306 (MySQL) or 5432 (PostgreSQL) open to 0.0.0.0/0 — your database is exposed to the internet
• Port 3389 (RDP) open to 0.0.0.0/0 — Windows remote desktop accessible to everyone
• Any port range like 0-65535 open to 0.0.0.0/0 — everything is exposed

• Port 80/443 (HTTP/HTTPS) open to 0.0.0.0/0 — this is normal for web servers and load balancers

2. Check for overly broad port ranges

Some security groups allow ranges like 1024-65535 or even 0-65535. This is almost always a mistake — someone didn't know which specific port was needed and opened everything "temporarily."

For each security group, ask: does this resource actually need all these ports? A web server needs 80 and 443. An API server might need 8080. Almost nothing needs 0-65535.

3. Identify unused security groups

Go to EC2 → Security Groups and check the "Associated instances" column (or filter by network interfaces). Security groups with no associated resources are clutter — they make audits harder and can be accidentally attached later.

Note: don't delete the default security group in any VPC. AWS won't let you anyway, but don't try.

4. Check for security groups referencing themselves

This is a common pattern in AWS — a security group rule that says "allow traffic from this same security group." It's used for allowing instances in the same group to communicate. This is usually fine, but make sure you understand why it's there.

5. Review outbound rules

Most security groups have a default outbound rule allowing all traffic to 0.0.0.0/0. For many workloads this is fine, but for sensitive systems (databases, payment processors), consider restricting outbound traffic to only what's needed.

6. Check your RDS and ElastiCache security groups

Database security groups are often overlooked. Go to RDS → Databases and click on each database. Check its security group — it should only allow connections from your application servers, not from 0.0.0.0/0.

The same applies to ElastiCache (Redis/Memcached) clusters.

7. Look for stale IP addresses in rules

Security group rules often reference specific IP addresses — a developer's home IP, a former office, a CI/CD server that's been decommissioned. These accumulate over time and create unnecessary access.

For each IP-based rule, ask: do we still need this? Does anyone know whose IP this is?

Fixing what you find

For each issue:

• Don't just delete rules — check what's actually using the security group first. Removing a rule that something depends on will cause an outage.
• Restrict, don't remove — if SSH is open to 0.0.0.0/0, restrict it to your office IP or VPN range instead of removing it entirely.
• Use security group references — instead of allowing a specific IP, allow traffic from the security group attached to the resource that needs access. This way, if the IP changes, the rule still works.
• Document why — add a description to every security group rule explaining what it's for. Future you will thank present you.

The ongoing problem

The real challenge with security groups isn't the one-time audit — it's keeping them clean over time. Developers add rules during debugging and forget to remove them. New services get broad rules "for now" that become permanent.

plainfra automates this. Connect your AWS account (read-only) and ask:

> "Do I have any security groups open to the internet?"

plainfra scans every security group across every region and gives you a prioritised list — critical exposures first, informational findings last.

But the real value is the weekly health report. Every Monday, plainfra checks your security groups automatically and flags any new exposures. That "temporary" SSH rule a developer added on Friday? It shows up in Monday's report before it becomes a permanent vulnerability.

Keeping plainfra connected means someone is always checking, not just when you remember to. When an auditor asks "are your security groups locked down?" — you already have the answer.