A single VPC tutorial gets you to "something works." Getting to "this is production-ready" requires understanding VPC design constraints, Transit Gateway routing logic, and how AWS PrivateLink eliminates service exposure at the network layer. This article covers the patterns used in enterprise-scale AWS deployments.

VPC CIDR Planning — Get It Right the First Time

VPC CIDRs cannot be changed after creation. Poor CIDR planning is one of the most common causes of networking rework in AWS environments that scaled past their original design.

  • Use RFC 1918 space, but plan for growth: A /16 per environment (prod, staging, dev) with /24 subnets per AZ per tier gives you room to grow without overlap issues.
  • Reserve space for future Transit Gateway peering: Overlapping CIDRs across VPCs that are later peered via Transit Gateway cannot be resolved without re-IPing. Document all CIDR allocations in a central IP Address Management (IPAM) tool — AWS provides native IPAM in VPC.
  • Three-tier subnet structure: Public (load balancers, NAT gateways), Private (compute), Isolated (databases, with no route to the internet or NAT). Isolated subnets should have no NAT gateway routes — use VPC Endpoints for S3 and DynamoDB access.

Transit Gateway: Hub-and-Spoke at Scale

VPC peering is fine for a handful of VPCs. Beyond 5–10 VPCs, the full-mesh peering model becomes unmanageable: N(N-1)/2 peering connections, each requiring manual route management. Transit Gateway (TGW) solves this with a regional hub router that all VPCs attach to.

Route Tables — The Key to TGW Segmentation

TGW route tables are not VPC route tables. They are the TGW's own routing fabric. By default, TGW has one route table and all attachments propagate routes into it — meaning every VPC can reach every other VPC. In an enterprise environment, this is almost never what you want.

The segmentation pattern: create one TGW route table per security domain (prod, non-prod, shared-services, inspection). Each route table has explicit associations (which attachments use this table for inbound lookups) and propagations (which attachment routes are advertised into this table).

  • Production VPCs associate to the prod route table. Only shared-services routes propagate into it. Prod VPCs cannot reach non-prod.
  • Non-production VPCs associate to non-prod. Shared-services propagates. Non-prod VPCs share routes with each other (acceptable for dev/test).
  • A centralised network inspection VPC (running Palo Alto, Checkpoint, or AWS Network Firewall) uses a dedicated inspection route table. All East-West traffic is steered through it via a default route pointing to the firewall attachment.

Connecting On-Premises: Direct Connect + TGW

Direct Connect (DX) provides private, dedicated connectivity between on-premises and AWS. For a multi-VPC environment, attach the Direct Connect Gateway (DXGW) to the TGW using a Transit VIF. This gives on-premises access to all VPCs attached to the TGW via a single DX connection — no per-VPC Virtual Private Gateways required.

Bandwidth sizing: DX hosted connections start at 50 Mbps. Dedicated connections are 1, 10, or 100 Gbps. For redundancy, provision two DX connections from different AWS Direct Connect locations (PoPs). Configure BGP to prefer one connection with higher local preference; the second connection fails over within ~30 seconds of a BGP session drop.

AWS PrivateLink: Service Exposure Without Network Exposure

PrivateLink allows you to expose a service (running behind a Network Load Balancer) in one VPC to consumers in other VPCs or accounts — without VPC peering, TGW attachments, or exposing the service to the internet. The consumer creates an Interface VPC Endpoint; traffic flows privately via Elastic Network Interfaces (ENIs) into your service VPC.

Use cases:

  • Expose a shared authentication service in a central VPC to all product VPCs in a multi-account environment without giving those accounts direct VPC access
  • Publish internal APIs for consumption by AWS customers (AWS Marketplace PrivateLink)
  • Access AWS services (S3, SQS, ECR, Secrets Manager) from private subnets without a NAT gateway — Gateway Endpoints are free; Interface Endpoints have an hourly charge

Inter-Region Connectivity: TGW Peering vs CloudWAN

TGW peering connects TGWs in different regions. The peering is static — no dynamic routing between regions. You must manually configure routes on both TGW route tables pointing to the peering attachment. Latency depends on AWS backbone routing between regions.

AWS Cloud WAN is the next evolution: a managed global WAN service that provides dynamic routing and centralised policy management across regions. For organisations with more than 3 regions, Cloud WAN's operational simplicity typically outweighs its higher cost compared to TGW peering meshes.

Common Architecture Anti-Patterns

  • NAT Gateway per subnet: One NAT Gateway per AZ per VPC is the correct pattern. A single NAT Gateway creates an AZ dependency — if the AZ fails, all private subnets in other AZs lose internet access. Per-subnet NAT Gateways multiply cost with no benefit.
  • Security Groups as the primary network segmentation: Security Groups are stateful instance-level controls. Network ACLs are stateless subnet-level controls. Neither replaces route table segmentation — traffic must be unable to reach the segment at the network layer, not just blocked at the host layer.
  • No flow logs: VPC Flow Logs are the minimum viable observability tool. Enable them to CloudWatch Logs or S3 for every production VPC. Without them, debugging connectivity issues requires guesswork.

Sripadatech designs and operates AWS network architectures for enterprise and mid-market clients. Contact us to review your AWS networking design.