2.2 Cloud Service Models (IaaS, PaaS, SaaS) & Abstraction Layers
Key Takeaways
- The classic SPI tier (IaaS, PaaS, SaaS) represents progressive levels of architectural abstraction and control inversion: consumer control is highest in IaaS and lowest in SaaS, while provider operational management increases inversely.
- Infrastructure as a Service (IaaS) provides virtualized raw compute, storage, and networking; the customer retains full responsibility for the guest operating system, network firewall rules, middleware, runtime, and application layers.
- Platform as a Service (PaaS) abstracts the underlying operating system, server hardware, and runtime maintenance, empowering developers to focus exclusively on application code, logic, and data configurations.
- Function as a Service (FaaS) / Serverless is an event-driven PaaS sub-category characterized by micro-billing per millisecond, zero idle costs, ephemeral execution lifecycles, and complete abstraction of underlying host or container infrastructure.
- The cloud abstraction stack spans seven logical layers (Facility, Hardware, Abstraction, Core Connectivity, Storage, Application, and Data), defining clear technical boundaries where security controls must be injected.
2.2 Cloud Service Models (IaaS, PaaS, SaaS) & Abstraction Layers
Quick Answer: Cloud computing services are grouped into the classic SPI tier: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). As an organization climbs from IaaS to SaaS, architectural abstraction increases, consumer operational overhead plummets, but direct consumer security visibility and control diminish. Function as a Service (FaaS) represents an event-driven serverless evolution of PaaS. Structurally, cloud architecture decomposes into seven logical layers from physical data center facilities up to customer data.
The Classic SPI Tier: Conceptual Overview
The Cloud Security Alliance (CSA) and NIST organize cloud capabilities into three fundamental service models known collectively as the SPI Tier (SaaS, PaaS, IaaS). The foundational law governing cloud architecture is the Principle of Control Inversion:
SERVICE MODEL CONSUMER CONTROL CSP MANAGEMENT EXAMPLE SERVICES
+---------------+ +------------------+ +----------------+ +-------------------+
| SaaS | | MINIMAL CONTROL | | MAXIMUM MGMT | | M365, Salesforce |
| PaaS | | MODERATE CONTROL | | MODERATE MGMT | | App Engine, RDS |
| IaaS | | MAXIMUM CONTROL | | MINIMAL MGMT | | AWS EC2, Azure VM |
+---------------+ +------------------+ +----------------+ +-------------------+
- In IaaS: You rent virtualized infrastructure building blocks. You build and maintain everything from the operating system up.
- In PaaS: You rent an application deployment platform. The provider runs the operating system, database engine, and runtime; you write and execute code.
- In SaaS: You consume a finished software product over a web interface or API. The provider manages the entire application stack; you manage your data and user permissions.
Infrastructure as a Service (IaaS)
In Infrastructure as a Service (IaaS), the Cloud Service Provider delivers raw compute (vCPUs, RAM), persistent block or file storage, and software-defined networking components. The underlying physical servers are partitioned via a hypervisor (such as KVM, Xen, or proprietary systems like AWS Nitro).
The Consumer Scope in IaaS
The customer is granted administrative (root/Administrator) privileges within the virtual instance. The customer is strictly responsible for:
- Selecting, installing, and licensing the guest operating system (e.g., Linux, Windows Server).
- Applying all operating system patches, security hotfixes, and kernel updates.
- Configuring host-based security controls: local firewalls (e.g.,
iptables, Windows Defender Firewall), antivirus, host intrusion detection systems (HIDS), and endpoint detection and response (EDR) agents. - Installing, tuning, and updating application runtimes (e.g., Python, Node.js, JVM), middleware, and web servers (Nginx, Apache).
- Configuring virtual network routing tables, security group ingress/egress rules, subnet allocations, and VPN/direct connect tunnels.
- Managing data storage volumes, filesystem formatting, backup retention schedules, and volume-level encryption keys.
The CSP Scope in IaaS
The provider manages and secures:
- Physical data center facilities, perimeter defenses, environmental controls, and biometric entry systems.
- Physical compute servers, memory modules, server racks, and power delivery.
- Physical network cabling, top-of-rack switches, and core optical backbones.
- The virtualization abstraction layer (the hypervisor) that enforces CPU, memory, and I/O isolation between tenant virtual machines.
[!TIP] IaaS Use Cases: Legacy application lift-and-shift migrations, workloads requiring non-standard kernel extensions or custom operating system configurations, low-level networking appliances (virtual firewalls, routers), and environments demanding strict control over runtime binaries.
Platform as a Service (PaaS)
In Platform as a Service (PaaS), the CSP abstracts away the operating system, hardware, and runtime environment. The provider supplies a pre-configured platform where developers can write, deploy, run, and scale applications without worrying about underlying infrastructure management.
The Consumer Scope in PaaS
The customer has no access to the underlying operating system shell or hypervisor. The customer is responsible for:
- Developing, testing, and securing application source code.
- Validating input and protecting against application-layer vulnerabilities (such as the OWASP Top 10).
- Managing third-party software dependencies, libraries, and language package managers (e.g.,
npm,pip,Maven). - Configuring application-level settings, environment variables, API secrets, and connection strings.
- Designing and maintaining database schemas, queries, and data classification.
- Configuring role-based access control (RBAC) governing which developers can deploy or modify code.
The CSP Scope in PaaS
The provider is responsible for:
- Provisioning, clustering, and maintaining the underlying host servers and operating systems.
- Automatically applying operating system security patches and kernel updates.
- Maintaining, upgrading, and securing the language runtime environment (e.g., patching PHP, Java, or Python runtimes against zero-day exploits).
- Dynamic horizontal auto-scaling and load balancing of application instances.
- Physical hardware reliability, multi-zone database replication, automated snapshotting, and hardware disaster recovery.
[!NOTE] Managed Databases as PaaS: Cloud relational databases (such as Amazon RDS, Azure SQL Database, Google Cloud SQL) are quintessential PaaS examples. The provider manages database engine patching, replication, automated failover, and OS security; the customer manages tables, indexes, SQL query optimization, user accounts, and data encryption.
Function as a Service (FaaS) / Serverless Computing
Function as a Service (FaaS), commonly referred to as Serverless Computing (e.g., AWS Lambda, Google Cloud Functions, Azure Functions), represents a hyper-abstracted, event-driven evolution of the PaaS paradigm.
+-----------------------------------------------------------------------------------+
| TRADITIONAL PaaS / IaaS (Server-Centric) |
| [Virtual Machine / App Container Running 24/7] -> Paying for Idle Time |
+-----------------------------------------------------------------------------------+
vs.
+-----------------------------------------------------------------------------------+
| SERVERLESS / FaaS (Event-Driven) |
| [Event Occurs] -> [MicroVM Boots in Milliseconds] -> [Function Executes Code] |
| -> [Result Returned] -> [MicroVM Immediately Destroyed] |
| Billing calculated strictly per 1ms of execution duration -> ZERO Idle Cost |
+-----------------------------------------------------------------------------------+
Defining Characteristics of FaaS
- Event-Driven Execution: Functions are generally invoked by platform events or direct calls, such as an HTTP request, object-storage event, queue message, or database change. Exact invocation and long-running behavior depends on the service.
- Consumption-Based Billing: Providers commonly bill invocation compute only while code runs, but provisioned concurrency, reserved capacity, storage, networking, logging, and related platform services can still create idle cost. Billing is metered at millisecond increments based on memory allocation and execution time.
- Ephemeral Execution Lifecycle: Functions spin up in stateless micro-containers or microVMs (such as AWS Firecracker), execute in milliseconds or seconds, and terminate. State must be externalized to object stores, caches (Redis), or databases.
- Automated Elasticity: The platform can add or remove concurrent function instances in response to demand, subject to service quotas, concurrency controls, cold starts, and provider scaling behavior.
Unique Security Realities of Serverless (FaaS)
- The Disappearing Network Perimeter: Traditional network perimeter controls (like IP-based security groups or web proxy egress filters) are ineffective because ephemeral function instances receive dynamic, short-lived private IP addresses.
- The Monolithic IAM Role Trap: Because developers frequently become frustrated with granular permission denials in serverless workflows, they often assign a single "wildcard" IAM execution role (
*) to all functions. If one function is compromised via SQL injection or command injection, the attacker inherits full cloud-account control. - Event Data Injection: Attackers can inject malicious payloads through non-standard event sources (e.g., poisoned metadata in an S3 object upload, malformed JSON in a Kafka stream, or crafted headers in an API gateway webhook) that bypass traditional Web Application Firewalls (WAF).
- Third-Party Dependency Vulnerabilities: Serverless codebases heavily utilize external package registries (
npm,pip). A vulnerable third-party package bundled into a function deployment zip package exposes the entire function to remote code execution. - Lack of Host Telemetry: Consumers cannot install traditional endpoint security agents (EDR/HIDS) on the underlying execution host. Security monitoring must rely on distributed application tracing (e.g., OpenTelemetry), API gateway logs, and cloud control plane audit trails.
Software as a Service (SaaS)
In Software as a Service (SaaS), the consumer accesses a complete, turnkey application hosted entirely by the provider. The consumer interacts with the software through a web browser, mobile application, or programmatic REST API.
The Consumer Scope in SaaS
The customer has no control over code, runtimes, operating systems, or infrastructure. The customer's responsibility is confined strictly to:
- Identity and Access Management (IAM): Provisioning and deprovisioning user accounts, enforcing Multi-Factor Authentication (MFA), setting up Single Sign-On (SSO) via SAML/OIDC, and establishing role-based permissions within the application.
- Data Classification and Governance: Determining what sensitivity level of data is permitted to enter the SaaS application, configuring Data Loss Prevention (DLP) sharing restrictions, and monitoring for inappropriate public link sharing.
- Application Configuration: Configuring tenant-level business logic, notification settings, and auditing policies.
- Third-Party Integrations: Managing OAuth authorization grants that allow external third-party add-ons or marketplace plugins to access the SaaS tenant's data.
The CSP Scope in SaaS
The provider manages the entire application stack: source code updates, database integrity, operating system patching, hypervisors, server clusters, network availability, physical facilities, regulatory audits (SOC 2, ISO 27001), and disaster recovery.
The Seven Logical Abstraction Layers
To standardize technical analysis and security control assignment, cloud architecture is conceptualized across seven logical abstraction layers (from bottom physical foundation to top data payload):
+---------------------------------+
| 7. Data Layer |
+---------------------------------+
| 6. Application Layer |
+---------------------------------+
| 5. Storage Layer |
+---------------------------------+
| 4. Core Connectivity Layer |
+---------------------------------+
| 3. Abstraction Layer |
+---------------------------------+
| 2. Hardware Layer |
+---------------------------------+
| 1. Facility Layer |
+---------------------------------+
- Facility Layer: Physical real estate, reinforced concrete structures, perimeter fencing, guard stations, biometric locks, redundant power grids, diesel backup generators, and HVAC environmental chillers.
- Hardware Layer: Physical bare-metal server blades, CPUs, ECC RAM modules, hardware cryptographic accelerators, network interface cards (NICs), physical top-of-rack switches, routers, and fiber cabling.
- Abstraction Layer: Software mechanisms that decouple physical hardware from compute workloads: Type-1 bare-metal hypervisors (KVM, ESXi, Xen), microVM runtimes (Firecracker), container runtimes (
containerd, CRI-O), and storage pooling controllers. - Core Connectivity Layer: Software-Defined Networking (SDN) backplanes, virtual private clouds (VPCs), virtual subnets, overlay routing tables, network address translation (NAT) gateways, and virtual firewall rules (Security Groups).
- Storage Layer: Virtualized storage abstractions: block storage volumes (e.g., AWS EBS, Azure Managed Disks), distributed object storage (AWS S3, Google Cloud Storage), distributed network file systems (NFS, SMB), and storage encryption fabrics.
- Application Layer: Managed software runtimes, web application servers, API gateways, microservice containers, custom business logic code, and third-party software dependencies.
- Data Layer: Structured SQL database schemas, NoSQL document collections, unstructured object payloads, encryption keys, metadata attributes, and customer proprietary records.
Comprehensive Comparison Matrix across Service Models
| Technical Layer | Infrastructure as a Service (IaaS) | Platform as a Service (PaaS) | Function as a Service (FaaS) | Software as a Service (SaaS) |
|---|---|---|---|---|
| 7. Data | Customer manages | Customer manages | Customer manages | Customer manages (via config) |
| 6. Application | Customer installs & patches | Customer writes & secures code | Customer writes function code | Provider manages completely |
| 5. Storage | Customer partitions & formats | Provider manages; customer configures | Provider manages; stateless function | Provider manages completely |
| 4. Connectivity | Customer designs virtual network | Provider manages; customer configures endpoints | Provider manages dynamically | Provider manages completely |
| 3. Abstraction | Provider manages hypervisor | Provider manages runtime & containers | Provider manages microVM lifecycle | Provider manages completely |
| 2. Hardware | Provider manages physical hosts | Provider manages physical hosts | Provider manages physical hosts | Provider manages physical hosts |
| 1. Facility | Provider manages data centers | Provider manages data centers | Provider manages data centers | Provider manages data centers |
| Monitoring Tools | Host EDR, HIDS, Syslog, OS agents | Application logs, APM, API metrics | Distributed tracing, CloudWatch/CloudTrail | SaaS audit logs, CASB/SSPM |
A cloud engineering team is modernizing an internal batch-processing microservice using a commercial Function as a Service (FaaS) serverless platform. During a security architecture assessment, a compliance engineer demands that the team install a standard corporate host-based intrusion detection system (HIDS) and kernel endpoint detection and response (EDR) agent onto the serverless runtime environment to inspect kernel system calls. Why is this compliance requirement technically impossible to fulfill in a FaaS architecture?
An enterprise migrates a mission-critical enterprise database onto an Infrastructure as a Service (IaaS) virtual machine instance. Six months post-deployment, a ransomware actor exploits an unpatched, known vulnerability in the guest operating system kernel, encrypting the database files. The enterprise leadership files a formal breach dispute against the cloud service provider, claiming the provider failed to apply mandatory operating system patches. How is responsibility assigned under the IaaS service model?
A multinational financial enterprise is adopting a commercial Software as a Service (SaaS) enterprise resource planning (ERP) platform. During the vendor governance and onboarding review, the security team is tasked with defining the internal security controls that remain strictly within the customer's operational control. Which set of security controls must the enterprise configure and manage directly in this SaaS deployment?