Shared Responsibility Model Across AWS, Azure, and GCP: Who Secures What?

Cloud Security Begins with Shared Responsibility

A cloud provider can secure a data center, patch the hypervisor, and protect the physical network. Yet a customer can still expose sensitive information through weak passwords, public storage, excessive permissions, or an unmonitored administrator account.

That is why moving to the cloud does not transfer every security responsibility to Amazon Web Services, Microsoft Azure, or Google Cloud.

The shared responsibility model explains how cloud security duties are divided between the provider and the customer. The provider protects the platform and underlying infrastructure. The customer protects how cloud services are configured, accessed, and used.

The exact boundary changes according to the provider, service, workload, deployment model, and regulatory requirements.

For beginners, the central lesson is simple:

Cloud providers secure the services they operate, while customers remain responsible for the identities, data, configurations, applications, and business decisions they control.

This guide compares AWS, Azure, and Google Cloud, explains how responsibilities change across IaaS, PaaS, and SaaS, and shows how organizations can prevent gaps between provider capabilities and customer action.

What Is the Shared Responsibility Model?

The shared responsibility model is a cloud security framework that divides security and compliance duties between a cloud service provider and its customer.

The provider typically manages physical facilities, hardware, core networking, and virtualization. The customer typically manages identities, permissions, data, application settings, workload configurations, and connections to the wider business environment.

AWS describes this division as security “of” the cloud and security “in” the cloud.

AWS protects the infrastructure used to deliver its services. Customers secure their data, applications, guest operating systems where applicable, access policies, and cloud configurations.

Microsoft explains that responsibilities change across on-premises infrastructure, IaaS, PaaS, and SaaS. Customers continue to retain responsibility for their data, endpoints, user accounts, and access management.

Google Cloud recognizes the shared responsibility model while also promoting a broader shared fate approach. This approach combines the responsibility boundary with secure foundations, architectural guidance, and tools intended to help customers achieve stronger security outcomes.

Who Is Responsible for Cloud Security?

Both the cloud provider and the customer are responsible for cloud security, but they control different parts of the environment.

The provider normally protects the physical and technical infrastructure that delivers the cloud service.

The customer decides:

• Who receives access
• Which permissions users and workloads receive
• What data enters the service
• How resources are configured
• Which security features are enabled
• How applications are developed
• How cloud activity is monitored
• How incidents are handled

A provider may offer encryption, logging, identity services, backups, firewalls, and monitoring tools. The customer still needs to configure and use those capabilities correctly.

Why the Shared Responsibility Model Matters

Updated content to paste

How Responsibilities Change Across IaaS, PaaS, and SaaS

The customer generally carries more technical responsibility in Infrastructure as a Service and less infrastructure responsibility in Software as a Service.

Less infrastructure responsibility does not mean no security responsibility.

IaaS Security

Infrastructure as a Service provides virtualized computing, networking, and storage while leaving the customer in control of much of the software stack.

For a virtual machine, the provider protects the physical infrastructure and virtualization layer. The customer may remain responsible for:

• Guest operating system security
• Operating system updates and patches
• Installed applications
• Host-based security controls
• Network rules and segmentation
• Identity and access management
• Workload configuration
• Data classification
• Cloud encryption
• Backup settings
• Logging and monitoring

For example, AWS identifies Amazon EC2 as an IaaS service where customers manage the guest operating system, security patches, installed applications, and security-group configuration.

This makes cloud patch management and cloud vulnerability management direct customer responsibilities for many IaaS workloads.

PaaS Security

Platform as a Service reduces the infrastructure that the customer must manage.

The provider may operate:

• Physical infrastructure
• Virtualization
• Operating systems
• Runtime environments
• Middleware
• Managed platform components

The customer still manages application code, data, identities, service configurations, secrets, APIs, and access policies.

PaaS security problems often arise when development teams assume that a managed platform also secures their application logic, API authorization, credentials, database permissions, and software dependencies.

SaaS Security

Software as a Service shifts most infrastructure and application-platform management to the provider.

The customer still manages:

• User accounts
• Authentication settings
• Administrator roles
• Data sharing
• Data retention
• Tenant configurations
• Connected applications
• Endpoint security
• Compliance decisions
• Monitoring
• Incident response

A SaaS provider may secure the application platform while a customer accidentally allows public sharing, leaves dormant administrator accounts active, or connects an unapproved third-party application.

The SaaS shared responsibility model therefore continues to require active customer security management.

AWS, Azure, and GCP Shared Responsibility Compared

AWS, Microsoft Azure, and Google Cloud use different terminology, security tools, and service designs. However, the central principle is broadly similar.

The provider protects the underlying cloud platform. The customer protects the resources, identities, data, applications, and configurations that remain within its control.

AWS Shared Responsibility Model

AWS is responsible for security of the cloud.

This includes the infrastructure used to deliver AWS services, such as:

• Physical facilities
• Hardware
• Core networking
• Virtualization
• Foundational service infrastructure

Customers are responsible for security in the cloud.

The exact customer responsibility depends on the service selected.

With Amazon EC2, customers manage the guest operating system, updates, patches, installed applications, and security-group configuration.

With more abstracted services such as Amazon S3 and Amazon DynamoDB, AWS operates more of the platform. Customers continue to manage their data, encryption choices, classification, and IAM permissions.

An AWS cloud security policy should therefore map each service to its customer-owned controls rather than applying one security checklist to every AWS workload.

Azure Shared Responsibility Model

Microsoft manages Azure data centers, physical networks, physical hosts, and the hypervisor.

As services become more managed, Microsoft also takes responsibility for operating systems, runtime environments, middleware, and other platform components.

Customers continue to retain responsibility for:

• Data
• Identities and user accounts
• Endpoints
• Access management
• Customer-controlled configurations
• Application security
• Compliance decisions

Customers need to configure controls such as role-based access control, multi-factor authentication, conditional access, data-protection options, and tenant-level settings.

Azure provides security, identity, governance, backup, and reliability capabilities. Customers must select and configure the options that meet the needs of their workloads.

Google Cloud Shared Responsibility and Shared Fate

Google Cloud’s responsibility boundary changes according to the service, workload, regulatory environment, location, and customer configuration.

Customers must understand their data, risks, and regulatory requirements and then determine which security controls each workload requires.

Google Cloud provides the underlying platform, security capabilities, deployment guidance, and recommended architectural patterns.

Google also uses the concept of shared fate.

Shared fate does not remove customer accountability. Instead, it reflects a more active provider-customer relationship supported by secure foundations, recommended configurations, architectural guidance, and tools intended to improve security outcomes.

Simple Provider and Customer Comparison

This comparison is a starting point, not a replacement for current service documentation.

A multi-cloud security program should maintain a responsibility matrix for every important service and workload.

How Service Models Affect Security Responsibilities

Customer Responsibilities That Never Disappear

Several cloud security duties remain with the customer regardless of the provider or service model.

Identity and Cloud Access Control

Customers decide who receives an account, which roles users receive, and how privileged access is governed.

Cloud access management should include:

• Multi-factor authentication
• Least-privilege permissions
• Role-based access
• Privileged account controls
• Regular access reviews
• Rapid removal of former users
• Temporary administrative access
• Controls for service accounts and workloads

A provider cannot know whether a finance employee should be allowed to manage production infrastructure or whether a contractor still needs an administrator role.

The provider supplies identity and security tools. The customer must decide how access should be granted and reviewed.

Cloud Data Security and Governance

Customers need to understand what information they place in the cloud.

Cloud data governance should cover:

• Data classification
• Business ownership
• Access restrictions
• Retention
• Sharing
• Data residency
• Backups
• Encryption
• Deletion
• Regulatory obligations

