VPN Tunnel Capacity Calculator
Calculate effective VPN tunnel throughput given link bandwidth, the tunnel's rated limit, and protocol overhead.
Inputs
e.g. AWS Site-to-Site VPN: ~1.25 Gbps per tunnel
IPsec/IKE encapsulation overhead, typically 10-20%
Total Effective Throughput (all tunnels)
1,700.00Mbps
Effective Throughput per Tunnel
850.00Mbps
Throughput Lost to Overhead
300.00Mbps
Binding Constraint
Underlying link bandwidth
Per-Tunnel Cap (before overhead)
1,000.00Mbps
Step by step
Values used
Underlying Link Bandwidth = 1,000 Mbps; VPN Tunnel Rated Limit = 1,250 Mbps; Protocol Overhead = 15 %; Number of Parallel Tunnels = 2
Per-tunnel effective throughput
throughput = min(link_bandwidth, vpn_rated_limit) × (1 − overhead%)
Total Effective Throughput (all tunnels)
= 1,700.00 Mbps
Effective Throughput per Tunnel
= 850.00 Mbps
Throughput Lost to Overhead
= 300.00 Mbps
Binding Constraint
= Underlying link bandwidth
Per-Tunnel Cap (before overhead)
= 1,000.00 Mbps
How it works
A VPN tunnel's throughput is capped by the lower of two limits — the underlying physical link's bandwidth, or the VPN service/appliance's own rated per-tunnel throughput limit (many cloud VPN services cap a single tunnel around 1.25 Gbps regardless of link speed) — and then reduced further by encapsulation overhead from IPsec/IKE headers and encryption. Running multiple parallel tunnels (e.g. via ECMP or multiple connections) multiplies effective aggregate capacity, which is the standard way to exceed a single tunnel's throughput ceiling on high-bandwidth links.
Formula
Per-tunnel effective throughput
throughput = min(link_bandwidth, vpn_rated_limit) × (1 − overhead%)
- B
- Underlying link bandwidth
- L
- VPN tunnel's rated throughput limit
- o
- Overhead fraction
Frequently Asked Questions
Why do cloud VPN services cap throughput per tunnel regardless of link speed?
Site-to-site VPN tunnels are typically processed by a single CPU core or crypto-processing path on both ends (an IPsec tunnel is inherently single-threaded per Security Association), so there's a hard ceiling independent of the underlying network link's raw capacity — many cloud providers publish this per-tunnel limit explicitly (e.g. ~1.25 Gbps).
How do I get more than one tunnel's worth of throughput?
Run multiple parallel VPN tunnels (common with ECMP-based multi-tunnel VPN configurations) and load-balance traffic across them, since each additional tunnel typically gets its own independent per-tunnel throughput allowance rather than sharing one combined limit.
Why does VPN overhead reduce throughput below the rated limit?
IPsec/IKE encapsulation adds header and authentication bytes to every packet (see the VPN Overhead calculator for the per-protocol breakdown), and encryption/decryption itself consumes processing resources — both reduce the actual usable payload throughput below the tunnel's theoretical rated capacity.
Which limit usually binds first: link bandwidth or the VPN rated limit?
On typical mid-size business connections (under ~1 Gbps), the underlying link bandwidth is usually the binding constraint. On very high-bandwidth links (multi-gigabit), the VPN service's own per-tunnel rated limit often becomes the bottleneck instead, since it doesn't scale with link speed.