14 Tips for Implementing the AWS Shared Responsibility Model


Dan Ennis CEO



The AWS Shared Responsibility Model  defines the security responsibilities of AWS and its customers when protecting cloud content and applications. Organizations should be aware that many of these tasks fall under their responsibility. This article provides a practical interpretation of the Model, explains where AWS responsibilities end and the customers’ start, and provides my top-14 pointers and tips for making sure you are properly fulfilling your security role when deploying applications on AWS EC2.

About the AWS Shared Responsibility Model

In its AWS Security White Paper AWS defines security responsibilities as follows:

“AWS is responsible for securing the underlying infrastructure that supports the cloud, and you’re responsible for anything you put on the cloud or connect to the cloud

Here’s how Amazon envisions it at a high level:



AWS Shared Security Responsibility Model
From: Amazon Web Services: Overview of Security Processes, November 2014


This model reduces your operational burden, because AWS operates, manages, and controls the components starting from the host operating system and virtualization layer, down to the physical security of the facilities in which the services operate.


AWS Responsibilities

  1. Securing the AWS Infrastructure
    As the cloud infrastructure provider, AWS is responsible for what they refer to as the “security of the cloud.” This includes the physical layer of the cloud including the compute, storage and network subsystems, operating and securing the data centers, AWS availability zones (AZs) and regions.
  1. Securing AWS Managed Services
    Managed services such as DynamoDB, RDS, Redshift or MapReduce benefit from end-to-end AWS management, so customers should not be concerned about most of the security configuration tasks such as patching and firewall configuration. Customers are still responsible for handling secure account credentials.


Customer Responsibilities

AWS customers are responsible for protecting any applications and services they deploy, referred to as “security in the cloud.” As an AWS customer you are responsible for protecting data, applications, operating systems and databases that you deploy on EC2 (as opposed to managed database services that are under AWS responsibility).  You are also responsible for access management, firewall configurations, server-side encryption, and more.

For example: for EC2 instances, you are responsible for managing the guest OS, including updates, security patches and applications. You are also responsible for any applications, software and utilities that you install on these instances, and for the configuration of the AWS-provided firewall, called a Security Group, on each instance. These are, in essence, the same security tasks you would perform on-prem.

The following AWS diagram illustrates the share of responsibilities:


Shared Responsibility Model Chart:

From: AWS Website


Checklist: Your Top-14 Tasks Within the AWS Shared Responsibility Model

Now let’s map the above chart into a set of feasible best-practices and tools. 


Operating System, Network and Firewall Configuration

 Configure AWS Security Groups (SGs): AWS provides Security Groups that serve as your virtual firewall, however, it is your responsibility to configure them for your EC2 instances. Associate SGs with your EC2 instances and configure rules per instance, or per group of instances.

  1. Leverage 3rd party companies to streamline SG configuration such as Dome9. This is essential or large-scale deployments.
  2. Configure AWS Access Control Lists (ACL): use ACLs as an optional security layer in addition to SGs, to control traffic in and out of a subnet. ACLs are intended for EC2 machines hosted on VPC. See Comparison of Security Groups and Network ACLs.
  3. Prefer deploying on VPC over EC2 classic. While VPC configuration may be more complex than EC2; e.g. when configuring public access, its security advantages are well worth the effort, as it provides additional granularity and flexibility in securing your deployment; for example by defining rules for both incoming and outgoing traffic vs. incoming only for EC2.
  4. Use AMIs for Platform Components: Use AMIs (Amazon Machine Images) instead of configuring a WordPress machine or a Linux Server from scratch. Buy a pre-hardened AMI for your system components to skip the security configuration work and reduce risk.


Platform, Application, Identity & Access Management

  1. Deploy Web Application Protection: You are responsible for protecting the application layer, which means that vulnerabilities in application code and in 3rd party code (e.g. WordPress plugins) fall under your responsibility. Failing to protect the application against vulnerability exploits allows attackers to compromise the web application and underlying sensitive data. Customers should deploy a dedicated solution such as a web application firewall (WAF) and make sure that the solution was designed for protecting AWS applications, deployed on AWS and leverages AWS services.
  2. Use industry best-practices for secure development and deployment: when deploying applications in the cloud use best practices including secure design and coding, incident response planning, pentesting, SAST/DAST systems etc.
  3. Use IAM (AWS Identity and Access Management) to limit access to your resources. Use the new IAM wizard “Managed Policies” to optimize user access permissions across your services.
  4. Prefer IAM Roles for EC2 over IAM users. When authenticating with AWS services APIs (e.g. to access S3) a common practice is to create an IAM user and generate an access key stored on a configuration file. This is bad practice because IAM permissions can be stolen if the EC2 instance is compromised. IAM Roles for EC2 are the preferred and secure way to authenticate with AWS services. For example, they can be defined per EC2 instance so when an instance is compromised it can be shut down. Here is a great article explaining about the security implications of IAM Roles for EC2


Customer Data

  1. Encrypt sensitive EC2 volumes by using Amazon EBS encryption. This will guarantee that any data stored on your EC2 and EBS instances is encrypted.
  2. Encrypt sensitive S3 buckets using S3-Managed Encryption Keys.
  3. You have the option to use S3 logging to track access to data, if needed.


General Application Security

  1. Use AWS Cloud Trail to track API access across your services. It will improve your ability to analyze security and compliance and will expose unauthorized API access.
  2. Define CloudWatch Alarms where needed – they are broad and generic and can be used to trigger an alert for nearly any service and parameter, such as RPS/PPS or bandwidth thresholds on Cloudfront, auto-scaling alarms when exceeding a predefined number of instances, or billing & budget limitations to make sure you stay within your planned monthly budget.



As you’ve seen, protecting AWS EC2 applications is not as difficult as it may initially seem. AWS and 3rd party vendors provide a broad set of tools to help you fulfill your role in the AWS Shared Responsibility Model.  There is obviously much more to this than the 14 items I’ve provided, but I hope this initial list can get you started. Feel free to write to me and suggest additional tools and best practices or to comment on my suggestions.

Thanks and be safe.