IAM policies are easy to expand and difficult to reason about from memory. Access Analyzer evaluates resource policies and trust relationships to identify access outside the boundary you intended.
Define the boundary first
An analyzer needs a clear zone of trust: an account, organization, or organizational unit. Findings are only useful when the team has agreed which external principals are legitimate.
The finding that started the work
The useful finding was not a dramatic public bucket. It was a resource policy granting access to an old account that had changed ownership. The policy was still technically valid, which made it more dangerous than an obvious syntax error: every review had treated it as background noise.
We traced the principal to the consuming workload, confirmed that the integration had been retired, and removed the statement. The important result was not the deleted line; it was discovering that nobody owned the exception anymore.
Prioritize findings by exposure
Start with public access, wildcard principals, sensitive data stores, and production roles. A finding is not automatically a vulnerability, but every accepted exception should have an owner, reason, and review date.
aws accessanalyzer list-findings \
--analyzer-name organization-boundary \
--status ACTIVEPut findings into delivery
Run analysis after policy changes and before production promotion. Store approved exceptions as code or tracked records so a policy review does not depend on one person remembering why a bucket is shared.
The resolution
We added analyzer checks to the infrastructure pipeline, routed new findings to the resource owner, and gave exceptions an expiry date. A finding could still be accepted, but acceptance required a reason and a review date. That turned a vague security concern into an operational queue.
Close the loop with an owner
For each finding, verify the principal, resource, actions, and conditions against the real integration. Then choose one of three outcomes: remove unintended access, narrow and document intentional access, or accept a time-bounded exception with an owner. Put the fix in infrastructure code and add a regression check where possible. Marking a finding archived without recording why only teaches the next reviewer to distrust the queue.
The finding is not the work. The work is restoring a clear answer to who can reach what, for which reason, and until when.
An access-review principle
A finding that remains open forever is not an accepted risk. It is an undocumented dependency.