IaaS, PaaS and SaaS Explained with Real Cloud Examples
A clear explanation of IaaS, PaaS and SaaS with real AWS, Google Cloud and Azure examples, a responsibility table and a practical way to choose.
IaaS, PaaS and SaaS are the three classic service models of cloud computing, and the difference between them comes down to one question: how much of the stack do you manage, and how much does the provider manage for you? This guide defines each model, shows real services from AWS, Google Cloud, Azure and developer clouds, and follows a single application through all three so the trade-offs are concrete.
The short definitions #
The widely cited definitions come from the US National Institute of Standards and Technology in NIST Special Publication 800-145. In everyday terms:
- IaaS (Infrastructure as a Service): you rent virtual machines, disks and networks. You install and run everything from the operating system up.
- PaaS (Platform as a Service): you hand over your application code, and the platform runs it. The provider manages servers, operating systems and runtimes.
- SaaS (Software as a Service): you use finished software through a browser or API. You manage your data and users, and nothing else.
Who manages what #
The clearest way to see the difference is to list the layers of a typical application and mark who is responsible for each one.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Data, users and access settings | You | You | You |
| Application code | You | You | Provider |
| Runtime and dependencies | You | Provider (you choose versions) | Provider |
| Operating system and patching | You | Provider | Provider |
| Scaling and capacity | You (with provider tools) | Mostly provider | Provider |
| Virtualization, hardware, data centers | Provider | Provider | Provider |
Notice the first row. In every model, your data, your user accounts and your access configuration remain your responsibility. This is the core of the shared responsibility model that all major providers publish: the provider secures the cloud, and you secure what you put in it.
IaaS in practice #
IaaS gives you the closest thing to your own hardware without owning any. You choose the machine size, the operating system, the network layout and the storage, and you are responsible for everything that runs on top.
Real examples
- Amazon EC2 with EBS volumes and a VPC on AWS.
- Compute Engine with Persistent Disk on Google Cloud.
- Azure Virtual Machines with managed disks and a virtual network.
- DigitalOcean Droplets, Hetzner Cloud servers, Linode instances and similar offerings from developer-focused clouds.
When IaaS is the right call
Choose IaaS when you need full control: specific kernel modules, unusual software, legacy applications that expect a normal server, or strict tuning of the operating system. It is also the natural landing zone for a “lift and shift” migration from on-premises servers. The cost is operational effort: patching, backups, monitoring, hardening and scaling are all your job.
PaaS in practice #
With PaaS you stop thinking about servers. You push code or a container, configure environment variables and scaling rules, and the platform handles the machines underneath.
Real examples
- AWS Elastic Beanstalk and AWS App Runner.
- Google App Engine and Cloud Run on Google Cloud.
- Azure App Service for web apps and APIs.
- DigitalOcean App Platform and Heroku.
- Managed databases such as Amazon RDS, Cloud SQL and Azure SQL Database, which apply the PaaS idea to databases: you get a database endpoint, not a server to maintain.
When PaaS is the right call
PaaS suits teams that want to ship features rather than run infrastructure: web applications, APIs, background workers and internal tools. The trade-offs are less control (you work within the platform’s supported runtimes and limits), a degree of lock-in to the platform’s configuration style, and pricing that can be higher per unit of compute than raw IaaS. For many small teams, the saved operations time more than pays for that.
SaaS in practice #
SaaS is software you simply use. There is nothing to deploy; you sign up, configure and start working.
Real examples
- Productivity suites such as Google Workspace and Microsoft 365.
- Business applications such as Salesforce for CRM.
- Developer-facing SaaS such as hosted source control, error tracking and transactional email APIs.
Your responsibilities shrink to configuration, data and identity: who has access, how strong their authentication is, what data you store and how long you keep it. Those responsibilities are still real. Misconfigured sharing settings in SaaS tools are a common source of data exposure.
The models in between: containers and serverless #
Modern cloud services do not always fit neatly into three boxes. Two categories sit between IaaS and PaaS and are worth naming.
Containers as a service
Managed Kubernetes services such as Amazon EKS, Google Kubernetes Engine and Azure Kubernetes Service run the control plane for you, while you still manage workloads, node configuration (unless you choose a fully managed mode) and cluster add-ons. They offer more control than PaaS and less operational work than running Kubernetes yourself on IaaS.
Functions as a service (serverless)
AWS Lambda, Cloud Run functions on Google Cloud and Azure Functions run individual functions in response to events, billed by invocations and execution time. They are often grouped with PaaS because you never manage servers. They work well for event-driven glue code, webhooks and scheduled jobs, and less well for long-running processes or workloads that need persistent connections.
One application, three ways #
Imagine a small company that needs a customer portal: a web app, a database and file uploads.
Built on IaaS
The team launches two virtual machines behind a load balancer, installs a web server and runtime, runs PostgreSQL on a third VM with a block storage volume, and configures nightly backups. They control every setting, and they also own every security patch, every disk that fills up and every 3 a.m. alert.
Built on PaaS
The team deploys the web app to a platform such as App Service, Cloud Run or App Platform, uses a managed PostgreSQL service and stores uploads in object storage. Scaling is a setting, operating system patching disappears, and backups for the database are handled by the service. The team gives up some tuning options and accepts the platform’s limits.
Bought as SaaS
If an existing customer portal product meets the need, the company subscribes, configures branding and user roles, and connects it to its CRM. Nothing is deployed. The trade-off is flexibility: features are whatever the vendor builds, and data lives in the vendor’s system under its terms.
How to choose for your own workload #
Work through these questions in order:
- Does a SaaS product already solve this well? If the problem is not your core business (email, CRM, chat), buying is usually cheaper than building.
- Can the application run within a PaaS platform’s supported runtimes and limits? If yes, start there. Fewer moving parts means fewer incidents.
- Do you have a hard requirement for control? Custom kernels, specific licensing, legacy software or strict compliance settings point to IaaS.
- Who will operate it? Be honest about skills and time. IaaS without someone responsible for patching and monitoring is a security risk.
- What will it cost at your expected scale? Compare total cost including people’s time, not only the hourly price of compute.
For help comparing providers once you know which model you need, see our framework for choosing a cloud provider and the discussion of hyperscalers versus developer clouds. If AWS is on your list, our AWS platform overview maps its main services onto these models.
Common misconceptions #
- “PaaS means no security work.” You still manage secrets, dependencies in your code, access control and data protection.
- “IaaS is always cheaper.” The compute may cost less per hour, but the operations time often outweighs the difference for small teams.
- “Serverless means no servers.” The servers exist; you just do not see or manage them.
- “SaaS data is backed up by the vendor, so I do not need to think about it.” Read the vendor’s terms. Retention, restore options and export formats vary widely.
Each major provider documents which of its services fall into which model and how shared responsibility applies. Good starting points are the AWS documentation, the Google Cloud documentation and Microsoft Learn for Azure.
Frequently asked questions #
What is the main difference between IaaS, PaaS and SaaS?
The difference is how much of the stack you manage. With IaaS you manage the operating system and everything above it. With PaaS you manage only your code and data. With SaaS you manage only your data, users and settings in finished software.
Is Kubernetes IaaS or PaaS?
Managed Kubernetes sits between the two and is often called containers as a service. The provider runs the control plane, while you manage workloads and, depending on the mode, the worker nodes.
Is AWS Lambda PaaS?
Lambda is usually described as functions as a service or serverless computing. It is often grouped with PaaS because you do not manage servers, but it is billed per invocation and execution time rather than for a running platform.
Can one company use IaaS, PaaS and SaaS at the same time?
Yes, and most do. A typical setup combines SaaS for email and productivity, PaaS for web applications and databases, and IaaS for workloads that need full control.
