Hello, and welcome to this lecture, where we shall look at what AWS abstract and container services are, as well as the differences between them.

So, before we get into the nitty gritty of security contact, it's important that we understand what AWS defines as these abstract and container services. There was a chance that when I mentioned container services, you may immediately been thinking of AWS EC2 Container Service, knows as ECS, and its association with Docker; however, this is something completely different, as I already explained during this lecture, but I just wanted to clarify that point straightaway.

Both container and abstract services can be seen as different service classifications. We are aware of AWS service categories which can be seen from the AWS Management Console such as Compute, Storage, and Database, but the classifications that are referred to are not listed or defined within the Management Console. So, what are they?

Let's start by looking at what is defined by AWS Container Services.

Services that fall under container services have the following characteristics:

• the service itself runs on separate infrastructure instances, such as EC2.
• AWS is responsible for managing the operating system and the platform.
• A managed service is provided by AWS, which is typically the service itself for the actual application which are seen as containers.
• As a user of these container services, you have a number of management and security responsibilities, including managing network access security, such as network access control list rules and any firewalls.
• Also, platform-level identity and access management where it exists.
• Examples of AWS container services include Relational Database Service, Elastic Mapreduce, and Elastic Beanstalk.

Now, if we take a lot of the characteristics of abstract services to see how these compare ...

• These services are removed, abstracted, from the platform or management layer which cloud applications are built on.
• The services are accessed via endpoints using AWS application programming interfaces, APIs.
• The underlying infrastructure, operating system, and platform is managed by AWS.
• The abstracted services provide a multi-tenancy platform on which the underlying infrastructure is shared.
• Data is isolated via security mechanisms.
• Abstract services have a strong integration with IAM, and examples of abstract services include S3, DynamoDB, Amazon Glacier, and SQS.

So, as you can see, the main differences between the two relate to responsibilities, control, and the level of administration and customization you have over the chosen service. Container services provide you with a greater level of control and responsibility than those of abstracted services, largely due to the fact they are not providing shared tenancy of the underlying service infrastructure, whereas abstract services do. Also, abstract services are not typically deployed within specific availability zones, as they are accessed via endpoints and so are abstracted from your VPC infrastructure.

As listed within these two definitions, there are some boundaries between responsibilities of security between you and AWS, and this is an important point. So let's look at this in greater detail, as it will help you understand and define the differences between the two.

One of the main principles of AWS security is that it operates its security processes via a model called the AWS shared responsibility model. This dictates which security controls are AWS's responsibility and which are yours. Now, depending on the service being used and deployed within AWS, the boundaries of responsibilities will vary. When planning and architecting your security policies, it's essential you have a clear understanding of where these boundaries lay for difference services.

There are three main models that AWS uses to define these responsibilities, these being:

1. the shared responsibility model for infrastructure services
2. the shared responsibility model for container services and
3. the shared responsibility model for abstract services.

By taking a look at each of these models, we will be able to clearly see the differences. So let's start by looking at the first model, based upon infrastructure, which includes services such as EC2. We will see how the level of responsibility shifts as we move onto container and then abstract services.

Although this course does not cover infrastructure services, I just want to graphically show you the change of responsibility as we go through the different models.

As we can see from this model, it's down to you to decide how secure you want your resources to sit in the cloud while AWS guarantees the global security of the cloud.

Looking at AWS responsibilities first, this covers the global infrastructure elements: regions, availability zones, and edge locations, and also the foundation of their services, covering compute, storage, database, and network.

AWS owns and controls access to their data centers, where your data resides. This covers physical access to all hardware and networking components, and any additional data center facilities, including generators, UPS, power distribution units, computer room air conditioning, and fire suppression systems. Essentially, AWS is responsible for the components that make up the cloud. Any data put into the cloud then becomes your responsibility.

So moving onto your responsibility, and as I've just mentioned, securing what goes into the cloud falls upon you. This covers both client and server encryption and network traffic protection. All the way up to the 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 the business or on existing controls you may already have in place. For example, it's up to you if you want to implement network access control lists, or NACLs, or encrypt your data.

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.

Now, we've covered this first model. Let's see the shift of responsibility as we start to look at container services.

Straightaway, we can see that both platform and application management, along with any operating system and 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. Note that firewall configuration remains the responsibility of the end user, which integrates at the platform and application management level. For example, RDS uses security groups of which you would be responsible for configuring and implementing.

Now, let's look at the shared responsibility model for abstract services.

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 responsible for using IAM tools to apply the correct permissions, both at the platform such as S3 bucket policies, and IAM user and group level.

As we progress through each of these models, it's clear to see that the level of control and responsibility shifts more towards AWS than that of the customer. So how does that affect how we apply security around these services that fall into the container and abstract classifications? How can we ensure that when we use these services, tight integration of security controls are applied? Coming up in the next lecture, we will address these questions.

 

Lectures:

• AWS Security Best Practices
• AWS Abstract and Container Services
• AWS Encryption at rest and in transit
• Network segmentation
• Identity and Access Management
• Built-in Service Security Controls
• Summary