OpenSearch Serverless time series collections vs a managed Logit.io stack for logs

On 27 October 2026 AWS announced time series collections for the next generation of Amazon OpenSearch Serverless. They are built for logs, metrics, traces and events, scale compute with load, tier older data to a cheaper warm layer on Amazon S3 and add alerting and anomaly detection to serverless collections. If you run logs on OpenSearch today, it is a fair question whether this changes your plans.

Short answer: OpenSearch Serverless time series collections suit teams already deep in AWS who want usage-based billing and are happy to wire up ingestion, IAM policies and dashboards themselves. A managed Logit.io stack suits teams who want a fixed, published price, Logstash and OpenTelemetry ingestion already set up, and OpenSearch Dashboards ready on day one. Both run OpenSearch, so the decision is mostly about billing model, who does the plumbing and how portable you need to be.

This guide compares the two on cost, operations, lock-in and support, using figures from the AWS pages linked throughout and Logit.io's public pricing. It includes the commands to stand up a test on each side and check that your logs arrived, so you can measure rather than guess.

What AWS announced

Time series collections are a new collection type on the next generation of OpenSearch Serverless. According to the AWS announcement, they let you ingest, store and analyse logs, metrics, traces and events without provisioning clusters, and support up to 100 TB of hot storage per collection. The points that matter most for a logging workload are these:

• Compute scales with load, down to zero. AWS says compute scales in seconds when an incident drives a surge in log volume, then scales back down when traffic settles. The pricing page adds that indexing and search OCUs scale to zero after 10 minutes of inactivity.
• Hot and warm tiers in one collection. Each document is written to a low-latency hot tier and to Amazon S3. The index.warm.after setting decides when data leaves the hot tier, from 1 day up to 3,650 days, and never longer than the index's retention, with a default of 1 day.
• Retention set on the index. index.data.retention takes a whole number of days from 1 to 3,650, usually set in an index template.
• A required timestamp. Every document needs a top-level date field, @timestamp by default or whatever you set in index.timestamp_field. Documents with a missing, null or invalid timestamp are rejected individually, so one bad record does not fail a whole _bulk request.
• Alerting and anomaly detection. Per-query, per-bucket and PPL monitors, plus Random Cut Forest anomaly detection, managed in OpenSearch UI workspaces. AWS notes that Classic serverless collections did not offer these.

Billing has two parts. You pay for compute in OpenSearch Compute Units (OCUs) and for hot and warm storage in GB-month. The pricing page describes one OCU as roughly 6 GB of RAM with corresponding vCPU, billed hourly at the collection group level with per-second granularity.

For background on the earlier serverless model, see our post on OpenSearch Serverless. This is a real improvement for serverless OpenSearch, particularly the warm tier that stays queryable without restoring snapshots. The rest of this post looks at what it means in practice for a team shipping logs.

The two models side by side

Topic	OpenSearch Serverless time series	Managed Logit.io stack
Engine	OpenSearch, run by AWS as a serverless service	OpenSearch, run by Logit.io as a managed stack
Billing	OCU-hours for indexing and search, plus hot and warm GB-month (AWS pricing)	Published plans: log management from $25/mo billed annually, Hosted OpenSearch from $45.52/node/mo (OpenSearch pricing)
Capacity planning	Set minimum and maximum OCUs on a collection group	Pick a plan or node tier; resize when volume changes
Ingestion	You choose and run the path into the collection, signed with IAM	Logstash and Hosted OpenTelemetry endpoints come with a Logs stack
Dashboards	OpenSearch UI workspaces	OpenSearch Dashboards included with the stack
Access control	Network policies and data access policies on IAM principals	Stack credentials, plus role-based OpenSearch API users on Business and Custom plans
Where it runs	AWS commercial Regions where the next generation of Serverless is available	Logit.io's managed platform, reached over HTTPS

Neither column is better in every row. The rest of the post walks through each topic, starting with the one most teams ask about first.

Cost: usage-based versus a published plan

The AWS model charges for what you use. That is attractive when log volume is spiky, because you are not paying for worst-day capacity on quiet days. AWS makes exactly this argument in the announcement: teams size clusters for the worst day and pay for it every other day.

