Multi-tenant vector isolation

How to implement multi-tenant vector isolation securely

The safest approach is to enforce tenant isolation at multiple layers: authentication, authorization, vector database partitioning, retrieval, and testing. A tenant should never be able to retrieve another customer's embeddings, document chunks, metadata, or source content—even if a developer accidentally omits a filter.

For most SaaS applications using retrieval-augmented generation (RAG), I recommend starting with a dedicated namespace per tenant or a database's native multi-tenancy feature. Use separate collections, indexes, or deployments when you need stronger isolation or contractual compliance guarantees.www.pinecone.io+2

1. Choose the right isolation strategy

Option A — Namespace per tenant

(Recommended default)

Each customer has a separate logical namespace within a shared index. Every read and write targets the authenticated customer's namespace.

Best for: SaaS applications with many customers. Example: Pinecone namespaces.

Limitation: isolation depends on correct namespace selection and access controls.

Option B — Shared collection with mandatory tenant filters

Every vector has a tenant identifier, and all searches apply an enforced filter. Qdrant supports payload-based partitioning and tenant-aware indexing.

Best for: many small tenants and cost-efficient shared infrastructure.

Limitation: a missing or incorrectly constructed filter can expose cross-tenant data.

Option C — Separate collections, indexes, or deployments

Give each tenant dedicated storage and, if needed, dedicated credentials, encryption keys, or compute.

Best for: highly regulated data, enterprise customers, residency requirements, or strong isolation needs.

Trade-off: higher operational and infrastructure cost.

Pinecone recommends namespaces as its standard multi-tenant pattern, while Qdrant recommends payload-based partitioning for many small tenants and dedicated shards for larger tenants. Weaviate provides native multi-tenancy with a separate shard per tenant.www.pinecone.io+2

2. Enforce tenant identity in your backend

This is the most important security rule: never trust a tenant ID supplied directly by the client as proof of authorization.

A secure request flow looks like this:

1. Authenticated customer

Sends a request with a valid access token

2. Authentication and authorization layer

Validates identity and verifies organization membership

3. Trusted tenant context

Derives the authorized tenant ID on the server

4. Tenant-scoped vector database

Executes reads, writes, updates and deletes within that tenant's boundary

The tenant context must be checked on every request, including background jobs and administrative operations. OWASP recommends enforcing tenant ownership at a boundary traversed by every tenant-owned access path.cheatsheetseries.owasp.org+1

3. Implement tenant-scoped retrieval

Here is a practical Python-style example using a namespace-per-tenant pattern, similar to Pinecone. The code illustrates the security architecture; adapt the SDK calls to your actual database client and authentication framework.

def search_documents(request, query_vector):
    # 1. Authenticate the caller.
    principal = authenticate(request)

    # 2. Derive the authorized tenant from trusted
    #    server-side identity and membership data.
    tenant_id = authorize_and_get_tenant(principal)

    # 3. Resolve the tenant's namespace on the server.
    namespace = tenant_namespace_for(tenant_id)

    # 4. Search only within that namespace.
    results = vector_index.query(
        namespace=namespace,
        vector=query_vector,
        top_k=10,
        include_metadata=True,
    )

    # 5. Return only authorized results.
    return results

Important implementation details:

• authenticate, authorize_and_get_tenant, and tenant_namespace_for represent your own trusted authorization functions, not built-in methods.
• Do not accept an arbitrary namespace from a request body and pass it straight to the database.
• Never expose unrestricted vector database credentials to browsers or customer applications.
• Apply the same tenant resolution to ingestion, updates, deletions, document retrieval and metadata lookups.
• If a user belongs to multiple organizations, verify which organization they are authorized to access for the current request.

For Pinecone's namespace approach, see the official multi-tenancy guide.cheatsheetseries.owasp.org+2

If you use Qdrant instead

Attach a trusted tenant identifier to every point and require a server-generated filter on every search:

from qdrant_client import models

def search_documents(client, collection, tenant_id, vector):
    # tenant_id must already be authorized by your backend.
    return client.query_points(
        collection_name=collection,
        query=vector,
        query_filter=models.Filter(
            must=[
                models.FieldCondition(
                    key="tenant_id",
                    match=models.MatchValue(value=tenant_id),
                )
            ]
        ),
        limit=10,
        with_payload=True,
    )

