IaaS, PaaS, and SaaS in plain terms: what the provider runs, what you run, examples of each, and how to choose the model that fits your project.
GeneralBy Samuel Malkasian | FounderJuly 10, 202611 min read
The difference between IaaS vs PaaS vs SaaS comes down to one question: how much of the stack do you want to manage yourself? With IaaS (Infrastructure as a Service) you rent raw compute, like a server, and you run everything on top of it. With PaaS (Platform as a Service) the provider runs the operating system and the plumbing, and you just deploy your code. With SaaS (Software as a Service) the provider runs the whole application, and you log in and use it. As you move from IaaS to PaaS to SaaS, the provider does more and you do less.
These are the three cloud service models defined by the U.S. National Institute of Standards and Technology, and almost every cloud product you have ever used is one of them. This guide defines each one with an everyday example, shows what the provider manages versus what you manage, places a VPS or cloud instance on the map (it is IaaS), and gives you a short checklist for picking the model that fits a given project. If you are new to the broader topic, start with what cloud hosting is, then come back here.
What does each cloud service model mean?
The three models are layers of a stack, sliced by who manages what. IaaS gives you raw infrastructure (servers, storage, networking) and you manage everything above it. PaaS gives you a ready-made platform to deploy code onto, and the provider manages the operating system and below. SaaS gives you a finished application you simply use. Each step up hands more responsibility to the provider.
A meal makes the split easy to picture. IaaS is buying groceries: you get the raw ingredients and a kitchen, and the cooking is on you. PaaS is a meal kit: the shopping and prep are done, you follow the steps and assemble the dish. SaaS is ordering at a restaurant: you pick from the menu and eat, and someone else handles everything in the back. The food gets to the table either way. What changes is how much of the work you do, and how much control you keep over the result.
That control-versus-effort tradeoff is the whole story. More control means more flexibility and more work. Less control means less flexibility and far less work. None of the three is better in the abstract. The right one depends on what you are building and how much of the machinery you want to touch.
What is IaaS and where does a VPS fit?
IaaS, or Infrastructure as a Service, rents you the building blocks of computing: virtual servers, storage, and networking. You provision a server and then you install and manage the operating system, the runtime, your application, and your data on top of it. A VPS or a cloud compute instance is the everyday face of IaaS. It is the most hands-on of the three models, and the most flexible.
NIST describes IaaS as provisioning "processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications." Crucially, the consumer "does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications" (). That single sentence is the dividing line: with IaaS, the operating system and everything above it is yours.
Written by
Samuel Malkasian | Founder
Samuel Malkasian is the founder and lead cloud architect at Carpathian, where he designed the platform's core architecture along with a range of client enterprise systems and open-source tools for AI workflows and integration. He serves as a Cyber Warfare Officer in the U.S. Army and has a background in machine learning, data science, and LLM architecture. He is currently focused on building AI infrastructure that is secure, efficient, and sustainable.
Examples of IaaS are the things people picture when they say "the cloud" in the literal sense:
A cloud VPS, where you get root access to a Linux server and install whatever you want.
Cloud compute instances such as AWS EC2, Google Compute Engine, or Azure Virtual Machines.
Cloud block and object storage, and the virtual networks that connect your servers.
What you manage on IaaS is almost everything: OS patching, security hardening, the web server, the database, backups, and scaling. What the provider manages is the physical hardware, the hypervisor, the data center, and the network underneath. You get full control of the software stack, and you accept the work that comes with it. If you want to go deeper on this specific layer, our guide to what a VPS is covers it in detail.
What is PaaS and who is it for?
PaaS, or Platform as a Service, hands you a managed environment to run your code without touching the server underneath. You push your application, and the provider runs the operating system, the language runtime, scaling, and patching. You keep control of your app and its configuration, and you give up control of the machine it runs on. It is the middle ground: less freedom than IaaS, far less maintenance.
NIST puts the boundary plainly. On PaaS, the consumer "does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment" (NIST SP 800-145). You worry about your code. The platform worries about the box it runs on.
Familiar PaaS products include:
App platforms like Heroku, Render, Google App Engine, and Azure App Service, where you deploy a repo and the platform runs it.
Managed database services, where the provider handles the database engine, backups, and failover.
Serverless and function platforms such as AWS Lambda, which take the idea further and run individual functions on demand.
PaaS suits teams who want to ship an application without becoming part-time system administrators. The standard advice in developer communities is that a managed platform is the sensible default for most web apps until you hit a specific reason to need more control (BMC). The honest tradeoff is lock-in: because PaaS leans on a provider's proprietary tooling and APIs, moving to a different platform later can be more work than moving a plain server would be. You are trading some portability for a lot less operational overhead.
What is SaaS and when is it the right choice?
SaaS, or Software as a Service, is a finished application you access over the internet, usually in a browser, with nothing to install or maintain. The provider runs the whole stack: infrastructure, platform, and the software itself. You log in, configure your settings, and use it. It is the least hands-on model and the one most people interact with every day without thinking of it as "cloud."
NIST is blunt about how little you manage here. With SaaS the consumer "does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings" (NIST SP 800-145). Your control ends at preferences and user accounts.
You already use a lot of SaaS:
Email and productivity suites like Gmail, Google Workspace, and Microsoft 365.
Collaboration tools like Slack, Notion, and Zoom.
Business software like Salesforce, Shopify, and QuickBooks Online.
SaaS is the largest slice of cloud spending by a wide margin. Gartner forecast cloud application services, the SaaS category, to reach roughly $299 billion in 2025, the biggest single segment of public cloud spend (Gartner). SaaS is the right choice when a solved problem already exists as a product and you have no reason to build it. You do not stand up your own email server to send a few hundred messages a month. The limitation is the flip side of the convenience: you adapt to the software's way of doing things, and your data and workflow live inside someone else's product.
What does the provider manage versus what you manage?
The clean way to remember the three models is by where the line of responsibility sits in the stack. From the bottom up, the layers are: physical hardware, virtualization, networking, the operating system, the runtime and middleware, the application, and finally your data and configuration. Each model draws the line at a different layer, and everything below the line is the provider's job.
Here is where the line falls in each model:
IaaS: the provider manages the hardware, virtualization, and network. You manage the operating system, runtime, application, and data. The line sits just below the operating system.
PaaS: the provider also takes the operating system and runtime. You manage only the application and its configuration. The line sits just below your code.
SaaS: the provider manages the entire stack including the application. You manage only your settings and user accounts. The line sits at the very top.
One point that catches people out: security is shared in every model, but the split moves with the line. This is the shared responsibility model. On IaaS you are responsible for patching the operating system and locking down your server. On SaaS the provider handles nearly all of it, and your job shrinks to managing access and not misconfiguring the settings you do control. The further up you go, the less security work is yours, but it never drops to zero.
How do you choose between IaaS, PaaS, and SaaS?
Start from what you are trying to do, not from the technology. If a product already solves your problem, use SaaS. If you are building an application and want to focus on code, use PaaS. If you need full control of the environment, or you are running something the higher layers will not allow, use IaaS. Most projects mix all three at once.
Walk these questions in order and you will land on the right model:
Is there already a product that does this? If a tool like email, CRM, or accounting software solves it, buy the SaaS and move on. Building your own copy of a solved problem is rarely worth it.
Are you building a custom application? If yes, default to PaaS. A managed platform lets a small team deploy and scale without running servers, which is why it is the common starting recommendation for standard web apps (BMC).
Do you need control the platform will not give you? If you need a specific operating system, custom networking, particular software the platform blocks, strict compliance, or predictable low-level performance, drop to IaaS and run it on a VPS or cloud instance.
Are you worried about lock-in or cost at scale? Proprietary PaaS features are convenient but harder to leave, and at high volume, serverless and managed platforms can cost more than running your own servers. IaaS is the most portable of the three.
A few honest caveats are worth stating. You do not have to pick one and commit forever. A typical setup runs a web app on PaaS, stores files in IaaS object storage, and pays for SaaS tools like email and analytics alongside it. And you can over-buy control just as easily as you can under-buy it. If a managed platform would run your app fine, reaching for a bare server you then have to patch and secure yourself is effort you did not need to spend.
It is worth naming where managed cloud hosting fits, since it sits between these labels. A managed cloud platform (the kind we run at Carpathian) gives you IaaS-style control of a server while the provider handles the heavier infrastructure work for you. That is a fit when you want root access and predictable performance without standing up a data center, and it is overkill if a simple SaaS tool already does the job. Pick the layer that matches the work, not the one that sounds the most capable.
Putting it together
The three cloud service models are not a hierarchy where higher is better. They are a slider for how much of the machinery you want to own. SaaS for solved problems, PaaS for shipping your own application without running servers, IaaS when you need control of the environment down to the operating system. A VPS or cloud instance lives in that last bucket, and it is the right tool when flexibility matters more than convenience.
The best model for any project is the one that leaves you managing only what you need to manage, and nothing more. Match the layer to the work, keep an eye on lock-in and scaling cost, and remember that most systems use all three together. If you want to go one level deeper on where servers fit, read what a VPS is and how to pick hosting for a small site next.
IaaS vs PaaS vs SaaS, Explained Simply | Carpathian
