Hybrid and Multi-Cloud Connectivity¶

Prerequisites

This section assumes familiarity with Amazon VPC, CIDR Planning, AWS Organizations, and the Within AWS connectivity services (AWS Transit Gateway and AWS Cloud WAN in particular). Review those topics first if you're new to AWS networking fundamentals.

Connecting AWS to networks outside AWS covers two distinct concerns, and the right answer is rarely a single service. Hybrid connectivity brings on-premises data centers and branch offices to AWS through private circuits, encrypted VPN, or SD-WAN overlays. Multi-cloud connectivity connects AWS to other public clouds for workloads that span providers.

Hybrid and multi-cloud overview showing three concerns: Hybrid Connectivity (Direct Connect, VPN, SD-WAN), Multi-Cloud Connectivity (AWS Interconnect, Partner-based), and Client Communication (Client VPN, Verified Access) — Hybrid and multi-cloud overview — Drawio Source

For on-premises connectivity, AWS Direct Connect delivers private, predictable bandwidth over dedicated circuits and is the foundation for most production hybrid deployments. AWS Site-to-Site VPN provides encrypted connectivity over the internet, useful when private circuits are not needed or as a complement to Direct Connect for layer-3 encryption. SD-WAN integration uses Transit Gateway Connect or AWS Cloud WAN Connect attachments to bring third-party SD-WAN overlays into the AWS network plane.

For multi-cloud, AWS Interconnect is the recommended option: a managed service that creates a direct, private connection between your AWS VPCs and another cloud provider's networks without requiring cross-connects at a colocation, partner coordination, or manual router configuration. The established alternatives (partner-based Direct Connect cross-connects, or Site-to-Site VPN between clouds) remain valid where AWS Interconnect doesn't yet support your other cloud, but they carry more operational overhead — a Region-pair gap alone is usually solved by extending inside each cloud instead.

Most organizations use more than one of these services simultaneously. The goal is to use each where it provides the most value. For the recommended architecture combining these services, see Building your hybrid and multi-cloud stack at the end of this page.

Private on-premises connectivity with AWS Direct Connect¶

AWS Direct Connect provides private, dedicated network connectivity between your on-premises network and AWS. Traffic flows over physical circuits provisioned at a Direct Connect location, bypassing the public internet entirely, so bandwidth is predictable, latency is consistent, and data transfer out of AWS is cheaper than over the internet. Direct Connect is the foundation for most production hybrid deployments, and it integrates with every AWS network service that terminates hybrid traffic: virtual private gateways, Transit Gateway, and AWS Cloud WAN.

Key capabilities:

:material-fiber: Dedicated and hosted connections

Dedicated connections at 1 Gbps, 10 Gbps, or 100 Gbps come directly from AWS at a Direct Connect location. Hosted connections at smaller speeds (50 Mbps to 25 Gbps) come from a Direct Connect Partner that has already provisioned capacity into the location.
Virtual interfaces (VIFs)

A single physical connection carries multiple VLAN-tagged virtual interfaces. Private VIFs reach VPC resources (via a virtual private gateway or a Direct Connect gateway). Transit VIFs reach Transit Gateways or AWS Cloud WAN core networks (via a Direct Connect gateway). Public VIFs reach AWS public service endpoints over private links.
Direct Connect Gateway

A globally distributed BGP route reflector. A single Direct Connect Gateway associates with virtual private gateways, Transit Gateways, or AWS Cloud WAN core networks across any AWS Region (except China), so one physical connection can reach many Regions without provisioning multiple circuits.
SiteLink

Routes traffic between two Direct Connect locations over the AWS global backbone without touching an AWS Region. Useful for connecting on-premises sites to each other through the AWS network when that path is shorter or more reliable than your WAN.
MACsec encryption

IEEE 802.1AE MACsec encrypts traffic at layer 2 between your router and the AWS Direct Connect router on supported 10 Gbps and 100 Gbps connections. Useful when compliance requires link-layer encryption on the dedicated circuit itself.
Dual-stack support

Private, transit, and public VIFs all support IPv4 and IPv6 BGP sessions. Dual-stack is configured per VIF, so you can run IPv4 and IPv6 on the same physical connection.

AWS Direct Connect Best Practices¶

Design for resiliency at the location and provider level, not just at the connection level¶

A single dedicated connection, even at 100 Gbps, is still one circuit through one Direct Connect location. For production hybrid traffic, follow the Resiliency Toolkit's maximum resiliency model: at least two connections at two separate Direct Connect locations, each sourced from a different provider and terminating on different on-premises routers. This removes location, provider, cross-connect, and device as single points of failure.

If the workload can tolerate degraded performance during a single location failure, the high resiliency model (two connections across two locations through one or more providers) is a reasonable middle ground. The development/test single-connection model is rarely appropriate for anything that ends up carrying production traffic.

Use a Direct Connect Gateway as the attach point¶

A Direct Connect Gateway is a free, globally distributed resource that acts as the BGP attach point between your VIFs and AWS network services (virtual private gateways, Transit Gateways, or AWS Cloud WAN core networks). Associating a single Direct Connect Gateway with multiple regional attach points means one physical connection can reach workloads in any Region, without a Region-specific VIF per destination.

