2.7 Vector Store Security, Multi-Tenancy & Connectivity

2.7 Vector Store Security, Multi-Tenancy & Connectivity

Vector Store Architectural Comparison Matrix

---

Multi-Tenant Isolation Patterns in Vector Databases

Enterprise RAG architectures frequently serve multiple corporate tenants or user roles with strict confidentiality requirements.

Pattern 1: Metadata Filtering (Soft Isolation)

• Mechanics: All tenants share a single vector index. Every ingested chunk includes a tenant_id metadata attribute.
• Query Time: Runtime calls inject a strict metadata filter: {"filter": {"equals": {"key": "tenant_id", "value": "tenant_442"}}}.
• Pros: Highly cost-effective; minimizes baseline OCU/instance overhead; simple operational model.
• Risks: Application-level misconfiguration could leak data; neighbor graph traversal in HNSW can occasionally suffer search quality degradation if a tenant filter excludes 99% of graph nodes.

Pattern 2: Schema / Table-Level Isolation (Aurora PostgreSQL)

• Mechanics: Each tenant receives an independent PostgreSQL table or schema within the same Aurora database.
• Security: Can be enforced using PostgreSQL Row-Level Security (RLS) policies tied to database application roles.
• Pros: Strong database-enforced security boundaries; complete ACID guarantees per tenant.

Pattern 3: Index-per-Tenant (Hard Isolation)

• Mechanics: A dedicated vector index or collection is provisioned for each customer tenant.
• Pros: Separate vector graphs reduce application-filter mistakes, but access policies and negative tests are still required.
• Cons: Substantial infrastructure cost; limits on maximum collections/indices per account; administrative scaling bottleneck.

---

AWS Secrets Manager & Network Security Configuration

When connecting Bedrock Knowledge Bases to third-party or provisioned vector stores (Aurora, Pinecone, MongoDB, Redis), security integration relies on AWS Secrets Manager and IAM:

1. Secrets Manager Integration:
   • Database administrative credentials (PostgreSQL username/password, Pinecone API key) are stored in an AWS Secrets Manager secret.
   • The Bedrock Knowledge Base service execution role must possess explicit permissions: secretsmanager:GetSecretValue on the secret ARN, and kms:Decrypt on the KMS key used to encrypt the secret.
2. Network & VPC Routing:
   • If Amazon Aurora is deployed inside a private VPC, Bedrock must be granted access.
   • For OpenSearch Serverless, a VPC Network Policy or public network policy must be associated with the vector collection, accompanied by an Encryption Policy (AWS KMS) and a Data Access Policy allowing the Bedrock service role ARN aoss:Create*, aoss:Update*, and aoss:Describe* permissions.

---

Exam Scenarios & Architectural Traps

Exam Scenario 1: The Relational Joining Requirement

A retail bank is building an internal RAG assistant to answer employee questions regarding client loans. The loan contracts are stored as vector embeddings, but user queries must only return contracts where loan_status = 'ACTIVE', risk_tier < 3, and the employee has regional territory clearance in the employee management database.

• Architectural Solution: Choose Amazon Aurora PostgreSQL with pgvector. This allows the application to execute a single query joining the vector similarity search (<=> cosine distance operator) directly against relational tables containing loan statuses and employee territory permissions, enforcing complete ACID consistency.

Exam Scenario 2: Index Degradation with IVFFlat

A development team selects Amazon Aurora with pgvector and builds an IVFFlat index over 100,000 initial documents. Over the next six months, the data volume triples to 300,000 documents. Users report that search recall has dropped noticeably and queries frequently miss recently added documents.

• Root Cause & Solution: IVFFlat partitions vectors around fixed centroid lists determined at index creation time. As new vectors are inserted, they are assigned to existing centroids without re-clustering, causing vector drift and degraded recall. The team must either:
  1. Transition the index to HNSW, which dynamically updates its multi-layer graph on every insert without requiring retraining.
  2. Implement a scheduled maintenance job that runs REINDEX INDEX during off-peak hours.

Common Trap: Assuming a Universal OpenSearch Serverless OCU Floor

A startup provisions an Amazon OpenSearch Serverless collection for a development/testing Knowledge Base that only holds 50 small documents. At the end of the month, they are surprised by an unexpected bill. OpenSearch Serverless capacity and minimums now depend on collection generation and configuration; current NextGen collection groups can support a minimum of zero for scale-to-zero. Check the current capacity documentation rather than assuming a universal 4-OCU floor. For low-volume development testing, Aurora Serverless v2 with pgvector or Pinecone Serverless can be significantly more economical.