Multi-Tenant RAG You Can Trust: The S3 Vectors Case

Multi-tenant RAG has a failure mode that never shows up in a demo. A user asks a question scoped to their own account, the retrieval layer quietly returns three documents instead of the twenty that exist, and the model fills the gap with confident nonsense. Amazon S3 Vectors just shipped a fix for the retrieval half of that problem, at no extra cost, and it changes how you should think about where your company’s AI knowledge lives.

The quiet bug in multi-tenant RAG

Most production RAG systems serve more than one audience from a single index: customers, business units, legal matters, regions. Every query carries a filter that says “only search this tenant’s stuff.” That filter is your isolation boundary and your relevance boundary at the same time.

Here is the catch. Vector search engines are built to be approximately right, fast. When a filter is very selective, say one customer’s 400 tickets out of 8 million (the example AWS uses in its launch announcement), many engines search the whole haystack first and apply the filter along the way. The matching documents are scattered, the search runs out of budget, and you get a short or mediocre result list. No error. No alert. Just worse answers.

For the business, that shows up as:

• Hallucination you can’t trace. The model didn’t have the right document, so it improvised. Your team blames the model. The model is innocent.
• Missing-document complaints. “I know the contract says this, why can’t the assistant find it?” Support tickets about AI accuracy are expensive and erode adoption fast.
• Pressure to weaken isolation. Engineers under deadline “fix” thin results by falling back to an unfiltered search. That is how one tenant’s data ends up in another tenant’s answer.

What AWS changed

As of September 30, 2026, S3 Vectors offers an ENHANCED index mode that applies the metadata filter first and only then ranks the matching vectors by similarity. AWS reports up to 5x higher recall on highly selective filtered searches. The practical points for a decision maker:

• No additional cost. Standard S3 Vectors storage, write and query pricing applies.
• New buckets get it by default. Vector buckets created on or after September 30 use ENHANCED automatically.
• Existing indexes need a flip. Older indexes stay on the previous CLASSIC behavior until someone switches them. It is a configuration change, not a data migration. No re-embedding, no downtime project.
• Broad availability. All commercial Regions where S3 Vectors runs, plus the China Regions.

That third bullet is the one to put on someone’s task list this week. If your RAG platform went live on S3 Vectors before October, it is running the old behavior right now.

Tenant isolation and compliance scoping

Pre-filtering is not a security control on its own. A filter is only as good as the code that builds it, and a bug that omits the tenant clause still leaks. But it removes the main engineering incentive to cut corners, because the filtered search now returns what it should. Combine it with controls you can audit:

• Tenant ID injected server-side from the authenticated session, never from the prompt or the client.
• Separate indexes or buckets for regulated tenants who contractually require physical separation. S3 Vectors allows up to 10,000 indexes per bucket, per the service limits, so this is cheap to do.
• IAM policies scoping which applications can query which buckets, with AWS CloudTrail logging access.
• Retrieval evaluations that test isolation explicitly: “does a query for tenant A ever return tenant B?” should be a gate in your release process.

For legal, financial services and media teams, the same mechanism handles matter-level scoping, issuer and date restrictions, and regional licensing rules. Those were the use cases AWS called out, and they are exactly where a missed document is a liability rather than an annoyance.

The cost argument: S3 Vectors vs always-on vector databases

The traditional options for RAG retrieval are a managed search cluster such as Amazon OpenSearch Service or a Postgres database running pgvector. Both are excellent. Both also bill you for provisioned compute and memory around the clock, whether anyone asks a question or not, and both get pricey as corpora grow into hundreds of millions of vectors.

S3 Vectors flips that model. You pay for storage, writes and queries, with no cluster to size. When AWS launched the service it pitched up to 90% lower total cost than conventional vector stores for upload, storage and query. Your mileage depends on query volume, so run your own numbers against the S3 pricing page. The tradeoff is latency: AWS documents roughly 100 ms for frequently queried indexes and sub-second for infrequent ones.

A sensible split for most organizations:

• S3 Vectors for large, long-tail, tenant-scoped knowledge: document archives, support history, contracts, agent memory. High volume of data, moderate volume of queries.
• OpenSearch for hot, high-QPS workloads that need hybrid keyword search or complex aggregations. AWS supports exporting from S3 Vectors to OpenSearch for exactly this.
• pgvector when vectors must sit transactionally next to relational data you already run in Postgres.

Before this release, the honest objection to S3 Vectors for multi-tenant work was filtered recall. That objection is now mostly gone, which makes the cheaper tier a credible default for a large share of RAG data.

Governance: what to ask your team this week

You don’t need to read API docs to run this decision well. You need answers to five questions:

1. Which of our RAG indexes run on S3 Vectors, and which are still in CLASSIC mode?
2. Do we have a recall benchmark for filtered queries, broken out by how selective the filter is? If not, build one before flipping modes, so the improvement is measured rather than assumed.
3. Where does the tenant filter come from in code, and who reviews changes to it?
4. Do any services fall back to unfiltered search when results look thin? Those fallbacks should be removed after the switch.
5. What is our current monthly spend on vector infrastructure, and how much of that corpus is cold enough to move to S3 Vectors?

If your stack uses Amazon Bedrock Knowledge Bases with S3 Vectors underneath, the same questions apply. The managed layer does not change the index mode for you.

The bottom line

RAG quality is mostly a retrieval problem wearing a model costume. S3 Vectors pre-filtering takes a known, silent retrieval failure off the table for tenant-scoped search, costs nothing extra, and requires a configuration change rather than a rebuild. Combined with storage-priced economics, it moves S3 Vectors from “cheap archive tier” to a serious default for multi-tenant knowledge. The risk of doing nothing is that your older indexes keep under-returning documents, and your users keep blaming the AI.

At Enkompass (enkompass.net), this is our home turf. We ship production Bedrock RAG and agent workloads with tenant-scoped retrieval on S3 Vectors, including the recall benchmarks and isolation tests that prove they behave. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.