BGP Configuration — AS-Path Prepending, MED, Communities, and BFD

BGP configuration on ANS-C01 is the deepest topic in the entire exam. While the Solutions Architect exam treats BGP as a checkbox ("yes, Direct Connect uses BGP"), the Advanced Networking Specialty exam asks "given an active Direct Connect with AS-PATH prepended by 3 on the customer side and a backup VPN with default AS-PATH, the customer wants on-premises traffic from a specific subnet to prefer the VPN — which BGP attribute do you manipulate, and on which side of the session?" That is routing policy via BGP attributes, and ANS-C01 has at least four to six questions on this exact territory.

This topic covers the BGP primitive surface for AWS hybrid networking: eBGP fundamentals on Direct Connect and Site-to-Site VPN, inbound traffic engineering via AS-path prepending, outbound traffic engineering via LOCAL_PREF, the special semantics of MED between AS pairs, AWS-managed BGP communities on Direct Connect (7224:7100/7200/7300 scope and 7224:1–9 NO_EXPORT signals), BFD for sub-second failure detection, ECMP load sharing across multiple BGP-routed connections, BGP timer tuning, and the most common active/passive and active/active failover patterns the exam tests as scenarios. It is mapped to Task Statement 2.1 (Implement routing and connectivity between on-premises networks and the AWS Cloud).

Why BGP Is the Linchpin of ANS-C01 Hybrid Connectivity

BGP is the only routing protocol AWS supports for hybrid connectivity. There is no OSPF, no IS-IS, no EIGRP between on-premises and AWS — every Direct Connect VIF and every Site-to-Site VPN that uses dynamic routing speaks eBGP (external BGP) between the customer's autonomous system and AWS's autonomous system. Static routing exists as a fallback for VPN connections, but Direct Connect requires BGP, and the modern best-practice answer for any non-trivial hybrid scenario is BGP. So BGP attribute knowledge is the gating skill for Domain 1.5, Domain 2.1, Domain 3.1, and several Domain 4 questions.

The framing across this topic is deterministic path selection via attribute hierarchy. BGP picks a best path among multiple advertisements by walking a sorted list of decision criteria: weight (Cisco-specific), LOCAL_PREF, locally originated, AS-PATH length, origin type, MED, eBGP-over-iBGP, IGP metric to next hop, oldest path, router ID, neighbour IP. The ANS-C01 testable subset is AS-PATH length, LOCAL_PREF, MED, and BGP communities. Mastering which attribute affects which direction of traffic, and which attribute is set by which side of the session, is the single largest leverage point in the exam.

The exam tests BGP in three distinct flavours. Single-session attribute manipulation asks "to make AWS prefer a specific path, which attribute do you set?" Multi-path comparison asks "given two BGP advertisements with different AS-PATH lengths and different MEDs from different ASes, which path does AWS choose?" Failover scenarios ask "given an active Direct Connect and passive VPN, design the BGP attributes so the VPN takes over only when DX fails."

Plain-Language Explanation: BGP — Path Selection via Attribute Hierarchy

BGP combines a few attributes (AS-PATH, LOCAL_PREF, MED, communities) into deterministic path selection. Three analogies anchor the moving parts.

Analogy 1: Highway Routing With Multiple Tolls and Detours

Think of BGP as route choice on a highway network with multiple ways to reach a destination. Each path is a sequence of tolls (autonomous systems) that a car must pass through. AS-PATH length is "how many tolls are on this route" — fewer tolls win. AS-PATH prepending is "make your route look longer by listing your toll twice or three times" — useful when you want oncoming traffic to choose a different route. LOCAL_PREF is your home navigation system's personal preference, telling your own car which exit to take when leaving home — it does not affect oncoming traffic at all because the other side cannot see it. MED is a hint you whisper to a specific neighbour: "if you have multiple ways to enter my network, please use this entry point" — the neighbour can ignore the hint or honour it, but the hint travels only as far as the immediate neighbour. BGP communities are stickers attached to your route advertisement: "this route is for local-only delivery, do not pass it along" — each AWS region or scope reads stickers and adjusts behaviour.

Analogy 2: International Mail With Postage Class Markings