Create a keyword payload index for the tenant field; on supported Qdrant versions, is_tenant=True can optimize tenant-aware storage. Remember that a filter implemented only by convention is not a complete security boundary: enforce it centrally and test every access path.qdrant.tech+1

4. Secure the entire RAG pipeline, not just vector search

A common mistake is to isolate the vector query but leave other data paths unprotected.

These controls align with the OWASP RAG Security Cheat Sheet and Multi-Tenant Security Cheat Sheet.cheatsheetseries.owasp.org+1

Also consider encryption at rest and in transit, least-privilege database credentials, tenant-level quotas, and dedicated encryption keys where your risk or compliance requirements justify them.

5. Test for cross-tenant data leakage

Before production, create at least two test tenants, A and B, with uniquely identifiable documents and vectors.

Security test checklist

of

[Copy test checklist]

Automate these tests in CI and run them against the real authorization and retrieval paths. Include negative tests that deliberately omit filters, alter identifiers, reuse connections and exercise bulk operations. For stronger assurance, use a database-enforced policy or separate credentials where supported, rather than relying exclusively on application developers to remember every filter.cheatsheetseries.owasp.org+2

6. My recommended architecture

For a typical multi-tenant SaaS RAG system:

1. Authentication: use a trusted identity provider and verify tenant membership server-side.
2. Isolation: use a namespace per tenant, or the database's native multi-tenancy mechanism.
3. Authorization: centralize tenant resolution and make unscoped access impossible in ordinary customer-facing code.
4. Defense in depth: use separate credentials, enforced database policies or dedicated deployments when your threat model warrants them.
5. Testing: continuously verify that cross-tenant reads and writes fail.
6. Operations: audit access, rate-limit tenants, and implement secure deletion and recovery procedures.

No single partitioning strategy guarantees security by itself. The key is ensuring that every route to tenant-owned data passes through an enforceable authorization boundary.

Tailor this to your vector database

Which vector database and application stack are you using? I can provide a more concrete implementation, including configuration, authorization middleware and isolation tests.

Vector database

Pinecone

Qdrant

Weaviate

Milvus

PostgreSQL / pgvector

Other / undecided

Application stack

Python / FastAPI

Python / Django

TypeScript / Node.js

Java / Spring Boot

Other

Isolation requirement

Namespace per tenant

Shared index with mandatory filters

Dedicated storage per tenant

Recommend the best fit

[Build my implementation]

Implementing multi-tenant vector isolation requires balancing security/isolation guarantees, resource efficiency (cost) , and query performance . In vector databases, isolation strategies generally fall into three architectural patterns, ranging from logical separation to complete physical siloization.

Here are the primary implementation strategies for multi-tenant vector isolation, ranked from lowest isolation/highest efficiency to highest isolation/lowest efficiency:

• Metadata Filtering (Logical Isolation)
  • How it works: All customer vectors live in a single index . Each vector is tagged with a metadata field (e.g., tenant_id: "customer_A" ). Queries enforce a filter like filter={tenant_id: "customer_A"}.
  • Pros: Extremely cost-effective; highly scalable for massive numbers of tiny tenants; easy to set up.
  • Cons: Security risk (a missed filter in application code leaks data); performance penalties because the database often scans a broader index space or relies on filtered ANN (Approximate Nearest Neighbor) graphs which can degrade recall.pinecone.io+1
• Namespaces / Logical Partitions (Compartmentalized Logical Isolation)
  • How it works: Vectors are grouped into logical partitions or namespaces (supported by platforms like Pinecone or Qdrant) within the same index or collection. Queries are scoped strictly to a specific namespace.
  • Pros: Better query performance and cleaner isolation than raw metadata filtering; offboarding a tenant is as simple as dropping/deleting the namespace; reduces accidental cross-tenant queries since queries target a discrete partition.
  • Cons: Still shares the underlying cluster/infrastructure; dependent on the database provider's internal namespace separation guarantees.docs.pinecone.io+1
• Dedicated Collections / Indexes per Tenant (Physical/Isolated Compute & Storage)
  • How it works: Every customer gets their own dedicated index, collection, or database instance.
  • Pros: Maximum security and isolation (zero risk of cross-tenant data leakage via query bugs); eliminates "noisy neighbor" resource contention; custom tuning per tenant.
  • Cons: Significantly higher infrastructure overhead and cost; management complexity increases when scaling to thousands of tenants.docs.pinecone.io
