Ensure Direct Connect Virtual Interfaces Are Providing Redundant Connections

Overview

This check verifies that your AWS Direct Connect gateways and virtual private gateways have virtual interfaces (VIFs) distributed across multiple Direct Connect connections at different locations. Redundancy at the connection level ensures your hybrid connectivity remains available even if one connection or location experiences issues.

Risk

Without redundant virtual interfaces across separate Direct Connect connections, you face significant availability risks:

• Single point of failure: A single device failure, fiber cut, or location issue can sever your on-premises to AWS connectivity
• Unplanned downtime: Maintenance at a single location could disrupt all traffic
• Routing blackholes: Loss of connectivity can cause packets to be dropped with no failover path
• Business disruption: Critical workloads depending on Direct Connect may become unreachable

Remediation Steps

Prerequisites

You need:

• An AWS account with Direct Connect permissions
• At least two Direct Connect connections in different locations (or the ability to order a second connection)
• Network information: VLAN IDs, BGP ASN, and IP addresses for the new virtual interface

Understanding Direct Connect redundancy concepts

Virtual Interface (VIF): A VLAN that carries traffic between your on-premises network and AWS over a Direct Connect connection.

Direct Connect Location: A physical colocation facility where AWS has Direct Connect equipment. Redundancy requires connections at different locations, not just different connections at the same location.

Connection: A dedicated network link between your router (or your partner's router) and AWS at a Direct Connect location.

Direct Connect Gateway: A globally available resource that enables you to connect your VPCs across regions to your on-premises network.

For true redundancy, you need virtual interfaces on separate connections at geographically distinct Direct Connect locations.

AWS Console Method

1. Check your current setup

   • Open the AWS Direct Connect console
   • Click Virtual interfaces in the left navigation
   • Note which connections your existing VIFs use (check the "Connection" column)
   • Click Connections to see the locations of each connection

2. Identify or order a second connection

   • If you only have connections at one location, you need to order a new connection at a different Direct Connect location
   • Click Create connection and select a different location from your existing connection
   • Work with your network provider to establish cross-connects at the new location

3. Create a redundant virtual interface

   • Once you have a second connection at a different location, click Virtual interfaces
   • Click Create virtual interface
   • Select Private (for VPC access) or Transit (for Transit Gateway)
   • Choose the connection at your second location
   • Fill in the required details:
     • Virtual interface name: A descriptive name (e.g., "prod-vif-secondary")
     • VLAN: A unique VLAN ID not used by other VIFs on this connection
     • BGP ASN: Your on-premises router's BGP autonomous system number
     • Router peer IPs: Amazon and customer IP addresses for BGP peering
   • Attach to the same Direct Connect gateway or virtual private gateway as your primary VIF
   • Click Create virtual interface

4. Configure BGP on your router

   • Set up BGP peering on your on-premises router using the provided Amazon peer IP
   • Ensure both VIFs advertise the same routes so traffic can fail over

AWS CLI

List your existing connections and their locations:

aws directconnect describe-connections \
    --region us-east-1 \
    --query 'connections[*].{ID:connectionId,Name:connectionName,Location:location,State:connectionState}' \
    --output table

List existing virtual interfaces:

aws directconnect describe-virtual-interfaces \
    --region us-east-1 \
    --query 'virtualInterfaces[*].{ID:virtualInterfaceId,Name:virtualInterfaceName,Connection:connectionId,Gateway:directConnectGatewayId,State:virtualInterfaceState}' \
    --output table

Create a private virtual interface on a different connection:

aws directconnect create-private-virtual-interface \
    --region us-east-1 \
    --connection-id <SECOND_CONNECTION_ID> \
    --new-private-virtual-interface '{
        "virtualInterfaceName": "prod-vif-secondary",
        "vlan": <UNIQUE_VLAN_ID>,
        "asn": <YOUR_BGP_ASN>,
        "amazonAddress": "169.254.100.1/30",
        "customerAddress": "169.254.100.2/30",
        "addressFamily": "ipv4",
        "directConnectGatewayId": "<YOUR_DX_GATEWAY_ID>"
    }'

Replace:

• <SECOND_CONNECTION_ID>: The connection ID at your secondary location
• <UNIQUE_VLAN_ID>: A VLAN ID not in use on that connection (1-4094)
• <YOUR_BGP_ASN>: Your on-premises BGP ASN
• <YOUR_DX_GATEWAY_ID>: Your Direct Connect gateway ID

CloudFormation

Note: AWS CloudFormation has limited support for Direct Connect resources. Virtual interfaces cannot be created directly with CloudFormation native resources.