This also simplifies migrations: when you move workloads between Regions or from Transit Gateway to AWS Cloud WAN, you re-associate the Direct Connect Gateway rather than re-provisioning VIFs. It also keeps the BGP control plane off the data path, so BGP re-convergence doesn't interrupt traffic on healthy paths.

Choose the right VIF type for each workload¶

Direct Connect offers three VIF types, each suited to a different use case. Picking the right one per workload matters more than defaulting to one type everywhere:

Transit VIF is the default for extending on-premises connectivity to the AWS network at large. Terminating on a Transit Gateway or AWS Cloud WAN core network (via a Direct Connect Gateway), a single Transit VIF reaches every VPC the hub routes to, with less VIF sprawl and centralized routing.
Private VIF to a specific VPC makes sense for workloads that justify a dedicated path: sustained high-throughput data transfer or latency-sensitive traffic where the hub's data processing adds overhead you want to avoid, or compliance cases where the workload can't share an attach point.
Public VIF is the right choice for consumption of AWS public service endpoints (for example, Amazon S3 or Amazon DynamoDB) directly over the Direct Connect path.

Most production environments run all three: one or more Transit VIFs as the backbone, Private VIFs for a small number of demanding workloads, and Public VIF where AWS public endpoint traffic is significant (S3 as the most common use case).

Use BGP attributes for traffic engineering across multiple Direct Connect paths¶

When you have multiple Direct Connect connections, BGP attributes let you shape how traffic flows: primary vs. secondary paths, load distribution across circuits, and symmetric return traffic. The supported attributes are Local Preference communities (on routes from AWS, higher wins), AS_PATH prepending (on routes you advertise, longer is less preferred), MED (on routes you advertise, lower wins when AS_PATH ties), and longest prefix match (which always overrides the attributes above).

For VIFs terminating on a Direct Connect Gateway, the on-side configuration happens on your on-premises router. The VIF and Direct Connect Gateway themselves don't have configurable BGP policy knobs, so traffic engineering is primarily an on-premises exercise. For AWS Cloud WAN deployments, Cloud WAN routing policies add an AWS-side control point: you can filter, summarize, and manipulate BGP attributes on routes between Cloud WAN segments and Direct Connect Gateway attachments from the policy rather than only from the on-premises router.

Enable BFD for sub-second failover¶

BGP hold timers alone detect a failed neighbor in around 90 seconds by default (three times the 30-second keep-alive interval). That's too long for most production hybrid workloads. Bidirectional Forwarding Detection (BFD) runs a lightweight liveness check alongside the BGP session and tears the session down as soon as the forwarding path fails, typically within about a second.

AWS enables asynchronous BFD on every Direct Connect BGP session automatically, with a 300 ms detection timer and a multiplier of 3 (roughly 900 ms to declare the session down). On your side, enable BFD with compatible timers on the on-premises router to complete the negotiation. Without BFD active on both ends, failover on a connection, VIF, or peer device issue still falls back to BGP hold timers, and the outage window is tens of seconds rather than sub-second.

BFD is especially important in multi-circuit or active/passive designs where the whole point of the redundancy is quick failover. Confirm that BFD is up on every session as part of turn-up validation, and alarm on BFD state the same way you alarm on BGP session state.

Plan IPv6 from the start¶

Every VIF type supports IPv6 BGP sessions. Configure IPv6 alongside IPv4 on each VIF from the beginning, even if your on-premises hosts are IPv4-only today. The AWS side supports dual-stack; the hard part is the on-premises rollout, and having the AWS side ready means you can adopt IPv6 when the on-premises network is ready without reopening VIF configuration.

Monitor BGP and VIF metrics actively¶

Direct Connect publishes CloudWatch metrics for BGP session state, connection state, and per-VIF ingress and egress bytes and packets. Alarm on BGP session state flapping and on unexpected traffic asymmetry (one VIF carrying significantly more or less than its siblings when BGP should balance them). Fast detection of BGP state changes is the difference between a failover that is invisible to users and one that causes a five-minute outage.

When to use AWS Direct Connect¶

Direct Connect is the right choice whenever any of the following applies:

Your hybrid workloads require predictable bandwidth or latency that the public internet can't guarantee.
You transfer large volumes of data out of AWS and want the lower Direct Connect egress pricing rather than internet egress rates.
You have compliance requirements that forbid sensitive traffic from traversing the public internet.
You are building any new production hybrid architecture. The path to high resiliency is multiple Direct Connect connections across multiple locations and providers, not a single Direct Connect paired with a VPN fallback.

Direct Connect is not the right starting point when connectivity needs to be up in days rather than weeks (provisioning involves cross-connects and provider coordination), when traffic volume is low enough that VPN cost and performance are acceptable, or when connectivity is short-lived (for example, a one-time data migration where VPN throughput is sufficient).

Combining AWS Direct Connect with other Hybrid Networking services¶

Combination	AWS Direct Connect handles	Other service handles
Direct Connect + Site-to-Site VPN	Private path into AWS	IPsec overlay on top of Direct Connect when MACsec is not available (for example, sub-10 Gbps hosted connections or compliance baselines that require layer-3 encryption)
Direct Connect + SD-WAN (via TGW/Cloud WAN Connect)	Underlying transport between on-premises SD-WAN appliances and AWS	Overlay delivered by the SD-WAN solution
Direct Connect + AWS Interconnect (multi-cloud)	On-premises hybrid path	Cloud-to-cloud path between AWS and another provider; the two can share a Direct Connect Gateway