• Dedicated Clusters / Siloed Infrastructure (Hard Isolation)
  • How it works: High-tier or enterprise customers get completely separate physical or virtual database clusters (e.g., separate deployments in your cloud environment).
  • Pros: Absolute enterprise-grade data security, compliance readiness (HIPAA, SOC2 strict boundaries), and dedicated resource allocation.
  • Cons: Highest cost and maintenance complexity.

Best Practices for Enforcement

1. Never trust application-level filters alone : If using metadata filtering, enforce the tenant_id injection at the middleware or database driver layer rather than relying on developers writing the WHERE clause correctly every time.cockroachlabs.com
2. Use Namespaces as a sweet spot : For most SaaS applications, namespace-level isolation (where supported) provides a great balance of performance, easy tenant deletion/offboarding, and safety.pinecone.io+1
3. Hybrid approach : Route free-tier or small tenants to a shared multi-tenant index with strict namespace/metadata boundaries, and spin up dedicated collections/clusters for enterprise clients who pay for isolated infrastructure.

To help narrow down the best architecture for your stack, could you share:

• Which vector database you are currently using (e.g., Pinecone, Milvus, Qdrant, pgvector)?
• How many tenants you plan to support, and their general size/scale?
• Your strictness requirements for compliance or data residency?

How to achieve multi-tenant vector isolation

The safest approach is to enforce tenant isolation at the vector database and application authorization layers, so that one client can never retrieve another client's embeddings, document chunks, or metadata.

If you're building a multi-tenant vector search or RAG (Retrieval-Augmented Generation) system, don't rely on the language model to enforce access control. Enforce permissions before retrieved content reaches the model. This aligns with the OWASP RAG Security Cheat Sheet.cheatsheetseries.owasp.org

1. Choose an isolation strategy

There are three common patterns. The right one depends on your number of clients, security requirements, and operational budget.

Option A: Namespace or tenant partition per client

(Good default)

Keep clients in the same index or collection, but assign each client a dedicated namespace or tenant partition. Queries are scoped to that partition.

Best for: many clients, shared infrastructure, efficient operations.

Examples: Pinecone namespaces and Weaviate multi-tenancy.www.pinecone.io+2

Option B: Shared collection with mandatory tenant filters

Store a tenant_id on every vector and apply a mandatory filter on every read, search, update, and delete operation.

Best for: many small, similarly sized tenants, especially with databases designed for tenant filtering.

Example: Qdrant payload-based multitenancy.qdrant.tech+2

Option C: Separate collection, index, or database per client

Give each client a separate data container, with its own access policies and potentially dedicated infrastructure.

Best for: strict isolation requirements, regulated workloads, custom retention policies, or dedicated customer environments.

This usually increases resource and operational overhead.www.pinecone.io+2

My recommendation: start with namespaces or native tenant partitions if your vector database supports them. Use separate infrastructure when your threat model or contractual requirements demand stronger isolation. A metadata filter alone is not a hard security boundary if application code can accidentally omit it.

2. Enforce tenant identity in a trusted backend

The most important security rule is: never trust a tenant_id supplied directly by the client.

A secure request flow looks like this:

Client request

JWT / session credential

Authentication + authorization

Validate identity and resolve permitted tenant

Tenant-scoped vector query

Inject the namespace or mandatory filter server-side

Authorized results only

Pass permitted chunks to the LLM

For example, in Python with a database that supports metadata filtering:

def search_documents(authenticated_user, query_embedding):
    # Resolve tenant membership using trusted server-side data.
    tenant_id = authorize_and_resolve_tenant(authenticated_user)

    if not tenant_id:
        raise PermissionError("No authorized tenant")

    # Illustrative API: adapt to your vector database.
    return vector_store.search(
        vector=query_embedding,
        filter={
            "tenant_id": {"$eq": tenant_id}
        },
        top_k=10,
    )

The authorize_and_resolve_tenant() function represents your actual authentication and authorization layer; it is not a built-in function. The filter syntax is illustrative and varies by database.

If users can belong to multiple organizations, resolve the requested organization against their verified membership before running the search.

3. Secure the entire data lifecycle

Isolation must cover more than similarity search. Use this checklist.

Security implementation checklist

