VPS, dedicated server or cloud instance: what actually differs

Shop for a server and the same thing arrives in three wrappers. A VPS has a price per month. A dedicated server has a bigger price per month, or a form to ask for a quote. A cloud instance has a price per hour, billed by the second, and a calculator to estimate what you might owe. The names suggest three different technologies, and mostly they are not: the VPS and the cloud instance are usually the same kind of virtual machine on the same kind of shared server, and the dedicated server is that server with nobody else on it. A fourth name, VDS, sits between the VPS and the dedicated server.

What differs is the deal. Who else runs on the hardware, whether you pay for the month or for the seconds you used, how fast you can add a second server or hand one back, and what happens on the night a power supply dies. Put the options side by side on those lines and the choice mostly follows from the shape of your load, not from which name sounds more modern.

Four ways to rent a computer

VPS (virtual private server). A virtual machine on a physical server shared with other customers. You get your own operating system, kernel, memory and disk. Your virtual CPUs are threads that the host schedules onto cores it shares among all its guests, so when every core is busy, yours wait. What is a VPS? covers the mechanism.

VDS (virtual dedicated server). Still a virtual machine on a shared server, but with processor cores allocated to it. One common tool is pinning: libvirt, a management layer commonly used with KVM, lets each virtual CPU be pinned to chosen physical CPUs of the host.¹⁶ Pinning only says where your vCPUs may run; a VDS also needs the host to keep every other guest off those cores, which is the provider's side of the deal. Some hosts call this "dedicated vCPU" or "dedicated cores". The machine is still shared. vCPU vs CPU core explains what a core of your own buys.

Dedicated server, or bare metal. The whole physical machine. No other customer runs on it, and there is no provider hypervisor between your operating system and the hardware unless you install one yourself. The two names mean the same product, and bare metal is also what AWS calls the instances that give you a whole machine.¹⁰

Cloud instance. A virtual machine, or sometimes a whole machine, taken from a large provider's pool through a web console or an API and billed for the time it exists. On AWS, an instance runs on hardware that other accounts may also be using, unless you choose dedicated tenancy.⁸

Containers also turn up in price lists. Docker describes them as isolated processes that share the operating system kernel with the other containers on a machine, where each virtual machine carries a full copy of an operating system.¹⁸ A container is a good way to run one packaged application, not a machine whose kernel you control, so this guide leaves containers aside.

The drawing at the top lines the options up by what is yours alone, with a container as the most shared point for reference. Cloud is not one of its columns: clouds rent everything from shared cores to whole machines, the first clue that the word describes something other than hardware.

What makes it cloud: NIST's five characteristics

The usual reference is the definition NIST, the US standards body, published in 2011. It calls cloud computing a model for on-demand network access to "a shared pool of configurable computing resources" that can be rapidly provisioned and released with minimal effort from the provider, and lists five essential characteristics:¹

• On-demand self-service. You set up servers and storage yourself, when you want them, without anyone at the provider handling the request.
• Broad network access. Everything is reached over the network, with ordinary clients and protocols.
• Resource pooling. One provider's hardware is shared among many customers and moved between them as their demand changes.
• Rapid elasticity. Capacity can be added and removed quickly, sometimes by automation, and from the customer's side it seems to have no ceiling.
• Measured service. The system meters use, so it can be monitored, controlled and reported, with provider and customer both able to see the numbers. NIST notes that the meter is typically what the customer pays by.

Renting a virtual machine on those terms is what NIST calls infrastructure as a service: you control the operating system, storage and applications, and the provider controls the infrastructure underneath.¹

Notice what the list leaves out: virtual machines, a kind of processor, who else is on the hardware. Red Hat puts it bluntly: "Neither cloud computing nor clouds are technologies unto themselves." The machinery underneath, it adds, may be physical servers, virtual machines or containers.² A cloud is defined by how it is run and sold.