A BGP advertisement is a postal item crossing customs from one country (AS) to another. Each customs stamp on the postal label is an AS in the AS-PATH. AS-PATH prepending is putting your country's stamp on the package three times so that the receiving country thinks your package crossed three borders — making your shipping route look longer and discouraging the recipient from preferring it. LOCAL_PREF is your post office's internal sorting preference: when you have two trucks to send a package, your manager tells you which truck to use — the choice is invisible to the recipient. MED is a "preferred entry port" sticker on the package — the recipient post office can use this hint when deciding which port-of-entry to send the package through, but only if all other criteria are equal. NO_EXPORT is a "this letter is for the recipient post office only — do not forward to any other country" stamp.

Analogy 3: Train Routing With Express vs Local Service

A BGP route is a train route from station A to station B. AS-PATH length is "number of train transfers required" — fewer transfers win. AS-PATH prepending is making your route look longer than it really is by inserting fake transfer announcements. LOCAL_PREF is the conductor at the originating station who decides which train this passenger boards — invisible to the destination. MED is a hint to the destination station: "if multiple trains arrive from my line, please direct this passenger to track 3" — only honoured by the immediate destination. BFD is the train control system that pings every 100 ms — if three pings fail, the train signals "track failure" and switches to the backup route automatically.

BGP Fundamentals on AWS — eBGP, ASNs, and Session Establishment

BGP is the inter-domain routing protocol of the public internet, defined in RFC 4271. AWS runs eBGP (between different ASes) on every BGP session — there is no iBGP between AWS and customer, because the AS boundary is always crossed.

Autonomous System Numbers (ASNs)

An ASN is a 16-bit (2-byte) or 32-bit (4-byte) integer identifying a routing domain. Public ASNs are allocated by IANA and used on the public internet. Private ASNs range from 64512–65534 (2-byte) or 4200000000–4294967294 (4-byte) — used internally and not advertised on the public internet. AWS uses ASN 64512 by default for Direct Connect and Site-to-Site VPN customer-side ASN, and 7224 for AWS-side public services on Direct Connect. The customer can use any private ASN or their own public ASN.

eBGP session establishment on Direct Connect

A Direct Connect Private VIF establishes an eBGP session between the customer router (BGP peer IP in the 169.254.x.x link-local range) and AWS's BGP speaker. The session uses TCP port 179. MD5 authentication is supported via a shared secret. Maximum hop count is typically 1 (single-hop eBGP) for direct cross-connect. After session establishment, both sides exchange OPEN, UPDATE, KEEPALIVE, and NOTIFICATION messages; UPDATEs carry NLRI (Network Layer Reachability Information) — the prefixes being advertised — plus path attributes (AS-PATH, MED, communities, NEXT_HOP, ORIGIN).

eBGP on Site-to-Site VPN

Site-to-Site VPN with dynamic routing establishes an eBGP session inside each IPsec tunnel — two tunnels per VPN connection, each with its own BGP session. The customer gateway peers with the AWS-side virtual private gateway or transit gateway. The same BGP attributes apply, though some AWS-managed communities are Direct Connect specific.

eBGP on Transit Gateway Connect

Transit Gateway Connect is an attachment type that establishes BGP over a GRE tunnel (rather than IPsec) atop an underlying VPC or DX attachment. Used primarily for SD-WAN integration where a customer's SD-WAN appliance establishes BGP directly with the TGW. Up to 4 BGP peers per Connect peer for ECMP, supporting higher aggregate bandwidth than a single VPN tunnel.

AS-PATH Prepending — Inbound Traffic Engineering

AS-PATH prepending is the act of artificially inserting your own ASN multiple times into the AS-PATH attribute when advertising a prefix to a neighbour. The neighbour sees a longer AS-PATH and (if all other attributes are equal) prefers a path with a shorter AS-PATH. This is the mechanism for influencing inbound traffic — making AWS choose path A over path B for traffic destined to your network.

Mechanics on Direct Connect

A typical Direct Connect failover scenario has two connections from the customer to AWS — primary and backup — both advertising the same prefix (say, 10.0.0.0/16) to AWS. By default, AWS sees both paths as equal and uses ECMP. To make the primary preferred, the customer prepends their own ASN twice or three times on the backup connection's BGP advertisement, making the backup path appear AS-PATH length 3 vs primary length 1. AWS picks the shorter path (primary) for inbound traffic.

Direction matters — prepending affects inbound

