Think Twice Before Using AWS OpenSearch Serverless

Many businesses today want a simple way to centralize, search, and visualize logs and operational data. From the outside, AWS OpenSearch Serverless looks like a perfect fit: no cluster management, automatic scaling, and deep AWS integration.

We thought the same.

Three months and $1,800 later, we migrated away.

This article shares our real production experience, concrete numbers, and the lessons we learned about when serverless actually makes sense—and when it doesn’t.

What Is AWS OpenSearch Serverless?

OpenSearch is AWS’s managed alternative to Elasticsearch. It provides:

• Full-text search across massive datasets
• Real-time indexing and aggregations
• Interactive dashboards (similar to Kibana)
• RESTful APIs for ingestion and querying

Serverless OpenSearch removes cluster management completely:

• No nodes to size or configure
• No capacity planning or scaling decisions
• AWS manages scaling, patching, and availability automatically
• Pay only for what you use (in theory)

You simply ingest data — AWS handles the rest.

On paper, this sounds ideal. In practice, the devil is in the details.

How Pricing Works (The Critical Part)

Understanding OpenSearch Serverless pricing is crucial before you start. Unlike traditional pay-per-query models, you’re paying for reserved compute capacity whether you use it or not.

OpenSearch Serverless pricing is based on OpenSearch Compute Units (OCU / ACU).

ACU Capacity

Typical Minimums

Current compute price (approximate): $0.24 per ACU-hour

Cost Example

Key takeaway:

• Even an empty collection costs ~$170/month
• Production redundancy quickly becomes $350–$400/month minimum
• This is before ingesting a single log

Compare this to:

• CloudWatch Logs: Pay per GB ingested (~$0.50/GB)
• S3 + Athena: Pay per query (~$5/TB scanned)
• Self-managed OpenSearch on EC2: ~$100-150/month for small clusters

The serverless premium is significant.

Our Initial Plan

We planned to use OpenSearch Serverless as a centralized observability platform for:

• Customer metadata - Search and analytics across user data
• S3 inventory data - Track storage usage and patterns
• DynamoDB records - Historical data analysis
• CDN logs (CloudFront) - Traffic patterns and debugging
• Time-series analytics - Dashboards for business metrics

Initial estimate: around $350/month

We based this on AWS’s calculator and assumed moderate growth. This turned out to be wildly optimistic—we underestimated three critical factors:

1. Minimum ACU requirements don’t scale down to zero
2. Empty indexes still consume resources
3. Log volume grows faster than expected

Phase 1 – Metadata & Aggregated Data

We first ingested:

• Aggregated S3 inventory data
• Small DynamoDB datasets

Early mistake: We ingested raw daily S3 inventory reports → huge volume.

Fix:

• Use Athena + Lambda to pre-aggregate
• Ingest only summarized records

After optimization, monthly cost stabilized around $250–$270.

Phase 2 – CloudFront Logs (Where It Broke)

CloudFront access logs:

• ~500 MB per day
• One index per day

Almost immediately:

• Read ACU ≈ 1
• Write ACU ≈ 1

CloudFront Cost Impact

Only for CloudFront logs.

Total bill jumped toward $380–$400/month, and data was still growing.

Hidden Cost: Empty Indexes Still Cost Money

We enabled data lifecycle rules (delete data after 2 weeks).

Surprise:

• Indexes with zero documents still existed
• Existing indexes still reserve compute capacity
• We were paying for nothing

Workaround:

• Custom Lambda running daily
• Deletes all indexes with 0 documents

This reduced waste — but required custom maintenance logic.

Phase 3 – More Logs, More Pain

After adding logs from another CDN:

Still minimal ingestion.

We didn’t even attempt:

• ALB logs
• VPC Flow Logs
• S3 access logs

Those would have pushed costs even higher.

The Bigger Problem: No Native Alerting

Logs are useful only if they generate insight.

We expected:

• Alerts
• Anomaly detection
• Thresholds
• Near real-time monitoring

Classic OpenSearch supports alerting. OpenSearch Serverless does not.

Capability Comparison

