The three panes
- YAML editor (left) — your topology is text. Edit it
directly and the canvas redraws; the two stay in sync. Load a
.yamlfile or pick a starting point from the examples menu. - Canvas (center) — the rendered topology. Use the
toolbar to add entities (
+ VPC,+ TGW,+ DX, …), drag from a node's handle to another node to create an attachment, click a node to edit its fields, and right-click to delete (with a preview of what cascades). - Trace panel (right) — enter a source IP and a destination IP, then run trace.
Reading a trace
A trace lists every hop on the forward path — subnet → route table → gateway → … — and ends in one of two ways:
- Reached — the destination is reachable. Each hop shows what carried the packet (a matched route, a BGP best-path winner, an attachment).
- Broke at a hop — the trace stops at the failing hop and
names the stage, the reason (e.g.
no_tgw_route,blackhole,vpn_down), and a fixable hint. The wrong answer is the lesson.
Traces run both directions: if A reaches B but B has no route back, that asymmetry is flagged — the classic gotcha where a ping leaves but the reply never returns.
What it models
Enough of the AWS data plane to reason about real hybrid topologies:
- VPC routing — subnets, route tables, longest-prefix match, the implicit local route, blackhole routes, IGW and NAT (public and private), VPC peering, and gateway/interface VPC endpoints (PrivateLink).
- Transit Gateway — attachments, route-table associations and propagations, static-vs-propagated precedence, attachment-type priority, TGW peering, and TGW Connect.
- Hybrid & Direct Connect — Virtual Gateways, Customer Gateways, Site-to-Site VPN, Direct Connect (dedicated/hosted, LAG, jumbo frames, MACsec), private/public/transit VIFs, Direct Connect Gateway (multi-VGW, DXGW↔TGW), and SiteLink.
- BGP path selection — AS_PATH prepend, MED, LOCAL_PREF via AWS community tags, prefix-list filtering, and ECMP-eligible path visibility.
What it doesn't model
TransitLab is a focused routing simulator, not a full AWS emulator. By design it does not cover:
- The control plane — no IAM, provisioning, quotas, or live AWS APIs. It models how packets route, not how resources are created or shared (cross-account RAM sharing and DXGW association proposals are abstracted away).
- IPv6 — addresses are IPv4 only; egress-only IGW is out of scope.
- Per-AZ / ECMP path spreading — each trace walks a single deterministic path. Real AWS load-balances across AZs and equal paths; the simulator shows ECMP-eligible counts but doesn't split the flow (the appliance-mode flag is honored in hop descriptions, not in per-AZ behavior).
- Reverse (AWS → on-prem) BGP advertisement — route synthesis is modeled on-prem → AWS. Prefix filters apply on that direction; the observable effect on best-path is the same, but withdrawal toward the customer side isn't simulated.
- Some BGP nuance — eBGP-over-iBGP and IGP-cost tie-breaks are abstracted (AWS hides them), and VPN MED is per-attachment rather than per-tunnel.
- PrivateLink specifics — services are abstract labels, not a live service catalog; there's no private-DNS resolution (matching is by IP/prefix) and endpoint policy is a simple allow/deny, not full IAM evaluation.
- Accelerated VPN, Client VPN, VPN concentrator, and the physical-layer details of LAG load-balancing — not modeled.
One working assumption: keep your CIDRs disjoint. The engine resolves routes by longest-prefix match and doesn't exhaustively flag every overlapping-CIDR misconfiguration across a whole topology.
Start here
Open the examples menu and load "Two VPCs via TGW" — the smallest complete topology. Run the default trace, then break it on purpose (delete a route-table propagation, blackhole a prefix) and watch where the path stops. From there, work up to the Direct Connect and BGP examples.