Benchmarking ClusterNest Standard against Amazon OpenSearch Service

We ran OpenSearch Benchmark against a three-node ClusterNest Standard cluster and the matching Amazon OpenSearch Service configuration, from a test machine inside AWS’s own region. We measured bulk indexing, queries and both together, from a single client up to 64 in parallel, and priced each cluster at its list price.

Clusters and pricing

We picked the AWS configuration that matches our Standard tier on paper: the same vCPU and memory per node, three nodes, the same OpenSearch version.

	ClusterNest Standard	Amazon OpenSearch Service
Data nodes	3, each 2 vCPU, 16 GiB	3 × r6g.large.search, each 2 vCPU, 16 GiB
Storage	250 GB per node	250 GB gp3 per node
OpenSearch	3.7.0	3.7
Index layout	3 primaries, 1 replica	3 primaries, 1 replica
Monthly price	$225	$551.28, excluding coordinator nodes and network traffic

OpenSearch 3.7 is the newest version Amazon OpenSearch Service offers, so we ran ClusterNest on 3.7.0 to match.

The AWS price is the on-demand list price in Europe (Frankfurt), checked on 15 October 2026: $0.202 an hour per r6g.large.search node for 730 hours, plus $0.1452 per GB-month for 250 GB of gp3 on each node. The cluster we tested ran 100 GB volumes, since the data never came close to filling them, and gp3 gives volumes of both sizes the same baseline IOPS and throughput. We also left out the three dedicated cluster manager nodes AWS recommends for production, which would add to the AWS bill. Every choice about the AWS side went toward the cheaper configuration.

Test machine placement

The test machine was an EC2 instance in eu-central-1, the same region as the AWS cluster: a c6i.large for the fixed-rate run and a c6i.2xlarge for the parallel sweeps, which never went above 43% CPU. That is where an AWS customer’s own applications would sit, and it gives AWS the shortest possible path.

ClusterNest’s endpoint is outside AWS, and every request to it also passes through a CDN and WAF layer before it reaches the cluster. From the same machine, on a connection that was already open, a _cluster/health request answered by the receiving node came back in:

None of the results that follow correct for it.

Workload

We used OpenSearch Benchmark 2.4.0 and its http_logs workload, web server logs from the 1998 World Cup site, trimmed to its first three daily files: 25,460,091 documents, about 3.4 GB of JSON. The queries are the ones the workload ships with: a term lookup for one request line, GET / HTTP/1.0, a range over timestamps, and hourly_agg, a date histogram over the whole set.

Every number here comes from OpenSearch Benchmark’s own report. Both clusters finished every run with a 0% error rate.

Fixed-rate query schedule

The http_logs schedule sends each query from a single client at a fixed rate, 50 a second for term, and reports the latency.

On that schedule a single ClusterNest client spent about 110 ms per request against AWS’s 30, so it could send only about seven a second and fell short of the target rate on term, both status-code range queries and scroll.

Query throughput by client count

So we took the rate limit off and swept the number of clients: 1, 4, 8, 16, 32 and 64, each running the same query back to back for 45 seconds after a 10-second warmup. We turned off the shard request cache first. Without that, every repeat of hourly_agg after the first is answered from cache, and the test measures the cache.

Query	Clients	Operations per second, higher is better		p90 latency (ms), lower is better
		AWS	ClusterNest	AWS	ClusterNest
term	1	35.5	9.9	30	109
term	16	219	190	107	106
term	64	278	669	318	137
range	1	40.2	10.3	26	127
range	16	188	190	100	121
range	64	250	687	362	132
hourly_agg	1	21.9	9.6	48	134
hourly_agg	16	68.6	133	294	153
hourly_agg	64	67.5	172	1,155	416

AWS runs out of room first. hourly_agg stops gaining at about 68 operations a second from 16 clients on, and from then on every extra client only adds queueing. term and range still creep upward at 64 clients, but their latency grows faster than their throughput does.

ClusterNest’s latency barely moves.