To compensate, you must build:

• Lambda polling jobs
• Step Functions workflows
• Managed Grafana
• Custom integrations

All of this adds engineering time, maintenance burden, and more cost.

At that point, serverless simplicity is gone.

Ask Yourself This

Are you willing to pay $600+ per month:

• To look at dashboards once or twice a day?
• Without native alerting?
• For data you could query elsewhere?

For us, the answer was no.

Cheaper Alternatives That Worked Better

After migrating away, we implemented a hybrid approach that cost a fraction of OpenSearch Serverless:

Our New Architecture

For real-time monitoring:

• CloudWatch Logs Insights for critical alerts
• Lambda functions for anomaly detection
• SNS for notifications

For historical analysis:

• Athena queries on S3
• Visualization with QuickSight
• Occasional ad-hoc analysis

For search functionality:

• DynamoDB with GSI for metadata
• ElastiCache for frequently accessed data

We kept logs in S3, queried on demand, and built lightweight dashboards. The total cost dropped by 80% while maintaining the same functionality.

When OpenSearch Serverless Actually Makes Sense

Despite our experience, OpenSearch Serverless isn’t inherently bad—it’s just expensive for certain use cases. It can be a good fit when:

Good Use Cases

1. Application search - Product catalogs, document search where users expect instant results
2. High-value, low-volume data - Business intelligence dashboards accessed frequently
3. Compliance requirements - When you need managed infrastructure with AWS compliance certifications
4. Rapid prototyping - Quick POCs where time-to-market matters more than cost
5. Unpredictable spiky workloads - When traditional clusters would be over-provisioned most of the time

Bad Use Cases (Our Scenario)

1. High-volume log aggregation - CloudWatch or S3 + Athena are much cheaper
2. Infrequent access patterns - Paying for 24/7 capacity you use once a day
3. Cost-sensitive projects - When budget is a primary constraint
4. Time-series data - CloudWatch or Timestream are purpose-built and cheaper
5. Alerting-heavy workflows - Lack of native alerting makes this painful

Lessons Learned

After this experience, here’s what we’d do differently:

1. Always Run a Cost Simulation

Before committing, model your actual usage:

• Estimate daily log volume
• Calculate required ACUs
• Project 3-month and 12-month costs
• Compare with alternatives

2. Start with the Cheapest Alternative

For logs, start with:

1. CloudWatch Logs (if already using AWS)
2. S3 + Athena (for historical analysis)
3. Self-managed OpenSearch on EC2 (if you need full features)
4. OpenSearch Serverless (only if others don’t fit)

3. Set Up Cost Alerts Immediately

We should have set CloudWatch billing alarms from day one:

• Alert at 50% of budget
• Alert at 80% of budget
• Daily cost reports

4. Question “Serverless” Marketing

“Serverless” doesn’t mean:

• ❌ Cheaper
• ❌ Zero maintenance
• ❌ Unlimited scaling

It means:

• ✅ No server management
• ✅ Automatic scaling (at a cost)
• ✅ Simplified operations (with tradeoffs)

AWS OpenSearch Serverless is:

• ✅ Easy to start
• ✅ Fully managed
• ❌ Expensive at scale
• ❌ Poor for log analytics
• ❌ Lacking native alerting

Suitable For

• Small search applications
• Low-volume indexed datasets
• Short-lived experiments

Not Suitable For

• High-volume logs
• Time-series observability
• Cost-sensitive analytics

Takeaway

Serverless does not automatically mean cheaper or simpler.

The real lesson isn’t “avoid OpenSearch Serverless”—it’s choose the right tool for your specific use case.

Always:

1. Model monthly costs with realistic data volumes
2. Simulate growth over 6-12 months
3. Test with production-like data before committing
4. Compare alternatives objectively
5. Set up cost monitoring from day one

We learned this the expensive way—$1,800 and three months of engineering time. Hopefully, this post helps you make a more informed decision.

What’s your experience with OpenSearch Serverless or other AWS serverless services? Share your cost optimization stories in the comments below—I’d love to hear what worked (or didn’t work) for you.