IAM(Identity access management is the service where you manage uses groups and access policies for your AWS account.You can manage

  • Users
  • Groups
  • Roles
  • IAM Access Policies
  • API keys

Specify a password policy as well as manage MFA requirement on per user basis.

By default, any IAM user created do not have any access. We have to provide access explicitly.

When a new AWS root account is created, it is  ” best practice” to complete the tasks listed in IAM under ” Security Status”

  • delete your  root access keys
  • Activate MFA for your root account
  • Create individual IAM user
  • Create user groups to assign permission
  • Apply the IAM password policy

To access the console login link for a user in AWS go to IAM>USERS> and click on the username for which you want to get console link. This will take you to user summary page. Click on “Security Credential” Tab in the summary and here you can see “Console login link”

IAM Policies

  • A policy is a document which states permissions for a particular user.
  • An explicit deny policy will always override the explicit allow policy. This is useful if a user has 10 policies attached and granting him access to various resources, then a single deny policy for all the resources will override them all. We do not need to individually remove each allow policy.
  • Some predefined policy templates are provided by the IAM which can be used straightforward
  • Administrative access: Full access to all AWS resources.
  • Power user access: Admin access without user group management
  • Read-only access:  AWS view resources policy.
  • Policies can never be attached to the AWS resources.We have roles for that purpose.


  • Users can be created in AWS from IAM resource.
  • For a new user created there is no access provided to the same. All access need to be provided by means of policies attached to the user.
  • When creating a user, policies can be attached or when after creating the same you can attach policies.
  • Multiple policies can be attached to the same user
  • User credentials shall never be stored on the EC2 instances.


  • We can make user groups in AWS using  IAM. We can even apply policies to the groups which will also take effect on the users.
  • Groups are the better way to manage several users altogether. Using Groups allows managing AWS resources more easily.


  • In case you want to work with AWS services and wish to assign then access to the resources, you cannot do same using AWS policies as policies cannot be attached to the  AWS services. For example, how will you provide access to an EC2 instance to AWS S3 bucket? You need roles for that.
  • A role is something that another entity can assume, and when doing so, it gets specific permissions defined by the role.
  • You can even store your access credentials on the EC2 instance and use the same to access S3 from it but that will be a wrong practice. You should create ROLE with S3 access and make EC2 instance to assume that role.
  • Other users(NON-AWS)  can assume a role for temporary access to AWS accounts and resources through having something like an Active directory or single sign-on.
  • using roles we can also provide cross-account access, where a user from one account can assume a role with permissions in other accounts.
  • Earlier for EC2 instance you must had to attach the role during instance creation process and could not modify that later on. But now you can attach a role to EC2 instance even after creating it or you can also change the existing role.
  • You can only attach one role to an EC2 instance.

IAM Security Token Service(STS)

  • STS allows us to create temporary security credentials, which provide trusted uses access to the AWS resources.
  • These temporary credentials are short-term and can be active from few min to several hours based on requirement.
  • STS is only accessible through API and cannot be contacted through AWS dashboard or console.
  • When we assign roles to the resources , it’s basically STS that works in the background.  For example, when a role is assigned to the EC2 instance for accessing the s3 storage, it’s basically STS that helps EC2 to access the S3.
  • Here role asks the  STS to generate temp access for the EC2 on S3 as per the policy attached to the role.
  • Third party authentications also use IAM security token service to provide access.


  • API access keys can be used to make programmatic access to the  to the AWS services and resources from:
    • AWS SDKs
    • AWS  CLI
    • AWS windows  tools for PowerShell
    • Direct HTTP calls
  • i.e. You can use IAM access keys to connect to AWS resources through CLI, sitting in your own network.
  • Always note that API keys are only available one time:
  • When you create a new user or  have to reissue the keys
  • In AWS console if you try to check access keys , you will only find access key id but not secrete key ID.











Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: