The Cloud's Shared Responsibility Model

Why it exists

When moving from an on-premises datacenter where you control everything to the cloud, it's easy to get confused about who is responsible for what. The Shared Responsibility Model was created to eliminate this ambiguity. It provides a clear framework that defines which security and management tasks are handled by the cloud provider and which are handled by you, the customer, preventing critical gaps in security.

The mental model

Think of cloud services like real estate. Using IaaS is like leasing an empty plot of land: the provider secures the land, but you have to build the house, install plumbing, and lock the doors. Using PaaS is like renting an unfurnished apartment: the building, power, and plumbing are managed, but you must furnish it and are responsible for who you let inside. SaaS is like a hotel room: nearly everything is managed for you, but you are still responsible for your luggage (data) and your room key (identity).

How it works

The division of responsibility shifts depending on the service model. In an on-premises world, you are responsible for everything. As you move to the cloud, the provider takes on more.

For IaaS (Infrastructure as a Service), the provider manages the physical datacenter, network, and servers. You manage the operating system, middleware, application, and data.

For PaaS (Platform as a Service), the provider adds management of the OS and middleware. You are only responsible for your application and your data.

For SaaS (Software as a Service), the provider manages almost everything. You are primarily responsible for your data within the service and managing user access.

Regardless of the model, you ALWAYS retain responsibility for your data, endpoints (like user laptops), accounts, and access management.

When to use it

This model is not a tool to choose, but a fundamental concept you must understand before deploying anything to the cloud. It's the basis for all cloud security architecture, compliance discussions, and incident response planning. Every cloud engineer must know where the provider's responsibility ends and theirs begins.

When not to use it

The model is always in effect when using a public cloud service. The only scenario where it doesn't apply is in a fully on-premises, self-hosted datacenter, where you are explicitly responsible for the entire stack, from the physical security of the building to the data in your applications.

One canonical example

A team deploys a web app on an Azure Virtual Machine (IaaS). Azure is responsible for securing the physical server and ensuring the hypervisor is patched. The team, however, is responsible for patching the guest operating system (e.g., Windows Server), securing their application code against SQL injection, configuring the virtual network firewall rules, and managing who has administrative access to the VM. If the team fails to patch a known vulnerability in the OS, any resulting breach is their responsibility, not Azure's.