Documentation¶

AWS Direct Connect documentation

Complete service documentation covering connections, virtual interfaces, Direct Connect Gateway, SiteLink, and MACsec.

Documentation
Resiliency Toolkit

AWS's recommended resiliency models (development, high, maximum) and the guided workflow for implementing them.

Documentation
AWS Direct Connect blog posts

Architecture walkthroughs, feature announcements, and implementation guides from the AWS Networking and Content Delivery blog.

Blog posts
AWS Direct Connect pricing

Port-hour charges for dedicated and hosted connections, plus data transfer out pricing that is typically lower than internet egress.

Pricing

Encrypted on-premises connectivity with AWS Site-to-Site VPN¶

AWS Site-to-Site VPN provides encrypted IPsec connectivity between your on-premises networks and AWS over the public internet. Each VPN connection consists of two IPsec tunnels terminating on separate AWS endpoints for redundancy, and supports both static routing and dynamic routing with BGP. Site-to-Site VPN can terminate on a virtual private gateway attached to a VPC, on a Transit Gateway, or on an AWS Cloud WAN core network.

Site-to-Site VPN is the fastest way to establish hybrid connectivity. It is commonly used as the primary path for sites that do not require a private circuit, for short-lived connectivity such as data migrations, and as an IPsec overlay on top of Direct Connect when MACsec is not available and layer-3 encryption is required.

Key capabilities:

IPsec encryption with two tunnels per connection

Every VPN connection provides two IPsec tunnels terminating on endpoints in separate Availability Zones.
Standard and Large tunnel bandwidth

Standard tunnels provide up to 1.25 Gbps per tunnel. Large tunnels provide up to 5 Gbps per tunnel, removing the need for complex ECMP bonding on high-throughput workloads. Large tunnels are available on Transit Gateway VPN and AWS Cloud WAN VPN attachments.
VPN Concentrator for many remote sites

A Transit Gateway attachment that aggregates many low-bandwidth (under 100 Mbps) VPN connections into a single attachment, with up to 100 sites per Concentrator and 5 Gbps aggregate bandwidth. Designed for distributed enterprises with dozens of branches (retail, hospitality, healthcare) that previously required managing multiple virtual concentrator appliances in AWS.
Accelerated VPN

Routes VPN traffic through AWS Global Accelerator and the AWS edge network, reducing jitter and improving throughput for customers far from the AWS Region. Available on Transit Gateway VPN connections.
Private IP VPN over Direct Connect

Terminates the VPN on a private IP address reachable over a Direct Connect connection instead of the public internet. Useful when you want IPsec encryption on top of a Direct Connect circuit without exposing the tunnel endpoint to the internet.
Dynamic routing with BGP

BGP on each tunnel lets the on-premises router learn AWS prefixes dynamically and advertise on-premises prefixes into AWS. Static routing is supported for devices that don't run BGP, but BGP is strongly recommended for any non-trivial topology.
Dual-stack support

VPN tunnels support IPv4 or IPv6 inside addresses. Dual-stack communication requires separate VPN tunnels for each protocol.

AWS Site-to-Site VPN Best Practices¶

Use multiple VPN connections with diverse ISP paths and dynamic routing¶

Every VPN connection provides two IPsec tunnels, but both terminate on AWS endpoints within the same connection. For production resiliency, provision two or more VPN connections, terminate them on different on-premises routers, and have each router reach AWS over a different ISP so a single-provider outage does not take down both paths at once. Use BGP on every tunnel so AWS learns and fails over between paths automatically, reports reachability through session state, and lets you steer traffic with BGP attributes; static routing skips all of that and is almost never appropriate for production. If an on-premises device does not support BGP, the fix is to replace the device rather than build around it.

Terminate VPN on Transit Gateway or AWS Cloud WAN, not virtual private gateways¶

A VPN to a virtual private gateway reaches exactly one VPC. A VPN to a Transit Gateway or AWS Cloud WAN core network reaches every VPC the hub routes to, with segmentation applied through route tables or network policy. For any environment with more than one VPC, terminate VPN on a Transit Gateway or AWS Cloud WAN.

This also enables Large tunnels (5 Gbps per tunnel), Accelerated VPN, and ECMP across multiple VPN attachments, none of which are available on virtual private gateway VPN.

Use VPN Concentrator for many low-bandwidth sites¶

VPN Concentrator addresses the many-branches use case: many sites, each with modest bandwidth needs, where provisioning a dedicated VPN connection per site creates Transit Gateway attachment sprawl and per-connection cost that doesn't match the workload. A VPN Concentrator attachment aggregates up to 100 sites (each under 100 Mbps) into a single Transit Gateway attachment, with 5 Gbps aggregate per Concentrator and up to 5 Concentrators per Transit Gateway.

Reach for VPN Concentrator when you have around 25 or more remote sites fitting the low-bandwidth profile (retail chains, hotels, healthcare branches, distributed field offices). The Concentrator runs BGP-only routing and provides AZ-redundant endpoints, so operationally it looks like one attachment with consistent routing policies and security rules applied across all connected sites, instead of a per-site connection to manage. For a handful of sites, or for sites that need more than 100 Mbps, stick with standard Site-to-Site VPN connections.

Use Accelerated VPN for distant sites¶

