View a markdown version of this page

Caching mechanism - AWS Prescriptive Guidance
Key responsibilities of the caching mechanismWorkflow of the caching mechanism

Caching mechanism

The caching mechanism ensures that repeated infrastructure scans, analyses, and dependency mappings are efficiently served without redundant API calls or reprocessing. The caching mechanism is implemented across all components—resource scanning, document generation, and dependency mapping. This layer reduces response times, optimizes Amazon Bedrock usage, and improves scalability for large or frequent workloads.

Key responsibilities of the caching mechanism

This section describes the key actions and responsibilities of the caching mechanism.

Avoid redundant computation

Before performing a new scan, analysis, or mapping, the system checks the cache for an existing result that matches the input dataset and request parameters. If found, the cached response is immediately returned, significantly reducing processing overhead.

The compare_infrastructure_data function is responsible for checking if the infrastructure data has changed and compares it to cached data, thus preventing redundant computation.

Cache AI-powered reports and dependency graphs

Both documentation reports and dependency mappings generated by Amazon Bedrockare stored with associated metadata. Cached entries include analysis type, input file fingerprints, timestamps, and processing details, so that repeat requests can be served instantly.

The check_ai_report_cache and check_dependency_graph_cache functions handle the checking of cache for AI reports and dependency graphs, respectively. If cached data is available, they return the data, saving computation time.

Track and expose cache statistics

The system provides a /cache/stats endpoint to expose cache utilization metrics, such as total cache hits, misses, and file counts. A cache hit is an event where a requested resource or result is found in the cache, allowing instant retrieval without repeating the underlying computation or API call. A cache miss is an event where no matching cached resource is found, triggering a fresh scan or analysis to generate new results which are then cached.

This enables observability into how often caching is used and how much computation is being saved.

The get_cache_stats function provides valuable cache utilization metrics, including the number of cache hits, misses, and the total size of the cache.

Enable cache maintenance and cleanup

Through the /cache/cleanup endpoint, old or stale cache files can be removed based on configurable retention periods. This approach prevents uncontrolled cache growth and ensures storage remains efficient over time.

The cleanup_old_cache function helps to manage old and stale cache files. It cleans up outdated files, so that only recent data is retained in the cache, preventing it from growing too large.

Workflow of the caching mechanism

The caching mechanism uses the following workflow:

  1. Cache lookup – When a request for documentation generation, infrastructure analysis, or resource mapping is received, the system first queries the cache with the normalized input data and request type.

  2. Cache hit – If a valid cached entry is found, the system enriches it with request-specific metadata (processing time, file details, and served-from-cache flags) and immediately returns the cached result to the client.

  3. Cache miss – If no valid cache entry is found, the system processes the request normally by calling AWS APIs or Amazon Bedrock, generates fresh results, and then saves them to the cache for future reuse.

  4. Cache monitoring and cleanup – Administrators can retrieve real-time statistics or trigger cache cleanup to remove entries older than a defined threshold (default 30 days). This keeps the cache performant and prevents excessive storage usage.