The most-tested ANS-C01 BGP fact: AS-PATH prepending influences the direction of traffic from the AS that receives the advertisement, back to the AS that sent it. So prepending on the customer-to-AWS direction influences traffic from AWS to on-premises. To influence traffic from on-premises to AWS, the customer must use a tool that affects local routing decisions — typically LOCAL_PREF on the customer side (which is invisible to AWS).

Active/passive Direct Connect + VPN backup

A canonical ANS-C01 scenario: customer has an active Direct Connect Private VIF and a passive Site-to-Site VPN as backup. Both advertise on-premises CIDRs to AWS. To ensure AWS prefers DX during normal operation:

• Customer side: prepend on-premises CIDRs by 2-3 ASes on the VPN side advertisement. AWS sees DX as AS-PATH length 1, VPN as length 3-4, prefers DX.
• AWS side: customer can additionally use AWS-managed BGP communities (7224:7100 / 7200 / 7300) to influence the AWS-side preference, though prepending on the customer side is usually sufficient.

When prepending fails

Prepending only works as a tiebreaker when other attributes are equal. If the VPN advertises with a higher LOCAL_PREF set on the AWS side (rare, normally not adjustable by customer), or if MED differs, prepending is overridden. The exam expects you to recognise that AS-PATH length is one criterion in BGP path selection but not the highest priority.

LOCAL_PREF — Outbound Traffic Engineering

LOCAL_PREF (Local Preference) is a 32-bit value an AS uses internally to express a preference among multiple paths to the same destination. Higher LOCAL_PREF wins. LOCAL_PREF is iBGP-only — it is not transmitted in eBGP UPDATEs and not visible to the neighbour AS.

Why LOCAL_PREF for outbound

Because LOCAL_PREF affects only the local AS's path selection, it is the right tool for influencing outbound traffic from your AS to a destination in another AS. On the customer side, the on-premises BGP routers set LOCAL_PREF on incoming AWS advertisements: a higher LOCAL_PREF on the DX-learned routes makes outbound traffic prefer DX, regardless of what AWS-side attributes say.

LOCAL_PREF and AWS-side advertisement

AWS does not expose direct LOCAL_PREF manipulation to customers. Instead, customers use AWS-managed BGP communities (7224:7100/7200/7300) that AWS translates into internal LOCAL_PREF settings within AWS's network. So although LOCAL_PREF as an attribute is iBGP-only, AWS provides community-based hooks that achieve a similar effect.

Worked example — outbound preference for DX

Customer has DX and VPN to AWS, both advertising spoke VPC CIDRs back to on-premises. To make on-premises-to-AWS traffic prefer DX:

• On-premises router: set local-preference 200 on routes received via DX, local-preference 100 on routes received via VPN. Higher LOCAL_PREF wins, so DX is preferred.
• AWS sees no change in customer's LOCAL_PREF (iBGP-only) and continues to advertise normally.

This is symmetric with the prepending example: AS-PATH prepending controls inbound; LOCAL_PREF controls outbound. Together they implement bidirectional traffic engineering.

MED (Multi-Exit Discriminator) — Per-Neighbour Entry Point Hint

MED is a 32-bit value carried in eBGP UPDATEs. Lower MED wins. MED is a hint from one AS to a specific neighbour AS about the preferred entry point when the neighbour has multiple ways to reach a prefix.

MED scope

MED is only compared between paths from the same neighbouring AS. If AWS receives paths from AS 65000 with MED 100 and from AS 65001 with MED 50, MED is not compared because the paths come from different ASes. Within AS 65000's two paths (e.g., from two different DX connections terminating in the same AS), the lower MED wins.

MED on Direct Connect

A customer with two DX connections to AWS from the same on-premises AS can use MED to express preference: connection A advertises with MED 100, connection B with MED 200. AWS receives both and prefers connection A for traffic to that prefix. This is a form of inbound traffic engineering, similar to AS-PATH prepending but more granular and only effective when both paths are from the same customer AS.

MED comparison rules

By default, AWS only compares MED between paths from the same neighbouring AS. The optional always-compare-med setting (not customer-configurable on AWS) would compare MED across all paths regardless of AS, which can cause unexpected path selection.

BGP Communities on Direct Connect — AWS-Managed Scope and Preference

BGP communities are 32-bit tags (typically formatted as XXXX:YYYY) attached to a route advertisement. AWS exposes specific communities on Direct Connect Public VIFs and (in limited form) Private VIFs to control AWS-side routing behaviour.