For branch offices or data centers far from the AWS Region, Accelerated VPN routes traffic through the AWS Global Accelerator edge network instead of the public internet. The improvement in jitter and throughput is meaningful for latency-sensitive or bandwidth-sensitive hybrid workloads, and enabling it is a per-connection toggle.

Accelerated VPN is most valuable when the AWS Region isn't in the same continent as the site or when internet routing between the site and the Region is historically unreliable.

Plan IPv6 from the start¶

VPN tunnels support IPv4 or IPv6 inside addresses, but a single tunnel carries one protocol. If you need both, provision dual-stack by creating one tunnel for IPv4 and another for IPv6 within the same connection configuration, and account for that in bandwidth and tunnel-count planning.

Monitor tunnel state, BGP sessions, and enable Site-to-Site VPN logs¶

CloudWatch publishes TunnelState, TunnelIpAddress, and BGP session state metrics per tunnel. Alarm on tunnel state transitions and on BGP session flap counts. A single tunnel going down is expected to happen periodically (AWS performs planned maintenance on tunnel endpoints); both tunnels down on the same connection for more than a few minutes is an outage.

Enable Site-to-Site VPN logs on every connection. These logs capture IKE negotiations, IPsec tunnel establishment, dead peer detection, and BGP routing activity, which is the information you need to troubleshoot a failed negotiation or a flapping session. Without them, diagnosing a tunnel that won't establish typically means pulling logs from the on-premises device alone; with them, both sides of the conversation are visible in one place.

When to use AWS Site-to-Site VPN¶

Site-to-Site VPN fits any of the following:

You need hybrid connectivity running today and Direct Connect takes longer to provision.
The site is small or remote, and the cost and physical provisioning of a Direct Connect circuit aren't justified.
You need an encrypted overlay on top of Direct Connect because MACsec is not available (sub-10 Gbps hosted connections) or compliance requires layer-3 encryption.
Connectivity is short-lived, for example, a one-time data migration where internet-based encrypted throughput is sufficient.
You're connecting many small branch offices that collectively would need more Direct Connect circuits than is practical (VPN Concentrator is typically the right tool at scale).

Site-to-Site VPN is not the right choice when you need predictable latency beyond what the public internet can guarantee, when you transfer volumes of data where internet egress cost becomes prohibitive, or when compliance specifically requires private physical circuits rather than encrypted overlays.

Combining AWS Site-to-Site VPN with other Hybrid Networking services¶

Combination	Site-to-Site VPN handles	Other service handles
VPN + AWS Direct Connect	IPsec overlay on top of Direct Connect when MACsec is not available or layer-3 encryption is required	Private path into AWS

Documentation¶

AWS Site-to-Site VPN documentation

Complete service documentation covering tunnel configuration, BGP, Transit Gateway and AWS Cloud WAN attachments, Large tunnels, and Accelerated VPN.

Documentation
Accelerated VPN

How to enable Accelerated VPN and when it improves throughput for distant sites.

Documentation
Hybrid Connectivity whitepaper

AWS whitepaper covering Site-to-Site VPN, Direct Connect, and SD-WAN architectures for hybrid connectivity.

Whitepaper
AWS Site-to-Site VPN blog posts

Architecture patterns, feature announcements, and implementation guides from the AWS Networking and Content Delivery blog.

Blog posts
AWS Site-to-Site VPN pricing

Per-connection-hour charges plus data transfer, with separate pricing for standard and Large tunnels and for Accelerated VPN.

Pricing

SD-WAN integration with AWS Transit Gateway and AWS Cloud WAN¶

This section is for organizations that already run SD-WAN across their branches and data centers and want AWS to participate in that overlay as a first-class site. The SD-WAN vendor handles the overlay itself (path selection, WAN optimization, site-to-site encryption, orchestration); AWS provides the attach point that brings the overlay into the AWS network plane.

The integration mechanism is Connect attachments on AWS Transit Gateway or AWS Cloud WAN. A Connect attachment carries multiple Connect peers, each with BGP for dynamic routing between the SD-WAN appliance and AWS. BGP is the standard control plane every SD-WAN vendor speaks. The tunnel protocol, the underlay, and the supported landing service differ between Transit Gateway and AWS Cloud WAN, and those differences shape the integration design; the sections that follow cover them.

SD-WAN integration showing on-premises devices connecting through virtual SD-WAN appliances in a Transit VPC to Transit Gateway or Cloud WAN, which routes to workload VPCs — SD-WAN integration — Drawio Source

Integration building blocks:

Transit Gateway vs AWS Cloud WAN differences

Both services support Connect attachments with BGP, but the supported tunnel protocol and underlay differ. Transit Gateway Connect uses GRE only and supports both VPC and Direct Connect underlays. AWS Cloud WAN Connect supports GRE and Tunnel-less Connect (a higher-performance option that eliminates encapsulation overhead), and the underlay must be a VPC attachment; Direct Connect Gateway is not supported. Pick the landing service that matches your existing AWS network backbone.
GRE and Tunnel-less Connect

GRE encapsulates the BGP and data traffic in a tunnel between the SD-WAN appliance and the AWS side. Tunnel-less Connect (AWS Cloud WAN only) skips the encapsulation entirely, so BGP runs directly between the appliance and Cloud WAN. Tunnel-less removes GRE overhead and typically delivers higher per-peer throughput.
VPC or Direct Connect underlay (Transit Gateway only)

