Serverless search: when Elastic Cloud Serverless or OpenSearch Serverless actually costs less

Both vendors now sell a tier with no nodes in it. Elastic Cloud Serverless bills Virtual Compute Units (VCUs) plus retained data; Amazon OpenSearch Serverless bills OpenSearch Compute Units (OCUs) plus S3 storage. In both, indexing and search compute are separate pools sitting in front of object storage, and you no longer choose instance types, shard counts, or replica counts.

This is not a packaging change. It removes most of the levers we normally pull in a cluster and cost review, and it replaces them with one lever: how much compute your workload provokes. Sometimes that is cheaper. Often, for a steady-state logging cluster, it is not.

The architecture, briefly

The common design in both products:

• Segments live in object storage. A written segment is uploaded; it is no longer a file whose only durable copy sits on an instance's disk with N replicas.
• Replicas stop being a storage multiplier. You are not paying 2x or 3x for durability. Object storage handles that, and you pay for one logical copy of retained data.
• Indexing and search scale independently. An ingest spike adds indexing compute without adding query capacity, and vice versa.
• Caches decide your latency. Because the durable copy is remote, query latency depends on whether the working set is in local cache. Cold reads pull from object storage and are slower — sometimes by an order of magnitude.

The last point is the one to hold onto. Serverless does not make your data faster to search; it makes the storage cheap and the cache the thing that matters.

What the units actually measure

Elastic Cloud Serverless prices per VCU-hour, in separate buckets for ingest, search, and (for the Elasticsearch project type) ML, plus a per-GB-month charge on retained data. Ingest VCUs track the work of indexing and the ingest pipeline; search VCUs track query concurrency and how much data has to be brought into cache to answer. There are also boost/performance settings that change how much cache you get per unit of search, which is a real price dial on latency-sensitive search projects.

Amazon OpenSearch Serverless prices per OCU-hour with separate indexing and search OCUs, plus S3 storage. The detail that decides most budgets is the floor: a collection provisions a minimum number of OCUs and holds them. For redundancy-enabled collections that minimum has historically been 2 indexing + 2 search OCUs; a dev-grade collection without redundancy halves it. Whatever the current numbers, read them before you model, because the floor is charged whether you send traffic or not.

That floor is why the first serverless bill surprises people in both directions. A tiny collection that would have run on two small nodes now pays the platform's minimum. A bursty workload that used to require provisioning for peak now pays close to its average.

Where serverless wins

Four workload shapes where we have seen it price out well:

1. Spiky ingest. Traffic that is 10x at 09:00 and idle overnight. Provisioned clusters are sized for the peak all day; serverless is not.
2. Large retention, small working set. Compliance or audit data where 95% of the volume is queried a few times a quarter. You pay object-storage rates for the bulk and compute only for the occasional investigation.
3. Many small tenants. Dozens of logical indices that individually cannot justify a node, where you were already over-provisioned just to have a quorum.
4. No operations budget. Small teams for whom "nobody has to do the 8.x-to-9.x upgrade" is worth real money. Version upgrades, node replacement, and rebalancing stop being your calendar items.

Where it does not

• Steady, high-volume logging. A pipeline doing a flat 500 GB/day is exactly what tiered, provisioned clusters with logsdb index mode, ILM, and frozen searchable snapshots are good at. Compute is busy constantly, so you get no burst discount, and you have already solved storage cost yourself.
• Latency-sensitive search with a large index. p99 now depends on cache residency you do not directly control. You can pay for more cache, but you cannot pin an index to a node or force-merge your way out of a problem.
• Workloads that need the knobs. No custom shard counts, no node roles or allocation awareness, no force merge scheduling, no custom plugins, and a constrained settings surface. If your stability came from careful shard strategy and allocation filtering, you are handing that expertise back.
• Anything that needs the excluded features. Feature parity moves, so check the current docs rather than a blog post — but both products exclude pieces of the classic stack, and "we will just do it in an ingest pipeline" is not always available.

How to evaluate it without guessing

Measure first. Four numbers make the decision most of the time.

1. Ingest shape. Bytes per hour for two weeks, not a daily average. Compute the peak-to-mean ratio. Below roughly 2:1, serverless's main advantage is missing; above 5:1, it is probably the cheapest thing you can buy.
2. Working-set size. From your query logs, what fraction of retained data is touched in 24 hours? If a 40 TB index has a 300 GB hot working set, the cache story is plausible. If analysts routinely scan a year, it is not.
3. Current true cost. Instances plus EBS plus snapshots plus the engineer-hours you actually spend on upgrades and cluster babysitting. Compare like with like; serverless absorbs some of that labor.
4. A real load test. Both platforms are pay-as-you-go, which means you can settle this empirically. Replay a day of production ingest and a day of production queries into a trial project or collection, then read the metered units. A week of that beats a quarter of spreadsheet argument.

A useful intermediate step: move one workload, not the platform. Audit logs, a low-traffic internal search app, or a single team's non-critical logs will tell you how the units meter against your traffic without betting the observability stack on it.

The migration details people miss

If you go ahead, treat it as a platform migration, because it is one:

• Index settings get rejected, not ignored. Templates carrying number_of_shards, number_of_replicas, allocation filters, or custom merge policy need cleaning before they will apply. Inventory your templates first.
• Client and API behavior. OpenSearch Serverless collections do not expose the full cluster API surface; SigV4 auth and per-collection endpoints change client config. Things like _cluster/settings, node stats, and some monitoring endpoints simply are not there.
• Your monitoring changes shape. Dashboards built on node-level metrics — heap, disk watermarks, per-node hot threads — lose their inputs. You now watch metered units, rejection and throttling signals, and latency. Rebuild the alerting before cutover, or you will be flying blind on day one.
• Exit path. Keep snapshots or a reindex path you have tested in the other direction. Serverless-to-provisioned is a real project; know the shape of it before you need it.

The short version

Serverless replaces a dozen cost levers with one, and moves your durable copy to object storage. If your workload is bursty or your retention dwarfs your working set, that trade is often a straight win and removes upgrade work you were doing by hand. If you run steady high-volume logging or latency-sensitive search over a large index, the provisioned cluster with good shard strategy, ILM, and data tiers is still the cheaper machine — and you keep the knobs that let you fix it at 2 a.m.

It depends on the shape of your traffic, and the shape is measurable. Measure it before you migrate.