Home » Glossary » Amazon AWS – Shared Responsibility Model

Amazon AWS – Shared Responsibility Model

It is often misunderstood and is vital to remove the grey areas of what Cloud providers do and do not provide.

The compliance and security of web services provided by the Big3 Hyper-Scale Cloud providers AWS, Microsoft Azure and Google Cloud is actually a ‘shared responsibility’.

What this means is that migrating services to the cloud is not in any way ‘hands off’. There is specific accountability that each party must take responsibility for.

In the case of AWS it is called the ‘Shared Responsibility Model’. AWS will take responsibility of the platform operational overhead, as AWS operates, manages and controls the components from the host operating system and virtualisation layer down to the physical security of the facilities in which the service operates. 

The customer therefore will assume responsibility and management of the guest operating system (including updates and security patches) and other associated application software as well as the configuration of the AWS provided security group firewall.

It is vital therefore that customers carefully consider the services they choose as their responsibilities vary depending on the services used, the integration of those services into their IT environment, and applicable laws and regulations. The nature of this shared responsibility also provides the flexibility and customer control that permits the deployment. 

As shown in the chart below, this differentiation of responsibility is commonly referred to as Security “of” the Cloud versus Security “in” the Cloud.

The complexities around the accountability and responsibility take careful consideration and planning, it is always advised that professional advice is sought. An approved Amazon Consulting Partner will follow the correct review, planning, PoC and deployment guidelines.


AWS responsibility “Security of the Cloud” – AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. These elements are the hardware, software, networking, and physical facilities that run AWS Cloud services.

Customer responsibility “Security in the Cloud” – The customer responsibility will be determined by the AWS Cloud services that a customer selects. This determines the amount of configuration work the customer must perform as part of their security responsibilities. For example, a service such as Amazon Elastic Compute Cloud (Amazon EC2) is categorised as Infrastructure as a Service (IaaS) and, as such, requires the customer to perform all of the necessary security configuration and management tasks. Customers that deploy an Amazon EC2 instance are responsible for management of the guest operating system (including updates and security patches), any application software or utilities installed by the customer on the instances, and the configuration of the AWS-provided firewall (called a security group) on each instance. For abstracted services, such as Amazon S3 and Amazon DynamoDB, AWS operates the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data. Customers are responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions.

The AWS/customer ‘shared responsibility model’ also extends to IT controls. The management, operation and verification of IT controls is shared in a similar way to the over arching IT environment. 

AWS can help customers with the operating controls by managing the controls associated with the physical infrastructure deployed in the AWS environment that may previously have been managed by the customer. As every customer deploys differently in AWS, customers can take advantage of shifting management of certain IT controls to AWS which results in a (new) distributed control environment. Customers can then use the AWS control and compliance documentation available to them to perform their control evaluation and verification procedures as required.

Below are examples of controls that are managed by AWS, AWS Customers and/or both.

Inherited Controls – Controls which a customer fully inherits from AWS.

    • Physical and Environmental controls


Shared Controls – Controls which apply to both the infrastructure layer and customer layers, but in completely separate contexts or perspectives. In a shared control, AWS provides the requirements for the infrastructure and the customer must provide their own control implementation within their use of AWS services. Examples include:

    • Patch Management – AWS is responsible for patching and fixing flaws within the infrastructure, but customers are responsible for patching their guest OS and applications.
    • Configuration Management – AWS maintains the configuration of its infrastructure devices, but a customer is responsible for configuring their own guest operating systems, databases, and applications.
    • Awareness & Training – AWS trains AWS employees, but a customer must train their own employees.


Customer Specific – Controls which are solely the responsibility of the customer based on the application they are deploying within AWS services. Examples include:

    • Service and Communications Protection or Zone Security which may require a customer to route or zone data within specific security environments.

For more information on how our Semantic Technology Consultants can help your business with reviewing the right solution, and your Cloud planning, design and migration project contact us today

We will arrange an initial call back, talk through options and discuss the next steps