Security Group

What is a security group?

A security group is a stateful virtual firewall attached to network interfaces (EC2 instances, RDS, load balancers, Lambda-in-VPC). Two properties define everything about how you use it. It’s allow-only: rules permit traffic, there is no deny, and everything not allowed is dropped. And it’s stateful: if inbound port 443 is allowed, the response leaves automatically — no matching outbound rule needed, no thinking about ephemeral ports.

The pattern that separates good from bad configs

Amateur configs allow CIDR ranges; professional configs reference other security groups: the database SG allows 5432 from the app-tier SG — not from a subnet range. Now membership defines access: any instance joining the app tier can reach the database, anything else can’t, and the rule survives IP churn, autoscaling, and subnet redesigns. This one habit turns security groups into an identity-like access model instead of brittle IP lists.

Where breaches actually start

0.0.0.0/0 on port 22 or 3389 remains the classic self-inflicted exposure — bots scan the entire IPv4 space for it continuously, and an open SSH port collects brute-force attempts within minutes. Databases with wide-open SGs are the second classic. The operational disciplines that matter: no 0.0.0.0/0 except on load balancers serving the public, session-manager/SSM instead of open SSH, and automated audits (Config rules, access analyzers) that alert on wide rules — because SGs accrete quietly, and every “temporary” rule is permanent until audited.

What people get wrong

• Confusing SGs with NACLs — SGs are stateful and instance-level; NACLs are stateless and subnet-level. Different tools, different jobs.
• One giant shared SG for everything, making least privilege impossible and every change a blast-radius question.
• Forgetting outbound: default allow-all egress means exfiltration is unimpeded; locking egress is the neglected half.

Primary source: AWS VPC documentation — security groups

Security Group Best Practices

Because security groups are stateful and support both allow rules referencing other security groups (rather than just fixed IP ranges), a common and recommended pattern is to reference security groups by ID rather than by IP address when defining rules between application tiers — for example, allowing a database security group to accept traffic only from an application server security group, rather than from a specific IP range that might change as instances are replaced. This makes security group configurations more resilient to infrastructure changes and easier to reason about at a glance, since the rule describes a relationship between logical tiers of the architecture rather than a set of IP addresses that requires cross-referencing against current infrastructure to understand.