Shared responsibility model

The matrices below are the documented customer-versus-provider split. They are not a control catalog or an attestation.

What each vendor actually says

AWS uses the phrases security of the cloud and security in the cloud. Of the cloud is facilities, hardware, network, and the virtualization layer AWS operates. In the cloud is guest OS patching on EC2, application software, and the security-group firewall you configure. AWS tells you to pick services carefully because the split changes. S3 still leaves you encryption settings and access policies even though you never patch a disk.

Azure publishes a matrix by on-premises, IaaS, PaaS, and SaaS. Microsoft’s page is blunt: for every cloud deployment type you own your data and identities. You also own the cloud components you control, and that set shrinks as you move toward SaaS. IaaS still means you configure the full network security stack on the virtual network. PaaS moves more network baseline to Microsoft. You still configure application-level controls.

Google Cloud documents the same IaaS-to-SaaS slide in its security overview: you secure what you bring, Google secures the infrastructure. The Architecture Center adds shared fate: Google’s view that listing responsibilities is not enough, and that landing-zone defaults and recommended controls should make the secure path easier. Shared fate is Google’s framing. It does not move legal accountability for your data off your ledger.

Alibaba Cloud’s Well-Architected security page uses the same of/in language. Alibaba Cloud is responsible for physical sites, devices, virtualization, and the Feitian platform layer. You are responsible for service configuration, workload security, and using the security capabilities the platform offers. ECS-specific docs repeat that OS patches and security groups on the instance are yours.

Prove a control is yours

Identity is always on your side of the line. On AWS, list the managed policies on a role that production uses:

aws iam list-attached-role-policies --role-name <workload-role>
aws iam get-role-policy --role-name <workload-role> --policy-name <inline-name>

An attached AdministratorAccess policy is a customer configuration defect. AWS did not assign it. Empty output on get-role-policy means there is no inline policy of that name, not that the role is safe.

Azure:

az role assignment list \
  --scope /subscriptions/<subscription-id> \
  --query "[?roleDefinitionName=='Owner'].{principal:principalName,scope:scope}" \
  -o table

Every Owner row is a customer choice at that scope. Azure RBAC data is global, which Microsoft documents as a replication property, not as a reason to grant Owner widely.

Google Cloud:

gcloud projects get-iam-policy PROJECT_ID \
  --format="table(bindings.role,bindings.members)"

roles/owner on a user email is your allow policy. Inheritance from a folder can add bindings you will miss if you only read the project.

Risks and limitations

The model is a diagram, not a ticket queue. A managed service can still be misconfigured: public buckets, open security groups, disabled disk encryption, logging sinks that never existed. Those sit on your side even when the hypervisor does not.

Compliance reports (SOC, ISO) describe provider controls. They do not attest your IAM. Mapping a control to “the cloud vendor” in an audit workbook because the logo is on the page is a process error.

Multi-cloud multiplies the matrices. AWS of/in, Azure IaaS/PaaS/SaaS, Google shared fate, and Alibaba of/in are four documents. A control you inherited on Azure App Service is not inherited on EC2.

Teams that say “the provider is secure” usually skipped encryption keys, identity federation, and backup restores. Those are customer tasks on every matrix above.

For how identity is evaluated on each platform, continue with IAM fundamentals. The production place those controls get enforced is the production landing zone.