Amazon OpenSearch Serverless: Who Is It Actually For?

Amazon OpenSearch Serverless went generally available on January 25th, after a preview that started at re:Invent. The pitch is the one you’d expect from anything with serverless in the name, which is that you stop thinking about instance types, shard counts, and scaling, and the service works that out while you get on with something else.

I’ve spent a while with it now and I think it’s genuinely good at a specific job. I also think a lot of people are going to reach for it, look at the first bill, and be surprised. So this is an attempt at the honest version of who should be using it, which requires talking about the billing model first because everything else follows from there.

OCUs, and how billing really works

Capacity is measured in OpenSearch Compute Units. One OCU is 6 GB of RAM with the corresponding vCPU, 120 GB of GP3 storage for fast access to hot data, and the data transfer to S3 where your data actually lives. Indexing and search scale separately, so you’re billed for OCUs on each side independently.

That separation is the genuinely clever part of the design. A log analytics workload that writes constantly and gets queried twice a day has completely different needs on each side, and on a traditional cluster you size the nodes for whichever one is worse and eat the waste on the other. Here the two scale on their own, and at GA the ceiling went up to 50 OCUs each for indexing and query.

Data sits in S3 rather than on the nodes, which is what makes the compute layer disposable enough to scale like this. It also means the storage and compute bills are genuinely separate, so retaining more data doesn’t force you into bigger instances the way it does on a domain.

Collections instead of clusters

You don’t create a cluster, you create a collection, and you pick a type when you do. Time series collections are for write-heavy log workloads, and search collections are for read-heavy application search. The type sets the defaults for how data is handled underneath, which is a reasonable abstraction because those two shapes really do want different behavior.

What you don’t get is a cluster to look at. There are no nodes, no shard allocation decisions, and no cluster health endpoint going yellow at three in the morning. Security also works differently, through separate encryption, network, and data access policies attached to the collection, rather than the fine-grained access control you’d configure inside a domain.

If your relationship with your current cluster consists mostly of resizing it and apologizing for it, the appeal here is obvious. You’re trading control for not having to care.

The floor nobody mentions

Here’s the part that catches people. When you create the first collection endpoint in an account, OpenSearch Serverless provisions four OCUs, being two for ingest with a primary and standby, and two for search with two copies for availability. Those four are the minimum and they run whether or not anything is happening.

At the US East rate of $0.24 per OCU-hour, four OCUs is roughly $700 a month before you index a single document. That number is the same whether the collection is serving a million queries a day or sitting empty in a development account.

For comparison, a small three node managed domain on m6g.large.search instances comes to somewhere around $280 a month plus storage. So the thing marketed as the option you reach for when you don’t want to think about capacity currently starts at roughly two and a half times what a modest cluster costs.

That is not a criticism of the service so much as a correction to the mental model. Serverless here does not mean scale to zero, and it does not mean cheap for small workloads. It means you don’t manage capacity, and there’s a standing charge for that privilege. Anyone whose intuition was shaped by Lambda is going to get this wrong the first time.

What you don’t get yet

At GA there are real gaps, and whether they matter depends entirely on what you were planning to do with it. Two of them are large enough to end the evaluation on their own.

Alerting and anomaly detection aren’t supported, which rules out a chunk of the operational monitoring use case that OpenSearch is often bought for. More significantly for the work I do, k-NN isn’t there either, so vector search is off the table. Given how much of the current interest in search is people wanting to put embeddings in an index, that one is going to redirect a lot of evaluations back to managed domains.

More broadly, not all OpenSearch plugins and advanced features are available, and you should assume the API surface is narrower than what you’re used to. If you have existing code talking to a cluster, that’s worth checking against the serverless documentation before you plan a migration rather than after.

Bursty versus steady

The economics come down to the shape of your load rather than its size. A big steady workload and a small spiky one point in opposite directions here, which is not the intuition most people bring to a serverless product.

Serverless does well with workloads that are genuinely unpredictable or spiky, where the alternative is provisioning for the peak and paying for it all month. It does well when you have many small workloads and the operational cost of running a cluster for each one is the real expense. And it does well when nobody on the team wants to own shard strategy, which is a legitimate engineering decision and not an admission of anything.

It does badly on steady, predictable load, because that’s precisely the case where sizing a cluster is easy and the standing OCU charge buys you nothing. It does badly on small workloads, where the floor dominates. And it does badly when you need the features it doesn’t have yet, which is not a subtle failure mode.

When a managed domain still wins

Most of the time, honestly, at least for now. That will change, and I’d expect it to change fairly quickly, but it’s where things stand a couple of months after GA.

If your traffic is predictable, if you already know how to size a cluster, if you need k-NN or alerting, if you want reserved instance pricing, or if you’re small enough that $700 a month is a real number, a managed domain is still the better answer. None of that is likely to stay true forever. The floor will come down, the feature gaps will close, and the calculus in a year probably looks different from the calculus today.

What I’d actually do right now is take your last month of cluster metrics and look at the ratio between peak and median utilization. If that ratio is close to one, you have a steady workload and serverless is solving a problem you don’t have. If it’s four or five, you’re provisioning for a peak you rarely hit, and the standing charge starts looking reasonable against all the capacity you’re currently paying to keep idle.

I’d also like to hear the other side of this. If you went with serverless and it worked out more cost efficient than the cluster it replaced, tell me about it, because I’m more interested in the shape of the workload that made it win than in the final number. The cases I’ve reasoned through here are the obvious ones, and the genuinely interesting version is probably something I haven’t thought of yet.

If you’re weighing this for a real workload and want help reading your own numbers, please reach out.