AWS Shared VPCs as an Alternative to Transit Gateways

How Security Groups behave for resources in shared subnets (Account-level roles, cross-account references, and enforcement path).

TL;DR: In a Shared VPC, participant accounts place ENI-owning resources directly inside subnets owned by a host account. Security Groups remain stateful per-ENI and must be owned by the ENI’s account, but you can reference SGs across accounts via RAM for least-privilege, SG-to-SG allow rules. NACLs and routes stay host-managed.

Overview: Shared VPC vs. Transit Gateway

Aspect	Shared VPC	Transit Gateway
Purpose	Centralize network & security for multiple accounts in a single VPC.	Scalable hub-and-spoke to connect many VPCs/on-prem networks.
Use Case	Multi-account workloads co-resident in common subnets.	Large, multi-region or BU-isolated topologies.
Data Path	Intra-VPC (no extra hops).	Via TGW; additional hop.
Performance	Lower latency (east-west).	Slightly higher latency through TGW.
Cost	No TGW processing fees.	Attachment + data processing charges.
Management	Host account owns VPC, subnets, routes, NACLs; shares via RAM.	Each VPC independently attaches and maintains TGW route tables.
Security Boundary	Common VPC fabric; SGs & NACLs enforce isolation.	Each VPC has independent boundary; TGW governs interconnect.

How Shared VPCs Work

Host Account

Owns VPC, subnets, route tables, IGW/NAT, NACLs.
Shares subnets with participant accounts via AWS RAM.
Controls routing, NACL policy, logging (Flow Logs/GuardDuty).

Participant Accounts

Create EC2/ENIs into shared subnets.
Own ENIs and the SGs that attach to those ENIs.
May reference host/other SGs (if shared) for least-privilege rules.

Data Plane

Traffic stays inside the same VPC fabric.
East-west isolation: stateful SGs + stateless NACLs.
North-south governed by routes, IGW/NAT/Firewall.

Security Groups in Shared Subnets

1) Ownership Model

ENI owner = participant account.
SG attached to an ENI must be owned by the same account as the ENI.
Cross-account references to SGs are supported when shared via RAM.

2) Cross-Account SG References

Example: allow inbound from a host-owned SG to a participant SG.

aws ec2 authorize-security-group-ingress \
  --group-id sg- \
  --source-group sg-

Requirements: same Organization, SG shared via RAM, and the reference is within the same VPC context.

3) Enforcement Path

SGs (stateful): evaluated per ENI on both sides of a flow. Return traffic is auto-allowed.
NACLs (stateless): subnet-level allow/deny managed by the host account (both directions must be allowed).
Routes: host account controls egress/ingress reachability (e.g., to IGW, NAT, Firewall, endpoints).

4) Administrative Controls

Component	Managed by	Description
Security Groups	Participant	Each account defines SGs for its ENIs/instances.
SG Cross-References	Host & Participant	Allowed when SGs are shared via RAM; use SG-to-SG rules over CIDR.
NACLs	Host	Subnet-level stateless filters; participants cannot modify.
Routing Tables	Host	Controls north-south and inter-subnet reachability.
Flow Logs / GuardDuty	Host	Central visibility and threat detection across shared subnets.

Best Practices

Prefer SG-to-SG rules instead of broad CIDRs.
Enable VPC Flow Logs in the host account; aggregate to a central log account.
Use AWS Network Firewall or Gateway Load Balancer in the host account for inspection.
Combine with PrivateLink to expose services between participant workloads without IGW/NAT.
Use clear SG naming conventions indicating owning account and purpose.

Diagram: Network Flow & SG Enforcement (Shared VPC)

architecture diagram (PNG/SVG) showing Host Account, Participant Account, shared subnets, SGs on each ENI, NACLs (host-managed), and arrows for east-west (ENI↔ENI via SGs) and north-south flows (routes/IGW/NAT/Firewall).

shared VPC aws

AWS Shared VPC vs. Transit Gateways