Q. What is AWS Direct Connect?
AWS Direct Connect is a network service that provides an alternative to using the Internet to utilize AWS cloud services.
Q. What can I do with AWS Direct Connect?
Using AWS Direct Connect, data that would have previously been transported over the Internet can now be delivered through a private network connection between AWS and your datacenter or corporate network.
Q. What are the benefits of using AWS Direct Connect and private network connections?
In many circumstances, private network connections can reduce costs, increase bandwidth, and provide a more consistent network experience than Internet-based connections.
Q. Which AWS services can be used with AWS Direct Connect?
All AWS services, including Amazon Elastic Compute Cloud (EC2), Amazon Virtual Private Cloud (VPC), Amazon Simple Storage Service (S3), and Amazon DynamoDB can be used with AWS Direct Connect.
Q. Can I use the same private network connection with Amazon Virtual Private Cloud (VPC) and other AWS services simultaneously?
Yes. Each AWS Direct Connect connection can be configured with one or more virtual interfaces. Virtual interfaces may be configured to access AWS services such as Amazon EC2 and Amazon S3 using public IP space, or resources in a VPC using private IP space.
Q. Can I use AWS Direct Connect if my network is not present at an AWS Direct Connect location?
Yes. AWS Direct Connect Partners can help you extend your preexisting data center or office network to an AWS Direct Connect location. Please see AWS Direct Connect Partners for more information.
Q. How can I get started with AWS Direct Connect?
Use the AWS Direct Connect tab on the AWS 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 AWS Direct Connect location you wish to use, the number of ports, and the port speed. You will also have the opportunity to request to have an AWS Direct Connect Partner contact you if you need assistance extending your office or data center network to the AWS Direct Connect location.
Q. Are there any setup charges or a minimum service term commitment required to use AWS Direct Connect?
There are no setup charges, and you may cancel at any time. Services provided by AWS Direct Connect Partners may have other terms or restrictions that apply.
Q. How will I be charged and billed for my use of AWS Direct Connect?
AWS 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.
Data Transfer via AWS Direct Connect will be billed in the same month in which the usage occurred. If you have a Hosted Virtual Interface, you will only be charged for the data transferred out of that virtual interface at the applicable Data Transfer rates. The account that owns the port will be charged the port-hour charges.
Q. Will regional data transfer be billed at the AWS Direct Connect rate?
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.
Q. What defines billable port-hours?
Port-hours are billed once the connection between the AWS 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 AWS 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.
Q. How does AWS Direct Connect work with consolidated billing?
AWS Direct Connect data transfer usage will be aggregated to your master account.
Q. How do I cancel the AWS Direct Connect service?
You can cancel AWS Direct Connect service by deleting your ports from the AWS 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 AWS Direct Connect, and/or a network service provider who may be providing network connectivity from your remote locations to the AWS Direct Connect location.
Q: Do your prices include taxes?
Except as otherwise noted, our prices are exclusive of applicable taxes and duties, including VAT and applicable sales tax.
For Dedicated Connections, 1Gbps and 10Gbps ports are available. For Hosted Connections, capacities of 50Mbps, 100Mbps, 200Mbps, 300Mbps, 400Mbps, 500Mbps, 1Gbps, 2Gbps, 5Gbps and 10Gbps may be ordered from approved AWS Direct Connect Partners. See AWS Direct Connect Partners for more information.
No. You may transfer any amount of data up to the limit of your selected port speed.
Q. What are the technical requirements for the connection?
AWS Direct Connect supports 1000BASE-LX or 10GBASE-LR connections over singlemode fiber using Ethernet transport. Your device must support 802.1Q VLANs.
Each AWS Direct Connect location enables connectivity to the geographically nearest AWS region. You can access all AWS services available in that region.
Direct Connect locations in the North America can also access the public resources in any North America region using a public virtual interface
Each AWS Direct Connect location enables connectivity to all Availability Zones within the geographically nearest AWS region.
Each connection consists of a single dedicated connection between ports on your router and an Amazon router. We recommend establishing a second connection if redundancy is required. When you request multiple ports at the same AWS Direct Connect location, they will be provisioned on redundant Amazon routers.
If you have established a second AWS 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. If you have configured a back-up IPsec VPN connection instead, all VPC traffic will failover to the VPN connection automatically. Traffic to/from public resources such as Amazon S3 will be routed over the Internet. If you do not have a backup AWS Direct Connect link or a IPsec VPN link, then Amazon VPC traffic will be dropped in the event of a failure. Traffic to/from public resources will be routed over the Internet.
No, VLANs are utilized in AWS Direct Connect only to separate traffic between virtual interfaces.
Not at this time.
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
Amazon will advertise public IP prefixes for the region via BGP. Direct Connect customers in the North America will receive the public IP prefixes for all US regions. You must advertise public IP prefixes (/30 or smaller) that you own via BGP. For more details, consult the AWS Direct Connect User Guide.
Autonomous System numbers are used to identify networks that present a clearly defined external routing policy to the Internet. AWS 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 AWS 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 AWS auto-generate the peer IP CIDR, the IP address space for both ends of the connection will be allocated by AWS in the 169.254.0.0/16 range.
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.
Q: When creating a virtual interface to work with AWS services using public IP space, what IP prefixes will I receive via BGP?
You will receive all Amazon IP prefixes for the region that you are connecting to. This includes prefixes necessary to reach AWS services, and may include prefixes for other Amazon affiliates, including those of www.amazon.com. For the current list of prefixes advertised by AWS, please download the JSON of AWS IP Address Ranges. Standard AWS Direct Connect data transfer rates apply for all traffic routed through your AWS Direct Connect connection.
Q. What IP prefixes should I advertise over BGP for virtual interfaces to public AWS services?
You should advertise appropriate public IP prefixes that you own over BGP. Traffic from AWS services destined for these prefixes will be routed over your AWS Direct Connect connection.
You can procure rack space within the facility housing the AWS Direct Connect location and deploy your equipment nearby. However, AWS customer equipment cannot be placed within AWS Direct Connect racks or cage areas for security reasons. Once deployed, you can connect this equipment to AWS 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. AWS has set the BFD liveness detection minimum interval to 300, and the BFD liveness detection multiplier to 3.
Using AWS Direct Connect with Amazon Virtual Private Cloud
Q. What are the technical requirements for virtual interfaces to VPCs?
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
AWS 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.
Q. How does AWS Direct Connect differ from an IPSec VPN Connection?
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. AWS Direct Connect does not involve the Internet; instead, it uses dedicated, private network connections between your intranet and Amazon VPC.
Q. Can I use AWS Direct Connect and a VPN Connection to the same VPC simultaneously?
Yes. However, only in fail-over scenarios. The Direct Connect path will always be preferred, when established, regardless of AS path prepending.
Q. Can I establish a Layer 2 connection between VPC and my network?
No, Layer 2 connections are not supported.
Link Aggregation Group (LAG) support in Direct Connect
Q. What is this feature?
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.
Q. What’s the max number of links I can have in a LAG group?
The maximum number of links will be 4x in a LAG group.
Q. What does the LOA look like?
You will receive a single LOA document with dedicated page for each connection.
Q. What are you using for Link Aggregation Groups?
We are using the industry standard of LACP.
Q. Are these LAGs Static or Dynamic LACP?
We are configuring Dynamic LACP bundles. Static LACP bundles are not supported.
Q. Are these in Active/Active or Active/Passive mode?
They will be in Active/Active. That means, that AWS ports will always be sending Link Aggregation Control Protocol Data Units (LACPDUs).
Q. Does the MTU change at all?
The MTU does not change.
Q. Can I have my ports configured for Active/Passive instead of Active/Active?
You could configure LAG at your endpoint with LACP active or passive mode, AWS side is always configured as Active mode LACP.
Q. Can I mix interface types and have a few 1G ports and a few 10G ports in the same bundle?
Only like interface types (ie. No mixing 1G and 10G in a bundle).
Q. What ports types will this be available on?
It will be available for 1G and 10G ports.
Q. Can I LAG Hosted Connections as well?
No. It will only be available for 1G and 10G Dedicated Connections. It will not be available for Hosted Connections.
Q. Can I create a LAG out of my existing ports?
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.
Q. Can I have a LAG that spans multiple AWS routers?
LAG will only include ports on the same AWS device. We don’t support multi- chassis LAG.
Q. How do I add links to my LAG once it’s set up?
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.
Q. What does the new LOA look like when I order additional connection to add to the LAG?
You will receive a separate LOA for each the new members of the LAG group.
Q. You’re out of ports and I have to order a new LAG, but I have VIFs configured! How do I move those?
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.
Q. Can I delete a single port from my LAG?
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.
Q. Can I delete my LAG all at once?
Yes, but just like a regular connection you won’t be able to delete it if you have VIFs configured.
Q. If I have only 2 ports in my LAG can I still delete one?
Yes, you can have a single port in a LAG.
Q. Can I order a LAG with only one port?
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.
Q. Can I convert a bundle back to individual ports?
Yes. This can be done with the DisassociateConnectionWithLag API call. See the API section.
Q. Can you just create a tool to move my VIFs for me?
You can use AssociateVirtualInterface API or console to do this operation.
Q. Does the LAG show as a single connection or a collection of connections?
It will show as a single dxlag and we’ll list the connection id’s under it.
Q. What does Min Links mean, and why do I have a check box for it when I order my bundle?
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.
Q. What’s the behavior if I don’t click the Min Links?
We’ll set Min Links to 0 by default.
Q. Can I change the Min Links after I’ve set up my bundle?
Yes. You can change the min links value after you’ve set up the bundle, either via console or via API.
Q. When I associate my existing DirectConnect connection with a LAG what happens with existing Virtual Interfaces already created with DirectConnect connection?
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.
Q. If I have multiple LAGs, can I still use BFD to improve fail over time between paths?
BFD is still supported.
Q. Can I set link priority on a specific link?
We’ll treat all links as equal, so we won’t set “link priority” on any specific link.
Q. Does having a LAG make my connection more resilient?
LAG will let you protect against single path failures between your data center and AWS. It won’t protect against a single device failure at AWS.
Q. Can I have VIFs on two different LAG connected to the same VGW?
Yes. This behavior is exactly like creating VIFs on single ports.
Q. Can I have a 40GE interface on my side that connects to 4x 10GE on the AWS side?
You will need 4x 10GE interfaces on your router to connect to AWS. A single 40GE
interface connecting to a 4x 10GE LACP is not supported.
Q. Is there a charge for LAG?
There is no extra charge for LAG.
IPv6 Support in Direct Connect
Q. Can I run IPv4 and IPv6 on the same virtual interface (VIF)?
AWS Direct Connect supports both single and dual stack configurations on public and private VIFs. You will be able to add an IPv6 peering session to an existing VIF with IPv4 peering session (or vice versa). You can also create 2 separate VIFs – one for IPv4 and another one for IPv6
Q. I need a public IPv6 range, can Amazon assign me a range?
Yes. Addressing for both public and private VIFs is provided by default and with a netmask of /125.
Q. What IP address will Amazon assign my private VIF if I select “assign an IP” in the console?
For a private IPv4 VIF, Amazon will provide you a /31 CIDR. For a private IPv6 VIF, Amazon will provide you a /125 CIDR.
Q. Will I still need to run BGP on my VIFs?
Yes. Both private and public Direct Connect require a native peering from IPv4 or IPv6. Multiprotocol BGP is not supported at this time.
Q. Can I bring my own BGP ASN?
At this time, you will not be able to bring your own BGP ASN. This feature is on the Direct Connect roadmap, and once enabled, you will be able to bring your own BGP ASN for the VIFs.
Q. Are there any changes to VLAN assignment?
No. Layer 2 functionality remains the same for IPv4 and IPv6.
Q. Will I still be able to use BFD for faster BGP failover times?
Yes. BFD is supported for IPv6 BGP peerings.
Q. Are there any changes in the length of CIDR you can advertise to AWS?
Yes, for IPv6 we will limit the length of CIDR you can advertise to AWS to /64 (or shorter) for public Direct Connect Virtual Interface. For IPv4, prefix limits will remain the same.
Q. What routes will AWS announce to me over a public VIF?
All public routes.
Q. Will you support multicast or anycast over IPv6 VIFs?
We will not support multicast or anycast on Direct Connect.
Q. What routes will I learn from AWS over a public VIF?
AWS Public Direct Connect will advertise IPv6 prefixes for all IPv6 enabled services.
Q. Can I create a Hosted Virtual Interface for someone that is IPv6 enabled?
Yes you can.
Q. Will this impact policers associated with Hosted Connections?
It will not.
Q. Will cloudhub still work in my VGW? (note also impacts VPN)
It will only work for like for like traffic. You can’t send v4 traffic out a v6 interface, for example. Translation between IPv4 and IPv6 is not supported.
Bring your own private Autonomous System Number
Q. What is this feature?
Configurable Private Autonomous System Number(ASN) allows customers to set the private ASN on the any newly created VGW.
Q. What is the cost?
There is no additional charge for this feature.
Q. How can I configure/assign my ASN to be advertised as AWS Console side ASN?
You can configure/assign an ASN to be advertised as the AWS 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.
Q. What ASN did AWS Console assign prior to this?
AWS China (Beijing) Region was assigned an ASN of 7224. It’s referred as “legacy public ASN” of the region.
Q. Can I use any ASN – public and private?
You can assign any private ASN to the AWS Console side. You can assign the "legacy public ASN" of the region until June 30th 2018. You cannot assign any other public ASN.
Q. Why can’t I assign a public ASN for the AWS Console half of the BGP session?
We are not validating ownership of the ASNs, therefore, we’re limiting the AWS Console side ASN to private ASNs. We want to protect customers from BGP spoofing.
Q. What ASN can I choose?
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 will continue to provide the “legacy public ASN” of the region. After June 30th 2018, we will provide a private ASN of 64512.
Q. What will happen if I try to assign a public ASN to the AWS Console half of the BGP session?
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.
Q. If I don’t provide an ASN for the AWS Console half of the BGP session, what ASN can I expect AWS Console to assign to me?
We will provide an ASN for the VGW if you don’t choose one. Until June 30th 2018, We will continue to provide the “legacy public ASN” of the region. After June 30th 2018, We will provide an ASN of 64512.
Q. Where can I view the AWS Console side ASN?
You can view the AWS Console side ASN in the VGW page of VPC console and in the response of EC2/DescribeVpnGateways API.
Q. If I have a public ASN, will it work with a private ASN on the AWS side?
Yes, you can configure the AWS Console side of the BGP session with a private ASN and your side with a public ASN.
Q. I have private VIFs already configured and want to set a different AWS Console side ASN for the BGP session on an existing VIF. How can I make this change?
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.
Q. I already have a VGW and a private VIF configured using an AWS Console assigned public ASN of 7224. If AWS Console automatically generates the ASN for the new private VGW, what AWS Console side ASN will I be assigned?
We will assign 64512 to the AWS Console side ASN for the new VGW.
Q. I have a VGW and a private VIF configured using an AWS Console assigned public ASN. I want to use the same AWS Console assigned public ASN for the new private VIF I’m creating. How do I do this?
You can configure/assign an ASN to be advertised as the AWS 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.
Q. I have a VGW and a private VIF configured using an AWS Console assigned public ASN of 7224. If AWS Console auto generates the ASN for the new private VIF using the same VGW, what AWS Console side ASN will I be assigned?
We will assign 7224 to the AWS Console side ASN for the new VIF. The AWS Console side ASN for your new private VIF is inherited from your existing VGW and defaults to that ASN.
Q. I’m attaching multiple private VIFs to a single VGW. Can each VIF have a separate AWS Console side ASN?
No, you can assign/configure separate AWS Console side ASN for each VGW, not each VIF. AWS Console side ASN for VIF is inherited from the AWS Console side ASN of the attached VGW.
Q. Where can I select my own ASN?
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 AWS Console half of the BGP session. Once VGW is configured with AWS Console side ASN, the private VIFs created using the VGW will use your AWS Console side ASN.
Q. I use CloudHub today. Will I have to adjust my configurations in the future?
You will not have to make any changes.
Q. I want to select a 32-bit ASN. What is the range of 32-bit private ASNs?
We will support 32-bit ASNs from 4200000000 to 4294967294.
Q. Once the VGW is created, can I change or modify the AWS Console side ASN?
No, you cannot modify the AWS Console side ASN after creation. You can delete the VGW and recreate a new VGW with the desired ASN.
Q. Is there a new API to configure/assign the AWS Console side ASN?
No. You can do this with the same API as before (EC2/CreateVpnGateway). We just added a new parameter (AWS Console Side ASN) to this API.
Q. Is there a new API to view the AWS Console side ASN?
No. You can view the AWS Console side ASN with the same EC2/DescribeVpnGateways API. We just added a new parameter (AWS Console Side ASN) to this API.
Q. What is the Maximum Transmission Unit (MTU) supported by AWS Direct Connect?
AWS Direct Connect support both 1500 and 9001 Maximum Transmission Unit (MTU). MTU is a configurable option on the AWS Direct Connect Private Virtual Interface.
Q. How do I change the MTU of a Private Virtual Interface?
- If you own both the AWS 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 AWS Direct Connect port is owned by another AWS 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 AWS Direct Connect port is provided by AWS 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 AWS Direct Connect Partner will need to contact AWS support to make the port Jumbo Frames capable.
Q. Can I use Jumbo Frames over AWS Direct Connect with both propagated and static routes?
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.
Q. If I have two Private Virtual Interfaces that advertise the same route and both Interfaces have different MTUs, which MTU will be used?
If two virtual interfaces advertise the same route, but use different MTUs, the lowest of the MTUs will be used for both virtual interfaces.
Q. Do you support moving of a Jumbo Frame enabled Virtual Private Interface from one Direct Connect port to another?
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.
Q. Is the downtime expected when enabling Jumbo Frames on a Private Virtual Interface?
Yes, if the owner of an AWS 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.
Q. How do I enable Jumbo Frames on a Link Aggregation Group (LAG) Private Virtual 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.
Local preference communities for private virtual interface
Q. What is this feature?
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.
Q. Can I use this feature for my existing EBGP sessions?
Yes, all existing BGP sessions on private virtual interfaces support the use of local preference communities.
Q. Will this feature be available on both Public and Private Virtual Interfaces?
No, this feature is currently available for private virtual interfaces only.
Q. Will this feature work with Direct Connect Gateway?
Yes, this feature will work with private virtual interfaces attached with Direct Connect Gateway.
Q. Can I verify communities being received by AWS?
No, at this time we do not provide such monitoring features.
Q. Do you charge additionally for this feature?
There is no additional charge for using this feature.
Q. What are the supported local preference communities for Direct Connect private virtual interface?
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
Q. What is the default behavior in case I do not use the supported communities?
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.
Q. I have two private VIFs on a physical connections at a Direct Connect location; can I use supported communities to influence egress behavior across these two private VIFs?
Yes, you can use this feature to influence egress traffic behavior between two VIFs.
Q. I have two Direct Connect connections, both 1G, I want all incoming traffic into my network load balanced across these two connections, can I use community based routing to achieve such load balancing across the locations?
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.
Q. Will the local preference communities feature support failover?
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.
Q. I have already configured my routers with AS_PATH, do I need to change the configuration to use community tags and disrupt my network?
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 AWS; Direct Connect follows the standard approach for path selection; Bear in mind that local preference is evaluated before the AS_PATH attribute.
Q. I have two Direct Connect connections, one is 1G and another is 10G, and both are advertising the 10.10.1.0/24 prefix; I would like to receive all traffic for this destination across the 10G Direct Connect connection, but still be capable of failing over to the 1G connection; Can local preference communities be used to balance traffic in this scenario?
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.
Q. How wide will you multipath traffic to my network?
We will multipath per prefix at up to 16 next-hops wide, where each next-hop is a unique AWS endpoint.