Amazon Bedrock Knowledge Base Costs Don't Show Up Under Bedrock

Your Bedrock bill is clean. Your OpenSearch bill is $347 this month. You don't use OpenSearch.

When a team creates an Amazon Bedrock Knowledge Base using the default Quick-create flow, AWS silently provisions an Amazon OpenSearch Serverless collection as the vector store. That collection starts billing immediately โ€” and keeps billing until it is explicitly deleted from a completely separate console.

The billing disguise is the story. There is no "Amazon Bedrock Knowledge Base" line item in your bill. The cost appears under Amazon OpenSearch Service as SearchOCU and IndexingOCU charges. A FinOps tool scanning for Bedrock anomalies will find nothing. The waste is invisible unless you know to look in the wrong place.

The mechanism has two parts. First, OpenSearch Serverless is not genuinely pay-per-use. "Serverless" in the name refers to operations, not billing. Two OCUs are always provisioned from the moment the collection is created: one SearchOCU and one IndexingOCU. At $0.24 per OCU per hour, that is $0.48/hour running 24 hours a day regardless of query volume โ€” $11.52/day, $345/month, whether you send one query or ten thousand. Second, when you delete the Knowledge Base from the Bedrock console, the OpenSearch collection is not deleted. AWS does not cascade the deletion. The collection keeps billing under Amazon OpenSearch Service while the Knowledge Base no longer exists in the Bedrock console.

The result: teams budget for Bedrock inference tokens. They get a surprise OpenSearch bill they cannot explain, for a resource they believe they already cleaned up.

The Billing Signal

FOCUS / CUR FieldWhat you expectWhat you get
ServiceName Amazon Bedrock Amazon OpenSearch Service
x_UsageType InvokeModelInference SearchOCU, IndexingOCU
ResourceId A Bedrock resource ARN bedrock-knowledge-base-<uuid> โ€” the collection name reveals the origin
BilledCost per day Low โ€” cents to a few dollars (inference tokens) $11.52/day flat โ€” identical at zero queries or 10,000 queries
Temporal profile Rises and falls with usage Perfectly flat โ€” no diurnal pattern, no weekday/weekend variation
Bedrock inference rows after KB deleted Drops to zero (expected) Absent โ€” but OpenSearch OCU charges continue unchanged

The detection condition: Amazon OpenSearch Service OCU charges present in an account, with zero or near-zero Amazon Bedrock inference rows in the same 30-day window. The OpenSearch spend has no associated search workload โ€” it exists only to back an idle or already-deleted Knowledge Base.

Real Incidents

These five incidents are sourced from public posts, AWS re:Post threads, and FinOps practitioner analysis. None are fabricated.

~$107 โ€” Hemanth D (Medium): Built a RAG pipeline using Bedrock KB Quick-create, never interacted with the OpenSearch console, discovered a $107 charge at month-end in Cost Explorer under "Amazon OpenSearch Service." The line items were SearchOCU and IndexingOCU. There was no "Bedrock" label anywhere on the bill.

~$200 โ€” MaruAI (Medium): Near-$200 bill after embedding a small document set and running light query tests. The author's framing: "'serverless' and 'on-demand' function primarily as marketing terms rather than guarantees of genuine pay-per-use economics."

~$10 for 10 queries (Reddit, via MaruAI article): Embedded less than 2 GB of PDFs, ran approximately 10 queries to the LLM, racked up $10 in 21 hours. Both SearchOCU and IndexingOCU started billing at collection creation โ€” before a single document was embedded. Quote: "It's supposedly serverless, but already racked up 21 hours for indexing and 21 hours for search."

$20 โ†’ $300+ (AWS re:Post thread): A user's monthly bill jumped from ~$20 to over $300 after testing Bedrock KBs. A second user in the same thread: $260 bill because the system allocated the minimum 4 OCUs for their configuration. A third user deleted the KB after 1 hour, assuming the collection would also be destroyed. They received an AWS Budgets alert 2 days later showing OpenSearch charges still running.

$170โ€“$700+/month per idle KB (Binadox FinOps analysis): A single unused Knowledge Base was estimated to cost between $170 and over $700/month depending on configuration. The Binadox report explicitly notes: "costs appear under 'Amazon OpenSearch Service' โ€” making it difficult to associate them with specific Bedrock projects." FinOps practitioners scanning for a Bedrock cost anomaly miss this entirely because the service name is wrong.


If you built it: what to look for and how to fix it

