The single fact that separates Direct Connect from every internet-based connectivity option: there is a literal, physical cable involved.

What a Cross-Connect Actually Is

A Direct Connect location is a colocation facility where AWS has network equipment present, and establishing a connection means physically running a fiber cross-connect between the customer’s (or their network provider’s) equipment rack and AWS’s networking equipment within that same facility. This is fundamentally a physical-layer action, not a software configuration step — the connection genuinely does not exist until that cable is run and both ends are verified as optically linked.

flowchart LR
    Cust["Customer Router\n(in colocation rack)"] -->|Physical Fiber\nCross-Connect| AWS["AWS Network Equipment\n(same Direct Connect location)"]
    AWS --> Cloud["AWS Global Network"]
        

Why Bandwidth and Latency Behave Differently Here

Because the connection does not traverse the public internet or any shared, congestion-prone path, both available bandwidth and latency variability are dramatically more predictable and consistent than an internet-based VPN — a property that matters enormously for latency-sensitive or bandwidth-intensive hybrid workloads.

Not every organization has equipment already sitting in an AWS-adjacent colocation facility.

Dedicated Connections vs. Hosted Connections

A dedicated connection provisions an entire physical port (1, 10, or 100 Gbps) directly for one customer, requiring that customer’s own equipment be physically present, or connected via a network partner, at the Direct Connect location. A hosted connection, by contrast, is provisioned and resold by an AWS Direct Connect Partner from their own existing physical connection into AWS, sized to a specific customer’s needs in smaller increments — a practical option for organizations that do not have their own equipment in the facility at all.

Direct Connect Locations as Physical Meeting Points

Each Direct Connect location is tied to specific AWS Regions it can reach, meaning the choice of which physical facility to establish a cross-connect in is itself an architectural decision, influenced by which Regions need to be reached and which facility is most practical for the organization’s own network footprint.

A single physical connection is sliced into multiple logically isolated virtual circuits using 802.1Q VLAN tagging.

VLAN Tagging Enables Multiple Virtual Interfaces on One Physical Connection

Using 802.1Q VLAN tags, a single physical cross-connect can carry multiple, logically isolated virtual interfaces simultaneously — for example, one private virtual interface reaching a production VPC and a separate private virtual interface reaching a completely isolated development VPC, all traveling over the same physical fiber without any traffic mixing between them.

flowchart TB
    Phys["One Physical\nCross-Connect"]
    Phys --> VIF1["Private VIF\n(VLAN 100) → Production VPC"]
    Phys --> VIF2["Private VIF\n(VLAN 200) → Development VPC"]
    Phys --> VIF3["Public VIF\n(VLAN 300) → S3, DynamoDB"]
        

Every virtual interface’s routing behavior is governed by the Border Gateway Protocol, the same protocol that runs the internet’s core routing.

Establishing a BGP Peering Session

Once a virtual interface is configured, the customer’s router and AWS’s router establish a BGP peering session over it, exchanging route advertisements — the customer’s router announces which private IP prefixes exist on their side, and AWS announces which prefixes (VPC CIDR ranges, or public AWS service ranges) are reachable on its side.

sequenceDiagram
    participant Cust as Customer Router
    participant AWS as AWS Router
    Cust->>AWS: BGP Open (peering request)
    AWS->>Cust: BGP Open (accepted)
    Cust->>AWS: Advertise on-premises prefixes
    AWS->>Cust: Advertise VPC / service prefixes
    Note over Cust,AWS: Routes exchanged continuously\nas network topology changes
        

Bidirectional Forwarding Detection for Fast Failure Detection

Because BGP’s own default timers can take tens of seconds to detect a failed peer, Direct Connect supports Bidirectional Forwarding Detection (BFD), a lightweight protocol that detects link failure in a fraction of a second, allowing BGP to withdraw affected routes and reroute traffic far faster than relying on BGP’s native failure detection alone.

Treating multiple physical connections as one logical, higher-bandwidth connection.

LAG as a Single Logical Interface

A Link Aggregation Group bundles multiple physical Direct Connect connections of the same bandwidth and terminating at the same Direct Connect location into a single logical interface, presenting one combined bandwidth capacity and one BGP session configuration to the rest of the network, rather than managing several independent connections separately.

flowchart LR
    P1["Physical Connection 1\n(10 Gbps)"] --> LAG["Link Aggregation Group\n(20 Gbps logical)"]
    P2["Physical Connection 2\n(10 Gbps)"] --> LAG
    LAG --> Net["Single Logical\nNetwork Interface"]
        

Why LAG Improves Both Bandwidth and Resiliency

Beyond simply adding bandwidth, a LAG also provides resiliency within a single location — if one physical connection in the group fails, traffic continues flowing over the remaining connections in the group automatically, without requiring a separate BGP failover event at the virtual interface level.

Extending one physical connection’s reach far beyond a single Region or a single VPC.

The Problem of Reaching Many VPCs Across Many Regions

