Shared VPCs Archives - AWS Security Architect

Shared VPCs for Production and Non Production Assets

anuj varma — Fri, 05 Dec 2025 18:25:49 +0000

Overview

A Shared VPC lets one AWS account (the Host) own a VPC and subnets and share those subnets with other AWS accounts (the Participants). This pattern centralizes networking while keeping workload control in the participant accounts.

High-level approach

Create separate subnet groups for prod and non-prod inside the host VPC.
Participant accounts deploy workloads (EC2, RDS, EKS, etc.) which attach ENIs into those shared subnets.
Host account manages routing, firewalls, NAT, endpoints, DNS and logging — not application compute.

What belongs in the Host VPC account

This account is your centralized networking account. Typical items:

The VPC and its CIDR(s).
Subnets — clearly labeled and separated for prod vs non-prod (e.g. Prod-App-Subnet-A, NonProd-DB-Subnet-A).
Route tables, IGW, VGW/TGW attachments.
Network appliances: NAT gateways, centralized firewall (AWS Network Firewall or 3rd party), IDS/IPS, etc.
VPC endpoints (S3, DynamoDB, Systems Manager) and endpoint policies.
DNS (Route 53 Resolver endpoints) and centralized logging/flow-logs.

Do not run application compute in the Host account — keep it a networking services account to reduce blast radius and permission complexity.

What belongs in the Participant accounts

Participant accounts own the workloads and most of the application-level controls:

Compute: EC2, ECS tasks, EKS worker nodes & pods (that create ENIs), Lambda functions (if VPC-enabled), etc.
Managed database resources such as RDS / Aurora (service ENIs attach to shared subnets).
Security groups — participants create and manage their own SGs.
Deployment pipelines, application IAM roles, monitoring/alerting agents.

Participants cannot modify VPC-level objects (subnets, route tables, IGW/TGW) — this restriction provides network control and safety.

Segmenting Production vs Non-Production

Key controls to host both environments safely in one shared VPC:

Subnet separation: distinct subnets for Prod and Non-Prod, ideally across multiple AZs.
Routing: Prod subnets route to prod-specific firewalls / TGW attachments; non-prod routes to non-prod appliances.
Network-level filtering: security groups, NACLs, and firewall policies that strictly control cross-environment traffic.
Org policy & IAM: use AWS Organizations SCPs, IAM role boundaries and least privilege to prevent privilege escalation between envs.
Separate logging & monitoring: keep prod logs and metrics isolated or labeled and access-controlled.

Example subnet layout (recommended)

Subnet	Purpose	Shared To
Prod-App-Subnet-A/B/C	Production application tier (multi-AZ)	Production participant accounts
Prod-DB-Subnet-A/B	Production databases (private)	Production participant accounts
NonProd-App-Subnet-A/B/C	Dev/Test application tier	Dev/Test participant accounts
NonProd-DB-Subnet-A/B	Non-prod databases	Dev/Test participant accounts
Shared-Services-Subnet	Centralized services: logging, bastion, SSM endpoints	Shared-services account + selected participants

Routing & NAT recommendations

Use separate NAT Gateways for prod and non-prod to avoid accidental traffic mixing and to charge-back costs accurately.
Route prod traffic through prod firewall or dedicated TGW attachment.
Consider Transit Gateway + route tables to control cross-account connectivity at scale.

Governance & security controls

Enforce AWS Organizations SCPs to block participant accounts from creating or modifying VPC infrastructure.
Use IAM and resource-based policies to restrict who can share/attach subnets.
Apply strict endpoint policies for VPC endpoints (S3, Secrets Manager, etc.) to control access by environment.
Use separate monitoring/alerting channels and RBAC for prod vs non-prod.

When NOT to share a VPC

Consider separate VPCs if any of the following are true:

You require absolute network separation for compliance (PCI-DSS, FedRAMP, HIPAA) with independent audit trails.
The environments have fundamentally different routing/firewall/peering needs that are hard to satisfy with one VPC.
You lack governance to centrally control network configuration and access.

Recommended organization structure (example)

