Skip to main content

The Shared-Responsibility Model and What the Cloud Actually Rents You

What This Concept Is​

A cloud provider does not rent you a magical server. It rents you a slice of a system where some failures and obligations are permanently theirs and the rest are permanently yours. The line between those two sets is the shared-responsibility model.

The classic AWS phrasing is:

  • the provider is responsible for the security and operation of the cloud (hardware, datacenters, hypervisors, the physical network, the managed-service internals)
  • the customer is responsible for everything in the cloud (the OS image, the application, the data, the IAM configuration, the network rules, the backups)

Where that line falls depends on the service. A VM hands you the OS; a managed database does not. A serverless function hides the OS entirely. The contract is not "you get a computer" - it is "you get a narrow set of guarantees, and everything else is still your job."

Every provider publishes its own version of the model (AWS "Shared Responsibility," Azure "shared responsibility," Google Cloud's "shared responsibility / shared fate"), and while the boundaries differ in detail, the rule is the same: the higher on the abstraction ladder, the more the provider owns - but configuration, data, and identity never cross over.

Why It Matters Here​

Almost every production outage traceable to "the cloud" turns out to be on the customer side of the line: a misconfigured security group, a leaked access key, an unpatched AMI, a missing backup, a bucket policy that said "Principal": "*". The provider's side fails too, but rarely, and when it does there are status pages and credits.

The rest of this module only makes sense once you internalize where the line sits:

  • a region going dark is the provider's problem, but tolerating that failure is yours (Cluster 1, concept 2)
  • a VM's OS patches are yours; a managed Fargate task's OS patches are the provider's (Cluster 2)
  • the VPC is yours to design; the underlying SDN is the provider's to operate (Cluster 3)
  • bucket encryption-at-rest is mostly the provider's; bucket policy and access keys are entirely yours (Cluster 4)
  • IAM is always yours. There is no "the provider should have stopped that" for over-permissive roles (Cluster 5)

If you cannot name which side of the line a responsibility sits on, you cannot design, audit, or defend the system. This is also the first question any security auditor will ask.

Concrete Example​

Three workloads, same shared-responsibility principle, different lines.

Workload A - EC2 VM running Nginx:

  • provider: datacenter, hardware, hypervisor, network fabric, EBS durability
  • customer: OS patches, Nginx config, TLS certs, security group rules, IAM role attached to the instance, application logs, backups, scaling policy

Workload B - RDS PostgreSQL (managed database):

  • provider: OS patches, Postgres binaries, automated backups if enabled, hardware failover, storage redundancy within an AZ, minor-version upgrades on an opt-in schedule
  • customer: database schema, user grants, query performance, backup retention settings, parameter group choices, which subnet group it lives in, who can call the API to drop it, encryption-key management

Workload C - AWS Lambda (serverless function):

  • provider: the entire runtime, OS, container image, autoscaling, datacenter, hardware, and the network path to the function
  • customer: the function code, its IAM role, its environment variables, its concurrency limit, its destination topics, how errors are handled

Cross-provider parallel: Azure frames the same idea in its Shared responsibility in the cloud doc with a stacked table per service tier (IaaS/PaaS/SaaS). Google Cloud extends it to "shared fate," where the provider takes an active role in customer-side success (Assured Workloads, Blueprints, organization policies pre-packaged). The labels differ; the math does not.

Notice what does not change across all three workloads and all three providers: IAM, data, and configuration are always the customer's responsibility. As the abstraction layer rises, the provider takes more of the OS and runtime, but never any of the access control.

Common Confusion / Misconception​

"Managed service means we don't have to worry about security." Managed services move the infrastructure security to the provider. They do nothing for your security: who can call the API, what policies are attached, which CIDR ranges can reach the endpoint, how secrets are rotated. The managed label is orthogonal to your configuration risk.

"Serverless means there's no server to secure." There is always a server; you are just not allowed to see it. You still own the function code, its dependencies (supply-chain risk), its IAM role, and the events it trusts.

"The cloud is secure by default." It is securable by default. A brand-new account has S3 Block Public Access on, security groups that allow no inbound traffic, and no IAM users. Every "the cloud failed us" story has a human turning one of those defaults off.

"The provider will notify me when I cross the line." Only sometimes. A public S3 bucket triggers a warning; an over-permissive IAM role does not. A deleted backup is just deleted. The "guardrail" services (Config, Security Hub, GuardDuty, SCC, Defender for Cloud) are opt-in - you have to turn them on and respond to them.

Gotcha: The shared-responsibility diagrams you see are simplifications. The real boundary for, say, RDS includes ~30 items split between customer and provider with asterisks on half of them. For any service you rely on, read that service's specific shared-responsibility page - not just the framework poster.

How To Use It​

Before you deploy anything, answer these:

  1. Which service am I using, and what is its shared-responsibility boundary?
  2. Which items on my side of the line am I actually configuring?
  3. Which items am I defaulting, and is the default appropriate?
  4. What is the blast radius if my side fails (leaked key, bad rule, over-wide role)?
  5. What is my recovery mechanism if the provider's side fails (AZ outage, service throttling)?
  6. Which side owns each of: OS patching, TLS cert rotation, backup retention, network ACL, encryption-key rotation, IAM policy review? Write this out for every service you use.

Write this down in a design doc before the first resource is created. Re-read it during incident reviews - most post-mortems rediscover the shared-responsibility line the hard way.

Check Yourself​

  1. A developer tells you "we use RDS, so backups are handled." What is wrong with that claim?
  2. Why is IAM always on the customer side, regardless of service tier?
  3. Name one provider-side responsibility you can verify (not just trust) using audit tooling.
  4. You adopt a managed Kubernetes service (EKS, GKE, AKS). Which of these are now the provider's job, and which stay yours: node OS patches, pod-level IAM, control-plane API availability, cluster RBAC, inbound internet rules to pods?
  5. On GCP, "shared fate" is different from "shared responsibility." In one sentence, what is the shift?

Mini Drill or Application​

Pick a service in your current (or most recent) project: VM, managed database, object store, or serverless function. In fifteen minutes, write a two-column table:

  • Left: everything the provider is responsible for
  • Right: everything you are responsible for

Then add a third column: "how do I know this is actually configured correctly?" For each customer-side item that does not have an answer, you have found a real risk.

Extension: repeat the exercise for the equivalent service on a second cloud provider (e.g., GCS vs S3, Cloud SQL vs RDS). Circle the two or three items that moved across the line. That is where your cross-provider mental model leaks the most.

Read This Only If Stuck​