Overview
Cloud service models describe how much of the infrastructure stack a provider manages on your behalf, from raw compute up through a fully hosted application. The three common tiers, Infrastructure as a Service, Platform as a Service, and Software as a Service, aren't different technologies so much as different lines drawn across the same stack, and that line directly determines both your operational burden and your share of security responsibility. Picking the right model for a given workload is a trade-off between control and convenience, not a strict hierarchy where higher is always better.
Quick Reference
| Model | You manage | Provider manages | Example |
|---|---|---|---|
| IaaS | OS, runtime, app, data, config | Physical hardware, virtualization, network | Raw virtual machines |
| PaaS | App code, data, config | OS, runtime, scaling infrastructure | Managed app platforms |
| SaaS | Configuration, data, access | Everything else, including the app | Hosted productivity/CRM tools |
Syntax
# IaaS - you provision and manage the VM's OS yourself
resource "aws_instance" "app" {
ami = "ami-0abcdef1234567890"
instance_type = "t3.small"
}# PaaS - you only describe the application; the platform
# manages the OS, runtime, and scaling underneath it.
name: checkout-api
runtime: nodejs20
instances: 2Examples
# IaaS: you're responsible for OS patching, runtime installation,
# and scaling policy - full control, full operational burden.
ssh ec2-user@app-instance
sudo apt-get update && sudo apt-get upgrade -yThe shared responsibility line moves with the model
For IaaS, you patch the OS. For PaaS, the provider does. For SaaS, there's no OS to think about at all, but your responsibility for access control and data never goes away, at any tier.
Visual Diagram
Common Mistakes
- Assuming a cloud provider is responsible for something the shared responsibility model actually places on the customer, most commonly, IAM configuration and data encryption, both of which are always the customer's job regardless of service model.
- Choosing PaaS or SaaS purely to reduce cost, without checking whether the workload actually fits the platform's constraints, forcing a fit often costs more in workarounds than it saves in operations.
- Treating "serverless" as a fourth, entirely separate category; it's more precisely understood as an extreme point on the PaaS spectrum, where even instance/server-count management is abstracted away.
- Over-provisioning IaaS "just in case" instead of evaluating whether a managed PaaS offering already handles the scaling problem being solved manually.
Performance
- Higher up the stack (PaaS, SaaS) generally means faster time-to-deploy for standard workloads, since the provider has already solved scaling and runtime management, at the cost of less control over exactly how that scaling behaves.
- IaaS gives the most control over performance tuning (custom kernel parameters, specific instance types, network placement) but requires the team to actually do that tuning.
- Cold-start latency is a real, model-specific performance characteristic of some PaaS/serverless offerings that doesn't exist the same way on a persistently running IaaS instance.
Best Practices
- Match the service model to the team's actual operational capacity and the workload's actual constraints, not to a blanket "always use the most managed option" policy.
- Read the specific shared responsibility documentation for whichever model and provider you're using, the line isn't identical across providers.
- Re-evaluate the choice as a workload matures, a prototype often starts on PaaS for speed, and some workloads later move to IaaS once their specific performance or compliance needs become clear.
- Never assume "managed" means "no responsibility", IAM, data classification, and access control remain the customer's job at every tier.