# Bedrock DELETE_UNSUCCESSFUL — the knowledge base needs its OpenSearch collection to delete

> Two Amazon Bedrock knowledge bases stuck at DELETE_UNSUCCESSFUL after their OpenSearch Serverless collections were deleted first, and the RETAIN fix.

- Source: https://oharu121.com/blog/bedrock-knowledge-base-delete-unsuccessful-opensearch-collection-retain/
- Published: 2026-08-30T23:04:24+09:00
- Tags: Amazon Bedrock, AWS, OpenSearch, RAG

---
**Key takeaways**

- Deleting a knowledge base runs two phases. The first purges vectors from the vector store, and it fails permanently once that store is gone.
- `DELETE_UNSUCCESSFUL` is not a transient state. Retrying the delete produces the same failure, because nothing about the missing collection changes between attempts.
- The fix is `dataDeletionPolicy: RETAIN` on every data source, which skips the purge entirely.
- `UpdateDataSource` is a `PUT`. Omitting `vectorIngestionConfiguration` is read as an attempt to change the chunking, which AWS rejects.
- Bedrock never deletes your vector store or your bucket, so nothing protects you from removing them in the wrong order.

## Introduction

I was clearing old Amazon Bedrock resources out of a personal AWS account when two knowledge bases refused to go away. Both sat at `DELETE_UNSUCCESSFUL`, a status the console reports without saying why, and pressing delete again just produced it a third time. What made it stubborn is that the cause was already in the past: **the OpenSearch Serverless collections behind both knowledge bases had been deleted first**, and each data source was configured to purge its vectors from those collections on the way out. The delete could never finish, no matter how many times it ran.

This article covers how that state was diagnosed from the CLI, why a missing vector store strands the delete permanently, the `dataDeletionPolicy: RETAIN` fix, one documented trap in `UpdateDataSource` that cost a second failed attempt, and the teardown order that avoids all of it.

## What the console would not explain

`ListKnowledgeBases` shows the shape of the problem immediately. Three knowledge bases in `ap-northeast-1`, two of them stuck:

```bash
aws bedrock-agent list-knowledge-bases --region ap-northeast-1 --output table
```

| knowledgeBaseId | name | status |
| --- | --- | --- |
| `ZZ01BJIIZ3` | knowledge-base-quick-start-handson-classic | `DELETE_UNSUCCESSFUL` |
| `PUVPB8DGEL` | internal-assistant-knowledge-base-test | `DELETE_UNSUCCESSFUL` |
| `GXPMI2WL6Q` | knowledge-base-rag-handson | `DELETING` |

The reason lives one call deeper, in a `failureReasons` array that the list view does not carry. `GetKnowledgeBase` returns it:

```bash
aws bedrock-agent get-knowledge-base \
  --region ap-northeast-1 --knowledge-base-id ZZ01BJIIZ3
```

```text
"failureReasons": [
    "Unable to delete data from vector store for data source with ID JLLYIBTATA. Check your vector store configurations and permissions and retry your request. If the issue persists, consider updating the dataDeletionPolicy of the data source to RETAIN and retry your request.",
    "Unable to delete data from vector store for data source with ID JLLYIBTATA. Check your vector store configurations and permissions and retry your request. If the issue persists, consider updating the dataDeletionPolicy of the data source to RETAIN and retry your request."
]
```

The same sentence twice, once per failed attempt. The other knowledge base returned the identical message against its own data source ID, `0NRPHQMCCN`. **The error names its own fix in the last clause**, which is easy to skim past on the way to reading "check your permissions" as the real advice.

## Were the vector stores actually reachable?

Both knowledge bases pointed at OpenSearch Serverless collections. Neither collection existed:

```bash
aws opensearchserverless batch-get-collection --region ap-northeast-1 \
  --ids rkulz4az4wngr17bmm67 6uu4dp3q3f2qqjkd2iqk
```

```json
{
    "collectionDetails": [],
    "collectionErrorDetails": [
        { "id": "rkulz4az4wngr17bmm67", "errorMessage": "The specified Collection is not found.", "errorCode": "NOT_FOUND" },
        { "id": "6uu4dp3q3f2qqjkd2iqk", "errorMessage": "The specified Collection is not found.", "errorCode": "NOT_FOUND" }
    ]
}
```

