Configure Bedrock Knowledge Base Data Source Deletion Policy

Overview

Configure Bedrock Knowledge Base deletion/retention behavior so embeddings are retained when a data source or an entire Knowledge Base is removed. The plan will discover all Knowledge Bases and their attached data sources, collect current deletion/retention policies and metadata, present recommended changes and impact summaries for your approval, apply approved KB-level policy updates to ensure embeddings are retained, and then validate and report the final state. Outputs include machine-readable inventories and audit metadata to support traceability and rollback planning.

Execution Details

Assessment — discover resources and current state

• Discover all Bedrock Knowledge Bases in the target account/region and collect per-KB metadata: ID, name, ARN, region, creation date, status, description/tags, service-managed identifiers, and any embedding-index identifiers exposed by the KB.
• Enumerate all data sources attached to each KB and collect per-source metadata: ID, name, type (S3, connector, crawler, etc.), ARN (if available), creation date, status, connection/ownership details (bucket ARN, crawler URL, connector identifier), and whether the source uses a separate embedding store or the KB’s shared embedding index.
• Identify data source types or configurations that cannot support retention policy changes and mark them as unsupported.
• Fetch current deletion/retention policies for each KB and for each attached data source: capture the exact policy JSON (or equivalent fields), timestamps, version/ETag if provided, and API response metadata.
• Analyze effective outcomes and conflicts: determine whether embeddings would be deleted or retained on (a) data-source removal and (b) KB deletion, detect KB vs data-source policy conflicts, and note any account-level or service defaults that influence behavior.
• Produce machine-readable artifacts for auditing and decision-making: an inventory of KBs and data sources, counts by status, consolidated policy report, and API metadata (request IDs, timestamps).

User review and approval — present options and collect explicit consent

• Present the consolidated report and, for each KB, a recommended change that will ensure embeddings are retained (explicit resource IDs/ARNs and the exact policy change proposed).
• Provide concise impact summaries per recommendation: what will be retained, storage/cost implications, and downstream effects.
• List resources flagged as unsupported for policy changes and explain why.
• Guide the user through configuration options and collect explicit approval that enumerates which KBs and data sources the agent is authorized to modify and acceptance of impact and rollback approaches.
• Record any declined changes and exclude those resources from subsequent configuration steps.

Configuration — apply KB-level retention settings

• For each Knowledge Base explicitly approved, prepare an auditable update payload documenting resource ID/ARN, policy fields to change, and new values.
• Where a data-source-level change is required to avoid conflict, include that requirement in the prepared payloads but do not modify data-source policies unless the user explicitly approved them.
• Include concurrency/version controls (ETag/policy version or equivalent) in updates to avoid overwriting concurrent changes.
• Apply updates to the approved KBs and capture per-resource service responses (success/failure, request IDs, timestamps).
• Record a change log entry for each update including resource ID/ARN, previous and new policy JSON, initiator marker, request ID, and timestamp.
• Continue updates on a per-resource basis unless a failure indicates a global problem; collect error details for any failed updates.
• After updates, re-fetch the KB policy to confirm persistence and that the intended values are present.

Validation — confirm retention is effective and report results

• Re-retrieve deletion/retention policies for all updated KBs and their attached data sources.
• Confirm the retention fields explicitly indicate embeddings will be retained on KB deletion and on data-source removal (as applicable).
• Produce evidence for each resource: resource ID/ARN, returned policy JSON, retrieval timestamp, and API request ID.
• Verify there are no conflicting data-source-level policies that override KB-level retention in a way that would still cause deletion.
• Produce a final machine-readable report listing updated resources, final policy JSON, evidence of persistence, and any resources that did not reach the expected state (including error messages and recommended next steps for user approval).

Outputs, Auditing, and Considerations

• Delivered artifacts: machine-readable inventories and mapping (KB → data sources), consolidated policy reports, per-change change logs, API metadata (request IDs/timestamps), and a final validation report.
• Auditability: all changes are documented with previous/new policy values, request IDs, timestamps, and an initiator marker.
• Considerations and risks: potential storage/cost impacts from retained embeddings, some data-source types may not support retention changes, and conflicting policies may require coordinated updates (and explicit approvals) to avoid unintended deletions.