Data encryption in cloud computing is shared in practice.

Providers offer encryption and key-management capabilities. Customers decide which options to use, who can access encryption keys, and how sensitive information is handled.

Cloud data protection therefore requires more than confirming that a provider supports encryption.

Cloud Configuration and Application Security

Cloud misconfiguration occurs when identities, storage, networks, services, or application settings are deployed incorrectly.

Examples include:

• Public storage
• Open management ports
• Excessive permissions
• Missing logging
• Disabled encryption
• Unrestricted network access
• Exposed secrets
• Unapproved service regions

Cloud configuration management should use approved templates, automated checks, peer review, change control, and continuous assessment.

Customers also retain responsibility for much of their cloud application security.

A provider cannot correct insecure business logic, weak authorization, exposed credentials, unsafe APIs, or vulnerable dependencies inside customer-developed software.

Monitoring and Cloud Incident Response

Providers monitor their platforms and respond to incidents within provider-controlled infrastructure.

Customers need to monitor:

• Cloud accounts
• User identities
• Administrator activity
• Applications
• Workloads
• Data access
• Configuration changes
• Customer-controlled networks

A cloud incident response plan should define:

• Which logs are enabled
• Who reviews alerts
• How compromised access is revoked
• How cloud resources are isolated
• How provider support is contacted
• How evidence is preserved
• Who communicates with affected stakeholders

Logging features that are available but not enabled or reviewed provide limited protection.

Cloud Disaster Recovery and Business Continuity

Cloud disaster recovery requires customer decisions about:

• Backup frequency
• Backup locations
• Cross-region replication
• Recovery time objectives
• Recovery point objectives
• Application dependencies
• Failover procedures
• Recovery testing

A provider cannot decide how much data loss or downtime is acceptable to the customer’s business.

Cloud business continuity plans should therefore cover applications and business processes, not only provider uptime.

Internal linking instruction: Link the phrase “cloud incident response” to the Cloud Incident Response Playbooks guide or course page. Do not publish this instruction as visible text.

Common Misunderstandings About Shared Responsibility

The shared responsibility model sounds simple, but it is often misunderstood.

One common mistake is assuming the cloud provider handles all security. In reality, providers secure the cloud platform, but customers must still secure their data, identities, applications, and configurations.

Another misunderstanding is around compliance. A provider may hold certifications, but that does not automatically make the customer’s cloud environment compliant.

Managed services can also create confusion. They may reduce operational work, but customers still have responsibilities for access control, governance, data protection, and secure use.

These misunderstandings can create gaps that attackers or auditors may expose later.

Best Practices for Managing Shared Responsibility

How to Put the Shared Responsibility Model Into Practice

The model becomes useful only when it is converted into repeatable controls, assigned ownership, and measurable evidence.

1. Inventory Cloud Services, Data, and Owners

Create an inventory of:

• Cloud accounts
• Azure subscriptions
• Google Cloud projects
• SaaS tenants
• Applications
• Workloads
• Data stores
• APIs
• External integrations
• Security tools

For each item, record:

• The provider
• The service model
• The business owner
• The technical owner
• The data involved
• The relevant regulatory requirements
• The responsibility documentation

Without an accurate inventory, organizations cannot determine which shared responsibilities apply.

2. Build a Responsibility Matrix

For every important cloud service, identify whether each control belongs to:

• The provider
• The customer
• Both parties
• A third-party supplier

The matrix should include:

• Identity and access
• Data protection
• Application security
• Cloud network security
• Configuration management
• Logging
• Vulnerability management
• Patch management
• Backup
• Disaster recovery
• Incident response
• Compliance evidence

Assign a named owner to every customer-controlled or shared control.

3. Establish a Cloud Security Policy

A cloud security policy should define:

• Mandatory customer controls
• Authentication requirements
• Access standards
• Encryption expectations
• Approved cloud regions
• Logging requirements
• Backup requirements
• Security-review processes
• Exception procedures
• Evidence requirements

