AWS Direct Connect

By the end of this lesson you will be able to

• Explain what AWS Direct Connect is physically (a line, a Direct Connect location, a cross-connect) and logically (virtual interfaces, each a VLAN with its own BGP session), and why companies pay for it instead of a VPN.
• Choose between a dedicated and a hosted connection, and know what each allows: speeds, how many virtual interfaces, capacity changes, MACsec, LAGs.
• Pick the right virtual interface: private, public or transit, and say where each one ends.
• Use a Direct Connect gateway to reach VPCs in many Regions and accounts through one virtual interface, and explain what it will never do.
• Encrypt Direct Connect traffic with an IPsec VPN over Direct Connect or MACsec, and say when each fits.
• Design for failure with the three resiliency models and a VPN backup, and steer traffic with BGP (longest prefix, local preference, AS path).
• Estimate the bill (port-hours plus data transfer out) and answer the exam’s Direct Connect scenarios by their keywords.

#Why Direct Connect exists

Lesson 22.4 connected an office to a VPC with a Site-to-Site VPN: encrypted tunnels over the public internet, ready in minutes, cheap, but only as steady as the internet happens to be that day. For many companies that is enough. For some it is not:

• a bank that moves terabytes between its data centre and AWS every night and cannot have the transfer slow down when the internet is busy;
• a stock exchange feed or a call-centre voice platform where latency must be the same at 3 a.m. and at 3 p.m.;
• a regulator who wants critical traffic off the public internet altogether;
• a hybrid system where the database is on-premises and the application servers are in AWS, talking all day.

AWS Direct Connect (DX) is the answer to all of these. It is a dedicated, private network connection from your network to AWS. Your traffic does not cross the internet: your router is connected by cable, usually through a Direct Connect Partner or a colocation building, to an AWS router at a Direct Connect location, and from there the AWS backbone carries it to the Region.

What you get from it:

• Consistent performance: the line is yours (or a slice reserved for you), so bandwidth and latency do not swing with internet traffic.
• High bandwidth: from 50 Mbps up to 400 Gbps per connection, and more with several connections.
• Lower data transfer out price: data leaving AWS over Direct Connect is charged at Direct Connect rates, which are lower than internet rates (details in the pricing section).
• Private and public resources on the same line: VPC private IPs (EC2, RDS) and AWS public endpoints (S3, DynamoDB) through different virtual interfaces.
• IPv4 and IPv6: both run over the same connection.

What you do not get:

• Speed of setup. A Site-to-Site VPN is up in minutes. A new Direct Connect connection often takes more than a month, sometimes several, because someone has to lay or rent fibre and patch cables in a building.
• Encryption. Direct Connect is private, not encrypted. More on that below; it is the most famous exam trap of the topic.

#How a connection is built

#Direct Connect locations and the cross-connect

A Direct Connect location is a colocation data centre (Equinix, Digital Realty, local carriers’ buildings…) where AWS keeps routers in its own locked AWS cage. Each location has an associated Region (Mumbai locations are associated with ap-south-1), but through a Direct Connect gateway you can reach any Region from it.

Inside the building, the link from your side to AWS is a cross-connect: a fibre cable from your cage (or your partner’s cage) to the AWS cage. Three ways to get there:

1. Your router is in the same building. You rent space there and order the cross-connect. Common for big companies.
2. A Direct Connect Partner brings you there. A telecom carrier runs a circuit from your office (the last mile) to its cage in the location, and the cross-connect continues from there. Common in Bangladesh: there is no Direct Connect location inside the country, so a partner carries the circuit to a location in a neighbouring country, such as India or Singapore. Run aws directconnect describe-locations to see the current list.
3. A hosted connection from a partner that already has its own ports there (see the next section).

#Ordering a dedicated connection

1. Request the port

   In the Direct Connect console (or aws directconnect create-connection), choose the location and the port speed: 1, 10, 100 or 400 Gbps.

