1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. AWS Solutions Architect Associate Level Certification Course - Part 1 of 3

Introduction to IAM


The AWS Solutions Architect Associate Level Certification
Overview about AWS
AWS Elastic Compute Cloud
AWS Simple Storage Service
AWS Identity and Access Management
Start course

AWS certifications are among the cloud industry's most valuable, and the Solutions Architect Associate Level exam is the jump off point for the whole series. Once you've mastered associate level material, you'll be comfortable designing and deploying fault tolerant and highly available systems on AWS, estimating costs and building cost control mechanisms, and choosing just the right blend of services for any project you're asked to provision.

The first course of this three-part certification exam preparation series, besides offering a good general overview of AWS, focuses on the core AWS services: EC2, EBS, S3 and IAM. The second course will discuss networking and include a practical design and deployment of a real-world application infrastructure. The third and final course will explore data management and application and services deployment.

Who should take this course?

This is an advanced course that's aimed at people who already have some experience with AWS and a familiarity with the general principles of architecting cloud solutions.

Where will you go from here?

The self-testing quizzes of the AWS Solutions Architect Associate Level preparation material are a great follow up to this series and a pretty good indicator of your readiness to take the AWS exam. Also, since you're studying for the AWS certification, check out the AWS Certifications Study Guide on our blog.


In this video, we're going to explore AWS's identity and access management or IAM tools. In simple terms, IAM lets you control access to all services associated with an AWS account. By creating accounts and groups for your users and by assigning carefully designed roles to each active service, you can determine precisely how every element of data is shared. Let's click on the IAM link. You can see from the column of links on the left that for our purposes right now, IAM divides its focus among groups, users, and roles.

While you must create an account for each participating team member, and as we'll soon see, you can define the rights and permissions individually. It could be far more efficient to organize your account into groups, assigning specified permissions to each group. And then, you can simply associate each user with the groups that provide the access he or she will need. So let's create some fictional users.

AWS will provide each user account with a unique access key ID, and secret access key to identification and authentication. You'll obviously have to securely transfer this information to each of your users.

Now they exist. You could click on any one of your users and attach a new user policy to directly define his permissions. But as we mentioned, this could be done far more efficiently through groups. So let's now click on groups.

Click on create new group, and let's create a group called users, whose members will need access, say, to all the EC2 instances on your account. You can see that Amazon provides us with a wide range of prebuilt policy templates, covering most of the likely scenarios we might need. Let's choose the Amazon EC2 full access template for our users group. Here, we're shown the actual code that drives this policy. We can see how the policy is divided into statements, separated by curly braces. Each statement has an action, that is which AWS service will be affected by the policy, in effect which could be to allow or deny, and resources, which specific elements of a service are included. In this example, the actual concern EC2, the effect will be to allow access, and the permission will extend to every EC2 resource. We will accept this policy, review the group configuration, and then create the group. Now we'll create a second group and call it admin.

This group will include only those users responsible for system administration. For the admin group, we'll choose the power user template. This simple policy as the negative connotation of not action implies, allows all actions, that is actions on all AWS services except for IAM, which you might want to leave only to the account root user, you. Again, you can refer the configuration and create the group. Now, we'll have to make the groups useful by actually adding users. Select the users group, then click on group actions and add users to group. Since we'd like all our users to have full EC2 access, we'll select everyone. Now deselect users and select the admin group instead. Again, we'll add users, this time selecting only our system administrator, Norm. He's the only one who will need the full access we associated with the admin group permissions. Let's take a quick look at the user's dashboard and click on, say, Alice. We can see that she doesn't yet have any user policy associated with her account, although we could add one if we need. But that her access has in fact been determined by a membership in the users group. Now we need to understand roles, AWS's tool for controlling the access and behavior of services and instances, rather than users or groups. As we'll soon see, Amazon offers three role types: services roles, controlling access to and from AWS services, like S3 or EC2, cross account access roles, allowing communication and data flow between services and separate AWS accounts, and identity provider access roles, allowing authentication via accounts from third party providers, like Google or Facebook. These identity provider access roles can be very useful in use cases that require you to provide temp reaccess to your services, and to processes and users who can't authenticate the normal way. Perhaps it's an employee of a company with which you do business, who needs to access your internal data. Or maybe a mobile app that has to be programmed to launch requests against your data. You can, for instance, select grant API access to SAML providers, where you'll be prompted to configure a specific SAML provider to allow authenticated on demand access. Similar temporary WS console access can also be arranged. Let's now take a look at AWS service roles. The Amazon EC2 role for instance, would allow your EC2 instances to access other AWS services. How much access it will have is determined by any policy templates you choose to associate with it. You could handcraft your own custom policy, or select one of Amazon's template policies.

Let's choose the administrator access template, which allows all actions against any resource, the most liberal of policies possible. We can review this role policy and create it. At any time, you can click on a role in the roles dashboard to view and manage its configuration. You should also be familiar with the policy simulator. Let's click on group, and then the admin group. We see it's only user Norm listed. We'll scroll down the list of policies of which there's currently only one, power user access. Click on manage policy to display the actual policy code.

Now however, click on the IAM policy simulator link. All the users in our account are listed on the left, except the root user, who always has full permissions over everything. We click on Alice and note that the Amazon EC2 full access policy is associated with her account. Now we'll select the service against which we'd like to test Alice's access. Let's choose EC2. Now we'll select a specific EC2 associated action to test. This will become most useful in cases where we've tried to apply complex, partially open policies to an account. We'll just choose a few actions pretty much at random. Click on an empty space to leave that popup, and click run simulation. We can see that all three actions are allowed, which considering that Alice has full EC2 access, is what we would have expected. If on the other hand, we tested Alice's ability to delete users through IM, we'll see that this is denied her. Again, exactly as we'd expect.

About the Author
David Clinton
Linux SysAdmin
Learning Paths

David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.

Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.

Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.

His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.