IaaS is the model where a provider runs the hardware, the network, and the hypervisor, and everything from the operating system upward becomes your responsibility - which is a much longer list than the phrase virtual machine suggests.
Every explanation of this model describes what you get. Fewer describe what you take on, and that side of the ledger is where the decision actually gets made. The instance appears on the invoice; the rest appears in your calendar.
Table of contents
- What you get, and where the line sits
- The list you inherit
- When that trade is clearly right
- If you are on IaaS, take the managed services anyway
- Making the decision reversible
- How this fits the rest of the stack
- FAQ
What you get, and where the line sits
The provider owns the data centre, the physical servers, the storage arrays, the network fabric, and the hypervisor that partitions machines into instances. You provision an instance with chosen CPU, memory, and disk, and receive an operating system with an IP address and a key.
The line is the hypervisor. Below it, the provider’s problem. Above it, yours, in full.
Around that core, IaaS providers also sell block storage volumes, object storage, virtual networks and firewall rules, load balancers, and snapshots. Those are genuinely useful and generally worth taking - they remove real work without moving the line.
The list you inherit
Written out plainly, because it is rarely written out at all.
- Operating system updates, including the security ones, on a schedule, forever.
- The web server and reverse proxy, configured and kept configured.
- The language runtime and its version, including the major upgrade nobody wants to schedule.
- TLS certificates, issued and renewed, with the renewal actually working rather than having silently stopped in March.
- Process supervision, so a crashed application restarts instead of staying down until someone notices.
- Log rotation, because a disk filled with logs is a genuinely common outage and an embarrassing one.
- Monitoring and alerting, configured to tell you before users do.
- Backups and a tested restore, for the database and anything else stateful.
- The deploy mechanism - whatever gets new code onto the machine safely, and back off it when the release is bad.
- Firewall rules and SSH access, reviewed when people join and leave.
None of it is difficult in isolation. All of it is permanent, and it arrives as interruptions rather than as scheduled work.
When that trade is clearly right
There are good reasons to take on the list, and they are specific rather than general.
You need kernel access, a specific kernel module, or a system-level dependency that cannot live in a container. You are running something that is not a web application - a game server, a mail server, a VPN endpoint, a build agent, a database with unusual extensions. You have compliance requirements that specify the architecture. You are at a scale where managed-service margins are a material number and you already employ people whose job this is. Or you need to run several unrelated things on one machine for cost reasons, which platforms deliberately make awkward.
Every one of those is a requirement pointing downward. What is not on the list is application size, traffic volume, or seriousness. Those are not reasons.
If you are on IaaS, take the managed services anyway
The most common expensive mistake in this model is treating it as all-or-nothing and running everything yourself because you are already on a VM.
The database is the important one. Running your own Postgres or MySQL on the application server saves a modest monthly sum and costs you version upgrades, connection tuning, replication if you want it, monitoring that fires before the disk is full rather than after, and backups you have to test. It also means the database and the application compete for the same memory and I/O, which is a recurring performance problem that looks mysterious from the outside.
The same applies to object storage, load balancing, and log aggregation. Take the managed version of each. Being on IaaS is a decision about the compute layer, not a vow to operate every component personally.
Making the decision reversible
Whichever way you go, the properties that keep the option open are the same three, and they are free at the beginning.
- Configuration in environment variables, never in files edited on the server. This is also what stops production drifting from staging in ways nobody can reproduce.
- No state on local disk. Files in object storage, sessions in a shared store, nothing important on the instance. A machine you can destroy and recreate is a machine that cannot hold you hostage.
- A standard managed database, dumped and restored with ordinary tools rather than tied to a proprietary API.
An application meeting those three conditions moves between a VM and a platform in an afternoon. That reversibility is worth considerably more than getting the layer choice right first time, because it means being wrong is cheap.
How this fits the rest of the stack
The comparison worth running is the instance price plus the hours against a platform plan, and only one of those two sides is easy to look up. The RunxBuild hosting calculator prices the service, the database, the storage, and the bandwidth so the platform side is exact and the comparison is honest. RunxBuild deploys Node, Next.js, Python, Go, Ruby, Java, .NET, and Docker services from GitHub with certificates, build logs, runtime logs, rollback, and autoscaling handled, alongside managed MySQL and Postgres with backups and private networking.
Useful related references:
- Cloud Managed Firewall: What It Does, What It Doesn’t, When to Use One
- What Is a Cloud Engineer, Really? (Not the LinkedIn Version)
- Rapid Elasticity: Scaling Out and In Automatically in the Cloud
- Services on RunxBuild
FAQ
What is IaaS cloud?
A model where the provider runs the data centre, hardware, network, and hypervisor, and you rent virtual machines. Everything above the hypervisor - operating system, runtime, web server, certificates, deploys, monitoring, backups - is your responsibility. Block storage, object storage, load balancers, and firewalls are usually available alongside.
What do I have to maintain on an IaaS server?
OS security updates, the web server and reverse proxy, the language runtime and its upgrades, TLS certificate renewal, process supervision, log rotation, monitoring and alerting, backups with a tested restore, the deploy mechanism, and firewall and SSH access. None is hard alone; all are permanent.
When should I choose IaaS over a managed platform?
When you need kernel access or a system-level dependency, when the workload is not a web application, when compliance specifies the architecture, when scale makes managed-service margins material and you already employ infrastructure engineers, or when you must run several unrelated things on one machine.
Should I run my own database on an IaaS server?
Generally not. It saves a modest monthly sum and costs you version upgrades, connection tuning, monitoring, and backups you must test yourself, while the database competes with the application for memory and I/O. Being on IaaS is a compute decision, not a commitment to operate everything.
How do I keep the option to move off IaaS later?
Keep configuration in environment variables rather than files edited on the server, keep no state on local disk so the machine can be destroyed and recreated, and use a standard managed database with a portable dump format. An application meeting those three conditions moves in an afternoon.