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

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:

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.

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

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

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.

References

1. AWS, "Amazon Bedrock Managed Knowledge Base is now generally available", AWS What's New, 17 June 2026.

1. Daniel Abib, "Introducing Amazon Bedrock Managed Knowledge Base for faster, more accurate enterprise AI applications", AWS News Blog, 17 June 2026.

1. AWS, "Amazon Bedrock Knowledge Bases product page".

1. AWS, "Amazon Bedrock Pricing", retrieved 21 July 2026.

1. AWS, "Amazon OpenSearch Service Pricing", retrieved 21 July 2026.

1. AWS, "AWS Capabilities by Region".

1. AWS, "Amazon Bedrock AgentCore".

1. AWS, "Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases", Amazon Bedrock User Guide.

1. AWS, "Fully managed RAG with Knowledge Bases for Amazon Bedrock", AWS Prescriptive Guidance.

1. AIwire, "AWS Launches Amazon Bedrock Managed Knowledge Base for Enterprise RAG Applications", 17 June 2026.

1. DevelopersIO, "Amazon Bedrock Managed Knowledge Base fully managed RAG service now generally available".

1. AWS Builder Center, "How Amazon Bedrock Managed Knowledge Base eliminates the plumbing".

Last updated: 21 July 2026.