examlab .net The most efficient path to the most valuable certifications.
Support
In this note ≈ 27 min

Direct Connect — VIF Types, LAG, MACsec, and BGP Design

5,400 words · ≈ 27 min read ·

ANS-C01 Domain 1.5 deep dive into AWS Direct Connect: dedicated vs hosted connections, three VIF types (private, public, transit), Direct Connect Gateway with 10-VGW limit, Link Aggregation Groups (LAG with LACP), MACsec layer-2 AES-256-GCM encryption requirements.

Do 20 practice questions → Free · No signup · ANS-C01

Direct Connect on ANS-C01 is the heaviest, deepest topic in Domain 1 — and the highest-yield. The Network Engineer Specialty exam is full of "you have a 100 Gbps dedicated Direct Connect connection at one location, a 10 Gbps dedicated at a second location, MACsec required by audit, three regions to access, 5 VPCs in each region, BGP active/active with ECMP, SiteLink for direct on-prem-to-on-prem traffic, and a Site-to-Site VPN tertiary backup — design the layer-1 through layer-4 details in 60 seconds". That is a Network Engineer's bread-and-butter problem and ANS-C01 routinely tests every layer of it: dedicated vs hosted connection economics, the three VIF types (private, public, transit) and their reach, Direct Connect Gateway's 10-VGW limit, LAG with LACP and minimum-active-links, MACsec at layer 2 with CAK/CKN keys, BGP eBGP with MD5, BGP communities 7224:7100/7200/7300 for AWS-side preference, BFD sub-second failover, and SiteLink for cross-on-prem transit.

This topic is Domain 1 (Network Design, 30 percent of the exam) Task Statement 1.5 in its entirety. The official ANS-C01 exam guide lists the knowledge bullets verbatim: "Routing fundamentals (dynamic vs static, BGP)", "Layer 1 and layer 2 concepts for physical interconnects (VLAN, LAG, optics, jumbo frames)", "Encapsulation and encryption technologies (GRE, IPsec)", "Resource sharing across AWS accounts", and "Overlay networks". The skills push you to design redundant hybrid connectivity, design BGP routing with attributes, and design SD-WAN integration. Roughly 8 to 12 of the 65 exam questions touch this territory — the heaviest topic in Domain 1.

Why Direct Connect Is the Specialty Exam's Most-Tested Service

Direct Connect is the layer-1 and layer-2 differentiator that justifies a Network Engineer Specialty cert. Generalist architects can talk about VPN as a hybrid option, but Direct Connect requires understanding optics (10 GBASE-LR vs 100 GBASE-LR4), LACP for link aggregation, MACsec for layer-2 encryption, BGP communities for regional preference, BFD for sub-second failover, and the difference between Public, Private, and Transit VIFs at a depth no architect cert reaches. The exam tests this because real-world Network Engineers in regulated industries — banks, telcos, healthcare — own these decisions and the AWS Specialty cert is meant to certify them.

The mental model the exam rewards is "the Direct Connect connection is the physical highway; VIFs are the lanes; BGP is the GPS; MACsec is the armoured truck". Pick the right physical layer (port speed, location), the right VIF for the destination (public for AWS public services, private for one VPC, transit for many VPCs via TGW), the right BGP attributes for traffic engineering, and the right encryption layer (MACsec at L2 if available, IPsec over Public VIF if not). ANS-C01 will reward this layered thinking with full-credit answers; candidates who think of Direct Connect as "fast VPN" will be punished on every distractor.

Plain-Language Explanation: Direct Connect — VIFs, LAG, MACsec, and BGP

Direct Connect combines physical connections (dedicated or hosted), virtual interfaces (three types), Direct Connect Gateways for multi-region/multi-VPC fan-out, LAG for bandwidth aggregation, MACsec for layer-2 encryption, and BGP for dynamic routing. Three analogies anchor the moving parts.

Analogy 1: The Private Railway Line

Think of Direct Connect as a private railway line between your warehouse (data center) and an Amazon distribution hub.

The dedicated connection is your own private railway — you own the rails, you own the locomotives, and you control which trains run. Available in 1 Gbps, 10 Gbps, and 100 Gbps speeds. The hosted connection is a shared railway with reserved cars — a Direct Connect Partner owns the underlying infrastructure and gives you a slice (50 Mbps to 10 Gbps), at lower cost but with less control.