Hold a typical VPS host up against the list. Ordering and reinstalling from a control panel is self-service; the server is reached over the internet; the hosts are a pool shared by many customers. That is three of five. The last two are where a classic VPS offer usually differs. Capacity comes in whole plans paid a month at a time, so you can add a server quickly but not give it back before the month is out, and use is billed as a flat price rather than by the meter NIST describes as typical. Elasticity and metering are what the word cloud adds in practice, and they are the two things to decide whether you need.

The large clouds, meanwhile, sell every level of sharing. AWS's T family of burstable instances gives a baseline of processor performance with the ability to burst above it, on the reasoning that plenty of general-purpose servers are quiet on average and rarely need full processor power for long.⁷ That is the shared-core bargain of a VPS under another name. At the other end, Dedicated Instances keep other accounts off your hardware,⁸ a Dedicated Host gives you the physical server itself,⁹ and bare metal instances drop the virtualisation layer, so your software reaches the hardware directly.¹⁰

Who shares the machine, and what you control

Walk the top drawing from the container to the dedicated server and one part of the machine after another becomes yours alone. On a VPS, the shared part you will notice is processor time. Your vCPUs compete with other guests' for the same cores, and when all of them are busy yours wait. Linux inside the guest counts that wait in /proc/stat as steal, which the kernel documentation defines as "involuntary wait".¹⁷ Memory is normally allocated to you, but the processor's caches and memory bandwidth, the disks and the network port serve every guest on the host.

A VDS removes the competition for cores and leaves the rest shared. That is the point of the middle option. It fixes the one resource whose sharing shows up as unpredictable delay, without paying for cores you would not use, while a neighbour copying a large backup still takes a share of the same disks and port. For a game server's main loop, a database under steady load or a build runner, cores are usually what matters, so a VDS is often the whole answer.

On a dedicated server there is nobody to share with. Every core, all the memory bandwidth, the disks and the network card are yours, and so is the responsibility for all of them.

Control runs along the same line. On every option except a container you have root, your own kernel and your own operating system, which is all most software needs. What only a whole machine gives you is the layer underneath:

• Your own hypervisor. You can run KVM on the machine and divide it up yourself. AWS lists workloads that need low-level hardware features, such as Intel VT, among the reasons to choose bare metal.¹⁰
• Licences tied to hardware. Some software is licensed per physical core or per socket. AWS's Dedicated Hosts let customers use such existing per-socket and per-core licences.⁹
• A known list of tenants: you. If a contract or a policy says your workload must not share hardware with other organisations, only a whole machine, rented by the month or from a cloud, satisfies it.

How you pay: flat months against metered seconds

The monthly model is simple. A VPS, a VDS or a dedicated server has a price per month, and you pay it whether the server was busy every minute or idle the whole time.

The metered model charges for time. AWS's On-Demand instances are paid by the hour or by the second, with a minimum of 60 seconds and no long-term commitment.³ Google's Compute Engine charges at least one minute and then bills in one-second increments.¹³ AWS gives its own example: run an instance for 20 seconds and you pay for a minute; run it for 3 minutes and 40 seconds and you pay for exactly that.⁴ The grain is not the same everywhere, either: the same AWS price list bills SUSE Linux Enterprise Server instances by the full hour.³

The meter covers the instance, not everything around it. A stopped AWS instance is not charged for usage, but its storage volumes still are,⁴ Elastic IP addresses are charged whether in use or idle, and data sent out to the internet is priced per gigabyte beyond a free allowance.³ A cloud bill is a sum of line items, and the instance is only one of them.

Metering also comes with a discount for giving up elasticity. AWS's Savings Plans lower the rate in exchange for committing to a set amount of compute per hour for one or three years.¹² The provider is then pricing what a monthly plan prices: capacity you pay for whether or not it is busy.

In an average month: 365 × 24 ÷ 12

730hours

Minimum charge for an AWS On-Demand instance

60seconds

A six-hour nightly job in an average month: a quarter of 730

182.5hours

Worked example: when paying by the second wins

