.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Updated and tested 21 October 2026
Three different products get sold under the name "cloud VPS". The first is an ordinary KVM virtual machine whose provider put "cloud" in the plan name because it sells better. The second is a VM on a hyperscaler (AWS, Azure, Google Cloud), billed by the second, surrounded by a catalogue of managed services and priced per gigabyte on the way out. The third is a VPS whose disk lives on distributed storage such as Ceph so the VM can move between hosts without stopping, which is a real technical difference and the one the term should have meant. When someone asks "VPS or cloud hosting", they're nearly always comparing the first product with the second, and that's the comparison this article makes. The third comes up in the storage section, because it changes what "high availability" means.
If your question is one step earlier, shared web hosting vs a VPS, the piece on web hosting vs VPS hosting covers it and none of the cost or storage arguments below apply there. Shared hosting has no instance to compare.
The hyperscaler model
A hyperscaler sells compute as an API. You call it, or a tool like Terraform calls it for you, and an instance appears within a minute with a network interface, a block volume and an identity that other services in the same account recognise. Stop the instance and billing stops. AWS's own EC2 on-demand pricing page states you "pay for compute capacity by the hour or second (minimum of 60 seconds)", and the other two large clouds work the same way. That granularity is the whole design: fleets of instances that grow at nine in the morning and shrink at six, controlled by an autoscaling group watching a CPU metric.
Around the compute sits the catalogue. A managed relational database that patches itself and fails over to a standby in another zone. Object storage with an HTTP API and versioning. Message queues, DNS, a CDN, a load balancer with a health check, a key store, a container scheduler. Each one is a service you'd otherwise install and run on a server, offered as something you configure and pay for by usage. That's the value, and for a team that would rather write application code than run Postgres, it's a large one.
The bill has three main lines: instance-hours, storage gigabyte-months and network egress. The last one surprises people. Traffic into the cloud is free or close to it, and traffic leaving to the internet is metered per gigabyte after a small allowance (AWS lists 100 GB a month across all services at the time of writing). A busy media server or a backup target that clients pull from can generate a network line larger than the compute line.
The VPS model
A VPS is a fixed monthly instance. You pick a size with a set number of vCPUs, a set amount of RAM and a disk, pay one price for the month and the bill is the same number next month unless you resized. Bandwidth is bundled: a port speed and either a transfer allowance in terabytes or an unmetered plan with a fair-use clause. No egress meter, no request counter.
Provisioning is instant too, and most providers have an API, but the culture is different. A VPS is a server you keep and maintain, with an IP address that stays the same for years and a hostname people know. You run the database on it, you run the reverse proxy, you set up the backups. The provider's job stops at the hypervisor and the network, and yours starts at the kernel. The first evening of that job is laid out in how to secure a VPS, and the ongoing part is monitoring and backups. Neither is optional on either platform, but on a hyperscaler some of it is sold back to you as a service.
Resizing exists but it's a step, usually a reboot to a larger plan, and downsizing is often not possible on the disk. Nobody autoscales a VPS in the hyperscaler sense. You size it for the peak, which is the trade the flat bill is built on.