The trade-off is predictability. Your monthly bill depends on how many OCUs indexing and search consumed, how much data sat in the hot tier and how much sat in warm. A noisy deploy that doubles log volume for an afternoon also raises indexing OCUs for that afternoon. A team that runs heavy searches during an incident review raises search OCUs. None of that is wrong, but it means the cost of a month is something you work out afterwards rather than something you know in advance.

AWS gives you a lever for this: the maximum OCU settings on the collection group cap spend, as the announcement puts it. Per-OCU and per-GB rates vary by Region, so read them for your Region on the AWS pricing page rather than relying on a figure copied into a blog post. The pricing page also notes that Database Savings Plans cover Serverless in exchange for a usage commitment.

A managed Logit.io stack works the other way round. You choose a plan, and the price is on the pricing page before you sign up. Log management starts from $25/mo billed annually, and Hosted OpenSearch starts from $45.52/node/mo, with a 14-day free trial. When volume grows past your plan you move up a plan, which is a decision you make, not a bill you discover.

Estimating your own numbers

The honest way to compare is to measure your own volume. Count a typical day's log documents and their size on your current platform, then price both options against it.

# Daily document count and store size for your log indices (any OpenSearch cluster)
# On Logit.io, use the logstash-* index pattern (or filebeat-* for Beats) in place of logs-*
curl -s -u "$OS_USER:$OS_PASS" "https://$HOST/_cat/indices/logs-*?v&h=index,docs.count,store.size&s=index"

# Peak versus average: count documents per hour for the last day
curl -s -u "$OS_USER:$OS_PASS" -H 'Content-Type: application/json' \
  "https://$HOST/logs-*/_search?size=0" -d '{
  "query": {"range": {"@timestamp": {"gte": "now-1d"}}},
  "aggs": {"per_hour": {"date_histogram": {"field": "@timestamp", "fixed_interval": "1h"}}}
}'

The ratio between your busiest hour and your average hour is the number that matters. A high ratio, for example a batch job that writes most of the day's logs in two hours, favours usage-based compute. A flat profile favours a fixed plan, because you would be paying for steady compute either way and gain nothing from scaling down.

Retention is the second input. With time series collections you pay hot rates for data younger than index.warm.after and warm rates after that. Work out how many days you really search at speed. Many teams find it is under a week, with older logs only opened for audits.

Operations: what you still run yourself

Serverless removes cluster sizing and tuning. AWS is clear that there are no clusters to size or tune: you set compute limits and a few index settings. That covers a lot of the operational work of running OpenSearch.

What it does not remove is the work around the cluster. To get logs flowing you still need to:

1. Create a collection group with capacity limits, then a time series collection inside it.
2. Write a network policy that decides where the collection can be reached from, and a data access policy that grants IAM principals read and write access.
3. Choose an ingestion path and sign requests with IAM credentials. Many existing shippers send basic-auth requests, so check that yours supports AWS request signing or put something in between that does.
4. Make sure every document has a valid top-level timestamp in the field you configured, because documents without one are rejected.
5. Set up dashboards, monitors and anomaly detectors in OpenSearch UI workspaces.

Here is the AWS CLI part of that, taken from the announcement:

aws opensearchserverless create-collection-group \
    --name app-logs-group \
    --generation NEXTGEN \
    --standby-replicas ENABLED \
    --capacity-limits '{
        "minIndexingCapacityInOCU": 0,
        "minSearchCapacityInOCU": 0,
        "maxIndexingCapacityInOCU": 96,
        "maxSearchCapacityInOCU": 96
    }'

aws opensearchserverless create-collection \
    --name app-logs \
    --type TIMESERIES \
    --collection-group-name app-logs-group \
    --encryption-config aWSOwnedKey=true

And the index template that sets the time field, tiering and retention:

PUT /_index_template/app-logs
{
  "index_patterns": ["app-logs*"],
  "template": {
    "settings": {
      "index.timestamp_field": "event_time",
      "index.warm.after": "7d",
      "index.data.retention": "30"
    }
  }
}

AWS also offers Express Create in the console, which sets up the collection group, encryption, network access and data access with default settings. That is the quickest way to try it.

The same job on Logit.io

