Comparing Cloud Providers’ Shared Responsibility Models

More and more enterprises are becoming multi-cloud. And when evaluating cloud service providers (CSPs) for different needs, one important factor is security. Yet, CSPs aren’t responsible for securing everything—depending on the component in question, you may be left on your own to ensure it’s adequately safeguarded in the cloud.

Thus, it helps to understand where exactly responsibility lies in the cloud. This is typically denoted by a shared responsibility model (SRM), which stipulates who is responsible for what. Typically, the CSP agrees to secure the underlying infrastructure, and the user or organization agrees to protect their data and to properly configure access to the applications that run in the cloud. Yet, there are nuances between cloud SRMs that bear highlighting.

As of 2023, Amazon Web Services (AWS) has the highest cloud computing market share, at 33%. This is followed by Microsoft Azure at 23% and Google Cloud Platform (GCP) at 11%. Below, we’ll review the differences between the shared responsibility models across these three top cloud service providers. We’ll seek to understand how security responsibility shifts as organizations evolve their cloud footprint and consider which model is best for certain objectives.

Amazon Web Services (AWS)

The AWS shared responsibility model is relatively straightforward—AWS customers are responsible for securing things like data, user accounts and the applications they host in the cloud. Alternatively, AWS is responsible for securing the digital and physical infrastructure: “This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.”

To dive a little deeper, the responsibility on the customer side also may include guest operating systems and configuration of the AWS firewalls. Since AWS has hundreds of services, the level of responsibility will vary depending on which ones are used. For example, AWS assumes ownership of infrastructure management for services like Amazon S3 and DynamoDB but not the management and configuration of infrastructure-as-a-service (IaaS). In general, customers are responsible for proper data handling and permissions.

AWS shared responsibility model
AWS shared responsibility model

This means that AWS users must take special care to ensure workloads like EC2 instances and S3 buckets are properly configured. Users should be careful when deciding what services to host on AWS to avoid vulnerabilities. And although Amazon shares some responsibility for certain IT controls, users must take the lead on creating data handling policies that conform with laws and compliances.

Microsoft Azure

With Azure, customers are always responsible for information and data, securing mobile and PC devices and managing accounts and identities. After this, Microsoft’s division of responsibility varies depending on whether your deployment is software-as-a-service (SaaS), platform-as-a-service (PaaS), infrastructure-as-a-service (IaaS) or hosted on a private data center.

The more encompassing the workload is, the less responsible Azure is for securing backend layers. For example, for PaaS, Azure takes shared responsibility for identity and directory infrastructure, applications and network controls. However, with IaaS and on-premises, this is entirely in the ballpark of the customer to secure.

Azure's division of responsibility
Azure’s division of responsibility

Regardless of the deployment type, Azure customers must always secure their data, endpoints, accounts and access management. Beyond that, Azure users will want to look carefully at their stack to understand where their workloads fit into the responsibility matrix. Thankfully, understanding the nuances should be relatively straightforward—the more advanced the implementation is, such as IaaS and fully controlled data centers, the more responsibility you must take on for the underlying operating system and physical infrastructure.

Google Cloud Platform (GCP)

Out of the Big Three, GCP’s shared responsibility model is the most intricate. Instead of shared responsibility, GCP describes it as a shared fate. At its basic level, GCP agrees to build and operate a safe cloud platform. And regardless of workload type, GCP customers are responsible for the access policies and content stored within applications.

Similarly to Azure, GCP responsibilities differ depending upon the type of workload and which GCP services you’re using. For functions-as-a-service (FaaS) and SaaS, GCP owns the bulk of security responsibilities. Starting with IaaS, customers take on more responsibilities, like identity, operations, access and authentication, network security and guest operating systems. On-premises installations shift nearly all responsibility to the customer, such as logging, encryption and securing the hardware.

GCP's matrix of shared fate
GCP’s matrix of shared fate

When using GCP, comprehending security responsibility requires an in-depth understanding of each service and its unique configuration mechanics. Customers are on their own to understand the correct regulatory requirements of the business they are working in, as well as geographic nuances. On that note, GCP provides a comprehensive document, Google Cloud Platform: Shared Responsibility Matrix, which outlines how to properly run PCI-compliant products and services on GCP.

Who’s Responsible for Securing What in the Cloud?

Assigning responsibility in the cloud is murkier than you might think. Although data breaches often occur in the public cloud, it’s on the user’s shoulders to fix insecure defaults and configure instances correctly to avoid tampering and privilege escalation. And although CSPs offer hardened firewalls and identity and access management tools, it’s up to the users to implement these tools effectively.

Understanding the reality of the cloud security models and where you fit into these matrixes will help IT leaders assign roles and responsibilities within their organizations. Above, we briefly explored how SRMs differ across the three major cloud computing providers. And as you can see, there are many similarities between the models. To summarize:

  • When using AWS, you are responsible for security “in” the cloud and they are responsible for the security “of” the cloud.
  • With Azure, you always own your data and identities and responsibility shifts depending upon the breadth of your implementation.
  • Finally, GCP takes on a ‘shared fate,’ shifting the responsibility of content and access policies to customers and safeguarding underlying networks and infrastructure.

Of course, organizations will want to carefully review the complete SRM of their cloud provider within the context of their unique cloud computing needs. More information on the shared security models of each CSP can be found here: AWS, Azure and GCP.

Avatar photo

Bill Doerrfeld

Bill Doerrfeld is a tech journalist and analyst based in Seattle. His beat is cloud technologies, specifically the web API economy. He began researching APIs as an Associate Editor at ProgrammableWeb, and since 2015 has been the Editor at Nordic APIs, a high impact blog on API strategy for providers. He loves discovering new trends, researching new technology, and writing on topics like DevOps, REST design, GraphQL, SaaS marketing, IoT, AI, and more. He also gets out into the world to speak occasionally.

bill-doerrfeld has 22 posts and counting.See all posts by bill-doerrfeld