IaaS, PaaS, and SaaS Through the Decisions You Still Own
IaaS, PaaS, and SaaS are often taught as three definitions to memorize. A more useful way to understand them is to ask what decisions the customer still owns. As a service becomes more managed, the cloud provider operates more of the underlying stack, but the customer does not stop being responsible for data, identities, access, configuration, and appropriate use.
The current AZ-900 objectives explicitly include infrastructure as a service, platform as a service, and software as a service. The exam-level distinction becomes practical when you use the models to reason about control, operations, security, cost, and speed.
The right question is rarely “Which model is best?” It is “Which responsibilities does this workload need us to own, and which responsibilities are we willing to delegate?”
IaaS gives the customer the most infrastructure control
With infrastructure as a service, the provider operates the physical datacenter, physical network, and hardware, while the customer manages much of the virtualized environment. Virtual machines are the familiar example: the organization chooses the operating system, patching approach, installed software, application configuration, and many network controls.
That control is valuable when applications need specific operating systems, agents, network behavior, or legacy dependencies. It also means more operational work. Teams must manage patching, capacity, hardening, monitoring, backups, and the lifecycle of the virtual machines they create.
IaaS can feel familiar to traditional infrastructure teams because many responsibilities resemble an on-premises server environment, only without owning the physical hardware.
IaaS also gives teams responsibility for configuration drift. Two virtual machines that began identically can diverge through manual changes, patches, and installed software. Infrastructure as code, standardized images, and automated configuration can reduce that risk, but the customer must design and operate those processes.
PaaS removes more platform operations
Platform as a service lets teams deploy applications or data workloads without managing the underlying operating system in the same way. Services such as managed application platforms, serverless functions, and managed databases can reduce patching and infrastructure administration.
The tradeoff is that the provider defines more of the platform. Applications may need to follow supported runtimes, service limits, deployment models, networking options, or configuration patterns. Developers gain speed by accepting those constraints.
PaaS is often attractive when the organization wants to focus engineering effort on application logic rather than the servers that host it.
PaaS can reduce undifferentiated operations, but teams still need to understand service limits and failure behavior. Managed does not mean infinite or automatically resilient. Quotas, supported regions, scaling rules, backup options, maintenance behavior, and network integration remain architecture decisions owned by the customer.
SaaS provides a finished application but still requires governance
Software as a service delivers a ready-to-use application. Microsoft 365 is a common example: Microsoft operates the application and underlying platform, while the customer configures users, access, data handling, sharing, retention, security settings, and business use.
This is why SaaS should not be confused with “the provider handles security.” The provider secures and operates large parts of the service, but the customer can still expose data through weak identity controls, excessive sharing, poor configuration, or inappropriate user behavior.
The Microsoft 365 environment makes this visible: a fully managed application still contains many customer-controlled security and governance decisions.
SaaS governance includes configuration lifecycle. New sharing features, defaults, integrations, and licensing changes can alter risk even when the customer never deploys software. Administrators need change review, access governance, data lifecycle controls, and monitoring because the application evolves continuously under a managed-service model.
Shared responsibility changes shape across the models
Some responsibilities remain with the customer in every cloud model. Microsoft’s shared-responsibility guidance emphasizes customer data, identities, access management, and the configurations the customer controls. Physical infrastructure belongs to the provider, while responsibility for operating systems, networks, and applications shifts as the service becomes more managed.
This model prevents a common misunderstanding. Moving from IaaS to PaaS or SaaS does not eliminate responsibility; it changes the layers where the customer must make decisions.
The cloud computing models become easier to compare when responsibility is the organizing idea rather than product names.
The shared-responsibility model should be documented for each critical service in plain language. Security teams often assume operations owns a task while operations assumes the provider owns it. A responsibility matrix that identifies patching, identity, backup, encryption choices, logging, incident response, and data governance can eliminate those gaps.
Control and convenience move in opposite directions
IaaS usually offers more low-level control but requires more operational effort. SaaS offers the least infrastructure control but can deliver business capability quickly. PaaS sits between those extremes for many application workloads.
Neither end is inherently better. A regulated legacy application may need infrastructure control that a SaaS product cannot provide. A standard business function may be wasteful to rebuild on virtual machines when a mature SaaS service already solves it.
Architecture quality depends on matching the level of control to the business requirement instead of choosing the model that gives engineers the most technical freedom.
Convenience also affects organizational skill requirements. IaaS demands deeper infrastructure expertise, while PaaS shifts knowledge toward application architecture and service behavior. SaaS may require less platform engineering but more configuration, identity, data governance, and vendor-management skill. Moving up the service stack changes the work; it does not remove the need for expertise.
Cost should include the operations you still own
An IaaS service may have a lower direct platform price than a highly managed service, but the organization must also pay for people, tools, patching, monitoring, backup, security engineering, and incident response. PaaS and SaaS can move some of that work into the service price.
This does not guarantee that managed services are cheaper. It means a fair comparison should include total operating effort, not only the line-item resource rate.
The Azure Fundamentals perspective is useful because service-model decisions affect both technical consumption and labor cost over the life of the workload.
Labor cost should include on-call burden. A self-managed platform may require teams to respond to operating-system failures, patch emergencies, capacity events, and backup problems. A managed service can transfer some of those responsibilities to the provider, which may have significant value even if the service price appears higher.
Portability and specialization are part of the tradeoff
More managed services can expose proprietary features that accelerate development but increase dependence on one platform. IaaS may allow more portable operating-system and application patterns, although infrastructure configuration can still become provider-specific.
Teams should decide where portability matters. A commodity internal application may benefit more from managed services than from theoretical portability. A platform expected to run across multiple environments may justify additional abstraction and operational effort.
Portability should be treated as a requirement with a business reason, not an automatic goal that overrides speed or simplicity.
Portability can be implemented selectively. An organization might accept a provider-specific managed database because migration risk is low while keeping application interfaces portable where strategic flexibility matters. Treating every layer as equally portable can add abstraction and complexity without producing meaningful business value.
Real systems mix service models
Most architectures do not live entirely inside one category. An application might run on PaaS, store data in a managed database, integrate with a SaaS identity or collaboration service, and retain an IaaS component for a legacy dependency.
That means shared responsibility must be evaluated component by component. The team should know which layers it owns for each service, how identities cross boundaries, where data moves, and which operational team responds when something fails.
The AZ-900 foundation is strongest when learners use the categories as reasoning tools rather than trying to force an entire environment into one label.
Mixed architectures need clear boundaries during incidents. When a SaaS application depends on a PaaS integration that reaches an IaaS-hosted legacy system, the response team must know which provider and internal team owns each layer. Service maps and dependency documentation are essential because the failure may cross several responsibility models.
Choose the service model by the decisions you want to own
For each workload, ask whether the organization needs operating-system control, custom network behavior, specialized runtime access, rapid application deployment, or a complete business application. Then identify the security, compliance, portability, cost, and support implications of delegating more of the stack.
The Microsoft Azure Fundamentals certification introduces this decision framework, and AZ-900 as a starting point before deeper Azure roles makes sense because later certifications assume candidates can reason about these boundaries. IaaS, PaaS, and SaaS are not just billing categories; they are different agreements about who operates what and which decisions remain yours.
Selection should also consider lifecycle horizon. A short-lived project may favor a managed service that minimizes setup, while a long-lived specialized platform may justify deeper control. The expected duration, rate of change, compliance obligations, and available skills can all influence whether owning more of the stack creates value or unnecessary operational debt.
Service-model choices should be revisited after major architecture changes. A workload that began on IaaS for migration speed may later be a strong PaaS candidate once dependencies are understood. Conversely, a SaaS product may stop fitting when regulatory, integration, or customization requirements change. Cloud architecture should treat service models as decisions that can evolve, not permanent identities.