Skip to main content
Aviatrix gateways deliver encrypted, inspected network throughput on standard cloud compute instances. Because capacity maps directly to instance families, you size a gateway the same way you size any cloud workload: start with the recommended size, measure, and resize or scale out without re-licensing or redeploying. This page lists the instance type behind each Aviatrix standard gateway size and the measured throughput you can expect from it. For higher-throughput deployments, Aviatrix recommends the AWS C6in instance family and the Azure Dsv5 instance family. Both support High Performance Encryption (HPE), which distributes traffic across multiple IPsec tunnels to deliver encrypted throughput well beyond the roughly 1.25 Gbps limit of a single IPsec tunnel.
All figures are the median encrypted throughput measured by Aviatrix across test runs. Large Payload uses full-size packets, the figure vendor datasheets commonly quote. IMIX is a blend of packet sizes that better reflects production traffic, so size for IMIX. Figures marked * are burst performance when operating within burst credits; see About Burst Performance. Treat these numbers as planning guidance, not a guarantee.

Quick Sizing

IMIX throughput per Aviatrix standard size, by gateway role. For Spoke Gateways with Distributed Cloud Firewall, see Performance with Distributed Cloud Firewall. Use this table to find a starting size, then check the detailed tables below.
For more throughput than a single instance provides, scale out: Transit and Spoke Gateways support up to instances with ECMP load balancing, so aggregate fabric capacity is not limited to the throughput of a single instance.

Choosing a Gateway Size

  • Spoke Gateways serve the workloads of a single VPC/VNet. Small is the most commonly deployed production Spoke Gateway size across Aviatrix deployments.
  • Transit Gateways are the hub of the fabric and terminate many spokes, so they need more headroom. Medium is the most common Transit Gateway size on AWS, and Small on Azure.
  • The same instance type can map to different standard sizes by role. For example, on AWS a c6in.large is a Small Transit Gateway but a Large Spoke Gateway. The tables below show the size for each role.
  • X Small sizes are for dev/test, not production.
After deployment, let the platform do the sizing work. Auto Right-Sizing watches real gateway usage and recommends a cost-efficient size from the tables below.
Earlier versions of this guide recommended Azure B-series, Dv2-series, and Fsv2-series instance types. Microsoft has announced retirement of these series in 2028. Choose Dsv5-series sizes for all new production gateways; existing gateways on retiring series continue to run but should be migrated at the next resize. Dsv6-series instance types are also supported beginning with Controller 10.0 and perform equivalently to their Dsv5 counterparts in Aviatrix testing.

Transit Gateway Performance

Measured end to end through a Spoke-Transit-Spoke path.

Spoke Gateway Performance

Measured Spoke Gateway to Spoke Gateway.
Custom rows are instance types outside the Aviatrix standard sizes for that role, shown for reference.

Performance with Distributed Cloud Firewall

Aviatrix inspects traffic on the gateway itself; there is no separate firewall appliance to size, license, or hairpin traffic through. The following figures are for a Spoke Gateway performing NAT on egress traffic, with traffic exiting directly from the spoke (no transit in the path). NAT Only is the same gateway with no Distributed Cloud Firewall policy applied. Each cell shows Large Payload / IMIX throughput in Gbps.

AWS

Azure

L7 inspection is packet-size sensitive: large-payload throughput stays close to NAT-only numbers, while IMIX traffic pays a higher per-packet inspection cost. Size egress gateways for your IMIX number, or scale out. Distributed Cloud Firewall is supported on burstable sizes down to Standard_B1ms for L4-only policy, Standard_B2s with external groups, and Standard_B2ms with IDS or IPS enabled. See Minimum Spoke Gateway Sizing for the full matrix.

FireNet

When you insert a third-party firewall through Transit FireNet, end-to-end throughput is limited by the lower of the firewall appliance’s inspection rate and the Transit Gateway’s forwarding rate. Size the Transit Gateway one standard size larger than the size whose throughput matches your target, and consult your firewall vendor’s cloud datasheet for the appliance-side limit. The following figures are for the Aviatrix side of the path (Spoke-Transit FireNet-Spoke, end to end).

About Burst Performance

Figures marked * are burst performance when operating within burst credits. Two kinds of AWS instance burst:
  • t3 instances earn CPU credits while traffic is light and spend them during bursts.
  • c6in.large, c6in.xlarge, and c6in.2xlarge earn AWS network burst credits the same way. IMIX traffic on these sizes stays below the baseline and is not affected. c6in.4xlarge and larger sustained full throughput for the entire test.
Most production gateways carry bursty traffic well below line rate and operate within burst credits nearly all of the time. Under continuous full line-rate load, credits run out after the time shown in Approximate Burst Duration, and throughput drops to the rate shown there. For workloads that run at full line rate for long periods, such as bulk data migration or backup, size for that post-burst rate or choose c6in.4xlarge or larger. Azure B-series instances are also burstable (marked *). Dsv5 instances showed no burst behavior in testing.
Aviatrix measured these figures on Controller versions 8.0 through 9.0 using AES-128 encryption with HPE enabled (except where marked Non-HPE), with CyPerf-generated traffic in a single region. Each figure is the median throughput across repeated test runs. Burst durations are the longest burst observed at full line rate starting with full credits; actual duration depends on the credit balance when a burst begins.