Lesson 008 · AWS Learning Path

AWS 008: IaaS, PaaS and SaaS

Anil Jalela · Published Jul 3, 2025 · 7 min read

The architecture problem

Three teams need a database-backed web application:

• Team A needs operating-system control for a licensed legacy component.
• Team B wants to deploy its own application but does not want to patch servers or a database engine.
• Team C only needs finished collaboration software and does not develop the application.

All three teams can use cloud services, but they should not receive the same service model. The service model determines which capability the provider supplies and which layers the customer must operate.

What you will be able to do

By the end of this lesson, you can:

1. distinguish Infrastructure as a Service, Platform as a Service, and Software as a Service;
2. map provider and customer responsibilities across a technology stack;
3. explain how control, operational effort, and configuration responsibility change;
4. avoid classifying a service by marketing language alone;
5. select a service model from requirements.

Start with the stack

Use this simplified stack:

Business process and users
Data and information classification
Application
Runtime and middleware
Operating system
Virtualization or resource abstraction
Servers and storage hardware
Networking and facilities

Identity, security configuration, monitoring, recovery, cost, and compliance cross several layers. They do not disappear in any model.

Infrastructure as a Service, IaaS

IaaS provides fundamental compute, storage, and networking capability. The customer can deploy operating systems and applications without owning the provider's physical infrastructure.

Typical customer responsibilities include:

• selecting and configuring the virtual machine;
• guest operating-system administration and patching;
• middleware and runtime;
• application deployment;
• data classification and protection;
• identity and network configuration;
• backup and recovery configuration;
• monitoring and cost control.

Typical provider responsibilities include:

• physical facilities;
• power and cooling;
• physical servers and storage;
• foundational networking;
• the virtualization or resource-abstraction layer.

Amazon EC2, Amazon EBS, and Amazon VPC provide important IaaS-style building blocks. Their exact responsibility boundaries are service-specific.

Choose IaaS when you need control that a higher-level platform does not expose, such as a particular operating-system configuration, agent, kernel-related capability, or legacy software requirement.

Do not choose IaaS merely because it feels familiar. Greater control also creates more patching, hardening, backup, monitoring, scaling, and recovery work.

Platform as a Service, PaaS

PaaS provides a platform on which the customer deploys or runs applications. The provider operates more of the underlying runtime, middleware, operating system, and infrastructure.

Typical customer responsibilities include:

• application code and dependencies permitted by the platform;
• application configuration;
• data and data classification;
• user and service access;
• secure use of platform features;
• observability and recovery choices exposed by the platform;
• cost and scaling policy.

Typical provider responsibilities include more of:

• runtime or managed engine operation;
• operating-system administration;
• platform patching;
• underlying infrastructure.

Managed database services, application platforms, container platforms, and serverless services can reduce undifferentiated operations, but do not all expose the same boundary. For example:

• a managed database can patch and operate the database infrastructure while the customer still designs schemas, controls access, protects data, selects backup settings, and tests recovery;
• a serverless compute service can remove server administration while the customer still owns code, dependencies, permissions, input validation, concurrency behavior, observability, and cost.

PaaS is not "AWS manages everything."

Software as a Service, SaaS

SaaS provides a finished application for consumers to use. Users commonly access it through a browser, mobile client, or application interface.

The provider operates the application and its supporting platform and infrastructure. The customer still has responsibilities such as:

• deciding whether the service is suitable;
• configuring the tenant;
• managing users, roles, and access;
• classifying entered or uploaded data;
• configuring retention, sharing, and security options;
• integrating the service safely;
• meeting legal and business requirements;
• managing subscription use and cost.

SaaS reduces application operation. It does not eliminate governance.

Responsibility comparison

This is a learning model. Always verify the exact AWS service documentation and agreement.

The word "mostly" is deliberate. Product boundaries vary, and customers still configure platform behavior.

Control and operational effort

More customer control
On premises -> IaaS -> PaaS -> SaaS

More provider-managed layers
On premises <- IaaS <- PaaS <- SaaS

Moving right can:

