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
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
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
Assuming DX zeros Internet DT-out for all destinations. Ignoring port-hour floors at low volume. Leaving NAT running “just in case” without modeling residual hours. Blending DX transfer with Internet DT-out on one CE chart. Comparing only $/GB while skipping colo/partner interconnect fees. No guaranteed savings from enabling Direct Connect.
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.
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.
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.
