VPC Routing — Longest Prefix Match, Propagation, and Blackhole Routes

VPC routing on ANS-C01 is the single most-tested mechanic in the entire exam. Where a Solutions Architect exam might ask "which subnet should the database go in?", the Advanced Networking Specialty exam asks "given a route table with a propagated 10.0.0.0/16 from a VGW, a static 10.0.0.0/24 to a peering connection, an explicit blackhole 10.0.0.5/32, and a default 0.0.0.0/0 to a NAT gateway — where does a packet for 10.0.0.5 go, where does a packet for 10.0.0.99 go, and where does a packet for 8.8.8.8 go?" That is longest prefix match arbitrating between static and propagated routes, and it is the primitive every other Domain 2 question is built on top of.

This topic covers the entire routing primitive surface: the local route, static and propagated routes, longest prefix match, route propagation from Virtual Private Gateways and Transit Gateways, ingress routing for middle-box patterns like Gateway Load Balancer sandwich topologies, blackhole routes for explicit traffic isolation in Transit Gateway route tables, and the subtle traps where VPC peering's non-transitive nature, asymmetric security group configuration, or MTU black holes break what looks like a perfectly correct route table. It is mapped to Task Statement 2.1 (Implement routing and connectivity between on-premises networks and the AWS Cloud) and Task Statement 2.2 (Implement routing and connectivity across multiple AWS accounts, Regions, and VPCs), both heavily tested with scenario-style questions.

Why VPC Routing Is the Foundation of ANS-C01 Domain 2

Domain 2 (Network Implementation) accounts for 26 percent of the ANS-C01 exam, second only to Domain 1 (Network Design, 30 percent). Within Domain 2, VPC routing is the connective tissue that holds every other implementation detail together. You cannot answer a Transit Gateway question without first reasoning about route tables. You cannot answer a Direct Connect failover question without understanding how propagated BGP routes interact with static routes. You cannot answer a PrivateLink scenario without recognising whether the endpoint route is in the right route table. So mastering VPC routing is the single highest-leverage study activity in Domain 2.

The framing across this topic is deterministic packet forwarding. Every packet leaving an ENI consults exactly one route table — the one associated with that ENI's subnet — and applies a single rule: longest prefix match wins, with static routes preferred over propagated routes at the same prefix length. There is no "policy routing" by source IP, no per-application route distinguisher, no VRF in the cloud sense. The simplicity is a feature: it makes routing decisions explainable. The downside is that any route-table misconfiguration produces silent failure rather than a helpful error, and the fix requires the operator to mentally simulate the longest-prefix algorithm.

The ANS-C01 exam tests VPC routing in three distinct flavours. Single-VPC routing asks about subnet route tables, ingress routing, NAT gateway placement. Multi-VPC routing asks about VPC peering route requirements, Transit Gateway attachment route tables, and inter-region routing. Hybrid routing asks how on-premises BGP-advertised prefixes get propagated to VPC route tables and how AWS arbitrates between propagated VGW routes, propagated TGW routes, and Site-to-Site VPN tunnels. This guide walks all three flavours with the precision the Specialty exam demands.

Plain-Language Explanation: VPC Routing — Longest Prefix Match and Propagation

VPC routing combines a few simple primitives (route tables, longest prefix match, propagation, blackhole) into surprisingly complex scenarios when stacked across hub-and-spoke topologies, hybrid connectivity, and middle-box inspection. Three analogies anchor the moving parts.

Analogy 1: The Postal Sorting Office With Specific-First Delivery

Think of every subnet as a postal sorting office and every route table as the delivery driver's route book for that office. The local route is the rule "anything for this neighbourhood, drop in the mailbox down the street" — always present, always wins for in-VPC delivery, never removable. Longest prefix match is the postal worker's rule: if a letter is addressed to "10 Downing Street, London", and the route book has both "all of London → main truck" and "10 Downing Street → diplomatic courier", the diplomatic courier wins because it's the most specific match. Static routes are entries the postmaster wrote in by hand — high authority, never changes unless someone explicitly rewrites them. Propagated routes are entries the route book auto-receives every morning from the regional dispatch (BGP from a Virtual Private Gateway or Transit Gateway) — useful but lower priority than handwritten entries at the same specificity. Blackhole routes are explicit "do not deliver to this address — return to sender silently" rules; they are how you isolate certain destinations from the rest of the network. VPC peering is a private courier line between two postal offices — but the courier driver only delivers to addresses written explicitly in their route book; they do not transit mail to a third office.

