Skip to content

Reducing EDA Data Transfer Costs with a Dedicated Direct Connect Gateway

7 minute read
Content level: Advanced
4

This article presents a cost-optimization pattern using a dedicated AWS Direct Connect gateway with private virtual interfaces to bypass Transit Gateway for bulk storage traffic, while preserving the existing Transit Gateway architecture for all other connectivity. The pattern applies to any EDA customer with petabyte-scale on-premises-to-AWS data transfers routed through Transit Gateway today.

Introduction

Electronic Design Automation (EDA) customers frequently migrate large volumes of design data, often measured in petabytes, from on-premises environments to AWS using AWS Direct Connect. Common storage destinations include Amazon S3 and Amazon FSx for NetApp ONTAP (FSxN). Customers with existing on-premises NetApp ONTAP storage, for example, leverage NetApp SnapMirror for efficient block-level replication to FSx for NetApp ONTAP on AWS.

A common architecture for EDA workloads includes multiple AWS Regions (for example, two Regions in the US and one in Asia Pacific or Europe) connected via AWS Transit Gateway or AWS Cloud WAN for inter-VPC and inter-Region communication. Connectivity from on-premises data centers to AWS is established through an AWS Direct Connect gateway associated with at least two AWS Direct Connect locations for redundancy.

While AWS Direct Connect does not incur Data Transfer In charges (data transferred into AWS over Direct Connect is $0.00 per GB in all locations), routing this inbound data through an AWS Transit Gateway incurs data processing charges for each gigabyte processed. For petabyte-scale data transfers, whether one-time migrations or recurring burst workloads, these Transit Gateway data processing charges can become significant.

This article describes a cost-optimization pattern that uses a dedicated AWS Direct Connect gateway with private virtual interfaces to route storage traffic directly to VPCs hosting Amazon FSx for NetApp ONTAP, bypassing Transit Gateway data processing charges entirely.


Architecture Overview

Typical EDA Architecture (Before Optimization)

Diagram 1: Before optimization. All traffic including PB-scale SnapMirror replication flows through Transit Gateway, incurring $0.02/GB data processing charges

In this architecture, all traffic, including petabyte-scale SnapMirror replication data, flows through the Transit Gateway via a transit VIF and Direct Connect gateway, incurring data processing charges on every gigabyte.

Optimized Architecture (With Dedicated Direct Connect Gateway)

Diagram 2: After optimization. A second Direct Connect gateway with private VIF routes storage traffic directly to VPCs, bypassing Transit Gateway

By creating a second AWS Direct Connect gateway (DXGW-2) with private virtual interfaces associated directly to the storage VPC(s), you route bulk storage replication traffic to Amazon FSx for NetApp ONTAP without traversing the Transit Gateway. The storage VPCs can remain attached to the Transit Gateway for all other communication with the rest of your AWS environment or on-premises networks. Both Direct Connect gateways can coexist on the same physical Direct Connect connection(s) and provide multi-account, multi-Region support.

Implementation Steps

  1. Create a second AWS Direct Connect gateway (DXGW-2) dedicated to storage traffic.
  2. Associate storage VPC virtual private gateways (hosting FSx for NetApp ONTAP) with DXGW-2.
  3. Create a new private virtual interface on your existing Direct Connect connection(s) and attach it to DXGW-2.
  4. Enable route propagation on the storage VPC subnet route tables to dynamically learn on-premises storage prefixes via VGW. Since the VPC route table typically has a default route (0.0.0.0/0) pointing to Transit Gateway, the more-specific on-premises storage routes learned via VGW will take precedence automatically.
  5. On the on-premises router, the private VIF (via DXGW-2) will advertise VPC-specific CIDRs for the storage VPCs, while the transit VIF (via DXGW-1 and Transit Gateway) advertises summary routes covering all VPCs in the region. The more-specific storage VPC routes learned via the private VIF will be preferred automatically. Use BGP attributes such as Local Preference to further control path selection if needed.
  6. Validate end-to-end path and MTU.