2. Download the LOA-CFA

   AWS reserves a port on one of its routers and gives you the Letter of Authorization and Connecting Facility Assignment (LOA-CFA). It tells the building operator exactly which AWS port to patch to. It expires after 90 days: if the cross-connect is not done by then, you download a new one.

3. Get the cross-connect and the last mile

   You (or your partner) give the LOA-CFA to the building, which runs the cross-connect; the partner completes the circuit to your premises. This is where most of the weeks go.

4. Bring the link up

   When light flows both ways, the connection state becomes available. Nothing is routed yet.

5. Create virtual interfaces

   Create a private, public or transit virtual interface (next sections). Each one is a VLAN with its own BGP session. When BGP is up, routes are exchanged and traffic flows.

#What your router must support

• Single-mode fibre and the right optics for the port speed (1, 10, 100 or 400 Gbps Ethernet).
• 802.1Q VLAN tagging, because every virtual interface is a VLAN on the same cable.
• BGP, with an optional authentication key. AWS’s side uses the ASN of the virtual private gateway or Direct Connect gateway (Amazon default 64512) for private and transit VIFs, and 7224 for public VIFs.
• BFD (Bidirectional Forwarding Detection) is optional but recommended: AWS enables it on its side, you enable it on your router, and a dead link is noticed in under a second instead of after BGP’s 90-second hold timer.
• MTU: 1500 by default; a private VIF supports jumbo frames of 9001 bytes and a transit VIF 8500 bytes.

The “BGP down” scenario in the animation is a real first-day failure. A private or transit virtual interface accepts 100 prefixes per address family from your side by default. Advertise more and AWS puts the BGP session into idle: the cable is fine, but nothing is routed. Summarise your routes, or raise the limit (up to 1,000) with prefix controls. Over a public VIF AWS advertises its public prefixes to you, and you may advertise up to 1,000 of your own.

#Connection types: dedicated or hosted

#Link aggregation groups (LAGs)

A LAG bundles several dedicated connections into one logical connection, so you configure virtual interfaces once and get more bandwidth. Rules:

• all connections have the same speed and end on the same AWS device at one location;
• at most four connections below 100 Gbps, or two at 100 or 400 Gbps;
• all links are active/active;
• a minimum links setting (default 0) makes the whole LAG go down when fewer members are left, so a half-dead LAG does not overload its survivors while a backup path stands ready;
• MACsec can be enabled on the whole LAG with one key.

A LAG adds bandwidth, not resilience against a location failure: everything is in one building on one device. For that you need the resiliency models below.

#Virtual interfaces: what you can reach

A connection is just a pipe. A virtual interface (VIF) decides where traffic goes. Each VIF is an 802.1Q VLAN with its own BGP session, and one dedicated connection can carry many of them side by side. Three kinds:

Points worth remembering:

• A private VIF cannot reach S3, because S3 is not inside your VPC. Use a public VIF, or an S3 interface endpoint in the VPC reached over the private VIF (lesson 10.10, lesson 22.2). A gateway endpoint never works from on-premises.
• A public VIF is not an internet connection. AWS does not carry you on to the internet, and it does not re-advertise your prefixes to other customers. It does advertise all its public prefixes, from every Region, tagged with BGP communities; filter them on your router (for example accept only 7224:8100, the local Region) if you do not want your whole AWS traffic to shift onto the line.
• One VGW per VPC, but one connection can carry several private VIFs to several VGWs in the location’s Region.
• Hosted VIFs: the owner of a dedicated connection can create a VIF and hand it to another account (for example a network account serving an application account).
• Hybrid DNS runs over the same VIFs: on-premises servers resolve AWS private names through Route 53 Resolver inbound endpoints, and VPCs resolve on-premises names through outbound endpoints (lesson 8.5).

#Direct Connect gateway

#The problem it solves

