Stop Hardcoding IPs: How AWS Security Group Referencing Actually Works

Most of the overly permissive security group rules we find in reviews aren't there because someone was careless. They're there because someone needed two things to talk to each other, didn't have a stable IP to point at, and opened up a CIDR range wide enough to be sure it would work.

That's the actual mechanism behind a surprising share of AWS network exposure. Not negligence — a missing tool. And the tool has been in the console the whole time: instead of putting an IP range in the source field of a rule, you can put another security group.

What referencing actually means

When you reference security group B as the source of an inbound rule in security group A, you are not copying B's rules into A. That's the most common misunderstanding, and it's worth being precise about.

What you're saying is: allow this traffic from any network interface that currently has security group B attached to it.

The membership is evaluated live. Attach B to a new instance and that instance can immediately reach A on the permitted port. Terminate it and the permission disappears with it. Nothing needs updating, because you never wrote down an address in the first place.

This is why referencing survives the situations that break CIDR rules: autoscaling, instance replacement, blue-green deploys, a container moving to a different host. The thing your rule points at is a label, not a location.

The pattern in practice

The typical shape is tiering. Your application servers carry sg-app. Your database carries sg-db. The inbound rule on sg-db allows port 5432 from sg-app — not from a subnet, not from 10.0.0.0/16, and certainly not from 0.0.0.0/0.

The result is a rule that reads like the architecture it's enforcing. Anyone opening that security group six months later can see the intent without having to work out which subnet contained what at the time it was written.

Self-referencing groups are the variation that confuses people most. A security group that references itself as a source means “members of this group can talk to each other on this port.” You'll see it in cluster traffic — node-to-node communication in ElastiCache, EMR, ECS, and similar — and you'll see it in inherited Terraform as self = true. It's usually legitimate. It's worth checking that the port range it opens is narrow, because a self-referencing rule on all ports quietly makes every member of that group fully reachable by every other member.

The rule-limit problem this also solves

There's a quota on how many rules a single security group can hold, and busy accounts hit it. The usual response is to request a quota increase or start attaching additional groups to the same interface, both of which add complexity.

Referencing often removes the need. Fifty individual IP rules for fifty instances collapse into one rule pointing at the group those instances share. One rule, regardless of how many members it has now or later.

For genuine IP ranges that can't be expressed as a group — a partner's network, an office egress IP, a third-party webhook source — a customer-managed prefix list does similar consolidation work, giving you one named object to maintain instead of the same CIDR pasted across a dozen groups.

Where referencing doesn't work

This is the part the tutorials skip, and it's where teams lose an afternoon.

• Anything outside your VPC boundary still needs a CIDR. On-premises networks, a SaaS provider's egress IPs, a customer's office — none of those have a security group you can point at.
• Cross-Region referencing isn't supported. If the two resources are in different AWS Regions, referencing won't get you there regardless of how they're connected.
• Cross-VPC referencing depends on how the VPCs are joined. Peered VPCs in the same Region support it. AWS added referencing support for Transit Gateway in late 2024 and for Cloud WAN in mid-2025, so the answer depends on both your connectivity model and whether the option is enabled on it — check the current documentation for your specific setup rather than assuming.
• Cross-account referencing works within the same Region, but the reference needs the account number alongside the security group ID.
• A referenced group can't be deleted while something still references it. That's a safety feature, though it does mean cleanup has an order to it.

The audit trade-off worth knowing about

Referencing is better security and slightly worse visibility, and it's honest to say so.

A rule that says “allow 5432 from 10.0.3.0/24” tells you exactly what it permits. A rule that says “allow 5432 from sg-app” tells you what it means but not what it currently reaches — to answer that, you have to resolve which interfaces carry sg-app right now.

In practice this is a good trade: intent-based rules are far less likely to drift into over-permission than address-based ones. But it does mean that reviewing security groups properly involves resolving group membership, not just reading the rules. It's one of the reasons a console skim isn't the same thing as an audit.

Where to start

If you want a fifteen-minute version of this: filter your security group rules for sources that are CIDR ranges rather than group references, and ignore anything that legitimately points outside your VPC. What's left is your candidate list. In most accounts we look at, a meaningful share of those rules exist only because nobody had a stable IP to point at on the day they were written.

Working out which rules can be converted, which genuinely need a CIDR, and what your groups actually reach today is exactly the kind of thing our AWS Security & Architecture Review maps out — every group, every rule, and the gap between what's permitted and what's used.