Analogy 2: The Library Card Catalogue With Specificity Rules

A VPC route table is a library card catalogue for finding books. The local route is the catalogue card "any book in this library → check the stacks", always present. Longest prefix match is "the most specific catalogue entry wins" — if the catalogue has both "Reference: Dewey 500–599" and "Reference: Dewey 530.12 → Special Collections", a request for Dewey 530.12 goes to Special Collections, not the general 500s shelf. Static routes are the librarian's handwritten override cards that always beat the printed cards at the same specificity. Propagated routes are the auto-printed cards from the union catalogue (BGP) — lower priority than handwritten cards at the same specificity. Blackhole routes are "this book has been declared lost — do not search the stacks" cards. Ingress routing is a special rule the head librarian sets at the front door: "any incoming request must first stop at the security desk before reaching the catalogue" — this is how you force traffic through inspection appliances.

Analogy 3: The Highway Network With Exit Signs

A VPC subnet is a driver entering a highway. The route table is the exit sign hierarchy at every junction. The local route is the on-ramp sign for "this VPC's CIDR — keep straight". Longest prefix match is the rule "the more specific exit wins": if there is an exit sign for "Region 10.0.0.0/16" and another for "Town 10.0.5.0/24", a driver going to 10.0.5.42 takes the Town exit. Propagated routes are highway signs put up by the regional transport authority based on traffic feedback (BGP); static routes are signs the local council bolted on top, and the local sign wins at the same specificity. Blackhole routes are "Bridge Out — Do Not Enter" signs that drop traffic intentionally. Ingress routing is a tollbooth at the entrance ramp that forces every vehicle through inspection before it joins the main road. VPC peering routes are private bridge lanes between two highways — but only specific addresses written on the bridge are allowed across; you cannot drive over the bridge to a third highway beyond it.

VPC Route Table Fundamentals — The Local Route, Static, and Propagated

Every VPC has a main route table at creation, and you can attach custom route tables to specific subnets. A subnet is associated with exactly one route table at any time; if not explicitly associated, it inherits the main route table. Each route table contains routes, and every route has three components: a destination CIDR, a target (local, IGW, NAT GW, VGW, TGW, peering connection, ENI, GWLB endpoint, etc.), and a propagation flag (static or propagated).

The local route — always first, never editable

The local route matches the VPC's primary CIDR (and any secondary CIDRs added later) and has target local. It is automatically created, cannot be deleted, and cannot be overridden — even a more specific static route in the same table loses to the local route for in-VPC traffic when the local route's CIDR covers the destination. This is the ANS-C01 rule that catches candidates: you cannot redirect intra-VPC traffic to a middle-box appliance via the standard route table because the local route always wins for the VPC CIDR.

Static routes — manually authored, highest priority at same prefix

A static route is a route you (or IaC) explicitly add. Static routes are evaluated against propagated routes by longest prefix match first, static-vs-propagated tiebreak second: at the same prefix length, a static route beats a propagated route. Static routes can target any valid destination — Internet Gateway, NAT Gateway, Virtual Private Gateway, Transit Gateway, VPC peering connection, network interface, Gateway Load Balancer endpoint, or carrier gateway (Wavelength).

Propagated routes — auto-populated from VGW/TGW

A propagated route is automatically added to the route table when route propagation is enabled for a Virtual Private Gateway or Transit Gateway attached to the VPC. Propagated routes come from BGP advertisements over a Site-to-Site VPN, Direct Connect VIF, or TGW attachment. Propagation reduces operational overhead — when on-premises advertises a new prefix, the VPC route table updates automatically without manual intervention.

Longest Prefix Match — How AWS Decides Which Route Wins

Every packet leaving an ENI triggers a route table lookup. AWS applies longest prefix match (LPM): among all matching routes, the one with the longest (most specific) prefix wins. A /32 beats a /24, a /24 beats a /16, a /16 beats a /0. Ties at the same prefix length are broken by static-over-propagated, then by route table priority order.

Worked example — three overlapping routes

Consider a route table with these entries:

A packet for 10.5.0.42 → /32 wins → ENI eni-9abc. A packet for 10.5.0.99 → /24 wins → TGW tgw-5678. A packet for 10.5.99.99 → /16 wins → VGW vgw-1234. A packet for 8.8.8.8 → /0 wins → NAT GW nat-def0.

LPM with the local route

The local route covers the VPC's primary and secondary CIDRs. No more-specific route in the table can override the local route within the VPC's own CIDR space — this is a special-cased rule (not the standard LPM tiebreak). To redirect intra-VPC traffic through a middle-box, you cannot use a /32 static route in the standard route table; you need either an ingress route table on the IGW or VGW (route table options feature) or you need to architect with separate VPCs and use TGW with appliance mode.

LPM and BGP

When BGP advertises multiple prefixes, AWS imports each as a separate propagated route. If on-premises advertises 10.5.0.0/16 and 10.5.0.0/24, both end up in the propagated route list, and LPM picks /24 for any 10.5.0.x packet. This is the basis for route summarisation — advertising a less-specific summary covers a wide range while still allowing more-specific exceptions to override.

Route Propagation — VGW and TGW BGP Auto-Population

Route propagation is the per-route-table flag that imports BGP-advertised prefixes from a Virtual Private Gateway or Transit Gateway into the route table automatically. Without propagation, you must add static routes for every on-premises prefix manually — operationally untenable for large hybrid networks.

VGW propagation

A VPC route table with a propagation flag set to "yes" for an attached VGW receives all BGP-advertised prefixes from the on-premises customer gateway via the Site-to-Site VPN. When on-premises adds a new branch office advertising a new /24, the route appears in the VPC route table within seconds. Removing the BGP advertisement removes the route automatically.

TGW propagation

For Transit Gateway, propagation is configured at the TGW route table level, not the VPC route table level. A TGW attachment can be associated with one TGW route table (this determines where the attachment looks up routes) and can propagate routes to one or more TGW route tables (this determines where its routes show up). The VPC route table simply has a static 0.0.0.0/0 → tgw-xxx entry to direct traffic to the TGW; the TGW route table handles the rest.

Propagation does not cover VPC peering

A frequent ANS-C01 trap: VPC peering connections do not participate in propagation. You must add static routes to both VPCs' route tables manually. There is no BGP between peered VPCs, no route exchange, no automatic adjustment when one VPC's CIDR changes.

Static override of propagated routes

You can disable propagation for a specific prefix by adding a static route at the same prefix length pointing somewhere else (or to a blackhole). This is the operator escape hatch when on-premises advertises a route you do not want to honour — for example, blocking a misconfigured BGP advertisement of 0.0.0.0/0 by adding a static 0.0.0.0/0 → NAT GW that wins the tiebreak.

Ingress Routing for Middle-Box and Gateway Load Balancer Patterns

Ingress routing is the VPC feature that lets you associate a route table with an Internet Gateway (IGW) or Virtual Private Gateway (VGW) rather than a subnet. The associated route table controls how inbound traffic is steered before reaching its destination subnet. This is the mechanism that enables middle-box inspection for north-south traffic.

The Gateway Load Balancer sandwich

