1.1 Cloud Service Models & Shared Responsibility

Cloud Service Models & Shared Responsibility

Cloud computing fundamentally transforms traditional IT operations by abstracting physical infrastructure into scalable, software-defined resources delivered over a network. According to the National Institute of Standards and Technology (NIST SP 800-145), cloud computing is defined by five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.

For enterprise architects and candidates preparing for the CompTIA Cloud+ (CV0-004) examination, mastering the architectural tiers of cloud service models and their underlying operational boundaries is critical. Every architectural decision—from workload migration to compliance enforcement—hinges on knowing exactly where the Cloud Service Provider's (CSP) operational boundary ends and the cloud tenant's responsibility begins.

---

1. Core Cloud Service Models

Cloud computing abstracts infrastructure across different layers of the technology stack. The industry categorizes these abstractions into three primary models—IaaS, PaaS, and SaaS—alongside modern paradigms such as FaaS (Serverless) and specialized XaaS variants.

+-----------------------------------------------------------------------------------------+
|                         CLOUD SERVICE MODEL ABSTRACTION STACK                           |
|                                                                                         |
|   Layer / Component        On-Premises       IaaS           PaaS           SaaS         |
|   +-----------------------+--------------+--------------+--------------+--------------+ |
|   | Applications          | Customer     | Customer     | Customer     | CSP Managed  | |
|   | Data & Access (IAM)   | Customer     | Customer     | Customer     | Customer     | |
|   | Runtime & Frameworks  | Customer     | Customer     | CSP Managed  | CSP Managed  | |
|   | Middleware & DB Engine| Customer     | Customer     | CSP Managed  | CSP Managed  | |
|   | Operating System (OS) | Customer     | Customer     | CSP Managed  | CSP Managed  | |
|   +-----------------------+--------------+--------------+--------------+--------------+ |
|   | Virtualization Layer  | Customer     | CSP Managed  | CSP Managed  | CSP Managed  | |
|   | Physical Servers      | Customer     | CSP Managed  | CSP Managed  | CSP Managed  | |
|   | Physical Storage      | Customer     | CSP Managed  | CSP Managed  | CSP Managed  | |
|   | Physical Data Center  | Customer     | CSP Managed  | CSP Managed  | CSP Managed  | |
|   +-----------------------+--------------+--------------+--------------+--------------+ |
+-----------------------------------------------------------------------------------------+

Infrastructure as a Service (IaaS)

Infrastructure as a Service (IaaS) provides the lowest level of cloud abstraction, delivering raw, virtualized computing resources over the internet. The CSP owns and operates the physical data centers, cooling, physical network switches, host servers, and hypervisors. The cloud tenant receives access to virtual machines (VMs), virtual private networks (VPCs/VNets), block storage volumes, and virtual firewalls.

• Tenant Responsibilities: The tenant must install, configure, secure, and patch the guest Operating System (Windows/Linux), configure network routing tables and firewall rules (Security Groups, Network ACLs), install runtimes, manage middleware (e.g., Apache, IIS, Nginx), deploy applications, and manage user identities and data backups.
• Architectural Trade-offs: IaaS offers maximum architectural flexibility, total control over OS kernel settings, and easy lift-and-shift migration for legacy monolithic applications. However, it demands the highest operational overhead, requiring dedicated systems administration, continuous OS patch management, and manual configuration of high-availability clustering.

Platform as a Service (PaaS)

Platform as a Service (PaaS) abstracts away the underlying operating system, server hardware, virtualization layer, and middleware. The CSP provides a fully managed execution environment containing pre-configured runtimes (Node.js, Python, Java, .NET), managed web servers, and managed database engines (e.g., Amazon Aurora, Azure SQL Database, Google Cloud SQL).

• Tenant Responsibilities: The customer is strictly responsible for authoring application source code, designing database schemas, writing queries, configuring application-level environment variables, and establishing role-based access control (RBAC).
• Architectural Trade-offs: PaaS dramatically accelerates development velocity, enables automated horizontal scaling, eliminates OS patching and hypervisor maintenance, and integrates seamlessly with Continuous Integration / Continuous Delivery (CI/CD) pipelines. The trade-off is reduced granular control: tenants cannot modify OS registry settings, install custom kernel drivers, or access underlying system logs directly.

