IaaS vs PaaS vs SaaS: the cloud service models explained

IaaS: you rent the building blocks

Infrastructure as a Service provides the fundamental components of computing — virtual machines, storage volumes and networking — on demand. The provider owns and operates the physical data centres, the hardware and the virtualisation layer; you take over from the operating system upward. That means you choose and patch the OS, install your runtime and software, configure the middleware, and design how the pieces connect.

Amazon EC2 is the classic example: you launch a virtual server, connect to it, and administer it much as you would a machine in your own office — except that it was created in moments and can be deleted just as fast. IaaS offers the most control of the three models, and with that control comes the most operational responsibility. It suits teams that need to configure their environment precisely, run unusual software, or migrate existing systems to the cloud with minimal change.

PaaS: you bring the application

Platform as a Service moves the boundary up the stack. The provider manages not only the infrastructure but also the operating systems, runtimes and much of the plumbing an application needs — patching, capacity, load balancing, recovery. You supply your application code and your data; the platform handles running them.

AWS Elastic Beanstalk illustrates the idea: you upload an application and the service provisions and manages the environment it runs in. Managed database services fit the same pattern — you use the database engine while the provider handles the servers underneath, the patching and the backups. The trade is clear: you give up fine-grained control over the environment and gain freedom from operating it, which for many teams is exactly the right exchange, because their value lies in the application, not the infrastructure beneath it.

SaaS: you just use the software

Software as a Service is the model most people already use daily without naming it. The provider runs everything — infrastructure, platform and the application itself — and you consume the finished product, usually through a browser or app, typically paying per user or via subscription. Web-based email is SaaS; so are online CRM systems, document suites and video-conferencing tools.

With SaaS, your responsibilities shrink to your own data, your users and how you configure the product. There is nothing to patch and no capacity to plan, which is precisely the appeal. The limit is flexibility: you can configure a SaaS product, but you cannot rebuild it — if the software does not fit how you work, your options are to adapt or to choose a different product.

The responsibility shift, side by side

A popular analogy compares the models to ways of getting pizza — make it at home, take a ready-made base, order delivery, or eat at a restaurant — with each option shifting more of the work to someone else. The analogy is memorable, but the definitions above matter more: what shifts between the models is precisely who manages each layer of the technology stack.

• IaaS — provider manages: physical data centres, hardware, virtualisation. You manage: operating system, runtime, application, data. Example: Amazon EC2.
• PaaS — provider manages: everything in IaaS plus the operating system and runtime. You manage: application and data. Examples: AWS Elastic Beanstalk, managed databases.
• SaaS — provider manages: the entire stack including the application. You manage: your data, users and configuration. Examples: web-based email, online CRM tools.

Where serverless fits, and how to choose

Serverless computing — running code without provisioning or managing any servers, as with AWS Lambda — pushes the PaaS idea to its logical end: you supply individual functions, and the provider handles absolutely everything about running them, scaling them and billing only for actual execution. Some describe it as its own model; most usefully it sits at the far convenience end of the same spectrum, beyond classic PaaS. Our separate explainer on serverless computing covers it in depth.

Choosing between the models is a question of where you want to spend effort. Take IaaS when you need control of the environment — custom configurations, specific software, lifted-and-shifted legacy systems. Take PaaS when your differentiation lives in the application and the infrastructure is undifferentiated toil. Take SaaS when the problem is already well solved and building anything yourself would be reinventing a commodity. Real organisations use all three at once, which is why understanding the boundary between them — rather than picking a favourite — is the actual skill.

How the service models appear on the exam

The service models are foundational certification material in the most literal sense. The AWS Certified Cloud Practitioner exam expects you to define IaaS, PaaS and SaaS, recognise which model a described service belongs to, and — crucially — understand how responsibility shifts between customer and provider as you move along the spectrum. That last idea feeds directly into the shared responsibility model, one of the most heavily tested concepts on the exam.

At associate level the vocabulary stops being tested directly and starts being assumed: Solutions Architect scenarios routinely hinge on choosing between a self-managed component and its managed equivalent, which is the IaaS-versus-PaaS decision wearing real service names. Learn the models as a way of reasoning about responsibility, not as three definitions to memorise, and both exams become easier.