LFCA 72 🐧 IaaS, PaaS, and SaaS Explained - KandZ

The previous chapter introduced cloud computing and the NIST definition with its five essential characteristics. This chapter goes deeper into the three service models that definition identifies: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). These are the categories that determine what the provider manages, what the consumer manages, and how the cost structure works.

The LFCA exam places this topic under Cloud Computing Fundamentals, which carries 18–20% of the total weight . The competency list includes “Cloud Computing,” “Cost and Budgeting,” and “Performance/Availability” . The service models are the foundation for all three. Knowing which model matches which use case is a practical skill that affects architecture decisions, operating costs, and team responsibilities.

Key point: The three service models describe a spectrum of responsibility. At one end, IaaS gives the consumer the most control and the most responsibility. At the other end, SaaS gives the consumer the least control and the least responsibility. PaaS is the middle. The choice is not about which is better — it is about which boundary matches the team’s skills, the workload’s requirements, and the organization’s constraints.

Why the service models matter

The cloud is not a single product. It is a collection of services at different levels of abstraction. Choosing the wrong level means either paying for management you do not need or taking on management you are not prepared for.

The control problem. A team that needs to install custom kernel modules, configure specific network interfaces, or run software that the platform does not support needs IaaS. A team that wants to write application code and not think about servers needs PaaS. A team that wants to use software, not build it, needs SaaS. The service model determines what is possible.

The skill problem. IaaS requires system administration skills: operating system configuration, patching, security hardening, backup management. PaaS requires application development skills and some platform configuration. SaaS requires only the skills to use the software. A team without system administrators should not choose IaaS for a workload that requires ongoing OS maintenance.

The cost problem. IaaS is billed per resource — per hour of virtual machine time, per gigabyte of storage, per gigabyte of network transfer. PaaS is billed per application instance, sometimes with additional charges for database size or build minutes. SaaS is billed per user per month. The cost structure determines how predictable the bill is and what drives the cost as the workload grows .

The lock-in problem. IaaS is the least locked-in. A virtual machine is a virtual machine; moving from one provider to another is mostly a matter of re-creating the VM image. PaaS is more locked-in because the platform provides services — databases, queues, caches — that the application depends on. SaaS is the most locked-in because the data is in the provider’s system and migrating it may not be practical.

The trade-off. There is no universally correct service model. A startup building a prototype may choose PaaS for speed. The same company, at scale, may migrate to IaaS for cost control. A team with a mature operations practice may prefer IaaS from the start. The right answer depends on the specific workload, the team, and the business constraints.

a. Infrastructure as a Service (IaaS)

IaaS provides the fundamental building blocks: virtual machines, storage volumes, networks, load balancers, and firewalls. The consumer provisions these resources and manages everything from the operating system upward. The provider manages the physical hardware, the hypervisor, and the network fabric .

The NIST definition states that in IaaS, “the consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls)” . This is the boundary: everything above the hypervisor belongs to the consumer.

A typical IaaS provisioning sequence:

# Provision a virtual machine
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.medium \
  --key-name my-key \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0

# Attach a storage volume
aws ec2 create-volume --size 100 --availability-zone us-east-1a
aws ec2 attach-volume --volume-id vol-xxx --instance-id i-xxx --device /dev/sdf

# Configure a load balancer
aws elbv2 create-load-balancer --name my-lb --subnets subnet-xxx subnet-yyy

After provisioning, the consumer logs into the VM and configures the operating system, installs the runtime, deploys the application, sets up monitoring, configures backups, and handles security patches. The provider’s responsibility ends at the hypervisor .

The common IaaS use cases are:

Lift-and-shift migrations. An existing application running on-premises is moved to a virtual machine in the cloud with minimal changes. The application does not know it is running in the cloud. This is the fastest path to cloud adoption for legacy workloads, but it does not take advantage of cloud-native features.

Custom infrastructure. A workload that requires specific kernel configurations, custom network topologies, or software that is not available on a PaaS. IaaS gives the consumer full control over the environment.

Cost-sensitive workloads. A steady-state workload with predictable resource requirements may be cheaper on IaaS than on PaaS because the consumer pays for the resources directly rather than for the platform’s abstraction.

Learning and experimentation. A developer who wants to understand Linux system administration, networking, and cloud infrastructure can provision a VM and experiment without buying hardware.

b. Platform as a Service (PaaS)

PaaS provides a platform for deploying applications. The provider manages the operating system, the runtime, the web server, the database, and the scaling infrastructure. The consumer provides the application code and its configuration. The NIST definition states that in PaaS, the consumer “does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment” .

The workflow is fundamentally different from IaaS. Instead of provisioning a VM and configuring it, the consumer pushes code to the platform:

# Deploy to Heroku (a PaaS)
git push heroku main

# The platform detects the language (Node.js, Python, Ruby, etc.)
# Installs the dependencies
# Configures the runtime
# Starts the application
# Routes traffic to it
# Scales the number of instances

The platform handles:

Operating system — the provider patches and updates it.
Runtime — Node.js, Python, Ruby, Java, Go, or .NET, kept current by the provider.
Web server — requests are routed to the application by the platform.
Database — provisioned and managed through the platform’s add-on system.
Scaling — the number of application instances is adjusted based on load.
Logging and monitoring — the platform collects and displays logs and metrics.
Deployment — the platform builds and releases the application from source.

The common PaaS use cases are:

Web applications and APIs. A team that wants to focus on application logic without managing servers. The platform provides the runtime, the database, and the deployment pipeline. The team writes code and pushes it.

Microservices. Each service is deployed independently to the platform. The platform handles the routing, the scaling, and the health checks. The team manages the service boundaries and the API contracts.

Prototypes and MVPs. The fastest path from code to a running application. The team does not spend time on infrastructure setup. If the prototype succeeds, the team can migrate to IaaS or a different platform later.

Applications with variable load. The platform’s auto-scaling adjusts the number of instances based on demand. The team does not configure scaling policies; the platform does.

One important limitation: PaaS platforms are opinionated. They support specific languages, specific runtimes, and specific deployment patterns. An application that does not fit the platform’s model requires either adaptation or a different service model. The lock-in is higher than IaaS because the application depends on the platform’s services.

c. Software as a Service (SaaS)

SaaS provides a complete application. The consumer does not provision infrastructure, does not deploy code, and does not manage the operating system, runtime, or database. The consumer uses the application through a browser or API. The NIST definition states that in SaaS, the consumer “does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings” .

The workflow is simply logging in:

Open a browser
Navigate to https://mail.google.com
Enter credentials
Use the application

There is no installation, no patching, no server management. The provider handles everything: the hardware, the operating system, the application, the database, the security patches, the feature updates, the uptime. The consumer pays a subscription fee, usually per user per month, and uses the software.

The common SaaS categories are:

Email and collaboration. Gmail, Microsoft 365, Slack, Zoom. The tools that teams use to communicate and coordinate.

Customer relationship management. Salesforce, HubSpot. The tools that sales and support teams use to manage customer interactions.

Project management. Asana, Trello, Jira. The tools that teams use to plan and track work.

Accounting and finance. QuickBooks, Xero. The tools that finance teams use to manage books and invoices.

Human resources. Workday, BambooHR. The tools that HR teams use to manage employees and benefits.

Development tools. GitHub, GitLab, Sentry. The tools that development teams use to manage code, track bugs, and monitor errors.

The common SaaS trade-offs are:

Data ownership. The data lives in the provider’s system. The consumer can export it, but the format may be provider-specific, and the migration to another provider may be difficult.

Customization limits. SaaS applications are designed for the common case. A business process that does not fit the application’s model requires either process change or a different tool.

Vendor dependency. If the provider changes the pricing, the features, or the terms, the consumer has limited recourse. The provider controls the product roadmap.

Security and compliance. The consumer must trust the provider’s security practices. For regulated data, the provider’s certifications — SOC 2, ISO 27001, HIPAA, GDPR — are the evidence that the security controls are in place.

Complete Example Session

This session walks through the same web application deployed on each of the three service models, showing what the consumer manages in each case.

# ============================================
# PART 1: THE APPLICATION
# ============================================

# A simple Node.js application with a database.
# It has a package.json, a server.js, and a database connection.
# The question is: where does it run, and who manages what?

# ============================================
# PART 2: IaaS DEPLOYMENT
# ============================================

# 1. Provision a virtual machine
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.medium \
  --key-name my-key \
  --security-group-ids sg-0123456789

# 2. SSH into the VM
ssh -i my-key.pem ec2-user@<public-ip>

# 3. Install the operating system packages
sudo yum update -y
sudo yum install -y nodejs npm git postgresql-server

# 4. Configure the database
sudo postgresql-setup initdb
sudo systemctl enable postgresql
sudo systemctl start postgresql
sudo -u postgres createuser app
sudo -u postgres createdb appdb

# 5. Clone and deploy the application
git clone https://github.com/example/app.git
cd app
npm install
npm run build

