OpenSearch Serverless pricing: OCU floor 2026

Amazon OpenSearch Serverless does not have one minimum cost, it has two, and which one you pay is decided by a collection type you choose before you index anything. A Classic collection bills "a minimum of 2 OCUs" for the first collection in an account, which is $350.40 a month at the $0.24 OCU-hour rate in AWS's own example. A NextGen collection scales to zero after ten idle minutes and bills nothing. The catch: time series collections, the log analytics case most people are pricing this service for, are not offered as NextGen at all.

How much does Amazon OpenSearch Serverless cost per OCU-hour?

$0.24 per OCU-hour in US East (N. Virginia), which is the rate AWS uses in its own worked example. The Serverless rate tables on the OpenSearch Service pricing page are rendered in JavaScript and are not in the page text, but Pricing Example 6 states the rate in prose twice: "Uses Indexing OCUs: 1 OCU-hours * 730 hours per month * $0.24 per OCU-hours = $176 per month". Check the pricing page for your own Region and collection generation before you budget on it.

That example also sets the month convention used here: 730 hours, not 720. One OCU held for a 730-hour month is $175.20. AWS prints $176, the first of several roundings on that page that all go the same way.

What is an OCU in OpenSearch Serverless, and what does one include?

An OpenSearch Compute Unit is a fixed bundle of memory and CPU. The capacity limits documentation defines it as "a combination of 6 GiB of memory and corresponding virtual CPU (vCPU), as well as data transfer to the shared storage and Amazon S3". The pricing page's NextGen section says "One OCU comprises approximately 6 GB of RAM and corresponding vCPU", and its Classic section adds more: "The number of OCUs corresponds directly to the CPU, memory, Amazon EBS storage, and I/O resources required to index data or run queries."

Indexing and search are metered separately and scale independently, which is what sets the floor: an account doing nothing still needs one of each before it can do either. Classic collections carry storage inside the unit too, since "For Classic collections, each OCU includes hot ephemeral storage of 120 GiB", against a ceiling where "OpenSearch Serverless supports up to 10 TiB of managed hot storage per collection."

Which OpenSearch Serverless collections can scale to zero OCUs?

Only NextGen collections inside a collection group. The scale to zero documentation is explicit: "Scale to zero is only available for NextGen collections that are part of a collection group." When it applies, "When no collection in the group has incoming requests for 10 minutes, search and indexing workers scale down to zero OCU and billing stops." Those ten minutes are fixed: "This idle period is not configurable."

Waking up is not instant. AWS says to "Expect 10–30 seconds of latency on the first request to each component while capacity is restored", and search and indexing wake separately. That is the trade priced in what a Lambda cold start costs.

Now the sentence that decides most bills. The OpenSearch Serverless overview notes that "Time series collections are only available for Classic collections. NextGen collections currently support Search and Vector search types only." Time series is AWS's own name for the log analytics segment, so the type you would pick for logs, traces and security events is the one type that cannot scale to zero. If log search is what you are costing, compare it against CloudWatch Logs ingestion and storage costs and querying the same logs in Athena: neither charges you for an idle engine.

What is the minimum monthly cost of an idle OpenSearch Serverless collection?

$350.40 a month for a Classic collection, on AWS's own numbers. The pricing page states the floor directly: "You will be billed at least for a minimum of 2 OCUs (1 OCU [0.5 x 2] indexing includes primary and standby, and 1 OCU [0.5 x 2] search includes one replica for HA) for the first collection in an account." Two OCUs at $0.24 for 730 hours is $350.40, or $4,204.80 a year, before a single document is indexed.

There is a documented way to halve it, and only one: "Additionally, OpenSearch Serverless also offers a dev-test option, where you can launch a collection without redundant standby nodes. This deployment mode further cuts the cost in half, with 0.5 OCU for indexing and 0.5 OCU for search." That is $175.20 a month, and it is a Classic-only control. The collection group creation guide confirms the console offers it as a Deployment type "option that is not available for NextGen collection groups".

The NextGen floor is zero, but the step above zero is large. The capacity documentation says "The minimum OCU capacity for a collection group is 0 OCUs for indexing and 0 OCUs for search", and, separately, "You can configure the OCU count to be 2, 4, 8, 16, or any multiple of 16 up to the maximum allowed capacity." The minimum is set per dimension, so read together those two sentences put the smallest non-zero minimum at 2 indexing plus 2 search. That is 4 OCUs, $700.80 a month: exactly twice the Classic floor you were trying to escape. AWS never states that number, and it is the price of opting out, since the guidance for opting out is to "make sure they are part of a collection group with minimum capacity set to a non-zero value."

Two AWS pages disagree about whether redundancy is still something you pay for. The capacity documentation says "OpenSearch Serverless offers high availability by default without requiring standby nodes or redundancy configuration." The pricing page, fetched the same day, itemises a standby and a replica inside the 2-OCU floor, and still sells dev-test as a way to drop them. It also hedges: "However, the minimum varies based on your data size and collections type in use." The floor is a starting point, not a ceiling.

When does a provisioned OpenSearch Service domain cost less than Serverless?

