Who AM I?

Accessing a system or thing was and is always an issue that we have to solve. The system that we interact can be seen as a block box that includes a bunch of subcomponents. Our purpose is to enter the box and try to use these subcomponents. Assume that a second that we describe the human roles and their responsibilities, probably, the following sentences can be built:

  • I am a worker who access to the room 1 and can open/close the windows.
  • I am an engineer who can access the device inside the room, and who can see the health status of the device and replace it with the new one.

As seen above, all these sentences describe the identity and their permission on a resource. The number of the examples can be increased with respect to the use cases.

Considering these phases, it is possible to say that AWS IAM services apply a similar strategy to create this service under the hood. These descriptions until this point consider end users, however, any entity in the AWS ecosystem can possess them, e.g. a service while communicating with another service.

In the end, the main goal of AWS IAM is to build a system as granular as possible from the security perspective. AWS IAM provides only the security from the identity and access management. This does not mean all security perspectives are covered by IAM. If we visualize AWS resources as in the figure below, the whole purpose of the AWS is to split the resources in small chunks and for each of which define an access requirement and to reach the resources requires an identification. By doing that, all entities in the system and their actions can be tracked, which users can use which resources, and whether there is an abnormal behavior, etc.. In the end, this approach increases the visibility of the entities and their actions in the whole AWS ecosystem.

How does AWS IAM answer “who AM I” question?

The long version of IAM is Identity and Access Management, which means AWS must recognize first entity who interacts with the system, and then allow them to consume the services according to the given permissions on a specific resource. If we return the sentences in the previous section back, and trying it to understand how AWS IAM interpret it:

I am a worker who access to the room 1 and can open/close the windows.

  • Assuming that accessing the Room is the identification (authentication) process.
  • Worker represents here role or user
  • Window is the Resource/Object
  • Opening/Closing Windows can be seen as Actions

AWS IAM applies the same analogy indeed, just it defines differently as below:

Effect parameter has only two values, either Deny or Allow, whereas Action parameter shows what permissions are given e.e. Listing all buckets and getting bucket location. Resource indicates on which resource, in this case s3 bucket, can be applied these actions. Even you may sometimes see Principal for specific users if defined, or Conditions just for resources that fulfil requirements, these are just additional useful features and do not change the core concept of IAM.

You can ask what is the meaning of actions. In the following figure, a resource is given, and it is surrounded via belonging functions. You can image this resource/service provides all these functionalities. Some functions are red colored, which means, any permission are given. If you add one of it to the action list, then the red box will be green, e.g. ListAllMyBucket and GetBucketLocation are permitted functions.

Roles, Users, Groups and Policies

Roles, users and groups can be created in AWS IAM section for having different purposes. Even though they have different names, indeed, they share the similar goals, which is having access to a resource and perform actions on it. A user represents a person, whereas a group indicates a group of persons which have the same permissions. Role is different from them, since it focuses indeed a specific task or a bunch of tasks. For example, an admin can be represented as a role. Roles can be described as granular as possible, and they can be assigned to a user, groups or software entities in AWS such as AWS lambda.

In all cases and definitions depend indeed on policies that you saw already in the previous section. Policy is an JSON file that defines permissions for roles, users or group can access to a specific resource and operate only the permitted operations. A policy contains statements, which can be composed of many permissions. The following figure depicts a policy for an S3 Bucket, and user/role can list all buckets created by the user/role and the bucket location can be obtained.

The policy descriptions are not limited with the aforementioned keywords, there are many other terms such as Principal, Conditions, etc. that are described in AWS in detail. You can see those descriptions as supplementary explanations for the aforementioned core part.


In this tutorial, we attempted at analyzing the AWS IAM and its concept by given some daily used sentences. Afterwards, we discussed how AWS IAM interprets these sentences in its own architecture by adding real example. Apart from all this tutorial, the most interesting part for me is the structure of AWS IAM, since it has a similarity to SELinux users, which is quite old concept.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store