# What is Direct Connect? Direct Connect links your internal network to an Direct Connect location over a standard Ethernet fiber-optic cable. One end of the cable is connected to your router, the other to an Direct Connect router. With this connection, you can create *virtual interfaces* directly to public AWS services (for example, to Amazon S3) or to Amazon VPC, bypassing internet service providers in your network path. An Direct Connect location provides access to AWS in the Region with which it is associated. You can use a single connection in a public Region or AWS GovCloud (US) to access public AWS services in all other public Regions. + For a list of Direct Connect locations you can connect to, see [AWS Direct Connect Locations](https://aws.amazon.com/directconnect/locations/). + For answers to questions about Direct Connect, see the [Direct Connect FAQ](https://aws.amazon.com/directconnect/faqs/#AWS_Transit_Gateway_support/). The following diagram shows a high-level overview of how Direct Connect interfaces with your network. ![\[Direct Connect\]](http://docs.aws.amazon.com/directconnect/latest/UserGuide/images/dx-vifs.png) **Topics** + [Direct Connect components](#overview-components) + [ ## Network requirements ](#overview_requirements) + [ ## Supported Direct Connect virtual interface types ](#dx-vif-types) + [Pricing for Direct Connect](#Paying) + [Access to remote AWS Regions](remote_regions.md) + [Routing policies and BGP communities](routing-and-bgp.md) ## Direct Connect components The following are the key components that you use for Direct Connect: **Connections** Create a *connection* in an Direct Connect location to establish a network connection from your premises to an AWS Region. For more information, see [Direct Connect dedicated and hosted connections](WorkingWithConnections.md). **Virtual interfaces** Create a *virtual interface* to enable access to AWS services. A public virtual interface enables access to public services, such as Amazon S3. A private virtual interface enables access to your VPC. The types of supported interfaces are described below in [Supported Direct Connect virtual interface types](#dx-vif-types). For more details about the supported interfaces, see [Direct Connect virtual interfaces and hosted virtual interfaces](WorkingWithVirtualInterfaces.md) and [Prerequisites for virtual interfaces](WorkingWithVirtualInterfaces.md#vif-prerequisites). ## Network requirements To use Direct Connect in an Direct Connect location, your network must meet one of the following conditions: + Your network is colocated with an existing Direct Connect location. For more information about available Direct Connect locations, see [AWS Direct Connect Product Details](https://aws.amazon.com/directconnect/details). + You are working with an Direct Connect partner who is a member of the AWS Partner Network (APN). For information, see [APN Partners Supporting AWS Direct Connect](https://aws.amazon.com//directconnect/partners/). + You are working with an independent service provider to connect to Direct Connect. In addition, your network must meet the following conditions: + Your network must use single-mode fiber with a 1000BASE-LX (1310 nm) transceiver for 1 gigabit Ethernet, a 10GBASE-LR (1310 nm) transceiver for 10 gigabit, a 100GBASE-LR4 for 100 gigabit Ethernet, or a 400GBASE-LR4 for 400 Gbps Ethernet. + Depending on the AWS Direct Connect endpoint serving your connection, on-premises device auto-negotiation might need to be enabled or disabled for any dedicated connection. If a virtual interface remains down when a Direct Connect connection is up, see [Troubleshoot layer 2 (data link) issues](ts-layer-2.md). + 802.1Q VLAN encapsulation must be supported across the entire connection, including intermediate devices. + Your device must support Border Gateway Protocol (BGP) and BGP MD5 authentication. + (Optional) You can configure Bidirectional Forwarding Detection (BFD) on your network. Asynchronous BFD is automatically enabled for each Direct Connect virtual interface. It's automatically enabled for Direct Connect virtual interfaces, but does not take effect until you configure it on your router. For more information, see [Enable BFD for a Direct Connect connection](https://aws.amazon.com/premiumsupport/knowledge-center/enable-bfd-direct-connect/). Direct Connect supports both the IPv4 and IPv6 communication protocols. IPv6 addresses provided by public AWS services are accessible through Direct Connect public virtual interfaces. Direct Connect supports an Ethernet frame size of 1522 or 9023 bytes (14 bytes Ethernet header \$1 4 bytes VLAN tag \$1 bytes for the IP datagram \$1 4 bytes FCS) at the link layer. You can set the MTU of your private virtual interfaces. For more information, see [MTUs for private virtual interfaces or transit virtual interfaces](WorkingWithVirtualInterfaces.md#set-jumbo-frames-vif). ## Supported Direct Connect virtual interface types AWS Direct Connect supports the following three virtual interface (VIF) types: + **Private virtual interface** This type of interface is used to access an Amazon Virtual Private Cloud (VPC) using private IP addresses. With a private virtual interface you can + Connect directly to a single VPC per private virtual interface to access those resources using private IPs in the same Region. + Connect a private virtual interface to a Direct Connect gateway to access multiple virtual private gateways across any account and AWS Region (except the AWS China Regions). + **Public virtual interface** This type of virtual interface is used to access all AWS public services using public IP addresses. With a public virtual interface you can connect to all AWS public IP addresses and services globally. + **Transit virtual interface** This type of interface is used to access one or more Amazon VPC Transit Gateways associated with Direct Connect gateways. With a transit virtual interface you connect multiple Amazon VPC Transit Gateways across multiple accounts and AWS Regions (except the AWS China Regions). **Note** There are limits to the number of different types of associations between a Direct Connect gateway and a virtual interface. For more information about specific limits, see the [Direct Connect quotas](limits.md) page. For more information about virtual interfaces, see [Direct Connect virtual interfaces and hosted virtual interfaces](WorkingWithVirtualInterfaces.md). ## Pricing for Direct Connect AWS Direct Connect has two billing elements: port hours and outbound data transfer. Port hour pricing is determined by capacity and connection type (dedicated connection or hosted connection). Data Transfer Out charges for private interfaces and transit virtual interfaces are allocated to the AWS account responsible for the Data Transfer. There are no additional charges to use a multi-account AWS Direct Connect gateway. For publicly addressable AWS resources (for example, Amazon S3 buckets, Classic EC2 instances, or EC2 traffic that goes through an internet gateway), if the outbound traffic is destined for public prefixes owned by the same AWS payer account and actively advertised to AWS through an Direct Connect public virtual Interface, the Data Transfer Out (DTO) usage is metered toward the resource owner at Direct Connect data transfer rate. For more information, see [AWS Direct Connect Pricing](https://aws.amazon.com/directconnect/pricing/). # Access to remote Direct Connect Regions Direct Connect locations in public Regions or AWS GovCloud (US) can access public services in any other public Region (excluding China (Beijing and Ningxia)). In addition, Direct Connect connections in public Regions or AWS GovCloud (US) can be configured to access a VPC in your account in any other public Region (excluding China (Beijing and Ningxia). You can therefore use a single Direct Connect connection to build multi-Region services. All networking traffic remains on the AWS global network backbone, regardless of whether you access public AWS services or a VPC in another Region. Any data transfer out of a remote Region is billed at the remote Region data transfer rate. For more information about data transfer pricing, see the [Pricing](http://aws.amazon.com/directconnect/pricing/) section on the AWS Direct Connect detail page. For more information about the routing policies and supported BGP communities for an Direct Connect connection, see [Routing policies and BGP communities](routing-and-bgp.md). ## Access to public services in a remote Region To access public resources in a remote Region, you must set up a public virtual interface and establish a Border Gateway Protocol (BGP) session. For more information, see [Virtual interfaces and hosted virtual interfaces](WorkingWithVirtualInterfaces.md). After you have created a public virtual interface and established a BGP session to it, your router learns the routes of the other public AWS Regions. For more information about prefixes currently advertised by AWS, see [AWS IP Address Ranges](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) in the *Amazon Web Services General Reference*. ## Access to VPCs in a remote Region You can create a *Direct Connect gateway* in any public Region. Use it to connect your Direct Connect connection over a private virtual interface to VPCs in your account that are located in different Regions or to a transit gateway. For more information, see [Direct Connect gateways](direct-connect-gateways.md). Alternatively, you can create a public virtual interface for your Direct Connect connection and then establish a VPN connection to your VPC in the remote Region. For more information about configuring VPN connectivity to a VPC, see [Scenarios for Using Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenarios.html) in the *Amazon VPC User Guide*. ## Network-to-Amazon VPC Connectivity Options The following configuration can be used to connect remote networks with your Amazon VPC environment. These options are useful for integrating AWS resources with your existing on-site services: + [Amazon Virtual Private Cloud Connectivity Options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/welcome.html) # Direct Connect routing policies and BGP communities Direct Connect applies inbound (from your on-premises data center) and outbound (from your AWS Region) routing policies for a public Direct Connect connection. You can also use Border Gateway Protocol (BGP) community tags on routes advertised by Amazon and apply BGP community tags on the routes you advertise to Amazon. ## Public virtual interface routing policies If you're using Direct Connect to access public AWS services, you must specify the public IPv4 prefixes or IPv6 prefixes to advertise over BGP. The following inbound routing policies apply: + You must own the public prefixes and they must be registered as such in the appropriate regional internet registry. + Traffic must be destined to Amazon public prefixes. Transitive routing between connections is not supported. + Direct Connect performs inbound packet filtering to validate that the source of the traffic originated from your advertised prefix. The following outbound routing policies apply: + AS\$1PATH and Longest Prefix Match are used to determine the routing path. AWS recommends advertising more specific routes using Direct Connect if the same prefix is being advertised to both the Internet and to a public virtual interface. + Direct Connect advertises all local and remote AWS Region prefixes where available and includes on-net prefixes from other AWS non-Region points of presence (PoP) where available; for example, CloudFront and Route 53. **Note** Prefixes listed in the AWS IP address ranges JSON file, ip-ranges.json, for the AWS China Regions are only advertised in the AWS China Regions. Prefixes listed in the AWS IP address ranges JSON file, ip-ranges.json, for the AWS Commercial Regions are only advertised in the AWS Commercial Regions. For more information about the ip-ranges.json file, see [AWS IP address ranges ](https://docs.aws.amazon.com//general/latest/gr/aws-ip-ranges.html) in the *AWS General Reference*. + Direct Connect advertises prefixes with a minimum path length of 3. + Direct Connect advertises all public prefixes with the well-known `NO_EXPORT` BGP community. + If you advertise the same prefixes from two different Regions using two different public virtual interfaces, and both have the same BGP attributes and longest prefix length, AWS will prioritize the home Region for outbound traffic. + If you have multiple Direct Connect connections, you can adjust the load-sharing of inbound traffic by advertising prefixes with the same path attributes. + The prefixes advertised by Direct Connect must not be advertised beyond the network boundaries of your connection. For example, these prefixes must not be included in any public internet routing table. + Direct Connect keeps prefixes advertised by customers within the Amazon network. We do not re-advertise customer prefixes learned from a public VIF to any of the following: + Other Direct Connect customers + Networks that peer with the AWS Global Network + Amazon's transit providers + When using a public interface, you can use either a public or private ASN. However, there are important considerations: + Public ASNs: You must own the ASN and have the right to announce it. AWS will verify your ownership of the ASN. Both ASNs (1-2147483647) and long ASNs (1-4294967295) are supported. + Private ASNs: You can use private ASNs from the following ranges: + private ASNs: 64512-65534 + private long ASNs: 4200000000-4294967294 However, Direct Connect will replace the private ASN with the AWS ASN (7224) when advertising your prefixes to other AWS customers or the internet. + ASN prepending: + With a public ASN (both ASN and long ASN), prepending will work as expected, and your prepended ASN will be visible to other networks. + With a private ASN (both ASN and long ASN, any prepending you do will be stripped when AWS replaces your private ASN with 7224. This means ASN prepending is not effective for influencing routing decisions outside of AWS when using a private ASN on a public virtual interface. + When establishing a BGP peering session with AWS over a public virtual interface, use 7224 for the autonomous system numbers (ASN) to establish the BGP session on the AWS side. The ASN on your router or customer gateway device should be different from that ASN. Your customer ASN can be either anASN (1-2147483647, excluding reserved ranges) or a long ASN (1-4294967295, excluding reserved ranges). ## Public virtual interface BGP communities Direct Connect supports scope BGP community tags to help control the scope (Regional or global) and route preference of traffic on public virtual interfaces. AWS treats all routes received from a public VIF as if they were tagged with the NO\$1EXPORT BGP community tag, meaning only the AWS network will use that routing information. ### Scope BGP communities You can apply BGP community tags on the public prefixes that you advertise to Amazon to indicate how far to propagate your prefixes in the Amazon network, for the local AWS Region only, all Regions within a continent, or all public Regions. #### AWS Region communities For inbound routing policies, you can use the following BGP communities for your prefixes: + `7224:9100`—Local AWS Regions + `7224:9200`—All AWS Regions for a continent: + North America-wide + Asia Pacific + Europe, the Middle East and Africa + `7224:9300`—Global (all public AWS Regions) **Note** If you do not apply any community tags, prefixes are advertised to all public AWS Regions (global) by default. Prefixes that are marked with the same communities, and have identical AS\$1PATH attributes are candidates for multi-pathing. The communities `7224:1` – `7224:65535` are reserved by Direct Connect. For outbound routing policies, Direct Connect applies the following BGP communities to its advertised routes: + `7224:8100`—Routes that originate from the same AWS Region in which the Direct Connect point of presence is associated. + `7224:8200`—Routes that originate from the same continent with which the Direct Connect point of presence is associated. + No tag—Routes that originate from other continents. **Note** To receive all AWS public prefixes do not apply any filter. Communities that are not supported for an Direct Connect public connection are removed. ### `NO_EXPORT` BGP community For outbound routing policies, the `NO_EXPORT` BGP community tag is supported for public virtual interfaces. Direct Connect also provides BGP community tags on advertised Amazon routes. If you use Direct Connect to access public AWS services, you can create filters based on these community tags. For public virtual interfaces, all routes that Direct Connect advertises to customers are tagged with the NO\$1EXPORT community tag. ## Private virtual interface and transit virtual interface routing policies If you're using AWS Direct Connect to access your private AWS resources, you must specify the IPv4 or IPv6 prefixes to advertise over BGP. These prefixes can be public or private. The following outbound routing rules apply based on the prefixes advertised: + AWS evaluates the longest prefix length first. AWS recommends advertising more specific routes using multiple Direct Connect virtual interfaces if the desired routing paths are meant for active/passive connections. See [ Influencing Traffic over Hybrid Networks using Longest Prefix Match](https://aws.amazon.com/blogs/networking-and-content-delivery/influencing-traffic-over-hybrid-networks-using-longest-prefix-match/) for more information. + Local preference is the BGP attribute recommended to use when desired routing paths are meant for active/passive connections and the prefix lengths advertised are the same. This value is set per Region to prefer [AWS Direct Connect Locations](https://aws.amazon.com/directconnect/locations/) that have the same associated AWS Region using the `7224:7200`—Medium local preference community value. Where the local Region is not associated with the Direct Connect location, it is set to a lower value. This applies only if no local preference community tags are assigned. + AS\$1PATH length can be used to determine the routing path when the prefix length and local preference are the same. + Multi-Exit Discriminator (MED) can be used to determine the routing path when prefix length, local preference, and AS\$1PATH are the same. AWS does not recommend using MED values given their lower priority in evaluation. + AWS uses equal-cost multi-path (ECMP) routing across multiple transit or private virtual interfaces when prefixes have the same AS\$1PATH length and BGP attributes. The ASNs in the AS\$1PATH of the prefixes do not need to match. ### Private virtual interface and transit virtual interface BGP communities When an AWS Region routes traffic to on-premises locations via Direct Connect private or transit virtual interfaces, the associated AWS Region of the Direct Connect location influences the ability to use ECMP. AWS Regions prefer Direct Connect locations in the same associated AWS Region by default. See [AWS Direct Connect Locations](https://aws.amazon.com/directconnect/locations/) to identify the associated AWS Region of any Direct Connect location. When there are no local preference community tags applied, Direct Connect supports ECMP over private or transit virtual interfaces for prefixes with the same, AS\$1PATH length, and MED value over two or more paths in the following scenarios: + The AWS Region sending traffic has two or more virtual interface paths from locations in the same associated AWS Region, whether in the same or different colocation facilities. + The AWS Region sending traffic has two or more virtual interface paths from locations not in the same Region. Fore more information, see [How do I set up an Active/Active or Active/Passive Direct Connect connection to AWS from a private or transit virtual interface?](https://repost.aws/knowledge-center/direct-connect-private-transit-interface/) **Note** This has no effect on ECMP to an AWS Region from on-premises locations. To control route preferences, Direct Connect supports local preference BGP community tags for private virtual interfaces and transit virtual interfaces. #### Local preference BGP communities You can use local preference BGP community tags to achieve load balancing and route preference for incoming traffic to your network. For each prefix that you advertise over a BGP session, you can apply a community tag to indicate the priority of the associated path for returning traffic. The following local preference BGP community tags are supported: + `7224:7100`—Low preference + `7224:7200`—Medium preference + `7224:7300`—High preference Local preference BGP community tags are mutually exclusive. To load balance traffic across multiple Direct Connect connections (active/active) homed to the same or different AWS Regions, apply the same community tag; for example, `7224:7200` (medium preference) across the prefixes for the connections. If one of the connections fails, traffic will be then load balance using ECMP across the remaining active connections regardless of their home Region associations . To support failover across multiple Direct Connect connections (active/passive), apply a community tag with a higher preference to the prefixes for the primary or active virtual interface and a lower preference to the prefixes for the backup or passive virtual interface. For example, set the BGP community tags for your primary or active virtual interfaces to `7224:7300` (high preference) and `7224:7100` (low preference) for your passive virtual interfaces. Local preference BGP community tags are evaluated before any AS\$1PATH attribute, and are evaluated in order from lowest to highest preference (where highest preference is preferred). # Long ASN support in Direct Connect Support for long ASNs (4-byte) allows you to configure long Autonomous System Numbers (ASNs) as part of the parameters of the BGP session established between the AWS network device and your network device. This feature is enabled or disabled on a per-account basis. You can set the an ASN or Long ASN range on either the console or through the APIs. + When using the console, the **ASN** field supports both ASNs and long ASNs. You can add any range from 1 to 4294967294. + When using the APIs to create a virtual interface, you can specify either an ASN (`asn`) or the Long ASN (`asnLong`) but not both. For more information on using ASN or Long ASN, see the following APIs in the [https://docs.aws.amazon.com/directconnect/latest/APIReference/Welcome.html](https://docs.aws.amazon.com/directconnect/latest/APIReference/Welcome.html): + `BGPPeer` + `DeleteBGPPeerRequest` + `NewBGPPeer` + `NewPrivateVirtualInterface` + `NewPrivateVirtualInterfaceAllocation` + `NewPublicVirtualInterface` + `NewPublicVirtualInterfaceAllocation` + `NewTransitVirtualInterface` + `NewTransitVirtualInterfaceAllocation` + `VirtualInterface` ## Considerations When choosing to use either an ASN or a long ASN, note the following: + **Backward compatibility**: Direct Connect automatically handles BGP sessions with both ASN and long ASN-capable routers. If your router doesn't support long ASNs, the BGP session will operate in ASN mode. + **ASN format**: You can specify 4-byte ASNs in either asplain format —for example, `4200000000` or asdot format — for example, `64086.59904`. Direct Connect accepts both formats but displays ASNs in asplain format + **Private ASN ranges:** When using private long ASNs (`4200000000-4294967294`), the same replacement behavior applies as with private ASNs. Direct Connect will replace your private ASN with `7224` when advertising to other networks. + **BGP community tags**: All existing BGP community tags (`7224:xxxx`) work with long ASNs. The community tag format remains unchanged. + **Monitoring and troubleshooting**: CloudWatch metrics, BGP session logs, and troubleshooting tools display long ASNs in asplain format for consistency. ## Availability and Pricing Note the following for long ASN support with Direct Connect: + **Availability**: Long ASN is available in all AWS Regions where Direct Connect is supported. + **Pricing**: There are no additional charges for long ASN support beyond standard Direct Connect pricing. **Note** Long ASN enablement applies to your entire AWS account. You cannot enable long ASN support for individual virtual interfaces or BGP peers. # Direct Connect private virtual interface routing example Consider the configuration where the Direct Connect location 1 home Region is the same as the VPC home Region. There is a redundant Direct Connect location in a different Region There are two private VIFs (VIF A and VIF B) from Direct Connect location 1 (us-east-1) to the Direct Connect gateway. There is one private VIF (VIF C) from Direct Connect location (us-west-1) to the Direct Connect gateway. To have AWS route traffic over VIF B before VIF A, set the AS\$1PATH attribute of VIF B to be shorter than the VIF A AS\$1PATH attribute. The VIFs have the following configurations: + VIF A (in us-east-1) advertises 172.16.0.0/16 and has an AS\$1PATH attribute of 65001, 65001, 65001 + VIF B (in us-east-1) advertises 172.16.0.0/16 and has an AS\$1PATH attribute of 65001, 65001 + VIF C (in us-west-1) advertises 172.16.0.0/16 and has an AS\$1PATH attribute of 65001 ![\[Private VIF Routing no AS_PATH\]](http://docs.aws.amazon.com/directconnect/latest/UserGuide/images/private-vif-as-path-1.png) If you change the CIDR range configuration of VIF C, routes that fall in to the VIF C CIDR range use VIF C because it has the longest prefix length. + VIF C (in us-west-1) advertises 172.16.0.0/24 and has an AS\$1PATH attribute of 65001 ![\[Private VIF Routing\]](http://docs.aws.amazon.com/directconnect/latest/UserGuide/images/private-vif-as-path-2.png)