Manu Shukla

Posted on Jul 21 • Originally published at ecorpit.com

Bedrock Managed Knowledge Base vs self-managed RAG in 2026: 6 connectors, 8 regions, no Mumbai

#amazonbedrock

Bedrock Managed Knowledge Base vs self-managed RAG in 2026: 6 connectors, 8 regions, no Mumbai

Summary. AWS made Amazon Bedrock Managed Knowledge Base generally available on 17 June 2026 at the AWS Summit in New York. It ships six native data connectors (Amazon S3, SharePoint, Confluence, Web Crawler, Google Drive and OneDrive), automatic parsing, managed vector storage and an Agentic Retriever that plans multi-hop queries. The trade is control. A self-managed Bedrock knowledge base lets you pick your own vector store from Amazon Aurora, Amazon OpenSearch Serverless, Amazon Neptune Analytics, MongoDB, Pinecone or Redis Enterprise Cloud, write custom chunking as a Lambda function, and use GraphRAG. It also makes you pay for that store whether or not anyone queries it: an OpenSearch Serverless vector collection bills a minimum of 2 OCUs at $0.24 per OCU-hour, about $350 a month before a single retrieval, plus $0.02 per GB per month of managed storage. Managed Knowledge Base is on-demand with no upfront commitment. Two facts matter more than the feature list for teams in India. The service launched in eight regions and none of them is Mumbai. And AWS has not published a per-GB or per-retrieval rate card for it yet.

What actually shipped on 17 June 2026

The GA announcement is short and specific. Managed Knowledge Base is a fully managed RAG service that lets developers "build production-ready AI agents grounded in enterprise data without managing vector databases, data pipelines, or retrieval infrastructure."

Daniel Abib, senior specialist solutions architect at AWS, framed the design goal in the launch post: "Managed Knowledge Base abstracts away the complexity of building and managing retrieval-augmented generation (RAG) pipelines, allowing developers to focus on business outcomes rather than infrastructure management."

Three pieces do the work.

Native data connectors. Six pre-built connectors pull data and permissions from SaaS systems: Amazon S3, SharePoint, Confluence, Web Crawler, Google Drive and OneDrive. The console data-source dropdown also exposes a Custom option for programmatic ingestion.

Smart Parsing. The service picks a parsing strategy per data type and connector rather than making you configure one. AWS describes connector-specific handling, giving the example that the Web Crawler connector "preserves HTML structure including embedded images and tables" while SharePoint connectors "maintain document hierarchy and relationships between files." It detects bounding boxes in documents and sends them to foundation models for extraction, captioning and scene description in video.

Agentic Retriever. Instead of a single retrieval pass, it decomposes a question into a plan and runs multi-hop retrieval with intermediate evaluation. AWS's worked example is a query that spans two documents: what is the ML platform team's cloud infrastructure budget, and does the expense policy allow prepaying annual commitments. A single retrieval finds the budget and misses the policy link. The retriever plans three steps, retrieves at each, stops when it has enough, and returns the top results.

By default the service selects and manages the embeddings model, the re-ranker and the foundation model on your behalf. You can override each.

The architectural difference in one table

Layer	Managed Knowledge Base	Self-managed Bedrock knowledge base
Vector store	Managed by AWS, not selectable	Aurora, OpenSearch Serverless, Neptune Analytics, MongoDB, Pinecone or Redis Enterprise Cloud
Chunking	Smart Parsing defaults, customisable	Semantic, hierarchical, fixed-size, or custom Lambda using LangChain or LlamaIndex components
Parsing	Automatic per data type and connector	Bedrock Data Automation or a foundation model of your choice
Retrieval	Agentic Retriever, hybrid search, document ranking	Retrieve and RetrieveAndGenerate APIs, re-ranker models, filters
Graph retrieval	Not offered at GA	GraphRAG when Neptune Analytics is the store
Structured data	Not part of the GA description	Natural language to SQL against warehouses and lakes
Billing shape	On-demand, indexed data size plus retrievals	Your vector store's own bill, running whether queried or not

The honest summary: Managed Knowledge Base collapses storage, retrieval, embeddings, re-ranking and model selection into one primitive. The self-managed path keeps every one of those as a decision you own.

The cost question, and what AWS has not published

This is where most comparisons published in the last month go wrong, so it is worth being precise about what is on AWS's own pages as of 21 July 2026.

The launch blog states the billing model plainly: "you pay for what you use with no upfront commitments. Pricing is based on two dimensions: the size of indexed data stored and the number of retrievals performed (on-demand)."

What the Amazon Bedrock pricing page does not currently carry is a per-GB indexed-storage rate or a per-retrieval rate for Managed Knowledge Base. Its Knowledge Bases section prices two adjacent things: structured data retrieval and re-ranking. Anyone quoting you a firm dollar-per-query figure for Managed Knowledge Base right now is extrapolating, not reading a rate card.

What you can price today, from the Bedrock pricing page:

Component	Published price	Unit
Amazon Rerank 1.0	$0.001	Per rerank request of up to 100 document chunks
Cohere Rerank 3.5	$2.00	Per 1,000 queries
Structured data retrieval	$0.002	Per GenerateQuery API call
Guardrails contextual grounding	$0.10	Per 1,000 text units
Guardrails content filters	$0.15	Per 1,000 text units

A re-rank request counts document chunks, not requests, so a 350-document request bills as four. AWS's own worked example: 2 million rerank requests where half carry more than 100 documents costs $3,000 in a month.

The self-managed floor is a fixed cost

The self-managed side is easier to price and usually more expensive at low volume, because a vector store runs continuously.

Taking Amazon OpenSearch Serverless, the most common choice for a Bedrock knowledge base, AWS's pricing page states you "will be billed at least for a minimum of 2 OCUs (1 OCU indexing includes primary and standby, and 1 OCU search includes one replica for HA) for the first collection in an account." OCUs bill at $0.24 per OCU-hour in US East (N. Virginia), and AWS's own examples use 730 hours per month.

Configuration	Monthly OCU cost	Basis
Standard, 2 OCU minimum	$350.40	2 x $0.24 x 730 hours
Dev-test, 0.5 indexing + 0.5 search	$175.20	1 x $0.24 x 730 hours
Managed storage	$0.02 per GB per month	Serverless collection storage

One detail catches teams out. AWS states that "a vector search collection cannot share OCUs with search and time series collections, even if the vector search collection uses the same KMS key," and that "a new set of OCUs will be created for your first vector search collection." If you already run OpenSearch Serverless for logs, your RAG workload does not ride along on it. It starts its own meter.

So the comparison at low query volume is roughly a $350 per month fixed floor against a consumption bill that starts near zero. At high, steady volume the arithmetic can invert, which is exactly why the missing Managed Knowledge Base rate card matters: you cannot yet compute the crossover point from published prices. Model it against your own retrieval counts once AWS publishes them, and treat any number you see quoted before then as an estimate.

A note on a claim circulating in coverage of this launch: several write-ups state that OpenSearch Serverless OCUs now scale to zero after ten minutes of inactivity and that minimums have been removed. That statement does not appear on the AWS OpenSearch Service pricing page as fetched on 21 July 2026. The page does say no OCUs are consumed when an OpenSearch Ingestion pipeline is paused, and that Direct Query consumes no OCUs when idle, which are different things. Check it against your own bill before you plan around it.

For the store-selection question underneath all of this, our comparison of pgvector against a dedicated vector database covers the trade-offs in more depth.

Connectors: coverage is the real differentiator

Source	Managed Knowledge Base	Self-managed Bedrock KB
Amazon S3	Yes	Yes
SharePoint	Yes	Yes
Confluence	Yes	Yes
Web Crawler	Yes	Yes, in preview
Google Drive	Yes	Not listed
OneDrive	Yes	Not listed
Salesforce	Not listed	Yes

Google Drive and OneDrive are the meaningful additions, and they matter more than they look. AWS says the connectors "natively pull enterprise data and permissions" from these systems. Permission-aware ingestion is the part teams routinely underestimate: a knowledge base that ignores source ACLs will happily answer a question using a document the asker was never allowed to read.

If Salesforce is your system of record, note that it appears on the self-managed connector list and not in the six Managed Knowledge Base connectors at launch.

Agents, MCP and the integration path

Managed Knowledge Base is a pre-built target type in Amazon Bedrock AgentCore Gateway. Selecting a knowledge base ID exposes it through the gateway with auto-generated role-based permissions and metrics in the AgentCore Observability dashboard.

The gateway speaks Model Context Protocol, so knowledge base tools are discovered by any MCP-compatible client. AWS names Strands Agents, LangChain, CrewAI, LlamaIndex and LangGraph. Teams already tracking protocol churn should read this alongside the MCP 2026-07-28 stateless specification migration, because the transport underneath these integrations is changing this month.

Migration is the least painful part. AWS states that Managed Knowledge Base uses the same APIs as existing Bedrock knowledge bases, naming Retrieve, StartIngest, StopIngest and IngestKnowledgeBaseDocuments, so moving "requires no code changes, just point to the new knowledge base ID." That claim is worth testing on a non-production knowledge base before you believe it for yours, but it sets a low bar for a pilot.

Region availability, and why that decides it for Indian enterprises

Managed Knowledge Base launched in eight regions: US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Dublin), Europe (Frankfurt), Europe (London) and AWS GovCloud (US-West).

Asia Pacific (Mumbai) is not on that list. Neither is Asia Pacific (Hyderabad).

For an Indian enterprise this is not a latency footnote. It is a data-residency decision. Using Managed Knowledge Base today means your indexed enterprise content sits outside India, most plausibly in Singapore-adjacent Sydney or Tokyo for latency, or in Frankfurt or Dublin if EU alignment matters more.

