hybrid · Educational

Cloud egress: Direct Connect / Interconnect vs Internet egress

Internet data-transfer-out via public IGW/NAT and AWS Direct Connect (hybrid private interconnect) are different meter stacks. DX adds port-hours and DX transfer SKUs; residual NAT can remain for destinations that still hairpin the public Internet. Map both with Mode A/B; keep rates Unknown until verified.

Updated 2026-09-10

One thick hybrid spoke — Direct Connect / Interconnect vs public Internet DT-out — not thin endpoint twin splits. Educational path templates only.

Bill-line map (educational)

Bill-line map: Direct Connect / Interconnect vs Internet DT-out (+ residual NAT)
Bill line / CE-style label	Direct Connect / hybrid path	Public Internet path	Do not blend with
Data Transfer–Out to Internet / AWS Outbound	Usually no for DX-only private destinations	Yes — public client / Internet hairpin	DX private transfer GB
Direct Connect Port Hours (1G / 10G / …)	Yes — dedicated / hosted port hours	No	NAT Gateway hours
Data Transfer via Direct Connect (Out / In)	Yes — DX transfer tiers by location	No	Internet DT-out list tiers
NAT Gateway Hours	Only if NAT remains for residual Internet	Yes when private subnets egress via NAT	DX port hours
NAT Gateway Bytes Processed	Only residual NAT traffic	Yes — processing GB on NAT path	DX private GB
VPC Peering / Transit Gateway processing	Possible on-ramp to DX / hybrid hub	Possible before Internet egress	Internet DT-out alone
Cross-AZ / InterZone	Possible before DX attachment	Possible before NAT/IGW	Same-AZ free assumptions
Hosted connection / partner interconnect fees	Often yes (partner / colo bill)	No	AWS Internet DT-out

Path matrix: Direct Connect / Interconnect vs Internet egress (educational)
Path template	Meters to model	Best when	FinOps note
On-prem / colo → DX → VPC	Port hours + DX transfer (+ TGW/peering if hub)	Steady hybrid volumes to private VPC CIDRs	Port hours dominate at low GB
VPC → IGW → public Internet	Internet DT-out tiers (+ free-tier cliff)	Public clients / SaaS over Internet	Do not swap DX $/GB into this cell
Private subnet → NAT → Internet	Triple-charge: hourly + processing + Internet DT-out	Private subnets with mixed public destinations	DX does not auto-retire NAT
Dual-path: DX for private + NAT/IGW for Internet	DX stack + residual Internet/NAT stack	Realistic hybrid estates	Model both; never claim “egress solved”
DX + Transit Gateway hub	DX meters + TGW attachment/processing	Multi-VPC hybrid on-ramp	See peering vs TGW
Sibling hybrid (GCP Interconnect / Azure ExpressRoute)	Provider-specific interconnect + Internet bandwidth	Multi-cloud hybrid vocabulary	Same pattern class — no thin twin spokes here

Sources (official DX / hybrid docs)

AWS Direct Connect pricing — as-of 2026-09-09 Unknown until verified
AWS Direct Connect User Guide — as-of 2026-09-09
Direct Connect connections & hosted connections — as-of 2026-09-09
AWS EC2 / data transfer pricing (Internet DT-out) — as-of 2026-09-09 Unknown until verified
Amazon VPC pricing (NAT Gateway) — as-of 2026-09-09 Unknown until verified
AWS VPC connectivity options (hybrid context) — as-of 2026-09-09

Dated starting points only — Unknown until verified means no invented $/GB. One thick hybrid spoke; GCP Interconnect / Azure ExpressRoute stay sibling vocabulary without endpoint twin pages. Educational only.

This spoke is a path template for hybrid private interconnect versus public Internet egress — not a broker quote. Pair with the Cost Explorer decoder when CE labels mention Direct Connect, Data Transfer–Out to Internet, NAT Gateway, or Transit Gateway.

Path templates to model

DX-only private destinations — port hours + DX transfer; check location tiers and hosted vs dedicated.
Public Internet DT-out — IGW path with list tiers and free-tier cliff; do not paste DX rates here.
Residual NAT — private subnets that still need arbitrary Internet keep the NAT triple-charge beside DX.
DX + TGW / peering hub — add attachment/processing as sibling meters before claiming a single hybrid $/GB.
Sibling interconnect vocabulary — GCP Cloud Interconnect / Azure ExpressRoute share the hybrid pattern class without separate thin PipeToll twins.

Common traps

DX zeros all Internet DT-out — Direct Connect / Interconnect private transfer does not erase public destinations, SaaS APIs, or residual NAT paths. Keep residual Internet as its own Mode A/B stack.
Port-hour floors ignored at low volume — Port $/hour can dominate sparse hybrid months even when private-transfer $/GB looks attractive. Model 730 h floors beside GB cells.
NAT left “just in case” — Idle NAT hours + residual processing still bill after DX cutover. Pair Mode B with the DX Mode A line; sibling NAT vs IGW.
DX blended with Internet on one CE chart — Opaque “Data Transfer” labels need the CE decoder before hybrid arithmetic. Separate DX private transfer from Internet DT-out.
$/GB-only comparisons skip colo / partner fees — Colo cross-connects, partner interconnect, and hosted connection markups sit outside the DX transfer SKU. Treat them as separate Unknown cells.
TGW / peering pasted into DX private transfer — Hub attachment + processing meters are not DX port hours. Open peering vs TGW when a transit hub sits on the on-ramp.
Scorecrowns from Incomplete — No savings guarantee from enabling Direct Connect. Badge unverified rates Unknown until verified.

