How can you access AWS resources from different accounts? Use different Profiles.

Recently I and some of my team members started working on projects from another Team that belong to a different AWS account as ours.

This is not the first time I need to access resources ( Lambdas or S3 Buckets does not matter) from other Teams' AWS Accounts.

Users or Profiles

In the past though, I had a User created ad hoc for myself under that team account.

This time I believe the approach was more correct, handy and flexible.

The Team A created a Role -- TeamBCrossAccountAccess - and defined TeamB AccountID as a trusted entity. Under that Role Permissions policies were added to define granularly to which resources of Team A members of Team B could access.

Then under Team B a Policy was created to allow users of Team B to Assume the role created by Team A

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::TEAM_A_ACCOUNT_ID:role/TeamBCrossAccountAccess"
        }
    ]
}

And that role was then attached to some users of Team B ( not all users of Team B were supposed to work on projects and access resources of Team A)

By doing that you can switch Profiles via the UI Console and of course via the CLI.

Since you don't have a new User for a different account, you don't need new credentials - check out AWS Documentation

if you want to understand the differences between Accounts, Users and Roles - and you don't need to sign off and sign in with a different password nor you need new AccessID and Tokens for your CLI.
Just select SwitchRoles from your UI Console Menu and then enter the AccountID of the other Team and selct the right role.

CLI Configuration

Even though you don't have new credentials, some changes are required in your CLI configuration anyway.

In the UI Console is really that simple, just select another Profile in the Menu ( but we are never using the CLI to build our infrastracture, right?!? Infrastructure as Code anyone? )
but within the terminal we need to tell AWS CLI to use a different profile, so we need to add it to our configuration.

Inside your ~/.aws/config add the profile for the new role ( similarly as you would do with a complete new account/user)

[profile TEAM_A]
role_arn = arn:aws:iam::TEAM_A_ACCOUNT_ID:role:role/TeamBCrossAccountAccess
source_profile = default.  <-- THIS POINTS TO THE CURRENT DEFAULT OF YOUR CONFIG which in my case is TeamB//

Then to use the CLI you can just invoke any command specifying which profile to use.

aws secretsmanager get-secret-value --secret-id a_secret_from_team_a --profile TEAM_A

Nice, but not so handy when you have CDK or Serverless or any other bunch of shell script using many commands and you don't want to edit them all to add --profile to each of them ( especially if you happen to work on TeamA repo directly, you don't want to add --profile TeamA on their scripts!)

Therefore, you can export AWS_DEFAULT_PROFILE=TEAM_A and set the other profile as default for all the following invocations of the CLI (within that Terminal tab)

Btw: ( since I have some other variables our CI/CD pipeline requires for tagging and other stuff, I created an Alias method in my .zhrc ( bashrc would also work) to quickly switch among the two profiles

set_TeamA() {
export AWS_DEFAULT_PROFILE=TEAM_A
export SOME_OTHER_VARIABLE=some value FOR_TEAM_A
}

set_TeamB{
export AWS_DEFAULT_PROFILE=default
export SOME_OTHER_VARIABLE=some value FOR_TEAM_B
}

Who am I?

How do you make sure that you are using the correct profile though and not risking to deploy a lambda to the wrong Account, or see your CDK deploy fail because it cant reference other resources?

I normally check it via this command:

aws sts get-caller-identity

which will return something like this if you are using the Assumed Role from the other account:

{
    "Account": "TEAM_A_ACCOUNT_ID",
     "Arn": "arn:aws:sts::TEAM_A_ACCOUNT_ID:assumed-role/TeamBCrossAccountAccess/botocore-session-....."
}

or this if you are currently using your main user/account

{
    "Account": "TEAM_B_ACCOUNT_ID",
    "Arn": "arn:aws:iam::TEAM_B_ACCOUNT_ID:user/YOUR_SURNAME"
}

Recap

So, if you have an AWS account to manage the resources of your team, and then you start working on a new project with resources of another team, the easiest and more secure approach is getting a Profile and Assume A Role that grants you access to the other account resources.

To troubleshoot, you can always test out any aws cli command specifying the profile you want to use and see if you have access, then use sts get caller identity to make sure you have the proper configuration set on your machine.

Hope it helps.