Users or Throughput? Sizing a VPN Server for Real Load
Account counts do not size a gateway; overlapping work does. Compare concurrent transfers, per-core CPU and queueing, then write the workload down.
Ten idle accounts cost less than one nightly backup that saturates the tunnel, and a user count cannot tell the difference. Sizing a VPN server is a comparison between two numbers: the concurrency you actually carry and the resource that runs out first. Most capacity mistakes come from choosing the first number and never measuring the second. Do both, in that order, and the hardware decision stops being a guess.
Compare the account count with the busy hour
The account count is a licence and a support boundary; the busy hour is a load. List the work that overlaps in that hour: calls, remote administration, large downloads, backups and the private application requests that keep people waiting. Then mark, for each item, whether it crosses the gateway and in which direction. Calls are symmetric and delay-sensitive, while a backup is one direction and tolerant of a slow start, so they stress different parts of the path.
Direction decides which link matters. A home uplink is rarely symmetric, and a branch that downloads all day hits its downstream limit long before the gateway breaks a sweat. Write the direction and the tunnel scope next to each item, because a gateway carrying only private destinations and one carrying all internet traffic are two different sizing problems.
Add background load as its own row: client updates, telemetry, and whatever the host does besides forwarding. Those bytes are easy to forget and they are counted by the same interface.
Find the resource that runs out before the link does
The link is only one candidate. A single tunnel's crypto work can pin one core while the interface sits half idle, and a saturated queue can make calls unusable at a throughput that looks mediocre on a graph. A destination that is one slow route away can also look like gateway weakness from the client's chair. Three observations separate these cases, and none of them needs a burst test.
| Observation | What to inspect |
|---|---|
| one core busy, bytes steady | per-core CPU, implementation, offload status |
| calls degrade during transfers | queueing and the access link |
| one remote destination slow | that route and its service |
Measure with a transfer you are permitted to run, and add the concurrent work in steps rather than all at once. Read the sustained rate and the interactive response together, because a peak-rate test alone hides a session that has become unusable. A gateway passing its maximum throughput while calls break up has not passed the test.
Then repeat the run with optional workloads stopped. A limit that moves when the backup stops was never the gateway's limit.
Turn the comparison into a number you can defend
Pick the resource that ran out and express the requirement in its units: cores at a target utilization during the busy hour, bits per second in each direction, or concurrent sessions under a delay bound. Leave room for updates, diagnostics and recovery, because a server sitting at its measured ceiling has nothing left for the work that keeps it running. Then write the numbers beside the configuration that produced them, including the client count and the test used.
A users-per-core figure is the least portable number in this exercise, because it assumes a protocol mix and a device profile that the next site does not share. Keep the measurement and drop the formula. When somebody asks for capacity for fifty more users, the honest answer is the busy-hour profile of those fifty, not a multiplication.
Record the response time as well as the throughput. Capacity that only preserves bulk transfer is not capacity for the people on calls, and the next review will ask about the difference.
Choose between scaling up and splitting the role
When the measured limit is one core, more cores at the same speed may not help; a faster core or a different worker model can. When the limit is aggregate CPU, a larger instance is the direct fix. When the limit is the access link, no server change helps and the comparison ends at the provider. Splitting the web and VPN roles onto separate hosts buys isolation at the cost of a second management surface.
Compare those options against the recorded number rather than against each other. A change that doubles a resource which was not the constraint is cost with no benefit, and the record is what lets you say so without an argument. Re-measure after the change with the same workload, or you have replaced one guess with another.