Skip to main content

AWS Shared Responsibility Model: Cloud Security

AWS security best practices begin with the AWS Shared Responsibility Model that dictates which security controls are AWS’s responsibility and which are yours.

Updated: September 2017 – Inclusion of additional models
Over my next several posts, I’ll be discussing AWS security best practices from different perspectives and covering different AWS services. The overall goal is to help you improve the security of your cloud environments. We’ll start with the AWS Shared Responsibility Model, which lies at the very foundation of AWS Security.
By the very nature of the phrase “AWS Shared Responsibility Model,” we can see that security implementation on the AWS Cloud is not the sole responsibility of any one player, but is shared between AWS and you, the customer.
The AWS Shared Responsibility Model dictates which security controls are AWS’s responsibility, and which are yours. In short, you decide how you want your resources to sit ‘in’ the cloud (in other words, how much access you choose to give to and from your resources), while AWS guarantees the global security ‘of’ the Cloud (i.e., the underlying network and hardware they provide to host and connect your resources).
We will briefly describe a number of configurable security elements later in this post, but first, we’re more interested in understanding our responsibilities rather than how to implement them.
In my experience, a solid understanding of the AWS Shared Responsibility Model makes it easier to build and maintain a highly secure and reliable environment. Without knowing where I needed to step in and take control of data security, I was never able to properly define just how secure my environment really was.

AWS treats security as a major priority…and so should you

Security is AWS’s number-one priority in every sense. It’s an area into which AWS pours huge capital and energy and devotes near-constant attention.
There’s a reason for this. After speaking with my business contacts in various sectors, it seems that security is still one of the main reasons corporations are reluctant to adopt a cloud presence. Overcoming this hesitation requires AWS to be at the very top of security excellence and governance.
Having served over a million customers in the past month alone, AWS’s most stringent security standards are already being used for audit purposes by the most security-sensitive customers around. Facing so many requirements, AWS is certified and compliant across a huge range of security standards, including PCI DSS, ISO, and SOC.
AWS Services are deployed and distributed in exactly the same way throughout their entire global infrastructure. This means a single user accessing a simple S3 bucket for document backups is covered by the same strict security standards as the largest and most demanding corporations.

AWS Shared Responsibility Models

To help provide a clear definition of the boundaries of responsibility, AWS has devised 3 main models, each representing where AWS and customer responsibilities start and end:

  1. Shared Responsibility Model for Infrastructure Services 
  2. Shared Responsibility Model for Container Services
  3. Shared Responsibility Model for Abstract Services

By taking a look at each of these models, we will be able to clearly see the differences. Let’s start by looking at the first model, based on an infrastructure that includes services such as EC2. Then, we’ll look at how the level of responsibility shifts as we move into containers and abstract services.
For more information on the differences between container and abstract services within AWS, please see our course AWS Security Best Practices: Abstract and Container Services.

Shared Responsibility Model: Infrastructure Services

As we said, AWS is responsible for what is known as Security ‘of’ the cloud. This covers their global infrastructure elements including Regions, Availability Zones, and Edge Locations, and the foundations of their Compute, Storage, Database, and Network services.
AWS owns and controls access to their data centers where your customer data resides. This covers physical access to all hardware and networking components and any additional data center facilities including generators, uninterruptible power supply (UPS) systems, power distribution units (PDUs), computer room air conditioning (CRAC) units, and fire suppression systems. Some of the security compliance controls mentioned previously are based upon this physical access entry and control. Essentially, AWS is responsible for the components that make up the cloud, any data put ‘into’ the cloud then becomes your responsibility.
With the basic Cloud infrastructure secured and maintained by AWS, the responsibility for what goes into the cloud falls on you. This covers both client and server side encryption and network traffic protection, security of the operating system, network, and firewall configuration, followed by application security and identity and access management.
How much of this additional security you wish to implement is entirely your decision. What you choose may depend on the nature of your business or on existing controls that you may already have in place. I recommend tightening security as much as possible to minimize exposure to external threats that could compromise your environment. The important point to remember is that, while AWS provides many powerful security controls, how and when to apply them is not AWS’s responsibility.

Shared Responsibility Model: Container Services

Examples of AWS container services include:

  • AWS Relational Database Service (RDS)
  • AWS Elastic Map Reduce (EMR)
  • AWS Elastic Beanstalk

