IAM Roles
Start course

In this course, we shall be looking at how AWS provides many different means of authentication.

Learning Objectives

  • The different methods of authentication that can be implemented when using AWS
  • The difference between username/password and Multi-factor authentication
  • How to configure MFA authentication
  • The process in which programmatic authentication is managed
  • How IAM roles can be used to authenticate and authorize EC2 instances to access resources
  • How Key Pairs are used to authenticate you to newly created EC2 instances
  • The different options available with regards to federated authentication

Intended Audience

  • AWS Administrators
  • Security Engineers
  • Security Architects
  • And anyone who is looking to increase their knowledge of security and authentication within AWS


You should have a basic understanding of AWS IAM and what the service is used for. It would also be advantageous if you had some basic hands-on experience of Amazon EC2, but it is not essential.


IAM roles provide an efficient and secure solution in authenticating and authorizing access. And their usage is considered a best practice when associated with applications running on EC2 instances that require access to other resources instead of embedding credentials into the application itself. IAM roles are objects created within IAM and have a defined set of permissions associated to them, much like a normal user or user group would have. 

However, they do not represent an identity like users do, they are simply an object with a list of authorized permissions associated. When working with Amazon EC2 instances, you can either associate a role to the instance during its creation or when it's up and running. Once you have associated an EC2 instance with your IAM role, your application instances can then access and make API calls within AWS that are authorized by the permissions given by the role. 

By having a role associated to the EC2 instance, there's no need to apply access key IDs as we did previously. Instead, when your application attempts to access an AWS resource, dynamic temporary access keys will be supplied by the role to determine if access is authorized. Roles are not just for instances, they can also be assumed by a user, allowing them to switch from their current set of permissions to take the permissions given by the role. It's important to note that permissions from the user and the IAM role are not amalgamated. 

The permissions are swapped from the user to the IAM role. To switch to a role, permissions must first be given to the user allowing them to switch to that role, which authorizes them to use this new set of temporary permissions. Roles also take care of access key rotation as well, so there's no need to perform your own rotation of access keys. 

It's more efficient to use roles for EC2 instances when requiring programmatic access over an IAM access key ID. This is because if you have multiple applications running on multiple EC2 instances, then when it comes to key rotation, you have a number of applications to associate the new keys to. To learn more about IAM roles, please see our existing course here.


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.