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 accounts through AWS Transit Gateway (TGW).

The goal was straightforward:

Account A
----------
Internal ALB
   ↓
Transit Gateway
   ↓
Account B
----------
Internal NLB

Account A
----------
Internal ALB
   ↓
Transit Gateway
   ↓
Account B
----------
Internal NLB

Instead 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-sg

Account A
----------
Internal ALB
SG: alb-sg
   ↓
AWS Network Firewall
   ↓
Transit Gateway
   ↓
Account B
----------
Internal NLB
SG: nlb-sg

On the NLB Security Group, I created inbound rules:

Port 80  -> Source: alb-sg
Port 443 -> Source: alb-sg

Port 80  -> Source: alb-sg
Port 443 -> Source: alb-sg

The 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    = REJECT

Source IP = ALB Private IP
Action    = REJECT

Interestingly:

Source = Prefix List      → Works
Source = ALB Security Group → Fails

Source = Prefix List      → Works
Source = ALB Security Group → Fails

This immediately suggested that routing was not the issue.

What I Verified

Transit Gateway Settings

Verified on both VPC attachments:

Security Group Referencing Support = Enabled

Security Group Referencing Support = Enabled

Security 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 Rejected

ALB SG Reference
       ↓
Not Evaluated Successfully
       ↓
Traffic Rejected

Even 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 Address

Source IP Address

Whereas Security Group Referencing evaluates:

Source Security Group Membership

Source Security Group Membership

Because 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
 ↓
NLB

ALB
 ↓
AWS Network Firewall
 ↓
Transit Gateway
 ↓
NLB

Use:

Managed Prefix Lists
Source subnet CIDRs
Source VPC CIDRs

instead of Security Group references.

Example:

NLB Security Group
  Port 443
  Source = Managed Prefix List

NLB Security Group
  Port 443
  Source = Managed Prefix List

This 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-rules

aws ec2 describe-security-group-rules

and confirm:

"ReferencedGroupInfo"

"ReferencedGroupInfo"

exists.

Check Flow Logs

If you see:

Traffic reaches destination ENI
Action = REJECT

Traffic reaches destination ENI
Action = REJECT

the 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.

Contents