For Transit Gateway Connect, the underlay can be a VPC (where SD-WAN virtual appliances run as EC2 instances) or a Direct Connect attachment (where the SD-WAN appliance is on-premises and peers with AWS over Direct Connect via a Direct Connect Gateway). The right choice depends on where you want your SD-WAN appliances to sit. AWS Cloud WAN Connect currently supports VPC underlay only.
Segment SD-WAN traffic into AWS environments

With Transit Gateway route tables or AWS Cloud WAN segments, you can map SD-WAN traffic classes (production, non-production, guest, IoT) to distinct routing domains inside AWS. This requires either multiple Connect peers (one per segment) or SD-WAN-side encapsulation that the vendor then maps to the appropriate AWS segment.
Dual-stack support

Connect attachments support IPv4 and IPv6 BGP sessions on the same GRE tunnel, so you can propagate IPv4 and IPv6 routes between the SD-WAN overlay and the AWS network without provisioning separate tunnels.

Best Practices for integrating SD-WAN networks with AWS¶

Choose the underlay based on where the SD-WAN appliance lives¶

If the SD-WAN vendor recommends running virtual appliances inside AWS (a common pattern), use a VPC-based Connect attachment on either Transit Gateway or AWS Cloud WAN: deploy the appliances in a transit VPC, attach the VPC to the chosen service, then layer the Connect attachment on top. The SD-WAN overlay connects on-premises devices to the appliances over the internet or Direct Connect.

If the SD-WAN appliances stay on-premises and peer with AWS directly, use a Transit Gateway Connect attachment with a Direct Connect underlay (via a Direct Connect Gateway). The on-premises SD-WAN devices establish GRE peers to the Transit Gateway over the Direct Connect circuit. This removes the virtual-appliance tier in AWS entirely, at the cost of requiring Direct Connect everywhere the SD-WAN terminates. This pattern is currently Transit Gateway only; AWS Cloud WAN Connect does not support a Direct Connect Gateway underlay.

Design for Connect peer redundancy per segment¶

A Connect attachment supports up to four Connect peers, each with two BGP sessions. For redundancy, provision at least two Connect peers per attachment, terminated on different SD-WAN appliances or different on-premises devices. AWS strongly recommends configuring both BGP sessions on every Connect peer; running a single session removes protection against BGP control plane failures during AWS maintenance events.

If you're segmenting SD-WAN traffic into multiple AWS environments (for example, production and non-production over the same Connect attachment), each segment typically requires its own Connect peer with routes filtered appropriately.

Use AWS Cloud WAN segments instead of Transit Gateway route tables for multi-Region SD-WAN¶

For a single-Region SD-WAN landing, Transit Gateway Connect with route table segmentation works well. For global SD-WAN deployments that land in multiple AWS Regions, AWS Cloud WAN Connect attachments into policy-defined segments are operationally simpler: the segmentation is part of the network policy, applied consistently across Regions, rather than being managed per-Region through individual Transit Gateway route tables.

Existing Transit Gateway Connect deployments can migrate incrementally. AWS Cloud WAN peers with Transit Gateways, so the SD-WAN attachments can stay on Transit Gateway while other traffic moves to AWS Cloud WAN.

Keep BGP prefix counts manageable¶

Connect peers support larger prefix counts than IPsec VPN (multi-protocol BGP with many thousands of prefixes is viable), but SD-WAN overlays often advertise every branch subnet as a separate prefix and the numbers grow quickly. Summarize on the SD-WAN side where possible, and monitor received-route counts on the AWS side through CloudWatch. Approaching per-peer limits is easy to miss until an advertisement storm triggers them.

If you land SD-WAN on AWS Cloud WAN, you can also summarize on the AWS side through routing policies: aggregate the prefixes announced to the Connect attachment, or filter routes arriving/leaving the AWS Cloud WAN network. This is useful when the SD-WAN orchestrator can't summarize cleanly at the source, or when different segments need different views of the branch prefix space.

Plan IPv6 from the start¶

Configure IPv6 BGP sessions alongside IPv4 on every Connect peer from the beginning. SD-WAN vendors are increasingly IPv6-capable, and the AWS side supports dual-stack natively. Retrofitting IPv6 after the fact often requires coordination with the SD-WAN orchestrator, which is smoother when the Connect peers are already dual-stack.

Documentation¶

Transit Gateway Connect documentation

Complete documentation on Connect attachments, Connect peers, GRE and BGP configuration, and VPC or Direct Connect underlays.

Documentation
AWS Cloud WAN Connect attachments

How to use Connect attachments with AWS Cloud WAN and policy-driven segments for global SD-WAN deployments.

Documentation

Multi-cloud connectivity¶

Workloads increasingly span multiple public clouds: a database in one cloud, an analytics platform in another, an application running in AWS consuming both. Connecting AWS VPCs to another cloud's networks historically required building the path yourself: provisioning Direct Connect to a colocation facility, cross-connecting to the other cloud's equivalent service, and maintaining the physical and BGP configuration on both sides. AWS Interconnect changes that by offering a managed, direct cloud-to-cloud connection that AWS and the peer cloud provision and maintain end to end.

