VPC peering facts that matter operationally

• Cross-account and cross-region peering both work — Peering works across AWS accounts (common for microservices in separate accounts) and across regions. Cross-region peering incurs data transfer charges ($0.01–0.02/GB depending on regions).
• CIDR blocks must not overlap — If VPC A uses 10.0.0.0/16 and VPC B uses 10.0.0.0/16, you cannot peer them. Ever. Plan your IP address schema at the organisation level before creating VPCs — fixing overlapping CIDRs later requires recreating VPCs.
• Route tables must be updated manually on both sides — Creating a peering connection does not automatically add routes. You must add a route in VPC A's route table pointing to VPC B's CIDR via the peering connection ID, and vice versa. This is a common source of "peering is up but I cannot connect" bugs.
• Non-transitive by design — Traffic cannot hop through a peered VPC to reach a third VPC. This is a fundamental property, not a configuration option. If you need transitive routing, you need a Transit Gateway.

Decision rules

• Use VPC Peering: connecting 2–5 VPCs with simple, static routing needs — Lower cost than TGW at small scale. Suitable for connecting a few environments (dev/staging/prod) or a production VPC to a shared services VPC. Becomes unmanageable past 5–6 VPCs.
• Use Transit Gateway: 6+ VPCs, multi-account architectures, or on-premises connectivity — The operational cost of managing peering connections and routes at scale far exceeds the TGW hourly cost. TGW also handles VPN and Direct Connect attachments in the same routing fabric.
• Use PrivateLink: exposing a service to consumers without full VPC network access — Team isolation with service access. Marketplace-style service publishing. Cross-account service consumption where you do not want the consumer VPC to have any network access to the producer VPC beyond a single endpoint.