Voice Traffic Hates Virtualization: When Bare Metal Earns Its Keep (and When It's Overkill)

Look, I get the appeal of the cloud. Spin up a VPS, snapshot it, destroy it, rebuild it in Miami. For most workloads, virtualization is the greatest gift sysadmins ever received. But voice traffic is not most workloads, and anyone who's paged on-call for a SIP system running on an oversold KVM node knows exactly what I'm talking about.

Let's talk about where bare metal genuinely wins, where it doesn't, and what the numbers actually look like.

The Case for Metal: Jitter Is a Budget Problem

Real-time media lives and dies by timing consistency. Your RTP stream doesn't care about average CPU — it cares about the worst 20 milliseconds of the last five minutes. A hypervisor with noisy neighbors introduces exactly that: steal time spikes, vCPU scheduling delays, and jitter that shows up as robotic audio right in the middle of your biggest customer call.

On a typical oversold VPS, we've measured CPU steal percentages swinging from 0% to 15% during peak hours. Fifteen percent steal time during an RTP flow means the jitter buffer is scrambling to compensate, and once it exceeds about 30–40ms of variance, callers hear it. On dedicated hardware, steal time doesn't exist. Your kernel owns the silicon.

Clock Drift and the RTC Problem

Here's the issue nobody mentions in the VPS pricing pages: virtualized timers lie. KVM guests rely on paravirtualized clocks that can drift under load, and timing-sensitive applications feel it first. Asterisk historically demanded a timing interface (DAHDI, or timing source) for conferencing and IAX2 — on metal, you get clean hardware RTC and HPET. In a guest, you're at the mercy of how the host is configured, which you don't control.

Modern Asterisk is less timer-picky than it used to be, but if you're running transcoding-heavy conferencing, media relays, or anything touching GSM codec conversion at scale, predictable clocks matter. Bare metal gives you hardware you can actually profile.

The Money Math

Let's price a realistic mid-size deployment — a FreeSWITCH or Kamailio box handling 200–300 concurrent calls with transcoding:

• Dedicated server (Hetzner AX-series, OVH Advance, or a colo box): $60–$150/month, 8–16 dedicated cores, no steal time, unmetered-ish bandwidth
• Comparable cloud instances (AWS c5.2xlarge territory): $250+/month before you touch bandwidth charges, which for RTP media are brutal — a busy hour of media can push terabytes
• Cheap VPS: $20–$40/month, fine for signaling, risky for media

Bandwidth is the hidden killer in the cloud. RTP doesn't compress, and egress pricing at $0.08–$0.10/GB turns a popular PBX into a surprise invoice. Most bare-metal providers include multiple terabytes or sell bandwidth at a fraction of hyperscaler rates.

Five Reasons to Go Bare Metal

1. Zero noisy neighbors for latency-sensitive RTP flows
2. Bandwidth economics — media-heavy workloads get destroyed on cloud egress pricing
3. Hardware access — PCIe GSM cards, Digium/Sangoma T1 boards, and echo-cancellation hardware need real PCIe passthrough, which ranges from painful to impossible on public clouds
4. Predictable performance — your capacity planning means something when you're not sharing a physical host
5. Compliance and data residency — CSEC and carrier-adjacent requirements are easier to demonstrate when you can point at physical hardware

Three Times You Should Stay in the Cloud

1. Signaling-only infrastructure. Kamailio registrars, SIP proxies, routing engines — these are lightweight and bursty, and a VPS handles them beautifully. If it's not touching RTP, virtualize it.
2. Dev, staging, and labs. Testing a dialplan change doesn't need dedicated silicon. Spin it up, break it, nuke it.
3. Geographic edge presence. Need a small SBC in Dallas, another in Ashburn, a third in Denver? Provisioning five $15 VPS beats five dedicated boxes for latency-optimized edge relays that handle modest call volume.

The Hybrid Answer Most Shops Land On

In practice, the winning architecture for most US telecom shops is a split: media and transcoding on bare metal in a well-connected datacenter (the 1670 Ashburn corridor, Dallas, or LA depending on your user base), signaling and management planes in the cloud where elasticity is actually useful.

One more practical note: bare metal providers like Hetzner, OVH, and PhoenixNAP have gotten dramatically better for telecom work — some offer dedicated AMD EPYC boxes with proper NUMA topology and even IPMI access, which means you can run real-time tuning (isolcpus, IRQ affinity, disabling deep C-states) the way you would on your own hardware.

Bottom Line

If your workload touches RTP at volume, terminates GSM or T1 circuits, or needs hardware you can physically touch, bare metal isn't nostalgia — it's engineering. If it's signaling, staging, or edge relays, stop overthinking it and rent the VPS. The worst outcome isn't choosing wrong; it's paying hyperscaler egress rates to deliver jittery audio from an oversold virtual machine.