An IaaS provider rents you the raw materials - virtual machines, block storage, networks - and hands you everything above the hypervisor: the operating system, the patching, the runtime, the deploys, and the pager.
The search results for this are almost all vendor lists, ranked roughly by revenue. That is a fine answer to a question nobody asked. If you are reading a list of IaaS providers, you have already made a much larger decision - that you want to operate infrastructure - and it is worth checking whether that decision was deliberate.
Table of contents
- What IaaS actually includes, and what it quietly does not
- The three layers, and the only question that matters
- How to compare providers, if you do need one
- The honest cost comparison nobody runs
- A reasonable default
- How this fits the rest of the stack
- FAQ
What IaaS actually includes, and what it quietly does not
The model is straightforward. The provider owns the data centre, the hardware, the networking gear, and the hypervisor that slices physical machines into virtual ones. You provision an instance with a chosen amount of CPU, memory, and disk, and you get a machine with an IP address and an SSH key.
From that boundary up, it is yours. The operating system and its security updates. The web server. The language runtime and its version. The database, if you run your own. The TLS certificates and their renewal. The process supervisor that restarts your app when it dies. The log shipping. The backups, and more importantly the restore drill nobody runs until they need it.
That list is not an argument against IaaS. It is the actual product. The bill you see is for the virtual machine; the cost you pay is the machine plus the hours.
The three layers, and the only question that matters
IaaS, PaaS, and SaaS are usually taught as a taxonomy. They are more useful as a single sliding control: how much of the stack do you want to be responsible for?
- IaaS - you get a machine. Maximum control, maximum operational surface. You choose the kernel and you own the consequences.
- PaaS - you get a place to run an application. You push code, the platform builds it and runs it. You give up kernel-level control and get deploys, rollbacks, and scaling in exchange.
- SaaS - you get finished software. No infrastructure decisions at all, and no ability to change how it works.
The question is not which layer is better. It is which layer your problem actually lives at. Teams end up on IaaS for three legitimate reasons: a workload that needs specific hardware or kernel access, a compliance requirement that names the architecture, or genuine scale where the margin on managed services becomes a real number. Everyone else is usually there by default.
How to compare providers, if you do need one
Once you are certain the workload needs raw infrastructure, the comparison is less about the vendor’s size than about four things that will bite you later.
- Egress pricing. Compute is roughly commodity. Data leaving the network is where cloud bills go strange, and the per-gigabyte rate varies by more than an order of magnitude between providers. Model your actual traffic, not the free tier.
- Managed service depth. You are on IaaS, but you will still want a managed database, object storage, and a load balancer. A provider with a shallow managed catalogue means you run those yourself too.
- Region and latency. Where your users are, and whether the provider has a region near them. This is the one thing you cannot fix later with a config change.
- Exit cost. How much of your architecture is written in the provider’s proprietary services. A VM is portable. A pile of vendor-specific queues, functions, and IAM policies is not.
The hyperscalers win on breadth and lose on simplicity and egress. The mid-size providers win on predictable pricing and lose on the long tail of managed services. Neither is a mistake; they are different trades.
The honest cost comparison nobody runs
Put the two options on one page. On the IaaS side: the instance, the block storage, the snapshots, the load balancer, the egress, and an honest estimate of engineer-hours per month for patching, certificate renewal, monitoring, and the occasional 2am restart.
On the platform side: the plan, the managed database, the storage, and the bandwidth. Fewer lines, a higher unit price, and no hours column.
For a small team the hours column usually decides it, and it decides it by a wide margin, because those hours are not spread evenly. They arrive as an afternoon lost to a broken certificate renewal on the day you were supposed to ship a feature.
For a large team with a platform group, the calculus flips - at scale the managed-service margin is real money and there are people whose job is already this. Most teams reading a list of IaaS providers are not that team yet.
A reasonable default
Start one layer higher than you think you need, and drop down only when a specific requirement forces it. It is straightforward to move an application from a platform onto raw infrastructure when scale or compliance demands it. It is much harder to claw back the eighteen months a small team spent becoming accidental system administrators.
Keep the application portable while you do it. A service that builds from a repository and reads its configuration from environment variables runs anywhere. That portability is what makes the decision reversible, which is worth more than getting it right first time.
How this fits the rest of the stack
The IaaS-versus-platform decision is a spreadsheet exercise that most teams never actually do, which is why it gets made by inertia. The RunxBuild hosting calculator lays out the service, the database, the storage, and the bandwidth as separate line items so the platform side of that comparison is a number rather than a guess. RunxBuild deploys Node, Next.js, Python, Go, Ruby, Java, .NET, and Docker services from GitHub with build logs, rollback, and autoscaling, alongside managed MySQL and Postgres with backups and private networking.
Useful related references:
- S3-Compatible Storage: The Providers and When to Use Each
- Backup as a Service Providers: What to Look For, What to Skip, How to Choose
- Backup as a Service: The BaaS Providers, the Trade-Offs, and When to Use It
- Services on RunxBuild
FAQ
What are the main IaaS providers?
The hyperscalers - AWS, Microsoft Azure, Google Cloud, and in Asia Alibaba Cloud - plus a tier of focused providers such as DigitalOcean, Linode, Hetzner, OVHcloud, and Oracle Cloud Infrastructure. The hyperscalers offer far more managed services around the raw compute; the smaller providers generally offer simpler, more predictable pricing.
What is the difference between IaaS and PaaS?
IaaS gives you a virtual machine and you manage everything above the hypervisor - OS, patching, runtime, deploys. PaaS gives you a place to run an application: you push code and the platform builds, runs, scales, and rolls it back. IaaS is more control and more operational work; PaaS is less of both.
Is IaaS cheaper than a managed platform?
The instance is usually cheaper than the equivalent platform plan, and that is not the whole cost. Add block storage, snapshots, load balancing, egress, and the engineer-hours for patching, certificates, monitoring, and incident response. For small teams the hours normally dominate and reverse the comparison.
Do I need IaaS for a small application?
Rarely. Raw infrastructure earns its keep when you need kernel-level control, specific hardware, a compliance requirement that names the architecture, or scale where managed-service margins become significant. A typical web application with a database is better served one layer up.
What should I compare between IaaS providers?
Egress pricing above all - compute is close to commodity and data transfer is where bills surprise people. Then the depth of managed services you will lean on, region coverage near your users, and how much of your architecture would be locked to that vendor’s proprietary services if you wanted to leave.