# 6. Configure the process manager
sudo npm install -g pm2
pm2 start server.js --name app
pm2 save
pm2 startup

# 7. Configure the reverse proxy
sudo yum install -y nginx
# Edit /etc/nginx/nginx.conf to proxy to port 3000
sudo systemctl enable nginx
sudo systemctl start nginx

# 8. Configure TLS
sudo yum install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com

# 9. Configure backups
# - Database dumps to S3
# - Log rotation
# - Snapshot schedule

# 10. Monitor
# - CloudWatch for VM metrics
# - Application logs
# - Database logs
# - Uptime checks

# The consumer manages: OS, database, runtime, application, TLS, backups, monitoring.
# The provider manages: hardware, hypervisor, network, storage.

# ============================================
# PART 3: PaaS DEPLOYMENT
# ============================================

# 1. Install the CLI
npm install -g heroku

# 2. Log in
heroku login

# 3. Create the application
heroku create my-app

# 4. Provision the database
heroku addons:create heroku-postgresql:standard-0

# 5. Configure environment variables
heroku config:set NODE_ENV=production
heroku config:set DATABASE_URL=<from the addon>

# 6. Deploy
git push heroku main

# 7. Scale
heroku ps:scale web=2

# The platform manages: OS, database, runtime, TLS, scaling, logging.
# The consumer manages: application code, environment variables, scaling decisions.

# ============================================
# PART 4: SaaS COMPARISON
# ============================================

# If a SaaS application already does what the application does,
# the consumer does not build the application at all.
#
# Example: a project management application.
#
# Instead of:
#   - Building a Node.js app
#   - Provisioning a database
#   - Deploying it
#   - Maintaining it
#
# The consumer subscribes to Asana, Trello, or Jira.
# The provider manages everything.
# The consumer uses the software.

# ============================================
# PART 5: THE RESPONSIBILITY MATRIX
# ============================================

# Layer              | IaaS | PaaS | SaaS
# -------------------|------|------|------
# Application code   | You  | You  | Them
# Application config | You  | You  | You (limited)
# Data               | You  | You  | You
# Runtime            | You  | Them | Them
# Middleware         | You  | Them | Them
# Operating system   | You  | Them | Them
# Virtualization     | Them | Them | Them
# Servers            | Them | Them | Them
# Storage            | Them | Them | Them
# Networking         | Them | Them | Them
# Data center        | Them | Them | Them

# ============================================
# PART 6: THE COST COMPARISON
# ============================================

# IaaS: t3.medium VM = ~$0.04/hour = ~$30/month
#       + storage + network + snapshots
#       + the time of the person managing it

# PaaS: Standard dyno = ~$25-50/month
#       + database addon = ~$50/month
#       + the time of the person deploying the code

# SaaS: Project management tool = ~$10-30/user/month
#       + the time of the people using it

# The comparison is not just the provider bill.
# It includes the labor cost of managing each layer.

# ============================================
# PART 7: THE DECISION FRAMEWORK
# ============================================

# Choose IaaS when:
#   - The application needs OS-level control
#   - The team has system administration skills
#   - The workload is steady and predictable
#   - There is a regulatory requirement for isolation

# Choose PaaS when:
#   - The team wants to focus on application code
#   - The application fits the platform's model
#   - The load is variable and auto-scaling is desired
#   - The speed of deployment matters more than control

# Choose SaaS when:
#   - The application already exists as a service
#   - The business process fits the tool
#   - There is no competitive advantage in building it
#   - The team has no capacity to maintain it

# ============================================
# PART 8: THE SERVERLESS EXTENSION
# ============================================

# Serverless (Function as a Service) is a further refinement of PaaS.
# The consumer provides only functions.
# The provider manages everything else.
# Billing is per invocation, not per instance.
# There is no idle cost.

# AWS Lambda example:
# Upload the function code
# Configure the trigger (HTTP, queue, timer)
# The provider runs the function when triggered
# The consumer pays only for execution time

# This is the logical endpoint of the "less management" spectrum.

# ============================================
# PART 9: THE LFCA EXAM CONTEXT
# ============================================

# The exam tests:
#   - The three service models and their boundaries
#   - The responsibility matrix for each model
#   - The cost implications of each model
#   - The use cases for each model
#   - The relationship between the models and the deployment models

# The exam expects you to know:
#   - What the provider manages in each model
#   - What the consumer manages in each model
#   - Examples of each model
#   - The trade-offs between control and convenience

# ============================================
# PART 10: THE SUMMARY
# ============================================

