IaaS vs PaaS vs SaaS: what each model means for cost, control and security

NIST defined the three cloud service models in September 2011: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). The definitions still work. What makes them useful for a buyer is one question per layer: who patches it, who pays for it, and who is blamed when it fails?

What you control in each model

NIST's wording is short. With IaaS the customer controls the operating systems, the storage and the deployed applications. With PaaS the customer does not manage the network, servers, operating systems or storage, but controls the applications it deploys. With SaaS the customer does not control the infrastructure or even individual application features, only per-user settings.

Microsoft's shared responsibility table turns that into a ledger.

The last two rows never move. Microsoft says it plainly: whatever the model, "you own your data and identities." You also remain responsible for the devices and endpoints that reach the service. AWS says the same in different words: the provider secures the cloud, and the customer secures what it puts in the cloud, with the split set by the service it picks.

IaaS: you patch the server

On Amazon EC2, AWS says the customer handles every security configuration and management task there, from guest operating system patches to the installed applications and the firewall rules. IaaS fits an existing application you want to move as it is, or software with specific operating system requirements.

The cost behavior differs too. IaaS bills for compute you reserve, and Azure Reservations can cut compute prices by up to 72% against pay-as-you-go in exchange for a one- or three-year commitment. That ceiling covers compute only. Microsoft states that a reservation does not cover Windows, additional software, networking or storage charges, so read the discount as a cap on one line of the bill. If your team already struggles to patch on-premises servers, IaaS moves the servers and keeps the patching.

PaaS: you ship the code

On PaaS the provider runs the operating system and runtime, and the application is shared work. Billing follows capacity rather than users. Azure App Service charges for the compute of each plan instance, and Microsoft notes you can save money by running several apps in one plan. Three small apps in three plans cost more than the same three in one plan, as long as they fit.

The trade-off is less control and some lock-in, since platform-specific features make a later move harder.

SaaS: you run the settings

SaaS is the finished product, usually priced per user. The provider runs nearly everything, which leaves the layers that cause incidents with you: who can sign in, what data sits in the tool, and which integrations are connected. Backup is a case in point, covered in why SaaS data needs its own backup and recovery. Treat a SaaS purchase as a new set of settings to maintain.

Filling in the ledger

Pick one workload per model and answer four questions: who patches the operating system, who patches the application, who manages sign-in, and what happens to the data if you leave. The answers should name a person or a team, not "the vendor." Most companies run all three models, and the ledger shows where your hours go. The cloud security checklist covers the controls that stay with you in every row.