Cloud Service Models (IaaS, PaaS, SaaS) Explained for AWS, Azure, and CompTIA

A cloud service model defines the division of responsibility between the cloud provider and the customer. At one end of the spectrum, on-premises computing puts every layer — hardware, OS, platform, application, and data — entirely under your control. At the other end, SaaS hands almost everything to the provider. IaaS and PaaS sit between those extremes.

The three service models exist because different use cases need different trade-offs. A startup building a new web app doesn't want to manage servers. An enterprise migrating a legacy application might need to control every detail of the OS. A company using payroll software just wants the functionality without any infrastructure concern. IaaS, PaaS, and SaaS map directly to these scenarios.

Understanding service models is foundational for cloud certifications because every other topic — shared responsibility, AWS IAM, Azure resource management — assumes you know where provider responsibility ends and customer responsibility begins.

IaaS gives you raw compute, storage, and networking resources that you manage yourself. The cloud provider owns and operates the physical hardware, the data center, the virtualization layer, and the hypervisor. You get virtual machines, storage volumes, and network configurations — and you are responsible for everything above that layer: the operating system, middleware, runtime, applications, and data.

Amazon EC2 is the defining IaaS example on AWS. When you launch an EC2 instance, AWS provides the server hardware and hypervisor. You choose the operating system, configure it, patch it, install your software stack, and manage it on an ongoing basis. You have full root access and full operational responsibility. Other AWS IaaS services include Amazon VPC for networking, Amazon EBS for block storage, and Amazon EFS for file storage.

Azure Virtual Machines is the Azure equivalent. When you deploy a VM, Microsoft provides the physical host and virtualization layer. You select the OS image, configure the machine, manage updates, and install your workloads. Azure also places the VM inside a Virtual Network (VNet) that you configure, giving you control over subnets, NSGs, and routing.

IaaS is the right choice when you need full control over the environment, are lifting and shifting existing software that cannot be refactored for cloud-native services, or have specific OS or kernel requirements. The trade-off is operational overhead: your team must handle OS patching, security hardening, capacity planning, and performance tuning. The cloud does not manage your VMs for you.

PaaS removes the infrastructure and platform management burden so you can focus exclusively on your application code and data. The cloud provider manages the OS, the runtime environment, middleware, and all patching and scaling. You deploy code, configure the application, and manage data. You cannot SSH into the underlying server — and you don't need to.

AWS Elastic Beanstalk is a PaaS offering. You upload your application code, choose your runtime (Node.js, Python, Java, Ruby, etc.), and Beanstalk handles deployment, load balancing, auto-scaling, and health monitoring. Amazon RDS is another PaaS example: AWS manages the database engine, OS, storage, patching, and backups. You manage the database schema, queries, connections, and data.

Azure App Service is the primary Azure PaaS for web applications. You deploy code in your chosen language and runtime, and Microsoft manages everything underneath — the OS, the runtime version, patching, availability, and scaling. Azure SQL Database is PaaS for relational workloads: Microsoft patches the SQL Server engine and manages storage; you manage your database schema and data.

PaaS reduces time-to-market significantly because you skip infrastructure provisioning and ongoing maintenance. The trade-off is reduced flexibility. You work within the supported runtimes and configurations the platform offers. If your application has unusual dependencies or requires custom kernel modules, PaaS may not fit.

SaaS is software you subscribe to and use without managing any infrastructure, platform, or application layer. The provider manages everything from physical hardware through the application itself. You manage your data and user access — nothing else. You interact with the software through a browser or API.

Microsoft 365 (formerly Office 365) is the most widely recognized SaaS product. Microsoft runs the Exchange mail servers, the SharePoint infrastructure, the Teams platform, and all application updates. You manage users, permissions, and the content your organization creates. You never patch Exchange or manage a database. Amazon WorkMail is an AWS SaaS email service that works the same way.

Salesforce, Zoom, Slack, and Dropbox are all SaaS. When your company signs up for Slack, no one provisions servers or installs software. You configure your workspace, add users, and use the product. The provider handles all availability, scaling, and security of the application layer.

SaaS is appropriate when you need business functionality without building or operating it, and when the application does not need deep customization of the underlying platform. The risk is vendor dependency — your operations rely on the provider's availability, pricing decisions, and data handling practices. Under the shared responsibility model, you still own your data and are responsible for who has access to it, even in SaaS.

Service models directly determine your security responsibilities. The shared responsibility model states that as you move from IaaS to PaaS to SaaS, the cloud provider takes on progressively more security responsibility. But certain responsibilities never transfer: your data, your users, and your access controls are always yours.

In IaaS, you are responsible for OS patching, firewall configuration, network access controls, application security, and data encryption. A misconfigured EC2 security group that exposes a database to the internet is your misconfiguration, not AWS's.

In PaaS, OS patching and runtime security move to the provider. You are responsible for secure application code, correct application configuration, and data handling. An application vulnerability in code you deployed to Azure App Service is still your responsibility.

In SaaS, the provider manages application security. You are responsible for identity and access management — which users have access, what permissions they hold, whether MFA is enforced. A SaaS breach caused by a compromised user account with excessive privileges is always a customer-side failure.

Exam questions on service models fall into three patterns: identify the model from a description, match a service to a model, or determine responsibility under the shared responsibility model.

For identification questions, look for the management boundary. The question mentions managing the OS, patching servers, or configuring the runtime yourself: that is IaaS. The provider manages the platform, you push application code: that is PaaS. The provider manages everything, users just log in and use software: that is SaaS.

For service matching: AWS EC2, Azure VM, Google Compute Engine = IaaS. AWS Elastic Beanstalk, AWS RDS, Azure App Service, Azure SQL Database, Google App Engine = PaaS. Microsoft 365, Gmail, Salesforce, Amazon WorkMail = SaaS. A common trap is placing RDS in IaaS because it involves databases and servers. RDS is PaaS — AWS manages the engine, OS, and patching.

For shared responsibility questions, the formula is: IaaS = customer manages OS and above. PaaS = customer manages application and data. SaaS = customer manages data and access. Encryption at rest is a shared control in all three models: the provider offers the capability, the customer decides to enable it and manages the keys.