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.
Peering is “free” — bilateral peering still meters data transfer across the peer (and cross-AZ when AZs differ). “No TGW attachment hours” ≠ “$0 path.” Keep peering DT as its own line.
TGW $/GB only — attachment hourly fees (active + idle leftovers) often dominate sparse-GB months. Inventory attachments before celebrating a processing rate.
Transitive routing through a peer — VPC peering is not a hub. Traffic does not transit VPC-B to reach VPC-C. Hub-and-spoke needs TGW (or another design) — see path templates above.
Blending TGW processing with Internet DT-out — private VPC-to-VPC GB is not public leave. Map CE labels with the Cost Explorer decoder; never one blended “data transfer” cell.
TGW replaces NAT — TGW connects VPCs (and on-prem via attachments). Arbitrary Internet destinations still need NAT / IGW or another egress path. Sibling: VPC endpoints vs NAT.
Incomplete → crown — Unknown / Incomplete cells stay Unknown. PipeToll never invents peering or TGW $/GB. Stay FinOps-lite; no savings guarantee.
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.
Hold the 2,000 GB/month VPC-to-VPC baseline and walk three architecture runs. Every unit rate stays Unknown until dated TGW/EC2/peering cites — literacy arithmetic, not a quote.
Run A — single peering link: peering DT × 2,000 GB (+ cross-AZ if AZs differ). No TGW attachment hours. Open Mode A (?path=peering-tgw).
Run B — TGW with 2 active attachments: attachment hours × 2 × 730 h + TGW data processing × 2,000 GB. Drop idle leftovers from the model explicitly.
Run C — TGW with 4 attachments (2 idle): same 2,000 GB processing + hours × 4 × 730 h. Idle attachments keep hours on the bill when GB ≈ 0 — model the hours tax separately from processing.
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.
Trademarks: Amazon Web Services, AWS, Microsoft Azure, Google Cloud Platform, GCP, and Cloudflare are trademarks of their respective owners. PipeToll (Ameti One LLC) is not affiliated with, endorsed by, or sponsored by those companies. Educational comparisons may be outdated — verify current rates with each provider.