AWS Interconnect is the default wherever a supported Region pair exists. Where one doesn't, extend a supported pair from inside each cloud before reaching for a partner-based cross-connect or an internet VPN — a coverage gap is usually a routing problem, not a reason to build the path yourself.

AWS Interconnect is a fully managed service that creates a private, high-speed connection between AWS VPCs and another cloud provider's networks. AWS Interconnect - multicloud is Region-paired: each Interconnect ties one AWS Region to one Region in the peer cloud, and you provision an Interconnect per pair you need to reach. The set of supported cloud providers and Region pairs is expanding — check Regional availability for the current list before designing around a specific pair. On the AWS side, an Interconnect attaches to a Direct Connect Gateway, which in turn associates with a Transit Gateway, AWS Cloud WAN core network, or virtual private gateway.

Unlike the do-it-yourself alternative at a colocation, AWS Interconnect abstracts away physical cross-connects, BGP configuration, and VLAN provisioning. You select the AWS Region, the peer cloud's Region, the required bandwidth, and the provider, and AWS and the provider provision both sides automatically. Capacity can be scaled up or down without re-provisioning.

Key capabilities:

Direct AWS ↔ other-cloud connectivity

A single managed object (the interconnect) connects a Direct Connect Gateway to the peer cloud's attach point. Traffic rides the AWS global backbone to the provider and hands off directly, with no intermediate internet hops.
Fully managed MACsec encryption

Every physical link is encrypted with IEEE 802.1AE MACsec between the AWS router and the provider's router, and AWS and the provider own the key lifecycle — there is no CKN/CAK pair for you to generate, rotate, or associate, and no bandwidth tier that lacks the capability. Traffic only flows when the encryption session is active, so no unencrypted path exists.
Built-in maximum resiliency

Every Interconnect is provisioned across redundant devices in at least two physically distinct facilities with independent power and networking. Multicloud connections use a four-connection model with ECMP load balancing, so at least one link stays up during planned maintenance or a device failure. A single Interconnect carries a 99.99% monthly uptime SLA.
Elastic bandwidth

Capacity can be increased or decreased without re-provisioning cross-connects or coordinating with the provider.
Direct Connect Gateway as the AWS attach point

The AWS side of the Interconnect attaches to a Direct Connect Gateway, which then associates with a Transit Gateway, AWS Cloud WAN core network, or virtual private gateway.
Fast provisioning

Interconnects are typically provisioned within minutes using the create-and-accept workflow between AWS and the provider. No cross-connect ticket, no BGP configuration, no VLAN negotiation.

AWS Interconnect Best Practices¶

Use AWS Interconnect as the default for supported Region pairs and providers¶

Where AWS Interconnect supports the AWS Region and peer cloud Region you need, it should be the default choice. The operational difference versus the partner-based Direct Connect alternative is substantial: no cross-connect, no BGP on your routers, no provider coordination during capacity changes, and MACsec on every link with no keys for you to manage.

The reason to look elsewhere is coverage, so check Regional availability rather than assuming a pair is listed. If it isn't, ask whether a supported pair can reach your Regions from inside each cloud (see No supported pair for the Regions you need) before abandoning AWS Interconnect. The partner-based approach and internet-based VPN are for clouds that aren't supported at all, or where the backbone path works but an existing colocation or carrier footprint makes one more cross-connect more efficient than inter-Region data transfer on two backbones.

Treat a single Interconnect as the resilient unit¶

The 99.99% SLA applies to one Interconnect because the redundancy is inside the object — a four-connection ECMP fabric across at least two facilities, pre-provisioned by AWS and the provider. Direct Connect reaches the same commitment only through a Multi-Site Redundant Deployment you need to manage; a single Direct Connect connection sits on a 95% tier. The mistake is importing that Resiliency Toolkit habit and provisioning a second Interconnect on the same Region pair for redundancy. That doubles cost without raising the commitment, because both ride the same fabric. Add Interconnects only for a different Region pair.

What stays yours is everything behind the demarcation point: the Direct Connect Gateway association, the Transit Gateway or Core Network Edge, and the workload. SLA eligibility requires the endpoint to span two or more Availability Zones, so a single-AZ target is both an availability risk and outside the commitment.

Key insight: AWS Interconnect turns resiliency from something you architect into something you inherit. The design question moves from "how many circuits and locations" to "is everything behind the Direct Connect Gateway as available as the Interconnect in front of it."

Use AWS Cloud WAN to decouple AWS-Region from Interconnect-Region¶

A virtual private gateway or Transit Gateway can only reach an Interconnect in its own AWS Region, even through a Direct Connect Gateway. Attach that Direct Connect Gateway to AWS Cloud WAN instead and the constraint disappears: any Core Network Edge can reach any Interconnect, so one Interconnect serves workloads in every Region in the core network.

The regional constraint is enforced, not advisory: attaching an Interconnect to a Direct Connect Gateway that is already associated to a Transit Gateway in a remote Region fails outright.

The peer cloud's side is a different story: the peer cloud Region an Interconnect pairs with is fixed by the Interconnect itself, and AWS Cloud WAN does nothing to change that. Landing traffic in a different peer cloud Region means either an Interconnect paired with that Region, or a hop from the paired Region using whatever cross-Region connectivity that cloud offers — which is for you to verify on their side, not something AWS Cloud WAN can do for you. See No supported pair for the Regions you need for when that hop is the right answer.

