Amazon Direct Connect FAQs

Amazon Direct Connect is a network service that provides an alternative to using the Internet to utilize Amazon Web Services cloud services.

Using Amazon Direct Connect, data that would have previously been transported over the Internet can now be delivered through a private network connection between Amazon Web Services and your datacenter or corporate network.

In many circumstances, private network connections can reduce costs, increase bandwidth, and provide a more consistent network experience than Internet-based connections.

All Amazon Web Services services, including Amazon Elastic Compute Cloud (EC2), Amazon Virtual Private Cloud (VPC), Amazon Simple Storage Service (S3), and Amazon DynamoDB can be used with Amazon Direct Connect.

Yes. Each Amazon Direct Connect connection can be configured with one or more virtual interfaces. Virtual interfaces may be configured to access Amazon Web Services services such as Amazon EC2 and Amazon S3 using public IP space, or resources in a VPC using private IP space.

Yes. Amazon Direct Connect Partners can help you extend your preexisting data center or office network to an Amazon Direct Connect location.

Use the Amazon Direct Connect tab on the Amazon Web Services Management Console to create a new connection. Then you will change the region to the region you wish to use. When requesting a connection, you will be asked to select the Amazon Direct Connect location you wish to use, the number of ports, and the port speed.

The Amazon Direct Connect Resiliency Toolkit provides a connection wizard that helps you choose between multiple resiliency models. These models help you to determine, and then place an order for, the number of dedicated connections to achieve your SLA objective. You select a resiliency model, and then the Amazon Direct Connect Resiliency Toolkit guides you through the dedicated connection ordering process. The resiliency models are designed to ensure that you have the appropriate number of dedicated connections in multiple locations.

No, a LAG does not make your connectivity to Amazon Web Services more resilient. If you have more than one link in your LAG, and if your min links is set to one, your LAG will let you protect against single link failure. However, it won’t protect against a single device failure at Amazon Web Services where your LAG is terminating.

To achieve high availability connectivity to Amazon Web Services we recommend you to have connections at multiple Amazon Direct Connect locations. You can refer to Direct Connect Resiliency Recommendations to learn more about achieving highly available network connectivity.

We recommend following the resiliency best practices detailed on the Direct Connect Resiliency Recommendations page to determine the best resiliency model to fit your use case. After selecting a resiliency model, the Amazon Direct Connect Resiliency Toolkit can guide you through the process of ordering redundant connections. Amazon Web Services also encourages you to use the Resiliency Toolkit failover test feature to test your configurations before going live.

Each dedicated Direct Connect connection consists of a single dedicated connection between ports on your router and an Amazon Direct Connect device. We recommend establishing a second connection for redundancy. When you request multiple ports at the same Amazon Direct Connect location, they will be provisioned on redundant Amazon Web Services routers.

Yes, Amazon Direct Connect offers an SLA.

Yes, you can configure the duration of the test. You can set minimum and maximum duration for the test to be 1 minute and 180 minutes, respectively.

Yes, you can cancel the test while the test is running. When you cancel the test, we will restore the Border Gateway Protocol session, and your test history will reflect that the test was canceled.

Yes, you can review your test history using the Amazon Web Services Management Console or through CloudTrail. We preserve your test history for 365 days. If you delete the virtual interface, your test history is deleted.

After the configured test duration, we will restore the Border Gateway Protocol session between your on-premises networks and Amazon Web Services using the Border Gateway Protocol session using the parameters negotiated prior to the test initiation.

Only the owner of the Amazon Web Services account that includes the virtual interface can initiate the test.

Yes, you can delete the virtual interface while the test for the same virtual interface is in progress.

Yes, you can run the test for the Border Gateway Protocol session(s) established using any type of virtual interface.

Yes, you can initiate a test for one or both Border Gateway Protocol sessions.

There are no setup charges, and you may cancel at any time. Services provided by Amazon Direct Connect Partners may have other terms or restrictions that apply.

Amazon Direct Connect has two separate charges: port-hours and Data Transfer. Pricing is per port-hour consumed for each port type. Partial port-hours consumed are billed as full hours. The account that owns the port will be charged the port-hour charges.