The Digital Personal Data Protection Act 2023 does not impose a blanket localisation requirement on all personal data, and cross-border transfer is permitted except to countries the central government restricts. But sector rules layer on top. Regulated entities in banking, insurance and payments frequently operate under supervisory expectations that are stricter than DPDP alone, and a RAG index built over customer correspondence, claims files or KYC documents is squarely inside that perimeter. The practical questions to answer before you pick the managed path:

Does the corpus contain personal data as DPDP defines it, and can you evidence lawful cross-border transfer for it?
Does your sector regulator impose storage or processing conditions beyond DPDP?
Can you meet erasure and correction obligations against a managed index you cannot inspect directly?
What is your position if a region you rely on is later restricted?

For teams where those answers are uncomfortable, a self-managed knowledge base in ap-south-1 with a vector store you control remains the safer architecture, and it stays available today. Our guidance on building DPDP-ready applications covers the consent and data-handling layer around this.

AWS points to the Capabilities by Region page for regional availability and roadmap, so the sensible read is that Mumbai arrives eventually. Nothing published gives a date.

A decision framework

Pick Managed Knowledge Base when most of these hold: your sources are inside the six supported connectors, you want permission-aware ingestion without writing it, your query volume is low or spiky enough that a fixed vector-store floor is wasteful, your team has no one who wants to own chunking strategy, and your data can lawfully sit outside India.

Pick a self-managed knowledge base when any of these bind: you need an Indian region today, you need GraphRAG or natural-language-to-SQL over structured stores, you need Salesforce ingestion, you have already tuned a chunking and embedding strategy that beats defaults on your evaluation set, or you need the vector store to be portable off AWS.

The middle path is the one most teams should take. The APIs are shared, so run both against the same evaluation set for a fortnight. Measure retrieval quality on your own questions rather than on AWS's example, and measure the bill. Two weeks of real numbers will settle an argument that a feature table cannot.

The real cost here is rarely the infrastructure. It is the evaluation harness you should have built before choosing either.

FAQ

When did Amazon Bedrock Managed Knowledge Base become generally available?

AWS announced general availability on 17 June 2026 at the AWS Summit in New York. It launched with six native data connectors, Smart Parsing, an Agentic Retriever, and native integration with Amazon Bedrock AgentCore Gateway. The service uses the same APIs as existing Bedrock knowledge bases, so migration requires pointing at a new knowledge base ID.

Which data connectors does Managed Knowledge Base support?

Six connectors ship at launch: Amazon S3, SharePoint, Confluence, Web Crawler, Google Drive and OneDrive. The console also exposes a Custom option for programmatic ingestion. AWS says these connectors pull both data and permissions from the source system. Salesforce appears on the self-managed connector list rather than in the managed six.

Is Managed Knowledge Base available in an Indian AWS region?

No. At general availability it runs in US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney and Tokyo), Europe (Dublin, Frankfurt and London) and AWS GovCloud (US-West). Neither Mumbai nor Hyderabad is included, which makes data residency the deciding factor for many regulated Indian workloads.

How much does Managed Knowledge Base cost?

AWS states pricing is on-demand across two dimensions, the size of indexed data stored and the number of retrievals performed, with no upfront commitments. As of 21 July 2026 the Bedrock pricing page does not publish a per-GB or per-retrieval rate for it. Published adjacent charges include Amazon Rerank 1.0 at $0.001 per request.

What does a self-managed vector store cost by comparison?

An Amazon OpenSearch Serverless collection bills a minimum of 2 OCUs for the first collection in an account, at $0.24 per OCU-hour. Across 730 hours that is about $350 a month before any query, plus $0.02 per GB per month of managed storage. A dev-test collection halves the compute to roughly $175.

Can a vector search collection share OCUs with an existing OpenSearch collection?

No. AWS states a vector search collection cannot share OCUs with search or time series collections even when it uses the same KMS key, and that a new set of OCUs is created for your first vector search collection. Existing OpenSearch spend does not absorb a new RAG workload.

What does the Agentic Retriever do differently?

It decomposes a complex question into a step-by-step plan and performs multi-hop retrieval with intermediate evaluation, rather than a single retrieval pass. AWS's example spans a team budget document and an expense policy, which a single pass would not connect. It stops searching once it has gathered sufficient relevant passages.

Does moving to Managed Knowledge Base require rewriting application code?

AWS says no. Managed Knowledge Base uses the same Retrieve, StartIngest, StopIngest and IngestKnowledgeBaseDocuments APIs as existing Bedrock knowledge bases, so migration means pointing to a new knowledge base ID. Validate this against a non-production knowledge base first, and compare retrieval quality on your own evaluation set.

How eCorpIT can help

eCorpIT is a CMMI Level 5 certified technology consulting organisation in Gurugram, and an AWS partner. Our senior engineering teams build RAG systems on both paths: managed knowledge bases where speed to production matters, and self-managed vector stores in ap-south-1 where data residency or retrieval tuning decides the architecture. We build the evaluation harness first, so the choice is settled by measured retrieval quality and a real bill rather than a feature comparison. If you are weighing this decision for a regulated workload, get in touch.