The Virtual Interfaces (VIFs) are the train types running on the line:

  • Private VIF is the express train to one specific Amazon warehouse (one VPC via VGW, or via DXGW to multiple VPCs).
  • Public VIF is the mail train carrying letters to all Amazon-public addresses (S3, DynamoDB, public service IPs) without entering the warehouse.
  • Transit VIF is the multi-warehouse cargo train that delivers to a transit hub (DXGW + TGW) which then fans out to dozens of warehouses across multiple regions.

The LAG (Link Aggregation Group) is two parallel rail tracks bundled — if one track is under maintenance, the other carries the load; together they carry double the trains.

MACsec is the armoured rail car with steel-encased rails — every car carries cargo encrypted at the rail-level (AES-256-GCM at layer 2), so even if a saboteur taps the rail, they read only ciphertext.

BGP is the railway switching system — dynamically routing trains based on track availability, congestion, and signal communications (BGP UPDATE messages).

BGP communities are the train-routing tags painted on each car — community 7224:7100 means "regional priority", 7224:7200 means "continental", 7224:7300 means "global".

BFD (Bidirectional Forwarding Detection) is the track-condition sensors at every kilometre — detecting rail breaks in sub-second time, signaling immediate train re-route.

SiteLink is the cross-warehouse delivery service — using the AWS rail network to ship goods directly between two of your warehouses (on-prem to on-prem) without entering an Amazon warehouse (VPC) at all.

Analogy 2: The Office Building With Multiple Phone Trunk Lines

A Direct Connect connection is a dedicated phone trunk line from your office to the telephone company's central office. The dedicated connection is your own line; the hosted connection is a leased extension on a partner's line.

VIFs are the phone numbers/extensions assigned to the trunk:

  • Private VIF is the direct extension to one specific Amazon office (VPC).
  • Public VIF is the operator-routed line that can call any public Amazon service (S3, DynamoDB).
  • Transit VIF is the conference call hub line that can connect to multiple Amazon offices across cities.

LAG is two trunk lines bonded together — bandwidth doubles, single-link failure is recoverable.

MACsec is the encrypted phone scrambler at both ends of the trunk line — AES-256-GCM at layer 2.

BGP is the phone routing protocol that learns which extensions are reachable.

SiteLink is the direct office-to-office calling through the telephone company's backbone, without going through the Amazon office.

Analogy 3: The Power Grid

Direct Connect is a dedicated high-voltage power line from your facility to the AWS power substation.

The connection is the physical line (1/10/100 Gbps = volt-amp capacity). Dedicated is owning your own transmission line; hosted is leasing a slice of a partner's.

VIFs are the power circuits on the line — Private VIF feeds one substation (VPC), Public VIF feeds the public grid (AWS public services), Transit VIF feeds the regional power router (DXGW + TGW).

LAG is redundant parallel lines for capacity and fault-tolerance.

MACsec is the encrypted-signal-coupling on the line — AES-256-GCM, line-rate.

BGP is the grid management protocol that learns which substations are reachable.

SiteLink is the inter-facility power transmission between your two facilities through the AWS grid backbone.

For ANS-C01, the private railway is the highest-yield mental model when the question mixes VIFs, LAG, BGP, and SiteLink. The phone trunk line is best for the connection-and-VIF distinction. The power grid sub-analogy makes MACsec and capacity-vs-redundancy decisions intuitive. Reference: https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html

Direct Connect Fundamentals — Dedicated vs Hosted

A Direct Connect connection is a physical fibre cross-connect between your equipment in a Direct Connect location (a colocation facility, e.g. Equinix DC1, Telehouse North) and AWS-owned routers in the same building. Two flavours: dedicated and hosted.

Dedicated connection

You own the AWS-side port at the Direct Connect location. Bandwidths: 1 Gbps, 10 Gbps, 100 Gbps. You order via the AWS console, AWS provides a Letter of Authorization (LOA), and the colocation provider (Equinix, etc.) runs a fibre patch from AWS's cage to yours.

Pros: full control of your port, supports MACsec (10/100 Gbps only), supports multiple VIFs (up to 50 per port), supports LAG aggregation. Cons: higher cost (port-hour fees), customer responsible for the colo space at the DX location and the fibre patch.

Hosted connection

A Direct Connect Partner owns the AWS-side port and provisions virtual sub-channels for customers. Bandwidths: 50 Mbps, 100 Mbps, 200 Mbps, 300 Mbps, 400 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps, 10 Gbps. Partners include Megaport, Equinix Cloud Exchange Fabric, Verizon, AT&T, NTT, etc.

