If you’re new to AWS, chances are your experience goes something like this:
Create a new AWS account
Log into the AWS console as the root user
Build and test things, everything works fine
Deploy an app or feature, everything falls apart
We’ll explain AWS Identity and Access Management (IAM) in an easy-to-understand way. IAM is a servic
e used to securely control access to AWS resources. It controls authentication (who) and authorization (w
hat they can do).
There are four main concepts in IAM: users, groups, roles, and policies. Let’s go through each one step b
y step in the AWS console.
Users
In the IAM console, click on "Users" and add users like "Michael Scott" and "Dwight Schrute". Specify thei
r access type (programmatic or console) and set passwords. You can also add tags to organize users.
Groups
In the IAM console, click on "Groups" and create groups like "Developers", "Testers", and "Admins". Add
users to these groups.
Roles
In the IAM console, click on "Roles" to create roles with specific permissions. Roles are similar to users, b
ut they don’t have credentials. They can be assumed temporarily by trusted entities.
Policies
A policy specifies who can do what to which resources and when. You can create policies for various use
cases and attach them to users, groups, or roles.
By attaching policies to users and groups, you control their permissions to access AWS resources.
Everything basically and there we go now backing up to roles since we hadn’t really talked about policies
previously. I didn’t want to get into roles too much, but let me just show you how to quickly create a role.
So, I have some roles in here from other work that I’ve done. You might not have any on your side, that’s f
ine. But you can always create a role. The common use case here is that we have a team at the company
that does ecommerce, and their EC2 instances need the ability to access CloudWatch and S3.
So, we’re going to create a role for those instances to assume at startup time.
Common use cases for roles are EC2. And then, down here, next permissions, we’ll attach policies similar
to what we just did with the users and groups. This one will be CloudWatch. And there should be one for
CloudWatch Logs full access.
Then, the other one, let’s say these instances are going to need S3 access, but we can get by with read-o
nly. This one right here, I’ll select that. Next, tags. Again, we’re going to skip this, but it’s a good way to ke
ep things organized. And on the review screen, this is where you’re going to give your role a name.
So, maybe this is "ecommerce service role". We’ll create the role. And now, when we go to start up a new
EC2 instance, it can assume this role, which is going to let its applications access S3 and the CloudWatc
h logs without needing to worry about credentials when the application is running.
Alright, we’ve covered quite a bit. So, let’s summarize here. We talked about users and groups. Users are
Create a new AWS account
Log into the AWS console as the root user
Build and test things, everything works fine
Deploy an app or feature, everything falls apart
We’ll explain AWS Identity and Access Management (IAM) in an easy-to-understand way. IAM is a servic
e used to securely control access to AWS resources. It controls authentication (who) and authorization (w
hat they can do).
There are four main concepts in IAM: users, groups, roles, and policies. Let’s go through each one step b
y step in the AWS console.
Users
In the IAM console, click on "Users" and add users like "Michael Scott" and "Dwight Schrute". Specify thei
r access type (programmatic or console) and set passwords. You can also add tags to organize users.
Groups
In the IAM console, click on "Groups" and create groups like "Developers", "Testers", and "Admins". Add
users to these groups.
Roles
In the IAM console, click on "Roles" to create roles with specific permissions. Roles are similar to users, b
ut they don’t have credentials. They can be assumed temporarily by trusted entities.
Policies
A policy specifies who can do what to which resources and when. You can create policies for various use
cases and attach them to users, groups, or roles.
By attaching policies to users and groups, you control their permissions to access AWS resources.
Everything basically and there we go now backing up to roles since we hadn’t really talked about policies
previously. I didn’t want to get into roles too much, but let me just show you how to quickly create a role.
So, I have some roles in here from other work that I’ve done. You might not have any on your side, that’s f
ine. But you can always create a role. The common use case here is that we have a team at the company
that does ecommerce, and their EC2 instances need the ability to access CloudWatch and S3.
So, we’re going to create a role for those instances to assume at startup time.
Common use cases for roles are EC2. And then, down here, next permissions, we’ll attach policies similar
to what we just did with the users and groups. This one will be CloudWatch. And there should be one for
CloudWatch Logs full access.
Then, the other one, let’s say these instances are going to need S3 access, but we can get by with read-o
nly. This one right here, I’ll select that. Next, tags. Again, we’re going to skip this, but it’s a good way to ke
ep things organized. And on the review screen, this is where you’re going to give your role a name.
So, maybe this is "ecommerce service role". We’ll create the role. And now, when we go to start up a new
EC2 instance, it can assume this role, which is going to let its applications access S3 and the CloudWatc
h logs without needing to worry about credentials when the application is running.
Alright, we’ve covered quite a bit. So, let’s summarize here. We talked about users and groups. Users are
