IaaS, PaaS, SaaS — Where the Line Actually Sits

You know the acronyms. The question is whether you're using them to make decisions or just to fill slides.

The Control-Convenience Axis Is the Only Thing That Matters

Start with what all three models are actually trading: control for convenience. That trade is continuous, not categorical, and where you sit on it determines what you own when something goes wrong and what you can tune when something needs to change.

IaaS — Infrastructure as a Service — hands you a virtual machine, a network interface, a block device. The provider manages physical hardware, hypervisor, and the data centre fabric underneath. You manage the operating system, the runtime, the middleware, the application, and every configuration decision above the hypervisor boundary. You get maximum control and maximum responsibility. A misconfigured kernel parameter is your problem. So is patching. So is the 3 a.m. call when disk fills.

PaaS — Platform as a Service — takes the OS and runtime off your hands. You bring code and configuration; the platform handles everything below that: language runtimes, web servers, scaling triggers, sometimes even deployment pipelines. Google App Engine, Heroku, Azure App Service — these are all PaaS shapes. You lose the ability to SSH into the underlying host, which matters less than developers imagine until the day they need to reproduce a production environment locally or diagnose a weird network behaviour that only happens inside the managed runtime.

SaaS — Software as a Service — removes the application layer from your responsibilities too. You configure and consume; the provider builds, operates, and updates the software. Salesforce, Workday, GitHub — the user organisation controls data and workflows, nothing below. The trade is nearly total: enormous operational convenience, almost no technical leverage. If the vendor's roadmap doesn't include a feature you need, your negotiating position is usually a feature request form.

Where the Line Actually Blurs

The clean three-tier picture works for teaching. It breaks down in practice because providers have strong commercial incentives to move customers up the stack. A managed database service sits between IaaS and PaaS: you don't manage the OS or the database engine binary, but you do configure schemas, indices, query plans, and replication topology. AWS RDS, Cloud SQL, Azure Database for PostgreSQL — these are not quite PaaS, because you still make consequential technical decisions; they're not quite IaaS, because you've ceded the engine. The industry sometimes calls this DBaaS or simply "managed service," but the label is less important than recognising that the managed database bargain has real terms: you give up tuning access and get operational simplicity in return.

Kubernetes clusters illustrate the same blur from the infrastructure side. A self-managed cluster on IaaS VMs is clearly IaaS. A managed control plane with managed node pools — GKE Autopilot, EKS with Fargate, AKS — starts absorbing what were PaaS responsibilities. Serverless functions are further still: no node to manage, often no runtime to configure beyond a language version and an environment variable. Calling Lambda "IaaS" because it runs on servers is technically coherent and practically useless.

The useful reframe is to ask, for any specific service: where does my operational boundary begin? Not "which acronym applies" but "what breaks on my watch, and what can I change?" That boundary is the actual line. It sits in a different place for every managed service, and it shifts as providers add features — sometimes expanding your control, more often contracting it in exchange for something you didn't ask for.

Why Imprecise Usage Costs You

Kubernetes clusters illustrate the same blur from the infrastructure side.

Using the acronyms loosely creates two failure modes. The first is architectural: teams that say "we're going PaaS" without defining what that means end up with some services at IaaS depth (because someone wanted control), some at SaaS depth (because a managed service was convenient), and no coherent answer to where their operational boundary sits. Shared responsibility becomes confused, not because the model is hard to understand but because nobody mapped it to the actual services in use.

The second failure mode is contractual and cost-related. SaaS pricing is almost never resource-proportional — you pay per seat, per document, per API call, in ways that don't track your usage patterns. IaaS is resource-proportional and therefore predictable if you model it. PaaS and managed services sit somewhere between: you might pay per request, per connection, per provisioned tier. Treating a managed service as if it were raw IaaS and expecting to right-size it the same way leads to billing surprises of a specific and avoidable kind.

The three-letter abbreviations are fine shorthand. They become a problem when they substitute for asking the concrete question: on this specific service, in this specific failure scenario, what does my team own? Answer that and you've done more useful architecture than any slide deck of stacked boxes will give you.