Understanding the Shared Responsibility Model
Every major cloud provider operates on a shared responsibility model, a framework that draws a clear line between what the provider is responsible for securing and what the customer is responsible for securing. AWS phrases it as the provider being responsible for “security of the cloud” (the physical infrastructure, hardware, networking, and virtualization layer), while the customer is responsible for “security in the cloud” (how they configure and use the services they consume). Azure and Google Cloud publish nearly identical models under different names.
How Responsibility Shifts by Service Type
- IaaS (e.g., Amazon EC2) – the provider secures the physical data center, host hypervisor, and network infrastructure; the customer is responsible for OS patching, IAM configuration, application-level security, network configuration inside their VPC, and data encryption.
- PaaS (e.g., Amazon RDS, Azure SQL Database) – the provider additionally manages the operating system and database engine patching, backups, and high availability; the customer is still responsible for access control policies, network exposure settings, and data classification.
- SaaS (e.g., Microsoft 365) – the provider manages nearly the entire stack including the application itself; the customer is primarily responsible for user access management, data governance, and configuration of application-level security settings.
Managed Kubernetes services like Amazon EKS add nuance: AWS manages and patches the Kubernetes control plane, but the customer remains responsible for patching worker node operating systems (unless using a fully managed node type like Fargate), securing workload manifests, and configuring RBAC and network policies correctly.
Example Scenario
A widely cited category of data breach involves an Amazon S3 bucket left publicly accessible. AWS fully secures the underlying S3 storage infrastructure against physical or hypervisor-level compromise, that part of the model is entirely on AWS. But whether a specific bucket’s access policy is public or private is a configuration decision made by the customer, squarely within “security in the cloud.” When such a bucket leaks sensitive data, the root cause is customer misconfiguration, not a failure of AWS’s infrastructure security, illustrating exactly where the responsibility line falls.
Why the Model Matters
The shared responsibility model clarifies audit and compliance boundaries: when a regulator or auditor asks who is accountable for a specific control, the model provides an authoritative answer for cloud-native services. It also directly shapes security architecture and incident response planning, since teams need to know in advance which parts of an incident fall to their own team to remediate versus which parts require opening a support case with the provider.
Trade-offs and Common Pitfalls
The most common failure is assuming the provider secures everything simply because the infrastructure is “in the cloud,” when in practice the customer side of the line, encompassing IAM policies, encryption settings, network exposure, and patching, is often the larger attack surface. Despite the model being well documented, misconfiguration remains consistently cited as the leading cause of cloud security incidents. The split for managed services like Kubernetes or serverless platforms is also frequently misunderstood, with teams unclear on exactly where control plane responsibility ends and workload responsibility begins.
Best Practices
- Explicitly map each cloud service in use to its specific responsibility split rather than assuming a single blanket policy applies across IaaS, PaaS, and SaaS.
- Use provider-native posture management tools, such as AWS Security Hub, AWS Config, or Microsoft Defender for Cloud, to continuously detect customer-side misconfigurations.
- Train engineering teams explicitly on their side of the responsibility line, not just security teams, since developers make the day-to-day configuration decisions that determine outcomes.
- Revisit the mapping whenever adopting a new managed service, since the responsibility split shifts meaningfully between IaaS, PaaS, and SaaS.
Frequently Asked Questions
What is Shared Responsibility Model?
The shared responsibility model defines which security tasks the cloud provider handles versus which ones the customer must handle, generally splitting 'security of the cloud' from 'security in the cloud.'
How does Shared Responsibility Model work?
Shared Responsibility Model works by combining the components described in the sections above. The main page walks through the architecture, the typical use cases, and the trade-offs to weigh before adopting it.
Why does Shared Responsibility Model matter?
Teams adopt Shared Responsibility Model to ship faster, run more reliably, and reduce the cognitive load on engineers. The benefits, limits, and adjacent tools are covered in the body above.
When should you use Shared Responsibility Model?
Use Shared Responsibility Model when the problems it solves match what your team is hitting today. The page above outlines the signals that mean you should adopt it now, and the cases where a simpler approach is fine.