Watch the pricing tier as the Interconnect's reach grows¶

AWS Interconnect has no per-GB data transfer charge. You pay an hourly rate set by two inputs: the bandwidth you provision, and a pricing tier from 1 (local) to 5 (maximum scope) reflecting the geographic distance between the Interconnect's local Region and the Regions whose traffic uses it. The Interconnect is subscribed to the lowest tier covering every path in use, so the farthest Region sets the price for all of them. A locally associated Transit Gateway or virtual private gateway is always Tier 1, since the association can only be in the Interconnect's local Region. For AWS Cloud WAN, the routing benefit carries a cost consequence. Adding a Core Network Edge re-evaluates the tier, so a new AWS Region can move an Interconnect several tiers up.

For proof-of-concept work, AWS Interconnect - multicloud includes one free local (Tier 1) 500 Mbps interconnect per AWS Region per generally available cloud provider. This free tier covers the AWS side only — check the other provider's pricing.

Plan IPv6 from the start¶

AWS Interconnect supports both IPv4 and IPv6 BGP sessions to the Direct Connect Gateway. Enable IPv6 alongside IPv4 on the Interconnect from the beginning so that when the peer cloud's IPv6 support catches up on your workloads' side, the transport is ready.

When to use AWS Interconnect¶

AWS Interconnect is the right choice when:

The AWS and peer cloud Regions you need are a supported pair, or reachable from one within each cloud.
You want encrypted cloud-to-cloud traffic without running and maintaining IPsec tunnels.
You want to avoid cross-connects at a colocation and BGP and VLAN coordination across two clouds and a facility.
You expect bandwidth to change as workloads evolve, rather than committing to static capacity.

AWS Interconnect is not the right choice when:

The cloud you need isn't supported at all — use partner-based Direct Connect or Site-to-Site VPN between clouds instead.
You already run a colocation footprint or carrier fabric reaching both clouds, and one more cross-connect costs less than inter-Region data transfer on both sides.
The extra hop through a paired Region breaks your latency budget.

No supported pair for the Regions you need¶

An unsupported Region pair is not the same as an unsupported cloud. Land the Interconnect at a pair that is supported and carry each leg the rest of the way inside each cloud.

On the AWS side this is solved: a Direct Connect Gateway attached to an AWS Cloud WAN core network lets any Core Network Edge reach any Interconnect on that gateway, so the Interconnect's Region doesn't have to be the Region your workload runs in. With Transit Gateway instead, inter-Region Transit Gateway peering gets you from the workload Region to the Region whose Interconnect is local. Both routes cost something: the AWS Cloud WAN route can raise the Interconnect's pricing tier, and the Transit Gateway peering route adds inter-Region data transfer charges.

On the peer cloud side, check that provider's documentation for how it carries traffic between its own Regions. The mechanisms, constraints, and charges differ by cloud, so confirm the target Region is reachable from the paired Region — and at what cost — before committing to this design.

Consideration	Extend inside each cloud	Third-party interconnection provider
Parties to manage	AWS and the peer cloud, one Interconnect object	You, the external connectivity provider, and both clouds
Cost shape	Hourly Interconnect charge at the tier the farthest Region sets, with no per-GB on the Interconnect itself, plus (optionally) each cloud's inter-Region data transfer	Provider port and fabric fees plus each cloud's private-connectivity charges
Latency	Predictable, but adds the hop through the paired Region	Can be shorter where the connectivity provider has presence near both target Regions
Encryption	MACsec on the Interconnect hop; each cross-Region leg stays on that cloud's own network	Yours to build, either MACsec in all ports or IPsec overlay
Provisioning	Minutes, through cloud consoles and APIs	Days to weeks, with cross-connects and BGP

Key insight: A missing Region pair is a routing problem before it is a sourcing problem. Ask whether each cloud can carry the last leg internally before taking on a third party, cross-connects, and your own BGP.

Other multi-cloud options¶

These patterns apply where AWS Interconnect doesn't reach: clouds that aren't supported at all, or cases where the backbone path is technically viable but the economics or latency favor building the path yourself.

Partner-based AWS Direct Connect to another cloud¶

The long-established pattern: provision an AWS Direct Connect connection at a Direct Connect location that also houses a peer cloud's equivalent service (Google Cloud Partner Interconnect, Microsoft Azure ExpressRoute, Oracle FastConnect), order a cross-connect or use a virtual interconnection partner's fabric to bridge the two, and configure BGP on each side to advertise prefixes between the clouds.

This gives you private, high-bandwidth connectivity in Regions and cloud pairs that AWS Interconnect doesn't yet support, and it can be the right choice where you already have Direct Connect circuits and a colocation footprint and want to extend the same facility to connect a second cloud.

The trade-offs compared to AWS Interconnect:

Physical and logical cross-connect to manage. Two clouds plus a facility means three parties.
BGP configuration on both sides. The path isn't managed end to end; you configure BGP, maintain the sessions, and debug the combined behavior.
Encryption is your responsibility. Cross-connects at colocation facilities aren't MACsec-encrypted by default. If compliance requires encryption, you run IPsec over the cross-connect, which reintroduces the tunnel overhead AWS Interconnect avoids.
Capacity changes take longer. Scaling bandwidth usually means re-provisioning cross-connects rather than adjusting through a console.

