Transit Gateway Peering Attachment
Does ZopNight manage Transit Gateway Peering Attachment?
Transit Gateway peering attachments bill per attachment-hour, plus per-GB inter-region data transfer on traffic crossing the peer. ZopNight discovers each peering on the 6-hour cycle, tracks both charges through Cost Explorer or CUR 2.0, and recommends deleting peerings that outlived a network redesign.
Rules that fire on Transit Gateway Peering Attachment
No active rule family targets Transit Gateway Peering Attachment today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, cost tracking, and recommendations only. |
A Transit Gateway peering attachment connects transit gateways across regions or accounts, billed per attachment-hour plus inter-region data transfer. Peerings left in place after network redesigns keep incurring both charges.
Attachment-hours plus the inter-region toll
A peering is itself an attachment on the transit gateway, and attachments meter hourly for as long as they exist. Traffic that crosses the peer between regions additionally pays inter-region data transfer per GB. So a peering has a fixed floor in hours and a variable component in bytes, and the failure mode is a peering whose variable component fell to zero while the fixed one kept running. Unlike VPC peering, which is free when idle, an idle TGW peering bills every hour.
Peering inventory in ZopNight
A dedicated provider picks up each peering attachment on the 6-hour discovery cycle. Attachment and data-transfer cost flow in from Cost Explorer or CUR 2.0, and the unused-peering recommendation flags attachments whose traffic has stopped, the signature of a hub-and-spoke redesign, a region consolidation, or a DR strategy that moved on. Peerings can only exist or not exist; there is no suspend, so the recommendation is always removal.
Redesigns that leave peers behind
Cross-region network topologies change more often than they get cleaned up. A migration from region-to-region peering to Cloud WAN leaves the old peers in place “until cutover is verified”, which means indefinitely. A disaster-recovery region gets decommissioned but its peering attachment survives because deleting it requires coordinating two regions’ route tables. And multi-account topologies leave orphaned accepter-side attachments when the requester account was closed.
Verifying a peering still earns its hours
In the VPC console, Transit gateway attachments filtered to the peering type list each attachment with its state and peer region. CloudWatch’s TransitGateway metrics show bytes in and out per attachment; a flat line across a month means the peer is pure fixed cost. Check both regions’ transit gateway route tables for routes pointing at the attachment before deleting it.