The next generation of Amazon OpenSearch Serverless is now generally available
NextGen OpenSearch Serverless scales 20x faster, hits true zero when idle, and cuts costs up to 60% — built for unpredictable agentic AI workloads.
View original announcement →Visual Summary
graph TD
A{{OpenSearch Serverless NextGen}}:::announced
B([Scale-to-Zero]):::feature
C([20x Faster Autoscaling]):::feature
D(Shared Storage Layer):::storage
E((AI Agents)):::external
F(Vercel Integration):::compute
G(Kiro Integration):::compute
H([OpenSearch Agent Skills]):::feature
I((Developers)):::external
E ==>|"bursty queries"| A
A -->|"decoupled compute"| D
A -->|"provisions in seconds"| C
A -->|"idle periods"| B
I -->|"natural language"| F
I -->|"provisions"| G
F -->|"creates collections"| A
G -->|"creates collections"| A
H -.->|"Claude Code, Cursor"| A
classDef announced fill:#ff9900,stroke:#ec7211,color:#fff,font-weight:bold
classDef compute fill:#e3f2fd,stroke:#1565c0,color:#1565c0
classDef storage fill:#e8f5e9,stroke:#2e7d32,color:#2e7d32
classDef feature fill:#fff3e0,stroke:#e65100,color:#e65100
classDef external fill:#f5f5f5,stroke:#616161,color:#616161
What's New
AWS has announced the general availability of the next generation of Amazon OpenSearch Serverless, a fully managed search and vector engine rebuilt from the ground up for agentic AI workloads. The new architecture introduces complete decoupling of compute and storage, enabling 20x faster autoscaling, scale-to-zero pricing, and up to 60% cost savings compared to provisioning clusters for peak load. The launch also includes native integrations with AI development platforms Vercel and Kiro, as well as OpenSearch Agent Skills support for coding environments like Claude Code, Cursor, and Codex.
How It Works
- Decoupled compute and storage: A new shared storage layer fully separates compute from storage, allowing each to scale independently. Compute can scale all the way to zero when idle, while data remains instantly accessible.
- NextGen collection groups: Collections are organized into collection groups that share capacity, managed via a new
create-collection-groupAPI with configurable min/max OCU limits for both indexing and search. - OpenSearch Compute Units (OCUs): Capacity is measured in OCUs representing CPU, memory, and I/O. The service provisions additional OCUs in seconds in response to incoming traffic, then scales back down just as quickly.
- Two collection types at GA: Search (full-text/BM25) and Vector Search (kNN/semantic) are the supported collection types; time series is not yet available in NextGen.
- Simplified endpoint model: Two resource-based endpoints are provided — a collection-level endpoint and a regional endpoint — simplifying multi-VPC and on-premises connectivity using standard VPC APIs without complex per-collection network policies.
- Express Create and Standard Create: The console offers a streamlined single-page creation flow; Express Create applies default security and network settings automatically, while Standard Create allows customization.
- Vercel Marketplace integration: Developers can provision OpenSearch collections directly from the Vercel dashboard with automatic environment variable injection and OIDC-based authentication (no static AWS keys required).
- OpenSearch Agent Skills: A GitHub-hosted collection of agent skills (
opensearch-project/opensearch-agent-skills) installable vianpx skills, enabling AI coding agents in Claude Code, Cursor, Kiro, and Codex to build and query OpenSearch infrastructure using natural language.
Why It's Important
- Agentic AI workloads are inherently bursty: AI agents trigger unpredictable bursts of vector queries during multi-step reasoning tasks, then go completely idle — a pattern that traditional always-on clusters handle poorly and expensively. NextGen is architected specifically for this pattern.
- Dramatic cost reduction: Scale-to-zero eliminates idle compute costs entirely, and pay-per-usage pricing delivers up to 60% savings versus provisioning clusters for peak capacity, making it viable to run many low-traffic or experimental search workloads without waste.
- Faster time to production: Resources provision in seconds (vs. minutes for Classic), and native integrations with Vercel and Kiro allow developers to go from idea to a production-ready search backend in minutes without touching infrastructure.
- Simplified multi-tenant architectures: Collection groups with shared capacity allow SaaS builders to serve many tenants efficiently — high-usage tenants scale up while idle tenants consume zero compute, eliminating the overprovisioning tax.
- Developer experience as a first-class concern: Integration with AI coding assistants means search infrastructure can be provisioned and queried via natural language within the developer's existing workflow, lowering the barrier for teams without deep OpenSearch expertise.
How It's Different
- 20x faster autoscaling vs. Classic: The previous generation reacted to load after workers were already under pressure; NextGen provisions OCUs proactively in seconds, maintaining consistent performance during traffic surges.
- True scale-to-zero vs. minimum capacity floor: Classic collections maintained a minimum baseline of active OCUs even when idle, incurring continuous costs. NextGen scales all the way to zero with no idle compute charges.
- Shared storage layer vs. per-collection storage: Classic tightly coupled compute and storage per collection. NextGen's shared storage layer allows compute to be released and re-attached independently, enabling faster cold starts and lower costs.
- Simplified networking vs. per-collection VPC policies: Classic required configuring network and security policies individually for each collection. NextGen's regional endpoint and collection-level endpoint model consolidates connectivity, making multi-VPC and on-premises access straightforward.
- Native AI platform integrations vs. manual SDK setup: Classic had no first-party integrations with AI development platforms. NextGen ships with Vercel Marketplace support, Kiro Power, and OpenSearch Agent Skills out of the box.
- Collection groups for capacity sharing vs. isolated collections: NextGen introduces collection groups as a new resource abstraction that pools OCU capacity across multiple collections, enabling more efficient utilization at scale.
When to Prefer It
- Agentic AI and RAG applications: When building retrieval-augmented generation pipelines or multi-step AI agents that generate unpredictable, bursty vector query traffic and need instant scale-up with zero idle cost.
- Development and staging environments: When you need a full-fidelity search/vector backend that costs nothing when not in use, making it ideal for CI/CD pipelines, prototyping, and non-production environments.
- Multi-tenant SaaS platforms: When serving many tenants with highly variable activity patterns — NextGen's shared capacity model ensures high-usage tenants get resources while idle tenants incur no compute costs.
- Teams using Vercel or Kiro: When your frontend or AI application is already deployed on Vercel, or you are using Kiro as your AI IDE, and you want seamless, in-dashboard provisioning without switching contexts.
- Workloads with flash-sale or event-driven traffic patterns: E-commerce, media, or financial services applications that experience sudden 10x+ traffic spikes and need infrastructure that responds in seconds rather than minutes.
- Greenfield AI projects with uncertain scale: When you don't yet know your traffic profile and want to avoid over-provisioning; pay-per-usage means you only pay for what agents actually consume.
- Avoid NextGen when: You require time series collection types (not yet supported in NextGen), or you have existing Classic collections with configurations that are not yet migrated — Classic remains available and can be selected explicitly.
Availability
- GA status: Generally available as of May 28, 2026; NextGen is now the default when creating a new collection via the AWS Console or by specifying
--generation NEXTGENin the CLI. - Regions: Available in all commercial AWS regions where Amazon OpenSearch Serverless is currently supported (covering US, Europe, Asia Pacific, Africa, Middle East, and South America regions as listed in the service endpoints documentation).
- Pricing model: Pay-per-usage based on OpenSearch Compute Units (OCUs) for compute and separate storage charges; scale-to-zero means no compute charges when idle; covered by Database Savings Plans for additional savings.
- Collection types supported at GA: Search (full-text/BM25) and Vector Search (kNN/semantic); time series collections are not available in NextGen at launch.
- Classic collections: Continue to be supported; existing Classic collections are unaffected and can still be created by specifying
--generation CLASSICor choosing "Switch to Classic" in the console. - Vercel integration: Available via the Vercel Marketplace; new AWS accounts created through Vercel receive $100 USD in credits to trial the service.
- OpenSearch Agent Skills: Available as an open-source package on GitHub (
opensearch-project/opensearch-agent-skills), installable vianpx skillsand compatible with Claude Code, Cursor, Kiro, and any agent supporting the Agent Skills standard.
Related Resources
- https://vercel.com/changelog/amazon-opensearch-serverless-is-now-available-in-the-vercel-marketplace
- https://kiro.dev/launch/powers/add/?name=opensearch-launchpad
- https://github.com/opensearch-project/opensearch-agent-skills
- https://docs.aws.amazon.com/general/latest/gr/opensearch-service.html
- https://aws.amazon.com/opensearch-service/pricing/
- https://aws.amazon.com/opensearch-service/features/serverless/
- https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-create.html
- https://aws.amazon.com/blogs/aws/introducing-the-next-generation-of-amazon-opensearch-serverless-for-building-your-agentic-ai-applications
- https://aws.amazon.com/blogs/big-data/the-next-generation-of-amazon-opensearch-serverless-built-from-the-ground-up-for-agents/