Data Transfer via Amazon Direct Connect will be billed in the same month in which the usage occurred. See additional Q & A below to understand how Data Transfer will be billed.

No, data transfer between Availability Zones in a region will be billed at the regular regional data transfer rate in the same month in which the usage occurred.

Port-hours are billed once the connection between the Amazon Web Services router and your router is established, or 90 days after you ordered the port, whichever comes first. Port charges will continue to be billed anytime the Amazon Direct Connect port is provisioned for your use. If you no longer wish to be charged for your port, please cancel your direct connect service using console.

Port-hours are billed once you have accepted the Hosted Connection. Port charges will continue to be billed as long as the Hosted Connection is provisioned for your use. If you no longer wish to be charged for your Hosted Connection, please work with the Amazon Direct Connect Partner to cancel the Hosted Connection.

All Hosted Connection port-hour charges at a Direct Connect location are grouped by capacity.
For example, consider the bill for a customer with two separate 200Mbps Hosted Connections at a Direct Connect location, and no other Hosted Connections at that location. The port-hour charges for the two separate 200Mbps Hosted Connections will be summarized under a single item with a label ending in “HCPortUsage:200M”. For a month with 720 total hours, the port-hour total for this item will be 1,440, or the total number of hours in the month multiplied by the total number of 200Mbps Hosted Connections at this location.

The Hosted Connection capacity identifiers which may appear on your bill are as follows:

HCPortUsage:50M
HCPortUsage:100M
HCPortUsage:200M
HCPortUsage:300M
HCPortUsage:400M
HCPortUsage:500M
HCPortUsage:1G
HCPortUsage:2G
HCPortUsage:5G
HCPortUsage:10G

Note that these capacity identifiers will appear by location depending on which Hosted Connection capacities you have at each location.

Amazon Direct Connect data transfer usage will be aggregated to your master account.

For publicly addressable Amazon Web Services 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 Amazon Web Services payer account and actively advertised to Amazon Web Services through an Amazon Direct Connect public virtual Interface, the Data Transfer Out (DTO) usage is metered toward the resource owner at Amazon Direct Connect data transfer rate.

For Amazon Direct Connect pricing information, please see Amazon Direct Connect pricing . If using an Amazon Direct Connect Partner to facilitate a Direct Connect connection, contact the Amazon Direct Connect Partner regarding any fees they may charge.

With the introduction of the granular Data Transfer Out allocation feature, the Amazon Web Services account responsible for the Data Transfer Out will be charged for the Data Transfer Out performed over a transit/private virtual interface. The Amazon account responsible for the Data Transfer Out will be determined based on the customer’s use of the private virtual interface as follows:

• Private virtual interface(s) is used to interface with Amazon Virtual Private Cloud(s) with or without Direct Connect gateway(s). In the case of the private virtual interface, the Amazon Web Services account owning the Amazon Web Services resources responsible for the Data Transfer Out will be charged.

You can cancel Amazon Direct Connect service by deleting your ports from the Amazon Web Services management console. You should also cancel any service(s) offered by a third party. For example, contact the colocation provider to disconnect any cross-connects to Amazon Direct Connect, and/or a network service provider who may be providing network connectivity from your remote locations to the Amazon Direct Connect location.

Except as otherwise noted, our prices are exclusive of applicable taxes and duties, including VAT and applicable sales tax.

For Dedicated Connections, 1Gbps, 10Gbps, and 100Gbps ports are available. 100Gbps ports are available at select locations only. Please refer to this page for more information. For Hosted Connections, capacities of 50Mbps, 100Mbps, 200Mbps, 300Mbps, 400Mbps, 500Mbps, 1Gbps, 2Gbps, 5Gbps and 10Gbps may be ordered from approved Amazon Direct Connect Partners.

No. 100 Gbps is only currently supported on Dedicated Connections.

Amazon Direct Connect supports  1000BASE-LX for 1Gbps, 10GBASE-LR for 10Gbps and 100GBASE-LR4 for 100Gbps connections over single mode fiber using Ethernet transport. Your device must support 802.1Q VLANs. See the Amazon Direct Connect User Guide for more detailed requirements information.

No. You may transfer any amount of data up to the limit of your selected port speed.

