Amazon Web Services - IAM in Simple steps

It would be the very first step to understand and define the Identity and Access Management for your services up and running on Amazon Web Services.

What is IAM?

The official documentation says - You can use IAM to control who can use your AWS resources (authentication) and how they can use resources (authorisation).

A bit complicated? Let's break IAM down to I + AM ...

What is Identity?

It simply describes WHO, very much like stakeholders of your services.

What is Access Management?

It describes that WHO - identity are
1. allowed/denied to access
2. on WHICH resources,
3. for WHAT purposes, and
4. on WHEN conditions.

You can read the official documentation of IAM at and a whole bunch of other explanations on Internet. But, I am here to emphasise on how we implement the AWS IAM with simple steps to satisfy the business needs.

Analyse your business

Identify your stakeholders - Identities

I will take Music streaming service business as an example that I understand most.

A stakeholder is a party that has an interest in a company. Stakeholders can be internal or external. So, focus and list all the stakeholders who currently involves in your business.

  1. Internal
    1.1. Owners (Could be the co-founders)
    1.2. Manager (Could be the CTO or COO or CFO)
    1.3. Employees (May not have one in startup)
  2. External
    2.1. Customers
    2.1.1. Subscribers (Could be free or premium)
    2.2. Suppliers
    2.2.1. Music copyrights holders (Could be composer, singer, producer or label company).

Read more about stakeholders at

Understand your Resources

AWS contains a broad range of cloud services, products, and resources available for delivering your services. This doesn't mean we need to use all of them. Hell, no. To know which resources are better for your business, build up three or four solutions using a variety AWS resources. Then, choose one that suits you most.
I choose the most suitable solution for my music streaming startup by combing these four AWS services altogether.
1. Lambda cloud functions for server-less functions,
2. AWS API Gateway for app api endpoints,
3. DynamoDB for database, and
4. S3 Bucket for file storage.

You can explore all available AWS products at

How will you give them Access?

We will again re-use the identities list above to define how they should be given access to the services.

  1. Internal
    1.1. Owners - They should be given full read/write access to your services. But if they are non-tech people who are only interested in AWS billing and reporting, they should be fine with Manager level role. With full access, they can be develop, monitor and amend all of AWS services. So, it is a great risk if it is given to all people this kind of access. Every team should have at least one full read/write root access to all services to control every resources nevertheless.
    1.2. Managers - They will be given selective permission to your services of specific kind. For example, if this is for CFO, he/she should be fine with full read access permission to AWS billing section. If this is for CTO, only programatic access permission to all AWS services would be fine.
    1.3. Employees - They would have the least permission to your services internally. For example, for a developer, only programmatic access permission to selective AWS services, such as full write access to one of the three AWS s3 buckets, or write access to one of the three AWS EC2 servers instances, etc....
  2. External
    2.1. Customers
    2.1.1. Subscribers - When it comes to External, most of the permission are given read only access first. More permissions should be added only when needed. For example, subscribers must be given read access permission to AWS s3 bucket to access audio files but not write access.
    2.2. Suppliers
    2.2.1. Music copyrights holders - They have similar permissions - mostly - as subscribers as they both are external stakeholders.

Less is More - It is a best practice to define the policy when you really need one.

Let's take a walk

AWS Management Console

AWS Management console allows you and your team to access and manage Amazon Web Services through a simple and intuitive web-based user interface. So, it is very likely that you will spend most of your time in this console to develop, amend and monitor your services. Login to your AWS console with this link with your username and password.

IAM Management Console

Within AWS Management Console, there are many individual consoles for each product and service. For example, if we want to define Identities and Access Management for our services, we go to IAM management console, with this link

  1. In IAM Management Console, you will see the following screen. IAM Management Console
  2. Click on the customise button under IAM users sign-in link, and enter your company name, pancasikha in my case. Then the link will be IAM users sign-in link

On-boarding your team members to Company's console

Suppose, you have a team of three members, and who are willing to explore all AWS services and do things altogether. That's fine. Let's create users for yourself and your team members as administrators who have full access to AWS.

  1. First click on Users tab, and click on Add user button. Add IAM user
  2. Enter user details. There are two access types that you can choose. If you are intended to use the programmatic access from your local machine terminal (or) command line (or) SDK, please check at programmatic access option. You will be given an access key ID and secret access key. With only AWS Management Console access, you will be given only a password to login. Enter user details
  3. Choose the permission as AdministratorAccess to provide full access to AWS services and resources. Choose permissions
  4. Review the user details that you are going to save along with its permissions. Review
  5. After clicking Create user, you will the following screen. It is important to write down all the access key ID, secrete access key and password at a secure place. Because the secrete access key and password will be shown only once. Success IAM users

If you are adding a CFO who is interested only in billing, you just have to repeat the above process with slight permission changes in step 2 and 3 like below.
1. Give console access only as he would not do coding.
2. Give permission to only billing section.


After you created the IAM user accounts for your team members, you can either send the instruction by email or any other way. Then, your team member can access to AWS Management Console with their user assigned username and password at

What's next?

In this post, we created some IAM user accounts for the team members (internal stakeholders) to access to AWS Management Console. There are external stakeholders left to create user groups and set permissions to your services. But I encourage you to create that kind of permission when needed while we are creating the services.

Thanks for giving your time to read this post. Hope this help you a bit to start learning AWS IAM.

References -

Nay Win Myint

Founder and CEO of Pancasikha Music Streaming Provider, JavaScript full-stack and Android developer and Graphic designer.

Rangoon, Myanmar