Prices change and differ between providers, so this example uses none. It uses one ratio you can work out from any two price lists. Take a flat-rate server at a monthly price M and a comparable metered instance at an hourly price h. Run the metered one for a whole month and it costs 730 × h. Call the ratio between the two k:

k = (730 × h) ÷ M

If k is 1.5, running the metered instance all month costs one and a half times the flat plan. Now three workloads.

A steady API and its database. Busy around the clock, one server's worth, 730 hours a month. Flat costs M; metered costs 730 × h, which is k × M. Metering wins only if k is below 1: only if the hourly price, spread over a month, undercuts the monthly one. At k = 1.5 the meter costs 1.5 × M, half as much again, so the flat plan wins.

A nightly batch job. A report that needs a server for 6 hours a night: 6 × 365 ÷ 12 = 182.5 hours a month, exactly a quarter of 730. The flat server costs M and sits idle 18 hours a day. Metered, you pay for 182.5 hours, 0.25 × k × M. Metering wins as long as k is below 4. At k = 1.5 that is 0.375 × M, well under the flat M.

An evening peak. A shop or a game community that needs two servers' worth of capacity all day and eight from 18:00 to 22:00. Flat plans cannot shrink for the quiet hours, so you rent eight for the month: 8 × M. Metered, you run two all month (2 × 730 = 1,460 hours) and six more for four hours a day (6 × 4 × 365 ÷ 12 = 730 hours). That is 2,190 server-hours, exactly 3 × 730, so the cost is 3 × k × M. Metering wins while 3k is below 8, which means while k is below about 2.67. At k = 1.5 it comes to 4.5 × M against 8 × M.

The third workload has a better answer than either: rent the floor flat and meter only the peak. Two flat servers cost 2 × M, and the six peak servers run 730 metered hours, k × M. The total, (2 + k) × M, beats eight flat servers whenever k is below 6, and beats metering everything whenever k is above 1. At k = 1.5 it comes to 3.5 × M, under both the 4.5 × M of metering everything and the 8 × M of flat plans. That is the general shape of a sensible bill: the steady part on steady pricing, elasticity bought only for the part that moves.

Two cautions before you plug in real prices. Compare whole bills: add storage, addresses and traffic to the metered side, and check what the flat price includes. And the peak only works if your application runs as several copies behind a load balancer, which is one more line on the bill. A single database server cannot become eight for the evening.

Growing and shrinking: up, out and back

Up, to a bigger server, usually means a restart, whatever the name on the invoice. AWS says you must stop an instance before changing its type and should plan for the downtime; when it starts again it moves to new hardware.⁵ Unless it holds a fixed Elastic IP address, it also comes back with a new public IPv4 address.⁴ A bigger VPS or VDS plan is the same kind of change: more vCPUs, memory and disk for the same virtual machine, which usually has to restart to use them all. A dedicated server grows by having parts fitted, which means someone opening the machine, or by moving to a bigger machine, which means a migration you plan.

Out, to more servers, is where metered clouds are strongest. An AWS Auto Scaling group keeps a fleet between a minimum and a maximum size, and its scaling policies launch or terminate instances as demand rises and falls.⁶ That is NIST's rapid elasticity made concrete. It works for the parts of an application that can run as identical copies, such as web servers, API servers and queue workers, and not for the parts that cannot, such as a single primary database.

Back, giving capacity up, is the direction people forget when they compare prices. On a meter, charges for an instance stop as soon as it is shutting down or terminated, though a stopped instance's storage keeps billing.⁴ On a monthly plan you have paid for the month.

When the machine fails

Every one of these options runs, at any moment, on one physical machine. A cloud instance is not spread across a data centre; like a VPS, it is a process on a host. What differs is what the provider can do when that host has a problem.

Planned maintenance is the easy case for virtual machines, because a running guest can be moved. KVM's live migration copies the guest's memory to the new host while the guest keeps running, then copies again the pages written in the meantime, and stops the guest only for the final hand-over of its state. It needs the guest's disk image reachable from both hosts, on shared storage.¹⁵ Google's Compute Engine live-migrates most instances during host events by default.¹⁴

