Cloud Shared Responsibility Model Explained — What AWS, Azure, and GCP Are NOT Responsible For
Cloud Shared Responsibility Model Explained — What AWS, Azure, and GCP Are NOT Responsible For
TLDR: Every major cloud provider — AWS, Azure, and GCP — publishes a shared responsibility model that defines exactly what they're accountable for and what you're accountable for. Almost every cloud breach maps to a customer-side failure, not a provider failure. Understanding where the line sits isn't just useful for security planning — it's the difference between a £300M Capital One breach and a secure environment. Here's the full picture.
What the Shared Responsibility Model Actually Says
The concept is simple: cloud providers are responsible for the security of the cloud. You are responsible for security in the cloud.
What the provider secures: the physical data centres, the hardware that runs your workloads, the network infrastructure connecting those data centres, the hypervisor layer that isolates your virtual machines from other customers, and the managed service internals — the underlying infrastructure of S3, RDS, Lambda.
What you secure: your data, your configurations, your access controls, your applications, your operating systems, your encryption choices, your network topology decisions, your identity and access management. Everything you build, deploy, and configure on top of the provider's infrastructure is yours to secure.
AWS publishes this explicitly at aws.amazon.com/compliance/shared-responsibility-model. Microsoft Azure's version and Google Cloud's version are substantively identical in their division of responsibilities, though GCP adds the concept of "shared fate" — Google's commitment to investing in tools that help customers fulfil their side of the model.
The frustrating reality is that while the model is clearly documented by every provider, it's rarely communicated clearly when companies first onboard. The default assumption that "AWS handles security" is understandable — and almost universally wrong in the ways that matter most.
## Provider vs Customer: The Side-by-Side Breakdown
| Responsibility Area | AWS / Azure / GCP | You |
|---|---|---|
| Physical data centre security | ✅ Provider | — |
| Hardware and network infrastructure | ✅ Provider | — |
| Hypervisor and isolation layer | ✅ Provider | — |
| Managed service availability | ✅ Provider | — |
| Operating system (EC2/VMs) | — | ✅ You |
| Application code and configuration | — | ✅ You |
| IAM users, roles, and policies | — | ✅ You |
| Network security groups and VPC config | — | ✅ You |
| Data encryption at rest | — | ✅ You |
| Data encryption in transit | — | ✅ You |
| S3 bucket access settings | — | ✅ You |
| Database configuration and access | — | ✅ You |
| Secrets and credentials management | — | ✅ You |
| Monitoring, logging, and alerting | — | ✅ You |
| Backup and recovery configuration | — | ✅ You |
Every item in the "You" column is a potential breach vector if misconfigured. Every single one.
How Responsibility Shifts Across IaaS, PaaS, and SaaS
The shared responsibility model isn't static — it shifts depending on which layer of cloud service you're using.
IaaS (Infrastructure as a Service) — EC2 instances, raw virtual machines, Azure VMs, GCP Compute Engine — is where you bear the most responsibility. The provider gives you a virtual machine. You're responsible for the operating system, its patches, its configuration, the applications running on it, and the network controls around it. Full stack, your problem.
PaaS (Platform as a Service) — AWS Lambda, Google App Engine, Azure App Service, managed databases like RDS or Cloud SQL — the provider takes on more. They manage the underlying runtime, the operating system patches, and the platform infrastructure. You're responsible for your application code, your data, and your access controls. The OS patching burden disappears; the application security burden doesn't.
SaaS (Software as a Service) — Salesforce, Google Workspace, Microsoft 365 — the provider manages almost everything at the infrastructure layer. Your responsibilities narrow to: user access management (who has access to what), data governance (what data is stored and where), and configuration security (are sharing settings, external access, and admin controls configured correctly).
The shift towards PaaS and SaaS doesn't reduce the importance of the shared responsibility model — it changes which specific controls you need to own. Salesforce misconfigurations that expose customer data to the wrong internal users are a customer responsibility, not Salesforce's.
The Grey Areas Where Most Breaches Actually Happen
The model is clean on paper. In practice, several areas sit in a grey zone where customer responsibilities are frequently misunderstood.
Managed databases (RDS, Cloud SQL). The provider patches the database engine. You control who has access to the database, what network rules govern its exposure, whether it's publicly accessible, and what data is stored in it. An RDS instance exposed to 0.0.0.0/0 on port 3306 with a weak password is entirely your responsibility — the managed service is working as designed.
Serverless functions (Lambda, Cloud Functions). The provider manages the execution environment. You control the IAM permissions granted to the function, the environment variables it has access to (including any secrets), and the application code it executes. An over-permissioned Lambda with an exploitable code vulnerability is a customer-side failure in two distinct ways.
CDN and edge services (CloudFront, Azure CDN). The provider operates the distribution network. Misconfigured cache settings that serve one user's authenticated content to another, or CORS misconfigurations that permit unintended cross-origin requests, are configuration decisions you made.
Shared responsibility for encryption. The provider offers encryption. You decide whether to use it, which keys to use, and who has access to those keys. An unencrypted S3 bucket or RDS instance isn't a provider failure — encryption is available, you just haven't enabled it.
Real Breach Examples Mapped to Responsibility Failures
Capital One, 2019 — a misconfigured WAF allowed an attacker to perform SSRF and obtain credentials for an IAM role. That role had excessive permissions to S3 buckets containing 100M+ customer records. The WAF misconfiguration was customer-side. The excessive IAM permissions were customer-side. AWS infrastructure functioned correctly throughout. Provider responsibility: zero.
Twitch, 2021 — a misconfigured internal GitLab instance exposed source code, internal tooling, and creator payment data. The exposure was a configuration decision, not a platform failure. Customer responsibility: entirely.
Toyota, 2023 — a cloud environment misconfiguration exposed vehicle data for 2.15 million customers over approximately ten years. The misconfiguration was introduced during a system migration and was never detected. Provider infrastructure: unaffected. Customer monitoring and access controls: absent.
The pattern across every major cloud breach is consistent: the provider's infrastructure was not compromised. A configuration decision made by the customer created the exposure.
Using the Model as a Security Planning Framework
The shared responsibility model is most useful when you reverse-engineer it into a checklist of questions for each responsibility area you own.
For IAM: Who has access to what? Is least privilege enforced? Are there inactive accounts or over-permissioned roles? We covered this in our IAM security post.
For data: Is data encrypted at rest and in transit? Are S3 buckets blocking public access? Are database instances isolated within a VPC? Detailed guidance in our S3 security post.
For applications: Is application code secure? Are secrets managed correctly? Are dependencies patched?
For monitoring: Is CloudTrail enabled? Is GuardDuty configured? Are billing alerts set? Would you know within the hour if something unusual happened in your account?
For each of these areas, the question isn't "is the provider handling this?" The question is "have we handled this, and can we demonstrate it?"
A Simple Audit Question for Each Responsibility Area
IAM: Can I list every entity with admin-level access in our AWS account right now — and explain why each one needs it?
Data storage: Are there any S3 buckets or storage resources that are publicly accessible, and do I know which ones intentionally?
Encryption: Is data encrypted at rest in every datastore we use, and do we control the encryption keys?
Network: Are there any resources exposed to 0.0.0.0/0 that don't need to be internet-accessible?
Secrets: Are there any secrets, credentials, or API keys stored in environment variables, code, or config files that should be in a secrets manager?
Monitoring: If an attacker obtained a valid credential and made 50 API calls in our AWS account right now, would we know about it today?
If any of these questions can't be answered confidently, that's a gap worth addressing before a breach forces the conversation.
Get a Clear Picture of Your Cloud Security Posture
Understanding the shared responsibility model is the starting point. Knowing exactly which items in the "your responsibility" column are correctly configured in your specific environment is a different exercise — one that requires looking at your actual setup, not the theory.
A cloud security review does exactly that: examines your IAM configuration, storage security, network controls, encryption posture, and monitoring coverage against the responsibilities you've taken on by running workloads in the cloud. The output is a prioritised, specific list of what needs to change — not a vendor's general best practice guide, but findings from your environment.
Get in touch to start with a scoping conversation, explore our services, or read more about how we work. More cloud and application security guides are on the Kuboid blog.
Kuboid Secure Layer provides cloud security assessments and web application penetration testing for startups and growing businesses. Visit www.kuboid.in.
