Cloud Service Models

Cloud service models describe how responsibility for a technology stack is divided between a cloud provider and its customer. The stack includes physical facilities, hardware, virtualization, operating systems, runtimes, applications, and data. Moving toward a more managed service generally transfers more infrastructure operations to the provider, but it does not eliminate customer responsibility for security or correct configuration.

Infrastructure as a Service, or IaaS, provides fundamental resources such as virtual machines, storage, and networking. The provider operates the physical infrastructure and virtualization layer, while the customer manages the guest operating system and installed software. For example, with Amazon EC2, AWS maintains the underlying hosts and hypervisor. The customer patches the instance operating system, updates application dependencies, configures security groups, and manages identities, application security, and data protection.

Platform as a Service, or PaaS, provides a managed environment for deploying applications without directly administering every underlying infrastructure layer. The provider typically operates the operating system and platform components, while the customer controls application code, data, and permitted configuration. Managed databases apply a similar division of responsibility. With standard Amazon RDS deployments, AWS manages the underlying operating system and database software maintenance, while customers manage database users, permissions, schemas, queries, network access, and backup retention settings. Customers must also plan maintenance windows, supported engine versions, and required upgrades; managed maintenance does not mean that every operational decision disappears.

Software as a Service, or SaaS, delivers a complete application that customers use and configure rather than build and operate. The provider manages the application stack, but customers still manage responsibilities such as user access, tenant settings, data classification, and appropriate use. A provider-operated application can still expose sensitive information if a customer grants excessive access or configures sharing incorrectly.

Serverless computing provides another useful abstraction, often described as Function as a Service for function execution. With AWS Lambda, AWS manages the execution infrastructure and underlying operating system. Customers remain responsible for function code, dependencies, execution-role permissions, triggers, secrets, and data handling. For managed runtimes, runtime updates follow Lambda's runtime management settings and support lifecycle. For container-image functions, customers must rebuild and deploy updated images, including updated runtime components and dependencies.

These models involve trade-offs rather than a simple ranking. IaaS offers extensive operating-system control and software flexibility but requires more patching and administration. Managed platforms and serverless services reduce infrastructure work but impose constraints on supported versions, execution environments, configuration, and portability. SaaS removes much application-operation work while offering less control over application implementation. Actual service capabilities and contractual responsibilities matter more than assigning every product a rigid model label.

The AWS shared responsibility model describes AWS as responsible for security of the cloud and customers as responsible for security in the cloud. The boundary shifts with the service: guest operating-system patching belongs to the customer on EC2, but AWS manages the underlying operating systems for standard RDS and Lambda. Data classification, access decisions, and secure customer-controlled configuration remain customer responsibilities across these examples. For exam scenarios and architecture reviews, identify the specific component and service rather than assuming that either party owns all security. Service models also differ from deployment models: public, private, and hybrid cloud describe deployment arrangements, not which stack layers the provider manages.