AWS Direct Connect virtual interfaces and hosted virtual interfaces - AWS Direct Connect
Public virtual interface prefix advertisement rulesSiteLinkPrerequisites for virtual interfacesMTUs for private virtual interfaces or transit virtual interfaces

AWS Direct Connect virtual interfaces and hosted virtual interfaces

You must create one of the following virtual interfaces (VIFs) to begin using your AWS Direct Connect connection.

  • Private virtual interface: A private virtual interface should be used to access an Amazon VPC using private IP addresses.

  • Public virtual interface: A public virtual interface can access all AWS public services using public IP addresses.

  • Transit virtual interface: A transit virtual interface should be used to access one or more Amazon VPC Transit Gateways associated with Direct Connect gateways. You can use transit virtual interfaces with any AWS Direct Connect dedicated or hosted connection of any speed. For information about Direct Connect gateway configurations, see Direct Connect gateways.

To connect to other AWS services using IPv6 addresses, check the service documentation to verify that IPv6 addressing is supported.

We advertise appropriate Amazon prefixes to you so that you can reach the public IP addresses of workloads in your VPCs and other AWS services. You can access all AWS prefixes through this connection; for example, public IP addresses used by Amazon EC2 instances, Amazon S3, API endpoints for AWS services, and Amazon.com. You do not have access to non-Amazon prefixes. For a current list of prefixes used by AWS, see AWS IP Address Ranges in the Amazon VPC User Guide. On this page you can download a .json file of the currently published AWS IP ranges. Note that for published IP address ranges:

  • Prefixes announced via BGP over a public virtual interface might be aggregated or de-aggregated compared to what is listed in the AWS IP address ranges list.

  • Any IP address ranges that you bring to AWS through your own IP addresses (BYOIP) are not included in the .json file, but AWS still advertises these BYOIP addresses over a public virtual interface.

  • AWS does not re-advertise customer prefixes that were received over Direct Connect public virtual interfaces to networks outside of AWS. Prefixes advertised on a public virtual interface will be visible to all customers on AWS.

Note

We recommend that you use a firewall filter (based on the source/destination address of packets) to control traffic to and from some prefixes.

For more information about public virtual interfaces and routing policies, see Public virtual interface routing policies.

If you're creating a private or transit virtual interface, you can use SiteLink.

SiteLink is an optional Direct Connect feature for virtual private interfaces that enables connectivity between any two Direct Connect points of presence (PoPs) in the same AWS partition using the shortest available path over the AWS network. This allows you to connect your on-premises network through the AWS global network without needing to route your traffic through a Region. For more information about SiteLink see Introducing AWS Direct Connect SiteLink.

Note

  • SiteLink is not available in AWS GovCloud (US) and the China Regions.

  • SiteLink does not work if an on-premises router advertises the same route to AWS on multiple virtual interfaces.

There's a separate pricing fee for using SiteLink. For more information, see AWS Direct Connect Pricing.

SiteLink doesn't support all virtual interface types. The following table shows the interface type and whether it's supported.

Virtual interface type Supported/Not supported
Transit virtual interface Supported
Private virtual interface attached to a Direct Connect gateway with a virtual gateway Supported
Private virtual interface attached to a Direct Connect gateway not associated with a virtual gateway or transit gateway Supported
Private virtual interface attached to a virtual gateway Not supported
Public virtual interface Not supported

Traffic routing behavior for traffic from AWS Regions (virtual or transit gateways) to on-premises locations over a SiteLink enabled virtual interface varies slightly from the default Direct Connect virtual interface behavior with an AWS path prepend. When SiteLink is enabled, virtual interfaces from an AWS Region prefer a BGP path with a lower AS path length from a Direct Connect location, regardless of the associated Region. For example , an associated Region is advertised for each Direct Connect location. If SiteLink is disabled, by default traffic coming from a virtual or transit gateway prefers a Direct Connect location that is associated with that AWS Region, even if the router from Direct Connect locations associated with different Regions advertises a path with a shorter AS path length. The virtual or transit gateway still prefers the path from Direct Connect locations local to the associated AWS Region.

SiteLink supports a maximum jumbo frame MTU size of either 8500 or 9001, depending on the virtual interface type. For more information, see MTUs for private virtual interfaces or transit virtual interfaces.

Prerequisites for virtual interfaces

Before you create a virtual interface, do the following:

To create a virtual interface, you need the following information:

Resource Required information
Connection The AWS Direct Connect connection or link aggregation group (LAG) for which you are creating the virtual interface.
Virtual interface name A name for the virtual interface.
Virtual interface owner If you're creating the virtual interface for another account, you need the AWS account ID of the other account.
(Private virtual interface only) Connection For connecting to a VPC in the same AWS Region, you need the virtual private gateway for your VPC. The ASN for the Amazon side of the BGP session is inherited from the virtual private gateway. When you create a virtual private gateway, you can specify your own private ASN. Otherwise, Amazon provides a default ASN. For more information, see Create a Virtual Private Gateway in the Amazon VPC User Guide. For connecting to a VPC through a Direct Connect gateway, you need the Direct Connect gateway. For more information, see Direct Connect Gateways.
Note

  • You can't use the same ASN for the customer gateway and virtual gateway/Direct Connect gateway on the virtual interface.

  • You can use the same customer gateway ASN for multiple virtual interfaces.

  • Multiple virtual interfaces can have the same virtual gateway/Direct Connect gateway ASN and customer gateway ASN as long as they are a part of different Direct Connect connections. For example:

    Virtual gateway (ASN 64,496) <---Virtual interface 1 (Direct Connect connection 1)---> Customer gateway (ASN 64,511)

    Virtual gateway (ASN 64,496) <---Virtual interface 2 (Direct Connect connection 2)---> Customer gateway (ASN 64,511)
VLAN A unique virtual local area network (VLAN) tag that's not already in use on your connection. The value must be between 1 and 4094 and must comply with the Ethernet 802.1Q standard. This tag is required for any traffic traversing the AWS Direct Connect connection.

If you have a hosted connection, your AWS Direct Connect Partner provides this value. You can’t modify the value after you have created the virtual interface.
Peer IP addresses A virtual interface can support a BGP peering session for IPv4, IPv6, or one of each (dual-stack). Do not use Elastic IPs (EIPs) or Bring your own IP addresses (BYOIP) from the Amazon Pool to create a public virtual interface. You cannot create multiple BGP sessions for the same IP addressing family on the same virtual interface. The IP address ranges are assigned to each end of the virtual interface for the BGP peering session.

  • IPv4:

    • (Public virtual interface only) You must specify unique public IPv4 addresses that you own.

      Note

      • Peering IPs for private and transit virtual interfaces can be from any valid IP range. This can also include customer-owned public IP addresses as long as these are only used for creating the BGP peering session and not advertised over the virtual interface or used for NAT.

      • We cannot guarantee that we will be able to fulfill all requests for AWS provided public IPv4 addresses.

      The value can be one of the following:

      • A customer-owned IPv4 CIDR

        These can be any public IPs (customer-owned or provided by AWS), but the same subnet mask must be used for both your peer IP and the AWS router peer IP. For example, if you allocate a /31 range, such as 203.0.113.0/31, you could use 203.0.113.0 for your peer IP and 203.0.113.1 for the AWS peer IP. Or, if you allocate a /24 range, such as 198.51.100.0/24, you could use 198.51.100.10 for your peer IP and 198.51.100.20 for the AWS peer IP.

      • An IP range owned by your AWS Direct Connect Partner or ISP, along with an LOA-CFA authorization.

      • An AWS provided /31 CIDR. Contact AWS Support to request a public IPv4 CIDR (and provide a use case in your request)

      • (Private virtual interface only) Amazon can generate private IPv4 addresses for you. If you specify your own, ensure that you specify private CIDRs for your router interface and the AWS Direct Connect interface only. For example, do not specify other IP addresses from your local network. Similar to a public virtual interface, the same subnet mask must be used for both your peer IP and the AWS router peer IP. For example, if you allocate a /30 range, such as 192.168.0.0/30, you could use 192.168.0.1 for your peer IP and 192.168.0.2 for the AWS peer IP.

  • IPv6: Amazon automatically allocates you a /125 IPv6 CIDR. You cannot specify your own peer IPv6 addresses.
Address family Whether the BGP peering session will be over IPv4 or IPv6.
BGP information

  • A public or private Border Gateway Protocol (BGP) Autonomous System Number (ASN) for your side of the BGP session. If you are using a public ASN, you must own it. If you are using a private ASN, you can set a custom ASN value. For a 16-bit ASN, the value must be in the 64512 to 65534 range. For a 32-bit ASN, the value must be in the 1 to 2147483647 range. Autonomous System (AS) prepending does not work if you use a private ASN for a public virtual interface.

  • AWS enables MD5 by default. You cannot modify this option.

  • An MD5 BGP authentication key. You can provide your own, or you can let Amazon generate one for you.
(Public virtual interface only) Prefixes you want to advertise

