AWS Shared Responsibility Model

AWS CLOUD

Share Post Now :

HOW TO GET HIGH PAYING JOBS IN AWS CLOUD

Even as a beginner with NO Experience Coding Language

Explore Free course Now

Table of Contents

Loading

In this blog, we will learn about AWS Shared Responsibility Model.

Almost all of the services and applications we see around us are cloud-based. Many organizations and enterprises host their data, applications, and services in the cloud. With such high demand, many students are preparing to work with cloud technologies. However, without comprehensive cloud security training, knowledge is incomplete.

Various services are active in the cloud simultaneously. Both cloud vendors and customers share some responsibility which we will learn with the following topics:

What is the Shared Responsibility Model?

AWS Shared Responsibility Model

The Shared Responsibility Model is a cloud security structure that specifies the security requirements of cloud service providers and users to ensure accountability. Simply said, a cloud vendor offers a variety of cloud services to its customers. One offers the service, while the other consumes it. The vendor is accountable for the service provided, while the user is responsible for the service consumption.

Levels of Abstraction in Cloud Computing

Security responsibilities can’t be common in all scenarios. Each scenario can demand additional security and responsibility. So, levels of abstraction are the area that pertains to the responsibilities. The levels of abstraction are just the other name for cloud computing service models: IaaS, PaaS, and SaaS.

Cloud Service Models

  • Infrastructure as a Service (IaaS) – Infrastructure as a Service is the lowest level of abstraction. Under IaaS, cloud vendors allow users to use their data centers, including servers, storage, network, hardware, and virtualization. The user has a great degree of control but more responsibility for security.
  • Platform as a Service (PaaS) – Platform as a Service is the next level of abstraction that enables users to build and run applications. Under PaaS, including the Infrastructure, the cloud vendor also provides a platform to build, run and manage applications.
  • Software as a Service (SaaS) – Software as a Service is the highest level of abstraction. Under SaaS, the cloud vendor hosts applications to make them available for the end-users or customers. SaaS removes the need for organizations to host applications in their private data centers.
  • Bare Metal Service – It is the final level of abstraction where the customer can use the hardware provided by the cloud vendor. It helps developers access the physical resources for their applications intended to run directly on hardware. For example, organizations can deploy EC2 instances to the AWS hardware instead of the virtualized environment.

Read More: Cloud Computing Service Model: IaaS, PaaS, and SaaS

AWS Shared Responsibility Model

The biggest challenge that organizations face is the confusion of the responsibilities leading to security compromisation. This confusion gives hackers a blind spot to attack, and many reports claimed the improperly shared security responsibilities as the culprit for various security incidents. Thus, Amazon Web Service (AWS) established the AWS Shared Responsibility Model to clarify responsibilities.

AWS Shared Responsibility Model

According to AWS Shared Responsibility Model, AWS is responsible for the Security of the Cloud and the customer is responsible for the Security in the Cloud.

  • AWS Responsibility: AWS is responsible for protecting the infrastructure that runs all the AWS services. In other words, AWS control, operate and manage the components from the host operating system and virtualization layer that is down to the physical layer in which the service operates.
  • Customer Responsibility: The customer’s responsibility depends on the AWS service used and the configuration they need to perform to secure that service. In other words, customers need to manage the guest operating system, including security patches and application software. Also, they need to configure the AWS-provided security controls like security groups, network access control, and IAM (Identity and Access Management).

The responsibility of both AWS and the customers varies with the service taken into use. So to make it more clear, we will discuss the shared responsibility model for some specific AWS services.

AWS Shared Responsibility Model for EC2

AWS Shared Responsibility Model for Amazon EC2

Elastic Compute Cloud or EC2 lies under infrastructure as a Service (IaaS), and the responsibility model for both cloud service provider and customer is as follows:

  • AWS Responsibility: AWS is responsible for the Infrastructure (Regions and Availability Domains) and services (compute, storage, database, and network) used with EC2.
  • Customer Responsibility: The customer is responsible for the security configuration or firewall (like security groups), guest operating system (like Ubuntu & Windows), applications & tools installed, client and server-side encryption, and customer data.

AWS Shared Responsibility for Containers

AWS Shared Responsibility Model for Amazon ECS

EC2 virtualizes hardware whereas container virtualizes the operating system and the responsibility model for both cloud service provider and customer is as follows:

  • AWS Responsibility: AWS is responsible for the Infrastructure (Regions and Availability Domains), services (compute, storage, database, and network), platform, and operating system.
  • Customer Responsibility: The customer is responsible for the security configuration or firewall (like security groups), Identity and Access Management (IAM), client and server-side encryption, and customer data.

Now, apart from AWS services, AWS Shared Responsibility also extends to IT controls.

Also Check Our blog post on AWS CloudHSM.

AWS Shared Responsibility of IT Controls

AWS and customers share responsibility for IT control management, operation, and verification, just as they do for IT environment responsibilities. AWS can assist clients by handling physical infrastructure controls, relieving them of the burden of operating controls. AWS control and compliance will assist clients in evaluating and validating their controls.

AWS Control Tower

The examples of controls managed by AWS, customers, and both are as follows.

Inherited Controls: These Controls are fully inherited by customers from AWS.

  • Physical and Environmental controls

Shared Controls: These controls apply to both the infrastructure and customer layers but from a completely separate perspective. AWS provides the infrastructure requirements, and the customer must provide their own control implementation within their use of AWS services. For example:

  • Patch ManagementHere, AWS is responsible for patching and fixing infrastructure flaws, whereas customers patch their guest operating systems and applications.
  • Configuration ManagementHere, AWS maintains the configuration of its infrastructure devices, whereas a customer takes responsibility for configuring their own guest operating systems, databases, and applications.
  • Awareness & Training – AWS trains AWS employees, whereas a customer must train their own employees.

Customer-Specific: These controls are solely the responsibility of the customer based on the application they are deploying within AWS services. Examples include:

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

Conclusion

Security should not be compromised at any cost, and AWS knows the importance of Cloud Security very well. We covered everything about the AWS Shared Responsibility Model and its importance in this blog and how it removes the confusion between the service provider and the customer.

To download the complete Certified AWS Solutions Architect Exam Questions Guide, click here

Related/Reference

Next Task For You

Begin your journey towards an AWS Cloud by joining our FREE Informative Class on Amazon Cloud Free Class by clicking on the below image.

AWS Job Oriented Free Class

Picture of mike

mike

I started my IT career in 2000 as an Oracle DBA/Apps DBA. The first few years were tough (<$100/month), with very little growth. In 2004, I moved to the UK. After working really hard, I landed a job that paid me £2700 per month. In February 2005, I saw a job that was £450 per day, which was nearly 4 times of my then salary.