AWS IAM – Summary

This post will provide you a summary for AWS IAM (Identity and Access Management) service. It is recommended to read before the exam(CSA-Associate or CSA-Pro) to refresh the knowledge. The following topics are covered.

  • IAM Introduction
  • IAM Best Practices
  • Different Types of Policies
  • Policy Evaluation
  • Identity Federation
  • STS API Methods

IAM Introduction

AWS IAM is a global service that you can use to manage access to AWS services and resources. Access can be granted to IAM users, groups and roles using permission policies.

Long Term Credentials

When you create an IAM user, you can assign him/her Access keys and User passwords which are considered to be long term credentials. Long credentials do not get expired. So never expose them to anybody else!

Temporary Credentials

IAM Role, on the other hand, provides short term temporary credentials to whoever assumes the role. These credentials get expired within 15mins to 12 hours and need to be refreshed.

IAM Role can be assumed by an IAM User, Group, Another Role in the same or different AWS Accounts. It can also be assumed by AWS services like EC2, Lambda, etc… or it could be federated users like Users in Active Directory of an on-premises organization, Web identities (Facebook users, Twitter Users, etc..)

IAM Role

An IAM Role has two main parts. Permission policy and Trust policy. (Theses policies are JSON objects) The permission policy describes the permission of the role. Trust policy describes who can assume that role. (E.g. EC2 service, Lambda service, A specific AWS Account, etc…)

Once the IAM Role is assumed by an allowed entity, AWS STS (Security Token Service) provides the temporary security credentials to the entity. The temporary security credentials contain the following information.

  • Session Token
  • Access Key ID
  • Secret Access Key
  • Expiration

When an IAM user from a different AWS Account assumes an IAM role of another account (E.g. Using the Switch Account feature in AWS Console or using the API) the temporary credentials from STS will replace his/her existing credentials of the trusted account – The account he is from.

IAM Best Practices

Following are the best practices for using IAM service. They must be thoroughly followed as IAM is the centralized service for Security in the AWS platform.

  • Lock Away Your AWS Account Root User Access Keys
  • Create Individual IAM Users
  • Use Groups to Assign Permissions to IAM Users
  • Grant Least Privilege
  • Get Started Using Permissions with AWS Managed Policies
  • Use Customer Managed Policies Instead of Inline Policies
  • Use Access Levels to Review IAM Permissions
  • Configure a Strong Password Policy for Your Users
  • Enable MFA for Privileged Users
  • Use Roles for Applications That Run on Amazon EC2 Instances
  • Use Roles to Delegate Permissions
  • Do Not Share Access Keys
  • Rotate Credentials Regularly
  • Remove Unnecessary Credentials
  • Use Policy Conditions for Extra Security
  • Monitor Activity in Your AWS Account

For more information about the best practices, follow this link to the AWS documentation.

Different Types of IAM Policies

There are three major types of IAM policies used to control access in AWS.

  1. Service Control Policies
  2. Identity-Based Policies
  3. Resource-Based Policies

Service Control Policies

Service Control Policies (SCPs) are used to manage all the AWS Accounts in your AWS Organization. SCPs can be applied at individual AWS accounts level or at Organizational Units (OUs) level inside your AWS Organization to control the maximum permission. (Applying the SCP to an OU means applying the same policy to all the AWS accounts under that OU).

In order to apply SCPs, you must enable “All Features” in the organization. SCPs aren’t available if your organization has enabled only the consolidated billing features.

If multiple SCPs affects an AWS Account, the maximum permission is determined by the overlap.

You can either use Whitelisting or Blacklisting of permissions when using SCPs to control maximum permissions. Blacklisting permissions provides less admin overhead when managing many AWS accounts.

SCPs are not a replacement to AWS IAM policies. They are only used to control what a specific AWS account can or cannot do. IAM policies are still required to manage access for different entities within the AWS account.

If you blacklist a resource/service for an AWS account using SCPs, that cannot be accessed even to the root user of that account.

Identity-Based Policies

