Cloud offerings are described along two axes. The service model (also called the delivery model) says how much of the stack the provider runs for you: infrastructure, a platform, or a finished application. The deployment model says who owns the infrastructure and who shares it. Knowing both tells you how much control you keep and how much work you take on.
The three service models#
Start with the service model, the first axis. Each one is a pre-packaged bundle of IT resources. Moving from IaaS to PaaS to SaaS, the provider manages more and you control less.
- Infrastructure as a Service (IaaS): you rent virtual machines, storage and networks. You install and run everything above the hypervisor.
- Platform as a Service (PaaS): you push application code. The provider runs the servers, operating system, runtime and scaling.
- Software as a Service (SaaS): you use a finished application through a browser or app. You manage only your users, settings and data.
Who manages what#
The list above is the short version. The table shows layer by layer what you manage (✓) in each model, with on-premises as the baseline; the rest belong to the provider.
| Layer | On-premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Data and access | ✓ | ✓ | ✓ | ✓ |
| Application | ✓ | ✓ | ✓ | ✗ |
| Runtime and middleware | ✓ | ✓ | ✗ | ✗ |
| Operating system | ✓ | ✓ | ✗ | ✗ |
| Virtualization | ✓ | ✗ | ✗ | ✗ |
| Servers, storage, network hardware | ✓ | ✗ | ✗ | ✗ |
| Physical data center | ✓ | ✗ | ✗ | ✗ |
The first row matters most. Even in SaaS, your data and who can access it stay your job. The same split drives security duties; see the shared responsibility model.
IaaS#
With the overall split in place, here's each model in more detail, starting with the one closest to running your own servers. IaaS gives you virtual building blocks and the most control. It suits teams that need a custom setup or must run software that expects a full server.
What you control#
Everything above the hypervisor is yours to decide.
| Area | What you can do |
|---|---|
| Virtual machines | Choose the OS, CPU and memory size, and install any software |
| Networking | Configure virtual networks, subnets, firewalls, IP addresses and load balancers |
| Storage | Attach block volumes, use object storage, take snapshots and backups |
| Scaling | Add or remove machines by hand or with auto scaling rules |
What you cannot control#
The provider keeps the layers below the virtual machine.
- The physical servers, network gear and disks.
- The hypervisor (the virtualization layer).
- Physical data center security: entry control, guards, cameras.
Examples: Amazon EC2, Google Compute Engine, Azure Virtual Machines. Netflix is a well-known EC2 customer. A developer who needs a test environment can rent an EC2 instance, install the OS packages and tools, and delete it after the test.
PaaS#
One step up the stack, PaaS gives you a ready platform for building and running applications. You focus on code; the platform handles servers, patching and scaling.
How it works#
Since you never touch a server, using PaaS looks different from IaaS. A typical workflow has three steps.
- Provision: create an application or project on the platform. It sets up compute, storage and networking in the background.
- Deploy: push code with Git or a CI/CD pipeline. The platform builds it and deploys it into the configured environment.
- Run: the platform allocates resources, scales the app and monitors it.
IaaS vs PaaS control#
Handing over the servers doesn't mean handing over every setting. PaaS still lets you set application-level options such as environment variables, logging and scaling limits. It hides the infrastructure-level options.
| Task | IaaS | PaaS |
|---|---|---|
| Choose instance types | ✓ | Usually ✗ |
| Configure the OS and VM | ✓ | ✗ |
| Scaling | You set rules for VMs | The platform scales the app |
| Access to servers | Full | None |
| Your focus | Infrastructure and application | Application only |
Examples: Heroku, Google App Engine, AWS Elastic Beanstalk, Azure App Service. A startup can push a web app to Heroku and let the platform handle deployment, load balancing and scaling.
Managed databases such as Amazon RDS are often grouped with PaaS. You get a database endpoint, and the provider handles the OS, patching and backups.
SaaS#
At the top of the stack, SaaS delivers a complete application over the internet. There is nothing to install or maintain, and billing is usually per user or per month.
- You manage: user accounts, settings, and the data you put in.
- The provider manages: the application, its infrastructure, updates, security and scaling.
Examples: Salesforce (CRM), Google Workspace, Microsoft 365, Zoom. A sales team that needs a CRM can subscribe to Salesforce and start working the same day.
Comparing the service models#
With all three models covered, the table puts them side by side.
| IaaS | PaaS | SaaS | |
|---|---|---|---|
| Control | Highest | Application and its settings | Settings and data only |
| Scaling | You configure it | The platform scales the app | The provider scales it |
| Typical user | Ops and DevOps teams | Developers | End users and businesses |
| Use when | You need a custom or legacy setup | You want to ship code without running servers | You need a standard tool, not a product to build |
One problem, three answers#
The table is easier to remember with a concrete case. A company wants to sell products online, and each model gives a different path.
- IaaS: run EC2 instances. The team installs and secures the OS, web server and database.
- PaaS: deploy the shop code to a platform like App Engine or Elastic Beanstalk. The platform handles servers and scaling.
- SaaS: subscribe to a hosted e-commerce product such as Shopify. The team configures the storefront and products and writes no server code.
Real companies mix models. A typical setup runs custom services on EC2 (IaaS), keeps data in RDS (managed database), and uses Microsoft 365 or Google Workspace (SaaS) for email and documents.
Deployment models#
Now the second axis. Where the service model is about how much of the stack you run, a deployment model describes who owns the infrastructure and who shares it, and the choice depends on cost, security, control and scale.
Public cloud#
This is the model most people mean when they say "the cloud." A provider owns and runs the infrastructure and rents it to many customers over the internet.
- Shared infrastructure: many tenants use the same hardware, with logical isolation.
- Pay as you go: you pay only for what you use.
- Provider-managed: the provider maintains, patches and scales the infrastructure.
- Fits: startups, web and mobile apps, workloads with changing demand.
- Examples: AWS, Microsoft Azure, Google Cloud.
Private cloud#
A private cloud flips the sharing. The infrastructure serves one organization only. It can run in that organization's own data center or be hosted by a third party.
- Dedicated resources: no other organization shares the hardware.
- More customization: you choose how everything is configured.
- Higher cost: you pay for all the capacity, used or not, and often run it yourself.
- Fits: strict regulatory needs (finance, healthcare) and large enterprises that want full control.
- Examples: platforms built with OpenStack or VMware.
Hybrid cloud#
A hybrid cloud connects a private environment with a public cloud so data and applications can move between them. A common pattern keeps sensitive data or core systems private and uses the public cloud for less sensitive work or traffic peaks.
- Fits: businesses with seasonal spikes, such as retail during holidays, or with data that must stay on-premises.
- Needs: reliable connections (VPN or a dedicated link such as AWS Direct Connect) and consistent tooling on both sides.
- Example: AWS Outposts puts AWS-managed hardware in your own data center.
Community cloud#
Several organizations with shared requirements, such as security or compliance rules, share one infrastructure. It is not open to the general public, and the members share the cost.
- Fits: government agencies, healthcare networks, universities working on joint research.
- Example: government-only regions such as AWS GovCloud (US), which serve agencies and their contractors.
Comparing deployment models#
The table puts the four deployment models side by side.
| Public | Private | Hybrid | Community | |
|---|---|---|---|---|
| Infrastructure | Shared by many tenants | One organization | Public plus private | Several similar organizations |
| Managed by | The provider | You or a third party | Both | Members or a third party |
| Cost | Pay as you go, lowest entry cost | Highest | Depends on the split | Shared by members |
| Control | Lowest | Highest | Mixed | High, shared |
| Fits | Startups, web apps | Regulated, large firms | Spiky or split workloads | Shared compliance needs |
Many companies also use more than one public provider. This is called multi-cloud, and it is different from hybrid cloud, which mixes private and public.
Key takeaways#
- IaaS gives you virtual machines, networks and storage. PaaS runs your code. SaaS is a finished application.
- Moving from IaaS to SaaS, the provider manages more layers and you control fewer.
- Your data and access control stay your job in every model.
- Public clouds are shared and pay as you go. Private clouds serve one organization. Hybrid connects the two. Community clouds serve a group with shared rules.
- Pick the model by the control you need, the compliance rules you face, and the work you want to own.