`ListCollections` agreed, returning `"collectionSummaries": []`. **There were zero OpenSearch Serverless collections left in the account**, while two knowledge bases still held ARNs pointing into them.

That rules out the permissions reading of the error. A role with no access to a collection and a collection that does not exist produce similar-sounding failures, and only one of them is fixable by editing IAM.

## Why a missing collection strands the delete

Deleting a knowledge base is two phases, and only the second one is bookkeeping.

Phase one is a **data plane** operation. When a data source carries `dataDeletionPolicy: DELETE`, Bedrock connects to the vector store and removes the vectors that data source ingested. Phase two is the **control plane** operation people picture when they click delete: dropping the knowledge base and data source records themselves.

Phase one needs a live collection. With the collection gone there is nothing to connect to, the call fails, and the resource lands in `DELETE_UNSUCCESSFUL` with phase two never attempted.

*Figure — TwoPhaseDelete: The delete stops at phase one. With the collection gone there is nothing to purge from, and the metadata that phase two would remove stays behind.*

This is why retrying does not help. **Nothing about a deleted collection changes between attempts**, so a retry re-runs a call whose precondition is permanently false. The state looks transient because `DELETING` and `DELETE_UNSUCCESSFUL` sit next to each other in the same status field, but one is a step and the other is a terminal outcome.

Both data sources confirmed the policy:

```bash
aws bedrock-agent get-data-source --region ap-northeast-1 \
  --knowledge-base-id ZZ01BJIIZ3 --data-source-id JLLYIBTATA
```

```json
{ "dataDeletionPolicy": "DELETE", "status": "DELETE_UNSUCCESSFUL" }
```

`DELETE` is the default the console's quick-start flow produces, so a knowledge base created by clicking through the wizard has it without anyone choosing it.

## The fix: set dataDeletionPolicy to RETAIN

`RETAIN` tells Bedrock to leave ingested data where it is, which skips phase one and lets phase two run. The agent proposed it directly from the error text and I approved the teardown; the sequence per knowledge base is update, then delete the data source, then delete the knowledge base.

```bash
aws bedrock-agent update-data-source \
  --region ap-northeast-1 \
  --knowledge-base-id PUVPB8DGEL --data-source-id 0NRPHQMCCN \
  --name knowledge-base-quick-start-6vf5c-data-source \
  --data-source-configuration '{"type":"S3","s3Configuration":{"bucketArn":"arn:aws:s3:::internal-assistant-docs"}}' \
  --vector-ingestion-configuration '{"chunkingConfiguration":{"chunkingStrategy":"HIERARCHICAL","hierarchicalChunkingConfiguration":{"levelConfigurations":[{"maxTokens":1500},{"maxTokens":512}],"overlapTokens":60}}}' \
  --data-deletion-policy RETAIN

aws bedrock-agent delete-data-source --region ap-northeast-1 \
  --knowledge-base-id PUVPB8DGEL --data-source-id 0NRPHQMCCN

aws bedrock-agent delete-knowledge-base --region ap-northeast-1 \
  --knowledge-base-id PUVPB8DGEL
```

Worth being explicit about what `RETAIN` gives up here, because it sounds like data loss and is not. Per the AWS documentation, `DELETE` "deletes all data when you delete your data source, but doesn't delete the vector store itself", and **"If you delete a data source or knowledge base, the vector store itself is not deleted."** The only thing `RETAIN` leaves behind is vectors inside a store. When that store has already been destroyed, there is nothing left to orphan.

## The pitfall: UpdateDataSource is a PUT, not a PATCH

The first attempt at this failed, and it failed on the knowledge base the agent tried first. The `--vector-ingestion-configuration` argument was left off, on the reasonable-looking assumption that an unspecified field is an unchanged field:

```text
aws: [ERROR]: An error occurred (ValidationException) when calling the UpdateDataSource operation: vectorIngestionConfiguration.chunkingConfiguration cannot be updated once created.
```

The API is a `PUT /knowledgebases/{knowledgeBaseId}/datasources/{dataSourceId}`, so **an omitted field is a field you are trying to clear**, not one you are leaving alone. The reference documentation says so in a callout above the request syntax: "You can't change the `chunkingConfiguration` after you create the data source connector. Specify the existing `chunkingConfiguration`." Read the resource, change the one field, and send it back complete.