Public IPv4 routes or IPv6 routes to advertise over BGP. You must advertise at least one prefix using BGP, up to a maximum of 1,000 prefixes.

  • IPv4: The IPv4 CIDR can overlap with another public IPv4 CIDR announced using AWS Direct Connect when either of the following is true:

    • The CIDRs are from different AWS Regions. Make sure that you apply BGP community tags on the public prefixes.

    • You use AS_PATH when you have a public ASN in an active/passive configuration.

    For more information, see Routing policies and BGP communities.

  • Over a Direct Connect public virtual interface, you can specify any prefix length from /1 to /32 for IPv4 and from /1 to /64 for IPv6.

  • You may add additional prefixes to an existing public VIF and advertise those by contacting AWS support. In your support case, provide a list of additional CIDR prefixes you want to add to the public VIF and advertise.
(Private virtual interface only) Jumbo frames The maximum transmission unit (MTU) of packets over AWS Direct Connect. The default is 1500. Setting the MTU of a virtual interface to 9001 (jumbo frames) can cause an update to the underlying physical connection if it wasn't updated to support jumbo frames. Updating the connection disrupts network connectivity for all virtual interfaces associated with the connection for up to 30 seconds. Jumbo frames apply only to propagated routes from AWS Direct Connect. If you add static routes to a route table that point to your virtual private gateway, then traffic routed through the static routes is sent using 1500 MTU. To check whether a connection or virtual interface supports jumbo frames, select it in the AWS Direct Connect console and find Jumbo frame capable on the virtual interface General configuration page.
(Transit virtual interface only) Jumbo frames The maximum transmission unit (MTU) of packets over AWS Direct Connect. The default is 1500. Setting the MTU of a virtual interface to 8500 (jumbo frames) can cause an update to the underlying physical connection if it wasn't updated to support jumbo frames. Updating the connection disrupts network connectivity for all virtual interfaces associated with the connection for up to 30 seconds. Jumbo frames are supported up to 8500 MTU for Direct Connect. Static routes and propagated routes configured in the Transit Gateway Route Table will support Jumbo Frames, including from EC2 instances with VPC static route table entries to the Transit Gateway Attachment. To check whether a connection or virtual interface supports jumbo frames, select it in the AWS Direct Connect console and find Jumbo frame capable on the virtual interface General configuration page.

When you create a virtual interface, you can specify the account that owns the virtual interface. When you choose an AWS account that is not your account, the following rules apply:

  • For private VIFs and transit VIFs, the account applies to the virtual interface and the virtual private gateway/Direct Connect gateway destination.

  • For public VIFs, the account is used for virtual interface billing. The Data Transfer Out (DTO) usage is metered toward the resource owner at AWS Direct Connect data transfer rate.

Note

31-Bit prefixes are supported on all Direct Connect virtual interface types. See RFC 3021: Using 31-Bit Prefixes on IPv4 Point-to-Point Links for more information.

MTUs for private virtual interfaces or transit virtual interfaces

AWS Direct Connect supports an Ethernet frame size of 1522 or 9023 bytes (14 bytes Ethernet header + 4 bytes VLAN tag + bytes for the IP datagram + 4 bytes FCS) at the link layer.

The maximum transmission unit (MTU) of a network connection is the size, in bytes, of the largest permissible packet that can be passed over the connection. The MTU of a virtual private interface can be either 1500 or 9001 (jumbo frames). The MTU of a transit virtual interface can be either 1500 or 8500 (jumbo frames). You can specify the MTU when you create the interface or update it after you create it. Setting the MTU of a virtual interface to 8500 (jumbo frames) or 9001 (jumbo frames) can cause an update to the underlying physical connection if it wasn't updated to support jumbo frames. Updating the connection disrupts network connectivity for all virtual interfaces associated with the connection for up to 30 seconds. To check whether a connection or virtual interface supports jumbo frames, select it in the AWS Direct Connect console and find Jumbo Frame Capable on the Summary tab.

After you enable jumbo frames for your private virtual interface or transit virtual interface, you can only associate it with a connection or LAG that is jumbo frame capable. Jumbo frames are supported on a private virtual interface attached to either a virtual private gateway or a Direct Connect gateway, or on a transit virtual interface attached to a Direct Connect gateway. If you have two private virtual interfaces that advertise the same route but use different MTU values, or if you have a Site-to-Site VPN that advertise the same route, 1500 MTU is used.

Important

Jumbo frames will apply only to propagated routes via AWS Direct Connect and static routes via transit gateways. Jumbo frames on transit gateways support only 8500 bytes.

If an EC2 instance doesn't support jumbo frames, it drops jumbo frames from Direct Connect. All EC2 instance types support jumbo frames except for C1, CC1, T1, and M1. For more information, see Network Maximum Transmission Unit (MTU) for Your EC2 Instance in the Amazon EC2 User Guide.

For hosted connections, Jumbo frames can be enabled only if originally enabled on the Direct Connect hosted parent connection. If Jumbo frames isn't enabled on that parent connection, then it can't be enabled on any connection.

For the steps to set the MTU for a private virtual interface, see Set the MTU of a private virtual interface.