AWS OpenSearch Serverless — When It Makes Sense and When to Avoid It

Figuring out OpenSearch Serverless when to use it versus sticking with provisioned clusters is one of those decisions that looks simple on the surface and absolutely is not. I’ve helped teams spin up both configurations across a range of workloads — from scrappy startup logging pipelines to enterprise search backends handling millions of queries per day — and the “just go serverless, it’s easier” advice gets people into trouble more often than AWS would probably like to admit. This article is a practical decision guide, not a feature tour. AWS docs cover what serverless does. This covers when it earns its place and when it’ll quietly burn your budget.

Serverless vs Provisioned — The Decision Matrix

Let’s establish the core difference first, because the naming causes confusion. OpenSearch Serverless is not a stripped-down version of OpenSearch Service. It’s a fundamentally different architecture — compute and storage are separated, there are no nodes to manage, and you don’t size anything upfront. Capacity scales automatically in units called OCUs (OpenSearch Compute Units). Provisioned OpenSearch Service means you pick instance types, count, and storage — and you pay for that capacity whether you use it or not.

That tradeoff is really the whole game. Here’s how I think about it:

• Unpredictable, spiky traffic — Serverless wins. If your workload looks like a heartbeat monitor during an earthquake, provisioned means you’re sizing for peaks and paying for valleys. Serverless scales to meet demand without manual intervention.
• Dev, test, and staging environments — Serverless wins, with caveats. You’re not running these 24/7 at load, so paying for idle provisioned nodes makes no sense. The cost floor on serverless is real, but it’s manageable at low utilization.
• Steady, predictable production traffic — Provisioned wins. Full stop. If your query volume is consistent, you can right-size instances, use Reserved Instances for up to 36% savings, and have predictable invoices. Serverless OCU pricing at steady-state is almost always more expensive.
• Cost optimization at scale — Provisioned wins again. I’ve seen teams move from serverless to provisioned and cut their monthly OpenSearch bill by 40 to 60 percent at moderate scale (say, 50+ GB of active index data with consistent query patterns).
• Index management complexity — This is where serverless surprises people. There are no Index State Management (ISM) policies in serverless. No fine-grained rollover automation. No hot-warm-cold tiering. If your use case depends on lifecycle management — and most logging use cases do — serverless removes tooling you’re probably counting on.

The honest version of the decision matrix: use serverless when you genuinely can’t predict load and operational simplicity has real dollar value for your team. Use provisioned when you have any kind of consistent workload or need the full OpenSearch feature surface.

Hidden Costs of Serverless

Probably should have opened with this section, honestly. Because the pricing model is where most people get burned.

OpenSearch Serverless charges in OCUs — OpenSearch Compute Units. As of 2024, one OCU costs $0.24 per hour in us-east-1. Here’s the part that stings: OCUs are billed separately for indexing and search, and there’s a minimum of 2 OCUs for each. That means even if you send zero traffic to a serverless collection, you’re paying for at least 2 indexing OCUs and 2 search OCUs.

Do the math on that minimum floor: 4 OCUs × $0.24 × 24 hours × 30 days = $691.20 per month at absolute zero traffic. Per collection. That number has ended more than a few “let’s just use serverless for everything” proposals I’ve sat in on.

Storage is billed separately on top of that — $0.024 per GB-month. At 500 GB of index data, that’s another $12/month, which is relatively minor. The OCU cost dominates at low-to-moderate scale.

Compare that to a provisioned setup: a single-node t3.medium.search instance runs about $0.068 per hour, or roughly $49/month. That’s obviously not production-grade, but a small r6g.large.search cluster with two nodes — adequate for many non-critical workloads — comes in around $340/month with comparable storage. The provisioned option costs less and gives you more operational control.

Where serverless pricing starts to make sense is when your indexing and query load is genuinely bursty and high-peak. If you’d otherwise need to provision for a peak that only occurs 10% of the time, serverless stops the waste. The math works when peak-to-average ratios are high. It doesn’t work when they’re not.

OCU Allocation Behavior

One thing worth knowing: AWS scales OCUs in whole units, and there’s some lag in scale-down. You won’t always see immediate cost reductions when traffic drops. The platform holds capacity for a period after a burst. This isn’t a dealbreaker, but it means your cost estimates based on average traffic are slightly optimistic compared to what you’ll actually see on the bill.

Performance Characteristics

Cold starts are real. Not catastrophic, but real. When a serverless collection has been idle — and “idle” can mean a period as short as a few minutes of no queries — the first request after that gap will be slower. I’ve measured cold start latency anywhere from 1 to 8 seconds depending on collection size and the complexity of the first query. For an API that a user is waiting on, that’s a problem. For a background analytics job that runs every hour, it probably isn’t.

Surprised by that range the first time I saw it in production. We had an internal reporting dashboard that ran a scheduled query every 30 minutes. The first query of each cycle was consistently hitting 4 to 6 seconds while the provisioned equivalent answered in under 200ms. That’s a meaningful gap.

Under sustained load, latency characteristics of serverless are actually reasonably competitive with provisioned — assuming you’ve scaled to enough OCUs. The architecture is built on S3-backed storage with compute separation, so there’s inherent read amplification compared to provisioned clusters where data lives on local NVMe storage attached to the nodes. For heavy aggregations on large datasets, this shows up as higher p99 latencies.

Throughput Limits

Serverless has hard service limits that provisioned doesn’t. By default, a single collection supports a maximum indexing throughput of 2 GB per minute and a maximum search concurrency that AWS manages but doesn’t fully document. You can request limit increases, but you’re operating in a managed ceiling. With provisioned, your throughput limits are essentially determined by your instance sizes and shard configuration — you have real control. For high-volume log ingestion (think 10+ GB per minute), serverless isn’t in the conversation.

Migration Path — Moving Between Models

This question comes up constantly: can you start on serverless and migrate to provisioned later? The short answer is yes, but it’s not automatic. There’s no AWS-native migration tool that moves data between serverless and provisioned OpenSearch. They are different services with different APIs and different index management models.

What migration actually looks like in practice:

1. Snapshot your serverless collection data to S3 using the OpenSearch snapshot API.
2. Restore from that snapshot into your provisioned domain.
3. Verify index compatibility — serverless collections use OpenSearch 2.x, and provisioned domains can run various versions. If you’re restoring into a version mismatch, some index features may not translate cleanly.
4. Update your application configuration to point at the new provisioned endpoint.
5. Run both in parallel for a validation period before decommissioning serverless.

The snapshot-and-restore approach works. It’s tedious, not dangerous. The main gotcha is index mappings and any custom analysis configurations — those need to be recreated on the provisioned side before restoring data. I’d budget a full engineering sprint for a non-trivial migration, not an afternoon.

Going the other direction — provisioned to serverless — is essentially the same process. No magic button. Same snapshot mechanism, same validation overhead.

One thing to check before committing to serverless early: if your use case involves ISM policies, rollup jobs, or transforms, those features don’t exist in serverless. When you migrate to provisioned, you’ll be rebuilding that operational logic from scratch. Design with that in mind if migration is a likely future state.

When to Avoid Serverless Entirely

Let me be direct here, because the AWS documentation won’t be.

High-volume log ingestion. If you’re running a centralized logging stack for a production environment — shipping application logs, VPC flow logs, CloudTrail events — serverless will either hit throughput limits or cost you significantly more than provisioned at scale. The teams doing this well are running OpenSearch Service with dedicated master nodes, UltraWarm for older data, and ISM policies automating the lifecycle. Serverless removes all of that tooling.

Steady production search. E-commerce product search, document retrieval, any customer-facing search feature with predictable traffic patterns — go provisioned. Size your cluster, tune your shards, use Reserved Instances if the workload is long-term. Serverless saves you operational overhead you’re probably willing to accept in exchange for predictable costs and better performance guarantees.

Cost-sensitive workloads at any reasonable scale. Once you’re past roughly 100 GB of active index data with consistent query patterns, the economics of serverless rarely win. Run the numbers for your specific workload. The $691/month floor per collection is the baseline — everything above that depends on your OCU consumption.

Workloads requiring advanced OpenSearch features. No ISM. No fine-grained rollover. No transforms. Limited security customization compared to provisioned (no resource-based access policies at the index level in the same way). If your use case depends on these, serverless isn’t a fit today. AWS adds features over time, but as of now these gaps are real.

Latency-sensitive applications. Cold starts and the S3-backed storage architecture make serverless a poor choice for anything where p99 latency matters and traffic isn’t constant enough to keep compute warm. Real-time autocomplete, session-sensitive search, anything where a user is waiting — provisioned with appropriately sized instances will serve you better.

Burned by the minimum OCU cost on a client project once — we had four serverless collections set up for different environments and didn’t realize until the first invoice came in at $2,764 for collections that were barely used. Moved three of them to a single shared provisioned domain within the week. Lesson learned, and a real argument for doing the math before you deploy.

OpenSearch Serverless is a genuinely useful service for the right workloads. It removes real operational overhead, scales automatically, and makes sense for teams that prioritize simplicity and have genuinely unpredictable traffic. It’s not a default choice. Know your traffic patterns, run the cost comparison against provisioned options, and make the decision deliberately.