Study ANS-C01 route maintenance for BGP, Direct Connect, VPN, Transit Gateway, VIFs, route priority, quotas, PrivateLink, VPC peering, summarization, and CIDR overlap.
Routing and connectivity maintenance questions on ANS-C01 are about keeping a working path correct as prefixes, accounts, Regions, quotas, and failure conditions change. The exam is testing steady-state operations: route hygiene, BGP behavior, private-service boundaries, route priority, summarization, and controlled changes.
The current AWS task statement is to maintain routing and connectivity on AWS and hybrid networks. The official scope includes BGP over Direct Connect, Direct Connect gateways, Transit Gateway, VIFs, route limits and quotas, PrivateLink, VPC peering, inter-Region and intra-Region communication patterns, route propagation, static and dynamic routing, route summarization, and CIDR overlap.
| Maintenance question | What a strong answer checks |
|---|---|
| Did the route control plane change? | BGP session state, advertised prefixes, accepted prefixes, local preference, AS path, and MED where relevant. |
| Did the AWS route domain change? | Transit Gateway route table association, propagation, static routes, blackhole routes, and VPC subnet routes. |
| Did scale introduce a quota problem? | Route-table limits, propagated route limits, attachment limits, bandwidth constraints, and VIF limits. |
| Did a private-service boundary change? | PrivateLink endpoint status, endpoint policies, VPC endpoint DNS, and consumer/provider permissions. |
| Did a VPC peering path change? | Non-overlapping CIDRs, routes in both VPCs, DNS options, and no transitive-routing assumption. |
| Did overlapping or more-specific prefixes appear? | Longest prefix match, route priority, summarization, and CIDR redesign or NAT patterns. |
Strong answers start with the maintained control plane before deep packet analysis.
| Symptom or requirement | Strongest first check |
|---|---|
| Hybrid route disappeared | BGP session, route advertisement, route propagation, and customer router state. |
| Direct Connect primary/backup path changed unexpectedly | BGP local preference community, AS path, prefix specificity, and connection health. |
| VPN failover behaves differently than expected | Tunnel health, static versus BGP routing, route priority, and customer gateway asymmetric-routing support. |
| One spoke VPC can no longer reach shared services | TGW route table association, propagation, blackhole routes, and VPC subnet route tables. |
| Private application access fails for one consumer | PrivateLink endpoint connection state, endpoint policy, service permissions, and DNS. |
| A new prefix breaks routing | CIDR overlap, longest-prefix match, route summarization, and route-table quota. |
| A simple two-VPC connection behaves unexpectedly | VPC peering routes, CIDR overlap, DNS resolution, and security controls. |
Use this loop when a previously working path changes.
flowchart LR
C["Change or symptom"] --> P["Prefixes and route source"]
P --> D["Route domain: VPC, TGW, DX, VPN, peering, or PrivateLink"]
D --> R["Route priority and propagation"]
R --> B["Boundary: security, DNS, endpoint, quota"]
B --> V["Validate path and document drift"]
The trap is starting with packet capture before confirming whether the route still exists and whether the correct route domain is using it.
Direct Connect routing maintenance often comes down to BGP state, advertisements, and path preference.
| Operational need | Maintenance check |
|---|---|
| Active/passive Direct Connect path | Local preference BGP communities, advertised prefix length, AS path, and connection health. |
| Active/active load sharing | Equal prefix length and compatible BGP attributes for ECMP where supported. |
| Public AWS service access over DX | Public VIF route policies and public prefix advertisement rules. |
| Private VPC access | Private VIF to VGW or Direct Connect Gateway pattern. |
| Transit Gateway access | Transit VIF through Direct Connect Gateway and TGW route-table behavior. |
| Unexpected inbound path from AWS to on-premises | Direct Connect local preference communities and prefix specificity. |
AWS Direct Connect supports local preference BGP community tags for private and transit VIFs. For exam reasoning, remember that route preference is not just “which link is up”; it is a combination of prefix specificity, local preference, AS path, and service-specific behavior.
Site-to-Site VPN maintenance requires knowing how static routes, BGP routes, and tunnel health interact.
| Situation | Maintenance implication |
|---|---|
| Customer gateway supports BGP | Dynamic routing is usually stronger for route exchange and failover behavior. |
| Customer gateway does not support BGP | Static routing is the fallback, but failover needs careful monitoring. |
| Same prefix exists through DX and VPN | Route priority and failover intent must be explicit. |
| VPN tunnel endpoint changes | Route priority can shift; both tunnels must be configured and monitored. |
| Customer gateway cannot support asymmetric routing | Failover tuning becomes more fragile. |
| Static and BGP choices conflict | Verify which route type is configured and which prefixes are known to AWS. |
AWS route priority rules can make a static route or Direct Connect route win over a VPN BGP route for matching prefixes. Maintenance questions often hide the answer in which route source is more preferred.
Transit Gateway maintenance is route-domain maintenance.
| Check | Why it matters |
|---|---|
| Attachment association | Determines which TGW route table is used by traffic entering from that attachment. |
| Route propagation | Determines which attachment routes are installed in which TGW route tables. |
| Static routes | Often required for peering, inspection, or specific override paths. |
| Blackhole routes | Useful guardrail, but can intentionally drop matching traffic. |
| VPC subnet route tables | Workload subnets must still route intended destinations to the TGW. |
| Route Analyzer and Network Manager | Help validate route intent and topology over time. |
Do not assume the default Transit Gateway route table is still the right route domain after an organization adds production, nonproduction, shared services, and inspection boundaries.
PrivateLink and VPC peering solve different private-connectivity problems, so they fail differently.
| Pattern | Maintenance checks |
|---|---|
| PrivateLink | Endpoint connection state, endpoint service permissions, endpoint policy, security groups on endpoint ENIs, private DNS, and provider service health. |
| VPC peering | Routes in both VPCs, non-overlapping CIDRs, security controls, DNS options, peering state, and no transitive-routing expectation. |
| Shared service through PrivateLink | Consumer endpoint DNS and endpoint policy often matter more than route propagation. |
| Simple VPC-to-VPC route through peering | Route tables and CIDR overlap are usually the first checks. |
If the prompt says “one service only,” maintain the PrivateLink boundary. If it says “network-level bidirectional routing,” maintain peering, TGW, or another routing pattern instead.
ANS-C01 explicitly includes limits and quotas plus route summarization and CIDR overlap. These are operations topics because they often emerge after the design scales.
| Issue | Strong maintenance response |
|---|---|
| Route table is approaching limits | Summarize prefixes, reduce unnecessary propagation, or redesign route domains. |
| Many small prefixes are advertised over BGP | Aggregate where safe and avoid leaking unnecessary routes. |
| CIDR overlap appears after merger or new account onboarding | Do not rely on route propagation; consider renumbering, NAT, PrivateLink, or isolated route domains. |
| Transit Gateway route table grows too broad | Split route domains, control propagation, and use blackhole routes where appropriate. |
| Route change has unknown blast radius | Stage the change and validate reachability before broad propagation. |
Route summarization is not just neatness. It protects route-table scale, reduces operational noise, and makes failure domains easier to reason about.
| Scenario | Strong first move |
|---|---|
| New on-premises prefix is not reachable from AWS | Check BGP advertisement, accepted routes, route propagation, and VPC/TGW route tables. |
| Backup Direct Connect path is used unexpectedly | Check BGP communities, prefix length, AS path, and connection health. |
| VPN failover drops traffic | Check tunnel health, route priority, customer gateway support for asymmetric routing, and BGP/static route behavior. |
| Shared service path breaks after new TGW segmentation | Check attachment association, propagation, static routes, and blackhole routes. |
| PrivateLink consumer cannot connect after provider change | Check endpoint service permissions, endpoint status, DNS, endpoint policy, and provider target health. |
| VPC peering works one way only | Check reciprocal route tables, security groups, NACLs, and return path. |
| Stem clue | Eliminate first | Keep in play |
|---|---|---|
| “new prefix advertised” | packet mirroring first | BGP advertisement, route tables, propagation |
| “route table near limit” | add every /32 | summarization, route-domain redesign |
| “one service private access” | broad peering by reflex | PrivateLink |
| “transitive routing over peering” | VPC peering as hub | Transit Gateway or Cloud WAN |
| “Direct Connect active/passive” | random AS path changes only | local preference communities, prefix specificity, health |
| “same prefix over DX and VPN” | assume both are equal | route priority and failover policy |
| “overlapping CIDRs” | more propagation | renumbering, NAT, PrivateLink, isolated domains |
When an established route path changes unexpectedly, use this order:
This order keeps maintenance focused on route state before moving into packet capture or application troubleshooting.
A company has two Direct Connect connections to AWS. The primary connection should receive return traffic from AWS for a set of private prefixes, and the backup connection should be used only if the primary fails. Both connections advertise the same prefixes with the same prefix length. After a maintenance window, AWS return traffic starts using the backup path even though the primary connection is healthy. Which check is strongest first?
Answer: Check Direct Connect BGP local preference communities and path attributes.
Why: The symptom is route preference for return traffic over Direct Connect, not packet payload or DNS. Direct Connect supports local preference BGP community tags for private and transit VIFs. If prefix length is the same, local preference and other BGP attributes can determine the preferred path.
For ANS-C01 route maintenance, check route source, prefix, route priority, route domain, quota, connectivity boundary, and return path before deep packet tools. Use BGP and Direct Connect evidence for hybrid route preference, Transit Gateway route tables for hub routing, PrivateLink state for service exposure, VPC peering routes for simple direct connectivity, and summarization or redesign when route scale or CIDR overlap is the real issue.
Continue with 3.2 Traffic Analysis and Connectivity Troubleshooting to choose the right evidence once route maintenance identifies the likely failure layer.