- Region is not a detail
- Global resources and the pseudo-region
- One account, one identity, one boundary
- Roles, not keys
- Reading a multi-account report
- Frequently asked questions
Almost nobody has one AWS account any more. Production, staging, a sandbox per team, something inherited from an acquisition, and a security account nobody touches. Scanning that estate raises questions a single-account tool never has to answer, and the answers determine whether your reports mean anything.
Region is not a detail
Most AWS APIs are regional. A call to describe-instances answers for the region you called it in and says nothing about the other thirty. So a scan is not one operation, it is one operation repeated per region, and the region list is a decision rather than a default.
Getting it wrong fails in both directions.
Scan too few regions and you under-report. This is the common case, and it is the one that produces the confident wrong answer. Resources concentrate in regions nobody thinks about: a proof of concept opened in us-west-2 two years ago, a Lambda deployed to eu-west-1 because a tutorial said so. The report looks clean because nothing looked.
Scan every region every time and you pay for it. Thirty-odd regions times every service is a lot of API calls and a lot of wall-clock time, mostly to confirm emptiness.
The workable shape is a scoped list for the frequent scan and a wider sweep occasionally. What matters is that the list is explicit and recorded with the scan, because a report that does not state its own coverage cannot be interpreted.
Global resources and the pseudo-region
Some AWS resources are not regional at all. IAM users, roles and policies, Route 53 hosted zones, CloudFront distributions and WAF's global scope exist once for the account.
These create two problems that look like bugs.
Duplicate blocks. Enumerate IAM once per region across five regions and you get five copies of every role. In generated Terraform that is five identical resource blocks with the same address, which does not parse. Global resources have to be collected once, at the account level, not once per region.
A region that is not a region. Output for global resources is conventionally filed under global. That is a directory name and a scope label, not an AWS region, and treating it as one produces reports that try to filter by a region that does not exist. Anything account-scoped needs a scope marker distinct from its region field, or account-wide findings vanish the moment a reader applies a region filter.
The tell that a tool has this wrong: an account-level finding that disappears when you filter the view by any specific region, or appears attached to whichever region happened to be scanned first.
One account, one identity, one boundary
Multi-account scanning is not multi-region scanning with more loops. The boundary is different: regions share a credential, accounts do not.
Two consequences shape everything else.
Credentials must not leak between accounts. Each scan runs with the credentials for its own account and nothing else. A worker process that handles several accounts has to isolate them properly rather than relying on ordering, because a credential leaking across the boundary means one customer's scan reading another's account.
An account is identified by its account ID, not by its label. Names are editable and duplicable, so anything that has to be counted, deduplicated or reconciled keys on the twelve-digit account ID. The same account connected twice under two names is one account, and a tool that thinks otherwise will double-count it.
Roles, not keys
Two ways to give a scanner access, and they are not equivalent.
| Access keys | Assumed role | |
|---|---|---|
| Lifetime | Until manually rotated | Minutes to hours |
| Revocation | Delete the key, hope nothing else used it | Delete the role or edit the trust policy |
| If leaked | Usable by anyone, anywhere | Unusable without the trust relationship and external ID |
| Per-account setup | A new IAM user per account | A role per account, same pattern |
| Audit trail | An IAM user with no context | Assumption events naming the principal |
Roles are the right answer at any scale and are close to mandatory across several accounts, because the alternative is a growing set of long-lived credentials in a database. Use an external ID: it is what stops a third party who learns your role ARN from persuading someone else's integration to assume it. The exact policy and trust relationship are in the read-only IAM role guide.
Do not reuse credentials across roles. The credentials a platform uses to run its own infrastructure and the credentials it uses to scan a customer account are different things with different blast radii, and treating them as interchangeable is how a scanning permission becomes a production permission.
Reading a multi-account report
Two questions to ask of any cross-account report before you trust the totals.
Does it state its coverage? Which accounts and which regions, per scan. A total across an unstated scope is not a number, it is an impression. Coverage should be visible next to the findings rather than assumed.
Does it deduplicate? The same resource can be reported by more than one analysis. Deduplication needs a key that every source agrees on: resource type, resource ID and region. Sources that return ARNs and sources that return bare IDs must normalise to the same form first, or nothing collapses and the total is inflated by exactly the overlap. We have had this bug twice and written about it in the rightsizing comparison.
Region is part of that key deliberately, so the same resource ID in two regions stays two resources. It is also why account-wide findings need their own scope marker: keyed by region, an account-level problem observed in five regions becomes five copies of one finding.
Frequently asked questions
Do I need to scan every AWS region?
Not on every run, but the region list has to be an explicit decision rather than a default. Scanning too few under-reports, and it is the common failure because resources concentrate in regions nobody thinks about, so the report looks clean because nothing looked. Scanning all thirty-odd regions every time costs significant time and API calls mostly to confirm emptiness. A scoped list frequently plus a wider sweep occasionally is the workable shape.
How are global AWS resources like IAM handled in a multi-region scan?
They must be collected once at the account level rather than once per region. Enumerating IAM in five regions produces five copies of every role, which in generated Terraform means five identical resource blocks with the same address. Output is conventionally filed under a global label, which is a scope name and not an AWS region.
Why do account-level findings sometimes disappear when I filter by region?
Because the finding was given a region rather than an account-wide scope marker. If an account-level problem is keyed by region it either vanishes under a region filter or attaches to whichever region happened to be scanned first. Account-scoped findings need a scope distinct from the region field.
Should I use IAM access keys or an assumed role for scanning?
An assumed role, and close to mandatory across several accounts. Keys live until manually rotated and are usable by anyone who obtains them, whereas role credentials last minutes to hours and are useless without the trust relationship. Revocation is editing a trust policy rather than deleting a key and hoping nothing else used it. Use an external ID to stop a third party who learns your role ARN from having someone else's integration assume it.
How does a scanner keep credentials from leaking between accounts?
Each scan runs with its own account's credentials and nothing else, with isolation enforced rather than relying on ordering. A credential crossing that boundary means one customer's scan reading another customer's account, so it is the one boundary that cannot be approximate.
How do I know a multi-account cost report is not double-counting?
Check that it states its coverage, which accounts and which regions, and that it explains its deduplication key. Deduplication needs resource type, resource ID and region, with every source normalising to the same identifier form first. Sources returning ARNs and sources returning bare IDs will not collapse against each other, and the total is then inflated by exactly the overlap.