Build Direct Connect virtual interface configurations with BGP peering, VLAN, and MTU settings.
Build Direct Connect virtual interface configurations with BGP peering, VLAN, and MTU settings.
Required Fields
ConnectionIdVirtualInterfaceNameVlanAsnAddressFamilyOutput will appear here...The builder validates that ConnectionId, VirtualInterfaceName, Vlan, Asn, and AddressFamily all resolve before accepting the JSON as a valid CreateVirtualInterface request, the fields Direct Connect needs to associate the VIF with a physical connection and establish BGP; it can't verify the VLAN tag doesn't collide with another VIF already using it on the same physical connection, that's checked only against the live connection's current VIF set.
Build an AWS Direct Connect virtual interface (private, public, or transit) with BGP peering parameters, VLAN tagging, and jumbo-frame MTU. VirtualInterfaceType determines what the VIF can actually reach: private connects to a VPC via a Virtual Private Gateway or Direct Connect Gateway, public reaches AWS public service endpoints (S3, DynamoDB) over Direct Connect instead of the internet, and transit connects specifically to a Direct Connect Gateway associated with a Transit Gateway, they're not interchangeable configurations of the same underlying VIF, picking the wrong type for your target architecture means starting over, not reconfiguring.
VIF type is a one-way decision at creation time, confirm you actually need private vs. public vs. transit before provisioning, since changing your mind later means full BGP re-establishment on a new VIF, not a quick edit.
Jumbo frame (MTU 9001) mismatches produce silent performance degradation, not a clear error, if a Direct Connect link enabled for jumbo frames starts showing intermittent issues after a network change somewhere in the path, MTU mismatch is a prime suspect worth checking early.
A Direct Connect Gateway is the more future-flexible choice over a directly-attached Virtual Private Gateway whenever there's any chance you'll need to reach more than one VPC or a Transit Gateway later, switching from a VGW-attached VIF to a DX-Gateway-attached one later is more disruptive than choosing correctly up front.
No, VirtualInterfaceType is set at creation and isn't mutable afterward, changing the fundamental connectivity model requires deleting the existing VIF and creating a new one of the desired type, which means a maintenance window and BGP re-establishment, not a simple configuration update.
You typically don't get an outright connection failure, instead you see silent packet fragmentation or drops for packets that exceed the actual supported MTU somewhere along the path, which manifests as intermittent, hard-to-diagnose performance issues or connection resets rather than a clear MTU-mismatch error. Confirm jumbo frame support end-to-end (the DX router, the VIF, and typically an ENI configured for jumbo frames in the VPC) before enabling it in production.
Not necessarily the same ASN for every VIF, each VIF's BgpPeers entry defines its own ASN and peer addressing independently, multiple VIFs can share the same customer ASN or use different ones depending on your network design, what has to be unique per VIF on the same physical connection is the VLAN tag, not the ASN.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.