On Logit.io, creating a Logs stack gives you the OpenSearch cluster, OpenSearch Dashboards and ingestion endpoints together. The dashboard's onboarding shows the setup for your shipper with your stack's endpoint, port and credentials already filled in, then waits until your first logs are searchable. The quickest test is to send one log line over the Hosted OpenTelemetry endpoint on your Logs stack (on by default for new Logs stacks; existing stacks switch it on from the Endpoints page):

# Values from Settings > Endpoints on your Logs stack
export LOGIT_OTEL="https://your-stack-id-otel.logit.io"
export LOGIT_USER="your-otel-username"
export LOGIT_API_KEY="your-api-key"

curl -s -o /dev/null -w "%{http_code}\n" -u "$LOGIT_USER:$LOGIT_API_KEY" \
  -X POST "$LOGIT_OTEL/v1/logs" -H "Content-Type: application/json" \
  -d '{"resourceLogs":[{"resource":{"attributes":[{"key":"service.name","value":{"stringValue":"compare-test"}}]},"scopeLogs":[{"logRecords":[{"severityText":"INFO","body":{"stringValue":"hello from the comparison test"}}]}]}]}'

A 200 means the endpoint accepted the log. This is the same shape as the Send a test signal option in onboarding, which sends one log, one trace and one metric.

If you already use Logstash, Filebeat or another Beats shipper, the onboarding has a ready-made config for each, and the existing pipeline keeps working. Cluster upgrades, patching and node health are handled by Logit.io rather than by your team. What you still own is choosing a plan that fits your volume and moving up when you outgrow it.

Verifying that logs arrived, on either side

Whichever you test, prove the data landed with a count rather than by eye. The query is standard OpenSearch on both sides, but the index pattern and time field differ.

On Logit.io, use the OpenSearch API endpoint from Settings, Endpoints. Logs land in logstash-* indices (or filebeat-* if you ship with Beats), with the time in @timestamp:

POST /logstash-*/_count
{
  "query": {
    "bool": {
      "filter": [
        {"query_string": {"query": "\"hello from the comparison test\""}},
        {"range": {"@timestamp": {"gte": "now-15m"}}}
      ]
    }
  }
}

On a time series collection, send the request to the collection endpoint signed with your IAM credentials. Using the app-logs template above, the index pattern is app-logs* and the time field is event_time:

POST /app-logs*/_count
{
  "query": {
    "bool": {
      "filter": [
        {"query_string": {"query": "\"hello from the comparison test\""}},
        {"range": {"event_time": {"gte": "now-15m"}}}
      ]
    }
  }
}

A count of zero usually means the query does not match the platform: logstash-* (or filebeat-*) and @timestamp on Logit.io, or your template's index pattern and index.timestamp_field on a time series collection. It is rarely a lost log. On a time series collection, also check the errors block of your _bulk responses, because rejected documents are reported there rather than failing the request.

Lock-in and portability

Both options run OpenSearch, so your queries, index templates and mappings are portable in principle. The OpenSearch query DSL in the examples above works on both. That is a real advantage over moving between two different query languages.

The differences are in the edges. Time series collections introduce settings such as index.warm.after, index.data.retention and index.timestamp_field that are specific to the service. Access goes through IAM network and data access policies, and creation goes through the aws opensearchserverless API. If you later move, those are the parts you rewrite. None of that is unusual for a managed cloud service, but it is worth counting.

With Logit.io the edges are different. Ingestion uses standard shippers (Logstash, Beats, OpenTelemetry SDKs and the OpenTelemetry Collector) pointed at an HTTPS endpoint, so moving away means changing an endpoint and a credential in your shipper config. Index lifecycle and stack sizing are part of the Logit.io platform, so those are the parts you would rebuild somewhere else.

A practical way to keep your options open on either platform:

• Keep shipper configuration in source control with the endpoint and credential as variables.
• Use OpenTelemetry semantic conventions such as service.name so field names do not depend on one vendor's schema.
• Store index templates and saved queries as files, not only in a UI.
• Test a restore or export path once, before you need it.

Support

AWS points feedback for the new collections to AWS re:Post or your usual AWS Support contacts, as the announcement says. For teams that already hold an AWS Support plan, that keeps everything in one place. The level of help you get depends on the plan you have with AWS.

