Most VPS buyers spend their evaluation time comparing vCPU counts and RAM allocations, then discover six months into production that the network was the problem all along. Latency spikes during peak hours, throughput that never reaches the advertised port speed, jitter that kills real-time workloads: these are not hardware failures. They are the predictable consequences of shared network architecture that the provider chose and the buyer never asked about. Understanding VPS network isolation before you sign is the difference between a platform that holds under load and one that quietly degrades exactly when you need it most.
The three specifications hiding inside “bandwidth”
Every VPS plan quotes a bandwidth figure. That figure is actually three distinct things bundled together, and providers rarely separate them clearly. The first is port speed: the maximum throughput the interface can carry. The second is monthly transfer allowance: the total volume of data you can move before throttling or overage charges apply. The third, and most consequential, is whether that port speed is dedicated or burstable.
A dedicated 1 Gbps port means your VPS has exclusive access to 1 Gbps; co-located instances on the same physical host do not compete for that allocation. A shared 1 Gbps port means the host’s uplink is divided among however many VMs the provider has placed there. Burstable bandwidth lets you reach the headline figure when the network is idle, then throttles you when it is not. Burstable is the default in most consumer-grade VPS plans, and it is rarely labelled as such.
Transfer accounting adds another wrinkle. Some providers count only outbound traffic against your monthly allowance; others count both directions. For workloads that receive large uploads, such as backup targets or file ingestion pipelines, the inbound accounting model can exhaust an allowance far faster than the spec sheet suggests.
Steal time and the noisy-neighbour problem
The noisy-neighbour effect is not a bug in a specific provider’s implementation; it is a structural property of shared infrastructure. A hypervisor time-slices physical CPUs across many VMs simultaneously. When a neighbouring VM saturates its allocation, your vCPU sits ready to run but cannot, because the hypervisor is serving someone else’s workload. The Linux kernel exposes this as steal time, reported as %st in tools like top and vmstat.
A commonly used diagnostic threshold: if steal time sits above roughly 10% for around 20 minutes, the instance is experiencing meaningful contention. Research into virtualised environments has documented performance degradation of up to 16 times baseline under heavy neighbour load. The same principle applies to network resources. If the physical host has a 10 Gbps uplink shared across dozens of VMs, a single tenant running a bulk transfer can compress everyone else’s effective throughput to a fraction of what the spec sheet promised.
The headline port speed is what you get when nobody else wants it. The guaranteed throughput is what you get when everyone does.
KVM with paravirtualised virtio drivers is the current standard for minimising this exposure at the compute layer: each VM runs its own kernel on virtual hardware, providing genuine isolation boundaries. Container-based hosting (OpenVZ, LXC) shares the host kernel and offers no equivalent boundary. But hypervisor choice only addresses CPU and memory isolation. Network isolation at the uplink layer is a separate architectural decision, and it is entirely in the provider’s hands.
QoS and traffic shaping: what you control versus what they control
Traffic shaping and policing are the two mechanisms providers use to manage VPS shared network performance. Shaping delays out-of-contract packets, introducing latency and jitter. Policing drops or relabels them, which is harsher but avoids queue buildup. Both are QoS techniques applied at the network interface level.
Here is the structural asymmetry that most VPS documentation glosses over: you can configure egress shaping inside your VM using Linux tools like tc and the HTB qdisc. You cannot shape inbound traffic from inside the VM at all. Inbound shaping requires either an IFB (Intermediate Functional Block) device or, more practically, shaping at the upstream router. That upstream router belongs to the provider. Whatever QoS policy governs how your traffic is prioritised on the shared uplink, the provider wrote it, and you cannot inspect or modify it.
This means that cloud VPS traffic shaping at the uplink level is a provider commitment, not a tenant capability. AWS, Azure, and GCP all offer QoS controls within their virtual network layers, but those controls apply to traffic flows between resources inside their platforms. The physical uplink contention model underneath is still theirs to manage. When evaluating a provider, the right question is not whether they offer QoS, but whether they make enforceable commitments about how the shared uplink is managed under contention.
What “carrier-neutral” and “Tier III” actually mean for your traffic
Marketing copy in the VPS market is full of phrases that sound like guarantees but are not. “Carrier-neutral” and “Tier III” are two that carry real technical and contractual meaning, and they matter specifically for network quality.
A carrier-neutral facility is not locked to a single transit provider. The operator can peer directly with multiple carriers, internet exchanges, and cloud on-ramps, choosing the best path for each traffic class rather than accepting whatever a single upstream provider offers. At a Tier III facility, redundant power and cooling paths mean the physical infrastructure sustains planned maintenance without downtime, and the uptime commitment is contractual rather than aspirational.
We operate our VPS infrastructure across Tier III, carrier-neutral sites, each ISO 27001 certified, with a contractual 99.9% uptime SLA. At AMS1 in Amsterdam, direct peering at AMS-IX and interconnects to AWS, Azure, GCP, Oracle, and Cloudflare mean that traffic to and from those platforms does not traverse public internet paths with unpredictable latency. When an engineer asks us what happens to their traffic under contention, we can point to the physical architecture and the contract, not a marketing page.
VPS networking best practices: what to ask before you commit
The following questions will separate providers who have thought through their network architecture from those who have not.
- Is the port speed dedicated or shared? If the answer is “burstable” or the spec sheet does not say “dedicated,” assume shared.
- What is the oversubscription ratio on your physical uplinks? Most providers will not answer this. The refusal is itself informative.
- How do you enforce QoS on the shared uplink? Ask specifically about what happens when a co-located VM saturates the link.
- Is the bandwidth guarantee in the contract? A number on a features page is not a service level agreement. Ask for the SLA document.
- What hypervisor technology do you use? KVM with virtio drivers is the current baseline for production isolation. Anything kernel-sharing warrants further scrutiny.
- How is inbound traffic counted? For workloads that receive significant data, this changes the economics of the plan entirely.
The underlying principle behind all of these is that VPS bandwidth guarantees and VPS network isolation are architectural properties, not marketing claims. They are determined by decisions the provider made about physical hardware, uplink provisioning, hypervisor configuration, and QoS policy, long before you signed up. The only way to verify them is to ask directly, read the contract, and, where possible, run your own benchmarks against the specific host rather than the provider’s published averages.
Providers competing on headline price tend to compress on exactly these dimensions: network quality, storage IOPS, and support SLAs are where margin gets recovered after a loss-leader compute price. The spec sheet comparison that shows two plans as equivalent rarely survives contact with the actual network architecture underneath.
