Now why would you do that? There can be many reasons, to have a visibility of all the resources in all of your AWS Accounts, for faster onboarding, cost calculations and many other reasons.


In this blog I assume that you have 2 AWS accounts between which you want to enable cross account access. One will be called Dev and another one will be Prod. Your script will run in Dev account and list resources in Prod Account.

An EC2 instance where your script will run.



To allow users from one AWS account to access resources in another AWS account, create a role that defines who can access it and what permissions it grants to users that switch to it.

Before creating a role, we need the account ID of the Dev AWS account. The account ID is a unique identifier assigned to each AWS account.

  1. Sign in to the AWS Management Console and open the IAM console. In the navigation pane on the left, choose Roles and then choose Create role. Choose the Another AWS account role type.
  2. For Account ID, type the Dev account ID.
  3. Choose Next: Permissions to set the permissions that will be associated with the role. We need read access for EC2. We can change these permissions as per our requirements.
  4. Then choose Next: Review.
  5. Give a name for the role name.
  6. (Optional) For Role description, type a description for the new role.
  7. After reviewing the role, choose Create role.
  8. Obtain the role’s Amazon Resource Name (ARN), which is a unique identifier for the role.

At this point, we have established trust between the Prod and Dev accounts by creating a role in the Prod account that identifies the Dev account as a trusted principal.


  1. Here are the steps required to add permissions to allow switching to the role.
  2. Sign in to the AWS Management Console and open the IAM console. Choose IAM In the navigation pane on the left, choose Roles and then choose Create role. Choose EC2 as type of trusted entity.
  3. Choose the Permissions tab, expand the Inline Policies section, and then choose Create Group Policy. If no inline policy exists yet, then the button does not appear. Instead, choose the link at the end of “To create one, click here.”
  4. Choose Custom Policy and then choose Select button.
  5. Type a policy name.
  6. Add the following policy statement to allow the AssumeRole action on the role in the Prod account.
  7. {
    "Version": "2012-10-17",
    "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": ""
  8. Choose Apply Policy to add the policy.
  9. The Allow effect explicitly allows the Role in Dev account access to the role in the Prod account.
  10. Choose Apply Policy.


Once cross account access is all set up, copy the script from this GitHub link on to your EC2 instance. Make sure to place the ARN of your role created in Prod Account on line number 21.


This script is using STS (Security Token Service) by AWS to assume the role in another AWS Account.

The AWS Security Token Service (STS) is a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate (federated users).


For cross-account access, imagine that you own multiple accounts and need to access resources in each account. You could create long-term credentials in each account to access those resources. However, managing all those credentials and remembering which one can access which account can be time consuming. Instead, you can create one set of long-term credentials in one account and then use temporary security credentials to access all the other accounts by assuming roles in those accounts.

Returns a set of temporary security credentials (consisting of an access key ID, a secret access key, and a security token) that you can use to access AWS resources that you might not normally have access to. Typically, you use AssumeRole for cross-account access or federation.

Important: You cannot call AssumeRole by using AWS root account credentials; access is denied. You must use credentials for an IAM user or an IAM role to call AssumeRole.

To assume a role, your AWS account must be trusted by the role. The trust relationship is defined in the role’s trust policy when the role is created. That trust policy states which accounts are allowed to delegate access to this account’s role.

Once we get the Credentials from STS we use it to call EC2 service in Prod account and list all the instances by calling describe_instances API in all the region.

The script list only EC2 instances, you can do similar stuff with any other AWS Service in which you are interested in like RDS, S3 buckets, DynamoDB etc.

Once you get the details you can either push it to Dynamo DB table or somewhere else from where you can keep track of your resources from time to time.


Before running the script, attach the IAM Role created in Dev Account to this instance so that the script can run.


  • Select the instance and the go to Actions and choose Instance Settings from the Dropdown.
  • Then choose Attach/Replace IAM Role.
  • Choose the IAM Role and click Apply.

Now run your script and you should be able to list the details about all your instances in all your regions in your other AWS Account.

Feel free to leave the comments if you need any help.

Leave a comment

Your email address will not be published. Required fields are marked *