Without an additional layer, a private virtual interface connects to exactly one VPC in one Region — an organization with dozens of VPCs spread across multiple Regions would otherwise need a proliferation of virtual interfaces and, in some cases, physical connections in multiple Regions entirely.

Direct Connect Gateway as a Global Routing Hub

A Direct Connect Gateway acts as a globally available routing intermediary that a virtual interface connects to once, and which can then be associated with multiple VPCs (via their virtual private gateways or transit gateways) across multiple Regions — meaning a single Direct Connect connection established in one location can reach VPCs in Regions the physical connection itself has no direct presence in.

flowchart TB
    Conn["Direct Connect Connection\n(one physical location)"] --> DCGW["Direct Connect Gateway"]
    DCGW --> VPC1["VPC — us-east-1"]
    DCGW --> VPC2["VPC — eu-west-1"]
    DCGW --> VPC3["VPC — ap-southeast-1"]
        

AWS defines explicit, named resiliency models rather than leaving redundancy design entirely open-ended.

Why Resiliency Model Choice Should Match Actual Business Impact

Selecting a resiliency model is fundamentally a cost-versus-risk decision — Maximum Resiliency provides the strongest protection but at meaningfully higher cost and complexity, making it appropriate specifically for workloads where a hybrid connectivity outage would cause serious, quantifiable business harm, rather than being a default choice for every use case.

A common, cost-effective pattern that layers a fundamentally different connectivity type as a backup path.

VPN as a Backup Path for Direct Connect

Rather than paying for a second full Direct Connect connection purely as a backup, many architectures configure a Site-to-Site VPN over the public internet as a failover path, with BGP configured so that the Direct Connect path is preferred under normal conditions and traffic automatically shifts to the VPN path if the Direct Connect connection becomes unavailable.

flowchart TB
    OnPrem["On-Premises Network"] -->|Primary: Direct Connect| AWS["AWS VPC"]
    OnPrem -->|Backup: Site-to-Site VPN\nover public internet| AWS
        

Influencing Path Preference With BGP Attributes

Path preference between the Direct Connect and VPN routes is controlled using standard BGP attributes such as AS-path prepending (making the VPN path look artificially longer, and therefore less preferred) or local preference, ensuring traffic only shifts to the VPN when the Direct Connect path genuinely becomes unavailable, rather than load-balancing unpredictably between the two.

Fine-grained control over exactly how traffic flows across redundant paths.

BGP Communities for Route Scoping

AWS Direct Connect supports specific BGP community tags that let a customer influence how their advertised routes propagate — for example, marking a route as local to a specific Region only, or as reachable across an entire continent, giving explicit, fine-grained control over route scope in complex multi-location architectures.

AS-Path Prepending for Explicit Preference Control

By artificially repeating their own Autonomous System number multiple times in a route advertisement, a customer can make a specific path appear “longer” and therefore less attractive under BGP’s standard path-selection algorithm, a common and effective technique for ensuring a secondary connection or location is only used when the primary path is genuinely unavailable.

flowchart LR
    Primary["Primary Connection\nAS-Path: 65000"] --> Sel{"BGP Path\nSelection"}
    Backup["Backup Connection\nAS-Path: 65000, 65000, 65000\n(prepended)"] --> Sel
    Sel -->|Shorter path preferred| Primary
        

Adding encryption at the physical connection layer, for organizations where privacy alone is not enough.

Why Direct Connect Traffic Is Not Encrypted by Default

Because Direct Connect traffic never traverses the public internet, it is inherently private in the sense of not being publicly routable — but “private” is not the same as “encrypted,” and highly regulated industries often require actual cryptographic protection of data in transit, even across a dedicated physical link.

MACsec Encrypting at the Ethernet Layer

MACsec (802.1AE) provides line-rate encryption directly at the Ethernet layer for supported dedicated connections, encrypting traffic between the customer’s router and AWS’s router without requiring any additional encryption tunnel to be configured at a higher layer, and without the meaningful throughput overhead that software-based encryption tunnels typically introduce.

flowchart LR
    Cust["Customer Router\n(MACsec-enabled)"] -->|Encrypted at\nEthernet layer| AWS["AWS Router\n(MACsec-enabled)"]
        

Using AWS’s own global network backbone to connect two of a customer’s own physical sites.

Beyond Site-to-AWS: Site-to-Site Over AWS’s Backbone

SiteLink allows traffic between two Direct Connect locations to route directly over AWS’s global network backbone rather than being forced to travel up to a specific AWS Region and back down again — useful for an organization connecting two of its own data centers, each with its own Direct Connect presence, without needing that traffic to logically pass through a Region’s VPC infrastructure at all.

flowchart LR
    Site1["Customer Site A\n(Direct Connect Location 1)"] -->|SiteLink over\nAWS Backbone| Site2["Customer Site B\n(Direct Connect Location 2)"]
        

Resilience in Direct Connect is deliberately layered — physical, protocol, and architectural.

Layering LAG, Multiple Locations, and BFD Together

Genuine high availability combines several of the mechanisms already covered: LAG for protection against a single connection failure, a second Direct Connect location for protection against a facility-wide event, and BFD for fast failure detection so BGP can reroute quickly once a failure does occur — no single mechanism alone is sufficient for a truly resilient hybrid network design.

Testing Failover Deliberately

Because hybrid network failover paths are exercised far less often than cloud-native failover mechanisms, deliberately testing a Direct Connect failover — by disabling a connection or a BGP session in a controlled manner — is a standard operational practice for validating that BFD timers, AS-path preferences, and backup VPN paths actually behave as designed before a real outage forces the issue.

Beyond MACsec, Direct Connect security spans physical access, routing policy, and IAM.

Physical Access Control at the Colocation Facility

Because the connection begins with a physical cross-connect, security starts with the colocation facility’s own physical access controls governing who can reach the customer’s equipment rack at all — a layer of security consideration that purely cloud-native services never require thinking about.

IAM Policies for Connection and Virtual Interface Management

Creating, modifying, or deleting connections and virtual interfaces is governed by IAM policy, allowing an organization to restrict which teams or roles can make changes to critical hybrid network infrastructure — an important control given how disruptive an accidental virtual interface deletion or BGP misconfiguration could be.

Route Filtering as a Security Boundary

Because BGP will advertise and accept whatever routes are configured, deliberate route filtering — only advertising the specific prefixes that should be reachable, and only accepting the specific prefixes expected from the other side — acts as an important security boundary, preventing accidental or malicious route leakage between environments that should remain isolated.

Observability spans both the physical connection and the BGP routing layer above it.

Why Physical and BGP-Layer Monitoring Must Both Be Watched

A healthy physical connection with a failed BGP session looks completely different from a failed physical connection, but both result in the same practical outcome — no traffic flowing — which is why comprehensive monitoring must track both layers independently rather than assuming one implies the other.

How organizations actually roll Direct Connect into a broader hybrid architecture.

Partner-Hosted Connections for Faster Onboarding

Organizations without existing equipment in an AWS Direct Connect location commonly start with a hosted connection through an AWS Direct Connect Partner already present in the facility, achieving working hybrid connectivity in days or weeks rather than the longer timeline a dedicated connection with new physical infrastructure would require.

Transit Gateway Integration for Centralized Routing

Pairing a Transit Virtual Interface with AWS Transit Gateway creates a centralized hub-and-spoke architecture where a single Direct Connect connection reaches many VPCs through the transit gateway’s own routing tables, simplifying what would otherwise be a sprawling mesh of individual virtual interfaces as an organization’s VPC count grows.

flowchart TB
    DX["Direct Connect\n(Transit VIF)"] --> TGW["Transit Gateway"]
    TGW --> VPCA["VPC A"]
    TGW --> VPCB["VPC B"]
    TGW --> VPCC["VPC C"]
        

Patterns that build genuine resilience, and mistakes that create a false sense of it.

Direct Connect solves a specific class of problem extremely well, at a real cost and complexity trade-off.

How organizations apply these mechanics in production hybrid networks.

No — Direct Connect traffic is private in the sense that it never traverses the public internet, but it is not cryptographically encrypted by default. MACsec, on supported dedicated connections, must be deliberately enabled for actual encryption.

Not necessarily — if both connections terminate at the same physical Direct Connect location, a facility-wide failure still takes down both. AWS’s High Resiliency and Maximum Resiliency models specifically require connections across separate physical locations.

Yes, through a Direct Connect Gateway, which acts as a global routing intermediary that a virtual interface connects to once, then associates with VPCs across multiple Regions without requiring a physical connection in each Region.

A private virtual interface connects to exactly one VPC directly. A transit virtual interface connects to a Transit Gateway, allowing a single virtual interface to reach many VPCs across many accounts through the transit gateway’s own routing.

Cost and speed of deployment — a Site-to-Site VPN backup path can be established quickly and inexpensively over the existing internet connection, providing a reasonable failover option for organizations that accept reduced bandwidth and internet-based variability during the rare event the primary Direct Connect connection fails.

Advanced command of Direct Connect starts with recognizing it as a genuinely physical service layered underneath a familiar routing protocol — a literal fiber cross-connect at a specific colocation facility, governed by BGP once established. Every advanced capability builds outward from that foundation: VLAN tagging lets one physical connection serve multiple isolated destinations, Direct Connect Gateway extends that connection’s reach across Regions and accounts, LAG and multi-location resiliency models protect against different failure scopes at different layers, and MACsec adds cryptographic protection the physical medium does not provide on its own. None of these mechanisms substitute for the others — a resilient, secure, well-performing hybrid network is the deliberate combination of the right resiliency model, correctly configured BGP traffic engineering, and encryption where genuinely required, matched to how much a hybrid connectivity failure would actually cost the business if it happened.