AWS-managed scope communities (Public VIF)

When advertising prefixes on a Public VIF to AWS, the customer can attach scope communities to control which AWS regions receive the advertisement:

• 7224:9100 — local AWS region only. AWS does not propagate this prefix beyond the region the DX connection terminates in.
• 7224:9200 — same continent. Propagated within the continent's regions only.
• 7224:9300 — global (default). Propagated to all AWS regions.

This is critical for customers who want their advertisement to be reachable only from a specific region — e.g., a regulated workload that must not be reachable from outside a country.

AWS-managed local-preference communities (Public and Private VIF)

When AWS advertises prefixes to the customer, the customer can influence AWS's outbound preference (which DX path AWS uses for traffic to the customer) by attaching local-preference communities to inbound advertisements:

• 7224:7100 — low LOCAL_PREF (less preferred).
• 7224:7200 — medium LOCAL_PREF (default).
• 7224:7300 — high LOCAL_PREF (most preferred).

If a customer has two DX connections and wants AWS to prefer connection A, they attach 7224:7300 to advertisements on connection A and 7224:7100 to advertisements on connection B. AWS internally translates these into LOCAL_PREF and prefers connection A.

NO_EXPORT and NO_ADVERTISE

The standard BGP communities NO_EXPORT (65535:65281) and NO_ADVERTISE (65535:65282) also work on AWS:

• NO_EXPORT — the route is not advertised outside the receiving AS.
• NO_ADVERTISE — the route is not advertised to any other BGP peer at all.

Useful when a customer wants AWS to receive an advertisement but not propagate it further — e.g., a private prefix that should reach AWS Region A but not be propagated to Region B.

BFD — Bidirectional Forwarding Detection for Sub-Second Failover

BFD is a lightweight protocol that detects link liveness in milliseconds rather than relying on BGP keepalive timers (which take 60–180 seconds to declare a session dead). When BFD detects a failure, it triggers immediate BGP session teardown, accelerating failover from minutes to under a second.

BFD on Direct Connect

AWS supports BFD on Direct Connect with default parameters: 300 ms tx interval, 3 multiplier — meaning a failure is declared after 900 ms of missed packets. Both sides must support BFD; the customer's BGP router enables BFD per neighbour. AWS's BFD support is automatic once the customer enables it on their side.

BFD on Site-to-Site VPN

Site-to-Site VPN supports BFD on the IPsec tunnel for fast failover between the two tunnels in a connection. Combined with active/active BGP routing, BFD ensures that if one tunnel goes down, traffic shifts to the other within a second.

BFD on TGW Connect

Transit Gateway Connect (GRE + BGP) supports BFD on each BGP peer, enabling sub-second failover for SD-WAN appliances.

Why BFD matters

Without BFD, BGP keepalive at 30 seconds and hold-time at 90 seconds means a failed link is detected after 90 seconds of missed keepalives. A 90-second outage is unacceptable for many production workloads. BFD reduces this to under a second.

ECMP — Equal-Cost Multi-Path Load Sharing

ECMP allows a router to use multiple equal-cost paths simultaneously, distributing flows across them via hash-based load balancing. On AWS, ECMP is enabled by default when multiple BGP-routed paths exist and the BGP best-path algorithm declares them equal.

ECMP on TGW

Transit Gateway supports ECMP for VPN attachments and Direct Connect attachments by default. Multiple Site-to-Site VPN connections to the same TGW with BGP can aggregate bandwidth: two 1.25 Gbps VPN connections give ~2.5 Gbps via ECMP. Up to 50 ECMP paths are supported in modern TGW configurations.

ECMP requirements

• All paths must have identical AS-PATH length (otherwise BGP selects the shortest).
• All paths must have identical LOCAL_PREF, MED, and other path attributes.
• Path selection algorithm uses 5-tuple hash (src IP, dst IP, src port, dst port, protocol) — same flow always takes same path; different flows distribute.

ECMP on VGW vs TGW

VGW (Virtual Private Gateway) does not support ECMP across multiple VPN connections. If you need bandwidth aggregation, migrate to TGW.

ECMP and ordering

A flow's hash determines which path it takes. Within a flow, packets stay on the same path so TCP ordering is preserved. Across flows, distribution is hash-uniform. This means a single high-bandwidth flow cannot exceed the bandwidth of one path; ECMP scales aggregate bandwidth, not per-flow bandwidth.

