By setting up cross-account access in this way, you don't need to create individual IAM users in each account, and users don't have to sign out of one account and sign into another in order to access resources that are in different AWS accounts.
Step 1 - Create a Role
First, you use the AWS Management Console to establish trust between the Production account (ID number 999999999999) and the Development account (ID number 111111111111) by creating an IAM role named UpdateApp. When you create the role, you define the Development account as a trusted entity and specify a permissions policy that allows trusted users to update the productionapp bucket.
Step 2 - Grant Access to the Role
In this step of the tutorial, you modify the IAM group policy so that Testers are denied access to the UpdateAPP role. Because Testers have PowerUser access in this scenario, we must explicitly deny the ability to use the role.
Step 3 - Test Access by Switching Roles
Finally, as a Developer, you use the UpdateAPP role to update the productionapp bucket in the Production account. You see how to access the role through the AWS console, the AWS CLI, and the API.
Ques : What are the 2 policies for cross account access?
5. KeyAns : Trust & Access
At times, you need to give a third party access to your AWS resources (delegate access). you need to define External IDs. e.g., hire a third-party company to monitor your AWS account.
Although you could give Example Corp access to an IAM user and its long-term credentials in your AWS account, you should choose instead to go with the highly recommended best practice of using an IAM role.
Here's a more detailed breakdown of this scenario:
1) You hire Example Corp, so they create a unique customer identifier for you. They give you your unique customer ID and their AWS account number.