OpenSearch Serverless

TL;DR: OpenSearch Serverless (late 2022) replaces node management with capacity that scales per OpenSearch Compute Unit (~6 GiB memory + compute) between a min and max you set — no node count, instance type, or shard config. Its economics come from charging near-nothing during quiet hours, so it wins on spiky, unpredictable, or dev/test workloads and loses to a Reserved-Instance-backed provisioned cluster on flat 24/7 production. Tuning moves up the stack — it doesn't disappear.

The numbers

• Provisioned reference: a 3-node m5.large.search cluster ≈ $350/mo, 24/7, idle or not.
• Serverless minimum baseline: ~2 OCUs for search collections, ~4 OCUs for time-series — tiny workloads aren't free, but real quiet periods still dominate.
• Flat-24/7 cross-over: ~12 OCUs constant ≈ 8,760 OCU-hours × ~$0.24 ≈ $2,100/mo, versus $1,400–$1,600/mo for a comparable Reserved-Instance cluster — provisioned wins on raw dollars there.
• Field examples: deploy/incident log spikes (3–4 OCU normal, 15–20 in a burst) saved 50–70%; business-hours e-commerce search saved 30–45%; multi-team dev/test saved 40–60% vs always-on dev clusters.

Do this

1. Set a sane min and max OCU cap — the cap keeps an indexing flood from running away with the bill.
2. Pick the right collection type — search (full-text) vs time-series (logs/metrics) have different OCU minimums and scaling; the wrong type quietly costs money.
3. Start with non-critical workloads — a dev collection or low-stakes log analytics before production search.
4. Watch OCU consumption in CloudWatch and wire billing alerts — indexing and querying drive OCUs differently; heavy indexing during spikes burns them fast.
5. Keep optimizing queries — serverless abstracts infrastructure, not bad aggregations, oversized indices, or wrong sharding.

Gotchas

• The minimum baseline is real — you pay for ~2 OCUs at idle per collection; still far cheaper than a full cluster 24/7 if you have any quiet hours.
• Less control — no JVM tuning, instance-type choice, or manual shard allocation.
• Feature gaps — cross-cluster search, some plugins, and snapshot management are limited or missing; check current docs before assuming parity.
• Cold-start latency — first queries after a deep scale-down warm up briefly.
• "Off-peak" may not be quiet — global time zones can keep a supposedly idle window busy; audit real traffic before migrating.

Skip this if

• It's a mission-critical 24/7 search app with consistently high load — a right-sized provisioned cluster with OpenSearch Reserved Instances usually wins on cost; choose serverless only if zero-maintenance HA is worth the premium.
• The workload is genuinely flat and predictable — you'd pay for elasticity you never use.
• Your bill is really about log volume and retention — pair CloudWatch Logs retention policies and CloudWatch Logs Infrequent Access to cut the observability bill from both ends.