Amazon Direct Connect supports 1000BASE-LX or 10GBASE-LR connections over single mode fiber using Ethernet transport. Your device must support 802.1Q VLANs.

Yes, you can advertise up to 100 routes over each Border Gateway Protocol session using Amazon Direct Connect.

Your Border Gateway Protocol session will go down if you advertise more than 100 routes over a Border Gateway Protocol session. This will prevent all network traffic flowing over that virtual interface until you reduce the number of routes to less than 100.

Using direct connect gateway, you can connect to VPCs deployed in any Amazon Web Services Region in China from any Amazon Direct Connect location in China. See the Direct Connect Gateway page to get more details.

Direct connect locations can also access the public resources in Amazon Web Services China Region using a public virtual interface.

Each Amazon Direct Connect location enables connectivity to all Availability Zones within the geographically nearest Amazon Web Services region in China.

Each connection consists of a single dedicated connection between ports on your router and an Amazon Web Services router. We recommend establishing a second connection if redundancy is required. When you request multiple ports at the same Amazon Direct Connect location, they will be provisioned on redundant Amazon Web Services routers. To achieve high availability, we recommend you to have connections at multiple Amazon Direct Connect locations. You can refer to this page to learn more about achieving highly available network connectivity.

If you have established a second Amazon Direct Connect connection, traffic will failover to the second link automatically. We recommend enabling Bidirectional Forwarding Detection (BFD) when configuring your connections to ensure fast detection and failover.

To achieve high availability, we recommend you to have connections at multiple Amazon Direct Connect locations. You can refer to this page to learn more about achieving highly available network connectivity.

No, VLANs are utilized in Amazon Direct Connect only to separate traffic between virtual interfaces.

This connection requires the use of the Border Gateway Protocol (BGP) with an Autonomous System Number (ASN) and IP Prefixes. You will need the following information to complete the connection:

• A public or private ASN. If you are using a public ASN, you must own it. If you are using a private ASN, it must be in the 64512 to 65535 range.
• A new unused VLAN tag that you select
• Public IPs (/30) allocated by you for the BGP session

We will advertise public IP prefixes for the region via BGP. You must advertise public IP prefixes (/30 or smaller) that you own via BGP. For more details, consult the Amazon Direct Connect User Guide .

Autonomous System numbers are used to identify networks that present a clearly defined external routing policy to the Internet. Amazon Direct Connect requires an ASN to create a public or private virtual interface. You may use a public ASN which you own, or you can pick any private ASN number between 64512 to 65535 range.

If you are configuring a virtual interface to the public Amazon Web Services cloud, the IP addresses for both ends of the connection must be allocated from public IP space that you own. If the virtual interface is to a VPC and you choose to have Amazon Web Services auto-generate the peer IP CIDR, the IP address space for both ends of the connection will be allocated by Amazon Web Services.

No.

Not for public Direct Connect virtual interfaces; but you can exchange traffic between the two ports in the same region if they are connecting to the same VGW.

You should advertise appropriate public IP prefixes that you own over BGP. Traffic from Amazon Web Services services destined for these prefixes will be routed over your Amazon Direct Connect connection.

You can procure rack space within the facility housing the Amazon Direct Connect location and deploy your equipment nearby. However, Amazon Web Services customer equipment cannot be placed within Amazon Direct Connect racks or cage areas for security reasons. Once deployed, you can connect this equipment to Amazon Direct Connect using a cross-connect.

Asynchronous BFD is automatically enabled for each Direct Connect virtual interface, but will not take effect until it's configured on your router. Amazon Web Services has set the BFD liveness detection minimum interval to 300, and the BFD liveness detection multiplier to 3.

Support for Transit Gateway is available in all commercial Amazon Web Services Regions.

You can use the Amazon Web Services Management Console or APIs to create transit virtual interface.

Yes, you can allocate transit virtual interface in any Amazon Web Services account.

No, you cannot attach transit virtual interface to your Virtual Private Gateway.

No, you cannot attach private virtual interface to your Amazon Transit Gateway.

Please refer to Amazon Direct Connect limits page to learn more about the limits associated with transit virtual interface.

No, you can create only one transit virtual interface for any Amazon Direct Connect connection of capacity greater than or equal to 1 Gbps.

No, a Direct Connect Gateway can only have one type of virtual interface attached.

No, an Amazon Transit Gateway can only be associated with the Direct Connect gateway attached to transit virtual interface.

It can take up to 40 minutes to establish an association between Amazon Transit Gateway and Amazon Direct Connect gateway.

You can create up to 51 virtual interfaces per 1 Gbps, 10Gbps, or 100 Gbps dedicated connection inclusive of the transit virtual interface.

Yes, you can create one transit virtual interface on any connection of capacity of 1 Gbps or more (1, 2, 5, 10, 100 Gbps).

You can create one transit virtual interface on the 4x10G LAG.

Yes, a transit virtual interface will support jumbo frames. Maximum transmission unit (MTU) size will be limited to 8,500.

Yes, you can continue to use supported BGP attributes (AS_PATH, Local Pref, NO_EXPORT) on the transit virtual interface.

This connection requires the use of Border Gateway Protocol (BGP). You will need the following information to complete the connection:

• A public or private ASN. If you are using a public ASN you must own it. If you are using a private ASN, it must be in the 64512 to 65535 range.
• A new unused VLAN tag that you select
• The VPC Virtual Private Gateway (VGW) ID

Amazon Web Services will allocate private IPs (/30) in the 169.x.x.x range for the BGP session and will advertise the VPC CIDR block over BGP. You can advertise the default route via BGP.

A VPC VPN Connection utilizes IPSec to establish encrypted network connectivity between your intranet and Amazon VPC over the Internet. VPN Connections can be configured in minutes and are a good solution if you have an immediate need, have low to modest bandwidth requirements, and can tolerate the inherent variability in Internet-based connectivity. Amazon Direct Connect does not involve the Internet; instead, it uses dedicated, private network connections between your intranet and Amazon VPC.

Yes. However, only in fail-over scenarios. The Direct Connect path will always be preferred, when established, regardless of AS path prepending.

No, Layer 2 connections are not supported.

Link Aggregation Groups (LAG) are a way for customers to order and manage multiple direct connect ports as a single larger connection instead of as separate discrete connections.

The maximum number of links will be 4x in a LAG group.

You will receive a single LOA document with dedicated page for each connection.

We are using the industry standard of LACP.

We are configuring Dynamic LACP bundles. Static LACP bundles are not supported.

They will be in Active/Active. That means, that Amazon Web Services ports will always be sending Link Aggregation Control Protocol Data Units (LACPDUs).

The MTU does not change.

You could configure LAG at your endpoint with LACP active or passive mode, Amazon Web Services side is always configured as Active mode LACP.

Only like interface types (ie. No mixing 1G and 10G in a bundle).

It will be available for 1G and 10G ports.

No. It will only be available for 1G and 10G Dedicated Connections. It will not be available for Hosted Connections.

Yes, if your ports are on the same chassis. Please note this will cause your ports to go down for a moment while they are reconfigured as a LAG. They will not come back up until LAG is configured on your side as well.

LAG will only include ports on the same Amazon Web Services device. We don’t support multi- chassis LAG.

You can request another port for your LAG, but if we do not have ports available in the same chassis you will need to order a new LAG and migrate your connections. For example, if you have 3x 1G links, and would like to add a fourth but we do not have a port available on that chassis, you will need to order a new LAG of 4x 1G ports.

You will receive a separate LOA for each the new members of the LAG group.

You can have multiple VIFs attached to a VGW at once, and you can configure VIFs on a connection even when it’s down. We suggest you create the new VIFs on your new bundle, and then move the connections over to the new bundle once you’ve created all of your VIFS. Remember to delete the old connections so we stop billing you for them.

Yes, but only if your min links is set to lower than the ports you’ll have left. Ex: You have 4 ports and Min links set to 4 – you won’t be able to delete a port from the bundle. If min links is set to 3, you can then delete a port from the bundle. We will return a notification with the specific panel/port you’ve deleted and a reminder to disconnect the cross connect and circuit from Amazon.

Yes, but just like a regular connection you won’t be able to delete it if you have VIFs configured.

Yes, you can have a single port in a LAG.

Yes you can. Please note we can’t guarantee there will be more ports available on the same
chassis in the future if you wish to add more ports.

Yes. This can be done with the DisassociateConnectionWithLag API call. See the API section.

You can use AssociateVirtualInterface API or console to do this operation.

It will show as a single dxlag and we’ll list the connection id’s under it.

Min links is a feature in LACP where you can set the minimum number of links needed to be active in a bundle for that bundle to be active and pass traffic. If, for example, you have 4 ports, your min links is set to 3, and you only have 2 active ports, your bundle will not be active. If you have 3 or more then the bundle is active and will pass traffic if you have a VIF configured.

We’ll set Min Links to 0 by default.

Yes. You can change the min links value after you’ve set up the bundle, either via console or via API.

When a DirectConnect connection with existing Virtual Interfaces (VIFs) is associated to a LAG, Virtual Interfaces are migrated to the LAG. Please note that certain parameters associated with VIFs needs to be unique like VLAN numbers to be moved to LAG.

BFD is still supported.

We’ll treat all links as equal, so we won’t set “link priority” on any specific link.

Yes. This behavior is exactly like creating VIFs on single ports.

You will need 4x 10GE interfaces on your router to connect to Amazon Web Services. A single 40GE
interface connecting to a 4x 10GE LACP is not supported.

There is no extra charge for LAG.

Configurable Private Autonomous System Number(ASN) allows customers to set the private ASN on the any newly created VGW.

There is no additional charge for this feature.

You can configure/assign an ASN to be advertised as the Amazon Web Services Management Console side ASN during creation of the new Virtual Private Gateway (VGW). You can create a VGW using the VPC console or a EC2/CreateVpnGateway API call.

Amazon Web Services China(Beijing) Region, operated by Sinnet was assigned an ASN of 7224. It’s referred as “legacy public ASN” of the region.

You can assign any private ASN to the Amazon Web Services Management Console side. You can assign the "legacy public ASN" of the region until June 30th 2018. You cannot assign any other public ASN.

We are not validating ownership of the ASNs, therefore, we’re limiting the Amazon Web Services Management Console side ASN to private ASNs. We want to protect customers from BGP spoofing.

You can choose any private ASN. Ranges for 16-bit private ASNs include 64512 to 65534. You can also provide 32-bit ASNs between 4200000000 and 4294967294.

We will provide a default ASN for the VGW if you don’t choose one. Until June 30th 2018, we have provided the “legacy public ASN” of the region. After June 30th 2018, we have started to provide a private ASN of 64512.

We will ask you to re-enter a private ASN once you attempt to create the VGW, unless it is the "legacy public ASN" of the region.

We will provide an ASN for the VGW if you don’t choose one. Until June 30th 2018, We have provided the “legacy public ASN” of the region. After June 30th 2018, We have started to provide an ASN of 64512.

You can view the Amazon Web Services Management Console side ASN in the VGW page of VPC console and in the response of EC2/DescribeVpnGateways API.

Yes, you can configure the Amazon Web Services Management Console side of the BGP session with a private ASN and your side with a public ASN.

You will need to create a new VGW with desired ASN, and create a new VIF with the newly created VGW. Your device configuration also needs to change appropriately.

We will assign 64512 to the Amazon Web Services Management Console side ASN for the new VGW.

You can configure/assign an ASN to be advertised as the Amazon Web Services Management Console side ASN during creation of the new Virtual Private Gateway (VGW). You can create VGW using console or EC2/CreateVpnGateway API call. As noted earlier, we will allow the use of the “legacy public ASN” for your newly created VGW.

We will assign 7224 to the Amazon Web Services Management Console side ASN for the new VIF. The Amazon Web Services Management Console side ASN for your new private VIF is inherited from your existing VGW and defaults to that ASN.

No, you can assign/configure separate Amazon Web Services Management Console side ASN for each VGW, not each VIF. Amazon Web Services Management Console side ASN for VIF is inherited from the Amazon Web Services Management Console side ASN of the attached VGW.

When creating a VGW in the VPC console, uncheck the box asking if you want an auto-generated BGP ASN and provide your own private ASN for the Amazon Web Services Management Console half of the BGP session. Once VGW is configured with Amazon Web Services Management Console side ASN, the private VIFs created using the VGW will use your Amazon Web Services Management Console side ASN.

You will not have to make any changes.

We will support 32-bit ASNs from 4200000000 to 4294967294.

No, you cannot modify the Amazon Web Services Management Console side ASN after creation. You can delete the VGW and recreate a new VGW with the desired ASN.

No. You can do this with the same API as before (EC2/CreateVpnGateway). We just added a new parameter (Amazon Web Services Management Console Side ASN) to this API.

No. You can view the Amazon Web Services Management Console side ASN with the same EC2/DescribeVpnGateways API. We just added a new parameter (Amazon Web Services Management Console Side ASN) to this API.

Direct Connect gateway is a grouping of virtual private gateways (VGWs) and private virtual interfaces (VIFs).

Yes, you can associate Amazon Virtual Private Clouds (Amazon VPCs) owned by any Amazon Web Services account with a Direct Connect gateway owned by any Amazon Web Services account.

You can use the Amazon Web Services Management Console or Amazon Direct Connect APIs to use multi-account support for the Direct Connect gateway. If you are the owner of the Direct Connect gateway, follow the steps outline in the Amazon Direct Connect user guide.

It provides two main functions.

First; Direct Connect gateway will enable you to interface with VPCs in any Amazon Web Services China Region, enabling you to use your Amazon Direct Connect connections in any Amazon Direct Connect China location to interface with more than one Amazon Web Services China Region.

Second; you can share a private virtual interface to interface with up to ten Virtual Private Clouds (VPCs), enabling you to reduce the number of Border gateway Protocol sessions between your on-premises network and Amazon Web Services deployments.

No. When using Direct Connect gateway, your traffic will take the shortest path from your Direct Connect location to the destination Amazon Web Services China Region and vice versa regardless of the associated home Amazon Web Services China Region of the Direct Connect location that you are connected at.

There are no charges for using a Direct Connect gateway. You will pay applicable egress data charges based on the source remote Amazon Web Services China Region and port hour charges as per Amazon Direct Connect pricing .

Yes, private virtual interface and Direct Connect gateway must be in the same Amazon Web Services account to use Direct Connect gateway functionality.

Virtual private gateway(s) can be in different Amazon Web Services accounts then the account owning the Direct Connect gateway.

Yes, Networking features such as Elastic File System, Elastic Load Balancer, Application Load Balancer, Security Groups, Access Control List, Amazon PrivateLink will still work with Direct Connect gateway.

Features that are currently not supported by Direct Connect, such as edge-to-edge routing, VPC peering, VPC endpoint, will not be supported by Direct Connect gateway.

Yes, you can associate a provisioned private virtual interface with your Direct Connect gateway when you confirm your provisioned Private in your Amazon Web Services account.

You can continue to use the current practice of attaching your VIF to VGW; you will continue to have intra-region VPC connectivity, and will be charged egress rate that is applicable based on geographical regions.

Please refer to Amazon Direct Connect Limits to get limits associated with the Direct Connect gateway feature.

No, a VGW-VPC pair cannot be part of more than one Direct Connect gateway.

No, one private virtual interface can only attach to a single Direct Connect gateway OR a single Virtual Private Gateway. We recommend that you follow Amazon Direct Connect resiliency recommendations and attach more than one private virtual interface.

Yes, as long as the IP CIDR blocks of the Amazon VPC associated with the Virtual Private Gateway do not overlap.

No, Direct Connect gateway does not break existing CloudHub for customers. Direct Connect gateway enables connectivity between on-premise networks and any Amazon region's VPC. CloudHub enables connectivity between on-premise network using Direct Connect or customer-owned VPN within the same region the VIF is associated with the VGW directly. Existing CloudHub functionality will continue to be supported.

Please refer to Amazon Direct Connect User Guide to review supported and not supported traffic patterns.

Yes, customers will still be able to attach a Direct Connect VIF directly to a VGW to support CloudHub

No, an existing private virtual interface associated with VGW cannot be associated with the Direct Connect gateway. Please create a new private virtual interface, and at the time of creation, associate with your Direct Connect gateway.

No. You can continue using your already created CloudHub.

No, you cannot associate an unattached VGW to Direct Connect gateway.

Traffic from your on-premise network to the detached VPC will stop, and VGW's association with the Direct Connect gateway will be deleted.

Traffic from your on-premise network to the detached VGW (associated with a VPC) will stop.

No, Direct Connect gateway only supports routing traffic from Direct Connect VIFs to VGW (associated with VPC). In order to send traffic between 2 VPCs, you would configure a VPC peering connection, the same as you do today.

You can detach a VGW-VPC pair from a Direct Connect gateway using the Amazon Web Services Management Console or API.

Yes, you can resize the Amazon VPC. If you re-size your Amazon VPC, you must re-send the proposal with the re-sized VPC CIDR to the Direct Connect gateway owner. Once the Direct Connect gateway owner approves the new proposal, the re-sized VPC CIDR will be advertised towards your on-premise network.

Yes, Direct Connect gateway offers a way for you to selectively announce prefixes towards your on-premise networks. As the owner of the Direct Connect gateway, you can override the prefixes being advertised towards the on-premises network before you accept the association proposal OR when you can update the association request with allowed prefixes.

For prefixes getting advertised from your on-premise networks, each VPC associated with a Direct Connect gateway will receive all prefixes announced from your on-premises networks.

If you want to limit traffic to and from any specific Amazon VPC, you should consider using Access Control Lists (ACLs) for each VPC.

Configurable Private Autonomous System Number (ASN). This allows customers to set the ASN on the Amazon side of the BGP session for private VIFs on any newly created Direct Connect Gateway.

Amazon Web Services China(Beijing) Region, operated by Sinnet and Amazon Web Services China(Ningxia) region, operated by NWCD.

You can configure/assign an ASN to be advertised as the Amazon side ASN during creation of the new Direct Connect gateway. You can create a Direct Connect Gateway using the Amazon Direct Connect console or a CreateDirectConnectGateway API call.

You can assign any private ASN to the Amazon side. You cannot assign any other public ASN.

Amazon is not validating ownership of the ASNs, therefore we're limiting the Amazon-side ASN to private ASNs. We want to protect customers from BGP spoofing.

You can choose any private ASN. Ranges for 16-bit private ASNs include 64512 to 65534. You can also provide 32-bit ASNs between 4200000000 and 4294967294.

We will ask you to re-enter a private ASN once you attempt to create the Direct Connect Gateway.

Amazon will provide an ASN of 64512 for the Direct Connect Gateway if you don't choose one.

You can view the Amazon side ASN in the Amazon Direct Connect console and in the response of the DescribeDirectConnectGateways or using DescribeVirtualInterfaces API.

Yes, you can configure the Amazon side of the BGP session with a private ASN and your side with a public ASN.

You will need to create a new Direct Connect Gateway with desired ASN, and create a new VIF with the newly created Direct Connect Gateway. Your device configuration also needs to change appropriately.

No, you can assign/configure separate Amazon side ASN for each Direct Connect Gateway, not each VIF. Amazon side ASN for VIF is inherited from the Amazon side ASN of the attached Direct Connect Gateway.

Yes, you can use different private ASNs for your Direct Connect Gateway and Virtual Private Gateway. Please note, the Amazon side ASN you will receive depends on your private virtual interface association.

Yes, you can use same private ASNs for your Direct Connect Gateway and Virtual Private Gateway. Please note, the Amazon side ASN you will receive depends on your private virtual interface association.

Direct Connect Gateway private ASN will be used as the Amazon side ASN for the Border Gateway Protocol (BGP) session between your network and Amazon Web Services.

When creating a Direct Connect Gateway in the Amazon Direct Connect Gateway console. Once Direct Connect Gateway is configured with Amazon side ASN, the private virtual interfaces associated with the Direct Connect Gateway will use your configured ASN as the Amazon side ASN.

You will not have to make any changes.

We will support 32-bit ASNs from 4200000000 to 4294967294.

No, you cannot modify the Amazon side ASN after creation. You can delete the Direct Connect gateway and recreate a new Direct Connect gateway with the desired private ASN.

Amazon Direct Connect support both 1500 and 9001 Maximum Transmission Unit (MTU). MTU is a configurable option on the Amazon Direct Connect Private Virtual Interface.

• If you own both the Amazon Direct Connect port and the Virtual Private Interface, you can modify the MTU of an existing Virtual Interface or you can create a new Virtual Interface with 9001 MTU using API, CLI or Console.
• If the Amazon Direct Connect port is owned by another Amazon Web Services account, the port owner will need to enable Jumbo Frames on the port by modifying the MTU on an existing Virtual Interface or create a new Virtual Interface with 9001 MTU.
• If your Amazon Direct Connect port is provided by Amazon Direct Connect Partner, then you need to check if the port is Jumbo Frames capable using API, CLI or console. If the port is Jumbo Frames capable, you can modify the MTU setting on the Virtual Interface. Otherwise, the Amazon Direct Connect Partner will need to contact Amazon Web Services support to make the port Jumbo Frames capable.

Jumbo Frames only apply to propagated routes from Direct Connect. If you add static routes pointing to your Virtual Private Gateway to the route table, traffic routed through static routes will be sent using a 1500 MTU.

If two virtual interfaces advertise the same route, but use different MTUs, the lowest of the MTUs will be used for both virtual interfaces.

If the destination port is not Jumbo Frames capable then you cannot move the Jumbo Frames enabled Virtual Interface to it. You will need to disable Jumbo Frames on the Virtual Interface and move it then re-enable Jumbo Frames. Alternatively, you can enable Jumbo on any Virtual Interface on the destination connection before moving the Jumbo Frames enabled Virtual Interface.

Yes, if the owner of an Amazon Direct Connect port (with Jumbo Frames not enabled on any virtual interface) creates a Jumbo Frame enabled Private Virtual Interface for the first time, there will be expected downtime of 5 to 30 seconds on the physical port. Other virtual interfaces on this port, regardless of their account, will also observe this downtime. If the physical port has at least one Virtual Interface that is Jumbo Frames enabled, then there will be no downtime observed on the physical interface.

You will need to enable Jumbo Frames for at least one Private Virtual Interface in the LAG to enable Jumbo Frames on the LAG.

This feature provides support for local preference communities for private virtual interfaces. With communities, customers can influence the return path for traffic sourced from both VPC address space.

Yes, all existing BGP sessions on private virtual interfaces support the use of local preference communities.

No, this feature is currently available for private virtual interfaces only.

Yes, this feature will work with private virtual interfaces attached with Direct Connect Gateway.

No, at this time we do not provide such monitoring features.

There is no additional charge for using this feature.

The following communities are supported for private virtual interface and are evaluated in order of lowest to highest preference. Communities are mutually exclusive. Prefixes marked with the same communities, and bearing identical MED*, AS_PATH attributes are candidates for multi-pathing.

7224:7100 – Low Preference

7224:7200 – Medium Preference

7224:7300 – High Preference

If you do not specify Local Preference communities for your private VIF, the default local preference is based on the distance to the Direct Connect Locations from the local region. In such situation, egress behavior across multiple VIFs from multiple Direct Connect Locations may be arbitrary.

Yes, you can use this feature to influence egress traffic behavior between two VIFs.

Yes, you can use community based routing to enable load balancing across Direct Connect locations; To do so, any prefixes requiring load-balancing must be marked with the same communities.

Yes, This can be accomplished by advertising prefixes over the primary/active virtual interface with a community for higher local preference than prefixes advertised over the backup/passive virtual interface; This feature is backwards compatible with pre-existing methods for achieving failover; if your Direct Connect is currently configured for failover, no additional changes are necessary.

No, we will continue to respect AS_PATH attribute. This feature is additional knob you can use to get better control over the incoming traffic from Amazon Web Services; Direct Connect follows the standard approach for path selection; Bear in mind that local preference is evaluated before the AS_PATH attribute.

Yes. by marking the 10.10.1.0/24 prefix advertised over the 10G Direct Connection with a community of a higher local preference, it will be the preferred path; In the event that the 10G fails or the prefix withdrawn, the 1G interface will become the return path.

We will multipath per prefix at up to 16 next-hops wide, where each next-hop is a unique Amazon Web Services endpoint.