of

OWASP specifically recommends preserving access-control metadata on every chunk, checking permissions at retrieval time, isolating tenant data, and cascading deletions through derived data and caches.cheatsheetseries.owasp.org

4. Test that cross-tenant access is impossible

Before production, create at least two test tenants, A and B, with deliberately recognizable documents.

Test direct ID lookups and administrative endpoints as well as semantic queries. Confirm that unauthorized documents are excluded before retrieval results, similarity scores, or document content can leak.

For high-assurance environments, consider independent databases or deployments, separate encryption keys, and stronger infrastructure-level access boundaries. Logical isolation in a shared database does not eliminate every possible side channel or privileged-administrator risk.

5. Apply the pattern to your vector database

The implementation details differ by provider:

• Pinecone — use one namespace per tenant as the usual starting point.
• Qdrant — use tenant payload filters, dedicated shard keys for selected tenants, or separate collections when appropriate.
• Weaviate — enable native multi-tenancy and scope operations to the correct tenant.

These are native database features, but you still need server-side authorization, safe credentials, and isolation tests.qdrant.tech+2

Which vector database and application stack are you using? For example, Pinecone, Qdrant, Weaviate, Milvus, or pgvector, with Python/FastAPI, Node.js, or LangChain. I can give you a concrete implementation for that stack, including tenant-scoped queries, writes, deletes, and automated isolation tests.

Achieving multi-tenant vector isolation requires balancing security, operational cost, and search performance . In vector search architectures (such as RAG systems or semantic search engines), isolation typically falls into three primary architectural patterns, ranging from shared-everything logical isolation to dedicated physical silos.medium.com+2

• Logical Isolation (Metadata Filtering) : All tenant vectors reside in a single shared index or collection, tagged with a tenant_id metadata field.

  • Pros : Lowest infrastructure cost, highly scalable resource pooling.
  • Cons : Weaker security boundary. A bug or omission in query-level filtering can expose cross-tenant data. Performance can also degrade if the filter matches a tiny fraction of a massive index.truto.one+1

• Namespaced / Partitioned Isolation : Tenants share the same database cluster or node infrastructure, but vectors are segregated into distinct namespaces, collections, or partition keys (e.g., using a dedicated namespace per tenant).

  • Pros : Better cost-to-isolation balance, cheaper than physical silos, easier tenant offboarding (dropping a namespace deletes all associated vectors cleanly).
  • Cons : Shared compute and memory pools mean a noisy neighbor can impact tail latencies.medium.com+2

• Physical / Siloed Isolation (Database-per-Tenant) : Each tenant gets a completely dedicated vector database instance, cluster, or isolated storage account.

  • Pros : Maximum security, compliance, and performance predictability. Perfect for enterprise or "Gold" tier clients.
  • Cons : Highest operational overhead and infrastructure cost.learn.microsoft.com+2

• Enforce at the Gateway Layer : Never rely on application logic or LLM system prompts to filter tenant data. Implement strict token-based authorization (such as signed JWTs containing a validated tenant_id claim) at your API gateway or middleware.truto.one+1

• Defense-in-Depth : Combine gateway authorization with native database-level access controls so that even internal service queries are pre-scoped to the active tenant.medium.com

• Granular Sub-Tenant Permissions : For document-level or row-level access control within a single tenant (e.g., user-specific permissions in an enterprise RAG app), append an allowed_principals metadata array during ingestion and filter dynamically at query time.truto.one

• Encryption at Rest : Utilize key-per-tenant envelope encryption managed via a Key Management Service (KMS) so that individual tenant payloads and vectors are cryptographically segregated.learn.microsoft.com+1

To help tailor this design to your stack, could you share:

• Which vector database are you currently using (e.g., Pinecone, Milvus, Qdrant, pgvector, Weaviate)?
• What is your approximate tenant scale and budget profile (hundreds of small tenants vs. a few massive enterprise clients)?

Achieving multi-tenant vector isolation requires balancing security, operational cost, and search latency . Relying on system prompts or application logic alone to keep tenant data separate introduces severe security risks.truto.one

Instead, enterprise architectures implement three primary isolation patterns, moving from logical sharing to complete physical separation.digeniotech.com

1. Metadata Filtering (Shared Index / Shared Namespace)

