June 3, 2026
AWS Transit Gateway Security Group Referencing — Lessons Learned, Limitations, and Troubleshooting
Recently, I was working on a multi-account AWS architecture where traffic needed to flow securely between workloads hosted in different AWS…
Pankaj Gupta
2 min read
Recently, I was working on a multi-account AWS architecture where traffic needed to flow securely between workloads hosted in different AWS accounts through AWS Transit Gateway (TGW).
The goal was straightforward:
Account A
----------
Internal ALB
↓
Transit Gateway
↓
Account B
----------
Internal NLBAccount A
----------
Internal ALB
↓
Transit Gateway
↓
Account B
----------
Internal NLBInstead of managing CIDRs or prefix lists, I wanted to leverage AWS Transit Gateway Security Group Referencing to allow traffic based on Security Group membership.
While the feature looked promising, I encountered some unexpected limitations that are worth sharing.
What is Transit Gateway Security Group Referencing?
Traditionally, Security Group references only worked within the same VPC or in limited peering scenarios.
AWS introduced Security Group Referencing for Transit Gateway, allowing Security Groups in one VPC to reference Security Groups attached to resources in another VPC connected through the same Transit Gateway.
Benefits include:
- Reduced dependency on CIDR-based rules
- Easier security management
- Dynamic access control based on Security Groups
- Simplified multi-account architectures
My Architecture
The setup looked like this:
Account A
----------
Internal ALB
SG: alb-sg
↓
AWS Network Firewall
↓
Transit Gateway
↓
Account B
----------
Internal NLB
SG: nlb-sgAccount A
----------
Internal ALB
SG: alb-sg
↓
AWS Network Firewall
↓
Transit Gateway
↓
Account B
----------
Internal NLB
SG: nlb-sgOn the NLB Security Group, I created inbound rules:
Port 80 -> Source: alb-sg
Port 443 -> Source: alb-sgPort 80 -> Source: alb-sg
Port 443 -> Source: alb-sgThe Transit Gateway attachments had Security Group Referencing enabled. Everything appeared correctly configured.
The Problem
Traffic consistently failed.
VPC Flow Logs on the NLB ENI showed:
Source IP = ALB Private IP
Action = REJECTSource IP = ALB Private IP
Action = REJECTInterestingly:
Source = Prefix List → Works
Source = ALB Security Group → FailsSource = Prefix List → Works
Source = ALB Security Group → FailsThis immediately suggested that routing was not the issue.
What I Verified
Transit Gateway Settings
Verified on both VPC attachments:
Security Group Referencing Support = EnabledSecurity Group Referencing Support = EnabledSecurity Group Rules
The Security Group rule was confirmed as a valid SG reference:
"ReferencedGroupInfo": {
"GroupId": "sg-xxxxxxxx",
"VpcId": "vpc-xxxxxxxx"
}"ReferencedGroupInfo": {
"GroupId": "sg-xxxxxxxx",
"VpcId": "vpc-xxxxxxxx"
}This ruled out:
- Incorrect SG IDs
- Invalid SG references
- CIDR-based misconfigurations
Routing
Confirmed:
- TGW route tables
- VPC route tables
- Return paths
Traffic was reaching the NLB VPC successfully.
NACLs
Verified that required ports and ephemeral return traffic were allowed.
The Root Cause
The key discovery came from the AWS documentation.
AWS explicitly states:
Security group referencing through Transit Gateway does not work across AWS Network Firewall or Gateway Load Balancer inspection paths.
In our environment, traffic traversed AWS Network Firewall before reaching the Transit Gateway.
As a result:
ALB SG Reference
↓
Not Evaluated Successfully
↓
Traffic RejectedALB SG Reference
↓
Not Evaluated Successfully
↓
Traffic RejectedEven though:
- TGW SG Referencing was enabled
- Security Group references were valid
- Routing was correct
The inspection path introduced a limitation that prevented the feature from functioning as expected.
Why Prefix Lists Worked
A Prefix List rule evaluates:
Source IP AddressSource IP AddressWhereas Security Group Referencing evaluates:
Source Security Group MembershipSource Security Group MembershipBecause Prefix Lists rely only on IP matching, they continued to function correctly even when traffic traversed AWS Network Firewall.
Recommended Workaround
For architectures involving:
ALB
↓
AWS Network Firewall
↓
Transit Gateway
↓
NLBALB
↓
AWS Network Firewall
↓
Transit Gateway
↓
NLBUse:
- Managed Prefix Lists
- Source subnet CIDRs
- Source VPC CIDRs
instead of Security Group references.
Example:
NLB Security Group
Port 443
Source = Managed Prefix ListNLB Security Group
Port 443
Source = Managed Prefix ListThis approach proved reliable and production-ready.
Key Takeaways
Before implementing Transit Gateway Security Group Referencing:
Verify TGW Configuration
- TGW Security Group Referencing enabled
- VPC Attachment Security Group Referencing enabled
Validate Security Group References
Use:
aws ec2 describe-security-group-rulesaws ec2 describe-security-group-rulesand confirm:
"ReferencedGroupInfo""ReferencedGroupInfo"exists.
Check Flow Logs
If you see:
Traffic reaches destination ENI
Action = REJECTTraffic reaches destination ENI
Action = REJECTthe issue is likely Security Group evaluation rather than routing.
Understand the Limitation
Security Group Referencing through Transit Gateway does not work across:
- AWS Network Firewall inspection paths
- Gateway Load Balancer inspection paths
This limitation can be easy to miss during design reviews.
Final Thoughts
Transit Gateway Security Group Referencing is a powerful feature for multi-account AWS environments. However, like many networking features, the implementation details matter.
If your architecture includes AWS Network Firewall or Gateway Load Balancer inspection VPCs, plan on using Prefix Lists or CIDR-based controls instead of Security Group references.
A few hours of troubleshooting can often be saved by understanding these limitations upfront.