Logit.io's support team handles questions across the platform, so questions about a Logstash pipeline, a parsing problem or an OpenSearch Dashboards visualisation all can go to the same place. That matters most for logs, where many problems are about the data and its shape rather than the service being up.

Failure modes and limits to plan for

On OpenSearch Serverless time series collections

• Rejected documents. A missing, null or invalid timestamp means the document is rejected. Shippers that do not check _bulk errors can lose these silently.
• Timestamps are fixed. AWS says a document's timestamp cannot be changed after it is indexed, so fix clock or parsing problems before ingest.
• Slower first warm query. When a query needs warm data, the service loads it back into the hot tier. AWS says the first query takes longer and later ones run at hot-tier latency.
• Cold starts. With a minimum of 0 OCUs the group can scale to zero after 10 minutes of inactivity, so the first request after an idle period may need capacity to come back.
• Spend tracks load. A logging storm raises indexing OCUs. The maximum OCU settings cap this, but a cap set too low can slow ingestion at the moment you need logs most.
• Regional availability. Time series collections are available in AWS commercial Regions where the next generation of Serverless is available, so check your Region first.

On a managed Logit.io stack

• Plan limits. A fixed plan has a fixed capacity. If your volume grows past it you need to move to a larger plan, so watch the usage page and the ingestion history on your stack.
• Credential mix-ups. Each endpoint has its own credential. A 401 is most often the right key on the wrong endpoint.
• Field mapping conflicts. If two sources send the same field with different types, OpenSearch rejects the later documents. Keep field names consistent across shippers.
• Managed-stack API limits. Some cluster-level OpenSearch APIs are restricted on a managed stack. The managed stack limitations page lists them.

How to decide

For a broader comparison with Amazon OpenSearch Service, see Logit.io as an AWS OpenSearch alternative.

Choose OpenSearch Serverless time series collections if most of these are true:

• Your workloads and identity already live in AWS and IAM.
• Your log volume is very spiky and you would rather pay per use than per plan.
• You have engineers who are comfortable building the ingestion path, access policies and dashboards.
• You want long retention in the same collection with a cheaper warm tier.

Choose a managed Logit.io stack if most of these are true:

• You want to know the monthly price before the month starts.
• You want Logstash, Beats or OpenTelemetry ingestion set up for you, with your credentials pre-filled.
• You want OpenSearch Dashboards ready on the first day, without building workspaces and policies.
• You run across several clouds or on-premises and want one HTTPS endpoint for all of it.

If you are unsure, run both for a week with the same sample of logs. Use the per-hour aggregation above to compare ingest, and the count query to check nothing went missing. A week of your real data will tell you more than any comparison table.

Frequently asked questions

Are time series collections still OpenSearch?

Yes. They are part of Amazon OpenSearch Serverless and use OpenSearch APIs such as _bulk, index templates and the query DSL. They also add service-specific index settings for tiering, retention and the timestamp field.

Is serverless cheaper than a fixed plan for logs?

It depends on the shape of your volume. Usage-based billing helps when traffic is very spiky or often idle. A steady flow of logs uses compute all day either way. Measure your busiest hour against your average hour, then price both using the AWS pricing page for your Region and the Logit.io OpenSearch pricing page.

Can I use OpenSearch Dashboards with time series collections?

AWS manages monitors, detectors and dashboards for these collections in OpenSearch UI workspaces, including an Observability workspace. A Logit.io stack comes with OpenSearch Dashboards.

Can I move my log queries between the two?

Mostly. Standard OpenSearch query DSL and index templates carry across. Service-specific settings, IAM policies and Logit.io stack settings do not, so plan to rewrite those.

Does Logit.io support alerting on logs?

Yes. Logit.io includes managed alerting for log stacks. The alerting docs cover how to set up rules and destinations.

How do I try a managed Logit.io stack?

Start a 14-day free trial, create a Logs stack and follow the onboarding, which waits until your first logs are searchable. Then run the count query above against your stack to check the data.

Next steps

If a published price and ready-made ingestion sound like the better fit, read about Hosted OpenSearch on Logit.io and compare node tiers on the OpenSearch pricing page.