Shared VPCs for Production and Non Production Assets

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)

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)