Software as a Service (SaaS)

Software as a Service (SaaS) provides a complete, turnkey application hosted and managed entirely by the CSP. End users interact with the application through a web browser, thin client, or mobile app (e.g., Microsoft 365, Salesforce, Google Workspace, ServiceNow).

• Tenant Responsibilities: The customer manages zero infrastructure, zero runtimes, and zero codebases. Tenant administration is strictly limited to user provisioning, Identity and Access Management (IAM), Multi-Factor Authentication (MFA) enforcement, Data Loss Prevention (DLP) policies, and data classification.
• Architectural Trade-offs: SaaS offers minimal operational overhead and instant global deployment. However, it locks organizations into the vendor's feature roadmap, limits customization, and introduces data sovereignty and API integration challenges.

Function as a Service (FaaS) / Serverless Computing

Function as a Service (FaaS) represents the pinnacle of compute abstraction. Developers author discrete, stateless functions triggered by asynchronous events (HTTP requests, database table updates, message queue items, or object storage file uploads). Examples include AWS Lambda, Azure Functions, and Google Cloud Functions.

• Key Characteristics:
  • Zero Server Management: Tenants never provision, patch, or scale virtual servers or container clusters.
  • Dynamic Event-Driven Scaling: The cloud platform automatically scales execution from zero instances up to thousands of concurrent function invocations within milliseconds.
  • Sub-Second Micro-Billing: Consumers are billed exclusively for the precise compute execution duration (measured in milliseconds) and memory consumed. Idle functions incur zero cost.
  • Statelessness and Ephemeral Storage: Execution containers are spun up on-demand and discarded after execution. Persistent state must be stored in external managed databases or object storage.
  • Cold Start Latency: When a function is invoked after a period of dormancy, the CSP must instantiate a new underlying micro-container runtime, introducing a brief execution delay known as a cold start.

Anything as a Service (XaaS) Extensions

Modern cloud architectures extend the as-a-Service taxonomy to specialized domains:

• Desktop as a Service (DaaS): Cloud-hosted virtual desktop infrastructure (VDI) streamed to thin clients (e.g., AWS WorkSpaces, Azure Virtual Desktop).
• Database as a Service (DBaaS): Fully managed, auto-scaling relational and NoSQL database engines with automated backups and replication (e.g., AWS DynamoDB, Azure Cosmos DB, Google Cloud Spanner).
• Storage as a Service (STaaS): Highly durable, globally accessible block, file, and object storage tiers (e.g., AWS S3, Azure Blob, Google Cloud Storage).
• Security as a Service (SECaaS): Cloud-delivered cybersecurity capabilities, including Cloud Access Security Brokers (CASB), Web Application Firewalls (WAF), and Distributed Denial of Service (DDoS) mitigation (e.g., Cloudflare, Zscaler, AWS Shield).

---

2. The Cloud Shared Responsibility Model

The Shared Responsibility Model is the foundational governance framework of cloud security. It explicitly delineates the security obligations of the Cloud Service Provider versus those of the Cloud Customer (Tenant).

A fundamental axiom of cloud architecture is:

The CSP is responsible for security OF the cloud, while the Customer is responsible for security IN the cloud.

+-----------------------------------------------------------------------------------------+
|                        SHARED RESPONSIBILITY DETAILED BREAKDOWN                         |
|                                                                                         |
|   Responsibility Tier            On-Premises    IaaS          PaaS          SaaS        |
|   +----------------------------+--------------+-------------+-------------+-----------+ |
|   | Customer Data & Content    | CUSTOMER     | CUSTOMER    | CUSTOMER    | CUSTOMER  | |
|   | Identity & Access (IAM)    | CUSTOMER     | CUSTOMER    | CUSTOMER    | CUSTOMER  | |
|   | Endpoint & Client Devices  | CUSTOMER     | CUSTOMER    | CUSTOMER    | CUSTOMER  | |
|   | Application Logic & APIs   | CUSTOMER     | CUSTOMER    | CUSTOMER    | CSP       | |
|   | Database Engine & Schema   | CUSTOMER     | CUSTOMER    | SHARED      | CSP       | |
|   | Operating System & Patches | CUSTOMER     | CUSTOMER    | CSP         | CSP       | |
|   | Network Controls (Firewall)| CUSTOMER     | CUSTOMER    | CSP         | CSP       | |
|   | Hypervisor & Virtualization| CUSTOMER     | CSP         | CSP         | CSP       | |
|   | Physical Host Hardware     | CUSTOMER     | CSP         | CSP         | CSP       | |
|   | Physical Data Center / Env | CUSTOMER     | CSP         | CSP         | CSP       | |
|   +----------------------------+--------------+-------------+-------------+-----------+ |
+-----------------------------------------------------------------------------------------+

