https://theawsblog.com/tags/multitenancy/Articles, tutorials and insights from the AWS community.Hugoen@theawsblog (The AWS Blog)@theawsblogWed, 24 Jun 2026 00:00:00 +0000https://theawsblog.com/news/emiliano-montesdeoca/opensearch-serverless-multitenant-search/Wed, 24 Jun 2026 00:00:00 +0000Emiliano Montesdeocahttps://theawsblog.com/news/emiliano-montesdeoca/opensearch-serverless-multitenant-search/Amazon OpenSearch Serverless next-generation architecture makes collection-per-tenant search more practical with scale-to-zero compute and regional endpoint routing.<p>Multi-tenant search has always forced an uncomfortable trade-off: isolate tenants cleanly and pay for too much infrastructure, or pool tenants together and accept more operational and security complexity.</p> <p>The AWS Big Data Blog post on <a href="https://aws.amazon.com/blogs/big-data/implement-multi-tenant-search-with-amazon-opensearch-serverless-next-generation/">multi-tenant search with Amazon OpenSearch Serverless next generation</a> is important because it changes that cost model. Scale-to-zero compute and regional endpoint routing make collection-per-tenant designs more realistic.</p> <h2 id="what-changed">What changed</h2> <p>OpenSearch Serverless next-generation architecture lets collection groups scale compute to zero, while storage charges still apply. AWS also added a per-account, regional endpoint that can route requests to collections using headers such as <code>x-amz-aoss-collection-name</code>.</p> <p>That means a SaaS application can keep a cleaner collection-per-tenant model without managing a separate endpoint and connection pool for every tenant.</p> <h2 id="why-builders-should-care">Why builders should care</h2> <p>Tenant isolation is easier to discuss in architecture reviews than to pay for in production.</p> <p>A collection-per-tenant design gives strong isolation boundaries for data, workload behavior, encryption, lifecycle, and noisy-neighbor risk. But if each tenant carries a minimum always-on compute cost, the design breaks down for long-tail tenants.</p> <p>Scale-to-zero compute makes the model more practical for SaaS platforms with many tenants that search occasionally. The regional endpoint also simplifies application routing. Instead of maintaining many endpoints, the application can target one endpoint and route by collection header.</p> <h2 id="the-trade-offs">The trade-offs</h2> <p>Collection-per-tenant is not automatically the best design.</p> <p>For very small tenants with similar access patterns, pooled indexes may still be simpler. For very large tenants, dedicated collections or even separate domains may be appropriate. For regulated tenants, encryption, access policy, and audit boundaries may matter more than cost.</p> <p>Builders should also design the tenant mapping layer carefully. A regional endpoint reduces endpoint sprawl, but the application still needs a reliable mapping from tenant ID to collection name or ID. That mapping becomes part of the security boundary.</p> <p>Operational questions remain:</p> <ul> <li>How are collections created and deleted?</li> <li>What happens when a dormant tenant becomes active?</li> <li>How are per-tenant quotas enforced?</li> <li>How are index templates and mappings rolled out safely?</li> <li>How are tenant-level costs reported?</li> </ul> <h2 id="what-to-do-next">What to do next</h2> <p>For SaaS search workloads, revisit the tenancy model. Compare pooled, collection-per-tenant, and hybrid approaches using real tenant distribution, not an average tenant.</p> <p>A practical path is:</p> <ol> <li>Put high-volume tenants in dedicated collections.</li> <li>Keep small tenants pooled or grouped if isolation requirements allow it.</li> <li>Use collection-per-tenant where security, compliance, or noisy-neighbor risk justifies the boundary.</li> <li>Automate collection lifecycle and mapping changes from the start.</li> </ol> <p>The takeaway is that OpenSearch Serverless is making stronger isolation less expensive. That does not remove design work, but it gives builders more room to choose isolation for good reasons instead of avoiding it because of minimum compute cost.</p>