For platform engineers, ML engineers, and DevOps engineers who provisioned a Bedrock Knowledge Base.

The bill doesn't tell you what happened. There is no "Knowledge Base" label on any line item. Here is exactly how to trace the charge back to its source and shut it off.

Step 1 โ€” Find the charge in Cost Explorer

In AWS Cost Explorer: set Service = Amazon OpenSearch Service, group by Usage Type. Look for rows labeled SearchOCU and IndexingOCU. If those rows are present and you don't have a deliberate OpenSearch Serverless workload, you have an idle or orphaned Knowledge Base collection.

For more detail: switch to group by Resource (requires resource-level cost allocation enabled). Look for resource IDs containing bedrock-knowledge-base-. AWS auto-names Bedrock KB collections with that prefix โ€” if you see it, the collection was created by a Knowledge Base, not by a standalone OpenSearch workload.

Step 2 โ€” Find the orphaned collection

AWS Console โ†’ Amazon OpenSearch Service โ†’ Serverless โ†’ Collections. Look for any collection named bedrock-knowledge-base-<uuid>. Cross-reference against active Knowledge Bases in the Bedrock console (Bedrock โ†’ Knowledge Bases). If no active Knowledge Base references the collection โ€” it is orphaned.

Via CLI:

# List all OpenSearch Serverless collections
aws opensearchserverless list-collections

# Cross-reference: list active Bedrock Knowledge Bases
aws bedrock list-knowledge-bases

Any collection matching bedrock-knowledge-base-* that has no corresponding active Knowledge Base is generating waste.

Step 3 โ€” Delete correctly (from the OpenSearch console, not Bedrock)

This is where teams get it wrong a second time. Deleting the Knowledge Base from the Bedrock console does not delete the OpenSearch collection. You must delete the collection separately:

  1. AWS Console โ†’ Amazon OpenSearch Service โ†’ Serverless โ†’ Collections
  2. Select the orphaned collection
  3. Delete โ€” billing stops immediately (no "stopped" state; deletion is the only off switch)

Via CLI:

aws opensearchserverless delete-collection --id <collection-id>

The billing stops on deletion. There is no grace period, no lingering charge.

Step 4 โ€” New projects: don't use Quick-create

The Quick-create flow is what silently provisions OpenSearch Serverless. The alternative:

The detection SQL (FOCUS-native)

If you have FOCUS-formatted billing exports (AWS Data Exports), this query identifies accounts where OpenSearch OCU costs are more than 10x Bedrock inference costs โ€” the cross-service signature of an orphaned or idle Knowledge Base:

-- QB18: Orphaned Bedrock Knowledge Base โ€” OCU cost >> Bedrock inference
-- Two-CTE join across servicename values within the same focus_billing table.
WITH ocu_daily AS (
    SELECT
        subaccountid,
        SUM(CASE WHEN x_usagetype LIKE '%OCU%' THEN billedcost ELSE 0 END) AS ocu_cost_30d,
        COUNT(DISTINCT resourceid) AS ocu_collection_count
    FROM focus_billing
    WHERE servicename LIKE '%OpenSearch%'
      AND x_usagetype LIKE '%OCU%'
      AND chargecategory = 'Usage'
      AND chargeperiodstart >= CAST(DATE_ADD('day', -30, CURRENT_DATE) AS TIMESTAMP)
    GROUP BY subaccountid
),
bedrock_inference AS (
    SELECT
        subaccountid,
        SUM(billedcost) AS bedrock_inference_cost_30d
    FROM focus_billing
    WHERE servicename LIKE '%Bedrock%'
      AND x_usagetype LIKE '%InvokeModel%'
      AND chargecategory = 'Usage'
      AND chargeperiodstart >= CAST(DATE_ADD('day', -30, CURRENT_DATE) AS TIMESTAMP)
    GROUP BY subaccountid
)
SELECT
    o.subaccountid,
    o.ocu_cost_30d,
    o.ocu_collection_count,
    COALESCE(b.bedrock_inference_cost_30d, 0.0) AS bedrock_inference_cost_30d,
    o.ocu_cost_30d / NULLIF(COALESCE(b.bedrock_inference_cost_30d, 0.0), 0) AS ocu_waste_ratio
FROM ocu_daily o
LEFT JOIN bedrock_inference b ON o.subaccountid = b.subaccountid
WHERE o.ocu_cost_30d > 50.0
  AND COALESCE(b.bedrock_inference_cost_30d, 0.0) < (o.ocu_cost_30d * 0.10)
