Abstract & Container Services
The course is part of these learning paths
When implementing different AWS services and architecting them within your environments, whether it be production, test or dev, do you know your security responsibilities for these services?
It is very likely that you are using services from three different classifications, which each have very different boundaries for enforcing security between the customer and AWS.
These classifications are:
- Infrastructure services
- Container services
- Abstract services
The level of responsibility around these services are defined within three different AWS Shared Responsibility Models, and it’s essential when using AWS you understand your level of responsibility when it comes to applying security.
This course focuses on Container and Abstract services. The primary Container services we look at are: RDS, EMR and Elastic Beanstalk and the primary Abstract services include: S3, DynamoDB, SQS and Glacier.
The lectures within this course will define and guide you through the following areas to help you apply the correct level of security to your Container and Abstract services.
What are AWS Abstract & Container Services?: This lecture provides you with a clear understanding of what abstract and container services are within AWS. There is a clear divide between the two which must be understood as responsibilities around security is a key difference between them
Security Controls: Data at Rest and In Transit: Here we will take a look some of the available options and best practises to help you maintain integrity and protection around your data when at rest, in transit and held within a number of container and abstract services
Security Controls: Network Segmentation: In this lecture we look at how we can use the network infrastructure and architecture to connect and restrict access to our container and abstract services to increase security through a number of different controls
Identity & Access Management: IAM is heavily used for both container and abstract services and plays a key part in authorisation and authentication for access and management, this lecture looks at how IAM can be used to help protect access across your services
Built-in Service Security Controls: This lecture will briefly look at some of the service specific security controls that may not have been covered in the previous lectures that you can leverage to help secure you data and environment
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
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:
- the shared responsibility model for infrastructure services
- the shared responsibility model for container services and
- 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.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 90+ courses relating to Cloud reaching over 100,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.