Pros: lower cost, no colo space required, faster to provision (Partner handles physical layer). Cons: limited to one VIF per hosted connection, MACsec not supported on hosted (a hard rule), capacity is shared with other Partner customers (though virtually segmented).

When to pick which

  • Hosted for <10 Gbps requirements with no MACsec need, fast time-to-deploy, or no colo presence.
  • Dedicated for 10/100 Gbps capacity, MACsec compliance, LAG bundling, or multi-VIF requirements.

A frequent ANS-C01 distractor: a scenario describes a 1 Gbps hosted connection with a regulatory MACsec requirement. The answer is NOT to enable MACsec on the hosted — it is to upgrade to a 10 Gbps dedicated connection (or higher) at a MACsec-capable DX location. Hosted connections inherently do not support layer-2 encryption because the underlying port is shared. Reference: https://docs.aws.amazon.com/directconnect/latest/UserGuide/MACsec.html

The Three Virtual Interfaces — Private, Public, Transit

A Direct Connect connection carries one or more Virtual Interfaces (VIFs). Each VIF is a VLAN-tagged sub-channel with its own BGP session. ANS-C01 expects you to know all three types in detail.

Private VIF

A Private VIF carries traffic to a single VPC via a Virtual Private Gateway (VGW) or multiple VPCs via a Direct Connect Gateway (DXGW). The on-premises IP space is advertised to AWS via BGP; AWS advertises the VPC's CIDR back.

  • VGW attachment: legacy single-VPC pattern. One VGW per VPC.
  • DXGW attachment: modern multi-VPC pattern. One DXGW can attach to up to 10 VGWs across multiple regions and accounts.

Use Private VIF for: accessing private VPC resources (EC2, RDS, internal ALB) from on-prem.

Public VIF

A Public VIF carries traffic to AWS public service IPs — S3, DynamoDB, public ALB IPs, EC2 public IPs, public Lambda function URLs. The on-premises router learns AWS's public IP prefixes via BGP and routes to them via the cross-connect (private path) instead of the internet.

Use Public VIF for: bulk S3 transfer that needs guaranteed bandwidth, regulatory requirements that forbid internet transit even to AWS-owned IPs, or accessing public services without VPC endpoints.

Public VIF advertises ALL AWS public IP ranges to your router — meaning your router learns thousands of routes covering every AWS region's public IPs. Filter on your side if needed.

Transit VIF

A Transit VIF carries traffic to a Direct Connect Gateway, which then attaches to Transit Gateways in one or more regions. This is the modern multi-VPC, multi-region, multi-account pattern.

  • One DXGW supports 3 Transit VIFs (3 active connections to the DXGW from on-prem).
  • One DXGW attaches to up to 6 TGWs (across regions and accounts).
  • Each TGW then fans out to dozens of VPCs.

Use Transit VIF for: multi-region multi-VPC hybrid connectivity from one or two on-prem locations.

Comparison

Aspect Private VIF Public VIF Transit VIF
Endpoint VGW or DXGW AWS public services DXGW only
Reach One or more VPCs (via DXGW) All AWS public IPs Multiple TGWs / VPCs
BGP advertisement direction Bidirectional, customer's CIDR ↔ VPC CIDR AWS pushes all public prefixes; customer pushes own public prefixes Bidirectional, customer's CIDR ↔ TGW CIDRs
Use case Private VPC access Public AWS service over private path Multi-region multi-VPC
Encryption needed beyond DX? Optional IPsec over private (rare) IPsec over Public VIF for full encryption Optional

A subtle ANS-C01 trap: candidates enable a Public VIF and are surprised when their on-prem router's BGP RIB explodes with thousands of routes (every AWS region's public IP block). Public VIF inherently advertises all AWS public prefixes globally — that's the whole point, since you might want to reach S3 in any region. The fix is on the customer side: BGP route filters on the on-prem router to accept only the regions you care about. Reference: https://docs.aws.amazon.com/directconnect/latest/UserGuide/WorkingWithVirtualInterfaces.html

Direct Connect Gateway — Multi-Region Fan-Out

A Direct Connect Gateway (DXGW) is a global resource (not regional) that aggregates Private and Transit VIFs and connects them to VGWs (one VGW per VPC) or TGWs (one TGW per region).

DXGW with VGWs (Private VIF)

A single DXGW can attach to up to 10 VGWs across regions and accounts. Each VGW is associated with one VPC. So with one Private VIF, you can reach up to 10 VPCs via DXGW. Useful for organisations with a small number of regional VPCs.

DXGW with TGWs (Transit VIF)