A sudden failure is different: a host that has lost power cannot hand over memory it no longer has. Google's documentation says a total hardware failure might prevent live migration; the instance crashes, and if automatic restart is on, as it is by default, Compute Engine restarts it, typically within three minutes and sometimes up to 5.5.¹⁴ AWS's automatic recovery, on the instance types that support it, tries to move an impaired instance to a different host. If that succeeds, the instance sees an unplanned reboot: what was in memory is gone and uptime starts again from zero. If it fails, the instance may keep running on the faulty host until someone steps in.¹¹ Data on local instance store disks is lost even on an ordinary stop.⁴

On a VPS or VDS the same physics apply, and one question decides a lot: where does your disk live? On network storage, the provider can boot your server on another host. On the failed host's own drives, your server waits for that machine to come back.

A dedicated server has no other host to restart on. A mirrored pair of disks survives one disk failing; a dead motherboard or power supply means waiting for the part, or restoring your backups onto another machine.

So none of the four makes one server highly available. Staying up through a hardware failure takes two servers on different machines and a way to move traffic between them, and surviving everything else takes backups. Server backups that actually restore covers that half.

Mistakes that cost money or uptime

• Multiplying an hourly price by 730 and stopping there. Add storage, addresses and traffic to the metered side and check what the flat price includes before you call either one cheaper.
• Reading "dedicated" as a whole machine. Dedicated cores and a dedicated server are different products. A plan with cores allocated to it still shares the machine's disks, memory bandwidth and network port.
• Moving an always-on server to a meter to save money. Metering saves you the hours you do not run, and an always-on server has none. If k is above 1, it costs more every month.
• Sizing a flat fleet for a four-hour peak. In the worked example the load used 72 of the 192 server-hours a day that the flat fleet paid for.
• Treating one cloud instance as highly available. It lives on one host. When the host fails, the best case is an automatic restart elsewhere with its memory gone. Two instances on different hosts are the minimum for staying up.
• Forgetting that a resize is a restart. Plan the window, and check whether the public address changes.
• Comparing vCPU counts across rows. Four vCPUs on shared cores and four cores allocated to you are not the same amount of processor. vCPU vs CPU core shows how to compare them.

Choosing by workload

Everything above fits on one table. Read it across a row for a trade-off, then answer the three questions in the drawing under it. The sections after the drawing take the questions in the same order.

When you need the hardware itself

Start with the reasons that come from the hardware: your own hypervisor, software licensed per socket or per core, hardware features a virtual machine cannot reach, or a rule that nobody else's code runs on the machine. Any one of them means a whole machine, whatever the rest of the workload looks like. If the load is steady, rent it by the month; if it comes and goes, clouds rent whole machines on a meter too.

Predictable or spiky

Next, ask whether the number of servers you need changes, and how predictably. A daily peak you can see coming is covered by a flat floor sized for the quiet hours plus metered capacity for the peak, as in the worked example. A spike you cannot predict, a launch or a sale or a mention somewhere large, is what elastic capacity is for: servers added when it arrives and given back afterwards. Work that exists for a few hours and then disappears, from a test environment to a data-processing run, belongs on a meter.

Steady or bursty

If the count stays the same, the server runs all month even when it is busy only part of the day, so for billing it is steady: a website, an API, a bot, a VPN, a game server with a regular crowd. For these the monthly row wins whenever k is above 1, and the last question is the processor. Bursty processor use, idle and then busy for a moment, is what shared cores are good at, so a VPS fits. Steady processor load, such as a busy database, a build runner or a game server's tick loop, is what a VDS is for.

When in doubt, start with the smallest option your answers point to and measure. Steal time that climbs whenever you are busy says shared cores are costing you; a load graph that sits flat all month says a meter will not pay. The server calculator sizes a plan from a workload, and the use cases work through common ones.