IaaS vs PaaS vs SaaS: Where Each Cloud Provider Fits

Three service models, one official definition

The labels IaaS, PaaS and SaaS did not come from marketing. They were formalized in NIST Special Publication 800-145, a short document from the US National Institute of Standards and Technology that defines cloud computing, its essential characteristics and its three service models. Almost every provider's own terminology traces back to it, and the original publication is still worth ten minutes of reading.

In the NIST framing, the models differ by what the consumer controls. Under Infrastructure as a Service, the consumer provisions processing, storage and networks and runs arbitrary software, including operating systems, on top. Under Platform as a Service, the consumer deploys applications using languages and tools the provider supports but does not manage the underlying operating system or servers. Under Software as a Service, the consumer simply uses an application through a client and controls little beyond user-specific settings.

That control axis is the key to the whole topic. Everything else, including price shape, skill requirements and lock-in, follows from how much of the stack you are handed.

Who manages which layer

Read the table from bottom to top and the pattern is obvious: each step to the right hands another layer to the provider. Read it from the "you" cells and a second pattern appears. Data and access are always yours, whichever model you pick. That point is developed further in our article on the shared responsibility model.

Where IaaS lives: the virtual machine is the product

Every provider on the AllCloudShop marketplace sells IaaS in some form, because a virtual machine with a public IP is the common denominator of the industry. AWS calls it EC2, Azure calls it Virtual Machines, Google Cloud calls it Compute Engine, Oracle calls it Compute within OCI, and Alibaba Cloud calls it ECS.

Developer clouds are IaaS almost by definition. A DigitalOcean Droplet, a Hetzner Cloud server, a Vultr Cloud Compute instance, a Linode and a Contabo VPS are all the same thing wearing different badges: a Linux or Windows machine that you administer yourself over SSH or RDP. Block storage volumes, virtual networks, firewalls and load balancers round out the IaaS layer.

What IaaS gives you is freedom: any operating system, any runtime, any daemon. What it demands is administration: security patches, log rotation, disk space, process supervision and backups are all your job. If that sounds like a burden, keep reading; if it sounds like control, a DigitalOcean account or a similar developer-cloud account is a fine home for it.

Where PaaS lives: push code, get a URL

Heroku is the reference example of PaaS. You push a Git repository, a buildpack detects the language, a dyno runs the resulting slug, and the platform handles routing, TLS termination, log aggregation and process restarts. You never see an operating system. Our guide to Heroku dynos and buildpacks explains the mechanics, and the Heroku account listing covers what a supplied account provides.

The hyperscalers each have PaaS offerings sitting beside their IaaS: AWS Elastic Beanstalk and App Runner, Azure App Service, Google App Engine and Cloud Run. Developer clouds have followed. DigitalOcean App Platform deploys from a repository in much the same way Heroku does, and several providers offer managed databases that are PaaS for the data tier.

The PaaS bargain is speed of delivery in exchange for constraints. You must fit the platform's supported runtimes, its process model and its filesystem rules, which are often ephemeral. When the application fits, the operational savings are large. When it does not, teams find themselves fighting the platform and eventually moving down a layer.

Where SaaS lives, and why cloud providers sell it too

SaaS is the model most people use without naming it: email in a browser, a CRM, a project tracker, a video call. Nothing is provisioned; you sign in and use it. Several cloud providers are also large SaaS vendors. Microsoft 365 and Google Workspace sit next to Azure and Google Cloud under the same corporate roof, and a Workspace or Entra ID directory often becomes the identity source for the infrastructure account.

From an infrastructure buyer's point of view, SaaS matters for two reasons. First, many things you might self-host, such as monitoring, error tracking and source control, are available as SaaS and are usually the right first choice for a small team. Second, when you build a SaaS product yourself, you are choosing between IaaS and PaaS to run it, which is exactly the decision the closing sections address.

The lines have blurred

The 2011 NIST definitions predate several categories that now dominate cloud spending. Serverless functions such as AWS Lambda, Azure Functions and Google Cloud Functions are closer to PaaS than IaaS, yet they are billed per invocation rather than per running process. Managed Kubernetes (EKS, AKS, GKE, DigitalOcean Kubernetes, Civo) hands you a control plane while leaving worker nodes and workloads to you: half IaaS, half PaaS.

Managed databases blur things further. Amazon RDS, Azure Database for PostgreSQL and DigitalOcean Managed Databases give you a PostgreSQL endpoint while hiding the operating system, which is PaaS behavior applied to a component rather than an application. Our comparison of managed versus self-hosted databases works through that trade-off.

The useful mental move is to stop asking "which model is this provider?" and start asking "for each component of my system, which layer do I want to own?" A single application might run on managed Kubernetes, talk to a managed database, send email through a SaaS API and store files in object storage, mixing all three models at once.

Choosing a layer for a real project

Three questions settle most cases. How much operational expertise does the team have, and does it want to spend it on servers? How unusual is the runtime (a standard Node.js or Python web app fits PaaS; a custom kernel module does not)? And how price-sensitive is the workload at scale, given that PaaS convenience is typically charged as a premium over raw compute?

Small teams shipping standard web applications lean PaaS and move down only when a constraint bites. Teams with sysadmin skills, unusual software or steady high utilization lean IaaS from the start. The Heroku versus AWS comparison is a concrete example of the two philosophies side by side, and serverless versus VPS for side projects applies the same reasoning to hobby-scale work.

Key takeaways

• IaaS, PaaS and SaaS are defined by how much of the stack you control, per NIST SP 800-145.
• Every provider on the marketplace sells IaaS; a virtual machine is the industry's common unit.
• PaaS (Heroku, App Platform, App Service, App Engine) trades constraints for operational simplicity.
• Data, access and application configuration remain your responsibility in every model.
• Serverless, managed Kubernetes and managed databases sit between the classic layers; pick a layer per component, not per project.