Security Group Referencing Across a Peered VPC That Breaks on Scaling

Security group referencing across peering works only when the referenced security group and the referencing resource are in VPCs that are peered and in the same Region, and the rule must reference a security group that actually contains the new instances.

Likely causes

1. The new Auto Scaling group uses a different security group. If the migration created a new security group for the web tier, the app tier's inbound rule still references the old group, which no longer contains the instances. Connections from the new instances are denied.
2. The new subnet range is not covered by the peering route. The route tables have the peer CIDR, but if the new subnet is outside the VPC CIDR or the route was scoped narrowly, traffic has no path.
3. Security group referencing requires the reference to resolve to the peer VPC's group. If the rule was recreated as a CIDR rule during migration, least-privilege is already violated.
4. NACLs. If the new subnet's NACL does not allow ephemeral return ports, the TCP handshake fails even though the security group allows 8443.

Least-privilege fix

• Update the app tier's inbound rule to reference the current web tier security group by ID (not a CIDR). If multiple web groups exist, add explicit references for each and remove stale ones.
• Ensure the new subnet is within the VPC CIDR covered by the peering route, or add the correct route.
• Verify NACLs on both sides allow 8443 inbound and the ephemeral range for return traffic.
• If the web tier spans VPCs, remember security group referencing does not work across non-peered or cross-Region paths; use a documented alternative such as a prefix list or a centralized inspection point, and record the exception.

Audit

Keep the rule as a security group reference, tag both groups with owner and purpose, and export security group configuration to your compliance evidence store so the reference is traceable.

Produce evidence at three layers: configuration, effective reachability, and continuous monitoring.

Configuration evidence

• Export the app tier security group's inbound rules showing a single allow for TCP 8443 sourced from the web tier security group ID, and no 0.0.0.0/0 or broad CIDR rules.
• Export the web tier security group's membership (instance IDs) and confirm every instance that should reach the app tier is a member.
• Export NACLs and route tables for both VPCs to show no alternate path.

Effective reachability evidence

• Use Reachability Analyzer from a web tier instance ENI to an app tier ENI on 8443 and show it is allowed; run a second analysis from an unrelated instance and show it is blocked.
• Capture a successful TLS connection test from an approved instance and a denied connection from a non-member to demonstrate enforcement.

Continuous monitoring

• Enable AWS Config rules that flag security groups allowing 8443 from 0.0.0.0/0 or from CIDRs, and flag drift from the approved reference.
• Alert on changes to the app tier security group and require review before the change is approved.
• Periodically re-run Reachability Analyzer and store results with timestamps as recurring evidence.

Keeping it current

Automate the exports on a schedule, store them in a versioned evidence bucket, and tie the process to the change management workflow so any security group or peering change regenerates the evidence. If the web tier moves again, the reference-based rule and the automated checks will surface the gap before it becomes an outage.