The canonical ANS-C01 ingress routing pattern is the Gateway Load Balancer sandwich. Inbound traffic from the internet to an ALB hits the IGW. Without ingress routing, the IGW forwards directly to the ALB subnet. With ingress routing, the IGW route table redirects the inbound traffic first to a Gateway Load Balancer endpoint (GWLBe) in an inspection subnet, where a third-party firewall fleet inspects, then back through routes to the ALB subnet. The return traffic from the ALB to the internet is routed back through the GWLBe (via the ALB subnet's route table) so the firewall sees both directions symmetrically.

Configuring ingress routing

Create a route table, associate it with the IGW (instead of a subnet), and add routes whose destinations are the CIDR ranges of subnets behind the inspection layer, with target vpce-xxxx (the GWLB endpoint). Inbound traffic destined to those CIDRs is redirected through the GWLB endpoint.

Why not just use NACLs or security groups?

NACLs and security groups filter traffic but cannot redirect it. Ingress routing is required when traffic must traverse a stateful inspection appliance that performs deep packet inspection, decrypts TLS, or applies behavioral analytics — controls that cannot be expressed as simple allow/deny tuples.

Blackhole Routes — Explicit Traffic Isolation

A blackhole route is a route whose target is intentionally invalid, causing AWS to drop matching traffic silently. There are two contexts where blackhole routes are used.

TGW blackhole routes

In a Transit Gateway route table, you can create an explicit static route with target blackhole. This is the canonical pattern for enforcing segmentation between TGW segments — for example, a non-prod TGW route table that propagates non-prod VPC routes but has a static blackhole for the prod VPC CIDR ensures that even a misconfigured route propagation cannot allow non-prod-to-prod traffic.

VPC route table blackholes (implicit)

In a VPC route table, a route whose target was a peering connection or VGW that has since been deleted is shown as blackhole until you remove or update it. This is not an intentional control — it is a stale-state warning that traffic for that prefix is silently dropped. The exam will sometimes describe a connectivity outage where the route table shows a blackhole entry; the fix is to update the route to a current target.

Why blackhole instead of just removing the route?

If you remove the route entirely, longest prefix match falls back to a less-specific route (often the default 0.0.0.0/0). A blackhole at the specific prefix prevents fallback — packets are explicitly dropped rather than rerouted to an unintended destination. This is particularly important in TGW route tables where you want to enforce isolation explicitly rather than relying on the absence of a route.

NAT Gateway Routing Patterns

The NAT Gateway provides outbound internet access for instances in private subnets without exposing them to inbound traffic. The routing pattern is canonical and tested in every Specialty exam.

Basic NAT GW pattern

Public subnet has a route table with 0.0.0.0/0 → IGW. Private subnet has a route table with 0.0.0.0/0 → NAT GW. The NAT Gateway itself sits in the public subnet (so it has an IGW route for its own traffic). An instance in the private subnet sending traffic to 8.8.8.8 follows 0.0.0.0/0 → NAT GW, the NAT GW translates the source to its public Elastic IP, and forwards via 0.0.0.0/0 → IGW from the public subnet's route table.

Per-AZ NAT GW for HA and cost

Each NAT Gateway is AZ-scoped. If the AZ fails, the NAT GW fails. Best practice: deploy one NAT GW per AZ in a separate public subnet, and configure each private subnet's route table to point to its own AZ's NAT GW (not a different AZ's). This avoids cross-AZ data transfer charges and provides HA. The exam favors this pattern explicitly — a "single NAT GW for the whole VPC" answer is wrong.

NAT GW vs NAT instance

NAT instances (EC2 instances acting as NAT) are deprecated in modern designs. They appear on the exam only as distractors — "use a NAT instance for cost optimization" is wrong because NAT GW is cheaper at scale and managed.

Subnet Architecture Patterns — Public, Private, and Isolated

Subnet architecture is the practical application of route table design. ANS-C01 expects you to recognise four subnet patterns and the route table that defines each.

Public subnet

Route table: local + 0.0.0.0/0 → IGW. Instances with public IPs are reachable from the internet (subject to SGs/NACLs). Used for ALBs, NAT GWs, bastion hosts, and any resource that must be directly reachable from the internet.

Private subnet (with egress)

Route table: local + 0.0.0.0/0 → NAT GW. Instances have no public IP, cannot be reached from the internet, but can initiate outbound connections via NAT. Used for application servers, batch workers.

Isolated subnet (no internet at all)

Route table: local only, plus optional routes to TGW/VGW for hybrid traffic. No 0.0.0.0/0. Used for databases, regulated workloads that must never reach the internet directly. AWS service access via interface VPC endpoints only.

Inspection subnet

Route table: local + 0.0.0.0/0 → IGW (for the inspection appliances themselves to reach updates) plus specific routes to spoke VPC CIDRs via TGW or peering. Hosts only the inspection appliances (Network Firewall, Palo Alto VM-Series, GWLB endpoints).

IPv6 considerations

For IPv6, the equivalent of 0.0.0.0/0 is ::/0 → IGW for public subnets, and ::/0 → egress-only IGW for private subnets (egress-only IGW is IPv6-specific, blocks inbound while permitting outbound). Dual-stack subnets need both IPv4 and IPv6 routes.

Hub-and-Spoke Multi-VPC Routing With TGW

The hub-and-spoke topology with Transit Gateway as the hub is the ANS-C01 canonical multi-VPC architecture. Each spoke VPC has a TGW attachment; the TGW's route tables define which spokes can reach which.

Spoke VPC route table

A spoke VPC's subnets have a route table with local + <other-spoke-CIDR or 0.0.0.0/0> → TGW. The simplest pattern uses a default route to TGW: every non-local destination flows to TGW, and TGW decides where it goes from there.

TGW route tables

The TGW typically has multiple route tables: one per security domain (prod, non-prod, shared services). Each spoke is associated with exactly one TGW route table (this determines its lookup table) and propagates its CIDR to one or more TGW route tables (this determines visibility from other spokes).

Spoke-to-spoke isolation

The standard pattern is prod spokes associated to prod TGW RT, propagating to prod and shared-services RTs; non-prod associated to non-prod RT, propagating to non-prod and shared-services. This produces full prod-to-prod connectivity, full non-prod-to-non-prod connectivity, no prod-to-non-prod connectivity, and shared-services reachable from both. Blackhole routes in each segment table for the opposite segment's CIDR enforce isolation explicitly.

Centralised egress

A common pattern: all spokes route 0.0.0.0/0 to TGW, and TGW route tables forward 0.0.0.0/0 to a shared egress VPC that has a NAT GW and IGW. This consolidates internet-egress charges and IP addresses to one VPC, simplifying egress filtering.

Common Routing Failures — Diagnostic Patterns

Three failure modes account for nearly every "connection is broken" question on ANS-C01.

Missing route — the most common

Symptom: traffic destined to a peer VPC, on-premises, or a TGW spoke gets dropped silently. Diagnosis: check the route table associated with the source subnet for the destination CIDR. If absent, add it. Specifically check VPC peering connections — VPC peering routes are not propagated and are easy to forget on one side.

Asymmetric routing — the silent killer

Symptom: TCP connections succeed initially but drop, or stateful firewalls drop "the second packet". Diagnosis: the request goes through path A, the response goes through path B, and a stateful firewall on B sees a TCP packet without a SYN-ACK match and drops it. Fix: TGW appliance mode for inspection VPCs, GWLB cross-zone or zonal alignment for inspection appliances, symmetric route table design for hybrid scenarios.

MTU black hole — the rare-but-deadly

Symptom: small ping packets succeed, large file transfers fail or hang. Diagnosis: a router along the path drops packets larger than its MTU but does not send the ICMP "fragmentation needed" message back to the sender (Path MTU Discovery fails). The sender keeps trying full-size packets. Fix: ICMP type 3 code 4 must be allowed end-to-end; or set TCP MSS clamping; or reduce sender MTU. AWS VPC supports 9001 byte jumbo frames within VPC, but Direct Connect, IGW, VPN, and inter-VPC traffic typically default to 1500.

Common Traps Recap — VPC Routing on ANS-C01

Trap 1: VPC peering propagates routes

Wrong. VPC peering routes are 100 percent manual. No BGP, no propagation, no transitive routing.

Trap 2: Static and propagated routes have the same priority

Wrong. At the same prefix length, static beats propagated. At different prefix lengths, longest prefix match wins regardless of origin.

Trap 3: The local route can be overridden

Wrong. The local route covers the VPC CIDR and cannot be overridden by any more-specific route in the same subnet's route table.

Trap 4: A single NAT GW for the whole VPC is best practice

Wrong. One NAT GW per AZ, with each private subnet routing to its own AZ's NAT GW, is the AWS-recommended HA pattern.

Trap 5: Removing a route is the same as adding a blackhole

Wrong. Removing falls back to less-specific routes (often 0.0.0.0/0). A blackhole at the specific prefix prevents fallback.

Trap 6: Ingress routing is for outbound traffic

Wrong. Ingress routing redirects inbound traffic at the IGW or VGW before it reaches the subnet. Egress routing is the standard subnet route table.

Trap 7: TGW propagation reaches into VPC route tables automatically

Partially wrong. TGW propagation populates TGW route tables, not VPC route tables. The VPC route table needs a static 0.0.0.0/0 → TGW (or specific CIDRs) to direct traffic into the TGW.

Trap 8: VPC peering supports transitive routing through a hub VPC

Wrong. Peering is non-transitive. Spoke A peered to Hub peered to Spoke B does not let Spoke A reach Spoke B. Use TGW for transitive multi-VPC.

FAQ — VPC Routing and Routing Decisions

Q1: How does longest prefix match resolve when a static and a propagated route exist at the same prefix length?

The static route wins. Longest prefix match is the first criterion: the most specific (longest) prefix is selected. If two routes have the same prefix length, AWS applies the static-over-propagated tiebreak, so a manually authored static route always overrides an auto-populated propagated route at the same specificity. This is the operator escape hatch — when BGP advertises something you do not want to honour, you can add a static route at the same prefix to override it. But at different prefix lengths, longest prefix wins regardless: a propagated /24 beats a static /16, because /24 is more specific. Memorise both halves of this rule for ANS-C01 scenario questions.

Q2: Why does VPC peering not support transitive routing, and what should I use instead?

VPC peering is a layer-3 forwarding relationship between two VPCs only. The two peers exchange traffic for prefixes explicitly listed in their route tables, and there is no mechanism for a peer to forward traffic to a third VPC on behalf of another peer. This is by design — AWS prevents transitive peering to keep blast radius small and routing decisions explicit. For multi-VPC connectivity where every VPC needs to reach every other, AWS Transit Gateway is the answer. TGW supports transitive routing natively: a packet from spoke A to TGW to spoke B is a single transitive hop. For complex segmentation, use multiple TGW route tables to enforce which spokes can reach which. For unidirectional service exposure (e.g., a SaaS provider exposing an API to many consumer VPCs), AWS PrivateLink is the answer, which works without traditional routing and even with overlapping CIDRs.

Q3: How do I redirect intra-VPC traffic through a Network Firewall or third-party inspection appliance?

This is harder than it looks because the local route always wins for the VPC's CIDR. Three patterns work. (a) Subnet-level segmentation: place inspection-required subnets in their own VPC and use TGW with appliance mode plus an inspection VPC, so the inter-subnet traffic crosses TGW and can be steered. (b) Gateway Load Balancer endpoints in each subnet's route table: GWLBe entries can override at specific prefix lengths within the local CIDR for some traffic patterns, but not all. (c) Host-based or sidecar inspection: instead of network-level redirection, run inspection on each instance (e.g., a sidecar agent) — orthogonal to VPC routing. The ANS-C01 canonical answer for "inspect intra-VPC traffic" is the multi-VPC + TGW pattern with appliance mode, not single-VPC route manipulation.

Q4: When does TGW route propagation populate a VPC's route table?

It does not — propagation in TGW context is between TGW attachments and TGW route tables, not directly into VPC route tables. The flow: a spoke VPC's TGW attachment propagates its CIDR to one or more TGW route tables. Other attachments associated to those TGW route tables can look up routes and forward. Each spoke VPC then has a static route in its VPC route table (e.g., 0.0.0.0/0 → tgw-xxx or <other-spoke-CIDR> → tgw-xxx) to direct traffic into TGW. The VPC route table itself does not auto-populate from TGW propagation — only from direct VGW propagation. This separation is intentional: it keeps VPC routing decisions explicit and prevents unbounded route table growth.

Q5: Why does my Site-to-Site VPN over TGW work for one CIDR but not another?

Most likely cause: BGP is advertising both CIDRs from on-premises, but the TGW attachment for the VPN is propagating only some of the routes to the destination spoke's TGW route table. Check the TGW route table associated with the destination spoke — does it contain a propagated route for the missing CIDR? If not, either the VPN attachment is not propagating to that route table, or BGP is filtering the advertisement. Second possibility: the VPC route table at the destination spoke does not have a route for that CIDR pointing to TGW. Third possibility: the on-premises customer gateway is BGP-advertising the CIDR with a longer AS-PATH or higher MED than expected, and AWS is preferring a different path. Use TGW Route Analyzer or VPC Reachability Analyzer to trace the path.

Q6: How do I set up a centralised egress VPC for outbound internet access from many spoke VPCs?

Pattern: a shared egress VPC in the network account, attached to the same TGW as all spokes. Egress VPC has public subnets with IGW + NAT GW, and a TGW attachment in private subnets. TGW route tables: every spoke has 0.0.0.0/0 → egress-VPC-attachment. Egress VPC's TGW attachment route table has spoke CIDRs propagated for return traffic. Egress VPC's public subnet has IGW for egress; private subnet has NAT GW for the spoke traffic to NAT through. Spokes save NAT GW costs (one NAT GW per AZ in the egress VPC instead of N per spoke), centralise egress filtering (Network Firewall in the egress VPC), and consolidate Elastic IPs for allow-listing by external services.

Q7: What is the difference between blackhole routes in a TGW route table and missing routes?

A blackhole is an explicit drop instruction; a missing route falls back to less-specific routes via longest prefix match, often ending at a default route. Functionally: TGW RT contains 10.5.0.0/16 → blackhole plus a default 0.0.0.0/0 → spoke-A. A packet for 10.5.0.42 hits the blackhole and is dropped. Without the blackhole, the packet falls back to the default and reaches spoke A — possibly an unintended destination. Use blackholes to enforce explicit segmentation: "non-prod must never reach prod" is a blackhole for the prod CIDR in the non-prod TGW route table. The exam favors blackhole answers in security-sensitive scenarios where "fallback to default" would be a security violation.

Q8: How do propagation, association, and static routes interact in a TGW route table?

Association decides which TGW route table an attachment uses for outbound lookups. Each attachment is associated with exactly one TGW RT. Propagation decides which TGW route tables an attachment's routes are advertised into. An attachment can propagate to many RTs. Static routes are manually added to a specific TGW RT and beat propagated routes at the same prefix length. Worked example: a prod VPC attachment is associated with the prod TGW RT (so its outbound traffic looks up the prod RT) and propagates its CIDR to the prod RT and the shared-services RT (so prod and shared-services attachments can reach it). A static route in the prod RT for 192.168.0.0/16 → on-prem VPN attachment overrides any propagated /16 from the same prefix.

Q9: What is the operational impact of having stale blackhole entries in a route table?

In a VPC route table, a route showing as blackhole typically means the target (peering connection, VGW, NAT GW) was deleted but the route was not. Traffic for that prefix is silently dropped. Operationally: investigate why the target was deleted — was the peering torn down intentionally? — and either remove the stale route (so traffic falls back to the default) or update the route to a current target. In a TGW route table, a blackhole appears as a deliberate static entry; deletion is a deliberate operator action. Monitor with VPC Reachability Analyzer and AWS Config rules to detect stale blackholes; alert with EventBridge on DeleteVpcPeeringConnection events to trigger route table cleanup automation.

Q10: How do I troubleshoot a "route looks correct but traffic still fails" scenario?

Apply the diagnostic ladder. Layer 1: VPC Reachability Analyzer — provide source ENI, destination IP, get a path with each hop annotated. If Reachability Analyzer says the path is good, traffic should flow; otherwise it pinpoints the failed step (security group, NACL, route table). Layer 2: VPC Flow Logs at the source ENI — filter for the destination IP; ACCEPT means the SG allowed it; REJECT means SG or NACL dropped it; absent means the source did not even attempt to send (often a routing or DNS issue). Layer 3: TGW Route Analyzer for cross-VPC paths — confirms the TGW route tables agree on the destination. Layer 4: packet capture (Traffic Mirroring or instance-level tcpdump) — for asymmetric routing or MTU black hole diagnosis. The ANS-C01 troubleshooting answer pattern is "Reachability Analyzer first, Flow Logs second, packet capture third" — start with the cheapest, most-targeted tool.

Further Reading

• VPC Route Tables
• Transit Gateway Route Tables
• VPC Peering Routing
• Route Table Options for IGW/VGW Ingress Routing
• NAT Gateway Scenarios
• Building a Scalable and Secure Multi-VPC AWS Network Infrastructure
• AWS ANS-C01 Exam Guide

VPC routing is the foundation; the next layer to master on ANS-C01 is Transit Gateway routing tables, attachments, and Connect for multi-VPC and SD-WAN integration patterns; BGP attribute manipulation for hybrid failover; PrivateLink and VPC endpoints for service exposure without traditional routing; and IaC patterns for CloudFormation/CDK/Terraform that author all of the above declaratively.

• Transit Gateway — Routing Tables, Attachments, and Connect
• BGP Configuration — AS-Path Prepending, MED, Communities, and BFD
• PrivateLink, VPC Endpoints, and Endpoint Policies
• IaC for Network Infrastructure