For infrastructure-as-code management of Direct Connect virtual interfaces, use one of these approaches:

1. Terraform (recommended) - See the Terraform section below for a complete example
2. AWS CLI - Use the CLI commands in the previous section
3. CloudFormation Custom Resource - Wrap AWS CLI/SDK calls in a Lambda-backed custom resource

If you need to manage Direct Connect virtual interfaces alongside other CloudFormation resources, consider using a hybrid approach where CloudFormation manages your VPCs, Transit Gateways, and other infrastructure while Terraform or CLI scripts manage the Direct Connect virtual interfaces.

Terraform

variable "primary_connection_id" {
  description = "Connection ID at primary Direct Connect location"
  type        = string
}

variable "secondary_connection_id" {
  description = "Connection ID at secondary Direct Connect location"
  type        = string
}

variable "dx_gateway_id" {
  description = "Direct Connect Gateway ID"
  type        = string
}

variable "customer_bgp_asn" {
  description = "Your on-premises BGP ASN"
  type        = number
  default     = 65000
}

# Primary Virtual Interface
resource "aws_dx_private_virtual_interface" "primary" {
  connection_id      = var.primary_connection_id
  name               = "prod-vif-primary"
  vlan               = 100
  bgp_asn            = var.customer_bgp_asn
  address_family     = "ipv4"
  amazon_address     = "169.254.100.1/30"
  customer_address   = "169.254.100.2/30"
  dx_gateway_id      = var.dx_gateway_id

  tags = {
    Name        = "prod-vif-primary"
    Environment = "production"
    Redundancy  = "primary"
  }
}

# Secondary Virtual Interface on different connection
resource "aws_dx_private_virtual_interface" "secondary" {
  connection_id      = var.secondary_connection_id
  name               = "prod-vif-secondary"
  vlan               = 200
  bgp_asn            = var.customer_bgp_asn
  address_family     = "ipv4"
  amazon_address     = "169.254.101.1/30"
  customer_address   = "169.254.101.2/30"
  dx_gateway_id      = var.dx_gateway_id

  tags = {
    Name        = "prod-vif-secondary"
    Environment = "production"
    Redundancy  = "secondary"
  }
}

output "primary_vif_id" {
  description = "Primary Virtual Interface ID"
  value       = aws_dx_private_virtual_interface.primary.id
}

output "secondary_vif_id" {
  description = "Secondary Virtual Interface ID"
  value       = aws_dx_private_virtual_interface.secondary.id
}

Verification

After creating redundant virtual interfaces:

1. In the AWS Console: Go to Direct Connect > Virtual interfaces and confirm you have VIFs on connections at different locations, all in "available" state

2. Check BGP status: Both VIFs should show BGP as "up" once your routers are configured

3. Run Prowler again to confirm the check passes:

   prowler aws --check directconnect_virtual_interface_redundancy -r us-east-1

Advanced verification with AWS CLI

Verify VIFs are on different connections:

aws directconnect describe-virtual-interfaces \
    --region us-east-1 \
    --query 'virtualInterfaces[?directConnectGatewayId!=`null`].{VIF:virtualInterfaceName,Connection:connectionId,Gateway:directConnectGatewayId,State:virtualInterfaceState,BGP:bgpPeers[0].bgpStatus}' \
    --output table

Confirm connections are at different locations:

aws directconnect describe-connections \
    --region us-east-1 \
    --query 'connections[*].{ID:connectionId,Location:location}' \
    --output table

For each Direct Connect gateway, verify you see at least two VIFs on connections at different locations.

Additional Resources

• AWS Direct Connect Resiliency Recommendations
• AWS Direct Connect Resiliency Toolkit
• Creating a Private Virtual Interface
• Direct Connect Gateway Associations

Notes

• Lead time for new connections: Ordering a new Direct Connect connection can take weeks to months depending on the location and provider. Plan ahead.

• Cost considerations: Each Direct Connect connection incurs hourly port charges plus data transfer costs. Evaluate the cost of redundancy against the business impact of downtime.

• Active/active vs active/passive: Configure BGP to use both paths actively (load sharing) or keep one as standby. Active/active provides better bandwidth utilization but requires proper BGP tuning.

• VPN backup: Consider adding a Site-to-Site VPN as an additional backup path over the internet. This provides resilience even if both Direct Connect locations fail.

• Testing failover: Periodically test failover by bringing down one VIF's BGP session to ensure traffic fails over correctly.

• Compliance frameworks: This check maps to C5, ISO27001, and KISA-ISMS-P requirements for network resilience and availability.