Every SAP-C02 candidate can draw the hub-and-spoke diagram: a Transit Gateway in the middle, VPCs and a VPN around it, one route table per security zone. If that were all the exam tested, Transit Gateway would be a free question. It is not, because the professional exam asks the second-order questions. Why did the return packet get dropped by the firewall in AZ 2? Which of the two identical prefixes wins when one arrives over Direct Connect and the other over VPN? Why does the SD-WAN appliance need GRE instead of a plain VPC attachment? Why did the multicast stream stop crossing the peering connection?
Those questions are about Transit Gateway internals: how route tables are evaluated, how traffic is pinned to Availability Zones, what the specialised attachment types do, and which tools show you the drop. Our SAP-C02 networking deep dive covers the service-level picture (attachment types, segmentation patterns, RAM sharing, inter-Region peering, VPN ECMP). This article assumes you have that and goes one layer down into the mechanics the exam actually probes.
Route Tables: Association Is Not Propagation
A Transit Gateway ships with one default route table that is, by default, both the default association table and the default propagation table. Disable both defaults at creation and AWS creates no default table at all, which is what you want for any segmented design, because it forces every attachment to be placed deliberately.
Two independent relationships connect an attachment to a route table, and the exam depends on you keeping them separate:
| Relationship | Cardinality | What it means |
|---|---|---|
| Association | Each attachment is associated with exactly one route table; a route table can have zero to many attachments. | The table used to look up the destination for packets arriving from that attachment. |
| Propagation | An attachment can propagate its routes to one or many route tables. | The attachment’s CIDRs are installed as propagated routes so other attachments can reach it. |
Association answers “where do packets from this attachment get routed?”. Propagation answers “who can learn routes to this attachment?”. The classic shared-services pattern is just those two knobs: isolated spoke VPCs are associated with the isolated table and propagate to the shared table; the shared-services VPC is associated with the shared table and propagates to both. Spokes cannot see each other because nothing propagates spoke CIDRs into the isolated table.
What propagates depends on the attachment type:
- VPC attachment: the VPC’s CIDR blocks (all of them, IPv4 and IPv6). You cannot filter them.
- VPN or Direct Connect gateway attachment with BGP: the prefixes learned from your on-premises router. The reverse direction also happens: routes in the table associated with a VPN attachment are advertised back to the customer gateway over BGP. For a Direct Connect gateway, the allowed-prefixes list controls what is advertised to the on-premises side.
- Connect attachment: routes in its associated table are advertised to the SD-WAN appliance over BGP, and the appliance’s BGP routes are propagated by default.
- Peering attachment: propagates nothing. Peering supports static routes only, and because there is no dynamic routing you also cannot do ECMP across two peering attachments.
Static, blackhole and prefix-list routes
On top of propagation you add static routes. Three facts about them carry exam weight:
- Static beats propagated for the same destination. If a static route and a propagated route have identical CIDRs, the propagated route is not even installed in the table. Remove the static route and the propagated one appears.
- Blackhole routes drop matching traffic. A blackhole route for
10.2.0.0/16in a spoke’s associated table is the standard way to explicitly deny spoke-to-spoke traffic even when a broader route (for example0.0.0.0/0to an egress VPC) would otherwise carry it, because the more specific blackhole wins the longest-prefix match. - Prefix-list references let you point a managed prefix list (say, all your on-premises ranges) at an attachment as a single route object. When the list changes, the routes change with it.
Quotas that appear in “will this design scale” questions: 5 Transit Gateways per account (adjustable), 5,000 attachments per Transit Gateway, 20 route tables per Transit Gateway (adjustable), 10,000 total routes across all tables, 50 peering attachments, and only one static route per prefix per attachment.
Route Evaluation Order: The Priority List You Must Memorise
When a packet arrives, the Transit Gateway evaluates its associated route table in this order:
- Most specific route (longest prefix match) always wins.
- For routes with the same CIDR from different attachment types, priority is:
- Static routes
- Prefix-list referenced routes
- VPC-propagated routes
- Direct Connect gateway-propagated routes
- Transit Gateway Connect-propagated routes
- Site-to-Site VPN over private Direct Connect-propagated routes
- Site-to-Site VPN-propagated routes
- VPN Concentrator-propagated routes
- Client VPN-propagated routes
- Peering-propagated routes (Cloud WAN)
- For routes with the same CIDR and the same attachment type learned over BGP, standard BGP tie-breaking applies: shorter AS path, then lower MED, then eBGP over iBGP. Routes advertised without a MED get a default of 0 on Direct Connect and 100 on VPN and Connect attachments.
The exam scenario this encodes is “on-premises 172.31.0.0/16 is advertised over both Direct Connect and a backup VPN; which path is used and what does the route table show?”. The answer: Direct Connect wins because DX gateway-propagated routes outrank VPN-propagated routes, and the Transit Gateway route table only shows the preferred route. The VPN route appears only when the DX advertisement disappears. Candidates who expect to see both routes with a preference flag get this wrong.
The second trap is the inversion with VPC route tables. In a VPC route table the local route is first, then longest prefix, and a static route beats a propagated route of the same CIDR. In a Transit Gateway route table, longest prefix is first and then the attachment-type list above applies. Same words, different ordering, and the exam will quote a VPC rule in a Transit Gateway question to see if you notice.
Finally, ECMP. Transit Gateway supports ECMP within an attachment type but never across attachment types. VPN ECMP is a toggle on the Transit Gateway (dynamic routing required, and the parent post covers the throughput math). Connect attachments get ECMP automatically when the appliance advertises the same prefix with the same AS path. Direct Connect gateway attachments get ECMP when prefix, length and AS path match exactly, which is why AWS recommends a single Direct Connect gateway with multiple transit VIFs rather than several gateways. VPC attachments cannot ECMP because VPC CIDRs cannot overlap, and peering cannot because it has no dynamic routing.
Availability Zones and Appliance Mode
When you attach a VPC you pick one subnet per Availability Zone you want enabled. The Transit Gateway places an elastic network interface in that subnet and can then reach every subnet in that AZ. The subtle rule: resources in an AZ with no attachment subnet cannot reach the Transit Gateway at all, even if their subnet route table points to it. “Instances in eu-west-1c cannot reach the hub while 1a and 1b work” has a one-line fix: add a subnet in 1c to the attachment.
By default the Transit Gateway keeps a flow in its originating AZ end to end. A packet from VPC A in AZ 1 is delivered to VPC B’s attachment ENI in AZ 1, and the reply from VPC B in AZ 2 is delivered to VPC A’s ENI in AZ 2. If the destination attachment has no ENI in the source AZ, the Transit Gateway picks a random AZ where it does and does not charge extra for the cross-AZ hop.
That AZ-affinity is exactly what breaks stateful inspection. Picture an inspection VPC with a firewall in AZ 1 and another in AZ 2, and all spoke traffic routed through it:
- Request from VPC A (AZ 1) → Transit Gateway → inspection VPC AZ 1 firewall → VPC B.
- Reply from VPC B’s instance in AZ 2 → Transit Gateway → inspection VPC AZ 2 firewall.
- The AZ 2 firewall has never seen the request, has no state for the flow, and drops the reply.
Appliance mode fixes this. With ApplianceModeSupport=enable on the inspection VPC attachment, the Transit Gateway hashes the flow (5-tuple) to pick one ENI in the appliance VPC and uses the same ENI for the return traffic for the life of the flow. Both directions traverse the same AZ and therefore the same firewall. It also means the Transit Gateway may send a flow to any AZ in the appliance VPC that has a subnet association, not only the originating AZ.
aws ec2 modify-transit-gateway-vpc-attachment \
--transit-gateway-attachment-id tgw-attach-0123456789abcdef0 \
--options ApplianceModeSupport=enableThe exam’s favourite follow-up is the limits of that guarantee:
- Enable it only on the appliance (inspection) VPC attachment, not on the spokes.
- Flow stickiness is guaranteed only when both directions of the flow arrive at the inspection VPC from the same Transit Gateway. Connect exactly one Transit Gateway to the appliance VPC; multiple gateways do not share flow state.
- Traffic that enters the inspection VPC from a different gateway, for example an internet gateway for inbound traffic, and is then forwarded to the Transit Gateway after inspection, can be dropped. Inbound inspection from the internet needs the Gateway Load Balancer pattern rather than appliance mode alone.
- Enabling appliance mode on an existing attachment can change which AZ existing flows use, so it is a change-window operation.
Network function attachments: Network Firewall without an inspection VPC
A newer option removes the inspection VPC entirely. A network function attachment connects AWS Network Firewall directly to the Transit Gateway. AWS provisions a service-managed buffer VPC with one Gateway Load Balancer endpoint per AZ, creates the attachment with appliance mode already enabled, and you simply point Transit Gateway routes at the attachment. Only static routing is supported on it, only AWS Network Firewall is supported (no third-party firewalls), and in a multi-account design the Transit Gateway can be shared through RAM so either the gateway owner or the firewall owner manages the attachment.
For the exam, the distinction is: “centralised inspection with third-party appliances” still means inspection VPC + appliance mode (or Gateway Load Balancer), while “centralised inspection with AWS Network Firewall and minimal operational overhead” now has the network function attachment as the lowest-effort answer. If the answer choices predate the feature, the inspection VPC pattern is still correct, so read the options rather than assuming.
Connect Attachments: GRE and BGP for SD-WAN Appliances
A plain VPC attachment is fine for workloads, but third-party SD-WAN or virtual router appliances need to exchange routes dynamically and push more than one tunnel’s worth of traffic. Transit Gateway Connect exists for that.
A Connect attachment rides on top of an existing transport attachment, either a VPC attachment or a Direct Connect attachment. On it you create up to four Connect peers, each a GRE tunnel between the appliance and the Transit Gateway with two BGP sessions inside it for control-plane redundancy. The Transit Gateway recognises matching GRE packets as Connect traffic; everything else on the same wire is ordinary transport-attachment traffic.
| Parameter | Value |
|---|---|
| Tunnel protocol | GRE (no IPsec; the transport is already private) |
| Routing | BGP only, no static routes on a Connect attachment |
| BGP flavours | eBGP (requires ebgp-multihop with TTL 2), iBGP (same ASN as the Transit Gateway, routes must originate from an eBGP peer with next-hop-self), MP-BGP for IPv6 prefixes over IPv4 peering |
| Inside (BGP) addresses | a /29 from 169.254.0.0/16 (some blocks reserved), optionally a /125 from fd00::/8; first address goes on the appliance |
| Transit Gateway outer address | taken from a Transit Gateway CIDR block you add to the gateway (up to 5 per gateway); shared with Private-IP VPN and Client VPN |
| Bandwidth | 5 Gbps per Connect peer, so up to 20 Gbps per Connect attachment with 4 peers and ECMP, provided the transport attachment can carry it |
| ECMP | Automatic across peers with identical prefix and AS path; not between the two BGP sessions of one peer |
| Not supported | BFD, BGP graceful restart, IPv6-only BGP peering |
| MTU | 8,500 bytes like other non-VPN attachments; set the GRE tunnel MTU 24 bytes below the interface MTU |
The scenario cue is “SD-WAN appliance in a VPC needs dynamic routing to the Transit Gateway at more than VPN throughput”. A Site-to-Site VPN attachment to the appliance would cap at 1.25 Gbps per tunnel with IPsec overhead the design does not need; a VPC attachment alone cannot exchange routes with the appliance. Connect gives BGP plus 5 Gbps per tunnel over the private transport. Note that the routes the appliance learns come from the route table associated with the Connect attachment, which is how you control what on-premises sites can reach.
Peering, Transit Gateway CIDR Blocks and VPN Concentrators
Three smaller mechanisms round out the attachment story:
- Peering (intra-Region or inter-Region) is static-only, non-transitive, encrypted on the AWS backbone, limited to one peering attachment between any two gateways, and up to 100 Gbps per AZ. Because routes do not propagate, each side needs explicit static routes to the other’s CIDRs, and summarising them into a prefix list is the maintainable approach.
- Transit Gateway CIDR blocks are an address pool you attach to the gateway (up to 5). They supply outer addresses for Connect peers, outside IPs for private-IP VPN (Site-to-Site VPN over Direct Connect without public IPs), and Client VPN endpoints. If a design mentions “VPN over Direct Connect with private IPs” or “Connect peer addressing”, a Transit Gateway CIDR block is required.
- VPN Concentrators are a newer attachment type that aggregates many Site-to-Site VPN connections (up to 100 per concentrator, 5 concentrators per gateway). They do not support ECMP, and their propagated routes sit below regular VPN routes in the priority list.
Multicast: A Transit Gateway as a Multicast Router
Multicast is the attachment feature most candidates have never used, which makes it a cheap differentiator on the exam. A Transit Gateway created with multicast enabled (it must be enabled at creation; you cannot flip it on later) acts as a multicast router between subnets of attached VPCs.
| Concept | Definition |
|---|---|
| Multicast domain | A segmentation unit. You associate subnets with a domain; a subnet can belong to only one domain. 20 domains per gateway. |
| Multicast group | Identified by a group IP address. Membership is at the elastic network interface level. Up to 100 members per group. |
| Source | An ENI statically registered to send. Only meaningful in static domains. |
| Member | An ENI registered to receive. In static domains members receive only; in IGMP domains members can send and receive. |
Membership can be static (API or console) or dynamic via IGMPv2. In an IGMP domain the Transit Gateway queries every member every two minutes; a member that misses three consecutive queries is removed from its groups; an explicit LEAVE removes it immediately. Security groups and NACLs must allow protocol 2 (IGMP) from 0.0.0.0/32 inbound and to 224.0.0.2/32 and the group address outbound, plus the UDP data itself.
The constraints that show up as distractors:
- Not supported over Direct Connect, Site-to-Site VPN, peering, or Connect attachments. Multicast is VPC-to-VPC inside one Transit Gateway. “Extend multicast to on-premises over DX” is a wrong answer.
- Fragmented multicast packets are dropped; keep below the MTU.
- Only static multicast supports IPv6. IGMP is IPv4.
- Non-Nitro instances cannot be sources and need source/destination checks disabled to receive.
- Throughput caps: 1 Gbps per flow, 20 Gbps aggregate per AZ. AWS explicitly says this is not for high-frequency trading-style workloads.
- Multicast traffic is not captured by Transit Gateway Flow Logs.
MTU and Bandwidth: The Numbers Behind “Why Is It Slow?”
| Path | Default | Note |
|---|---|---|
| VPC attachment | up to 100 Gbps per AZ each direction, 7.5 M pps | Historically quoted as 50 Gbps; current docs say 100, and AWS tries to burst beyond it |
| Direct Connect gateway or peering attachment | up to 100 Gbps per AZ each direction | |
| Connect peer | 5 Gbps, 300 K pps | 4 peers per attachment |
| VPN tunnel | 1.25 Gbps | aggregate with ECMP on dynamic-routing VPNs only |
| MTU (VPC, DX, Connect, peering) | 8,500 bytes | jumbo frames |
| MTU (VPN) | 1,500 bytes |
Two MTU behaviours are testable. First, when you migrate from VPC peering (which supports 9,001-byte jumbo frames) to a Transit Gateway (8,500), packets between 8,501 and 9,001 bytes are dropped until both VPCs are updated, so switch both sides at once. Second, Path MTU Discovery works on VPC and Connect attachments (the gateway sends ICMP FRAG_NEEDED / Packet Too Big), but not on VPN, Direct Connect or peering attachments, and the Transit Gateway clamps TCP MSS on every packet.
Transit Gateway Flow Logs: Seeing the Drop
VPC Flow Logs show you what left an ENI; they cannot tell you why the Transit Gateway dropped it. Transit Gateway Flow Logs capture traffic at the gateway or per attachment and publish to CloudWatch Logs, S3 or Firehose. Only the gateway owner can create them, which matters in a RAM-shared design where spoke accounts cannot enable logging on the hub.
The fields that make them a debugging tool rather than a billing record:
| Field | What it tells you |
|---|---|
tgw-attachment-id, tgw-pair-attachment-id | Ingress and egress attachments for the flow |
tgw-src-az-id, tgw-dst-az-id | Which AZs the flow used, the fast way to confirm whether appliance mode is doing its job |
flow-direction | ingress or egress relative to the gateway |
packets-lost-no-route | Dropped because the associated route table had no match |
packets-lost-blackhole | Dropped by a blackhole route |
packets-lost-mtu-exceeded | Dropped for exceeding 8,500 (or 1,500 on VPN) |
packets-lost-ttl-expired | Routing loop between tables or gateways |
Limitations: multicast is not logged, and Connect attachment traffic appears under the transport attachment, so enable logging on the gateway or the transport attachment rather than on the Connect attachment. For topology-level questions (“which route table will a packet from attachment X to 10.4.0.0/16 use?”), Route Analyzer in AWS Network Manager evaluates the Transit Gateway route tables for a source and destination without sending traffic. Pairing the two is the professional-level debugging sequence: Route Analyzer to confirm intent, Flow Logs to confirm behaviour.
Decision Table for the Exam
| Scenario phrase | Mechanism |
|---|---|
| ”Same prefix learned over DX and VPN, which is active?” | DX gateway-propagated outranks VPN-propagated; table shows only the preferred route |
| ”Prevent two spokes from talking despite a default route to egress” | More specific blackhole route in the spoke’s associated table |
| ”Stateful firewall drops return traffic in another AZ” | Enable appliance mode on the inspection VPC attachment only |
| ”Centralised AWS Network Firewall with least operational overhead” | Network function attachment (static routes, appliance mode pre-enabled) |
| “SD-WAN appliance needs BGP and >1.25 Gbps” | Connect attachment, GRE + BGP, 5 Gbps per peer, 4 peers |
| ”Multicast between VPCs” | Multicast-enabled Transit Gateway, IGMPv2 or static domains; not over DX/VPN/peering/Connect |
| ”Instances in one AZ cannot reach the gateway” | Add an attachment subnet in that AZ |
| ”Jumbo frames break after moving from VPC peering” | 8,500 vs 9,001 MTU; update both VPCs together |
| ”Why was the packet dropped at the hub?” | Transit Gateway Flow Logs packets-lost-* fields; Route Analyzer for the intended path |
| ”Route to the peer gateway is not appearing” | Peering is static-only; add static routes (ideally via a prefix list) |
Turning Mechanics into Exam Points
Transit Gateway questions on the SAP-C02 are rarely about whether to use a Transit Gateway. They are about whether you can predict what the gateway will do with a specific packet under a specific route table, AZ layout and attachment mix. That is a skill you build by working scenarios, not by rereading the quotas page.
Sailor.sh’s AWS Certified Solutions Architect - Professional (SAP-C02) mock exam bundle includes eight full-length mock exams whose networking scenarios go exactly this deep: inspection VPCs that silently drop return traffic, route tables with competing propagated prefixes, and hybrid designs where the right answer depends on knowing that peering cannot propagate. Every explanation walks through why each distractor fails, which is where the attachment-priority list and the appliance-mode guarantee stop being trivia and become instinct. Pair it with the SAP-C02 networking deep dive for the service-level patterns and the multi-account architecture guide for how the hub is shared across the Organization.
Frequently Asked Questions
What is the difference between route table association and propagation in Transit Gateway?
Association determines which route table is consulted for packets arriving from an attachment; each attachment is associated with exactly one table. Propagation installs an attachment’s routes into one or more tables so other attachments can reach it. Segmentation designs come from associating isolated attachments with one table while propagating them selectively into others.
In what order does a Transit Gateway evaluate routes?
Longest prefix match first. For identical CIDRs from different attachment types: static, prefix-list, VPC-propagated, Direct Connect gateway-propagated, Connect-propagated, VPN over private DX, Site-to-Site VPN, VPN Concentrator, Client VPN, then Cloud WAN peering-propagated. For identical CIDRs from the same attachment type over BGP: shorter AS path, lower MED, eBGP over iBGP. Only the preferred route is displayed in the table.
What does Transit Gateway appliance mode do?
It makes the gateway choose one network interface in the appliance VPC by flow hash and use that same interface for both directions of the flow for its lifetime, so a stateful firewall in one AZ sees both request and reply. Without it, the gateway keeps each direction in its originating AZ, which can deliver the reply to a different firewall that drops it. Enable it only on the inspection VPC attachment and attach only one Transit Gateway to that VPC.
When should I use a Transit Gateway Connect attachment?
When a third-party virtual appliance such as an SD-WAN router inside a VPC (or reachable over Direct Connect) needs dynamic BGP routing with the Transit Gateway and more throughput than IPsec VPN provides. Connect uses GRE tunnels with BGP, supports up to four peers at 5 Gbps each (20 Gbps per attachment with ECMP), and does not support static routes, BFD or BGP graceful restart.
Does Transit Gateway multicast work over Direct Connect, VPN or peering?
No. Multicast routing is supported only between subnets of VPCs attached to the same Transit Gateway. It is not supported over Direct Connect, Site-to-Site VPN, peering attachments or Connect attachments, and it must be enabled when the gateway is created.
What MTU does a Transit Gateway support?
8,500 bytes for traffic between VPC, Direct Connect, Connect and peering attachments, and 1,500 bytes over VPN. Path MTU Discovery is supported on VPC and Connect attachments only, and MSS clamping is applied to all packets. VPC peering supports 9,001 bytes, so migrating to a Transit Gateway requires updating both VPCs at the same time.
Can Transit Gateway peering propagate routes or use ECMP?
No. Peering attachments support only static routes, so nothing propagates and ECMP across peering attachments is impossible. You add static routes on each side pointing to the peering attachment, and only one peering attachment can exist between any two Transit Gateways.
What is a Transit Gateway network function attachment?
An attachment that connects AWS Network Firewall directly to the Transit Gateway through a service-managed buffer VPC with Gateway Load Balancer endpoints in each AZ, created with appliance mode already enabled. It removes the need to build and manage an inspection VPC, supports static routing only, and currently supports only AWS Network Firewall rather than third-party appliances.
Conclusion
The SAP-C02 rewards candidates who treat Transit Gateway as a router with rules rather than a box on a diagram. Keep association and propagation separate in your head, memorise the attachment-type priority list and the fact that only the preferred route is shown, know that appliance mode exists because the gateway otherwise pins flows to their originating AZ, and recognise the specialised attachments by their cues: Connect for SD-WAN with GRE and BGP, multicast domains for VPC-only multicast, network function attachments for Network Firewall without an inspection VPC, and peering as the static-only exception to everything. When a scenario asks why traffic disappeared, reach for Flow Logs’ packets-lost-* fields and Route Analyzer.
Those mechanics convert directly into exam points because the distractors are built from the misconceptions this article dismantled. Drill them under time pressure, then revisit the networking deep dive and notice how many of its patterns depend on the internals you now understand.