How to use the TransitLab AWS networking simulator

The three panes

• YAML editor (left) — your topology is text. Edit it directly and the canvas redraws; the two stay in sync. Load a .yaml file 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, optionally add a protocol and port (to evaluate security groups and NACLs), then run trace. The source can be a public or on-prem address too, so you can trace inbound from the internet — not just VPC-to-VPC.

Reading a trace

A trace lists every hop on the forward path — subnet → route table → gateway → … — and ends in one of three 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_tgw, vpn_down), and a fixable hint. The wrong answer is the lesson.
• Routed, then dropped — with a protocol and port set, a security-group or NACL denial keeps every routing hop and layers the verdict on top: "the path exists, but the packet is dropped at X." Routing and filtering are different lessons, and the trace keeps them apart.

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.

A failure also carries an analyzer-style code — TransitLab's own normalization of the failure, written the way AWS's Reachability Analyzer explains a blocked path: NO_ROUTE_TO_DESTINATION, ENI_SG_RULES_MISMATCH (a security-group drop), SUBNET_ACL_RESTRICTION (a NACL drop). Some coincide with real Reachability Analyzer codes; don't expect a 1:1 match. When the source (or, on an ingress drop, the destination) is a declared host, the result also includes a synthesized VPC Flow Log line (ACCEPT or REJECT) — so the vocabulary the console and the exam use is right there in the trace. Non-fatal issues surface as advisories rather than stopping the trace: appliance-mode AZ asymmetry, a stateless-NACL return path that only partly opens the ephemeral range, an endpoint with no declared host (so its security groups couldn't be evaluated).

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, gateway/interface VPC endpoints (PrivateLink), and IGW edge (ingress) route tables — including internet-sourced traces that enter through an IGW, so you can reason about inbound reachability, not just egress.
• Security groups, NACLs & inspection — layer a flow (protocol + port) over the route and the path is checked against stateful security groups and stateless network ACLs, including the classic ephemeral-port return-path asymmetry, security-group references across peering, and endpoint security groups. GWLB and middlebox forced inspection is honored, and TGW appliance-mode AZ affinity is modeled: with appliance mode on, both directions pin to one inspection AZ; with it off, each direction follows its own source AZ and the trace flags when the reply would hit a different appliance than the request. Security groups attach to hosts — an ENI stand-in with an IP and security_group_ids — and hosts, security groups and NACLs are declared in YAML for now (the editor validates the references but has no form for them yet); an endpoint with no host is routed but not SG-evaluated, and the trace says so.
• 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 data-plane simulator — routing plus SG/NACL filtering — 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.
• ECMP path spreading — each trace walks a single deterministic path. Real AWS load-balances across equal-cost paths; the simulator shows ECMP-eligible counts but doesn't split the flow. (Appliance-mode AZ affinity is modeled — see above — but per-AZ multipathing is not.)
• 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.
• DNS — nothing resolves a name. The Route 53 Resolver labs trace the IP path to inbound/outbound endpoint ENIs across the hybrid link; Resolver rules, forwarding, and private hosted zones aren't simulated.
• Appliance verdicts & the default SG — forced inspection routes the packet through the appliance, but the appliance's own rules (Network Firewall, a third-party firewall) aren't evaluated. The VPC default security group isn't modeled (an SG-less interface endpoint is "not evaluated", never denied), and ICMP matches on protocol only, not type/code.
• 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 — 48 labs grouped by topic, from VPC and NAT through Transit Gateway, Direct Connect, BGP, PrivateLink, inspection, security groups & NACLs, and the IP path to Route 53 Resolver endpoints. 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, BGP, and security-group examples.