The failure was quiet in the way that costs time. The update returned non-zero, but the two delete commands after it ran anyway and both reported `DELETING`, which reads like success. About four minutes later the knowledge base was back at `DELETE_UNSUCCESSFUL` with a fresh timestamp, having gone through exactly the same phase-one failure as before, because the policy was still `DELETE`. Sending the update again with the existing hierarchical chunking config included returned `"dataDeletionPolicy": "RETAIN"`, and the delete then completed.

**A failed precondition does not stop the commands that follow it.** Check that the policy actually reads `RETAIN` before issuing the delete, rather than checking the delete's own exit code.

## Verification

Both knowledge bases were gone, along with the third that had been mid-delete since the first listing:

```bash
aws bedrock-agent list-knowledge-bases --region ap-northeast-1 --output json
```

```json
{
    "knowledgeBaseSummaries": []
}
```

The `DELETING` one, `GXPMI2WL6Q`, completed on its own without intervention. Its collection was gone too, so whether it was ever at risk of the same failure is not something this session established.

Two IAM service roles were left behind by the teardown, both named `AmazonBedrockExecutionRoleForKnowledgeBase_<suffix>` with a random suffix the console picked. Deleting a knowledge base does not remove the execution role the console created for it.

## Delete in dependency order: knowledge base, then OpenSearch, then S3

The general rule this incident is a case of: **delete the resource that depends on others before the ones it depends on.** A Bedrock knowledge base sits on top of two things it does not own, and it needs one of them alive to finish its own delete.

*Figure — TeardownOrder: The knowledge base is the only resource here that needs another one alive to delete cleanly. Removing the collection first is what strands it.*

1. **Knowledge base first**, data sources included. This is the only step with a live dependency: phase one reaches into the vector store, so the collection has to still be there.
2. **OpenSearch Serverless second.** Delete the collection, and the security, network, and data access policies created alongside it. Nothing in Bedrock removes these for you, which the documentation states plainly. The collection is also the expensive part, billed per OCU-hour regardless of query volume.
3. **S3 last.** The bucket is only read during ingestion, so it blocks nothing at teardown. It goes last because it is the copy of your source documents, and re-ingesting is the cheapest recovery available if you decide the teardown was premature.

The console does not enforce any of this, and it gives no warning when you delete a collection that a knowledge base still points at. The reason is visible in the documentation quoted above: Bedrock treats the vector store as yours, never deletes it, and therefore never treats it as part of the knowledge base's lifecycle. That is a reasonable design that happens to leave the ordering entirely to you.

## Summary

Two knowledge bases were stuck at `DELETE_UNSUCCESSFUL` because their OpenSearch Serverless collections had been deleted before them, leaving a `dataDeletionPolicy: DELETE` data source trying to purge vectors from a store that no longer existed. Setting `dataDeletionPolicy: RETAIN` on each data source skipped that purge and let both deletes complete.

Three things worth keeping:

- **`DELETE_UNSUCCESSFUL` is terminal, not transient.** Read `failureReasons` from `GetKnowledgeBase` rather than retrying, and confirm whether the vector store still exists before reaching for IAM.
- **`UpdateDataSource` replaces the resource.** Resend the existing `chunkingConfiguration`, and verify the field you meant to change before running the delete that depends on it.
- **Tear down in dependency order.** Knowledge base, then OpenSearch Serverless, then S3. Nothing enforces it, and reversing the first two steps is the failure described above.

## References

- [Delete a data source from your Amazon Bedrock knowledge base, including the note that the vector store itself is not deleted](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-ds-delete.html)
- [UpdateDataSource API reference, with the callout saying to specify the existing chunkingConfiguration](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_UpdateDataSource.html)
- [DataSource API reference, listing dataDeletionPolicy values and the DELETE_UNSUCCESSFUL status](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_DataSource.html)
- [Delete an Amazon Bedrock knowledge base](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-delete.html)
- [AWS re:Post knowledge center: resolve the "Failed to delete knowledge base" error in Amazon Bedrock](https://repost.aws/knowledge-center/bedrock-delete-knowledge-base-error)