A single DXGW can attach to up to 6 TGWs. Each TGW fans out to many VPCs. So with one Transit VIF, you can reach 6 × N VPCs (where N is the per-TGW VPC count). This is the canonical pattern for large enterprise networks.

DXGW limitations

  • DXGW does NOT route between attached VGWs or TGWs (it is non-transitive at the gateway level).
  • DXGW does NOT support overlapping CIDRs across attached VGWs (they must be unique).
  • TGW peering is NOT supported over DXGW — to connect TGWs across regions, use TGW inter-region peering.
  • Public VIFs cannot attach to DXGW; only Private and Transit VIFs.

Multi-account DXGW

A DXGW in account A can be associated with VGWs/TGWs in account B via AWS RAM (sharing the DXGW or DXGW association proposal). The on-prem connection bills the account that owns the DX connection.

A Link Aggregation Group bundles multiple Direct Connect connections into a single logical connection using IEEE 802.3ad LACP (Link Aggregation Control Protocol).

LAG benefits

  • Bandwidth aggregation: 2× 10 Gbps = 20 Gbps logical.
  • Resilience: one connection failure doesn't tear down the LAG; LACP fails over to remaining links.
  • Single management endpoint: VIFs sit on the LAG, not on individual connections.

LAG requirements

  • All connections in the LAG must be the same speed (all 10 Gbps or all 100 Gbps; no mixing).
  • All connections must be in the same Direct Connect location (same colo facility).
  • Maximum 4 connections per LAG for dedicated; 2 for hosted-LAG (a hosted LAG is a Partner offering).
  • All connections owned by the same AWS account.

A LAG has a minimum-active-links parameter (1 to 4). If the LAG has fewer than minimum-active-links operational, the entire LAG is declared down. This prevents a degraded LAG from carrying load while signaling false confidence — better to fail over to a backup LAG cleanly. Typical setting: 1 (any single link keeps LAG up) for max availability, or 2 (need at least 2 links) if 1 link's bandwidth is insufficient.

LAG and MACsec

MACsec runs on the physical connections within the LAG, not at the LAG layer. Each member connection negotiates MACsec independently. All members must have MACsec configured for the LAG to enforce encryption end-to-end.

A frequent ANS-C01 distractor: a candidate proposes a "diverse LAG" with one member at DC1 and another at DC2 for geographic redundancy. AWS does NOT support this — LAG members must be in the same DX location. For geographic redundancy, use two separate Direct Connect connections at different DX locations, each with its own VIF and BGP session, and use BGP attributes (AS-PATH prepend) to control active/passive vs active/active. Reference: https://docs.aws.amazon.com/directconnect/latest/UserGuide/lags.html

MACsec — Layer 2 Encryption at Line Rate

MACsec (IEEE 802.1AE) encrypts ethernet frames at layer 2 with AES-256-GCM at line rate (no CPU overhead on the wire). On Direct Connect, MACsec encrypts the entire physical link from the customer router to the AWS DX router.

Why MACsec instead of IPsec

  • Line-rate: AES-256-GCM in hardware, no perf hit at 10/100 Gbps.
  • Layer 2: encrypts every frame including ARP, BPDU, LACP, and BGP traffic. IPsec (layer 3) only encrypts IP payload.
  • Stateless on the wire: no IPsec tunnel setup, no rekey storms.
  • Simpler operationally: just configure CAK/CKN on both ends.

Requirements

  • Dedicated connection at 10 Gbps or 100 Gbps. Hosted is NOT supported.
  • MACsec-capable Direct Connect location (most are; check the AWS documentation list).
  • MACsec-capable customer router supporting IEEE 802.1AE-2006 with GCM-AES-256 cipher suite.
  • Pre-shared CAK (Connectivity Association Key) and CKN (Connectivity Association Key Name) configured on both ends.
  • Static MAC addresses on the customer router (recommended).

Key management

The CAK/CKN can be:

  • Pre-shared by the operator (manual configuration on both routers).
  • AWS Managed via KMS — AWS generates the CAK and stores in KMS; the customer-side router fetches via API.

MACsec scope of protection

MACsec encrypts only the dedicated cross-connect from customer router to AWS DX router. Beyond the AWS DX router, traffic is on the AWS backbone (private but not MACsec-encrypted). End-to-end encryption from customer to a specific VPC instance still requires application-layer TLS or layered IPsec.