Without help, a private VIF ends on one VGW, and that VGW must be in the associated Region of the Direct Connect location. A company with VPCs in Mumbai, Singapore and Frankfurt would need lines into three locations, or at least three sets of VIFs to manage.

A Direct Connect gateway (DXGW) is a global object. You attach a private VIF (or a transit VIF) to it once, then associate it with VGWs (up to 20) or transit gateways (up to 6) in any AWS Region except the China Regions, in your account or in other accounts. One VIF, one BGP session, and the data centre learns the prefixes of every associated VPC.

#What it will not do

• No VPC-to-VPC routing. The gateway connects on-premises to the VPCs. Associations on the same gateway cannot send traffic to each other: VPC A cannot use it to reach VPC B. Use VPC peering (22.1) or a transit gateway (22.6). One edge case: if you advertise a supernet such as 10.0.0.0/8 from on-premises that covers the VPCs, packets can hairpin through the Direct Connect location and VPCs can reach each other; advertise specific prefixes (and use security groups) if they must stay apart.
• No overlapping prefixes. The allowed prefixes of its associations must not overlap; plan addresses first (lesson 3.1).
• Not a data-path box. It is a set of BGP route reflectors outside the traffic path, highly available by design: you never deploy a second one for resilience.

#Across accounts and with a transit gateway

• Cross-account: the VGW or transit gateway owner sends an association proposal; the gateway owner accepts it and can narrow the allowed prefixes.
• With a transit gateway: attach a transit VIF to the gateway and associate the gateway with the transit gateway. Every VPC attached to the transit gateway is then reachable through one VIF. Share the transit gateway with other accounts through AWS RAM (lesson 20.1) and one line serves the whole organisation. The full pattern is in lesson 22.6.

#Encryption: private is not encrypted

This is the trap the notes call the biggest one. People hear “private dedicated line” and assume it is encrypted. It is not. Direct Connect traffic travels as plain text over your fibre, the partner’s circuit and the cross-connect. Anyone who can tap the fibre or a patch panel can read it. (Inside AWS, traffic between Direct Connect locations and Regions is encrypted by AWS at the physical layer, but that does not cover the parts outside AWS.)

Two ways to encrypt:

#Resiliency: designing for a cut cable

A Direct Connect connection is a physical thing. A rat chews a cable, an excavator digging a drain on the airport road cuts the fibre, an AWS router fails, the colocation building loses power or floods. A single connection is a single point of failure. AWS describes three resiliency models (the Direct Connect Resiliency Toolkit in the console orders them for you):

Click your way through them:

Notice what the lab shows: high resiliency survives a location failure but then runs on half the bandwidth with no spare left; maximum resiliency still has two connections, on separate devices, after losing a whole location. That is why “mission critical” or “maximum resiliency” in a question points to two locations and four connections.

#A Site-to-Site VPN as the backup

Maximum resiliency costs four ports, four cross-connects and two partners. The most cost-effective way to make Direct Connect highly available is a Site-to-Site VPN over the internet as the backup: Direct Connect carries traffic normally, the VPN takes over when it fails. Both run BGP, so failover is automatic. Only two questions need answering: which path wins while both are up, and in which direction?

#AWS to your network: AWS decides

For traffic leaving AWS toward your data centre, the VGW (or transit gateway) chooses among the routes it has learned:

1. Longest prefix match first: a /24 beats a /16, whatever link it came from.
2. If the prefixes are the same, a VGW prefers routes learned over Direct Connect to static VPN routes, and those to BGP-learned VPN routes. A transit gateway also ranks Direct Connect gateway routes ahead of VPN routes.
3. Between several VPN connections, the shorter AS path wins, then the lower MED. Among several Direct Connect VIFs you can steer with local preference BGP communities (7224:7100 low, 7224:7200 medium, 7224:7300 high), checked before AS path.

So for the same prefix, AWS already prefers Direct Connect without any work from you. Your job is not to advertise more specific prefixes over the VPN, or the VPN wins by rule 1.