Immediately, at small scale. The cheapest instance rate stated in prose on the pricing page is an "m7g.medium.search instance priced at $0.068/hr (on-demand) in US East (N. Virginia)". Over 730 hours that is $49.64. The same page prices gp3 at "EBS General Purpose SSD (gp3) = $0.122 per GB per month".

Put the other way round: the Classic minimum bill buys 7.06 m7g.medium.search instances running every hour of the month, or 2.45 of the instances Pricing Example 8 lists at "r8g.large.search = $0.196" per hour. Three nodes is a real cluster; the Serverless floor is an empty collection. Serverless wins on operations, not on the first few hundred dollars.

One limitation belongs in that decision. The overview's own list says "There's currently no way to automatically migrate your data from a managed OpenSearch Service domain to a serverless collection. You must reindex your data from a domain to a collection." The domain versus collection comparison sets out the rest of what changes, including encryption at rest, which that table lists as optional for domains and required for collections. Picking the wrong side is not a setting you flip later.

What does OpenSearch Serverless managed storage cost per GB-month?

The pricing page states two different rates in two places. Its Serverless example bills 1,440 GB of ingested data at a rate "which incurs a charge of $0.02 per GB per month = $29 per month". Every domain example on the same page uses a different figure, printed in its own cost table as "Managed Storage for data nodes = $0.024 per GB per month". We are not going to tell you which one applies to your collection: read the Managed Storage row of the Serverless table on the pricing page in your Region, because that row is one of the JavaScript-rendered values.

At either rate, storage is not what makes this service expensive. At $0.02 per GB-month it takes 8,760 GB of stored data to equal one OCU held all month, so compute is the bill until you are past roughly 8.8 TB, close to the 10 TiB hot storage ceiling per collection. That is the opposite shape to the storage-class minimums that dominate an S3 bill.

Retention is the lever that exists. The data lifecycle policy documentation covers time series collections, where "The lower bound is 24h and the upper bound is 3650d." Budget a tail: OpenSearch Serverless "then deletes the documents automatically on a best-effort basis, typically within 48 hours or 10% of the retention period, whichever is longer." On a 365-day policy that 10% is 36 days of data you asked to delete and are still storing.

Do OpenSearch Serverless collection types change the bill?

Yes, in two ways, and the second doubles a floor. First, the type decides where your data sits: "For search and vector search collections, all data is stored in hot storage to ensure fast query response times", while time series collections "use a combination of hot and warm storage".

Second, and more expensively, vector collections get their own compute. The pricing page: "A vector search collection cannot share OCUs with search and time series collections, even if the vector search collection uses the same KMS key as the search or time series collections. A new set of OCUs will be created for your first vector search collection." The capacity documentation says the same thing about grouping: "Only one type of collection (search, time series, or vector search) can be included in a single collection group." So an account running a product search collection and a RAG vector collection on Classic pays two minimums, hypothetically $700.80 a month idle rather than $350.40. Nowhere does AWS add those two numbers up for you.

Collection groups did remove one older multiplier. The collection groups documentation says that "Collections within the same collection group share compute resources and OCU memory space, even when they use different KMS keys for encryption", "eliminating the need for separate OpenSearch Compute Units (OCUs) for each KMS key". Before that a second encryption key meant a second set of OCUs: one of the few places where a KMS key decision has a four-figure consequence unrelated to the KMS bill.

How do OpenSearch Serverless OCUs show up on the AWS bill?

As two compute lines and a storage line. The pricing page describes the billing view: "You will see one entry for compute in OCU-hours with two labels: one for data indexing and the other for search." Granularity is finer than the hourly rate suggests, since "OCUs are billed on an hourly basis on a collection group level with per-second granularity", and the comparison table states the whole model in one line: "You're charged in OCU-hours for compute for data ingestion, compute for search and query, and storage retained in S3."

Watch it with the two account-level CloudWatch metrics the capacity page names, SearchOCU and IndexingOCU. The same page frames the maximum as the real control: "Use maximum capacity as a budgetary control lever to ensure your collections always stay within a defined spend limit." Check what yours is set to. The console creation form defaults maximum indexing and maximum search capacity to 96 OCUs each. At $0.24 an OCU-hour, 192 OCUs held for a 730-hour month would be $33,638.40, and the OpenSearch Serverless quotas allow that to be raised to 1,700 OCUs each way. Both figures are hypothetical ceilings, not forecasts, but a default ceiling worth $33,638 a month is worth lowering on the way past.

One discount lever applies. The pricing page notes that "Serverless is also covered by Database Savings Plans", so a Serverless commitment is measured in dollars per hour rather than in OCUs.

Finally, AWS's own Example 6 does not quite add up, in the direction you would expect. Its four components are $2.92, $175.20, $28.80 and $175.20, a true total of $382.12. Each is rounded up to $3, $176, $29 and $176, and the example prints "The total monthly charges = $384". The $1.88 gap is 0.49%: nothing on one collection, worth knowing if you are forecasting from AWS's examples. It is the same habit that shows up in Aurora Serverless v2's idle ACU floor, where a service named serverless also bills a minimum every hour it exists, and in the per-GB charges behind VPC flow logs, which is usually the data you were about to point at an OpenSearch collection in the first place.