Burstable EC2 VPN: Standard or Unlimited CPU credits?

A small VPN gateway passes a speed test, feels fine, and then degrades after lunch. The instance was not lying during the test; it was spending credits it earned while idle. Burstable instances are designed to do exactly that, which makes a short benchmark a poor predictor of an afternoon of transfers. The two credit modes also fail in different ways, and choosing between them is the real decision.

Where the speed test borrowed from

One CPU credit is one vCPU running at full utilization for one minute. A burstable instance earns credits at its baseline rate and spends them when it exceeds that baseline. An idle night builds a balance; a busy morning draws it down.

That is why the first test looks good. The instance had a budget saved up, spent it on encryption work, and reported a healthy rate. Nothing in the result tells you what happens when the balance reaches zero. The benchmark measured a burst, and a burst is what the instance is designed to deliver. It never measured the steady state you are about to depend on.

The arithmetic you have to do

The inputs are the baseline percentage per vCPU, the vCPU count, the accrued balance, and the load you expect. For illustration only, take a hypothetical two-vCPU instance with a ten percent baseline per vCPU, 24 accrued credits, and one vCPU fully busy while the other idles. These numbers are declared inputs, not the specification of any particular instance size.

Earn rate:       2 x 10% x 60 = 12 credits/hour
Workload usage:  1 x 100% x 60 = 60 credits/hour
Net draw:        60 - 12 = 48 credits/hour
Accrued budget:  24 / 48 = 0.5 hours

Under those assumptions the budget is gone in about half an hour. Background work, changing load and the instance's own accounting move the result, and none of this predicts VPN throughput. What it predicts is when the sustained constraint starts to bite.

Note the second reading as well: one busy vCPU is roughly half the aggregate CPU capacity in this example. A moderate overall percentage can hide a saturated core, so look at per-core behaviour alongside the credit numbers.

Standard and Unlimited: same zero, different meaning

In Standard mode, an exhausted balance constrains sustained CPU toward the baseline. The instance keeps working, just slower, and the ceiling is predictable. In Unlimited mode the instance can keep drawing on surplus credits after the balance hits zero, and sustained use above baseline can produce charges under the service's accounting rules.

So a CPUCreditBalance of zero means throttling in one mode and possible billing in the other. That is the whole comparison, and it is why reading the metric without reading the mode is misleading.

Surplus is not a simple per-credit invoice either. Later operation below baseline can pay surplus usage down, and other charge conditions apply. Check the configured mode and the current service rules rather than relying on a free-tier claim from an old blog post.

What to watch during real work

Record CPUCreditUsage and CPUCreditBalance next to the transfer's duration and rate. On Unlimited, add CPUSurplusCreditBalance and CPUSurplusCreditsCharged. AWS's CPU-credit monitoring guide explains what each one reports and how often.

Retest with representative concurrency and enough duration to see the trend, and record the starting balance. An idle morning and a busy afternoon are not the same experiment, even with identical commands.

Limits that are not CPU

Network bandwidth has its own baseline and burst behaviour, and packet-rate or connection allowances can bind before the CPU does. Memory matters when the VPN implementation keeps per-connection state, and a small instance can run out of it long before it runs out of credits.

A healthy credit balance therefore proves one thing: the CPU budget is not the current constraint. It says nothing about the network path, and it says nothing about what happens at twice the concurrency. Watch the network metrics in the same window as the credit metrics, so a throughput drop has a candidate cause instead of a theory.

Choosing a baseline on purpose

Use the measured sustained workload to pick a baseline, or accept bursting explicitly and budget for it. Either answer is defensible when it is written down; neither is defensible when it is inferred from someone else's successful video stream.

If the gateway is load-bearing, treat the credit mode as part of the capacity plan rather than a default you never opened. The mode you choose is the failure you get to predict.