FinOps checklist (understanding)

Inventory DX ports (dedicated/hosted), locations, and residual NAT/IGW paths for 30–90 days.
Export CE/CUR lines for DX port hours, DX transfer, Internet DT-out, NAT hours/processing, InterZone, and TGW separately.
Classify destinations: private VPC/on-prem via DX vs true public Internet.
Illustrate with Mode A · path=dx-interconnect and Mode B for residual NAT — rates stay Unknown.
Sibling-check CE decoder, peering vs TGW, NAT vs IGW, and methodology.

Glossary: Internet DT-out, NAT Gateway, triple-charge, path template, Unknown until verified.

FinOps-lite Unknown until verified

Worked example (educational): 8 TB/month hybrid + 1.2 TB residual Internet

Scenario: steady 8,000 GB/month on-prem ↔ VPC over Direct Connect; 1,200 GB/month still leaves via NAT to public Internet; one DX port in a single location.
DX candidate: line port hours × 730 h — rate Unknown; DX transfer × 8,000 GB — rate Unknown.
Internet residual: NAT hours × 730 h — rate Unknown; NAT processing × 1,200 GB — rate Unknown; Internet DT-out × 1,200 GB — rate Unknown.
Optional hub: if TGW sits on the DX on-ramp, add TGW processing as its own Unknown cell (see peering/TGW spoke).
Do not claim savings without dated cites. Educational only — open Mode A with path=dx-interconnect and Mode B for residual NAT.

Numbered DX vs Internet — Unknown rate cells
#	Scenario line	Volume	Unit rate
1	Direct Connect port hours	730 h	Unknown $/hour
2	DX data transfer (private)	8,000 GB	Unknown $/GB
3	NAT Gateway hours (residual)	730 h	Unknown $/hour
4	NAT processing (residual)	1,200 GB	Unknown $/GB
5	Internet DT-out (residual)	1,200 GB	Unknown $/GB
6	TGW processing (if hub)	subset of GB	Unknown $/GB

Worked-estimate sensitivity (educational)

Hold the 8 TB DX private + 1.2 TB residual Internet baseline and walk three hybrid path-class runs. Port $/hour, private-transfer $/GB, NAT hours/processing, and Internet DT-out stay Unknown until dated provider cites — literacy arithmetic, not a hybrid ROI quote.

Run A — Hybrid + residual split: 8,000 GB DX private on Mode A (?path=dx-interconnect) plus residual 1,200 GB Internet + NAT on Mode B. Never blend DX private transfer into the Internet DT-out cell; decode CE talkers via the CE decoder.
Run B — Port-hour floor twin: same month with sparse hybrid GB (e.g. 500 GB) but a full DX port still billed ~730 h. Re-run Mode A for private GB alone and keep port hours visible — low-volume months can flip “cheap $/GB” stories when floors dominate.
Run C — Residual-NAT sibling: DX carries the 8 TB east-west, but 2,400 GB still leaves via NAT (SaaS / public APIs). Double the residual Internet line vs baseline; sibling depth on NAT vs IGW and free-tier cliffs via AWS cliff. Optional TGW on-ramp stays its own Unknown cell.

Sensitivity runs — Unknown rates (educational)
Run	What changes	Meters to keep visible	Unit rates
A	8 TB DX + 1.2 TB residual Internet split	DX port · DX private · NAT · Internet DT-out	Unknown
B	Port-hour floor twin (sparse hybrid GB)	Port hours dominate · private GB small	Unknown
C	2.4 TB residual-NAT sibling	DX private · doubled residual NAT/Internet · cliffs beside A	Unknown

Cross-read cross-AZ vs cross-region, peering vs TGW, PrivateLink vs NAT, and methodology. Badge every unverified rate Unknown until verified. No savings guarantee from turning on Direct Connect.

Open calculator Mode A Mode B (residual NAT) Mode A · port-floor twin 500 GB Cost Explorer decoder NAT vs IGW

FAQ on this path

Does Direct Connect eliminate Internet data-transfer-out charges?

Not automatically. Direct Connect is a hybrid private interconnect path with its own port-hour and DX data-transfer meters. Public Internet DT-out and residual NAT can still appear when traffic leaves via IGW/NAT. Map each bill line separately — educational vocabulary only.

How does this relate to GCP Interconnect or Azure ExpressRoute?

They are sibling hybrid interconnect path classes across clouds. This spoke deepens AWS Direct Connect vs Internet DT-out without splitting thin endpoint twins. Keep rates Unknown until verified on each provider page — see methodology.

Will Direct Connect guarantee lower egress spend?

No. PipeToll never guarantees savings. Port hours, DX transfer tiers, Internet DT-out, and residual NAT are separate Unknown cells until dated cites exist.

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.