Enable IAM Access Analyzer to Detect External Access in the Region

Overview

Enable IAM Access Analyzer across your AWS environment to detect and monitor external sharing of resources. The plan walks through discovering your current analyzer coverage, helping you choose the right analyzer scope (account-level or organization-level) and regions, standardizing naming and tagging, provisioning or reusing analyzers, and finally validating that the configuration is correct, non-duplicative, and aligned with your governance model.

By the end, you have a clear, documented analyzer strategy (account vs. org, per region), consistently named and tagged analyzers, and confidence that there are no unintended gaps or duplicates in your IAM Access Analyzer configuration.

Execution Details

Phase 1: Assessment

Inventory existing IAM Access Analyzers

First, gather a complete inventory of existing IAM Access Analyzer analyzers across all in-scope accounts and regions. This includes:

• Enumerating all analyzers in each selected region.
• Recording key details such as name, ARN, type (account or organization), status, region, and scope (account ID or organization metadata).
• Capturing metadata like creation time, last analysis time, and existing tags.
• Highlighting regions or accounts that already have analyzers of the intended scope, to avoid overlap.
• Storing all information in a structured format (for example, a table or spreadsheet) for use in later decisions.

Choose analyzer scope and target regions

Next, use the inventory to guide scope and placement decisions. The plan will:

• Present you with the current analyzers and their coverage so you can see what’s already in place and where gaps exist.
• Guide you through deciding whether to use:
  • Account-level analyzers,
  • Organization-level analyzers,
  • Or a combination, based on your governance and AWS Organizations setup.
• For organization-level analyzers, confirm that the management or delegated administrator account and org structure are appropriate.
• Help you select target regions where analyzers should run, taking into account compliance and data residency requirements.
• For each region, decide whether to create a new analyzer or reuse an existing one.
• Produce a structured decision record per region specifying:
  • Whether an analyzer will be account-level, organization-level, or none.
  • Whether it will be newly created or an existing analyzer reused.
  • Any constraints or preferences (e.g., limited regions, no redundant analyzers).

Define analyzer naming and tagging standards

Finally in assessment, define consistent naming and tagging rules so analyzers are easy to manage and identify. The plan will:

• Have you review existing analyzer names and tags to avoid conflicts.
• Help you design a naming convention that may encode environment, scope, and region.
• Ensure you specify a unique analyzer name for each planned analyzer in its account/region.
• Confirm the intended scope (account or organization) for each analyzer aligns with the prior decisions.
• Guide you in defining required and optional tags (e.g., Name, Environment, Application, Owner, CostCenter, Compliance/SecurityCategory) and any allowed values.
• Document any variations needed for different accounts, regions, or scopes.
• Produce a finalized specification that, for each planned analyzer, lists:
  • Target region and scope,
  • Analyzer name,
  • Full tag set to apply or enforce.

Phase 2: Configuration

Provision IAM Access Analyzer with the chosen scope and region

With the design decisions finalized, the plan moves into provisioning. It will:

• Use the list of planned analyzers (from the assessment) as the source of truth.
• Confirm for each target account and region that there isn’t already an analyzer of the same scope, unless reuse is explicitly intended.
• Prepare configuration parameters for:
  • New account-level analyzers (name, type=account, region).
  • New organization-level analyzers (name, type=organization, appropriate management or delegated admin account and region).
• Create any new analyzers as specified.
• For analyzers intended to be reused, verify that their type and region match the design and that no conflicting changes are needed.
• Retrieve and check each analyzer’s details post-creation to verify correct name, type, region, and an appropriate initial status.
• Record any creation failures along with relevant context for follow-up.
• Produce a configuration summary listing all analyzers that were successfully created or reused, including their names, types, regions, and scope details.

Ensure IAM Access Analyzers have the required tags

After analyzers are in place, the plan enforces the agreed tagging standards. It will:

• Load the tagging requirements defined during assessment.
• Retrieve current tags for each analyzer created or standardized.
• Compare existing tags against the target set to find missing tags, incorrect values, or tags to remove.
• Plan and apply updates to:
  • Add missing required tags (such as Name, Environment, Owner, CostCenter).
  • Correct non-compliant tag values.
  • Optionally remove tags that no longer fit your standards.
• Re-check tags after updates to ensure they match the desired configuration.
• Produce a tagging summary that shows, for each analyzer, the final tag set and any issues that prevented updates.

Phase 3: Validation

Verify IAM Access Analyzer status, scope, and configuration

Once configuration is complete, the plan validates that analyzers are operating as intended. This step will:

• Use the list of analyzers created or standardized in the plan as the reference.
• Retrieve each analyzer’s current configuration (name, type, region, status).
• Confirm that each analyzer:
  • Exists in the correct region,
  • Has the expected name and type (account vs. organization),
  • Matches the planned scope (correct account or correct organization and admin/management account).
• Check that each analyzer is active or otherwise in a healthy expected state.
• Document any mismatches in scope, name, region, or status for remediation.
• Produce a validation summary listing, for each analyzer, its final status, scope, and region, and flagging any that are misconfigured or inactive.

Confirm there are no unintended duplicate analyzers

Finally, the plan ensures the analyzer layout is clean and unambiguous. It will:

• Re-enumerate all IAM Access Analyzer analyzers in in-scope accounts and regions.
• Group analyzers by account/organization, region, and type (account or organization).
• Verify that:
  • For account-level analyzers, there is at most one intended analyzer per account per region, unless multiple analyzers are explicitly justified.
  • For organization-level analyzers, there is at most one intended analyzer per organization per region in the management or delegated admin account, unless explicitly designed otherwise.
• Identify any regions or accounts with multiple analyzers of the same type and overlapping scope and confirm whether they are intentional or configuration drift.
• Record unintended duplicates, including their names, ARNs, regions, and potential impact (such as redundant or confusing findings).
• Provide a final duplicate-check summary confirming that analyzer distribution matches your intended design and listing any exceptions that may require cleanup or consolidation.