Its 110 ms is a fixed cost per request, not a sign of a busy cluster, so more clients add throughput almost one for one. At 64 clients ClusterNest served 669 term queries a second with a p90 of 137 ms. AWS served 278 at 318 ms. It had not hit a ceiling at 64; we stopped there.

Bulk indexing throughput by client count

Bulk indexing shows the same shape, more sharply. We sent 5,000-document bulk requests from 1 to 32 parallel clients, 90 seconds per step after a 20-second warmup, into fresh indices.

Bulk clients	Documents per second, higher is better		p90 latency (ms), lower is better
	AWS	ClusterNest	AWS	ClusterNest
1	27,634	6,905	161	701
4	58,565	40,664	443	527
8	58,206	77,409	903	601
16	63,581	91,808	1,342	990
32	60,226	131,301	3,401	1,733

One bulk request of 5,000 documents, about 670 KB, took around 620 ms to reach ClusterNest and complete, against 134 ms for AWS. A shipper that keeps a single request in flight gets about 7,000 documents a second. Four in flight gets 40,000, and 32 get 131,000, more than twice the most we could push into the AWS cluster with any number of clients.

Queries during bulk indexing

Log clusters rarely get to choose between reading and writing, so we ran the query sweep a second time with a background feed of 10,000 documents a second, about a sixth of what the AWS cluster could absorb on its own.

AWS lost 14 to 25% of its peak query rate to the writes. ClusterNest lost 3 to 25% and kept the larger lead at every client count above 16. Both held the feed at 10,000 documents a second for most of the run. The exceptions were the heaviest steps: AWS slipped to 7,600 at 64 term clients, and ClusterNest to 6,200 at 64 hourly_agg clients.

Throughput per dollar

Dividing the highest rate each cluster reached in the sweeps by its monthly price gives the throughput each $100 a month buys. The AWS price is the lowest that configuration can cost, before data transfer and coordinator nodes, so the AWS bars are the most a dollar could buy there.

These are the highest rates each cluster reached, not its ceiling. AWS had stopped gaining on bulk indexing and hourly_agg. ClusterNest was still climbing on every measure when the sweeps ended.

Limitations

• A strictly sequential client pays the per-request floor. A script that sends one query, waits for the answer and then sends the next sees about 110 ms per request on ClusterNest against 30 ms on AWS, from inside AWS’s region.
• One region, one day. The test machine sat in Frankfurt, next to AWS. A machine in another region, or in your own data centre, would close some or all of the 12 ms gap.
• Repeat runs of heavy aggregations moved more on ClusterNest. Over two passes of the stock schedule, the p90 of hourly_agg_with_filter went from 221 ms to 576 ms on ClusterNest and from 383 ms to 389 ms on AWS. The parallel sweeps ran once each.
• Shortened schedules. Fixed-rate queries ran 20 measured iterations rather than the workload’s 100, and each sweep step ran 45 seconds. Percentiles beyond p90 are noisy at that length, so we do not quote them.
• No dedicated cluster managers on AWS. Adding them, as AWS recommends, would raise the AWS price and might help its coordination time.

Reproducing the test

Everything here runs on open-source tools: OpenSearch Benchmark 2.4.0 from its Docker image, the http_logs workload trimmed to logs-181998, logs-191998 and logs-201998, three primaries and one replica per index, 5,000-document bulk requests. The sweeps are three custom test procedures in that workload, and we will send them to anyone who asks.

Run it from where your applications run. The result that counts is the one from your own network, with your own concurrency.

ClusterNest Standard

A three-node ClusterNest Standard cluster is $225 a month at a flat per-node price. Ingest isn’t metered, queries aren’t counted, and Dashboards, coordinator nodes and support are included, so 669 queries a second cost the same as one. The pricing page sets it against AWS, Datadog and New Relic for a full logging workload.

If you are weighing it against Amazon OpenSearch Service for a workload of your own, write to [email protected]. We are happy to run your numbers with you.