# IaaS = infrastructure as a service
#   You manage the OS and above.
#   Provider manages hardware and virtualization.

# PaaS = platform as a service
#   You manage the application and data.
#   Provider manages everything below.

# SaaS = software as a service
#   You manage only your data and user settings.
#   Provider manages everything.

# The choice is the boundary of responsibility.
# Match the boundary to the team, the workload, and the constraints.

The ten parts cover the application, IaaS deployment, PaaS deployment, SaaS comparison, the responsibility matrix, cost comparison, the decision framework, serverless, LFCA context, and summary.

Quick Reference

The Service Model Comparison

Aspect	IaaS	PaaS	SaaS
Provider manages	Hardware, network, virtualization	+ OS, runtime, middleware	Everything
Consumer manages	OS, runtime, middleware, app, data	App, data	Data, settings
Examples	EC2, Azure VMs, GCE	Heroku, App Engine, Elastic Beanstalk	Gmail, Salesforce, Office 365
Control	High	Medium	Low
Responsibility	High	Medium	Low
Lock-in	Low	Medium	High

The Responsibility Matrix

Layer	IaaS	PaaS	SaaS
Application code	Consumer	Consumer	Provider
Application config	Consumer	Consumer	Consumer
Data	Consumer	Consumer	Consumer
Runtime	Consumer	Provider	Provider
Middleware	Consumer	Provider	Provider
OS	Consumer	Provider	Provider
Virtualization	Provider	Provider	Provider
Servers	Provider	Provider	Provider
Storage	Provider	Provider	Provider
Networking	Provider	Provider	Provider

The Decision Framework

Question	IaaS	PaaS	SaaS
Need OS control?	✅	❌	❌
Focus on code only?	❌	✅	✅
Need a finished app?	❌	❌	✅
Have sysadmin skills?	Required	Not required	Not required
Variable load?	Manual scaling	Auto scaling	Provider handles
Cost predictability?	Per resource	Per instance	Per user

The Cost Structures

Model	Billing Unit	Predictability
IaaS	Per resource per hour	Variable
PaaS	Per application instance	Moderate
SaaS	Per user per month	High

Best Practices

✅ Do This:

# Match the service model to the team's skills
# No sysadmins → not IaaS                             # ✅

# Match the service model to the workload
# Steady state → IaaS or PaaS
# Variable load → PaaS or serverless                  # ✅

# Use PaaS for prototypes and MVPs
git push heroku main                                  # ✅

# Use SaaS when the tool already exists
# Don't build what you can buy                         # ✅

# Monitor the cost of whatever model you choose
# Set budget alerts in the provider console            # ✅

❌ Don’t Do This:

# Don't choose IaaS without sysadmin capacity
# The OS will not patch itself                         # ❌

# Don't choose PaaS if the application does not fit
# The platform's opinionated model is not optional     # ❌

# Don't assume SaaS is always cheaper
# Per-user pricing grows with the team                 # ❌

# Don't ignore the labor cost of managing a layer
# The bill is not the only cost                        # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
IaaS chosen without skills	Underestimated OS management	Match to team capacity
PaaS chosen with incompatible app	Ignored platform constraints	Test the platform first
SaaS chosen without migration plan	Data locked in provider	Check export options
Cost overrun on IaaS	Resources left running	Monitor usage, set alerts
Scaling issues on IaaS	Manual scaling not configured	Use auto-scaling groups

Real-World Examples

1. IaaS Provisioning

aws ec2 run-instances --image-id ami-xxx --instance-type t3.medium

2. PaaS Deployment

git push heroku main

3. SaaS Login

https://mail.google.com

4. IaaS Storage

aws s3 mb s3://my-bucket

5. PaaS Database

heroku addons:create heroku-postgresql

6. SaaS Subscription

Salesforce: $25/user/month

7. Serverless Function

aws lambda create-function --function-name my-func

8. Container Service

aws ecs create-cluster

9. Managed Database

aws rds create-db-instance --db-instance-class db.t3.micro

10. Monitoring Service

# SaaS: Sentry, Datadog, New Relic

Visual

The Service Model Stack

┌──────────────────────────────────────────────┐
│  THE THREE SERVICE MODELS                    │
│                                              │
│  ┌────────────────────────────────────────┐  │
│  │  SaaS                                  │  │
│  │  Application                           │  │
│  │  (You use it)                          │  │
│  ├────────────────────────────────────────┤  │
│  │  PaaS                                  │  │
│  │  Runtime, Middleware, Database         │  │
│  │  (You provide the app)                 │  │
│  ├────────────────────────────────────────┤  │
│  │  IaaS                                  │  │
│  │  VMs, Storage, Network                 │  │
│  │  (You provide the OS and above)        │  │
│  ├────────────────────────────────────────┤  │
│  │  Physical Infrastructure               │  │
│  │  (Provider)                            │  │
│  └────────────────────────────────────────┘  │
│                                              │
└──────────────────────────────────────────────┘