This pattern is the right choice when AWS Interconnect doesn't cover the cloud or Region pair and the traffic volume or latency requirements don't tolerate the internet-based alternative.

AWS Site-to-Site VPN between clouds¶

The simplest multi-cloud option, and sometimes the only option for low-volume or short-lived workloads: establish Site-to-Site VPN from an AWS Transit Gateway or AWS Cloud WAN core network to the peer cloud's VPN gateway. BGP runs over the tunnels and carries prefixes between the clouds.

Internet-based VPN is fast to set up (no physical provisioning), cheap for low-volume workloads, and widely supported. It is also internet-based, which means performance is subject to public internet conditions, and it ties up IPsec throughput on both sides.

Use this when AWS Interconnect isn't available and the workload can tolerate internet-based performance, or for low-volume cloud-to-cloud traffic that doesn't justify a partner-based Direct Connect setup.

Comparing the multi-cloud options¶

Aspect	AWS Interconnect	Partner-based Direct Connect	Site-to-Site VPN between clouds
Transport	AWS global backbone, direct handoff to peer cloud	Dedicated cross-connect at a colocation facility	Public internet
Management model	Fully managed by AWS and the provider	You manage BGP, VLANs, cross-connects across three parties	You manage BGP and IPsec on both sides
Encryption	MACsec by default	Your responsibility (typically IPsec overlay)	IPsec over internet
Provisioning time	Minutes	Days to weeks	Minutes
Capacity changes	Elastic, on demand	Requires cross-connect re-provisioning	Elastic on each cloud
Cost shape	Hourly per Interconnect by bandwidth and distance tier, no per-GB	Port hours, cross-connect fees, and data transfer out	Hourly per connection plus data transfer
SLA	99.99% per Interconnect	Depends on your deployment model: 99.99% multi-site redundant, 99.9% multi-site non-redundant, 95% single connection	99.95% per VPN connection
Coverage today	Selected AWS Region pairs with supported clouds, expanding	All major clouds, subject to colocation footprint	All major clouds
Best for	Supported cloud pairs and Regions, production multi-cloud workloads	Cloud pairs and Regions not yet covered by AWS Interconnect, existing colocation deployments	Low-volume or short-lived workloads where the cloud pair or Region is not yet covered by AWS Interconnect

Documentation¶

AWS Interconnect documentation

Complete service documentation covering both the multicloud and last mile offerings, concepts, attach points, and supported Region pairs.

Documentation
AWS Interconnect pricing

Hourly charges set by provisioned bandwidth and a distance-based pricing tier, with no per-GB data transfer. Cross-connect fees are included in the managed service, unlike the partner-based alternative.

Pricing

Building your hybrid and multi-cloud stack¶

Real-world hybrid and multi-cloud architectures combine several of these services, with each one operating at the layer where it provides the most value.

The services covered in this page are complementary layers, not competing alternatives.

Hybrid and multi-cloud stack showing three tiers: Client communication (Verified Access, Client VPN), Multi-cloud (AWS Interconnect, Partner-based), and Hybrid connectivity (Direct Connect, VPN, SD-WAN) — Hybrid and multi-cloud stack — Drawio Source

New environments¶

Organizations building hybrid and multi-cloud connectivity from scratch have the opportunity to adopt the patterns that scale best from day one:

On-premises path and resiliency: AWS Direct Connect terminating on a Transit Gateway or AWS Cloud WAN core network through a Direct Connect Gateway, designed to the Resiliency Toolkit's maximum resiliency model (multiple connections across multiple locations and providers). Resiliency comes from multiple Direct Connect connections, not from pairing a single Direct Connect with a VPN fallback.
VPN where it adds value: AWS Site-to-Site VPN on the same Transit Gateway or AWS Cloud WAN for fast-start sites that don't yet have Direct Connect, short-lived connectivity, or as an IPsec overlay on top of Direct Connect when MACsec is not available.
Multi-cloud: AWS Interconnect where supported, sharing the same Direct Connect Gateway as the on-premises Direct Connect. Partner-based Direct Connect or Site-to-Site VPN between clouds only where AWS Interconnect coverage isn't there yet.
SD-WAN integration: Transit Gateway Connect or AWS Cloud WAN Connect attachments if the organization already runs SD-WAN across branches and wants that overlay to extend into AWS.
Application access: See Remote Access for AWS Verified Access and AWS Client VPN guidance.

Existing environments¶

Organizations running established hybrid patterns have working foundations that don't need to be replaced:

AWS Direct Connect remains the foundation. If circuits are terminated on virtual private gateways rather than Transit Gateway or AWS Cloud WAN, evaluate consolidating onto a hub through a Direct Connect Gateway as the environment grows.
AWS Site-to-Site VPN remains fully supported. Consider Large tunnels for high-throughput sites and Accelerated VPN for sites distant from the Region.
Partner-based Direct Connect to another cloud keeps working and should not be ripped out for its own sake. Evaluate AWS Interconnect for new multi-cloud pairs or when existing cross-connects come up for renewal.
SD-WAN integrations on Transit Gateway Connect can migrate incrementally to AWS Cloud WAN when multi-Region management complexity grows; AWS Cloud WAN peers with existing Transit Gateways, so SD-WAN traffic doesn't have to move all at once.
AWS Client VPN can coexist with AWS Verified Access during migration. See Remote Access for the recommended migration path.