The policy should support the wider cloud security strategy, cloud risk management process, and cloud compliance framework.

US organizations can use the six functions in the NIST Cybersecurity Framework 2.0 as a flexible structure:

• Govern
• Identify
• Protect
• Detect
• Respond
• Recover

The framework does not prescribe a single technology stack. It helps organizations organize cybersecurity outcomes, responsibilities, and risk-management activities.

4. Automate Cloud Configuration and Monitoring

Use:

• Approved infrastructure templates
• Policy as code
• Cloud-native security controls
• Configuration baselines
• Automated compliance checks
• Continuous monitoring

Automate checks for:

• Public storage
• Excessive permissions
• Missing encryption
• Exposed administrative ports
• Disabled logging
• Unsupported software
• Weak backup settings
• Unapproved deployment regions

Automation improves consistency, but security teams still need to review findings and resolve exceptions.

5. Protect Applications and Workloads

Use a cloud workload protection platform or comparable cloud workload security controls where appropriate.

Combine workload protection with:

• Secure software development
• Secrets management
• Cloud vulnerability management
• API security
• Patch management
• Runtime monitoring
• Container security
• Application testing

No single security product covers every customer responsibility.

6. Test Compliance, Incident Response, and Recovery

A cloud security audit should test customer-controlled security measures, not simply collect the provider’s certifications.

Provider reports demonstrate controls within the provider’s scope.

Customers still need evidence that their own controls operate effectively, including:

• IAM controls
• Data protection
• Configuration management
• Logging
• Retention
• Incident response
• Backup
• Recovery testing

Test cloud incident response and recovery procedures before a real disruption occurs.

Internal linking instruction: Link the phrase “cloud misconfiguration” to a relevant guide on cloud configuration risks or security best practices. Do not publish this instruction as visible text.

Frequently Asked Questions

What Is the Shared Responsibility Model?

The shared responsibility model divides cloud security duties between the cloud provider and the customer.

The provider protects the underlying cloud infrastructure and managed service components. The customer protects identities, data, applications, configurations, and the way cloud services are used.

Does the Cloud Provider Protect Customer Data?

The provider protects the infrastructure and service mechanisms used to store and process customer data.

The customer remains responsible for classifying information, controlling access, configuring encryption, setting retention requirements, managing sharing, and meeting relevant regulatory obligations.

Is the Customer Responsible for Cloud Patching?

It depends on the service.

In IaaS, customers normally patch guest operating systems and applications.

In PaaS and SaaS, the provider handles more platform patching, while customers remain responsible for their code, configurations, integrations, and customer-managed components.

Who Is Responsible for SaaS Security?

The SaaS provider secures the application platform and underlying infrastructure.

The customer manages user accounts, authentication, permissions, tenant configurations, data sharing, connected applications, endpoints, and how the service is used.

Is the Model the Same Across AWS, Azure, and GCP?

The core principle is similar, but the exact division varies according to the provider, service, configuration, workload, location, and regulatory requirements.

Organizations should review the current documentation for each service rather than assuming one provider’s model applies unchanged to another.

Turn Shared Responsibility Into Clear Ownership

The shared responsibility model does not divide security into two completely separate halves.

It creates a working boundary that changes according to the provider and service being used.

AWS, Azure, and Google Cloud protect their underlying platforms. Customers remain accountable for identity, access, data, configuration, application security, monitoring, compliance, incident response, and resilience within their own environments.

The safest approach is to:

• Document each cloud service
• Identify the correct responsibility boundary
• Assign every customer-controlled security measure to a named owner
• Automate checks where practical
• Review the responsibility matrix when services, architecture, or business requirements change

The Shared Responsibility Model Across AWS, Azure, and GCP course provides a structured introduction to provider and customer duties across the three major cloud platforms.

Explore the course to understand who secures what and how to prevent responsibility gaps from becoming cloud security incidents.