Cloud Computing Models Explained: IaaS, PaaS, and SaaS With Real Examples

Cloud computing isn’t one thing. It’s three service models stacked on top of each other, each handling a different layer of the technology stack. Understanding which model fits which use case is the difference between a cloud strategy that works and one that creates new headaches while solving old ones.

I explain this to clients constantly. Here’s how I think about it.

TL;DR: Worldwide public cloud spending is forecast at $723.4 billion in 2025, up 21.5% from 2024 (Gartner, 2024). The three service models — IaaS (you manage applications and data), PaaS (you manage applications only), and SaaS (the vendor manages everything) — form a spectrum from maximum control to maximum convenience. Most businesses use all three: IaaS for custom infrastructure, PaaS for development, and SaaS for business applications.

What Are the Three Cloud Service Models?

Public cloud spending will reach $723.4 billion in 2025 (Gartner, 2024). That money splits across three models, and the choice between them comes down to a simple question: where should your team spend its time?

Every layer you manage yourself is a layer you must also secure, update, and troubleshoot. So the real question is which layers give you a competitive edge. Everything else? Let someone else handle it.

IaaS (Infrastructure as a Service). The provider gives you virtual machines, storage, and networking. You manage everything above that: operating systems, middleware, applications, data. Think of it as renting a building. You bring the furniture.

Examples: AWS EC2, Microsoft Azure VMs, Google Compute Engine. Use cases: custom application hosting, dev/test environments, high-performance computing, and scenarios where you need full control over the software stack.

PaaS (Platform as a Service). The provider manages infrastructure plus the operating system and runtime. You manage your applications and data. Think of it as renting a furnished office. You bring your work.

Examples: SAP BTP (Cloud Foundry and Kyma), Heroku, Google App Engine, Azure App Service. Use cases: application development, API hosting, scenarios where you want to deploy code without managing servers.

SaaS (Software as a Service). The provider manages everything: infrastructure, platform, and application. You configure it and use it. Think of it as a co-working space. You just show up and work.

Examples: SAP S/4HANA Cloud (public edition), Salesforce, Microsoft 365, SAP Concur. Use cases: business applications where you want functionality without building or managing software.

How Do Real Businesses Use Each Model?

SAP’s cloud backlog reached EUR 77 billion, up 30% year-over-year (SAP News, 2025). That backlog represents companies making choices across all three cloud models right now.

Let me give you three real scenarios.

IaaS in practice: A manufacturing company runs its legacy applications on AWS EC2 instances. They moved off on-premise servers but kept the same software. Same apps, different infrastructure. They still manage the operating system, patches, and application configuration. The win: no more hardware procurement, and they can scale capacity during peak production periods. It’s a lift-and-shift, and sometimes that’s exactly the right move.

PaaS in practice: An SAP customer builds custom extensions for Sales Cloud V2 using SAP CAP on BTP’s Cloud Foundry. They write business logic in Node.js, deploy to BTP, and the platform handles scaling, availability, and infrastructure. They never touch a server. They just push code. That’s a neat workflow, and it’s how we build most of our client extensions at Spadoom.

SaaS in practice: A mid-size company uses SAP Concur for expense management. Employees submit expenses through the mobile app, managers approve them, finance processes reimbursements. The company configured Concur’s expense policies and approval workflows but didn’t build a single line of custom software. That’s the sweet spot for SaaS.

Most companies use all three models at the same time. The choice depends on the use case, not a blanket “we’re cloud-first” policy.

Who Are the Major Cloud Providers?

The top three public cloud providers (AWS, Azure, and Google Cloud) hold a combined market share exceeding 70% (Synergy Research, 2025). AWS leads at roughly 31%, Azure at 25%, Google Cloud at 11%.

For SAP workloads, the provider choice often comes down to which hyperscaler your SAP contract is on. RISE with SAP runs on AWS, Azure, or GCP, and SAP pre-negotiates the infrastructure. For non-SAP workloads, it depends on existing skills and technology partnerships.

Amazon Web Services (AWS). The largest provider with the broadest service catalogue. Strong in compute, storage, machine learning, and serverless computing. SAP runs on AWS for many RISE with SAP customers.

Microsoft Azure. Second largest, tightly integrated with Microsoft’s enterprise ecosystem (Office 365, Active Directory, Teams). Strong in hybrid cloud, enterprise identity, and Windows-based workloads.

Google Cloud Platform (GCP). Third largest, known for data analytics, machine learning (Vertex AI), and Kubernetes (GKE). Strong in big data, analytics, and open-source technologies.

SAP BTP is a specialised PaaS built specifically for SAP workloads. It runs on top of AWS, Azure, or GCP. You choose the hyperscaler when creating subaccounts. BTP adds SAP-specific services (Integration Suite, HANA Cloud, CAP runtime) that generic cloud providers don’t offer. We use BTP for virtually every client extension and integration project.

How Do You Choose the Right Model?

Forty-three per cent of organisations say generative AI influenced their ERP decisions in 2025 (ERP Today, 2025). AI capabilities are increasingly available as SaaS, which shifts the model choice for many teams.

Here’s the simple decision framework I use with clients:

• Use SaaS when the application exists and does what you need. Don’t build what you can buy. CRM, ERP, expense management, email: these are solved problems.
• Use PaaS when you need custom applications but don’t want to manage infrastructure. API services, custom business logic, integrations, microservices.
• Use IaaS when you need full control over the software stack. Legacy application hosting, specialised computing (GPU workloads), and scenarios with strict compliance requirements that mandate OS-level control.

A practical rule that we follow at Spadoom: start with SaaS. Drop to PaaS when SaaS can’t be configured to meet your needs. Drop to IaaS only when PaaS constraints block your architecture. Prima vista it sounds too simple, and honestly, it usually is that simple. People overcomplicate this.

FAQ

Is cloud computing always cheaper than on-premise?

Not always. Cloud is cheaper for variable workloads, small to mid-size deployments, and companies without dedicated IT infrastructure teams. For large, steady-state workloads, on-premise can be cheaper over 5+ years. The proper comparison is TCO (total cost of ownership) over the expected lifetime, not monthly cost versus upfront cost.

Is cloud computing secure enough for regulated industries?

Yes, when configured correctly. Major cloud providers (AWS, Azure, GCP) hold certifications for ISO 27001, SOC 2, HIPAA, and PCI DSS. They invest billions in security infrastructure. The risk typically comes from misconfiguration, not from the cloud itself. Most security breaches in cloud environments are caused by customer configuration errors, not provider vulnerabilities.

What is multi-cloud and when does it make sense?

Multi-cloud means using more than one cloud provider (e.g., AWS for compute, Azure for identity, GCP for analytics). It makes sense when different providers offer best-in-class capabilities for different workloads. It adds complexity though, so don’t adopt multi-cloud unless you have a crisp reason for each provider.

Can I move between cloud providers?

In theory, yes. In practice, it depends on the model. IaaS workloads are the most portable (VMs and containers move relatively easily). PaaS workloads may use provider-specific services that don’t exist elsewhere. SaaS workloads require data export and re-implementation on the new platform. Portability decreases as you move up the stack.

What is serverless computing?

Serverless is a subset of PaaS where you deploy individual functions rather than applications. The provider handles all infrastructure, scaling, and availability automatically. You pay per execution, not per hour. Examples: AWS Lambda, Azure Functions, Google Cloud Functions. Use cases: event-driven processing, API backends, and scheduled tasks.