Azure B-series VMs: understand CPU credits before sizing a busy application

Burst capacity is a workload fit decision

Azure B-family virtual machines use CPU credits to support workloads whose demand is usually modest but occasionally rises. The important question is not simply how many vCPUs the size lists. It is whether the application's normal CPU requirement fits the baseline and whether its bursts leave enough quiet time to rebuild credits.

A B-series VM earns credits while operating below its baseline CPU performance and spends credits while working above it. When available credits are exhausted, CPU performance is limited to the baseline until credits accumulate again. A workload that starts fast and slows after a sustained busy period can therefore be hitting the credit boundary rather than an application regression.

Measure the busy period, not only the daily average

A low daily average can conceal an hour of continuous processing. Background jobs, scheduled reports, builds and traffic peaks may overlap. Inspect CPU demand during those periods alongside queue latency and application response time. Where exposed for the selected size, CPU credit metrics help connect the observed slowdown to the burstable performance model.

Memory, storage throughput and network requirements are separate sizing constraints. Additional credits cannot correct an application that is swapping, a disk that has reached its performance limit or a connection pool that is saturated. Capture those metrics together so a proposed VM change addresses the actual limiting resource.

Build a representative comparison

1. Record the chosen size's documented baseline and credit behavior.
2. Measure CPU, memory, disk and latency across a full workload cycle.
3. Include scheduled background activity and the busiest traffic interval.
4. Run a comparable test on a size designed for sustained CPU demand.
5. Compare the measured outcome with regional prices and operational requirements.

Use Azure Advisor's cost recommendations as a starting point rather than a complete application performance review. Its recommendations use measured utilization and defined criteria. Validate them against the application's burst pattern, memory needs, recovery time and availability design before approving a resize or shutdown.

Plan the operational effect of resizing

A VM resize can involve a restart, a deallocation or a different placement constraint depending on the selected change. Check the current documentation and the availability of the target size in the intended region. Schedule the change with application health checks and a recovery path, especially when a single VM carries both interactive traffic and background work.

For a queue-heavy service, compare reducing concurrency with moving to a sustained-performance VM. Lower concurrency can improve latency and memory stability while leaving more work pending; a larger machine can improve capacity while increasing cost. The decision should state the required completion rate and response-time target rather than promising that more vCPUs will solve every bottleneck.

Verify the result against the original requirement

After the change, measure the same busy interval and check queue age, completion rate and request latency. Keep the old metrics with the new ones so the improvement can be assessed honestly. A well-chosen burstable VM is economical for the right demand pattern; a workload needing continuous CPU is better evaluated against a size designed to supply that performance consistently.

References

• B family VM size series - Azure Virtual — Microsoft Learn
• Optimize virtual machine (VM) or virtual machine scale — Microsoft Learn