When MACsec is required

  • Regulatory compliance mandating layer-2 encryption (HIPAA, certain financial regimes).
  • Audit requirements for "encrypted dedicated link".
  • Insurance / contractual obligations specifying line-rate encryption.

For most enterprise hybrid scenarios, MACsec is overkill — IPsec over Public VIF or VPN-over-DX provides sufficient confidentiality without the dedicated 10/100 Gbps requirement.

A subtle ANS-C01 distinction: MACsec encrypts only the dedicated cross-connect, not the path beyond AWS's edge router. Within AWS, Direct Connect Gateway and TGW backbone traffic is on the AWS private network — private but not MACsec-encrypted. For end-to-end encryption, you still need application-layer TLS or a layered IPsec VPN over the Direct Connect. Reference: https://docs.aws.amazon.com/directconnect/latest/UserGuide/MACsec.html

BGP on Direct Connect — The Required Routing Protocol

BGP on Direct Connect is mandatory — there is no static-routing option. The Network Engineer Specialty exam expects deep BGP fluency.

BGP setup

Each VIF has its own BGP session with these parameters:

  • Customer ASN: your private (64512–65534) or public ASN.
  • AWS ASN: assigned by AWS (e.g. 64512 or 7224 for some VIF types).
  • BGP MD5 authentication password: shared secret on both ends.
  • Customer router peer IP: the on-prem router's IP on the cross-connect link.
  • AWS peer IP: AWS's IP on the cross-connect link.
  • VLAN tag: 1 to 4094, identifies the VIF.

BGP peering IPs

  • For Private/Transit VIFs: customer-supplied IPs from a /30 or /29 range (you choose).
  • For Public VIFs: customer-supplied publicly routable IPs (you must own them).

BGP timers

Default Direct Connect BGP timers: keepalive 30 seconds, hold-time 90 seconds. Industry default is keepalive 60 / hold-time 180 — AWS is more aggressive for faster convergence. Tunable but not commonly changed.

BFD for sub-second failover

Bidirectional Forwarding Detection (BFD) is a sub-second failure-detection protocol that runs alongside BGP. With BFD enabled, link failure is detected in 300ms by default (configurable lower). Without BFD, BGP holdtime (90s) controls failover — too slow for production.

BFD is supported on Direct Connect and is the canonical answer for "improve failover time on a BGP session". Both ends must have BFD configured; AWS enables BFD per-VIF on request.

  • eBGP: external BGP between two distinct ASs (customer and AWS).
  • ASN: Autonomous System Number — customer can use private (64512–65534) or public.
  • MD5 authentication: shared-secret hash protecting BGP sessions from spoofing.
  • AS-PATH prepending: artificially lengthen AS-PATH to influence inbound traffic.
  • LOCAL_PREF: AWS's internal preference; customer cannot directly set, but can influence via BGP communities (7224:7100/7200/7300).
  • MED (Multi-Exit Discriminator): customer-set attribute that AWS uses for ingress preference.
  • BFD: Bidirectional Forwarding Detection, sub-second BGP failover.
  • Reference: https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html

BGP Communities for Direct Connect

AWS publishes BGP community values that customers can attach to advertisements to influence AWS-side routing decisions.

Scope communities (7224:7100/7200/7300)

When the customer attaches one of these communities to advertised prefixes:

  • 7224:7100 — Local preference: AWS prefers paths within the same region to reach this prefix.
  • 7224:7200 — Continental preference: AWS prefers paths within the same continent.
  • 7224:7300 — Global preference: AWS prefers paths globally (default).

Use case: a customer with two Direct Connects, one in us-east-1 and one in eu-west-1. They tag the eu-west-1 prefix with 7224:7100 (regional) so AWS-to-EU traffic prefers the EU connection over the US connection.

NO_EXPORT and NO_ADVERTISE

Standard BGP communities:

  • NO_EXPORT: AWS will not advertise this prefix beyond the immediate eBGP peer (your router) — useful to limit prefix scope.
  • NO_ADVERTISE: even more restrictive, this prefix is not advertised at all beyond the receiving router.

These let customers prevent AWS from re-advertising their prefixes through other AWS-owned BGP relationships.

AWS-advertised prefixes (Public VIF)

On Public VIFs, AWS advertises its public IP prefixes to the customer with these AWS-set communities:

  • 7224:9100: prefix is local to the same DX region.
  • 7224:9200: prefix is in a different region of the same continent.
  • 7224:9300: prefix is on a different continent.

The customer's BGP router can filter advertisements by community to receive only relevant ones (e.g. accept only 7224:9100 to limit RIB size).