#Your network to AWS: your router decides

For traffic leaving your data centre, your router has learned the VPC prefixes twice, over Direct Connect and over the VPN. Standard BGP decides, and you control it:

• Local preference (checked early): set a higher value, say 200, on routes learned over Direct Connect. The recommended way.
• AS path prepending (checked later): make the VPN path look longer, for example by prepending your own ASN several times on routes learned over the VPN, so the router sees Direct Connect as the shortcut.

Two more details from the animation:

• Keep both directions on the same path. If requests leave on Direct Connect and replies return on the VPN, a stateful firewall in your data centre drops the replies. Advertise the same prefixes on both links and set preferences on both sides.
• Detect failure fast. Without BFD, BGP waits up to its 90-second hold timer before declaring Direct Connect dead. With BFD (300 ms × 3 by default), failover takes about a second.

The backup VPN is a lifeboat: about 1.25 Gbps per tunnel over the internet, with internet latency. A VGW uses one tunnel at a time; on a transit gateway, several VPN connections with ECMP add up (lesson 22.6). If the business cannot live on that during an outage, buy a second Direct Connect connection instead.

#What it costs

Direct Connect has two main charges, plus the partner’s own bill:

• Port-hours: charged for every hour the port is provisioned, whether traffic flows or not. Example prices at most locations: dedicated 1 Gbps $0.30/hour, 10 Gbps $2.25/hour, 100 Gbps $22.50/hour, 400 Gbps $85/hour; hosted 50 Mbps $0.03, 500 Mbps $0.20, 1 Gbps $0.33, 10 Gbps $2.48 per hour.
• Data transfer out: data leaving AWS over Direct Connect, per GB, by source Region and Direct Connect location. Examples: about $0.02/GB from US Regions to US locations, $0.045/GB from Mumbai (ap-south-1) to an India location. Internet data transfer out from ap-south-1 starts at about $0.1093/GB.
• Data transfer in is free.
• MACsec has no extra charge. SiteLink adds an hourly fee per VIF and its own per-GB rates.

Worked example: an analytics platform in ap-south-1 sends 40 TB a month back to the bank’s data centre.

The 5 TB a night flowing into AWS costs nothing either way. Direct Connect pays for itself on heavy outbound traffic, steady performance and compliance, not on inbound uploads. Prices vary by Region and location: check the Direct Connect pricing page (example prices verified November 2026). The whole-chapter cost view is in lesson 22.8.

#Choosing a design

1. Bandwidth and deadline

   Below 1 Gbps → hosted. 1 Gbps and above → dedicated (or a hosted 1–25 Gbps from a qualified partner). Need it this week → start with a Site-to-Site VPN now, order Direct Connect, keep the VPN as the backup later.

2. What it must reach

   One VPC → private VIF to its VGW. VPCs in several Regions or accounts → private VIF to a Direct Connect gateway. Many VPCs → transit VIF + Direct Connect gateway + transit gateway, shared with RAM. S3 and public services → public VIF, or an interface endpoint over the private VIF.

3. Encryption

   Required → IPsec VPN over Direct Connect (standard), or MACsec for dedicated 10/100/400 Gbps at supported locations when you need line rate.

4. Failure

   Mission critical → maximum resiliency (2 locations × 2). Important → high resiliency (2 locations × 1), or one connection plus a VPN backup when cost matters most. Dev and test → two connections in one location, or one plus VPN.

#What goes wrong