Active/Passive vs Active/Active Failover Patterns

ANS-C01 expects you to design two canonical failover topologies using BGP attributes.

Active/Passive — Direct Connect primary, VPN backup

Goal: DX is primary; VPN takes over only if DX fails.

• Customer side: AS-PATH prepend by 2-3 on the VPN advertisement to AWS. AWS sees DX as shorter path, prefers DX.
• AWS side: customer attaches 7224:7100 (low LOCAL_PREF) to advertisements received on the VPN side, 7224:7300 (high LOCAL_PREF) to DX advertisements. AWS prefers DX outbound.
• BFD on DX for sub-second failover detection.
• When DX BGP session goes down, AWS sees only the VPN path and uses it; when DX recovers, BGP re-converges and traffic shifts back.

Active/Active — Two Direct Connects with ECMP

Goal: Both DXes carry traffic simultaneously; each can take over the other's load on failure.

• Both DX connections advertise identical prefixes with identical AS-PATH, LOCAL_PREF, MED. AWS sees them as equal-cost.
• ECMP distributes flows 50/50 by 5-tuple hash.
• BFD on both for fast failure detection.
• If one fails, the other takes 100 percent of the traffic instantly (subject to bandwidth headroom).

Active/Active — DX + VPN with ECMP (less common)

Possible but unusual. Both must advertise identical attributes, which conflicts with the typical desire to prefer DX. Used when bandwidth aggregation is the priority over path preference. Tune for symmetric AS-PATH and LOCAL_PREF.

BGP Timer Tuning and Session Stability

BGP session stability depends on keepalive and hold-time parameters. Both are negotiated at session establishment; the lower value of the two sides applies.

Default and recommended values

• AWS default: keepalive 30 seconds, hold-time 90 seconds.
• Aggressive (with BFD): keepalive 30, hold-time 90, plus BFD with 300 ms / 3 multiplier.
• Without BFD, faster failover: keepalive 10, hold-time 30 (negotiated down).

Aggressive timers without BFD stress the BGP control plane and risk false flaps under temporary congestion. AWS recommends BFD over aggressive timer tuning.

BGP session flapping

A flapping session (repeatedly establishing and tearing down) is usually caused by:

• Physical layer instability (fibre, optical signal).
• Layer 2 issues (VLAN config, MTU mismatch).
• BGP timer mismatch (not common on AWS — AWS negotiates flexibly).
• BGP route limit exceeded — AWS shuts down the session if the advertised prefix count exceeds the limit.

BGP prefix limits on AWS

• Direct Connect Private VIF: max 100 prefixes received from customer.
• Direct Connect Public VIF: max 1000 prefixes received from customer.
• Site-to-Site VPN: max 100 prefixes received from customer.

Exceeding the limit shuts down the session. The fix is route summarisation — aggregate /24s into /16s on the customer side.

Common Traps Recap — BGP on ANS-C01

Trap 1: AS-PATH prepending influences outbound traffic

Wrong. AS-PATH prepending influences inbound traffic from the neighbouring AS. To influence outbound, use LOCAL_PREF on your local routers.

Trap 2: LOCAL_PREF is visible to AWS

Wrong. LOCAL_PREF is iBGP-only — not transmitted in eBGP UPDATEs. AWS cannot see customer-side LOCAL_PREF directly. Use BGP communities (7224:7100/7200/7300) for AWS-side preference.

Trap 3: MED is compared globally

Wrong. MED is compared only between paths from the same neighbouring AS (by default).

Trap 4: BGP timers can give sub-second failover

Wrong. BGP keepalive/hold-time at default give 90-second detection. Use BFD for sub-second failover.

Trap 5: VGW supports ECMP across multiple VPN connections

Wrong. VGW does not ECMP. Use TGW for ECMP across VPN attachments.

Trap 6: Direct Connect supports static routing

Wrong. Direct Connect requires BGP. Site-to-Site VPN supports both static and dynamic (BGP); BGP is recommended.

Trap 7: 7224:7300 is for outbound preference

Wrong. 7224:7300 is AWS's outbound preference (i.e., AWS-to-customer direction) — set by the customer on routes advertised TO AWS. To influence customer's outbound preference, set LOCAL_PREF on the customer's own router.

Trap 8: Prefix limit is per ASN

Wrong. Prefix limit is per VIF type: 100 on Private VIF, 1000 on Public VIF, 100 on VPN.

