What actually changes when a company moves a workload from its own server room into the cloud? The honest answer is that almost everything changes at once: who patches the operating system, who holds the encryption keys, who answers the phone at 3 a.m., and who signs the invoice at the end of the month. The cloud service model you pick decides how that work gets divided. Pick well and the team spends its time on things customers care about. Pick badly and you inherit the worst parts of both worlds.
This article walks through the three main models, what each one genuinely makes easier, where each one bites, and the mistakes that show up again and again in real deployments.
What the three cloud service models actually mean
The vocabulary is standardized. The U.S. National Institute of Standards and Technology published its working definition of cloud computing in September 2011, and it remains the reference text most architects still cite. According to NIST’s definition of cloud computing in Special Publication 800-145, there are three service models:
- Software as a Service (SaaS): the consumer uses the provider’s applications running on cloud infrastructure, usually through a browser, without managing the underlying platform.
- Platform as a Service (PaaS): the consumer deploys self-built or acquired applications onto the provider’s supported languages, libraries, services and tools.
- Infrastructure as a Service (IaaS): the consumer provisions processing, storage, networks and other fundamental computing resources, and can run arbitrary software, including operating systems.
The same document lists five essential characteristics that separate real cloud from a server with a fancy name: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Those five traits are where most of the benefits come from. They are also where most of the headaches come from, because each one hands control to somebody outside your building. (What is SaaS? Software as a Service explained)
The benefits, model by model
SaaS: speed and someone else’s maintenance
SaaS wins on time to value. There is no server to size, no database to tune, no certificate to renew. A finance team can be live on a new expense tool in an afternoon. The provider handles patching, uptime engineering and feature releases, and the customer pays a subscription rather than buying hardware.
The practical benefit is that SaaS turns a capital project into an operating expense and a procurement decision. For functions that are not your differentiator, such as email, payroll or customer support ticketing, that trade is usually excellent.
PaaS: the developer productivity sweet spot
PaaS sits in the middle and often gets overlooked. The provider runs the servers, the runtime, the scaling rules and the deployment pipeline. The customer brings code and data. For a small engineering team, this removes a huge amount of undifferentiated work: no cluster upgrades, no load balancer config, no midnight kernel patches.
Managed databases, container platforms and serverless functions all fit here. The benefit is measured in engineering hours returned to product work, which is a far more honest metric than a raw infrastructure price comparison.
IaaS: control when you need it
IaaS gives the most knobs. You choose the operating system, the network layout, the storage type and the security tooling. That matters for legacy applications that cannot be rewritten, for workloads with unusual compliance requirements, and for teams that already have deep systems expertise.
The benefit is flexibility plus elasticity: capacity that used to take months to procure can be switched on in minutes. That changes planning completely. Instead of buying for peak load three years out, teams can size for today and adjust. The discipline of doing that well is worth studying separately, and a walkthrough of planning capacity for a new cloud service shows how the forecasting actually works when demand is uncertain.
Where the challenges really live
The shared responsibility line is fuzzier than people think
Every model splits duties between provider and customer, but the split is not always obvious. Under IaaS the customer typically owns the operating system, middleware, runtime, applications and data. Under SaaS the provider owns nearly all of it, and the customer owns its users, its configuration and its data. PaaS lands somewhere between.
The classic mistake is assuming “cloud” means “secure by default.” It does not. A misconfigured storage bucket, an over-permissive identity role or an unpatched application is the customer’s problem in every model. NIST’s companion guidance on security and privacy in public cloud computing, SP 800-144, lays out governance, trust and incident-response questions that a service model choice does not answer on its own.
In practice, the fix is boring and effective: write down, per workload, who patches what, who holds which keys, who reviews logs and who declares an incident. Do it before go-live, not during the first outage.
Cost control is a skill, not a feature
Elasticity cuts both ways. Resources that scale up automatically also bill automatically. Teams that move to the cloud without tagging, budgets and regular reviews routinely find spend drifting upward, because unused volumes, idle test environments and forgotten snapshots all keep charging.
What actually works: tag every resource with an owner and a cost centre from day one, set budget alerts at the account level, and review the bill monthly with the people who generate it. Splitting workloads across separate accounts makes this far easier to enforce, and there is a solid case for when to split workloads across cloud accounts that covers the trade-offs. Data transfer is the sneaky line item most teams miss until the first big bill arrives; a method for tracking cloud data transfer costs helps catch it early.
Lock-in is real, and now partly a legal question
Vendor lock-in has moved from a grumble to a regulated topic. The European Union’s Data Act, Regulation (EU) 2023/2854, entered into force in January 2024 and applies from September 2025. It includes provisions intended to make switching between cloud providers easier and to reduce contractual barriers. The full text is available through the EU Data Act on EUR-Lex, and it is worth reading if your organisation buys cloud services in Europe.
Technical lock-in is separate from contractual lock-in. Proprietary managed services can be deeply convenient and deeply sticky. A pragmatic middle path: use managed services freely for commodity functions, but keep core data in portable formats and avoid burying business logic in a single vendor’s proprietary runtime unless the convenience clearly outweighs the exit cost.
Compliance does not transfer to the provider
Under the General Data Protection Regulation, a cloud customer is generally the data controller and the provider is a processor, which means a written data-processing agreement is required under Article 28. The text of the GDPR on EUR-Lex sets out those duties. The same logic applies to sector rules in health, finance and the public sector.
The trap is assuming a provider’s compliance certifications cover your obligations. They do not. Certifications describe the provider’s controls. Your regulator cares about your data, your retention periods, your access reviews and your breach notification process.
Availability and portability are not guarantees
Provider outages happen. When they do, customers of SaaS and PaaS have limited ability to respond beyond waiting and communicating. IaaS customers can sometimes fail over to another region, but only if they designed for it in advance, and that design costs money and complexity that many teams underestimate.
Portability is uneven too. Standards work exists, including ISO/IEC 19941 on cloud interoperability and portability, but in practice moving a running workload between providers is rarely a simple export. The realistic approach is to test the exit: restore a backup into a different environment, confirm the data leaves in a usable format, and document how long it would take.
A side-by-side view
| Question | SaaS | PaaS | IaaS |
|---|---|---|---|
| Who patches the OS? | Provider | Provider | Customer |
| Who manages the application? | Provider | Customer | Customer |
| Typical time to first value | Hours to days | Days to weeks | Weeks to months |
| Control over configuration | Low to moderate | Moderate | High |
| Lock-in risk | High, but data export is usually possible | Moderate to high | Lower |
| Best fit | Standard business functions | Custom apps, small teams | Legacy, specialised or regulated workloads |
Mistakes that show up again and again
A few patterns recur across organisations of very different sizes.
- Choosing the model by habit rather than by need. Teams with strong systems skills default to IaaS even when a managed platform would serve them better. Teams without those skills sometimes pick IaaS and then discover they have bought a data centre with a monthly bill.
- Skipping the inventory. You cannot decide where a workload belongs if nobody knows what it depends on, who owns it, or what data it touches. A structured pre-migration inventory prevents most of the surprises.
- Treating the migration as a one-off project. Cloud estates drift. Without a regular review of cost, access and architecture, the tidy design from year one quietly rots.
- Ignoring the announcement details. Region launches and service changes come with fine print about features, latency and data residency. Learning how to read a cloud region announcement saves a lot of rework.
- Assuming the provider’s security team is your security team. It is not. The shared responsibility model puts your configuration, identities and data firmly in your hands, which is why cloud security practice deserves its own budget line rather than a footnote.
How to choose without overthinking it
A simple decision path works for most workloads. Ask three questions in order.
First, is this function a source of competitive advantage? If not, SaaS is usually the right answer, and the faster the better. Second, does the team write and own the code? If yes, PaaS removes the most operational drag per pound spent. Third, does the workload have a hard technical constraint, such as a legacy runtime, a specialised licence or a regulatory requirement that managed platforms cannot meet? If so, IaaS is justified.
Then check the exit. For each workload, write down how the data would leave, in what format, and how long it would take. If the answer is “we would have to ask the vendor nicely,” that is a risk to record, not a reason to panic.
Finally, revisit the decision annually. Service models are not marriages. Plenty of organisations run a sensible mix: SaaS for back-office functions, PaaS for the product, and a small IaaS footprint for the awkward legacy system nobody wants to touch. The broader discipline of cloud infrastructure and architecture is mostly about keeping that mix intentional rather than accidental, and the wider field of enterprise AI and cloud intelligence is increasingly shaped by the same choices.
Conclusion
The benefits of cloud service models are real: speed, elasticity, and the ability to stop paying for idle metal. The challenges are equally real, and they cluster around the same place, which is the boundary between what the provider manages and what you still do. SaaS removes the most operational work and hands over the most control. IaaS keeps the most control and hands back the most work. PaaS trades a little of each for developer speed.
The organisations that do well are rarely the ones that picked the theoretically perfect model. They are the ones that wrote down the responsibility split, tagged their resources, tested an exit, and reviewed the whole arrangement once a year. That is a modest amount of discipline, and it is the difference between a cloud strategy and an expensive surprise.
FAQ
What is the main difference between IaaS, PaaS and SaaS?
The difference is how much of the technology stack the customer manages. With IaaS you manage the operating system and everything above it. With PaaS the provider runs the platform and you bring the application and data. With SaaS the provider runs the whole application and you manage users, configuration and your own data.
Which cloud service model is cheapest?
There is no universal answer, because the cheapest option depends on what you count. SaaS usually has the lowest upfront cost and the least operational overhead. IaaS can look cheaper on a raw compute comparison but requires staff time for patching, security and administration. PaaS often wins on total cost for custom applications because it reduces engineering overhead.
Is the cloud more secure than an on-premises data centre?
Not automatically. Cloud providers invest heavily in physical and infrastructure security, but the customer remains responsible for configuration, identity management, access control and data protection. Many breaches in cloud environments come from customer-side misconfiguration rather than provider failures, which is why the shared responsibility split matters so much.
What does vendor lock-in mean in practice?
It means the cost and difficulty of moving away from a provider. That includes contractual terms, proprietary services, data formats and staff familiarity. Lock-in is not automatically bad, since managed services save real effort, but it should be a conscious trade rather than an accident. Keeping data in portable formats and testing an exit plan reduces the risk.
Do compliance obligations change when data moves to the cloud?
The obligations stay with you. Under data protection law, a cloud customer is typically the controller and the provider is a processor, which requires a written processing agreement and ongoing oversight. Provider certifications describe the provider’s controls, not yours, so retention rules, access reviews and breach procedures remain the customer’s responsibility.
How often should a cloud service model choice be reviewed?
At least once a year, and whenever a workload changes significantly. Pricing, provider features and business needs all shift. A model that made sense at migration time may be unnecessarily expensive or restrictive two years later, and regular reviews catch that drift before it becomes embedded in the architecture.