The Responsibility Matrix

┌──────────────────────────────────────────────┐
│  WHO MANAGES WHAT                            │
│                                              │
│  IaaS:                                       │
│    Provider: ████████████░░░░░░░░           │
│    Consumer: ░░░░░░░░░░░░████████           │
│                                              │
│  PaaS:                                       │
│    Provider: ████████████████████░░░        │
│    Consumer: ░░░░░░░░░░░░░░░░░░░░███        │
│                                              │
│  SaaS:                                       │
│    Provider: ███████████████████████░       │
│    Consumer: ░░░░░░░░░░░░░░░░░░░░░░░█       │
│                                              │
│  More █ = more responsibility                │
│                                              │
└──────────────────────────────────────────────┘

The Decision Flow

┌──────────────────────────────────────────────┐
│  CHOOSING A SERVICE MODEL                    │
│                                              │
│  Does the software already exist as a        │
│  service?                                    │
│    └─ YES → SaaS                             │
│    └─ NO ↓                                   │
│                                              │
│  Does the app fit a platform's model?        │
│    └─ YES → PaaS                             │
│    └─ NO ↓                                   │
│                                              │
│  Does the team have sysadmin skills?         │
│    └─ YES → IaaS                             │
│    └─ NO → Reconsider the team or the app    │
│                                              │
└──────────────────────────────────────────────┘

The Cost and Control Trade-off

┌──────────────────────────────────────────────┐
│  CONTROL vs CONVENIENCE                      │
│                                              │
│  IaaS:  High control, high responsibility    │
│         Low lock-in, variable cost           │
│                                              │
│  PaaS:  Medium control, medium responsibility│
│         Medium lock-in, moderate cost        │
│                                              │
│  SaaS:  Low control, low responsibility      │
│         High lock-in, predictable cost       │
│                                              │
│  There is no "best" — only the right match.  │
│                                              │
└──────────────────────────────────────────────┘

Summary

Item	Value
IaaS	Infrastructure: VMs, storage, network
PaaS	Platform: runtime, middleware, database
SaaS	Software: fully managed application
IaaS consumer manages	OS, runtime, middleware, app, data
PaaS consumer manages	App, data
SaaS consumer manages	Data, user settings
IaaS examples	EC2, Azure VMs, GCE
PaaS examples	Heroku, App Engine, Elastic Beanstalk
SaaS examples	Gmail, Salesforce, Office 365
LFCA weight	Cloud Computing Fundamentals, 18–20%

Key takeaways:

The three service models describe a spectrum of responsibility. IaaS gives the consumer the most control and the most responsibility. SaaS gives the least of both. PaaS sits in the middle. The choice is about which boundary matches the team, the workload, and the constraints .
In IaaS, the consumer manages the operating system and everything above. The provider manages the hardware, the hypervisor, and the network. The consumer patches the OS, installs the runtime, deploys the application, and configures backups .
In PaaS, the consumer manages only the application and its data. The provider manages the OS, the runtime, the middleware, and the database. The consumer pushes code, and the platform handles the rest .
In SaaS, the consumer manages only their data and user settings. The provider manages everything else. The consumer uses the software through a browser or API. No installation, no maintenance, no servers .
The responsibility matrix is the key to understanding the models. Each layer of the stack — application, runtime, OS, virtualization, servers — is managed by either the provider or the consumer. The service model determines where the line is drawn .
The cost structure reflects the responsibility boundary. IaaS is billed per resource, PaaS per instance, SaaS per user. The provider bill is not the only cost — the labor of managing each layer must be included in the comparison.
The right choice depends on the team, the workload, and the constraints. A team without sysadmins should not choose IaaS. An application that does not fit the platform’s model should not choose PaaS. A business process that already exists as a SaaS tool should not be built from scratch.

Remember: IaaS, PaaS, and SaaS are not competing products. They are different boundaries of responsibility in the same stack. The provider manages from the bottom up. The consumer manages from the top down. The service model determines where the line is drawn. Choose the model that matches the team’s skills, the workload’s requirements, and the organization’s constraints. The LFCA exam tests the boundaries, the examples, and the trade-offs. Understand the responsibility matrix, and the rest follows.

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!