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

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:

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:

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

"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:

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

{
    "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.

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:

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

{ "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.

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:

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:

aws bedrock-agent list-knowledge-bases --region ap-northeast-1 --output 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.

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

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.
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.
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.

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

Introduction

What the console would not explain

Were the vector stores actually reachable?

Why a missing collection strands the delete

The fix: set dataDeletionPolicy to RETAIN

The pitfall: UpdateDataSource is a PUT, not a PATCH

Verification

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

Summary

References

RAG vs fine-tuning for KB search — what fine-tuning actually learns, and when pure IR wins

Two SQL shapes that stopped a text-to-SQL agent doing arithmetic in prose — ROLLUP and scalar subqueries

_override.tf runs committed Terraform in a sandbox — and apply caught what validate missed

LLMs do not "think": token prediction as the key to hallucination, prompt engineering, and prompt-leak attacks

Granted on Windows swaps a plaintext AWS key for SSO — and be aware of the two AWS logins

Deploying an MCP server on Bedrock AgentCore — Cognito OAuth, and a benchmark that lied

Introduction

What the console would not explain

Were the vector stores actually reachable?

Why a missing collection strands the delete

The fix: set dataDeletionPolicy to RETAIN

The pitfall: UpdateDataSource is a PUT, not a PATCH

Verification

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

Summary

References

Share this article

Related posts

RAG vs fine-tuning for KB search — what fine-tuning actually learns, and when pure IR wins

Two SQL shapes that stopped a text-to-SQL agent doing arithmetic in prose — ROLLUP and scalar subqueries

_override.tf runs committed Terraform in a sandbox — and apply caught what validate missed

LLMs do not "think": token prediction as the key to hallucination, prompt engineering, and prompt-leak attacks

Granted on Windows swaps a plaintext AWS key for SSO — and be aware of the two AWS logins

Deploying an MCP server on Bedrock AgentCore — Cognito OAuth, and a benchmark that lied