ORDER BY o.ocu_cost_30d DESC
LIMIT 25

Threshold rationale: ocu_cost_30d > $50 suppresses single-day test collections that haven't accrued meaningful waste yet (~5 days of minimum billing). The 10ร— ratio catches accounts where the OpenSearch meter is running without a proportionate AI workload โ€” the defining signature of an idle or orphaned collection.


If you watch the bill: how to detect this at scale

For FinOps practitioners and cloud finance analysts responsible for multi-account visibility.

The tricky part of this pattern for FinOps is that the charge looks unremarkable. OpenSearch Serverless OCU rows don't flag as anomalies in most rules-based tools. They are flat, they are small relative to total cloud spend in most environments, and there is nothing in the line item itself that signals "this is backing a feature in a different service."

Multi-account detection

In Cost Explorer: set the date range to the last 30 days, Service = Amazon OpenSearch Service, Group by = Usage Type. If any account shows SearchOCU or IndexingOCU charges, flag it for investigation. Most accounts don't run OpenSearch Serverless deliberately โ€” these charges are often the first sign.

For a systematic view across all accounts: use the detection SQL above against your consolidated billing export. Run it account by account or across your organization's consolidated payer account. A result set with any rows is an immediate action item.

Dollar impact math

The floor cost is deterministic. Each idle Knowledge Base collection costs:

Teams that tested multiple KB configurations โ€” a common pattern for AI prototyping โ€” may have two, three, or four orphaned collections across dev, staging, and sandbox accounts. At three idle collections: $1,036/month in invisible OCU charges. At ten: $3,456/month. These are pre-tax charges that compound quietly for months before anyone looks.

Setting up the alert

AWS Budgets: create a cost budget for service = Amazon OpenSearch Service, filter by usage type containing "OCU". Set a threshold at ~$50/month (roughly 4โ€“5 days of minimum billing). This catches newly orphaned collections within a week of creation โ€” before the monthly bill arrives.

For stricter detection: set up a CloudWatch metric alarm or AWS Cost Anomaly Detection monitor specifically on OpenSearch Serverless spending. Cost Anomaly Detection can detect an unexpected new spend pattern within 24โ€“48 hours, which is the fastest path to catching a newly orphaned collection.

Escalation template

When you find the charge and trace it to a team:

We found OpenSearch Serverless OCU charges in [account name] totaling $[X] over the past 30 days. These appear to be from a Bedrock Knowledge Base collection named bedrock-knowledge-base-[uuid]. There are no corresponding Bedrock inference charges in the same period, which suggests the Knowledge Base was deleted but the OpenSearch collection was not.

Action needed: log into the Amazon OpenSearch Service console โ†’ Serverless โ†’ Collections and delete this collection if it is no longer in use. The billing stops immediately on deletion. If this collection is still needed, let us know the owning project so we can tag it correctly.

Tagging and tracking going forward

The root problem is that Quick-create bypasses the tagging step. A collection provisioned through the Bedrock console inherits none of the tags you'd normally require for a new AWS resource. Enforce this at the IaC level: any Knowledge Base created through Terraform or CDK should tag the corresponding OpenSearch collection with owner, project, bedrock-kb-id, and environment. This makes future audits trivial and keeps orphaned collections from being unattributable.


If you own the outcome: the governance gap and how to close it

For Engineering Managers, VPs of Engineering, and CTOs who need root cause and a process fix.

What happened, in plain English

Your team created a Bedrock AI feature using AWS's default setup flow. That flow silently creates infrastructure in a completely separate AWS service โ€” Amazon OpenSearch โ€” without clearly communicating this in the UI or in any billing documentation at the point of provisioning. When your team finished testing and deleted the feature, they deleted the Bedrock Knowledge Base. AWS does not automatically delete the OpenSearch infrastructure that backs it. That infrastructure kept billing.

The billing appeared under "Amazon OpenSearch Service" โ€” a service your team doesn't use deliberately. No existing alert was configured to catch unexpected OpenSearch spend. Nobody looked at OpenSearch line items. The charge accumulated for weeks or months before someone noticed a number that didn't belong.

This is not operator error in the traditional sense. The two-step deletion requirement is not documented in the Bedrock Quick-create flow. The billing disguise is a consequence of AWS's service architecture, not a team misconfiguration. But the result โ€” real dollars spent on nothing โ€” is the same regardless of cause.

