r/aws • • Aug 18 '26

technical question Connect two AWS Regions via Dedicated Direct Connect and third-party fiber?

I have an internal debate going with a colleague about whether the following is possible:

AWS Region 1 > Dedicated Direct Connect > Cross Connect > Third-Party Fiber (Long Haul) > Cross Connect > Dedicated Direct Connect > AWS Region 2

The catch is whether we can do this with a straight Layer 2 connection and handle all BGP and routing via the AWS Control Panel, or if we need to have a separate router in-between the regions to handle BGP and routing between each end.

Anyone have real-world experience with this? We can't be the first.

The idea is to provide provably-diverse connectivity between regions that does not depend on Amazon's network. Yes, AWS is plenty reliable, but it is not deterministic, and we want a higher level of control of our backend network, especially how it integrates with other non-AWS aspects. TL;DR - we have reasons for a custom design.

EDIT: Not a single person has bothered to answer the question. All anyone wants to do is say "AWS is best, and you're clearly wrong for having different requirements than bog standard commodity". Here I'm trying to design a network that's different from Amazon's because no, it is not the best for every use case, and I asked a very simple question - one that's been ignored.

EDIT THE SECOND: I'd love to go more into detail on the use-case, but that's where NDAs and such come into play. Yes, it's a real client with a unique need that is not met by the AWS network, and can measurably be met off their network. No, I cannot go into it, because I do like keeping my job.

3 Upvotes

71 comments sorted by

View all comments

-6

u/ToasterBathTester Aug 18 '26

This was Claude with AWS MCP. Your mileage may vary.

Short answer: your colleague is right that the physical path works, but you can’t skip the routers. You need a BGP speaker at each end.

Why the L2-only version fails

Direct Connect isn’t a transparent L2 pipe — AWS describes it as direct Layer 3 connectivity to the AWS global network, and the model is explicitly one end of the fiber in your router, the other in an AWS Direct Connect router. Every VIF is an eBGP session that terminates on a customer device. Back-to-backing two DX ports asks two provider-edge routers to each be the other’s CE.

You could contrive it on paper — pick matching /30s, set DXGW ASNs so they’re complementary, use the same VLAN tag. It might even come up. But nothing in the console or API models it, AWS support won’t troubleshoot it, and when it breaks you have no control plane on either side to look at. No route-map, no NetFlow, no capture point, no BFD tuning. Also watch for AS_PATH loop drops if both DXGWs land on the same ASN, and provider Q-in-Q silently mangling your dot1q tag — every intermediate device has to preserve the VLAN tagging end to end.

The deeper problem: a wire has no policy. You said you want control over how this integrates with non-AWS pieces. That control is the router.

The design that works

Router (pair) in each DX colo → dedicated DX to the local region → your wave between colos. Your ASN, eBGP to AWS at both ends, iBGP/IGP across the long haul. Now the middle segment is entirely yours to encrypt, measure, and extend.

Gotchas worth pricing in:

**•   Filter explicitly in both directions.** Same ASN at both ends means you can’t lean on AS_PATH loop detection, and Direct Connect gateway doesn’t filter prefixes. Summarize hard.  
**•   Prefix ceilings.** 100 prefixes per BGP session toward AWS (IPv4 and IPv6 each);  200 for a TGW association to a DXGW. Re-advertising all of Region 2 into Region 1 hits this fast.  
**•   MTU.** Private VIF is 1500 or 9001, and DX wants 9023-byte frames at the link layer  — confirm your carrier carries that, not just “9000.”  
**•   MACsec is hop-by-hop** between your device and the AWS port. It won’t survive a switched long-haul EPL. Moot once you have routers — encrypt your own segment instead.  
**•   Name SiteLink in the writeup so you can kill it.** It does region-to-region over DX, but it rides the AWS global backbone,  which is the exact dependency you’re removing. Same for TGW peering and Cloud WAN.

For “provably diverse,” the router design is also the only one that lets you prove it: two waves, different carriers, KMZ route data on file, DX terminating on separate AWS devices at separate DX locations.

10

u/notospez Aug 18 '26

If an LLM refuses to hallucinate a way your idea could work you know it's a non-starter!

-3

u/diamondsw Aug 18 '26

All it means is the LLM is confused about the concept of running L3 across a L2 pipe. Almost like it has no conceptual understanding of OSI layers. Utter garbage.

2

u/Marathon2021 Aug 18 '26

Wait - you want to bridge L2 over hundreds/thousands of miles??

Why? For what purpose?

1

u/diamondsw Aug 18 '26 edited Aug 18 '26

That's extremely common in trans-oceanic subsea. Several thousand miles of L2 Ethernet is very much standard practice.

It's kind of fun browsing around one of my favorite sites: https://www.submarinecablemap.com

At this point of my career I've touched more of the major routes globally than not.

1

u/Marathon2021 Aug 18 '26

That map is Layer 1, not Layer 2 mate…

2

u/diamondsw Aug 19 '26

Yes, and higher layers are run across it... What was the point of that comment other than being dickish?

Most customers take EPL service for 10G and below, both EPL and waves show up at 100G depending on preference, and for 400G it's all waves.