The post Shared VPCs for Production and Non Production Assets appeared first on AWS Security Architect.

DMZs versus Shared VPCs

anuj varma — Mon, 03 Nov 2025 22:51:50 +0000

AWS Shared VPC Architecture – Segmentation by Ingress Type

In an AWS Shared VPC architecture, the host account owns and manages the VPC, subnets, and routing.
It shares specific subnets with participant accounts through AWS Resource Access Manager (RAM).
This allows each participant account to deploy workloads into shared subnets — without owning or modifying the core VPC networking.

1. Segmentation Models

A. Environment-Based

Each participant account represents an environment (e.g., Dev, Test, Prod).
Subnets within the shared VPC are labeled and shared accordingly:

Dev Account: dev-public-*, dev-private-* subnets
Test Account: test-public-*, test-private-* subnets
Prod Account: prod-public-*, prod-private-*, prod-isolated-* subnets

This keeps environments isolated while maintaining consistent security and routing through a single centrally managed VPC.

B. Workload-Based (by Ingress Profile)

Alternatively, participant accounts may represent workload ingress types:

Edge / Public Ingress Account: Internet-facing workloads using ALB/NLB, CloudFront origins.
Private Services Account: Application workloads reachable only through internal ALBs, VPC Lattice, or PrivateLink.
Data or Regulated Account: Isolated workloads (RDS, MSK, S3 endpoints) accessible only through endpoints or service meshes.

2. Ingress Flow Diagram

          +----------------------+
          |      Internet        |
          +----------+-----------+
                     |
                     v
         +-----------+-----------+
         |  Edge (Public Ingress)|
         |  Account – ALB/NLB    |
         +-----------+-----------+
                     |
                     v
         +-----------+-----------+
         |  Private App Services |
         |  Account – ECS/EKS    |
         +-----------+-----------+
                     |
                     v
         +-----------+-----------+
         |   Data/Isolated Tier  |
         |   Account – RDS, EFS  |
         +-----------------------+

Each tier runs in its own participant account using subnets shared from the host VPC.
Traffic flows from public ALBs → internal services → data layers, all within controlled ingress boundaries.

3. Governance and Control Layers

Subnet Sharing: Host account shares only the appropriate subnets (public/private/isolated) with each participant account.
Routing: Host account manages route tables (e.g., IGW routes only for public subnets, NAT or GWLB for private).
Security Groups: Participant accounts define SGs for their resources; AWS Firewall Manager can enforce org-wide SG policies.
Network Firewall: Centralized inspection via AWS Network Firewall or GWLB in the host account.
SCPs & Config: Prevent public resources in private-only accounts; ensure compliance via Config/FMS rules.

4. Example Mapping Table

Participant Account	Shared Subnets	Ingress Type	Typical Components	Notes
acct-edge	edge-public-, edge-private-	Public (ALB/NLB)	Internet ALB, WAF, CloudFront	Handles all internet-facing ingress
acct-apps	apps-private-*	Private	Internal ALB, ECS, EKS, Lattice	Accessible only via internal routing or Lattice
acct-data	data-isolated-*	Private (no IGW/NAT)	RDS, Aurora, MSK, S3 Endpoints	Ingress via Lattice/PrivateLink only
acct-prod	prod-public-, prod-private-, prod-isolated-*	Mixed (Controlled)	Tiered production stack	Strict SCP and FMS enforcement

5. Key Enforcement Mechanisms

Use AWS Firewall Manager to enforce org-wide SG and NFW policies.
Apply Service Control Policies (SCPs) to block creation of public ALBs or IGWs in private-only accounts.
Implement Config Rules for continuous compliance (public IP detection, restricted-ssh).
Tag subnets and accounts with Environment and IngressType for automation and visibility.

The post DMZs versus Shared VPCs appeared first on AWS Security Architect.

AWS Shared VPC vs. Transit Gateways

anuj varma — Fri, 24 Oct 2025 14:41:06 +0000

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 (ENIENI via SGs) and north-south flows (routes/IGW/NAT/Firewall).

The post AWS Shared VPC vs. Transit Gateways appeared first on AWS Security Architect.