Visualize AWS Transit Gateways with Network Manager
Published on · Updated on
Rebuilt the guide around Transit Gateway registration, current Network Manager maps and telemetry, analyzer scope, Cloud WAN separation, and pricing.
AWS Network Manager’s Global Networks for Transit Gateways feature gives you a central inventory and topology view of existing Transit Gateways across Regions and, when configured, accounts. It can show AWS attachments and on-premises network objects that you model in the global network. It does not create or change Transit Gateways, prove that an application can connect, or benchmark traffic. This guide covers the Transit Gateway view; AWS documents its scope and concepts.
Before you start
You need an existing Transit Gateway. Create or change the Transit Gateway and its attachments through Amazon VPC, then register the gateway with Network Manager. A Transit Gateway can belong to only one global network. When registered, its VPC, VPN, Direct Connect gateway, Connect, and peering attachments are included in the global network. The feature is an inventory and monitoring view; it does not modify those network resources.
Network Manager uses a fixed home Region for each global network. AWS currently documents US West (Oregon), us-west-2, for commercial Regions and AWS GovCloud (US-West) for GovCloud networks; the home Region cannot be changed after the global network is established. For multiple AWS accounts, multi-account access is optional and requires AWS Organizations with Network Manager trusted access. You can register a delegated administrator to handle it from a member account. Start with the current setup prerequisites and home Region details for your account scope.
Create a global network and register Transit Gateways
- Create the container. Open Network Manager, choose Connectivity and Global Networks, then create a global network with a name and description. Do not create a Cloud WAN core network unless you are using Cloud WAN.
- Register an existing gateway. Open the global network, choose Transit gateways, then Register transit gateway. Select the account and Transit Gateway, and register it. Repeat for each gateway whose details and attachments you want included.
- Model on-premises resources when needed. Add sites, devices, and links to represent physical locations and network equipment, then associate supported customer gateways or Connect peers. These records are details you provide; Network Manager does not discover your entire physical network for you.
For a multi-Region network, a global network can include Transit Gateways from several Regions. If two registered gateways are peered, the peer gateway can appear from the registered gateway’s attachment, but its own attachments are visible only when you register that peer Transit Gateway too. Review Transit Gateway registration behavior and limits before organizing gateways into global networks.
Use an IAM role or federated console session with only the permissions required to create or view the global network and register the intended resources. For multi-account visibility, use the documented Organization and delegated-administrator setup.
Read the topology and geography views
Open the global network and choose Transit Gateway network to see its overview. The geography view places AWS Regions and registered network resources on a map; it can show VPCs and the connectivity of VPNs, Direct Connect gateways, and Connect peers, along with sites and devices that you added. The topology tree presents logical relationships. Use these views to answer “what is registered, where is it, and how is it represented?”—not “can this packet reach its destination?” AWS describes the views in its Transit Gateway dashboard guide.
Select a gateway or attachment to inspect the resource details and related objects. If a remote peer’s attachments are missing, confirm that the peer gateway itself is registered. If an on-premises office or device is absent from the map, add the corresponding site, device, link, and supported association; the map uses the location information you provide for those objects.
Know what monitoring and events show
The Transit Gateway Monitoring view uses Amazon CloudWatch metrics for gateway traffic. It includes bytes and packets in and out and bytes or packets dropped because of a black-hole route or no matching route. These measures help you spot traffic changes and certain routing drops. They do not measure application request latency, per-flow packet loss, or the time for a packet to cross the network. CloudWatch metrics for Transit Gateway are documented in the Network Manager monitoring guide.
Network Manager also provides Transit Gateway network events such as topology, routing, and status changes through EventBridge. The console’s event summary requires onboarding to CloudWatch Logs Insights; follow the documented onboarding flow and ensure the role has the required permissions. You can create CloudWatch alarms on supported metrics or EventBridge rules for selected events, but there is no generic Network Manager alert that detects every network issue. A blank chart or event pane should prompt you to check the selected gateway, account, time range, permissions, and event onboarding.
Choose a diagnostic tool for the question
| Question | Use | What the result means |
|---|---|---|
| What gateways, attachments, and modeled sites are in this network? | Network Manager geography, topology, and inventory views | A view of registered or modeled resources, not a live path test. |
| Do the Transit Gateway route tables contain a path for these addresses? | Network Manager Route Analyzer | It analyzes Transit Gateway route tables for registered gateways. It does not inspect VPC route tables, customer-gateway routes, security groups, or network ACLs; it does not support intra-Region peering, and it returns a return-path result only when the forward path succeeds. |
| Does the current supported VPC configuration allow this path? | VPC Reachability Analyzer | It models supported resource configuration and reports a path or a blocking component. It sends no packets and does not test the data plane. |
| What happened to real application traffic? | Application telemetry, an approved active test, CloudWatch metrics, and VPC Flow Logs as appropriate | These provide workload or observed-traffic evidence. Choose each signal for its documented scope. |
The Route Analyzer documentation spells out its Transit Gateway route-table scope and limitations. Use Reachability Analyzer when you need a supported, same-Region configuration analysis across VPC resources. For accepted or rejected VPC IP-flow records, enable VPC Flow Logs. For measured throughput, jitter, or latency, use a controlled test and application telemetry; see the network benchmarking guide.
Troubleshoot missing map, metric, or event data
- A Transit Gateway is missing: confirm that it exists, is registered with this global network, and belongs to the account you selected. A Transit Gateway can be registered to only one global network.
- Attachments are missing: confirm that the attachment belongs to the registered Transit Gateway. Register a peered Transit Gateway separately if its attachments must appear.
- Sites or devices are missing: create the site/device records and required links or associations. Verify their location details if they should appear on a geography map.
- Metrics look empty: select the correct gateway and time range, then check CloudWatch access and the Transit Gateway metrics in the gateway’s Region. These metrics show gateway traffic and routing drops, not request latency.
- Events are not visible: complete CloudWatch Logs Insights onboarding for the global network and verify the required IAM permissions. Use EventBridge for rules that should route matching events to another target.
For a longer checklist that separates Network Manager, CloudWatch, Flow Logs, and configuration analyzers, see AWS network dashboard troubleshooting. For the route-table associations and return paths behind a Transit Gateway flow, read how Transit Gateway route tables work.
Understand Cloud WAN and costs
A global network can organize registered Transit Gateways without a Cloud WAN core network, or include a Cloud WAN core network when you use that service. AWS Cloud WAN is a managed wide-area networking service built around a core network, with its own configuration workflow and pricing. Skip Cloud WAN core-network setup when your task is only to register and visualize Transit Gateways.
AWS states that there are no additional fees for using Global Networks for Transit Gateways. The Transit Gateways, attachments, data processing, data transfer, and other resources you use can still incur their normal charges. If you add a Cloud WAN core network, check current Cloud WAN pricing separately. AWS’s Transit Gateway pricing page describes the underlying attachment and data-processing charges.
For more on Transit Gateway route scale, bandwidth, MTU, and service quotas, continue with the Transit Gateway scalability and limits guide. To validate the VPC routes and security controls that sit beyond the Transit Gateway, use the VPC configuration guide.
Frequently asked questions
Does Network Manager create or change my Transit Gateway?
No. Create and configure Transit Gateways and their attachments through Amazon VPC or the EC2 APIs. Network Manager creates the global-network container, registers existing gateways, and provides inventory, topology, monitoring, and analysis views.
Does the map prove that traffic can reach a resource?
No. The map represents registered AWS resources and modeled network objects. Use Route Analyzer for Transit Gateway route-table analysis, Reachability Analyzer for supported VPC configuration paths, and live application or network tests for observed behavior.
Do I need a Cloud WAN core network?
No, not to register and visualize Transit Gateways with Global Networks for Transit Gateways. Create a core network only when you are using AWS Cloud WAN and have reviewed that service’s separate configuration and pricing.