All tenant vectors and embeddings are stored inside a single index or collection. Every vector is tagged with a tenant_id key in its metadata layer. During a query, the application appends a metadata filter (e.g., filter={“tenantId”: “customer_123”}).truto.one+1

• Pros: Highly cost-efficient; minimal resource overhead; fast to spin up new tenants.
• Cons/Risks: Weakest isolation. If an application developer forgets to include the filter in a query or misconfigures the syntax, data leaks across tenants. It also suffers from "noisy neighbor" compute issues and inefficient scan performance on large indexes.
• Best for: Low-risk internal tools or secondary, fine-grained sub-tenant controls (like document-level RBAC).medium.com+2

2. Namespace / Partition-Based Isolation (Shared Index / Isolated Partitions)

Tenants share the same underlying database cluster or physical index, but their vectors are segregated into hard logical partitions, such as Namespaces (e.g., in Pinecone) or Tenants/Shards (e.g., native multi-tenancy in Weaviate). Queries are scoped strictly to the partition/namespace at the API connection layer.weaviate.io+3

• Pros: Strong isolation boundaries; queries are automatically restricted to the partition, making cross-tenant leakage architecturally difficult. Tenant offboarding or deletion is instantaneous (drop the namespace), and search performance is optimized because the distance calculation doesn't iterate over unrelated records.
• Cons: Higher memory consumption than pure metadata filtering, though vastly cheaper than provisioning unique hardware.
• Best for: The industry sweet spot for standard SaaS applications balancing cost, multi-tenant scale, and enterprise-grade security.pinecone.io+3

3. Dedicated Collections / Indexes Per Tenant (Siloed Model)

Every customer gets their own physically or logically independent collection, index, or separate database instance.medium.com+1

• Pros: Maximum isolation. Zero data overlap, independent HNSW/IVF index tuning per tenant (custom M and efConstruction parameters), and individual compliance/auditing capabilities. A compromise or performance degradation in one tenant's index cannot impact another.
• Cons: Expensive. Resource utilization scales poorly with thousands of tenants due to idle memory overhead for small/inactive customers.
• Best for: High-compliance enterprise tiers (e.g., HIPAA, GDPR enterprise requirements) or massive tenants with huge data footprints.medium.com+4

Core Security Enforcement Rules

Regardless of which pattern you select, production systems enforce three strict rules:

1. Never trust the prompt: Do not pass the tenant_id via LLM system instructions or dynamic text generation; enforce it programmatically in the API middleware.truto.one
2. Bind Identity to Token: Extract the tenant_id dynamically from a validated, cryptographically signed JSON Web Token (JWT ) rather than trusting parameters passed in the client request body.truto.one
3. Ingestion-Time Tagging: Stamp the isolation key (namespace or metadata ) the moment the embedding is generated and written, so untagged data cannot exist.truto.one

If you'd like, let me know:

• Which vector database you are using (e.g., Pinecone, Weaviate, Milvus, Qdrant, pgvector)
• Your approximate number of tenants and average data volume per tenant

I can provide specific configuration code or architecture recommendations tailored to your stack.

Yes. There are several well-established patterns for achieving multi-tenant vector isolation, and the most important distinction is between filtering results by tenant and enforcing tenant isolation as a security boundary.

For a production RAG (retrieval-augmented generation) system, I recommend designing isolation across the entire data path: authentication, document ingestion, vector storage, retrieval, and the LLM context. A missing tenant filter at any one of these stages can expose another customer's data.

1. The main isolation patterns

Pattern A — Shared collection with mandatory tenant filters

(Best default for many small tenants)

Store vectors for multiple customers in one collection, with a tenant_id field on every vector. Require every search, fetch, update, and delete to be scoped to the authenticated tenant.

• Advantages: low infrastructure overhead and easy scaling.
• Risks: a missing or incorrectly constructed filter can expose cross-tenant data.
• Example: Qdrant supports payload-based multitenancy.qdrant.tech+1

Pattern B — Native tenant namespaces or dedicated shards

Give each customer a separate namespace, partition, or shard, and make the tenant identifier mandatory when accessing it.

• Advantages: stronger structural separation and more predictable tenant-specific operations.
• Risks: tenant routing and administrative permissions still need to be secured.
• Examples: Weaviate uses dedicated tenant shards; Qdrant supports user-defined shards.qdrant.tech+3