FAQ — BGP Configuration on AWS

Q1: Which BGP attribute do I use to make AWS prefer Direct Connect over VPN for traffic to my on-premises network?

This is inbound traffic engineering (AWS-to-customer direction). Use AS-PATH prepending on the VPN side: when advertising on-premises prefixes from your customer gateway to AWS, prepend your ASN by 2 or 3 on the VPN BGP session. AWS sees DX with AS-PATH length 1 and VPN with length 3-4, prefers DX (shorter path wins). Alternatively or additionally, attach BGP community 7224:7100 to VPN advertisements (low local-preference for AWS) and 7224:7300 to DX advertisements (high local-preference). AWS internally translates these into LOCAL_PREF settings within its network. Both methods compose, and using both gives the strongest preference.

Q2: Why does my LOCAL_PREF setting not influence AWS's path selection?

Because LOCAL_PREF is iBGP-only — it is a path attribute that does not cross AS boundaries in eBGP UPDATEs. Your customer-side LOCAL_PREF affects only your own routers' decisions about outbound traffic from on-premises to AWS. To influence AWS's choice of path inbound to on-premises, use AS-PATH prepending or AWS-managed BGP communities (7224:7100/7200/7300). The exam tests this distinction frequently — answer choices often pair "set LOCAL_PREF 200 on AWS-side advertisement" (a no-op) with "set AS-PATH prepend by 3 on backup advertisement" (correct). Recognise that LOCAL_PREF is your local AS's tool for outbound preference and AS-PATH prepending is the cross-AS tool for inbound preference.

Q3: How does MED differ from AS-PATH prepending for inbound traffic engineering?

Both influence the neighbouring AS's choice of path back to your network. MED is a per-AS-pair hint — only compared between paths from the same neighbouring AS, finer-grained, lower wins. AS-PATH prepending is comparable across all paths — any path with longer AS-PATH is less preferred regardless of source AS. Use MED when you have two DX connections from the same on-premises AS and want a soft preference between them; AWS will compare MED and prefer the lower value. Use AS-PATH prepending when you have paths from different topologies (DX vs VPN) or want a stronger, hierarchically-evaluated preference. AS-PATH prepending is more robust because BGP's path selection algorithm evaluates AS-PATH before MED, so prepending wins when the two attributes conflict.

Q4: When should I enable BFD on Direct Connect, and what are the trade-offs?

Enable BFD whenever fast failover is required and the customer router supports it. Default BFD parameters (300 ms tx, 3 multiplier) detect failure in 900 ms and trigger BGP session teardown immediately, giving sub-second failover to a backup path. Trade-offs: BFD generates additional packets (every 300 ms in each direction), so on extremely low-bandwidth links it adds modest overhead — typically negligible on Direct Connect (1+ Gbps). BFD requires CPU on both ends; underpowered customer routers may struggle with aggressive timers. BFD does not work over GRE tunnels in some implementations; verify customer router support. AWS-recommended default: enable BFD on every BGP session for sub-second failover, accept the modest overhead.

Q5: How do I aggregate bandwidth from multiple Site-to-Site VPN connections to AWS?

Use Transit Gateway with ECMP, not VGW. VGW does not ECMP across multiple VPN connections — only one is active at a time. TGW supports ECMP across BGP-routed VPN attachments and Direct Connect attachments. Architecture: create N Site-to-Site VPN connections to a single TGW, each with two IPsec tunnels (so 2N total tunnels), each running BGP with identical AS-PATH and identical attributes. TGW sees them as equal-cost and hashes flows across them. Aggregate bandwidth ~= N × 1.25 Gbps (single VPN tunnel maximum). Up to 50 ECMP paths supported in modern TGW. For bandwidth requirements above 5-10 Gbps, Direct Connect is more cost-effective and provides guaranteed throughput.

Q6: What does the BGP community 7224:9100 versus 7224:9300 do on a Direct Connect Public VIF?

These are AWS-managed scope communities that control how far AWS propagates a customer's prefix advertisement on a Public VIF. 7224:9100 keeps the advertisement local to the AWS region the DX connection terminates in — AWS does not propagate the prefix to other regions. 7224:9200 propagates within the continent (e.g., all North America regions). 7224:9300 propagates globally — the default. Use 7224:9100 when a customer's prefix should be reachable only from a specific region (e.g., a regulated workload that must not be reachable from outside a country). Use 7224:9300 when the customer wants global accessibility through AWS's backbone.