• “We have Direct Connect, so it is encrypted.” It is not. Audit fails. Add IPsec over Direct Connect or MACsec.
• The link is up but nothing flows. No virtual interface yet, the VIF’s VLAN or BGP ASN does not match the router, or BGP is idle because you advertised more than 100 prefixes.
• On-premises cannot reach S3 privately. Someone built only a gateway endpoint, or tried to reach S3 over a private VIF. Use an interface endpoint or a public VIF.
• Traffic uses the VPN while Direct Connect is healthy. A more specific prefix is advertised over the VPN, or your router has no local preference and picked the VPN on a tie-break.
• Replies are dropped after failover or failback. Asymmetric paths through a stateful firewall: set preferences on both sides and advertise the same prefixes on both links.
• Failover takes 90 seconds. BFD is not enabled on your router.
• A whole location fails and everything stops. Both connections, or a LAG, were in one building. LAGs add bandwidth, not location resilience.
• VPC A reaches VPC B “through the Direct Connect gateway” after on-premises starts advertising 10.0.0.0/8, or cannot reach it at all when someone expected the gateway to route between them.
• An association fails because two VPCs on the same gateway use the same CIDR.
• The public VIF moves too much traffic onto the line: AWS advertises all its public prefixes, and without filtering every AWS-bound flow, even to other Regions, now prefers the private line.
• The LOA-CFA expired before the building ran the cross-connect: download a new one.
• The hosted connection drops packets at peaks: AWS polices it at the purchased rate.

#How it is used in system design

• Hybrid core: a data centre database with application servers in AWS, connected by Direct Connect with a VPN backup and BFD, so the application sees one network.
• Landing zone networking: a central network account owns the Direct Connect connections, a Direct Connect gateway and a transit gateway shared through RAM; application accounts only attach their VPCs (lesson 22.6).
• Data platforms: on-premises producers stream to AWS over a private VIF and S3 interface endpoints, or over a public VIF for bulk uploads; Direct Connect’s lower data-out rate makes pulling results back affordable.
• Regulated industries: banks and hospitals use maximum resiliency, encryption (IPsec or MACsec) and TLS, and test failover on a schedule.
• Migrations: a VPN on day one, Direct Connect when it arrives, Snowball for the first bulk copy if the line is still too slow (lesson 23.5).

#Try it yourself

Direct Connect ports cost money from the moment they are provisioned and need a real cross-connect, so most readers will only run the read-only commands. Never put a real authentication key in a script.

# 1. Where can I connect? (location codes, names, available port speeds)
aws directconnect describe-locations --region ap-south-1 \
  --query "locations[].[locationCode,locationName,availablePortSpeeds]" --output table

# 2. Request a 10 Gbps dedicated port at a location, with MACsec capability
aws directconnect create-connection --location <location-code> \
  --bandwidth 10Gbps --connection-name dhaka-dx-1 --request-mac-sec

# 3. Download the LOA-CFA for the building operator (base64 PDF in the output)
aws directconnect describe-loa --connection-id dxcon-fg5678gh

# 4. A Direct Connect gateway with the Amazon-side ASN
aws directconnect create-direct-connect-gateway \
  --direct-connect-gateway-name telco-dxgw --amazon-side-asn 64512

# 5. A private VIF on VLAN 101 to that gateway
aws directconnect create-private-virtual-interface --connection-id dxcon-fg5678gh \
  --new-private-virtual-interface '{"virtualInterfaceName":"prod-private","vlan":101,
    "asn":65010,"authKey":"<bgp-auth-key>","addressFamily":"ipv4",
    "directConnectGatewayId":"5f294f92-bafb-4011-916d-9b0bexample","mtu":9001}'

# 6. A transit VIF on VLAN 201 for the transit gateway design
aws directconnect create-transit-virtual-interface --connection-id dxcon-fg5678gh \
  --new-transit-virtual-interface '{"virtualInterfaceName":"tgw-transit","vlan":201,
    "asn":65010,"addressFamily":"ipv4",
    "directConnectGatewayId":"5f294f92-bafb-4011-916d-9b0bexample","mtu":8500}'

