The shared responsibility model cloud providers publish is a contract about who secures what: the provider secures the infrastructure ("security of the cloud"), and you secure everything you configure, deploy, and store on it ("security in the cloud"). It sounds simple, and every major provider — AWS, Azure, Google Cloud — states it prominently. Yet misunderstanding of exactly where the line sits is arguably the single most common root cause of cloud incidents. Public object storage buckets, over-permissive IAM roles, unpatched customer-managed VMs: none of these are provider failures. They are customer-side responsibilities that someone assumed were "handled by the cloud."
The one-sentence version, and why it is not enough
AWS phrases it as: AWS is responsible for security of the cloud; the customer is responsible for security in the cloud. Azure and Google Cloud draw the same picture with slightly different labels. The provider runs the physical data centers, the hypervisors, the storage and network hardware, and the managed-service control planes. You own your data, your identities, your configurations, your application code, and — depending on service type — your operating systems and runtimes.
The trouble is that "depending on service type" clause. The boundary is not fixed; it slides with every service you consume. An EC2 instance, an RDS database, a Lambda function, and a SaaS CRM all place the line in different spots, and a real estate of a modern company spans all four at once.
How the line moves: IaaS, PaaS, SaaS
Think of the stack as layers: physical facilities, hardware, virtualization, operating system, runtime/middleware, application, identity, data.
IaaS (e.g., EC2, Azure VMs, GCE). The provider stops at the hypervisor. You own the guest OS — patching it, hardening it, its firewall rules — plus everything above: runtimes, application code, TLS configuration, identities, and data. If a VM is running an unpatched OpenSSH or an outdated web framework, that is your finding, not the provider's.
PaaS / managed services (e.g., RDS, App Service, Cloud Run, managed Kubernetes). The provider takes the OS and often the runtime. You still own the service configuration (is the database publicly reachable? is encryption at rest enabled? who can assume the service role?), your application code, your dependencies, identity, and data. Managed Kubernetes is a classic split-brain case: the provider secures the control plane; worker node hardening, RBAC, network policies, and workload images are yours.
SaaS (e.g., Microsoft 365, Salesforce, GitHub). The provider owns nearly the whole stack. What remains yours is not trivial, though: user and access management, sharing settings, tenant configuration, third-party app grants, and the data itself. Most SaaS breaches trace back to a customer-side identity or an OAuth grant, not a provider compromise.
Always yours, everywhere: data classification, identity and access management, and what your own code does. No service model takes those off your plate.
The zones where teams get burned
Configuration is always customer-side
The provider guarantees that the storage service enforces the access policy you set. It does not guarantee the policy is sane. Publicly listable buckets, security groups open to 0.0.0.0/0, database snapshots shared publicly — the platform executed your instructions faithfully. This category is so dominant that an entire product class (CSPM, cloud security posture management) exists to catch it.
Identity is the new perimeter
The 2019 Capital One breach is the canonical case study: an SSRF flaw in a customer-run application was used to reach the instance metadata service and harvest credentials for an over-privileged IAM role. Every layer the attacker touched — the vulnerable app, the WAF configuration, the role's permissions — sat on the customer side of the model. The lesson is that in cloud, over-permissioned identities convert small application bugs into full data-store access.
Your application and its supply chain never transfer
Nothing in any provider's model covers the code you deploy or the open source it depends on. A vulnerable version of a logging library inside a container on a fully managed platform is exactly as exploitable as on-prem. That is why cloud posture tooling and application-layer scanning are complements, not substitutes: CSPM sees the misconfigured bucket, while software composition analysis sees the vulnerable dependency inside the workload, and DAST sees the injection flaw in the running app. An SCA platform such as Safeguard fits on the customer side of the line — it addresses the part of the model the provider explicitly hands to you.
Patching splits three ways
Provider patches the hypervisor and managed-service internals. You patch guest operating systems on IaaS and, universally, your application dependencies. Container images blur this in people's heads: the provider patches the container service, but the base image and every package inside your image are yours to rebuild.
Shared responsibility vs. "shared fate"
Google Cloud has pushed a refinement it calls shared fate: instead of pointing at the line when things go wrong, the provider leans over it — secure-by-default configurations, opinionated blueprints, guardrails like organization policies, and attestations that help customers hold their side. AWS and Azure have equivalent motions (Well-Architected reviews, secure baselines, Defender recommendations).
This matters practically: defaults have improved (for example, block-public-access settings on new storage buckets), which quietly removes whole classes of historical mistakes. But improved defaults do not change ownership. If you disable a guardrail, the consequences are still yours.
Making the model operational
Reading the diagram is not the same as operating it. Concretely:
- Inventory services, then assign owners per layer. For each cloud service in use, write down who owns configuration, identity, data, and (where applicable) OS/runtime. Unowned layers are where incidents live.
- Encode your side as policy. Use infrastructure-as-code scanning, CSPM rules, and organization-level guardrails (SCPs, Azure Policy, GCP org policies) so the customer side is enforced continuously, not audited annually.
- Treat identity as tier-zero. Least privilege on roles, short-lived credentials, and mandatory MFA close the pathways that turn small bugs into large breaches.
- Cover the application layer explicitly. Dependency scanning, secrets detection, and runtime testing are customer obligations under every model. Build them into CI rather than bolting them onto audits.
- Check the model against your compliance scope. Auditors for SOC 2, ISO 27001, or FedRAMP will expect you to demonstrate your controls and to inherit the provider's via their attestations (SOC reports, FedRAMP authorizations). Knowing which control is inherited versus implemented saves weeks of evidence-gathering.
Reading provider documents critically
Each provider publishes a version of the model, and the details differ enough to matter. AWS's applies per service and is documented in each service's security chapter. Azure's diagram explicitly shows responsibility shifting across on-prem, IaaS, PaaS, and SaaS columns. Google's documentation pairs the model with shared-fate resources. When you adopt a new service — especially newer managed AI or data services — read its specific security documentation rather than assuming the generic diagram applies. Serverless and event-driven services in particular have configuration surfaces (function permissions, event source policies) that the generic picture does not show.
FAQ
What is the shared responsibility model in cloud computing?
It is the division of security duties between a cloud provider and its customer: the provider secures the underlying infrastructure and managed-service internals, while the customer secures their data, identities, configurations, applications, and (on IaaS) guest operating systems.
Who is responsible for a misconfigured storage bucket?
The customer. Providers guarantee the access controls work as configured; setting them correctly is on your side of the line under every major provider's model.
Does the model differ between AWS, Azure, and Google Cloud?
The principle is identical; the details differ per service and per provider. Azure and GCP publish layer-by-layer diagrams across IaaS/PaaS/SaaS, and Google extends the idea with "shared fate." Always check the specific service's security documentation.
Does the provider secure my application dependencies?
No. Application code and open source dependencies are customer responsibility in every service model, including fully managed platforms — which is why dependency scanning and application testing remain necessary in the cloud.