Work Across Multiple AWS Accounts

Most teams run more than one AWS account: one for production, one for staging, one for development, sometimes more. This walkthrough connects three of them to one CloudThinker workspace and then asks questions that span all three: where the money goes, what’s idle, and which IAM access is risky. What you’ll need:

A CloudThinker workspace. The quickstart creates one.
Permission to create IAM roles in each AWS account, and access to AWS CloudShell in each one.
For cost questions: Cost Explorer turned on in each account. AWS can take up to 24 hours to activate it on a new account. The role’s ReadOnlyAccess policy already includes the ce:Get* reads Optimize uses. AWS bills Cost Explorer API requests separately (USD 0.01 per request at AWS list price).

How multiple accounts work

Each AWS account is its own connection in CloudThinker. There’s no hub account and no role chaining to set up. When you connect an account, CloudThinker assumes a read-only role in that account (CloudThinkerAccessRole) and gets short-lived credentials for it. Agents pick an account from two fields you fill in when you connect it:

Field	What to put in it	Example
Alias	A short name you’ll use in prompts	`production`
Description	What the account holds. Agents read this to choose between accounts.	`Production AWS account, customer-facing workloads`

Write descriptions that tell the accounts apart. “AWS account” three times gives agents nothing to choose on. “Staging, mirrors production, reset weekly” does.

Connect the accounts

Repeat these steps once per account. There’s no organization-wide or StackSets onboarding: each account needs its own connect dialog, because each dialog generates its own External ID. If you’d rather create the roles with Terraform or CloudFormation, expand Manual steps in each dialog for the trust policy. The full reference, including the access-key method, is on the AWS connection page.

Open the connect dialog

In the sidebar, click More → Workspace settings → Connections, select Amazon Web Services, and click Connect. Keep Role-Based (recommended) selected.

Name the account

Fill in Alias and Description using the table above. Default AWS region (optional) is only a starting point: agents can use any region the role can reach.

Run the setup script in that account

Click Open CloudShell and sign in to the AWS account you’re connecting. Back in the dialog, click Copy Script to Clipboard, paste it into CloudShell, and press Enter. The script creates CloudThinkerAccessRole with the AWS managed ReadOnlyAccess policy and prints the role’s ARN.ReadOnlyAccess can read data as well as configuration, such as S3 objects. For a narrower role, see Required permissions for the ViewOnlyAccess plus SecurityAudit option and what it gives up.

Copy the script from the dialog you’re completing, every time. Each dialog generates its own AWS External ID, and the script bakes it into the role’s trust policy. A script copied from another account’s dialog won’t match.

Paste the Role ARN and connect

Paste the ARN into AWS Role ARN, leave AWS External ID as it is, and click Connect.Success state: the account shows a Connected status.

After connecting, set the environment

The connect dialog doesn’t ask for an environment, so set it now. On the Amazon Web Services detail panel, click the pencil icon on the account’s row and set Environment to Production, Staging, or Development in Edit Instance. It labels the account for people and agents. Approval Rules don’t read it. A Rule has no Environment field, so it covers an account only when you pick that connection under Connections.

When you’re done, Connections lists three Amazon Web Services connections, for example production, staging, and development, each Connected.

Check which accounts agents can reach

Before you compare anything, confirm every account answers. In a new conversation, ask:

List every AWS account you can reach through my connections. For each one, show the alias, the 12-digit account ID, and the regions you can see.

Expected result: one row per connection with its real account ID. Agents aren’t limited to the Default AWS region: they can use any region the role can reach. A region blocked by a service control policy (SCP) returns AccessDenied there. If an account is missing or shows an error, fix it now (see Troubleshooting) so later comparisons don’t silently skip it.

Compare spend across accounts

You have two routes. Use Optimize when you want saved, repeatable numbers. Use a chat prompt when you have a one-off question.

You want	Use	Where
A savings report covering every account, with one section each	Optimize reports with All accounts scope	Optimize → Reports
One account’s spend by service or region	Cost Explorer	Optimize → Cost Explorer, pick the account next to the page title
A quick side-by-side answer in your own words	A chat prompt	Any conversation

Generate an all-accounts report

Open Reports

In the sidebar, select Optimize → Reports.

Pick the scope

Choose All accounts in the selector above the report cards.

Pick a report

Select Savings opportunities.Success state: a new conversation opens, and the finished report appears as an artifact with one section per account.

Reports use the cost data Optimize already stores, so they don’t call AWS for fresh data. Optimize pulls new billing data once a day. The Updated button in the Optimize page header shows when each account last refreshed. Missing data shows up as a gap, never as zero, and Optimize never adds different currencies together. To run the report on a cadence, select Add schedule under Scheduled reports. A schedule keeps the accounts it captured when you created it, so recreate it after you connect another account. See Schedule a recurring report.

Ask in chat

Name the accounts by alias so there’s no guessing:

Compare last month's AWS spend for production, staging, and development. Show a table with the top five services in each account and flag any service that grew more than 20% from the month before.

Expected result: a table per account (or one combined table) with service names and amounts, and the services that grew past 20% called out.

Find cost waste in each account

Non-production accounts often collect forgotten resources. Ask the same question of every account at once:

In staging and development, find EC2 instances with average CPU under 10% over the last two weeks, and unattached EBS volumes. Group the results by account and include instance IDs, types, and regions.

Expected result: a list per account with resource IDs you can look up in the AWS console. Nothing is stopped or deleted: the role is read-only. For ranked savings with estimated amounts, open Optimize → Findings and pick each account in the page header. See Recommendations.

Find security issues across accounts

The ReadOnlyAccess role lets agents review IAM roles, users, and policies in every connected account. Two prompts that pay off quickly:

List IAM users and roles that haven't been used in 90 days in production, staging, and development. Group by account and show the last-used date for each.

Across all my AWS accounts, find IAM users with access keys older than 90 days and any user without MFA. Show one table per account.

Expected result: a table per account with identity names and dates. Use it as a cleanup list. Agents report what they find; they don’t remove anything.

Every call an agent makes is an ordinary AWS API call. To see exactly what ran in an account, filter CloudTrail in that account by CloudThinkerAccessRole.

Let agents make changes in some accounts only

The setup script’s role is read-only, so AWS refuses every write in every account until you grant more. To let agents fix things in, say, development but never in production:

Add only the write actions you need to CloudThinkerAccessRole in the development account. Leave the production role on ReadOnlyAccess. For example, this inline policy lets agents stop and start only instances tagged env=dev:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:StopInstances", "ec2:StartInstances"],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": { "StringEquals": { "aws:ResourceTag/env": "dev" } }
    }
  ]
}

Check the Allow writes switch on the Amazon Web Services detail panel in Connections. It’s on by default for AWS. Turn it off on any connection that should stay read-only even if its role changes later.
Add an Ask first Rule and pick the staging and production connections under Connections, so a person signs off before a write runs there. Rule enforcement is off by default and CloudThinker turns it on per workspace, so until then keep the Approval mode on Manual — that is what makes a write wait for a person today.

See Write access for how IAM permissions and Allow writes combine.

Troubleshooting

An account is missing from the answer

Cause: the connection isn’t Connected, or its Description is too vague for agents to match it to your prompt.Fix: check the account’s status in More → Workspace settings → Connections. Then edit its Description to say what the account holds, and name it by alias in your prompt.

The second account fails with AccessDenied on sts:AssumeRole

Cause: the script or trust policy came from a different account’s dialog, so the External ID doesn’t match.Fix: open a fresh connect dialog for that account and run the script it shows. If CloudThinkerAccessRole already exists there, the script stops. If no other CloudThinker connection uses that role, delete it in CloudShell and run the new script:

aws iam detach-role-policy --role-name CloudThinkerAccessRole \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
aws iam delete-role --role-name CloudThinkerAccessRole

Otherwise, expand Manual steps in the dialog and update the existing role’s trust policy with the External ID it shows.

Cost questions return no data for one account

Check: Cost Explorer is on in that account and has had 24 hours to activate. Member accounts in AWS Organizations may be blocked from Cost Explorer by the management account.Fix: turn on Cost Explorer, or connect the management account to see costs for the whole organization.

A scheduled all-accounts report skips a new account

Cause: a report schedule keeps the accounts it captured when you created it. Accounts you connect later aren’t added.Fix: recreate the schedule on Optimize → Reports with All accounts selected.

Learn

Workshops

Scenarios

Work Across Multiple AWS Accounts

How multiple accounts work

Connect the accounts

Check which accounts agents can reach

Compare spend across accounts

Generate an all-accounts report

Ask in chat

Find cost waste in each account

Find security issues across accounts

Let agents make changes in some accounts only

Troubleshooting

Next steps

Connect an AWS account

Optimize reports

​How multiple accounts work

​Connect the accounts

​Check which accounts agents can reach

​Compare spend across accounts

​Generate an all-accounts report

​Ask in chat

​Find cost waste in each account

​Find security issues across accounts

​Let agents make changes in some accounts only

​Troubleshooting

​Next steps

Connect an AWS account

Optimize reports

How multiple accounts work

Connect the accounts

Check which accounts agents can reach

Compare spend across accounts

Generate an all-accounts report

Ask in chat

Find cost waste in each account

Find security issues across accounts

Let agents make changes in some accounts only

Troubleshooting

Next steps