A subtle ANS-C01 trap: candidates assume tagging a prefix with 7224:7100 affects on-prem routing decisions. It does NOT — the community influences AWS's preference for paths to that prefix. Customer-side routing decisions are governed by the customer's own LOCAL_PREF and MED settings, opaque to AWS. Memorise: 7224:* communities are AWS-only knobs that the customer can set to nudge AWS's choice. Reference: https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html

Redundancy Models — Dual-Location, LAG + Backup, DX + VPN

Tier 1 Maximum Resilience: Dual-DX-Location

Two completely separate Direct Connect connections at two different DX locations, with separate fibre paths, separate physical buildings, and separate ISP / carrier paths to your on-prem. BGP active/active or active/passive between them, controlled by AS-PATH prepending and LOCAL_PREF. This is the AWS-recommended pattern for tier 1 production hybrid.

Tier 2 High Resilience: LAG + Redundant LAG

Two LAGs at two DX locations. Each LAG is itself a bundle of 2–4 connections. This provides bandwidth aggregation within each location and geographic redundancy across locations.

Tier 3 Standard Resilience: DX + Site-to-Site VPN backup

One Direct Connect connection (single point of failure on physical layer) plus a Site-to-Site VPN over the public internet as backup. Site-to-Site VPN is much cheaper than a second DX connection but introduces internet-path variability. BGP path-selection ensures DX is preferred when up; VPN takes over on DX failure.

Active/active vs active/passive

  • Active/active with ECMP (Equal-Cost Multi-Path): both DX connections carry traffic concurrently; BGP advertisements are equal-weight; load is balanced via 5-tuple hash.
  • Active/passive with AS-PATH prepend on backup: one DX is preferred (shorter AS-PATH); the other only carries traffic if the primary fails.

ECMP requires identical advertisements on both paths and is the throughput-maximising pattern. Active/passive is simpler to reason about and the typical exam answer for "primary DX with VPN backup".

Failover testing

A frequent ANS-C01 question: how do you test DX failover without disrupting production? Answer: shut down the BGP session on the primary DX (or block at the DX router). Traffic should fail over to the backup. Test during a maintenance window with traffic shadowing if possible.

SiteLink — On-Prem-to-On-Prem Over the AWS Backbone

AWS Direct Connect SiteLink lets two on-prem locations connected to AWS via Direct Connect send traffic directly to each other through the AWS backbone, without the traffic entering a VPC.

Pre-SiteLink, on-prem-to-on-prem traffic via AWS required: site A → DX VIF → DXGW → TGW or VGW in a VPC → TGW or VGW back out → DXGW → site B. This is a "VPC hairpin" that wastes data-transfer cost and adds latency.

SiteLink eliminates the VPC: site A → DX VIF (with SiteLink enabled) → AWS backbone → DX VIF at site B. Direct.

Requirements

  • Both DX connections must be in the SiteLink network.
  • Both VIFs must have SiteLink enabled (per-VIF flag).
  • SiteLink-eligible regions only.
  • Per-GB SiteLink transfer fee applies.

Use cases

  • Multi-DC enterprise with two data centres in different regions, both connected to AWS — SiteLink enables direct DC-to-DC transit through AWS rather than over their own WAN.
  • Multi-cloud connectivity from on-prem to a different cloud (Azure ExpressRoute connected via a partner peering at an AWS DX location).

Limitations

  • SiteLink is for traffic between on-prem locations only; does not affect VPC-to-on-prem traffic.
  • SiteLink uses BGP for route propagation; static routing is not supported.
  • Bandwidth is bound by the slower of the two DX connections.

Common Traps Recap — Direct Connect on ANS-C01

Trap 1: MACsec works on hosted connections

Wrong. MACsec is dedicated 10/100 Gbps only.

Trap 2: LAG members can be in different DX locations

Wrong. LAG members must be in the same DX location.

Trap 3: Public VIF advertises only your VPC's CIDR

Wrong. Public VIF advertises all AWS public IP prefixes to the customer.

Trap 4: Transit VIF works with VGW

Wrong. Transit VIF requires DXGW, which then attaches to TGW. VGW is only with Private VIF.

Trap 5: BGP is optional on Direct Connect

Wrong. BGP is required; static routing is not supported.

Trap 6: BGP communities affect customer-side routing

Wrong. 7224:* communities affect AWS-side routing only.

Trap 7: DXGW supports overlapping VPC CIDRs

Wrong. No overlapping CIDRs allowed across DXGW-attached VGWs/TGWs.

Trap 8: TGW peering works over DXGW

Wrong. TGW peering uses TGW inter-region peering, not DXGW.

Trap 9: BFD is enabled by default on Direct Connect BGP

Wrong. BFD requires explicit configuration on both ends and per-VIF AWS configuration.

Wrong. SiteLink eliminates the VPC hairpin entirely.

Trap 11: A single DX connection at one location is highly available

Wrong. One DX = single point of failure. AWS recommends dual-location for tier 1.

Trap 12: MACsec encrypts traffic end-to-end through AWS

Wrong. MACsec encrypts only the dedicated cross-connect.

FAQ — Direct Connect on ANS-C01

Q1: When should I pick a hosted connection vs a dedicated connection?

Pick hosted when (a) bandwidth need is below 10 Gbps and there's no MACsec requirement, (b) you don't have or want colo presence at a Direct Connect location, (c) time-to-deploy is critical (Partners can provision in days vs weeks for dedicated), (d) capital cost is a concern. Pick dedicated when (a) you need 10 or 100 Gbps, (b) MACsec layer-2 encryption is required, (c) you need LAG bundling, (d) you need multiple VIFs (50 per dedicated port), (e) regulatory compliance demands a private port. ANS-C01 typically scenarios at 10+ Gbps with MACsec or LAG — that forces dedicated.

Q2: How do I architect dual-region Direct Connect with regional preference?

Provision two Direct Connect connections, one near us-east-1 (e.g. DC2-Ashburn) and one near eu-west-1 (e.g. DC1-Dublin). Use Transit VIFs into a single DXGW that attaches to TGWs in both regions. Tag prefixes advertised to AWS with BGP community 7224:7100 (regional) — this tells AWS to prefer paths within the same region. Result: AWS-to-eu-west-1 prefers the Dublin connection; AWS-to-us-east-1 prefers the Ashburn connection. Customer-side, use LOCAL_PREF on the on-prem routers to prefer the appropriate egress path. ANS-C01 will test this exact pattern as the "regional preference with global DXGW" answer.

Q3: What is the difference between a Private VIF, Public VIF, and Transit VIF?

A Private VIF carries traffic to a single VPC via VGW or up to 10 VPCs via DXGW + VGWs. A Public VIF carries traffic to AWS public services (S3, DynamoDB, public ALB IPs) over the private cross-connect, bypassing the internet. A Transit VIF carries traffic to a Direct Connect Gateway, which fans out to up to 6 TGWs across multiple regions and accounts. Reach: Private VIF = single VPC or small fan-out via DXGW; Public VIF = AWS public IPs globally; Transit VIF = many VPCs across regions via TGW. ANS-C01 expects you to pick Transit VIF for any modern multi-VPC multi-region architecture; Private VIF for legacy single-region single-VPC; Public VIF for niche scenarios (regulatory non-internet routing to S3).

Q4: How does BFD improve failover compared to BGP defaults?

Default BGP on Direct Connect uses keepalive 30 seconds, hold-time 90 seconds. Without BFD, a link failure is detected only when 3 missed keepalives accumulate — up to 90 seconds. With BFD enabled, sub-second failure detection (default 300ms, configurable lower). When BFD detects failure, BGP is informed immediately and re-converges. Net effect: failover time drops from ~90 seconds to <1 second. BFD requires explicit configuration on both customer router and AWS side (per-VIF). The Specialty answer for "minimize BGP failover time on Direct Connect": enable BFD on both ends, with default 300ms detection.

Q5: What is MACsec and when do I need it?

MACsec (IEEE 802.1AE) is a layer-2 encryption protocol that encrypts ethernet frames using AES-256-GCM at line rate with no CPU overhead. On Direct Connect, MACsec encrypts the dedicated cross-connect from customer router to AWS DX router. You need it when (a) regulatory compliance mandates layer-2 link encryption (HIPAA, certain financial regimes), (b) audit requires "encrypted dedicated link" without IPsec performance overhead, (c) your data is so sensitive you can't tolerate even physical tampering of the fibre. For most enterprise scenarios, MACsec is overkill — IPsec over Public VIF or Site-to-Site VPN provides equivalent confidentiality. MACsec requires dedicated 10/100 Gbps connection (not hosted), MACsec-capable router, and CAK/CKN key configuration. ANS-C01 will reward MACsec for "regulated industry, layer-2 encryption mandatory" and reward IPsec/TLS for "in-transit encryption" without those keywords.

