Educational — Cloud egress & data-transfer cost guides. FinOps-lite estimators. Not a quote, broker, or savings guarantee. Launching soon where incomplete.
nat-vpc · Educational

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 labelPeering pathTransit Gateway pathDo not blend with
VPC peering data transferYes — GB across the peerUsually N/A (use TGW processing)Internet DT-out
Transit Gateway attachment hoursNoYes — per VPC/VPN/DX attachmentNAT hourly
Transit Gateway data processingNoYes — per GB processedInternet DT-out
Cross-AZ / InterZonePossible on either sidePossible + TGW AZ localitySame-AZ free assumptions
Internet DT-outOnly if path leaves to public InternetOnly if path leaves to public InternetPrivate VPC-to-VPC GB
NAT processing / NAT hourlyOnly if Internet via NATOnly if Internet via NATTGW attachment hours
Path matrix: VPC peering vs Transit Gateway (educational)
Path templateMeters to modelBest whenFinOps note
VPC-A ↔ VPC-B via peeringPeering DT GB (+ cross-AZ if hops cross zones)Few VPCs, simple bilateral appsNo transitive routing through a peer
VPC-A → TGW → VPC-BAttachment hours + TGW data processing (+ cross-AZ)Hub-and-spoke, many VPCsAttachment sprawl multiplies hours
On-prem → TGW → VPCVPN/DX attachment + TGW processing + regional DTHybrid connectivitySeparate DX/VPN SKUs from TGW GB
Peering mesh (N×N)Many peer links × GBAvoid when N growsOperational + meter complexity
Private subnet → NAT → InternetTriple-charge stackTrue Internet destinationsNot solved by peering/TGW alone

Sources (official AWS docs)

  1. AWS Transit Gateway pricing — as-of Unknown until verified
  2. What is VPC peering? — as-of
  3. What is a transit gateway? — as-of
  4. AWS EC2 / data transfer pricing — as-of Unknown until verified
  5. VPC peering routing / limitations — as-of

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

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

  1. Inventory peers and TGW attachments (active + idle) for 30–90 days.
  2. Export CE/CUR lines for peering DT, TGW processing, InterZone, Internet DT-out separately.
  3. Classify destinations: VPC-private vs true Internet.
  4. Model with Mode A for GB lines and Mode B only when NAT remains — rates stay Unknown.
  5. Sibling-check VPC endpoints vs NAT, ELB cross-zone, and methodology.

Glossary: VPC peering, Transit Gateway, cross-AZ, path template, Unknown until verified.

FinOps-lite Unknown until verified

Worked example (educational): 2,000 GB/month VPC-to-VPC + 4 TGW attachments

  1. Scenario: two app VPCs exchange 2,000 GB/month; alternative designs are one peering link vs a TGW with 4 attachments (2 VPC + 2 unused leftovers).
  2. Peering candidate: line peering DT × 2,000 GB — rate Unknown; add cross-AZ if AZs differ — rate Unknown.
  3. TGW candidate: line attachment hours × 4 × 730 h — rate Unknown; line TGW data processing × 2,000 GB — rate Unknown.
  4. Idle attachments: keep hours on the bill even when GB ≈ 0 — model explicitly.
  5. Do not claim savings without dated cites. Educational only — open Mode A with Unknown cells.
Numbered peering vs TGW — Unknown rate cells
#Scenario lineVolumeUnit rate
1Peering data transfer2,000 GBUnknown $/GB
2Cross-AZ (if applicable)subset of GBUnknown $/GB
3TGW attachment hours4 × 730 hUnknown $/hour
4TGW data processing2,000 GBUnknown $/GB
5Idle attachment hoursincluded in #3Unknown

Open calculator Mode A Cost Explorer decoder

FAQ on this path

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.