Critical CompTIA Cloud+ Exam Traps

1. Data and IAM are ALWAYS Customer Responsibilities: Regardless of whether an organization deploys an IaaS virtual machine, a PaaS database, or a SaaS email suite, the customer is 100% responsible for customer data classification, data encryption, and Identity and Access Management (IAM). If a SaaS database is left accessible without MFA or an S3 bucket is configured with public read permissions, the breach is legally and operationally the customer's fault, not the CSP's.
2. Operating System Patching Shifts with Model: In IaaS, OS security updates (e.g., applying Linux kernel CVE patches or Windows Update packages) are solely the customer's duty. In PaaS and SaaS, the CSP transparently patches and upgrades the underlying OS without customer intervention.
3. Network Configuration Responsibility: In IaaS, the customer must design the IP subnetting, configure route tables, and define stateful Security Group firewall rules. In PaaS, the CSP manages the network ingress infrastructure, though the customer may configure access restriction rules or private endpoints.

---

3. Real-World Multi-Cloud Service Mapping

Enterprise cloud engineers must translate conceptual service models across the major hyperscalers: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).

---

4. Multi-Tenancy, Single-Tenancy & Isolation Architectures

Cloud computing achieves massive economies of scale through multi-tenancy—the architectural practice of serving multiple independent customers (tenants) from a shared pool of physical compute, storage, and networking hardware.

+-----------------------------------------------------------------------------------------+
|                       MULTI-TENANCY VS SINGLE-TENANCY COMPARISON                        |
|                                                                                         |
|   MULTI-TENANT ARCHITECTURE (Standard Cloud)    SINGLE-TENANT (Dedicated Host / Private)|
|   +---------------------------------------+     +-------------------------------------+ |
|   | Tenant A VM  | Tenant B VM  | Tenant C|     | Tenant A - Web VM | Tenant A - DB VM| |
|   +---------------------------------------+     +-------------------------------------+ |
|   |   Hypervisor Logical Isolation Layer  |     |   Hypervisor Logical Isolation Layer| |
|   +---------------------------------------+     +-------------------------------------+ |
|   |   Shared Physical Host Hardware       |     |   Dedicated Physical Host Hardware  | |
|   |   (Shared CPU, RAM, NIC, Bus)         |     |   (Dedicated to Tenant A ONLY)      | |
|   +---------------------------------------+     +-------------------------------------+ |
+-----------------------------------------------------------------------------------------+

The Noisy Neighbor Phenomenon

In standard multi-tenant environments, a tenant shares physical CPUs, memory buses, and network interface cards (NICs) with workloads owned by other organizations. If Tenant B launches an unoptimized batch analytics job or experiences a massive traffic spike, it can saturate the shared physical CPU cache or network bus, degrading the performance of Tenant A's latency-critical application. This condition is known as the noisy neighbor problem.

Architectural Mitigations for Noisy Neighbors:

• Dedicated Instances: Virtual machines running on hardware dedicated to a single customer account, isolated at the host level from other customers, though sharing hardware with the same account's other VMs.
• Dedicated Hosts: Physical bare-metal servers assigned entirely to a single tenant. The tenant gains full visibility into socket and core allocations, satisfying strict licensing requirements (Bring Your Own License - BYOL) and preventing any cross-tenant co-location.
• Quality of Service (QoS) & IOPS Provisioning: Utilizing cloud storage with guaranteed throughput (e.g., AWS Provisioned IOPS io2, Azure Ultra Disk) where storage controllers enforce rate-limiting algorithms to guarantee consistent I/O performance.