How It Works

AWS Direct Connect Gateway: Key Characteristics

An AWS Direct Connect gateway is a globally available resource that enables connectivity between your on-premises network and VPCs across multiple Regions. Important characteristics include:

  • No additional charges. There are no additional charges for an AWS Direct Connect gateway itself. Standard port-hour and Data Transfer Out charges still apply to the underlying Direct Connect connection.
  • Global construct. A single Direct Connect gateway can connect to VPCs in different AWS Regions.
  • Multi-account support. Virtual private gateways from different AWS accounts can be associated with a Direct Connect gateway.
  • Association limits. A Direct Connect gateway can be associated with up to 20 virtual private gateways, or up to 6 Transit Gateways.
  • Coexistence. Multiple Direct Connect gateways can share the same physical Direct Connect connection through separate virtual interfaces.

Cost Savings Explained

PathData Transfer InTGW Data Processing
Transit VIF → DXGW → Transit Gateway → VPC$0.00/GBApplies per GB processed
Private VIF → DXGW → VPC (via VGW)$0.00/GBNot applicable

Data processing charges apply for each gigabyte sent from a VPC, Direct Connect, or VPN to the AWS Transit Gateway. By routing storage traffic through a private virtual interface to a dedicated Direct Connect gateway that is associated directly with the storage VPC's virtual private gateway, you bypass Transit Gateway entirely and eliminate these data processing charges.

For EDA customers transferring petabytes of design data, the savings can be substantial. For example:

  • 1 PB through Transit Gateway = approximately $20,000 in data processing charges ($0.02 per GB)
  • Recurring monthly PB-scale SnapMirror syncs can result in tens of thousands of dollars per month in avoidable charges

Implementation Considerations

MTU

  • Enable jumbo frames (9001 bytes) on the private VIF for high-throughput storage transfers. Transit VIFs support up to 8500 bytes.
  • Ensure end-to-end MTU consistency across on-premises routers, NetApp ONTAP inter-cluster LIFs, Direct Connect, and FSx for NetApp ONTAP subnets.
  • Changing MTU on a virtual interface may briefly disrupt all VIFs on the same physical connection (up to 30 seconds).

Routing and BGP

  • A Direct Connect gateway associated with a Transit Gateway cannot also be associated with a virtual private gateway, and vice versa. This is why a separate Direct Connect gateway is required for the private virtual interface to the storage VPCs.
  • Multiple VIFs (private and transit) coexist on the same physical Direct Connect connection, each with its own VLAN and BGP session.
  • Private VIF advertises VPC-specific CIDRs; transit VIF advertises summary/aggregate routes via allowed prefixes. Longest-prefix match handles path selection naturally on both sides.
  • Use BGP Local Preference or AS Path prepending on on-premises routers for additional traffic steering control if needed.

Constraints

  • VPCs associated with a single Direct Connect gateway cannot have overlapping CIDR blocks.
  • A Direct Connect gateway associated with virtual private gateways cannot simultaneously be associated with a Transit Gateway.

Resilience

  • Maintain at least two AWS Direct Connect connections and/or locations for redundancy.
  • Create matching private VIFs on each connection for the storage path.
  • The transit VIF path (via Transit Gateway) can serve as a failover for storage traffic, though data processing charges would apply.

Summary

For EDA customers transferring petabyte-scale data to AWS storage services over AWS Direct Connect, creating a dedicated Direct Connect gateway with private virtual interfaces provides a cost-effective path for bulk storage traffic that avoids Transit Gateway data processing charges. This approach:

  • Reduces cost. Eliminates Transit Gateway data processing charges on high-volume storage replication traffic.
  • Coexists with existing architecture. Both Direct Connect gateways operate on the same physical connections. Transit Gateway remains in place for general connectivity, routing, and inspection.
  • Maintains multi-Region, multi-account support. The Direct Connect gateway is a global resource and supports VPC associations across Regions and accounts.
  • Incurs no additional gateway charges. The Direct Connect gateway itself has no additional cost.

Related Resources