Cloud egress: VPC peering vs Transit Gateway path matrix
VPC peering and Transit Gateway (TGW) are different VPC-to-VPC path templates. Peering is a bilateral link with data-transfer meters and no TGW attachment hours; TGW adds attachment hourly fees plus data-processing GB — and both can still incur cross-AZ charges. Map bill lines before comparing to Internet DT-out. Keep rates Unknown until verified.
Updated
Peering and Transit Gateway are different VPC-to-VPC meters — map attachment hours, data processing, and cross-AZ before comparing to Internet DT-out.
Bill-line map (educational)
Bill-line map: peering vs Transit Gateway vs Internet
Bill line / CE-style label
Peering path
Transit Gateway path
Do not blend with
VPC peering data transfer
Yes — GB across the peer
Usually N/A (use TGW processing)
Internet DT-out
Transit Gateway attachment hours
No
Yes — per VPC/VPN/DX attachment
NAT hourly
Transit Gateway data processing
No
Yes — per GB processed
Internet DT-out
Cross-AZ / InterZone
Possible on either side
Possible + TGW AZ locality
Same-AZ free assumptions
Internet DT-out
Only if path leaves to public Internet
Only if path leaves to public Internet
Private VPC-to-VPC GB
NAT processing / NAT hourly
Only if Internet via NAT
Only if Internet via NAT
TGW attachment hours
Path matrix: VPC peering vs Transit Gateway (educational)
Dated starting points only — Unknown until verified means no invented $/GB. PrivateLink vs NAT egress is a sibling spoke; thick hybrid DX lives on Direct Connect / Interconnect vs Internet (no thin endpoint twins). Hybrid TGW row remains here.
This spoke is a path template for VPC-to-VPC connectivity — not a broker quote. Pair with the Cost Explorer decoder when CE labels mention peering, TGW, or InterZone.
Path templates to model
Bilateral peer, same region — peering DT GB; check AZ placement on each side.
Hub VPC with many spokes via TGW — Σ attachment hours + processing GB; watch unused attachments.
Hybrid attachment — VPN/DX SKUs separate from TGW processing.
Cross-AZ hairpin on either design — add cross-AZ as its own line.
Internet still required — keep NAT triple-charge if destinations are public.
Common traps
Assuming peering is “free.” Counting only TGW $/GB while ignoring attachment hours. Expecting transitive routing through a peer. Blending TGW processing with Internet DT-out on one CE chart. No guaranteed savings from migrating peering ↔ TGW.
FinOps checklist
Inventory peers and TGW attachments (active + idle) for 30–90 days.
Export CE/CUR lines for peering DT, TGW processing, InterZone, Internet DT-out separately.
Classify destinations: VPC-private vs true Internet.
Model with Mode A for GB lines and Mode B only when NAT remains — rates stay Unknown.
Is VPC peering always cheaper than Transit Gateway?
No. Peering has no hourly attachment fee but does not scale hub-and-spoke routing the same way. Transit Gateway adds attachment hours and per-GB processing. PipeToll never guarantees savings — measure bytes and attachments before changing architecture.
Does peering remove cross-AZ data-transfer charges?
No. Cross-AZ (cross-zone) transfer can still apply when traffic crosses availability zones, whether via peering or TGW. Separate that meter from Internet DT-out.
Will Transit Gateway replace NAT for Internet egress?
No. TGW connects VPCs (and on-prem via attachments). Arbitrary Internet destinations still need NAT, IGW, or another egress path.