IaaS vs PaaS vs SaaS

When you use the cloud, you and the provider split the work of running software. The cloud service model is the line that decides who does what. There are three classic models: IaaS (Infrastructure as a Service), PaaS (Platform as a Service), and SaaS (Software as a Service). Picking the right one is one of the most important early decisions you make, because it sets how much you operate, how much you control, and how easily you can leave later.

The pizza-as-a-service analogy

The easiest way to remember the models is to imagine wanting pizza for dinner. There are four ways to get it, and each hands off more work to someone else.

Approach	You provide	They provide	Cloud equivalent
Make it at home	Everything (oven, gas, dough, toppings, table)	Nothing	On-premises (your own data center)
Take-and-bake	Oven, gas, your table	The prepared pizza	IaaS
Delivery	Your table and drinks	Pizza, oven, the kitchen, the driver	PaaS
Dine out	Just yourself (you show up hungry)	Everything	SaaS

As you move down the table, you do less and less work, but you also have less and less control over how the pizza is made.

IaaS: Infrastructure as a Service

IaaS gives you raw building blocks: virtual servers, storage, and networking. AWS keeps the physical hardware, the data center, and the host running. You install and manage the operating system (OS), patches, runtime, and your application on top.

The classic AWS IaaS service is Amazon EC2 (Elastic Compute Cloud, virtual servers you rent by the second). Other examples are Amazon EBS (Elastic Block Store, virtual hard disks) and Amazon VPC (Virtual Private Cloud, your own private network).

When to use it: you need full control of the OS, custom networking, or specific software that must run on a server you tune yourself. When not to: if you just want to run code and never touch a server, IaaS is more work than you need.

Launch an EC2 instance from the console:

Open the EC2 console and choose Launch instance.
Pick an Amazon Machine Image (AMI) (a template for the OS and disk), e.g. Amazon Linux 2023.
Choose an instance type (the size), e.g. t3.micro.
Select a key pair for SSH access and a security group (a virtual firewall).
Click Launch instance.

The same thing with the AWS CLI (Command Line Interface) v2:

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids sg-0a1b2c3d \
  --subnet-id subnet-0a1b2c3d

Output:

{
    "Instances": [
        {
            "InstanceId": "i-0a1b2c3d4e5f",
            "InstanceType": "t3.micro",
            "State": { "Name": "pending" }
        }
    ]
}

Tip: With IaaS, AWS does not patch your OS or your app. If you forget to apply security updates, that is on you. This freedom is the trade-off for control.

PaaS: Platform as a Service

PaaS hides the servers. You hand AWS your code (or a container), and it runs, scales, and patches the underlying machines for you. You stop thinking about operating systems and focus on the application.

AWS PaaS examples:

AWS Elastic Beanstalk — you upload a web app and it provisions the EC2 instances, load balancer, and scaling behind the scenes.
AWS Lambda — “serverless” functions; you supply a function and AWS runs it on demand with no servers to manage.
AWS App Runner — point it at a container or repo and it serves your web service.

When to use it: you want to ship features fast and do not want to manage servers, patching, or scaling. When not to: if you need a special OS kernel module, custom networking the platform forbids, or very fine-grained tuning, the platform’s guardrails will get in your way.

Deploy a Lambda function with the CLI:

aws lambda create-function \
  --function-name hello-world \
  --runtime python3.13 \
  --handler app.handler \
  --role arn:aws:iam::111122223333:role/lambda-basic \
  --zip-file fileb://function.zip

Output:

{
    "FunctionName": "hello-world",
    "Runtime": "python3.13",
    "State": "Active",
    "MemorySize": 128
}

Console steps for the same deploy:

Open the Lambda console and choose Create function.
Pick Author from scratch, name it hello-world, runtime Python 3.13.
Choose or create an execution role (IAM permissions the function runs with).
Click Create function, then upload your code under the Code tab.

Cost note: Lambda has no charge when idle. You pay per request and per millisecond of run time, and the AWS Free Tier includes 1 million free requests per month. An always-on EC2 t3.micro costs roughly $7.50/month whether it is busy or not.

SaaS: Software as a Service

SaaS is finished software you simply log in and use. There is nothing to deploy, patch, or scale. AWS runs the entire stack, including the application itself.

AWS SaaS examples include Amazon WorkMail (managed email and calendar), Amazon WorkDocs (file storage and sharing), and Amazon Chime (meetings). You configure them through a console or admin panel, not by writing code.

When to use it: the software already does what you need (email, chat, CRM) and building it yourself adds no value. When not to: when the product is your core differentiator and you need to control how it behaves.

Who manages what

This is the heart of the decision. The further right you go, the less you operate.

Layer	On-premises	IaaS (EC2)	PaaS (Lambda)	SaaS (WorkMail)
Application	You	You	You	AWS
Runtime / language	You	You	AWS	AWS
Operating system	You	You	AWS	AWS
Virtualization	You	AWS	AWS	AWS
Servers / storage	You	AWS	AWS	AWS
Networking hardware	You	AWS	AWS	AWS
Data center / power	You	AWS	AWS	AWS

The model dictates your day-to-day work. With IaaS you have an operations burden (patching, scaling, monitoring the OS). With PaaS that burden mostly disappears. With SaaS there is no operations work at all.

Gotcha: more managed means less control and harder migration. A SaaS or deeply managed PaaS service often uses proprietary APIs and formats. Moving a Lambda + DynamoDB app to another cloud is far harder than moving a plain EC2 + open-source database setup. This is called vendor lock-in. Choose more managed when speed matters most, and lean toward IaaS or portable, open standards when long-term portability matters more.

Best practices

Start with the most managed option that fits your needs; only drop to IaaS when you hit a real limit. Less to operate means fewer ways to get breached or page yourself at 3am.
Match the model to the team. A small team without ops engineers should favor PaaS and SaaS.
Watch for lock-in on critical paths. Keep data in portable formats and isolate provider-specific code behind a thin layer where you can.
Mix models freely. A real app might use Lambda (PaaS) for APIs, EC2 (IaaS) for a legacy service, and WorkMail (SaaS) for email.
Re-check the cost model, not just the price. PaaS that scales to zero can be cheaper than an idle IaaS server, but a busy PaaS workload can cost more than a reserved instance.
Use the Free Tier to prototype each model before committing.