AWS Security Group Analyzer

Read a set of security group rules. Two properties explain most of what is confusing about them, and both are the opposite of how a network ACL behaves.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Analyze. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

SSH open to the internet

Scanned continuously, and Session Manager removes the need entirely

inbound tcp 22 0.0.0.0/0

The whole private range

Wider than your VPC, and a future peering widens it further

inbound tcp 5432 10.0.0.0/8

A group reference

Follows membership rather than addresses, which is what you want

inbound tcp 5432 sg-0123abcd

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Adding a security group to restrict access

    Groups only allow, and the result is the union of all of them. Attaching another can only widen what is reachable.

    Instead:Remove or narrow the rule that is too broad, or use a network ACL for a deny.

  2. Allowing the whole private range because it is not public

    It covers every peered network and every VPN, present and future, so a peering added later silently widens the rule.

    Instead:Use the VPC's own CIDR, or reference the source security group.

  3. Opening SSH to 0.0.0.0/0 temporarily

    It is found by scanners within minutes, and temporary rules are the ones that stay.

    Instead:Use Session Manager, which needs no inbound rule at all.

Everything is an allow, and the result is the union

There is no deny rule. Attaching another group can only widen access, never narrow it, and the effective permission is every rule in every attached group added together.

Which means blocking one address needs a network ACL

A security group cannot express "everything except this". If you need a deny, the ACL on the subnet is the only place to put it.

They are stateful, so return traffic is automatic

An allowed inbound connection's replies go out regardless of the outbound rules. This is why a security group needs no ephemeral port rule, and it is exactly the assumption that makes network ACLs confusing, because those track nothing.

Reference a group rather than a CIDR

Allowing sg-0123abcd lets in anything currently in that group, following membership rather than addresses. It keeps working when instances are replaced and needs no updating when subnets change, which a VPC CIDR does not.

The whole private range is wider than your VPC

10.0.0.0/8 covers every peered VPC, every VPN and every Direct Connect network reachable from here, including ones added next year. A peering can widen the rule with nobody editing it.

SSH and RDP on 0.0.0.0/0 are found within minutes

These ports are scanned continuously, whatever the instance is called and however temporary the change was meant to be. Session Manager needs no inbound rule at all, which is the answer rather than a narrower CIDR.

What this cannot see

Which interfaces the group is attached to, or what the network ACL says. It reads the rules you paste, in your browser, and makes no API call.