View a markdown version of this page

Dependency mapping - AWS Prescriptive Guidance
Key responsibilities of the dependency mapping componentWorkflow of the dependency mapping componentUser view of dependency mapping

Dependency mapping

The dependency mapping component analyzes relationships between AWS resources and builds a comprehensive graph of how AWS services interact with each other. Unlike the scanning phase (which only inventories resources) and the documentation phase (which explains configurations and best practices), dependency mapping focuses on interconnections. To infer how resources are linked, this phase relies heavily on resource-based policies (for example, Amazon S3 bucket policies, Lambda execution permissions, and Amazon SNS or Amazon SQS access controls).

While the system produces a structured Markdown document for consistency and auditability, the same data is also consumed by the UI to generate an interactive graph view. This makes it possible to explore resource connections visually, identify access paths, and spot potential misconfigurations.

Key responsibilities of the dependency mapping component

This section describes the key actions and responsibilities of the dependency mapping component.

Extract policies and identifiers

The process begins by examining the infrastructure data (JSON from the scanning phase) and isolating all resources that expose policies, such as Amazon S3 buckets, Lambda functions, Amazon SNS topics, Amazon SQS queues, or Amazon EC2 instances with IAM profiles. For each resource, the system extracts identifiers and any attached resource-based policies. Examples of identifiers are IDs, Amazon Resource Names (ARNs), and names. These identifiers and policies form the basis of relationship discovery.

The extract_resource_policies function handles the extraction of policies and identifiers, by processing the infrastructure data to extract resources with attached policies, such as Amazon S3 buckets and Amazon EC2 instances.

Construct resource ARNs

Where possible, full ARNs are extracted directly from the resource metadata. For resources that don't provide ARNs explicitly, the system reconstructs them by using service-specific patterns. This approach guarantees a uniform representation across all resources, which is essential for cross-service dependency analysis.

The extract_resource_arn function handles the process of constructing ARNs. It either directly extracts ARNs from resource metadata or reconstructs them by using service-specific patterns defined in ARN_CONSTRUCTION_MAP.

Dependency analysis powered by Amazon Bedrock

After policies and ARNs are extracted, the system generates structured prompts that are passed to Amazon Bedrock (using the Claude 3.7 Sonnet model). The prompts strictly enforce a structured Markdown output format where each resource and its connections are described in a predictable schema. This approach helps to produce output that machines can parse, and humans can read.

The generate_resource_mapping_from_infra_data function generates a service-by-service Markdown output after extracting and processing resource based policies using Amazon Bedrock.

Continuation and retry handling

The mapping process includes a continuation mechanism that does the following:

  1. If Amazon Bedrock can't analyze all resources in a single call, it returns CONTINUE_ANALYSIS.

  2. The system generates a continuation prompt with the remaining resources, waits briefly (to avoid rate limits), and retries.

  3. This cycle repeats until all resources are analyzed or the marker is detected.

The generate_service_markdown_with_continuation function ensures that services are processed sequentially and that the continuation prompt logic is handled with retries in case of rate limits or incomplete analysis.

Aggregation and combination

Finally, all per-service dependency mappings are merged into a single, consolidated Markdown document.

This process is handled by the method combine_service_markdown_results. It ensures that all the dependency mappings are merged in a logical, readable format. The format starts with a header, followed by the total resources, successful services, and resource dependencies for each service. The final document presents both the successes and failures of the analysis in a structured way.

Graph conversion for UI

The Markdown output is parsed and transformed into a graph data model (nodes and edges) using React Flow as follows:

  • Nodes represent resources such as Lambda functions, Amazon S3 buckets, and Amazon DynamoDB tables.

  • Edges represent connections or access relationships such as Lambda to S3: InvokeFunction. This enables the frontend to render a network graph where dependencies can be visually explored.

Workflow of the dependency mapping component

The dependency mapping component uses the following workflow:

  1. Input: infrastructure data – The dependency mapping process begins with the JSON output generated in the document generation phase. This file contains detailed information about AWS resources, their metadata, and any attached resource-based policies, serving as the foundation for all subsequent analysis.

  2. Policy extraction – Before relationships can be mapped, the system runs a policy extractor that identifies resources with attached policies. It normalizes identifiers such as ARNs, cleans up service-specific variations, and outputs a refined dataset focused only on resources relevant for dependency mapping.

  3. Prompt construction – After the clean dataset is prepared, the system constructs specialized prompts tailored for Amazon Bedrock (which is using Claude). These prompts embed extracted policy data and enforce strict Markdown formatting rules, so that the AI generates structured, machine-readable, and human-readable output instead of free-form text.

  4. Amazon Bedrock analysis – Amazon Bedrock processes the prepared dataset and generates dependency mappings by analyzing policies and resource metadata. To handle large infrastructures, the system includes retry and continuation support, allowing analysis to continue seamlessly across multiple calls until all resources are covered.

  5. Aggregation and post-processing – Outputs from individual service analyses are aggregated into a single unified document. During this stage, duplicates are removed and errors are flagged. Metadata, such as total resources analyzed, services covered, and processing time, is appended for completeness.

  6. Graph transformation – The structured Markdown output from Amazon Bedrock is transformed into a graph data model. Each resource becomes a node and relationships derived from policies or metadata are represented as edges, enabling a clear visualization of dependencies and access flows.

  7. Visualization in UI – Finally, the dependency graph is rendered in the UI using React Flow, where users can explore it interactively. Features like zoom, filtering, and search help engineers and security teams to quickly identify relationships, spot misconfigurations, and understand the broader AWS resource landscape.

User view of dependency mapping

The dependency mapping results are displayed as an interactive graph in the UI. Users can explore resource relationships visually, making it easier to understand complex dependencies across AWS services. You can also select any specific resource card to focus on its specific dependencies.