WireGuard throughput by AWS instance size

A Weft site in AWS is one Ubuntu instance in your VPC, joined to your offices over WireGuard. Which size it should be comes down to one question: how much traffic must it carry, and for how long? We measured eight instance types to answer it.

What we measured

For each type, two instances in the same availability zone of eu-west-2 (London), running Ubuntu 24.04. Between them we ran iperf3 twice: straight across the VPC, and through a kernel WireGuard tunnel, the same WireGuard Weft uses. Each test ran for 30 seconds, with one stream and with four. We did this on 2 October 2026.

Two things to keep in mind. This is plain WireGuard; Weft carries VXLAN inside its tunnels, which costs a few per cent more. And both ends sat in one zone, so these are the instance's limits, not your office broadband's: a site talking to an office is usually limited by the office line first.

Results

Instance	vCPU	Direct, 4 streams	WireGuard, 1 stream	WireGuard, 4 streams	AWS baseline	Price, per month
t4g.small	2	4.95 Gbit/s	2.82	2.81	0.128	$13.72
t4g.medium	2	4.96	2.86	2.71	0.256	$27.45
t4g.large	2	4.96	2.65	2.59	0.512	$54.90
t4g.xlarge	4	4.97	3.88	4.12	1.024	$109.79
c7g.large	2	12.41	4.55	4.57	0.937	$62.71
c7g.xlarge	4	12.41	6.31	6.81	1.876	$125.34
c7i.large (Intel)	2	12.41	5.48	5.85	0.781	$77.42
c7i.xlarge (Intel)	4	12.41	7.04	7.17	1.562	$154.83

Throughput in Gbit/s. "AWS baseline" is the bandwidth AWS guarantees indefinitely, from the EC2 API (BaselineBandwidthInGbps). Prices are London on-demand Linux rates from the AWS Price List API on 2 October 2026, times 730 hours, in US dollars; data transfer is extra.

The column that matters is the baseline

Every type above is sold as "up to" 5 or 12.5 Gbit/s, and a fresh instance delivers it. It is spending a bucket of network credit, and when that runs out it drops to its baseline. To see how quickly, we ran WireGuard on a fresh t4g.small for fifteen minutes:

Time	WireGuard, 4 streams
0 to 10½ minutes	2.70 to 2.81 Gbit/s, steady
10½ to 11 minutes	0.38 Gbit/s
11 to 15 minutes	0.117 Gbit/s, steady

That is a fall of more than twenty times, to just under the 0.128 Gbit/s baseline once WireGuard's own overhead is taken off. The bucket refills while the link is quiet, so ordinary office traffic, which comes in bursts, sees the fast rate most of the time. A backup job or a large replication that runs for an hour sees the baseline.

The bigger types burst too: c7g and c7i are "up to 12.5 Gbit/s" with baselines below 2. Our 30-second figures for them are burst figures, and the same reasoning applies.

Which size

A few laptops reaching a cloud network, light traffic: t4g.small. Bursts to nearly 3 Gbit/s through WireGuard and holds 128 Mbit/s. $14 a month.
An office's day-to-day traffic into the cloud, file shares and line-of-business apps, a few hundred Mbit/s at most for long: t4g.large, 512 Mbit/s sustained.
Sustained gigabit, replication, backups, or a hub many sites pass through: c7g.xlarge, 1.9 Gbit/s sustained and nearly 7 through WireGuard in bursts. Or t4g.xlarge for 1 Gbit/s sustained at a little less.

Graviton or Intel? Intel's c7i was a little faster through WireGuard in bursts, but costs about a quarter more and has the lower baseline at each size. For a Weft site, the Graviton c7g gives more sustained bandwidth per dollar, and it is the architecture our own fleet runs.

One more thing about the t4g types: they also run on CPU credit. Hours of full-rate encryption can spend that as well, and in the default "unlimited" mode AWS charges for the excess rather than slowing you down. If a site will be busy for long periods, a c7g avoids both kinds of credit altogether.

Measuring your own

Your traffic is the real test. The console's Paths page shows each site's tunnels with latency and loss, and the site's own page shows its traffic over time. If a cloud site's traffic sits at its baseline for long stretches, it is time for the next size up, which in AWS is a stop, a change of type and a start.