Q6: How do I architect Direct Connect to multiple AWS regions from one on-prem location?

Use a Transit VIF on a Direct Connect connection terminating at a Direct Connect Gateway. Attach the DXGW to TGWs in each target region (up to 6 TGWs). Each regional TGW fans out to its own VPCs. Result: one physical DX connection + one DXGW = access to 6 regions × dozens of VPCs. Customer-side, the on-prem router learns all regional CIDRs via BGP. AWS-side, prefixes can be tagged with BGP community 7224:7100 for regional preference. Alternatively, for resilience, two DX connections at two DX locations, each with its own Transit VIF into the same DXGW for active/active redundancy.

Q7: When does Site-to-Site VPN make sense as backup to Direct Connect?

VPN-over-internet as DX backup is the standard cost-effective resilience pattern when (a) the workload tier doesn't justify a second DX connection ($XXX/month port-hour fee), (b) brief failover-induced latency increase is acceptable (VPN over public internet may add 30–80ms latency vs DX), (c) the organization wants belt-and-suspenders without doubling DX cost. Architecture: primary DX with eBGP to AWS, secondary VPN with eBGP to the same AWS endpoint (TGW or VGW). AWS prefers DX over VPN naturally because DX is shorter AS-PATH (or use AS-PATH prepend on VPN to be explicit). On DX failure, AWS shifts to VPN within seconds (fast BGP convergence). Compared to dual-DX, the cost savings are significant; the trade-off is variable internet latency during failover.

SiteLink lets two on-premises locations both connected to AWS via Direct Connect send traffic directly to each other through the AWS backbone, without entering any VPC. Pre-SiteLink, on-prem-to-on-prem via AWS required a "VPC hairpin" — traffic enters VPC A, leaves to TGW, exits VPC A back to the other on-prem. This wastes data-transfer cost (charged on both VPC ingress and egress). SiteLink bypasses the VPC entirely. Use cases: (a) two corporate data centres in different regions both connected to AWS, where you want them to talk via AWS rather than your private WAN, (b) extending an MPLS overlay through AWS backbone. Per-GB SiteLink transfer fees apply. ANS-C01 will reward SiteLink for "two on-prem sites talking through AWS without VPC".

Q9: How do I use BGP attributes to engineer traffic on a multi-DX setup?

For inbound to AWS (outbound from on-prem perspective): use AS-PATH prepending on the less-preferred path. AWS sees the longer AS-PATH and prefers the shorter one. Example: DX A is preferred, prepend your ASN twice on DX B's BGP advertisement to AWS — AWS prefers DX A.

For outbound from AWS (inbound to on-prem): use BGP community 7224:7100 (regional) on prefixes you want to receive via the regional DX. AWS prefers paths within the same region matching this community.

For active/active ECMP: ensure both DX connections advertise identical AS-PATH and same prefixes; AWS will load-balance via 5-tuple hash across both paths. Customer-side, configure ECMP on the on-prem router for symmetric outbound balancing.

These are the canonical Specialty exam BGP traffic-engineering knobs: AS-PATH prepend (inbound), BGP communities (outbound), ECMP (active/active).

Q10: What happens if I exceed BGP prefix limits on a Direct Connect VIF?

A Direct Connect VIF accepts a maximum of 100 prefixes advertised from the on-premises router (unless raised via support). If you exceed, the BGP session drops (or AWS sends a NOTIFICATION error message and tears down the session). Recovery requires reducing prefixes (route summarization on the on-prem side) and re-establishing the BGP session. Prevention: monitor advertised prefix count via CloudWatch (custom metric or show ip bgp neighbor summary), aggregate routes at the on-prem router using supernetting (e.g. summarize ten /24s into one /20). AWS does NOT summarize advertised routes from your side automatically. ANS-C01 frequently scenarios this trap: candidate has hundreds of /24 routes from on-prem, BGP session flaps when the count crosses 100. Answer: aggregate routes on the on-prem router.

Once Direct Connect architecture is in place, the natural next operational layers on ANS-C01 are: BGP Configuration — AS-Path Prepending, MED, Communities, and BFD for the routing-attribute deep-dive that traffic-engineers DX paths; VPN — Site-to-Site, Client VPN, and ECMP for the IPsec backup and complementary VPN options; Transit Gateway — Routing Tables, Attachments, and Connect which is the AWS-side fan-out target of Transit VIFs; and Network Encryption — TLS, ACM, IPsec, and MACsec for the cryptographic deep-dive on every layer of the stack.

Official sources

More ANS-C01 topics