Straight away, we can see that both Platform and Application management along with any operating system or system and network configuration has shifted to being the responsibility of AWS and is no longer down to us as the customer to manage.  This is a huge difference from that of infrastructure-based services.  However, not all responsibility has shifted. You should note that firewall configuration remains the responsibility of the end user, which integrates at the platform and application management level. For example, RDS utilizes security groups, which you would be responsible for configuring and implementing.

Shared Responsibility Model: Abstract Services

Examples of abstract services include:

  • Simple Storage Service (S3)
  • DynamoDB
  • Amazon Glacier
  • SQS

You will notice that even more responsibility has been shifted to AWS, specifically Network Traffic protection, which AWS will manage via the platform protecting all data in transit using AWS’s own network.  You are also responsible for using IAM tools to apply the correct permissions both at the platform (such as S3 Bucket policies) and IAM user/group level.
As we progress through each of these models, it’s clear that the level of control and responsibility shifts more toward AWS than to the customer.

AWS accounts

When you create your AWS Account, you will have an AWS Administrator account and credentials that will allow you to create other users, groups, and roles within the Identity & Access Management (IAM) Service. Right from the get-go, you are in control of who can access your resources, and it’s up to you to manage this access properly. IAM is a very powerful tool that you can use to create a very specific set of access permissions and private security keys for the resources you deploy. Within IAM, you can also implement Multi Factor Authentication, something I strongly recommend for ALL of the administrator accounts that you create, and especially the admin account.
To learn how to use IAM and understand all of its features, take a look at our course, AWS: Overview of AWS Identity & Access Management (IAM).

OS security patches

Once you launch an EC2 instance, the responsibility for properly applying the latest security patches to the operating system is yours as we can see from the infrastructure model. AWS will not notify you when a new patch is released for your EC2 instance OS; you must manage EC2 OS security.
Whether you’re running Windows or some flavor of Linux (like CentOS, Ubuntu, or SUSE), you must manage the operating system’s security settings. Do not assume that the latest AMIs (Amazon Machine Images) have the very latest security patches. Always check for updates, for example using “yum update” (or “aptitude safe-upgrade”) for Linux, and the Windows update program for Windows.

Security Groups and NACLs

