Shared Responsibility Model

The Responsibility Boundary

When a company lifts a workload into the cloud, the first question is never "how do we secure this?" — it's "which parts are already secured for us?" The shared responsibility model answers that question by drawing a line between the cloud provider's obligations and the customer's obligations. Getting this boundary wrong is the root cause of most cloud breaches: teams assume the provider handles something the customer owns, or they waste effort re-securing what the provider already covers.

The provider's side: security of the cloud

The provider is responsible for the physical and virtualization layers that make the cloud exist. This includes:

• Physical security of data centers — access controls, power, cooling, hardware lifecycle
• Network infrastructure — the backbone, edge locations, and core routing
• Hypervisor and host OS — the virtualization layer that isolates tenant workloads
• Managed service internals — for services like RDS, Lambda, or CloudFront, the provider patches the underlying runtime

AWS, Azure, and GCP all publish detailed responsibility matrices. The key insight is that the provider's responsibility is always the same regardless of what you run — they secure the substrate.

The customer's side: security in the cloud

Everything you build, configure, or deploy on top of that substrate is your responsibility. This includes:

• Data classification and encryption — you decide what's sensitive and how it's encrypted at rest and in transit
• Identity and access management — who can do what, with which credentials, under which conditions
• Network configuration — VPC design, security groups, firewall rules, routing tables
• OS and application patching — for IaaS workloads, you patch the guest OS and everything above it
• Customer-managed keys — if you bring your own key (BYOK), you manage rotation and access

The critical nuance: the boundary shifts by service model

This is where most people get tripped up. The responsibility line is not fixed — it moves depending on whether you're using IaaS, PaaS, or SaaS:

With EC2, you own the OS patching. With RDS, AWS patches the database engine and OS — you manage access, encryption, and data. With SaaS, the provider owns almost everything except your data and who can access it.

Why this matters for security decisions

Understanding the boundary prevents two failure modes:

1. Assuming the provider handles something you own — e.g., assuming AWS patches your EC2 instances (it doesn't) or that S3 buckets are private by default (they're not)
2. Over-engineering controls the provider already has — e.g., building redundant physical access controls when the provider already handles that

The model is not a suggestion — it's the contractual and architectural reality of cloud computing. Every security decision you make should start with "which side of the line does this control fall on?"

Breach Patterns at the Boundary

The shared responsibility model isn't theoretical — it maps directly to real breach patterns. When you read incident post-mortems, the root cause is almost always a customer-side control that was assumed to be the provider's job.

Pattern 1: Public storage buckets

The most common cloud breach is an exposed S3 bucket, Azure Blob, or GCS object. The provider gives you the storage service; you configure the access policy. When a bucket is accidentally set to public, that's a customer-side misconfiguration — the provider delivered exactly the service you asked for.

# Checking bucket policy for public access (AWS CLI)
aws s3api get-bucket-policy --bucket my-app-data --query 'Policy' --output text | jq .

# Checking block public access settings
aws s3api get-public-access-block --bucket my-app-data

The provider offers tools like S3 Block Public Access, but enabling them is the customer's responsibility. The service works correctly — the misconfiguration is in how the customer used it.

Pattern 2: Over-privileged IAM roles

When an EC2 instance is given an IAM role with s3:* permissions and the instance is compromised, the attacker gets full S3 access. The provider's IAM service worked exactly as configured — the customer attached an over-permissive role.

// Over-permissive role — customer-side mistake
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }]
}

The provider gives you the tools to scope permissions tightly (least privilege, permission boundaries, SCPs). Using them correctly is on you.

Pattern 3: Unpatched IaaS workloads

When a vulnerability like Log4Shell spreads through cloud environments, the compromised systems are almost always customer-managed EC2 instances or containers. The provider patches the hypervisor and host infrastructure — but the guest OS and application layers are the customer's responsibility.

# Checking for available security updates on an EC2 instance (Amazon Linux 2)
sudo yum check-update --security

# Applying security patches
sudo yum update --security

Pattern 4: Misconfigured network security groups

A security group that allows 0.0.0.0/0 on port 22 (SSH) or 3389 (RDP) is a customer configuration error. The provider's security group service is working correctly — the rule you created is too permissive.

# Auditing security groups for open SSH
aws ec2 describe-security-groups \
  --filters "Name=ip-permission.cidr,Values=0.0.0.0/0" \
  --query "SecurityGroups[?IpPermissions[?FromPort==`22`]].GroupId" \
  --output text

The pattern behind all patterns

Every one of these breaches follows the same shape: the customer assumed a control was the provider's responsibility, or failed to configure a customer-side control correctly. The shared responsibility model exists precisely to make this boundary explicit — so you can focus your security effort on the controls you actually own, and verify that the provider's controls are operating as expected.