Cloud Service Models
IaaS, PaaS, and SaaS one by one, then the comparison that tells them apart.
Every cloud provider packages what it sells into one of 3 service models, and the difference between them is not a technicality. It decides how much of the stack you manage yourself, how fast you can ship, and how much control you keep. This topic covers Infrastructure as a Service, Platform as a Service, and Software as a Service individually, then puts all 3 side by side so you can tell them apart in a scenario instead of only naming them in isolation.
What This Topic Covers
- Infrastructure as a Service (IaaS): raw compute, storage, and networking, with the operating system and everything above it left to you, delivered by products like AWS EC2, Azure Virtual Machines, and Google Compute Engine
- Platform as a Service (PaaS): a platform that runs your code without asking you to manage servers or an operating system, delivered by products like AWS Elastic Beanstalk, Heroku, and Google App Engine
- Software as a Service (SaaS): a complete application run entirely by the provider, from Gmail to Salesforce to Slack, and the multi-tenant architecture that makes it affordable
- A full side-by-side comparison of all 3 models, the keyword cues that identify each one in a scenario, and why moving up the stack is a tradeoff rather than a straightforward upgrade
Why It Matters
Nearly every decision in the rest of this domain assumes you can place a service into one of these 3 models. Regions, compute, storage, and databases, covered in the next topic, are all building blocks that show up inside IaaS, PaaS, and SaaS products alike, and knowing which model you are working in tells you what you are actually responsible for.
Exam questions in this space rarely ask for a definition. They describe a constraint, root access to a kernel, a team with no developers, a requirement to just ship code, and expect you to know which model that constraint points to. Get comfortable with that pattern here, and the shared responsibility model in the Security and Reliability domain will feel like an extension of something you already know, not a new idea.