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.