Q7: What is the difference between Direct Connect Private VIF, Public VIF, and Transit VIF in terms of BGP behavior?

Private VIF establishes BGP between customer and a Virtual Private Gateway in a specific VPC. AWS advertises the VPC's CIDR (or DXGW-associated VPC CIDRs); customer advertises on-prem prefixes. Limited to 100 prefixes received from customer. Public VIF establishes BGP between customer and AWS's edge for public AWS services. AWS advertises all public AWS service prefixes (the entire AWS public IP space); customer can advertise their own public prefixes. Limited to 1000 prefixes received from customer. Scope communities (7224:9100/9200/9300) are useful here. Transit VIF establishes BGP to a Direct Connect Gateway, which fans out to multiple Transit Gateways across regions. Behaves like Private VIF semantically but supports multi-region multi-VPC connectivity through DXGW + TGW. The exam tests recognising which VIF type is right for a scenario.

Q8: How does BGP route summarisation help me stay within prefix limits?

Direct Connect Private VIF accepts max 100 prefixes from customer. If customer has 200 specific /24s on-premises, BGP session breaks after limit exceeded. Solution: configure customer router to summarise specific routes into less-specific aggregates before advertising. For example, sixteen /24s in 10.5.0.0/24 through 10.5.15.0/24 can be summarised into one /20 (10.5.0.0/20). 200 /24s can become ~12 /20s, well within the 100 limit. Summarisation is configured on the customer side via BGP aggregate-address or platform-specific commands. Trade-off: summarisation hides longer-prefix routes, so traffic destined to 10.5.99.99 (in 10.5.96.0/20) goes via the same path as 10.5.5.5; you lose path diversity for sub-summary prefixes. AWS does not summarise advertised routes automatically — that is the customer's responsibility.

Q9: What happens to BGP routing when one side of a BGP session is over BFD timeout?

BFD detects link failure (typically 900 ms with default parameters), then triggers an immediate BGP NOTIFICATION to tear down the session. The router clears all routes received from that session and reconverges. With redundant paths configured (a second DX or VPN), traffic shifts via BGP best-path selection to the surviving path within a second. Without BFD, the BGP session would remain up until hold-time expires (90 seconds default), during which traffic to the failed path would black-hole. BFD is the difference between sub-second and 90-second outages on physical link failures. Configure BFD on every production BGP session.

Q10: What is the AWS-recommended pattern for active/active hybrid connectivity to maximise availability?

Two Direct Connect connections from two distinct Direct Connect locations (different physical sites), each with redundant fibre to the on-premises network. Both connections advertise identical prefixes with identical BGP attributes — equal-cost. AWS uses ECMP (when via TGW) or single-best-path (when via VGW). BFD enabled on both. Each connection terminates on a different customer router for full resilience. Add a Site-to-Site VPN as tertiary backup over the public internet, with AS-PATH prepended by 4-5 to ensure it is used only when both DXes fail. Expected availability with this design: 99.99 percent for the hybrid path. AWS Well-Architected Reliability Pillar describes this exact pattern as the gold standard for tier-1 hybrid connectivity. ANS-C01 questions that mention "tier-1 mission-critical hybrid" expect dual-DX + VPN tertiary as the answer.

Further Reading

• Direct Connect Routing Policies and BGP Communities
• Site-to-Site VPN Routing Options
• BFD on Direct Connect
• Transit Gateway Connect Attachments
• AWS Hybrid Connectivity Whitepaper
• RFC 4271 — A Border Gateway Protocol 4 (BGP-4)
• AWS ANS-C01 Exam Guide

BGP is the routing protocol; the next layer is Direct Connect VIF types and physical layer design for the connections that carry BGP, Site-to-Site VPN with BGP for cheaper hybrid connectivity, Transit Gateway routing for the multi-VPC fabric BGP advertisements feed into, and VPC routing primitives for how propagated routes ultimately become forwarding decisions inside subnet route tables.

• Direct Connect — VIF Types, LAG, MACsec, and BGP Design
• VPN — Site-to-Site, Client VPN, and ECMP
• Transit Gateway — Routing Tables, Attachments, and Connect
• VPC Routing — Longest Prefix Match, Propagation, and Blackhole Routes