What each cloud service type gives you, what you still manage, and typical use cases for each.
From Ultra Transcenders AZ-900 by Tony Rough (publishing soon)
Cloud services are grouped into three service types according to how much of the stack the provider manages. The type chosen decides the split of the shared responsibility model described in Chapter 1, “Cloud computing, cloud models and pricing”.
Infrastructure as a service (IaaS) is the most flexible category and gives the most control. The provider maintains the hardware, network connectivity to the internet and physical security; the customer is responsible for everything else, including operating system installation, configuration and maintenance (patching), network configuration, and database and storage configuration. In effect, the customer rents hardware in a cloud datacentre and decides what to do with it.
Azure examples: Azure Virtual Machines, Azure Disk Storage and virtual networks.
Typical use cases:
Platform as a service (PaaS) is the middle ground between renting datacentre space (IaaS) and paying for a complete solution (SaaS). The provider maintains the physical infrastructure, physical security and internet connection, and also the operating systems, middleware, development tools and analytics services. The customer doesn’t have to worry about licensing or patching operating systems and databases; it focuses on application code, data and access controls, with some networking and application security settings shared.
Azure examples: Azure App Service, Azure Functions, Azure SQL Database and Azure Storage.
Typical use cases:
Software as a service (SaaS) is the most complete model from a product perspective: the customer rents or uses a fully developed application. The provider manages almost the whole stack, including infrastructure, platform and application maintenance; the customer mainly manages its data, identity and access settings, and device access. SaaS is the least flexible model, but the easiest to get running and needs the least technical expertise.
Microsoft examples: Microsoft 365 and Dynamics 365.
Typical use cases:
| Aspect | IaaS | PaaS | SaaS |
|---|---|---|---|
| What the customer gets | Virtualised infrastructure (servers, storage, networking) | A managed platform to build and run applications | A finished application |
| Flexibility and control | Most | Moderate | Least |
| Customer manages | Operating system, patching, middleware, runtime, applications, data, network configuration | Application code, data, access controls; some network and app settings shared | Data, identities and access, devices |
| Provider manages | Hardware, physical network, physical security, hypervisor | Everything in IaaS plus operating system, middleware, runtimes, development tools | Almost everything, including the application |
| Operating system patching | Customer | Provider | Provider |
| Expertise needed | Most | Moderate | Least |
| Azure or Microsoft examples | Azure Virtual Machines, Azure Disk Storage, virtual networks | Azure App Service, Azure Functions, Azure SQL Database, Azure Storage | Microsoft 365, Dynamics 365 |
| Typical use cases | Lift-and-shift migration, dev/test with full control | Application development, analytics and BI | Email, productivity, finance and expense apps |
Many Azure solutions combine service types, for example a web app on PaaS using a database on a virtual machine. Serverless services such as Azure Functions (Chapter 1) sit within PaaS: Microsoft lists Azure Functions alongside App Service as PaaS examples. The individual compute and hosting services are compared in Chapter 4, “Compute and application hosting”.
Common trap: PaaS still requires the customer to patch the operating system - in PaaS the provider maintains the operating system and middleware; the operating system is the customer’s responsibility only in IaaS.
Common trap: SaaS is the most flexible service type because it is the most complete - SaaS is the least flexible and IaaS the most flexible; SaaS trades flexibility for the least management effort.
This note is one section of Ultra Transcenders AZ-900: Microsoft Azure Fundamentals, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Publishing soon on Amazon in Kindle and paperback editions.
About the book · AZ-900 terms in the glossary · All AZ-900 study notes
Which security and management duties Microsoft owns, which you always keep, and which shift by service type.
What sovereign regions are, who can use them, and how they differ from the public Azure regions.
How peering connects virtual networks within and across regions, and what traffic and transitivity rules apply.
How each storage redundancy option copies your data and which failures it protects against.
The three Zero Trust principles and how they change the traditional network-perimeter approach to security.
How resource locks prevent accidental deletion or change, how they inherit, and how they differ from RBAC and Policy.
What Azure Advisor recommends across its categories and how it fits alongside Service Health and Azure Monitor.