• reduce infrastructure operation;
• speed delivery;
• standardize common controls;
• constrain low-level customization;
• change portability and integration options;
• change pricing dimensions;
• require different skills.

Neither end is universally better.

Practical exercise: classify the required capability

Create:

mkdir -p "$HOME/nitwings-aws/evidence/aws-008"

Create:

$HOME/nitwings-aws/evidence/aws-008/service-model-decisions.md

For each scenario, choose IaaS, PaaS, SaaS, or "requirements insufficient."

Scenario 1

A vendor requires a supported Linux distribution, root-level installation, a kernel module, and a fixed agent.

Expected direction: IaaS, because the workload needs guest operating-system control. Confirm that the requested kernel feature is supported.

Scenario 2

A development team owns application code but wants the provider to operate servers, runtime patching, and automatic platform scaling.

Expected direction: PaaS-style managed application platform or serverless service, after checking runtime, scaling, networking, deployment, and portability requirements.

Scenario 3

A small business needs email and document collaboration. It has no application development requirement.

Expected direction: SaaS, subject to identity, data, retention, integration, availability, and compliance evaluation.

Scenario 4

A database team wants to control schema, queries, indexes, users, backups, and recovery settings but does not want to patch the database host operating system.

Expected direction: managed database platform, commonly treated as PaaS. The customer retains important database and data responsibilities.

Scenario 5

A manager says, "Use SaaS because it is cheaper."

Expected direction: requirements insufficient. Cost alone does not establish functional fit, data control, integration, security, compliance, or exit requirements.

For each answer, include:

• required customer control;
• provider-managed layers desired;
• customer responsibilities that remain;
• one rejected alternative;
• one question that could change the answer.

Service labels are less important than the actual boundary

AWS includes infrastructure, managed, serverless, and application services. Some products do not fit a classroom category perfectly.

Use these questions:

1. What capability does the service deliver?
2. Which layers can the customer configure?
3. Which layers does AWS operate and patch?
4. Who controls identities and data?
5. Who defines backup and recovery?
6. Who monitors application health?
7. Which failures can the customer remediate?
8. What is the exit or migration path?

An exam scenario normally tests these consequences, even when it uses a service name.

Shared responsibility changes, accountability does not

Suppose a PaaS service patches its platform. The customer may still be responsible for:

• choosing a supported runtime;
• updating application dependencies;
• responding to deprecation notices;
• testing after a platform update;
• controlling deployment;
• protecting data and secrets;
• setting permissions;
• verifying recovery.

Provider management reduces tasks. It does not make the customer unaccountable for the workload.

Common misconceptions

Check your understanding

1. Who patches the guest OS on an ordinary EC2 instance?
2. Who classifies data stored in a managed database?
3. Does SaaS remove the need to manage users?
4. Why might a legacy application require IaaS?
5. Why is "managed service" not a sufficient responsibility description?

Expected answers

1. The customer.
2. The customer.
3. No.
4. It may need operating-system, agent, runtime, networking, or installation control that a platform does not expose.
5. Each service manages a different set of layers and exposes different configuration, recovery, security, and operational responsibilities.

Architecture decision points

Choose the highest-level managed service that satisfies the workload requirements and team capabilities, but verify:

• required control;
• supported runtime or software;
• security and data boundaries;
• recovery and availability needs;
• performance behavior;
• integration and network access;
• portability and exit;
• operational skills;
• pricing dimensions.

Do not maximize management abstraction when it breaks a real requirement. Do not maximize control when the team cannot operate it safely.

Completion gate

You pass AWS 008 when:

• all five scenarios have a defensible classification;
• each decision identifies remaining customer responsibilities;
• you can map the simplified stack across IaaS, PaaS, and SaaS;
• you can explain one reason to choose and one reason to reject each model;
• no AWS resource was created.

Retain service-model-decisions.md for the three-tier architecture in AWS 022.

Official sources

• NIST SP 800-145, The NIST Definition of Cloud Computing
• NIST SP 500-322, Evaluation of Cloud Computing Services
• AWS shared responsibility model
• AWS compute services overview
• AWS overview: What is cloud computing?