# 7. Associate a VGW in another Region with the gateway, limiting what is advertised
aws directconnect create-direct-connect-gateway-association \
  --direct-connect-gateway-id 5f294f92-bafb-4011-916d-9b0bexample \
  --gateway-id vgw-0a1b2c3d4e5f67890 \
  --add-allowed-prefixes-to-direct-connect-gateway cidr=10.2.0.0/16

# 8. Bundle two ports into a LAG (same speed, same location)
aws directconnect create-lag --number-of-connections 2 --location <location-code> \
  --connections-bandwidth 10Gbps --lag-name dhaka-lag

# 9. Check the VIFs and their BGP state
aws directconnect describe-virtual-interfaces \
  --query "virtualInterfaces[].[virtualInterfaceName,virtualInterfaceType,vlan,virtualInterfaceState,bgpPeers[0].bgpStatus]" \
  --output table

# 10. Failover test: take one VIF's BGP down for 10 minutes
aws directconnect start-bgp-failover-test \
  --virtual-interface-id dxvif-ffabc123 --test-duration-in-minutes 10

Output of step 9 on a healthy setup:

-----------------------------------------------------------------
|                  DescribeVirtualInterfaces                    |
+---------------+----------+------+------------+---------------+
|  prod-private |  private |  101 |  available |  up           |
|  s3-public    |  public  |  102 |  available |  up           |
|  tgw-transit  |  transit |  201 |  available |  up           |
+---------------+----------+------+------------+---------------+

On the router, check that BGP sees both paths and which one wins (Cisco-style syntax):

router# show ip bgp 10.20.0.0/16
  Paths: (2 available, best #1)
  64512 via 169.254.10.1 (Direct Connect)  localpref 200  best
  64512 via 169.254.44.5 (VPN tunnel 1)     localpref 100
router# show bfd neighbors
  169.254.10.1   Up   300 ms x 3

From an instance, mtr -rwc 20 172.16.5.20 should show a short, steady path through the virtual private gateway with the same latency every run; repeat it during a failover test and watch the path and latency change to the VPN.

#Summary

Key takeaways

• Direct Connect: a dedicated private connection from your network to AWS through a Direct Connect location (cross-connect from your or a partner’s cage to the AWS cage). Steady bandwidth and latency, lower data-out price, IPv4 and IPv6, not over the internet, but often more than a month to set up.
• Dedicated: 1, 10, 100, 400 Gbps ports, ordered from AWS (LOA-CFA, 90 days), up to 50 private/public VIFs + 4 transit VIFs, speed never changes, MACsec and LAG possible. Hosted: 50 Mbps–25 Gbps from a partner, one VIF, speed changed only by the partner, no MACsec. Below 1 Gbps → hosted.
• LAG: up to 4 same-speed dedicated connections (2 at 100/400 Gbps) at one location, active/active, minimum links: bandwidth, not location resilience.
• VIFs are VLANs with BGP: private → VPC private IPs (VGW or DXGW), public → AWS public endpoints like S3 in all Regions (not the internet), transit → transit gateway through a DXGW. Exceed 100 prefixes on a private/transit VIF and BGP goes idle.
• Direct Connect gateway: global, one VIF to VPCs in many Regions (not China) and accounts, up to 20 VGWs or 6 transit gateways, no VPC-to-VPC routing, no overlapping prefixes, highly available by design.
• Not encrypted by default. Standard fix: IPsec VPN over Direct Connect (~1.25 Gbps per tunnel). Line-rate fix: MACsec on dedicated 10/100/400 Gbps at supported locations.
• Resiliency: dev/test (1 location, 2 connections), high (2 locations × 1), maximum (2 locations × 2 = 4, mission critical).
• Cheapest backup: Site-to-Site VPN. AWS → you: longest prefix, then Direct Connect before VPN for the same prefix. You → AWS: local preference (or AS path prepending on the VPN). Same prefixes on both, BFD for fast failover.
• Cost: port-hours + data transfer out at Direct Connect rates; data in free.

Self-check: AWS Direct Connect30 questions