AWS Direct Connect virtual interfaces - AWS Direct Connect

AWS Direct Connect 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 either your VPCs or other AWS services. You can access all AWS prefixes through this connection; for example, Amazon EC2, Amazon S3, and Amazon.com. You do not have access to non-Amazon prefixes. For a current list of prefixes advertised by AWS, see AWS IP Address Ranges in the Amazon Web Services General Reference. AWS does not re-advertise customer prefixes that were received over AWS Direct Connect public virtual interfaces to other customers. For more information about public virtual interfaces and routing policies, see Public virtual interface routing policies.

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. If you're using a prefix filter (route map), ensure that it accepts prefixes with an exact match or longer. Prefixes advertised from AWS Direct Connect may be aggregated and may differ from the prefixes defined in your prefix filter.

Hosted virtual interfaces

To use your AWS Direct Connect connection with another account, you can create a hosted virtual interface for that account. The owner of the other account must accept the hosted virtual interface to begin using it. A hosted virtual interface works the same as a standard virtual interface and can connect to public resources or a VPC.

You can use transit virtual interfaces with Direct Connect dedicated or hosted connections of any speed. Hosted connections support only one virtual interface.

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.
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. 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)

        Note

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

    • (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.

  • IPv6: Specify a prefix length of /64 or shorter.

  • 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.

  • You can specify any prefix length over a Direct Connect public virtual interface. IPv4 should support anything from /1 - /32, and IPv6 should support anything from /1 - /64.

(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.

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.

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 Set network MTU 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.
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. 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)

        Note

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

    • (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.

  • IPv6: Specify a prefix length of /64 or shorter.

  • 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.

  • You can specify any prefix length over a Direct Connect public virtual interface. IPv4 should support anything from /1 - /32, and IPv6 should support anything from /1 - /64.

(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.