Identity and Access Management
Start course

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:

  1. Infrastructure services
  2. Container services
  3. 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


Hello, and welcome to this lecture, where we will look at how the IAM service is used to help implement security across both container and abstract services.

IAM is tightly integrated with both of the shared responsibility models, and both of them require you to understand the different methods of using IAM to implement the different security controls around these services.

This lecture will not cover how to create and setup these controls. More information on how to do this can be found within our existing courses and labs, Introduction to IAM, and Advanced Roles and Groups Management Using IAM.

Regardless of the service, you must be familiar with AWS IAM. This will allow you to control who has access to which services and also under which conditions. IAM policies allow you to configure conditional access. For example, configuring access only during set time periods or from a specific IP address.

IAM enforces multiple methods of authentication and authorization against resources within your AWS environment. Detailed information on this subject can be found in our existing course entitled Understanding of AWS Authentication, Authorization, and Accounting.

So let's take a look at how IAM can help to control access to our container services, looking firstly at RDS.

An authenticated identity whether that be a user within your AWS account, a user from another account, another service, or even a federated user from your on-premise Microsoft active directory environment, the identity can access your RDS instance providing they have authorized permissions to do so. Using the correct permissions and access control, you are able to grant or restrict access on a granular level within RDS. For example, you can specify who can create an RDS database, who can access it, and who can run snapshots, et cetera, all through using IAM policies attached to the user, group, or role. As I said earlier, these permissions can even be based on specific conditions. For example, only to allow access at a specific time of day or from a specific IP address.

IAM policies are JSON formatted files. The following policy example only allows the user to create an RDS instance using the MySQL as the database engine type using the Condition parameter.

RDS permissions can only be given through IAM policies. There are no resource based policies that can be applied like it's possible within S3, such as bucket policies or S3 ACL's.

You must review who should have access to your database along with the correct level of permissions. Be as granular as possible when looking at data security across your databases. For improved management, create groups and roles, and apply permissions to these rather than individual users.

EMR also uses IAM to control access to its resources, such as the clusters and the data itself, again with policies, groups, and roles that we have already discussed. To understand the full level of access that can be granted or denied, see the EMR documentation provided by AWS.

By default, when an IAM user launches a new cluster, it is restricted to only that user. No other IAM users are ever to see the clusters; however, there is an option to make the cluster visible to all IAM users if required.

To help you manage permissions for EMR within IAM, you could always implement the AWS managed policies and assign them to users, groups, or roles. If they do not fully fit your requirements, then you can copy, edit, and customize these policies as required, which saves a lot of time and effort. And this applies to all services discussed within this lecture, and these AWS managed policies are a good source to base your permissions upon.

Looking at our abstract services, we can apply all of the same IAM security controls that we have already discussed; however, there are some differences worth noting. For example, when we look at S3, we can implement additional resource based access control methods, such as bucket policies and access controllers, which can specify permissions at an object level given granular access. When there are conflicting access permissions between IAM and resource based permissions, then access will be granted on a least privileged basis.

So, for example, the user John may have access of our IAM policy that grants access to delete objects within bucket CA-Lecture. In addition to this, there is a bucket policy attached to a bucket CA-Lecture that explicitly denies the principle John to delete objects. If John tried to delete an object within this bucket, he would be denied as access is granted based on least privileged and a denial will always take precedence over an allow.

As we are already aware, IAM allows you to create very specific permissions against different services for access. DynamoDB is no exception, and, in fact, with IAM, you can even grant access to specific rows within a DynamoDB table for specific users given a fine grained access control on the database itself.

As you can see, there isn't a huge amount of difference between how IAM is used to manage authentication, authorization, and access control to both container and abstract services. IAM is fundamental in granting users and services access to resources within AWS.

This access control centers around the following components of IAM:

  • Users
  • Groups
  • Roles, and
  • Permissions

Understanding how these interact with each other is imperative in applying an effective security policy from an access control perspective. Like I mentioned earlier, we have courses on IAM that go into these details in great detail, and I highly recommend you take these courses.

In addition to these IAM components, other services such as S3 may have their own resource level permissions, which you should invest time into understanding in order to help you add another layer of security to your data, and this may be required for specific governance controls depending on the data being used.

That brings us to the end of this lecture, and coming up next, we take a brief look at how some of the services have built-in functionality to help you secure your data. Understanding the services you're working with is just as important as understanding the security features offered by other AWS services such as IAM.




About the Author
Learning Paths

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 150+ courses relating to Cloud reaching over 180,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.