Cloud computing is often explained as a three-layer stack: infrastructure as a service, platform as a service, and software as a service. That model is useful because it shows how responsibility moves upward from raw computing resources toward finished applications. It becomes misleading, however, when the layers are treated as a strict hierarchy that every modern cloud product fits neatly. Serverless functions, managed databases, container platforms, AI services, integration products, and security services sit across those boundaries. A better way to learn the stack is to understand what the provider manages, what the customer still controls, and how much operational responsibility each service removes.
NIST Gives the Classic Three-Service Model
NIST SP 800-145 defines cloud computing through five essential characteristics, three service models, and four deployment models. The three service models are software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). That vocabulary remains useful because it describes increasing levels of provider management. It also helps separate cloud computing from ordinary hosting: the broader NIST definition includes on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.
The model is a starting point, not a complete modern product catalog. Cloud providers now expose services for containers, functions, analytics, machine learning, identity, messaging, databases, observability, and security. Many of those offerings combine characteristics of more than one classic layer. Readers new to the subject should first become comfortable with cloud basics, then use the service-model layers to reason about control and responsibility rather than memorizing product names.
IaaS Gives You Resources and Leaves You More to Operate
Infrastructure as a service provides fundamental computing resources such as virtual machines, networks, and storage while the provider operates the underlying physical infrastructure. Customers usually retain responsibility for operating systems, runtime configuration, applications, data, identity choices inside the workload, patching above the provider boundary, and much of the monitoring and resilience design. That control makes IaaS flexible, especially when moving software that expects conventional servers or specialized network layouts.
The trade-off is operational work. Virtual machines still need images, patching, configuration, backup design, capacity decisions, telemetry, and lifecycle management. Infrastructure automation can reduce manual effort, but automation does not make ownership disappear. IaaS is therefore best understood as rented programmable infrastructure rather than “someone else runs everything.” It is often the right layer when compatibility, deep operating-system control, custom network appliances, or specialized runtime requirements matter more than minimizing operational burden.
PaaS Trades Low-Level Control for a Managed Application Platform
Platform as a service raises the abstraction. The provider manages more of the operating environment so developers can focus on code, application configuration, data, and service behavior. A traditional PaaS can manage runtime versions, instance provisioning, patching, health, and scaling conventions. Modern managed application platforms also include container services, managed runtimes, deployment slots, integrated logging, service bindings, and policy controls. The exact boundary varies by product, which is why “PaaS” should prompt a responsibility review rather than a fixed assumption.
The benefit is speed and consistency. Teams can standardize deployment and reduce server administration, but they accept provider constraints around supported runtimes, networking, scaling models, configuration, and upgrade schedules. Platform decisions also affect portability. If an application uses only a generic runtime, moving may be straightforward; if it depends heavily on proprietary identity, messaging, database, deployment, and observability features, the practical switching cost rises. Architecture should therefore weigh operational simplicity against flexibility and long-term coupling.
SaaS Delivers the Application but Not Zero Responsibility
Software as a service gives the customer a finished application accessed over a network. The provider runs the application stack and infrastructure, while the customer configures the service, manages users, controls data use, integrates the product with other systems, and sets governance around retention, sharing, access, and business process. Email, collaboration, CRM, ticketing, HR, and finance platforms are common examples.
The phrase “the vendor manages it” often hides important customer duties. A SaaS breach can begin with weak identity configuration, excessive admin privileges, unsafe sharing, unmanaged OAuth integrations, poor offboarding, or sensitive data stored without governance. Resilience also requires understanding provider backup, export, retention, and recovery capabilities. SaaS removes infrastructure operations; it does not remove accountability for how the application is configured or how organizational data moves through it.
Managed Services Blur the Neat Stack
Modern cloud architecture includes managed databases, queues, event buses, Kubernetes control planes, data warehouses, API gateways, function platforms, AI endpoints, and many other products that do not fit perfectly into a simple three-box diagram. A managed database feels like PaaS because the provider operates the database engine and infrastructure, yet the customer still owns schema design, queries, access, data quality, performance choices, and recovery configuration. A managed container platform can leave node management to the provider while customers remain responsible for workloads, images, secrets, policies, and application observability.
This is why service selection works better when teams map responsibilities component by component. A useful cloud architecture view focuses on capabilities, interfaces, ownership, and operating model. The label is less important than knowing who patches, who scales, who monitors, who backs up, who controls identities, and who responds when something fails.
Shared Responsibility Changes With Every Abstraction
As teams move from IaaS toward more managed services, provider responsibility generally increases, but customer responsibility does not vanish. It changes shape. With virtual machines, the customer may patch an operating system. With a serverless service, there may be no operating system to patch, but the customer still needs secure code, least-privilege permissions, dependency management, secret handling, event validation, logging, data protection, and sensible concurrency limits. With SaaS, infrastructure is abstracted away, yet identity governance and information handling remain critical.
The architecture decision therefore should include a responsibility matrix before production. Ask who owns runtime updates, certificates, encryption keys, backup, restore testing, scaling, network paths, logs, alerting, vulnerabilities, configuration drift, and incident evidence. Doing this early avoids the common failure in which every team assumes another team owns the control. Abstraction reduces some categories of work while concentrating attention on the parts customers still control.
Cross-Cutting Services Matter More Than the Diagram Suggests
Identity, networking, data, observability, automation, security, and cost management cut across every cloud layer. A SaaS application still depends on identity and network access. A PaaS service still needs telemetry and data classification. An IaaS environment still needs governance and automation. Real architectures are therefore graphs of dependencies, not vertical stacks. The same business transaction may pass through SaaS interfaces, API gateways, functions, managed databases, queues, and virtual networks before it completes.
Architecture reviews should follow that transaction and ask what happens when a dependency is slow, unavailable, misconfigured, compromised, or unexpectedly expensive. A architecture review is more useful than simply labeling each component IaaS or PaaS because it forces teams to examine reliability, security, performance, cost, and operational evidence across service boundaries.
Choose the Layer by Required Control and Operating Capacity
There is no universally superior cloud layer. IaaS may be appropriate when software requires operating-system control or migration compatibility. PaaS can be better when application teams want managed runtimes and faster delivery. SaaS is often sensible when the business needs a mature capability rather than a custom application. Serverless and specialized managed services can reduce administration further when their execution model matches the workload. The decision should follow requirements, not fashion.
A practical selection process starts with the application’s constraints: customization, latency, data residency, integration, portability, compliance, recovery, skills, release frequency, cost profile, and operational staffing. Then compare how candidate services divide responsibility. The “layer” is useful because it tells you what kind of work is being abstracted. The architecture succeeds only when the organization is willing and able to own what remains.
Another practical way to learn the layers is to take one application and redesign it several times. Run it first on virtual machines, then move the runtime to a managed application platform, replace selected components with managed databases and queues, and finally consider serverless functions or SaaS where appropriate. For each version, document what the provider now operates, what the application team still owns, and which failure modes moved rather than disappeared. This exercise makes abstraction concrete.
It also reveals that cost and skill requirements shift with the service model. Higher abstraction can reduce infrastructure labor but increase dependence on service-specific limits, pricing dimensions, and operational tooling. Lower abstraction may provide flexibility while requiring more engineering capacity. The best architecture is therefore not the one with the most managed services; it is the one whose responsibility boundary matches the organization’s needs and capabilities.
A useful architecture exercise is to compare the same workload at two abstraction levels. Model who patches the runtime, who handles scaling, where logs live, how identity is enforced, how backups work, and what happens during an outage. That comparison often exposes hidden operational cost. A service that looks expensive per unit can still be cheaper if it removes months of platform engineering, while a highly managed service can be a poor fit when portability, custom networking, or specialized runtime control is essential. Treat abstraction as an operating-model decision, not simply a product category. The best layer is the one whose responsibility boundary matches the team’s skills, risk tolerance, and expected rate of change.