Identity-based policies are attached to an IAM user/group or a role. It specifies what the identity (user/group/role) can do. For example, you can allow an IAM user “John” to read from a certain S3 bucket (E.g. mybucket) and Deny spinning up any EC2 instances.

   "Version": "2012-10-17",
   "Statement": [
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": ["arn:aws:s3:::mybucket/*"]
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "*"   

We can set up quite granular access controls using Identity-Based Policies. For Identity-based policies, it’s not mandatory to mention the “Principal” – (to whom the policy gets applied to), as it is implied from the attached identity. Identity-based policies can be managed( Managed by AWS or Customer. These can be reused among many identities) or inline policies (Applied only to a certain identity).

Resource-based Polices

Resource-based policies are applied to a resource rather than to an identity. You can attach resource-based policies to S3 buckets, SQS queues, etc… With resource-based policies, you can specify who has access to the resource and what actions they can perform on it. Resource-based policies are inline only, not managed.

      "Principal": "*",

Above policy can be applied to the “mybucket” s3 bucket to Allow only read-only access to the content of the s3 bucket to anybody. Note that we must specify “Principal” – to whom the policy gets applied to. In the above policy, it’s anyone.

Policy Evaluation

When a principal tries to access an AWS resource, there could be multiple types of policies applied. (SCPs, Identity-based policies, resource-based policies). AWS evaluates all these policies before allow or deny access to the resource for the principle. The main logic behind policy evaluation is as follows.

  • The decision starts at Deny
  • Evaluate all the applicable policies to the resource and to the principal
  • Explicit “DENY” policies override any Explicit “Allow” policies
  • If there is no explicit “DENY” polices defined but only Explicit “Allow” polices, the access is granted to the resource
  • If there are no explicit policies defined for the resource (ALLOW or DENY) implicit “DENY” is applied by default. So the access to the resource is denied.

Evaluating Policies Within a Single Account

Following steps take place when an IAM User/Role try to access a resource within a single AWS account.

  • Check if Service Control Policies (SCPs) permits the action. If not Deny access immediately.
  • If SCP allows, then check the Identity-based policy(IAM policy) attached to the identity and the resource-based policy attached to the resource. For example, if IAM user, John is accessing an S3 bucket, check IAM policy attached to John and also check resource-based policy attached to that S3 bucket.
  • If either Identity-based policy OR resource-based policy allows the action, Allow John accessing the S3 bucket.

Evaluating Cross Account Polices

When a user from a different AWS account wants to access a resource of another AWS account then the policies are evaluated as follows.

  • Check if Service Control Policies (SCPs) permits the action. If not Deny access immediately.
  • If SCP allows, then check the Identity-based policy(IAM policy) attached to the identity and the resource-based policy attached to the resource.
  • If BOTH Identity-based policy AND resource-based policy allows the action, Allow the user to access the resource.

Identity Federation

You can create up to 5,000 IAM users per AWS account. Imagine your organization has 10,000 users who need access to an AWS account. First of all, it is not allowed to create 10,000 IAM users. Even if it was possible, administrating 10,000 IAM users can be a nightmare. This is where the identity federation comes into the play.

Identity federation means outsourcing identity management to an external party. It could be google, facebook, twitter, on-premises active directory. Google, Facebook, Twitter, etc.. are examples of Web Identities. Active Directory, on the other hand, is an example of a Co-operate identity manager.

Identity federation is based on the trust between AWS and the External Identity provider(Web or Co-operate). The process of AWS identity federation is as follows.

  • Create an AWS IAM role that can be assumed by a federated identity
  • Provide required permission to that IAM Role.
  • Configure AWS and the external IDP (Identity Provider)
  • If it is web identity like facebook or twitter, create an app on facebook or twitter and configure app ids and secrets in AWS
  • If it is corporate identity like Active Directory, upload metadata document or link metadata URL in AWS. Do the necessary configuration at the on-premises side as well.
  • When a user wants to access a resource in AWS, direct him/her to the login page of web identity (login with facebook, etc…) or the login page of Active Directory.
  • Once the user has successfully logged in, send a confirmation token to AWS. In the case of web identity, it could be id_token, If it is Active Directory it could be SAML assertion.
  • AWS will trust the assertion and allow the user to assume the IAM Role thereby access the authorized resources in AWS.

STS API Methods

AWS IAM Roles provides temporary credentials to whoever authorized to assume an IAM Role. Temporary credentials are supplied by AWS Security Token Service (STS) by evaluating the permission polices attached to the role.

There are Five main API methods provided by AWS STS.

  • AssumeRole
  • AssumeRoleWithWebIdentity
  • AssumeRoleWithSAML
  • GetFederationToken
  • GetSessionToken


This is typically used for cross-account access. The AWS account who wants to share a resource with another AWS account can create an IAM Role. Add the permission policy and the trust policy to the role. We can refer the other AWS account id in the trust policy. So the other account can use “Switch Role” feature in the AWS Console to enter the role name and account id of the resource sharing account and get access to the resource


This API call returns a set of temporary security credentials for users who have been authenticated via a SAML authentication response. Typically used for Active Directory federation.


This API call returns a set of temporary security credentials for users who have been authenticated in a mobile or web application with a web identity provider. If you have a mobile app where the users need to access an AWS resource (E.g. Upload profile photo to a S3 bucket) you can set up the IAM role, configure web identity and allow all authenticated (With facebook, google, etc..) federated users to assume that role.


GetFederationToken API call needs Long Term Credentials of an IAM User instead of IAM Role. Because of that, use this API method only in a safe environment where the long term credentials can be stored.

It returns a set of temporary security credentials (consisting of an access key ID, a secret access key, and a security token) for a federated user. Typical use is in a proxy application that gets temporary security credentials on behalf of distributed applications inside a corporate network.


Typically used to receive temporary credentials for Untrusted environments. It returns a set of temporary credentials for an AWS account or IAM user. The user must already be an IAM user. When he wants to access AWS resource in untrusted environments, he can use MFA to protect calls to AWS with GetSessionToken call.


Please follow and like us:

Static Web Hosting with Amazon S3 and Amazon CloudFront

Following blog post is linked with the video on static web hosting with Amazon S3 and CloudFront. You can find it here. This blog post covers the theoretical aspects of S3, CloudFront and Cloud9 services.

If you want to deploy your react/angular/vue.js applications Amazon S3 static web hosting is the best choice on AWS platform. Your sites will receive 99.999999999% durability and 99.99% availability just by only deploying to S3. That means, the website assets i.e. images/videos/html/js files will almost never be lost and the site will be available to the users 99.99% of the time. All that is provided to you at a low cost, no server management (serverless) and high scalability.

Static Web Applications

What is a static web application? Static web applications have web pages with static content. It may contain HTML, JavaScript, CSS etc. That web application is typically interacting with a backend to send and receive data. The backend could be a REST or GraphQL backend.

Static web application does not have dynamic content. It does not rely on server-side processing including server-side scripts such as PHP, and JSP. If you upload these files to an S3 bucket, it will not function as it should since S3 doesn’t support server-side scripting.

The Architecture

Figure 01

In the above simple architecture, we are adding the website built code which is just HTML, CSS and Javascript into the S3 bucket. Then we are serving the website via a CloudFront distribution. Amazon CloudFront service is used as a Content Delivery Network (CDN) which operates at the Edge.

Amazon S3

S3 is short for Simple Storage Service. It is one of the cost-effective services to host static content like images/videos/files on the AWS cloud. Amazon S3 is an “object storage” where you can store objects (e.g. images, videos, files) as a whole with metadata associated with these objects. So each object is self sustained and thus enables S3 to facilitate distributed storage architecture.

Since Amazon S3 is an Object Storage, it cannot be used for block storage. For example, you cannot host an operating system (eg: Linux/Windows) on an S3 bucket. For that, you should use EBS (Elastic Block Storage) volume attached to an EC2 instance. In block storage, a file is divided into equally sized units and be stored. When retrieving the complete file, it uses an index to find the related units and put them together to create the full file. Each unit does not contain metadata so that is not self-sustained or comprehensible when viewed individually.

S3 – Life Cycle Management

Amazon S3 supports Life Cycle Management of the objects. That means you can set rules for each object (file/image/video) to change the storage type with time. You can move a file from frequently accessed file type to an infrequently accessed file type to even archiving that file with Amazon Glacier. AWS also supports S3-Intelligent-Tiering Storage class where S3 will monitor the access behavior of the objects in buckets and automatically

S3 – Encryption

S3 also supports Encryption of objects using S3 Server-Side encryption and S3 Client-Side encryption options. If you enable server-side encryption, S3 will encrypt objects before saving and decrypt objects before reading/downloading the objects. S3 client-side encryption allows you to manage the encryption process by yourself at the client side.

S3 – Versioning

S3 versioning allows you to keep versions of the s3 objects. When you enable versioning for a bucket, updates to an object will always be a new version. You can easily rollback to earlier version if required. If you delete an object S3 will not delete the object if the versioning is enable. It will add a delete marker on top of the object instead. It is always possible to delete the delete marker and restore the object easily.

S3 – Access Control

When you create an S3 bucket, it defaults to private. Only the creator/owner can read the content of the bucket. You can further use S3 access policies to control access to an s3 bucket or an s3 object. There are two main access control policies.

  1. Resource-Based Policies
    • Bucket policy
    • ACL (Access Control Lists)
  2. User-Based Policies (IAM policies)

Both of these policy types are JSON based policies. Resource-based policies are applied at S3 bucket or an S3 object whereas User-based policies are applied to the IAM users who are accessing S3 to work with objects.

An S3 ACL is a sub-resource that’s attached to every S3 bucket and object. It defines which AWS accounts or groups are granted access and the type of access. When you create a bucket or an object, Amazon S3 creates a default ACL that grants the resource owner full control over the resource.

As a general rule, AWS recommends using S3 bucket policies or IAM policies for access control. S3 ACLs is a legacy access control mechanism that predates IAM.

Please follow and like us: