skip to content

In an AWS security group rule, what does it mean to name another security group as the source instead of a CIDR block, and where does that stop working?

level: middleimportance: should knowfreq 52%

answer

  1. membership, not addresses
  2. rules that survive an Auto Scaling event
  3. resolves to attached interfaces' private IPs
  4. no match when the source is a public or NAT address

basics

~20 s

It means "any network interface that currently has that security group attached", resolved to their private addresses. Membership replaces addresses, so rules survive scaling and IP churn. It only applies to traffic arriving on private addresses inside the VPC or a same-Region peered VPC.

solid answer

~50 s

Naming a security group as the source turns the rule from an address statement into a **membership** statement: the database's group allows port 5432 from `sg-app` rather than from a CIDR, and AWS resolves that to the private addresses of every ENI currently carrying `sg-app`. Instances that scale in or out are covered automatically, with no rule edits and no IP bookkeeping, and the rule keeps meaning the right thing when subnet CIDRs are re-planned. It also expresses intent — "the app tier may reach the database" — which a CIDR never does. The limits are that it matches only on **private** addresses inside the VPC, so traffic that arrives via an internet gateway or a NAT gateway carries the wrong source IP and never matches; it is not available across Regions; and network ACLs cannot reference security groups at all, only CIDRs.

go deeper

for a junior

Know that a rule's source can be another security group and that it means "instances carrying that group", not a copy of its rules. Be able to sketch the load balancer to app to database chain.

for a middle

Explain that AWS resolves the reference to the private addresses of member ENIs, why statefulness means the rule goes only on the receiving side, and why a self-referencing group is the cluster-gossip pattern.

for a senior

Debug it out loud: the caller's ENI does not carry the named group, or the traffic arrives on a public or NAT address instead of a private one. Mention that tracked connections can outlive the revoked rule.

for a principal

Frame it as a naming standard. Group references make the rule set readable and auditable as an architecture, and they are what makes CIDR-based rules a liability once several teams share a VPC and re-plan its address space.

## Membership instead of addresses A security-group rule needs a source for inbound traffic (or a destination for outbound). That source can be a CIDR block, a managed prefix list, or **another security group**. The third option is the one that separates people who have run a real VPC from people who have read about one. When the database tier's security group carries an inbound rule of `TCP 5432 from sg-app`, it is not saying "from these addresses". It is saying "from any elastic network interface that currently has `sg-app` attached". AWS resolves that membership continuously to the private IP addresses of those interfaces. Launch three more application instances into the Auto Scaling group and they are covered the moment their ENI comes up; terminate them and the permission evaporates with them. ## What this buys you **It survives churn.** Instance addresses in a VPC are ephemeral. A rule pinned to `10.0.3.47/32` is stale the next time that instance is replaced; a rule pinned to a group is never stale. **It survives re-planning.** Rules written as `10.0.0.0/16` quietly permit anything that lands anywhere in the VPC, including workloads that arrive years later. A rule pinned to a group keeps its meaning when subnets are added or CIDRs are resized. **It states intent.** `sg-app -> sg-db on 5432` reads as an architecture diagram. A reviewer can tell whether it is correct. `10.0.3.0/24 -> 10.0.7.0/24 on 5432` requires them to go and look up what lives in those subnets. **It is not symmetric, and does not need to be.** Because security groups are stateful, the rule goes on the *receiving* side only. The database group allows inbound from `sg-app`; the application group needs no matching outbound rule beyond its default allow-all egress, and the replies flow back on the tracked connection. ## The canonical shapes The tiered pattern: ``` sg-alb inbound tcp 443 from 0.0.0.0/0 sg-app inbound tcp 8080 from sg-alb sg-db inbound tcp 5432 from sg-app ``` Nothing but the load balancer can reach the application port, and nothing but the application can reach the database — expressed in three rules that never need editing as the fleet scales. The self-referencing shape is the other common one: a security group whose inbound rule names *itself*, so that every member can talk to every other member. That is exactly what the VPC's default security group does, and it is how cluster members — a Redis replication group, a Kafka-style peer set, a service mesh's sidecars — are allowed to gossip without enumerating anyone. ## Where it stops working **Public paths.** The match is on the packet's source address as it arrives at the ENI, and that must be the private address of a member interface. If traffic leaves the VPC and comes back through an internet gateway, the source is a public IP. If it goes out through a NAT gateway, the source is the NAT gateway's address. Neither matches the group reference. This is a real trap: two instances in the same VPC that talk over each other's *public* DNS names will fail a rule that would have worked over their private names. **Cross-Region.** Security-group references work within a VPC and across a VPC peering connection when both VPCs are in the same Region — including across accounts, where you write the reference as the peer account's ID plus the group ID. Peering between Regions does not support referencing, so those rules fall back to CIDRs. **Network ACLs.** A NACL rule takes a CIDR block only. There is no way to express "from that security group" at the subnet layer, which is one more reason subnet-level filtering ages badly. **Connection tracking outlives the rule.** Removing a group reference does not necessarily sever connections already established through it; a tracked flow can persist until it goes idle. If you are revoking access during an incident, verify the connections actually dropped rather than assuming the rule change was instantaneous. ## The interview shape The question is usually asked as a debugging scenario: "the rule allows `sg-app` and the app still cannot reach the database". The two answers worth having ready are that the traffic is arriving on a public or NAT address rather than a private one, and that the caller's ENI does not actually carry `sg-app` — a common outcome when a task, Lambda function or load balancer node was launched with a different group than the one the rule names.

  • An application instance reaches its database by the database's public DNS name and the rule allowing sg-app does not match. Why?
    Resolving the public name sends the traffic out through the internet gateway, so it arrives with a public source address rather than the member ENI's private address, and the group reference cannot match it. Using the private DNS name keeps the flow inside the VPC on private addresses and the rule works. This is also why the public path costs you data-transfer charges you did not intend.
  • What is a self-referencing security group for?
    It lets every member of the group talk to every other member without enumerating addresses — cluster peers, replication traffic, sidecars. The VPC's default security group is exactly this: its inbound rule names itself. Scope the ports rather than allowing all traffic, otherwise one compromised member has unrestricted lateral reach across the whole group.
  • Can a network ACL rule reference a security group?
    No. Network ACL rules accept a CIDR block only, because they sit at the subnet boundary and know nothing about which interfaces carry which groups. That is a real argument for keeping segmentation in security groups: the subnet layer cannot express identity, only addresses, so its rules go stale as the network is re-planned.

saying these in an interview costs you the question

  • Thinking the rule copies the other group's rules in
  • Adding a matching outbound rule on the source group as well
  • Expecting the reference to match traffic arriving via NAT or an internet gateway
  • Believing security-group references work across Regions
  • Trying to name a security group in a network ACL rule

context

resolving links…