To fully secure your instances, I can’t stress enough the importance of configuring your security groups as tightly as possible. Security groups act as an instance-level firewall with rules, filtering traffic into and out of your instance. They work at a protocol and port level, restricting source traffic at an IP and security group level. This allows you to grant access to your instances using specified protocols and port numbers, opening access from only a single IP address (x.x.x.x/32), from anywhere in the world ( or from addresses in another, pre-configured security group.
For security within your Virtual Private Cloud (VPC) at the subnet/network level, you can implement Network Access Control Lists (NACLs). The NACL is similar to security groups in that it is comprised of rules, but it monitors traffic at the subnet level. It’s important to note that security groups are stateful, while the NACL is stateless. You must remember this when setting up your NACL, as it means you will need to specify rules for both inbound and outbound traffic. NACLs are associated with specific subnets, and so present a great way to help protect against DDOS attacks. Understanding these groups is crucial to controlling who or what can access the resources within your VPC.


Should you need greater security for your data when it’s at rest, you could implement client- or server-side encryption and traffic integrity and protection. For example, you can use 256-bit AES encryption methods with S3 buckets, or enable EBS encryption for your EC2 storage volumes.

This has been the first of a series of articles based on AWS Security and AWS security best practices. I hope this has provided a better understanding of what is expected from you (the customer) with regards to security, compared to what is supplied and managed by AWS. With this, you can now begin deploying a strong and effective security policy within your environment from the ground up.
With this first post from our security series, I hope you’re clear on the division of roles created by the AWS Shared Responsibility Model. Next, I will be covering security concepts related to Amazon’s Virtual Private Clouds, including the best practice use of security groups and how they should be used to achieve the highest instance security possible. I will also discuss the differences between dedicated and multi-tenant instances, and provide an overview of secret and public access keys when using API calls to access EC2 instances.
Got feedback? Please leave a comment below.

Written by

Stuart is the AWS content lead at Cloud Academy where he has created over 40 courses reaching tens of thousands of students. His content focuses heavily on cloud security and compliance, specifically on how to implement and configure AWS services to protect, monitor and secure customer data and their AWS environment.

Related Posts

Khash Nakhostin
— November 13, 2018

Understanding AWS VPC Egress Filtering Methods

Security in AWS is governed by a shared responsibility model where both vendor and subscriber have various operational responsibilities. AWS assumes responsibility for the underlying infrastructure, hardware, virtualization layer, facilities, and staff while the subscriber organization ...

Read more
  • Aviatrix
  • AWS
  • VPC
— November 10, 2018

S3 FTP: Build a Reliable and Inexpensive FTP Server Using Amazon’s S3

Is it possible to create an S3 FTP file backup/transfer solution, minimizing associated file storage and capacity planning administration headache?FTP (File Transfer Protocol) is a fast and convenient way to transfer large files over the Internet. You might, at some point, have conf...

Read more
  • Amazon S3
  • AWS
— October 18, 2018

Microservices Architecture: Advantages and Drawbacks

Microservices are a way of breaking large software projects into loosely coupled modules, which communicate with each other through simple Application Programming Interfaces (APIs).Microservices have become increasingly popular over the past few years. The modular architectural style,...

Read more
  • AWS
  • Microservices
— October 2, 2018

What Are Best Practices for Tagging AWS Resources?

There are many use cases for tags, but what are the best practices for tagging AWS resources? In order for your organization to effectively manage resources (and your monthly AWS bill), you need to implement and adopt a thoughtful tagging strategy that makes sense for your business. The...

Read more
  • AWS
  • cost optimization
— September 26, 2018

How to Optimize Amazon S3 Performance

Amazon S3 is the most common storage options for many organizations, being object storage it is used for a wide variety of data types, from the smallest objects to huge datasets. All in all, Amazon S3 is a great service to store a wide scope of data types in a highly available and resil...

Read more
  • Amazon S3
  • AWS
— September 18, 2018

How to Optimize Cloud Costs with Spot Instances: New on Cloud Academy

One of the main promises of cloud computing is access to nearly endless capacity. However, it doesn’t come cheap. With the introduction of Spot Instances for Amazon Web Services’ Elastic Compute Cloud (AWS EC2) in 2009, spot instances have been a way for major cloud providers to sell sp...

Read more
  • AWS
  • Azure
  • Google Cloud
— August 23, 2018

What are the Benefits of Machine Learning in the Cloud?

A Comparison of Machine Learning Services on AWS, Azure, and Google CloudArtificial intelligence and machine learning are steadily making their way into enterprise applications in areas such as customer support, fraud detection, and business intelligence. There is every reason to beli...

Read more
  • AWS
  • Azure
  • Google Cloud
  • Machine Learning
— August 17, 2018

How to Use AWS CLI

The AWS Command Line Interface (CLI) is for managing your AWS services from a terminal session on your own client, allowing you to control and configure multiple AWS services.So you’ve been using AWS for awhile and finally feel comfortable clicking your way through all the services....

Read more
  • AWS
Albert Qian
— August 9, 2018

AWS Summit Chicago: New AWS Features Announced

Thousands of cloud practitioners descended on Chicago’s McCormick Place West last week to hear the latest updates around Amazon Web Services (AWS). While a typical hot and humid summer made its presence known outside, attendees inside basked in the comfort of air conditioning to hone th...

Read more
  • AWS
  • AWS Summits
— August 8, 2018

From Monolith to Serverless – The Evolving Cloudscape of Compute

Containers can help fragment monoliths into logical, easier to use workloads. The AWS Summit New York was held on July 17 and Cloud Academy sponsored my trip to the event. As someone who covers enterprise cloud technologies and services, the recent Amazon Web Services event was an insig...

Read more
  • AWS
  • AWS Summits
  • Containers
  • DevOps
  • serverless
— July 11, 2018

AWS Certification Practice Exam: What to Expect from Test Questions

If you’re building applications on the AWS cloud or looking to get started in cloud computing, certification is a way to build deep knowledge in key services unique to the AWS platform. AWS currently offers nine certifications that cover the major cloud roles including Solutions Archite...

Read more
  • AWS
— June 26, 2018

Disadvantages of Cloud Computing

If you want to deliver digital services of any kind, you’ll need to compute resources including CPU, memory, storage, and network connectivity. Which resources you choose for your delivery, cloud-based or local, is up to you. But you’ll definitely want to do your homework first.Cloud ...

Read more
  • AWS
  • Azure
  • Cloud Computing
  • Google Cloud