Shared Responsibility Model

The shared responsibility model describes which security and operational duties belong to a cloud provider and which remain with the customer. AWS states the principle compactly — “security and compliance is a shared responsibility between AWS and the customer” — with the provider “responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud.” Descriptions here follow the AWS and Microsoft documentation, checked in September 2026.

The sentence that actually matters for planning is the next one: “customer responsibility will be determined by the AWS Cloud services that a customer selects.” There is no single boundary. Each service draws its own, which is why the model is a question to ask per service rather than a diagram to read once.

Duties that do not divide in two

Discussions treat this as a split. It is more accurately a three-way sort, and the middle category is where mistakes live.

• Transferred. The provider does it and you cannot. Physical datacenter security, the hypervisor, the physical network — in Microsoft’s matrix, physical hosts, physical network, and physical datacenter belong to the provider from IaaS upward.
• Shared. Both parties hold a part, and assuming otherwise leaves a gap. Patch management is the canonical example: “AWS is responsible for patching and fixing flaws within the infrastructure, but customers are responsible for patching their guest OS and applications.”
• Always retained. Yours at every service level. Microsoft lists them as data (including “data classification, data protection, encryption decisions”), endpoints, accounts, and access management — “role-based access control (RBAC), multifactor authentication, and conditional access policies.”

The retained list is short and it is the one to internalize, because it does not shrink as you move up the stack. A fully managed database still leaves you the data, its classification, who may reach it, and how they authenticate.

How the line moves between service types

The clearest illustration is the same provider’s description of two of its own services. Running virtual machines, the customer handles “management of the guest operating system (including updates and security patches), any application software or utilities installed by the customer on the instances, and the configuration of the AWS-provided firewall.”

Using an object store or managed database instead, “AWS operates the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data” — and the customer’s work becomes “managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions.”

Microsoft’s matrix generalizes it by row: the operating system is the customer’s through IaaS and the provider’s at PaaS and SaaS; network controls are the customer’s at IaaS, shared at PaaS, the provider’s at SaaS; and customer data, configurations and settings, and identities and users are the customer’s in every column, including on-premises.

The failure this model predicts

Nearly every publicized cloud data exposure sits in the retained rows rather than the transferred ones: a storage bucket left open, an over-permissive role, a credential in a repository, a default password unchanged. The provider’s infrastructure worked exactly as documented.

The mechanism is a reasonable inference drawn one step too far. A migration removes real work — patching, capacity, hardware failure — and the relief is genuine. The inference that security in general has moved is not, and it is easiest to make when nobody wrote down which rows changed.

So the practice worth adopting is unglamorous: for each service you adopt, record in the design document which duties moved and which did not. One line per service. The rows that stay yours then become a permanent operational list — access reviews, key rotation, configuration drift — rather than a discovery made during an audit. Least privilege is the principle those reviews apply, and it belongs to you at every level of managed service.

What the model is not

The model has limits worth stating. It is a governance description rather than a contract: Microsoft’s own page notes it uses “responsibility” in a governance sense — who configures, operates, and monitors each control — and that it “is not intended to convey legal conclusions or to modify or contradict the terms of any agreement.” What you owe a regulator or a customer comes from your obligations and your agreements, not from a diagram.

And it says nothing about where data may physically sit, which is a separate constraint covered by data residency. A provider can be fully responsible for the infrastructure while running it in a jurisdiction your obligations do not permit.

How the boundary interacts with the choice between virtual machines, containers, and serverless is worked through in You Rented the Server, Not the Outcome.

References: AWS, Shared Responsibility Model; Microsoft Learn, Shared responsibility in the cloud (documentation updated 2026-08-24).