Shared Responsibility Model — what belongs to the cloud provider vs the customer

The shared responsibility model defines who protects what in cloud environments. It is the starting point of any cloud security strategy. Providers like AWS, GCP, and Azure document this clearly, yet in practice the boundary still confuses entire teams.

The basic split

PROVIDER responsibility (security OF the cloud):
  - Physical hardware in data centers
  - Global network, routers, switches
  - Hypervisors and VM isolation
  - Base software for managed services (RDS, S3, Lambda)
  - OS patches for fully-managed services

CUSTOMER responsibility (security IN the cloud):
  - Service configuration (IAM, security groups, buckets)
  - Data at rest and in transit
  - OS of VMs/EC2 instances (patching, hardening)
  - Applications and workload code
  - Credential and key management
  - Monitoring, logging, and incident response

It shifts with the service model

The customer’s share of responsibility changes depending on the contract model:

On-Premises: customer controls everything (hardware → app)

IaaS (EC2, GCE, Azure VM):
  Provider → hardware, hypervisor, physical network
  Customer → OS, runtime, middleware, app, data, virtual network config

PaaS (Elastic Beanstalk, Cloud Run, App Service):
  Provider → OS, runtime, platform
  Customer → app, data, platform-level configuration

SaaS (Google Workspace, Salesforce, Office 365):
  Provider → almost all infrastructure
  Customer → data, user permissions, app security configuration

Common misunderstandings

“The provider guarantees availability, so I don’t need backups.” Service availability is not data protection. If you delete an S3 bucket, the data is gone. The provider does not restore what the customer deleted — whether by accident or ransomware.

“The service is managed, so it’s secure.” A managed RDS protects the database OS. It does not protect your schema, your database permissions, or your queries against SQL injection.

“The cloud’s internal network is trusted.” Lateral movement between resources in the same account is possible when security groups and IAM are misconfigured. Zero trust applies inside the cloud too.

Quick mapping — AWS as example

S3:
  AWS  → durability, disk encryption, availability
  You  → ACLs, bucket policy, block public access, versioning

EC2:
  AWS  → hardware, hypervisor, physical network
  You  → OS patches, firewall (security groups), SSM agent, antivirus

Lambda:
  AWS  → OS, runtime, scaling
  You  → code, execution role permissions, environment variables

RDS:
  AWS  → OS, engine patches, automated backups
  You  → passwords, database permissions, VPC/subnet group, public access toggle

IAM:
  AWS  → the IAM service itself
  You  → users, roles, policies, MFA — all yours

Best practices

• Read your provider’s Shared Responsibility Model. It is official documentation that binds what they guarantee.
• Document internally which controls belong to the platform team versus the application team.
• In audits, “who is responsible for X” must have a clear, written answer.
• Use frameworks such as CIS Benchmarks and NIST CSF to map the controls that are your responsibility.