We're evaluating a custom, provably diverse connection between two AWS Regions. The proposed path is: AWS Region 1 → Dedicated Direct Connect → cross-connect → third-party long-haul fiber → cross-connect → Dedicated Direct Connect → AWS Region 2.
The question is whether the two Direct Connect endpoints can be connected as a straight Layer 2 circuit, with BGP and routing configured through AWS, or whether we must install routers at the two colocation sites to terminate the Direct Connect sessions and route traffic across the long-haul circuit.
The goal is to avoid depending on the AWS network between Regions, while gaining more control over path diversity, latency, and integration with non-AWS infrastructure. This is a deliberate custom design rather than an attempt to replace a standard AWS architecture. Has anyone implemented or validated something similar?
3 Answers
If you need to demonstrate diversity, routers are effectively required. You can document separate carriers, physical routes, colocation facilities, and AWS Direct Connect devices, then apply explicit route policy at both ends. A Layer 2 handoff gives you no meaningful way to enforce or inspect those policies.
Also account for VLAN-tag preservation, MTU end to end, BGP prefix limits, route summarization, and failure detection. If you need encryption, Direct Connect link encryption is generally limited to the customer-to-AWS segment; a separate routed long-haul segment gives you a place to apply your own encryption and telemetry.
The physical transport may be possible, but the Direct Connect design should include a customer router at each end. Direct Connect is not a transparent Layer 2 extension between Regions; each private VIF uses BGP between AWS and a customer-owned device. Two AWS-facing endpoints cannot generally be treated as a supported router-to-router circuit through the console.
A more practical design is a router pair at each colocation site: each pair establishes eBGP with its local Direct Connect connection, while the routers use eBGP, iBGP, or an IGP across the private long-haul circuit. That gives you policy control, route filtering, monitoring, encryption options, and a useful troubleshooting point. A direct Layer 2 arrangement might appear technically conceivable with matching VLANs and addressing, but it would be outside the normal supported model and would leave you without control of the routing plane if something failed.
An AWS service such as inter-Region Direct Connect connectivity or a transit design may simplify the architecture, but those options still rely on AWS-managed paths and therefore don’t meet the stated independence requirement. For the requirements described, the clean answer is two independently connected AWS edges with customer routers and a separately engineered inter-site network.
That distinction is the important one: the question isn’t whether the carrier can carry Ethernet frames, but whether AWS supports the other Direct Connect endpoint acting as the customer-side BGP peer. The supported architecture assumes your own device terminates each session.