The governance gap

Three things failed simultaneously:

  1. No lifecycle policy for AI infrastructure. When your team spun up a Bedrock Knowledge Base for a proof-of-concept, there was no requirement to provision it through IaC (Terraform, CDK), no tag enforcement, and no cleanup checklist. Console-click provisioning bypasses every governance layer you've built for traditional infrastructure.
  2. No alert on new OpenSearch spend. A budget alert on OpenSearch Serverless OCU usage would have fired within a week of the collection being created. That alert didn't exist because nobody anticipated OpenSearch charges from a Bedrock project.
  3. Two-console deletion is an undocumented gotcha. The Bedrock console gives no indication that deleting a Knowledge Base leaves an OpenSearch collection running. The gap is in AWS's product, not your process โ€” but the cost falls on you.

The policy fix

Three changes close the gap:

  1. Require IaC for all Knowledge Base provisioning. No Quick-create in production or staging. Any Bedrock Knowledge Base created through Terraform or CDK must tag the corresponding OpenSearch collection and include a deletion lifecycle aligned with the project lifecycle. This makes "delete the feature" a single operation that cleans up both resources.
  2. Add an OpenSearch Serverless OCU budget alert. Threshold: $50/month. Recipient: whoever owns the cloud bill for that account. First-line response: check the OpenSearch console for collections named bedrock-knowledge-base-* and cross-reference against active Knowledge Bases. This catches orphans within a week of creation.
  3. Migrate new projects to S3 Vectors. As of December 2025, Amazon S3 Vectors is available as the vector store for new Bedrock Knowledge Bases. It is genuinely pay-per-use, has no OCU floor, and costs up to 90% less for moderate workloads. Make S3 Vectors the default in your IaC templates going forward. Existing KBs can be migrated.

The decision on existing collections

For any idle or orphaned collections already running: delete them. The billing stops immediately. There is no cost to deletion and no value being delivered by an idle collection. If there is uncertainty about whether a collection is still in use, check the Bedrock console โ€” if no active Knowledge Base references it, it's not in use.

For active Knowledge Bases backed by OpenSearch Serverless: evaluate migration to S3 Vectors. The migration path exists. The business case is straightforward: at $345/month per collection, a team running five Knowledge Bases in production is spending $1,725/month on vector storage alone. Migrating to S3 Vectors brings that to near-zero for the same query volume.

What good looks like

Every OpenSearch Serverless collection in your organization is tagged to an owning team, a project, and a corresponding Bedrock Knowledge Base ID. New collections cannot be created through the console in any environment above sandbox โ€” IaC is the only path. An OpenSearch OCU budget alert fires within 48 hours of any new OCU spend appearing in any account. When a Knowledge Base is decommissioned, the Terraform destroy tears down both resources atomically.


Fix checklist

  1. Audit now. In Cost Explorer: Service = Amazon OpenSearch Service, Group by = Usage Type. Any SearchOCU or IndexingOCU rows you can't attribute to a deliberate OpenSearch workload are candidates for investigation.
  2. Find orphaned collections. AWS Console โ†’ Amazon OpenSearch Service โ†’ Serverless โ†’ Collections. Look for bedrock-knowledge-base-* naming. Cross-reference against active Knowledge Bases in the Bedrock console.
  3. Delete from the OpenSearch console, not Bedrock. Bedrock KB deletion does not cascade. The collection must be deleted separately. Billing stops immediately on deletion.
  4. Set a budget alert on OpenSearch OCU spend. Threshold: $50/month. Catches new orphans within a week of collection creation, before the monthly bill arrives.
  5. Require IaC for new Knowledge Bases. No Quick-create in production or staging. Terraform or CDK only โ€” with tagging and lifecycle tied to the project lifecycle.
  6. Default to S3 Vectors for new projects. No OCU floor, pay-per-use, up to 90% cheaper than OpenSearch Serverless for typical Knowledge Base workloads.
  7. Run a quarterly OpenSearch Serverless audit. Collections named bedrock-knowledge-base-* with no active Bedrock KB reference: delete or escalate to the owning team within 48 hours.

Find out what else is hiding in your AI cloud bill

The Bedrock Knowledge Base pattern is one of several AI spend anomalies that standard FinOps tools miss because they cross service boundaries. The DropInFinOps free assessment takes 2 minutes and shows you which patterns your current billing setup is positioned to catch โ€” and which ones are accumulating undetected.

Take the free assessment โ†’