OpenSearch Serverless had an annoying limitation: you had to pay for compute even when your application wasn't doing anything (which is decidedly not serverless). AWS managed the infrastructure and scaled it for you, but an idle collection still had a compute bill. For a search engine serving traffic all day, that might be fine. For an internal AI agent that runs a few tasks and then sits unused on nights and weekends, paying to keep its vector store ready can cost more than actually using the application.

AWS addressed this with OpenSearch Serverless NextGen, released on May 28, 2026. It can scale compute to zero, provision capacity in seconds, and autoscale up to 20 times faster than the previous architecture, now called Classic (which means “old, plz don't use” in AWS slang, in case you didn't know). AWS also says it costs up to 60% less than OpenSearch clusters provisioned for peak traffic. Let's get into how it works, how much it costs, and why I'd start every new OpenSearch Serverless workload with NextGen.

This article is sponsored by Inngest

Long-running agents need endurance.

They must endure waiting for users, and weather tool failures. They must take each new jump in model intelligence in stride.

Inngest makes long-running agents durable, observable and improvable over time. 

Check out their generous free tier and a sleek local dev server for testing your workflows.

Build for the long run with Inngest.

NextGen makes the compute workers stateless and gives them access to a distributed shared storage layer. That lets AWS release compute without removing your stored data, and add workers without first populating a local disk, just like it has been doing for S3 for over 2 decades (nope, not asking why didn't we get this sooner).

An OpenSearch Compute Unit, or OCU, is the unit AWS uses to measure compute capacity. Search and indexing have their own OCUs and scale separately. This is true for both Classic and NextGen.

In Classic mode, Classic workers use local storage to serve data, and while it also has durable managed storage, meaning you can turn off a worker without losing your database, the limitation is that its operating model keeps compute running and ties serving capacity more closely to data held locally.

With NextGen, new workers can access the shared storage and start processing requests much sooner. When demand disappears, AWS can release those workers while leaving the data in storage. That's what makes both faster scaling and scale-to-zero possible, and what allows AWS to recover the capacity when you release it and to stop billing you for it.

The architectural change is beneficial to you even if your app never reach zero capacity. Adding compute in seconds instead of waiting minutes for additional capacity lets your app respond faster to traffic increases, and lets you release capacity faster instead of keeping the cluster slightly overprovisioned to handle traffic spikes.

NextGen automatically scales search and indexing compute to zero after 10 minutes without requests to the relevant component across the collection group. That timeout isn't configurable, but you can set up minimum capacity so that the OpenSearch cluster never scales to zero in the first place.

Search and indexing capacity operate independently. You can keep indexing new documents while search compute is at zero, or keep serving queries while indexing compute is at zero.

When traffic returns, the component receiving the request starts again. AWS documents 10-30 seconds of latency on the first request while capacity is restored, which is frankly terrible for real-time traffic, but you can always set a minimum capacity above zero. Search and indexing can each have their own cold start, though it would be very rare for this to be an issue at all for indexing I guess.

Keep in mind that AWS queues requests while compute starts, but your application likely still has its own timeout settings. A request waiting inside OpenSearch can outlive the timeout in your client or the service calling it. Test the complete request path. And test it from the user's perspective, because an application timeout of 10 minutes will definitely wait the 10-30 seconds for OpenSearch's response, but a real user might just leave.

If your application (or users) can't tolerate that delay, you have two options:

NextGen's minimum values start at 0, then 2, 4, 8, and 16 OCUs, followed by multiples of 16. 1 OCU is not a valid setting, it's 2 or nada. Also remember that scale-to-zero only stops the compute charge. Your data remains stored, and you keep paying for storage. Which is generally what you want from a database.

Every NextGen collection belongs to a collection group. Groups were optional in Classic, but in NextGen they're an essential part of how you organize and manage capacity.

Collections in the same group share compute, and you configure minimum and maximum capacity at the group level, separately for search and indexing. Those settings apply to the collections sharing that group. This is useful when you have several small collections. For example, a SaaS application might give each tenant its own collection while letting compatible collections share capacity. You can also use different KMS keys for collections in the same group, so sharing compute doesn't require sharing an encryption key.

An important consequence of this is that an idle collection doesn't make the whole group idle. If another collection keeps receiving search requests, the group's search capacity remains active and won't suffer from a cold start.

NextGen also adds a regional endpoint for your AWS account, alongside individual collection endpoints. Your client can use one single hostname to talk to OpenSearch, and identify the target collection through a request header. That greatly simplifies connection management when an application accesses many collections. Moreover, both endpoint types support standard AWS PrivateLink with automatic private DNS, making private connections much easier than with Classic.

These changes are less eye-catching than scale-to-zero, but managing fewer endpoints and less networking configuration is still useful work you don't have to do.

Here's the comparison:

The main opportunity is reducing the number of OCU-hours you pay for. For the first Classic collection with redundancy enabled, the baseline is typically two OCUs: one for indexing and one for search. Classic's development and testing option can reduce that baseline by disabling redundant standby capacity. Collection type and data size can also affect capacity requirements.

NextGen lets eligible idle compute drop to zero. If your workload spends most of its time waiting for requests, that can make a large difference. If it's busy all day, scale-to-zero has little to save.

The following examples use a 730-hour month and assumed rates of $0.24 per OCU-hour and $0.024 per GB-month of storage. Use the current OpenSearch pricing for your region when estimating your own workload.

I'm only considering compute and storage for these examples. No data transfer, GPU-accelerated index construction, and other application costs.

Suppose an internal agent queries a vector store during the working day. It runs tasks in bursts, and nobody uses it overnight or on weekends.

Assume:

For this simplified calculation, we'll leave out the compute used during the 10-minute wait before scaling to zero. You should include it in a production estimate, especially if activity is split into many short sessions.

That's about $313 less per month, or roughly 75% lower in this simplified example.

The difference comes from the 1,306 OCU-hours Classic spends maintaining capacity during idle periods. The active work costs the same under these assumptions.

The pattern of those idle periods matters, too. One long quiet stretch gives the service time to scale down. Requests arriving every few minutes can keep it running, even if the total number of requests is small.

Now suppose you're running product search for an application with traffic throughout the day and night. Assume:

No savings from scale-to-zero, because nothing scales to zero.

NextGen's faster scaling may still help the service follow changes in demand. Its shared storage architecture may also change the capacity your particular workload needs. But this calculation doesn't assume either benefit.

I'd measure those improvements before using them to justify a migration. But if this was a new project, this is why I'd always default to NextGen. Even when it doesn't help, it doesn't hurt either.

AWS's 60% figure compares NextGen with OpenSearch Service clusters provisioned for peak capacity. It isn't a promise that every Classic collection becomes 60% cheaper, it's just a figure that marketing thought would sound impressive. As I've just shown you, real savings could be $0, or they could be even higher than 60%.

To understand how much (or how little) you could save, you need to know your own traffic patterns and baseline. Assume NextGen will save you something, or at worst $0. Don't assume the savings are worth a migration, run your own calculations first.

Also include GPU-accelerated vector index construction in your estimate. It's billed separately when used, and its importance depends on how much vector data you build or rebuild.

Database Savings Plans can also reduce eligible OpenSearch compute rates in exchange for a one-year usage commitment. Apply those discounts consistently when comparing options, and size the commitment around usage you expect to keep.

Agents that retrieve data in bursts are an obvious fit. An agent may issue many vector queries while completing a task, then stop until someone gives it another task. NextGen can release compute during those gaps.

The cold start still matters. An asynchronous research task can tolerate it more easily than an assistant expected to answer immediately. Still, even for an AI assistant I'd set a minimum capacity of 2 and let OpenSearch Serverless NextGen scale in seconds rather than have Classic take minutes to do so.

Development and testing environments are another strong fit. If a collection is used during working hours and sits untouched the rest of the week, the always-on baseline will dominate the bill. Scale-to-zero makes it much easier to keep the data available without continuously paying for compute.

Batch workloads also benefit when processing happens in defined windows. You can warm the collection before the job starts, run the work, and let it scale down afterward.

Multi-tenant applications can benefit from shared capacity and the regional endpoint, particularly when tenants have different activity patterns. I'd check the combined traffic of each group, though. A group containing tenants active around the clock may never reach zero.

For steady production traffic, I'd evaluate NextGen on scaling behavior, operational improvements, and measured cost. Scale-to-zero alone isn't a migration case.

And if you need time-series collections, keep the supported collection types in mind. NextGen launched with search and vector search; time-series collections weren't included. Check support before planning a move.

Moving an existing collection requires creating a new collection group and collection, then reindexing the data. It's a migration with a cutover.

AWS describes the migration as preserving queries and index mappings, with clients moving to the new endpoint. I'd still test the application's actual queries and response handling before switching production traffic.

The practical steps are:

For a small collection, that’s pretty straightforward. For a large collection with continuous writes and several applications using it, it can be significant work. Estimate the monthly savings and compare them with that effort. Saving a little on the AWS bill doesn't automatically justify spending days rebuilding a working deployment.

For a quick test, Express Create creates the collection group and required policies for you. Review those defaults though, since the documented configuration uses an AWS-owned encryption key, public network access, and a data access policy granting the creating IAM principal full access. Public network access still requires authorization, but those defaults may differ from what you need in production.

For a new search or vector workload on OpenSearch Serverless, NextGen would be my starting point. The ability to release idle compute is useful, and faster scaling and simpler endpoint management add value beyond the savings.

For an existing workload, here's my decision table:

The main improvement is that OpenSearch can now stop charging for compute your application has stopped using. That's particularly valuable for small applications, intermittent jobs, and agents with long gaps between tasks, so long as you can tolerate the cold starts. And by you I mean your users.

I'd start by looking at how often your collection is idle, how long those gaps last, and whether the next request can wait. Those three things will tell you much more than any article about the topic, including this one.

Also, remember that OpenSearch also has its regular, non-serverless option. That's not deprecated by any means, what NextGen effectively deprecates is the old OpenSearch Serverless mode (now called Classic). Going non-serverless is still a very valid choice.