What is Infrastructure-as-a-Service (IaaS)?

IaaS is a cloud model that rents fundamental computing resources — virtual machines, storage, networking — on demand, billed as you go. The NIST definition draws the boundary precisely: the provider controls the physical infrastructure; you control operating systems, storage, and deployed applications. It is the bottom rung of the cloud ladder — the one that replaces buying servers with renting them.

Key takeaways

What using IaaS looks like

The signature experience is a machine in minutes — followed by everything a machine has always needed:

# Minute one: rent the machine
$ cloud compute create --size medium --image ubuntu-24.04
   ✓ vm-7f3a running — 203.0.113.40

# Minute two onward: everything is still your job
$ ssh [email protected]
$ apt update && apt upgrade          # patching: yours
$ apt install nginx postgresql       # stack: yours
$ ufw allow 443 && configure-tls…    # security: yours
$ crontab -e                         # backups, rotation, monitoring: yours

That trade — hardware in minutes, operations forever — is the whole model. For contrast, here is the same “get a backend running” goal at the top of the ladder, where the infrastructure never surfaces at all:

// JavaScript / Node.js — Back4app JS SDK
const note = new Parse.Object('Note');
note.set('text', 'Shipped without touching a VM');
await note.save(); // no instance sized, no OS patched, no firewall rules

// Flutter / Dart — Back4app Flutter SDK
final note = ParseObject('Note')
  ..set('text', 'Shipped without touching a VM');
await note.save(); // no instance sized, no OS patched

// iOS / Swift — Back4app Swift SDK
var note = Note()
note.text = "Shipped without touching a VM"
note.save { result in
  if case .success = result { print("saved — zero infrastructure managed") }
}

// Android / Kotlin — Back4app Android SDK
val note = ParseObject("Note").apply {
  put("text", "Shipped without touching a VM")
}
note.saveInBackground { e ->
  if (e == null) Log.d("Note", "saved — zero infrastructure managed")
}

Who manages what

This split is also the security model: the provider secures the cloud, you secure everything in it. Misconfiguration on the customer side — open storage buckets, permissive firewall rules, unpatched systems — is the leading cause of cloud breaches, which is why the “you run” box deserves more respect than it usually gets.

IaaS vs. PaaS vs. BaaS vs. on-premises

One clarification that recurs in every “IaaS vs.” discussion: serverless models aren’t a fourth column of the same kind — they abstract the unit of compute (per-invocation) rather than the layer of management, which is why a serverless platform can itself run on IaaS underneath.

Common use cases

• Lift-and-shift migrations. Existing server applications move to rented VMs mostly unchanged — same stack, no more hardware refresh cycles.
• Custom and legacy stacks. Unusual runtimes, licensed software, or OS-level tuning that managed platforms won’t allow.
• Compliance-driven control. Regimes that require knowing and configuring exactly what runs beneath the application.
• High-performance and specialized workloads. GPU fleets, large-scale data processing, and anything with hardware-shaped requirements.
• Disaster recovery and burst capacity. Standby environments and traffic-spike headroom that would be ruinous to own as idle hardware.

Should you build on IaaS? A decision matrix

The pattern worth internalizing: IaaS is rarely wrong for moving existing systems, and rarely right for starting standard ones — a new app backend assembled by hand on VMs is weeks of work that higher rungs deliver before lunch.

Limitations and trade-offs

• Operations remain yours. Patching, hardening, scaling, backups, monitoring — the runbook survives intact; only the hardware under it changed.
• Bill shock is a skill issue you inherit. Idle instances, oversized VMs, and forgotten storage bill around the clock; cost management becomes an ongoing discipline.
• Egress is the exit toll. Data flows in free and out at a price — a mechanism that quietly compounds into cloud vendor lock-in as data accumulates.
• Security misconfiguration is the top failure mode. The provider’s half of shared responsibility is excellent; breaches overwhelmingly happen in the customer’s half.
• The skills tax. Running infrastructure well requires people who run infrastructure well — a hiring requirement the pay-as-you-go pricing page doesn’t mention.

Where Back4app stands relative to IaaS

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Relative to IaaS, it is the opposite end of the trade: no OS access, no infrastructure control — and no runbook, because the entire “you run” box from the diagram above is the platform’s job. Teams that need raw infrastructure for one specialized workload can run it beside a BaaS backend; teams building standard app backends can skip the bottom rung entirely. And because the stack is open source, descending the ladder later — self-hosting the platform on IaaS you control — remains a real option, not a rewrite.