Pattern C — Separate collections, databases, or deployments

Allocate a separate collection or database to each tenant, or separate infrastructure for particularly sensitive customers.

• Advantages: smaller blast radius, simpler tenant-specific deletion and stronger opportunities for resource and access isolation.
• Risks: increased cost, operational overhead, and more complex fleet management.
• Best fit: regulated workloads, enterprise isolation requirements, or a small number of large tenants. Qdrant specifically recommends reserving separate collections for a limited number of tenants that need stricter isolation.qdrant.tech+1

These patterns can also be combined. For example, use shared collections for ordinary customers and dedicated shards or deployments for high-isolation customers.

2. Security controls that make isolation reliable

The database partitioning choice matters, but the enforcement architecture matters just as much.

1. Derive tenant identity from trusted authentication

Resolve tenant_id from a validated identity token or server-side membership lookup. Do not trust a tenant ID supplied in a request body, query parameter, or arbitrary HTTP header without authorization checks. AWS describes using authenticated identity to establish tenant context.aws.amazon.com+1

2. Centralize retrieval authorization

Provide a single retrieval service that injects the mandatory tenant scope into every vector query. Avoid allowing application endpoints or LLM agents to issue unrestricted vector database queries directly.

3. Enforce the boundary on all data operations

Scope not just similarity search, but also direct ID lookups, metadata filters, hybrid search, reranking inputs, updates, deletes, and document downloads. Vector IDs should not be treated as authorization tokens.

4. Restrict direct database access

Keep vector-store credentials server-side. Use private networking where supported, least-privilege credentials, and per-tenant database identities or scoped credentials when available. Avoid giving end users unrestricted database API keys.

5. Test isolation as a security invariant

Create automated cross-tenant tests for search, fetch, update, and delete. Verify that Tenant A cannot access Tenant B's records even when it knows a document ID, manipulates filters, or supplies a forged tenant identifier.

3. Example: enforce tenant scoping in a RAG pipeline

A secure architecture looks like this:

Customer request

Authenticated user and organization membership

Authorization middleware

Validates identity and derives trusted tenant_id

Tenant-scoped retrieval service

Applies mandatory namespace, shard, or tenant filter

Vector database

Returns only authorized tenant records

Context validation → LLM

Only authorized retrieved chunks enter the prompt

For example, using Qdrant's payload-filtering model, the core query would look like this:

def retrieve_for_tenant(
    client, collection, authenticated_tenant_id, query_vector
):
    return client.query_points(
        collection_name=collection,
        query=query_vector,
        query_filter={
            "must": [
                {
                    "key": "tenant_id",
                    "match": {"value": authenticated_tenant_id},
                }
            ]
        },
        limit=10,
    )

The important part is not the filter syntax. It's that authenticated_tenant_id comes from trusted server-side authorization, never directly from the user's query. Also, the ingestion pipeline must assign ownership correctly, and all other access paths must enforce the same boundary. Qdrant documents this payload-filter approach in its multitenancy guide.qdrant.tech+1

4. Which vector database pattern should you choose?

For a concrete comparison, Pinecone recommends one namespace per tenant as its standard multitenancy pattern, with queries and other operations scoped to a namespace. www.pinecone.iodocs.pinecone.io Weaviate provides native tenant-specific shards, while Qdrant offers payload filtering and dedicated-shard options.qdrant.tech+3

5. A final security checklist

Before deploying, verify that:

• Every indexed chunk has a server-assigned tenant identifier.
• Every retrieval path enforces tenant scope by default.
• Direct record access cannot bypass authorization.
• Ingestion, retries, background jobs, and re-indexing preserve ownership.
• Caches, conversation history, and retrieval-result stores are tenant-scoped.
• Logs and observability tools do not inadvertently expose other tenants' document content.
• Cross-tenant negative tests run in CI.
• Tenant deletion covers vectors, source documents, caches, and derived indexes.

My recommendation: Start with native namespaces or tenant-specific shards when your vector database supports them. Combine that with centralized authorization and automated cross-tenant tests. Choose separate infrastructure when your security, compliance, or contractual requirements justify the additional operational cost. No partitioning mechanism alone replaces authorization.

For further architectural guidance, see the AWS SaaS tenant isolation strategies, which explains pooled, siloed, and hybrid isolation models.docs.aws.amazon.com+1