OpenSearch Serverless: Complete Guide to AWS’s Managed Search Service (2026)

OpenSearch Serverless is AWS’s fully managed, serverless deployment option for OpenSearch that automatically scales resources based on workload demands. Launched in 2023, it eliminates the operational overhead of managing search clusters while maintaining the powerful search and analytics capabilities OpenSearch is known for. This comprehensive guide covers everything you need to know about OpenSearch Serverless in 2026.

What is OpenSearch Serverless?

OpenSearch Serverless is an on-demand, auto-scaling configuration for Amazon OpenSearch Service. Unlike traditional OpenSearch deployments where you provision and manage specific instance types and counts, OpenSearch Serverless automatically adjusts compute and memory resources based on your application’s needs.

Key characteristics:

• No cluster management or capacity planning required
• Automatic scaling up and down based on workload
• Pay only for resources consumed (compute + storage)
• Sub-second response times for most queries
• Built-in high availability across multiple Availability Zones
• Compatible with OpenSearch Dashboards

OpenSearch Serverless vs. Managed OpenSearch

How OpenSearch Serverless Works

Collections

In OpenSearch Serverless, you work with collections instead of domains. A collection is a logical grouping of indices that share the same security and capacity settings.

Collection types:

• Search: Optimized for full-text search with low latency
• Time Series: Optimized for log analytics and observability data
• Vector Search: Optimized for similarity search and machine learning use cases

OpenSearch Compute Units (OCUs)

OpenSearch Serverless measures and bills compute capacity in OpenSearch Compute Units (OCUs). One OCU provides:

• 6 GB of memory
• Corresponding compute and storage resources

Minimum OCUs per collection:

• Search collections: 2 OCUs (for indexing) + 2 OCUs (for search) = 4 OCUs minimum
• Time series collections: 2 OCUs (for indexing) + 2 OCUs (for search) = 4 OCUs minimum

AWS automatically adds or removes OCUs based on workload, up to your configured maximums.

Data Lifecycle

Indexing flow:

1. Data sent to collection endpoint
2. Indexing OCUs process and index the data
3. Indexed data stored in Amazon S3 (durable storage)
4. Hot data cached in search OCUs for fast queries

Query flow:

1. Query submitted to collection endpoint
2. Search OCUs retrieve data from cache or S3
3. Results returned to application

Key Features and Benefits

1. Automatic Scaling

OpenSearch Serverless scales compute resources up and down automatically within seconds:

• Scale up: When query load increases, AWS adds search OCUs automatically
• Scale down: During low-traffic periods, AWS reduces OCUs to save costs
• No downtime: Scaling happens without service interruption

This is particularly valuable for applications with:

• Unpredictable traffic patterns
• Seasonal spikes (e-commerce, tax season, etc.)
• Dev/test environments with intermittent usage

2. Simplified Operations

AWS handles all operational tasks:

• Cluster provisioning and configuration
• Software patching and upgrades
• Backup and disaster recovery
• Multi-AZ replication
• Index lifecycle management

3. Built-in Security

Security features included by default:

• Encryption: Data encrypted at rest (S3) and in transit (TLS)
• Network isolation: VPC endpoint support
• Access control: Integration with AWS IAM, SAML, and OpenID Connect
• Data access policies: Fine-grained access control at collection and index level

4. High Availability

Built-in resilience without configuration:

• Automatic replication across multiple Availability Zones
• No single point of failure
• 99.9% SLA for availability

Use Cases for OpenSearch Serverless

1. Application Search

Power full-text search for applications without managing infrastructure:

• E-commerce product search
• Documentation and knowledge bases
• Media and content libraries
• Internal enterprise search

Why serverless: Search traffic is often unpredictable (daily cycles, marketing campaigns, viral events). Serverless automatically handles these variations.

2. Log Analytics (Time Series)

Analyze application logs, infrastructure metrics, and security events:

• Application performance monitoring (APM)
• Security information and event management (SIEM)
• Infrastructure monitoring
• Audit logging

Why serverless: Log volumes fluctuate significantly. Serverless scales automatically during incident investigations while reducing costs during normal operations.

3. Vector Search / ML Applications

Build similarity search and recommendation engines:

• Product recommendations
• Content personalization
• Image and video similarity search
• Anomaly detection

Why serverless: Removes infrastructure management for ML engineers, allowing focus on model development.

4. Development and Testing

Ideal for non-production environments:

• Development clusters that run intermittently
• QA/staging environments
• Proof-of-concept projects
• Demo environments

Why serverless: Pay only when actively using the service. No need to size instances or shut down/start clusters manually.

Pricing Model

Cost Components

OpenSearch Serverless pricing consists of two components:

1. Compute (OCU-hours):

• Indexing OCUs: $0.24 per OCU-hour
• Search OCUs: $0.24 per OCU-hour
• Billed per OCU per hour (minimum 4 OCUs per collection)

2. Storage (GB-month):

• $0.024 per GB-month for indexed data
• Stored durably in Amazon S3

Cost Example

Scenario: Small search application

• Collection runs 24/7
• Uses minimum 4 OCUs (2 indexing + 2 search)
• 50 GB indexed data

Monthly cost:

• Compute: 4 OCUs × 730 hours × $0.24 = $700.80
• Storage: 50 GB × $0.024 = $1.20
• Total: ~$702/month

When Serverless is Cost-Effective

Serverless wins when:

• Workload is unpredictable or highly variable
• Usage is intermittent (dev/test environments)
• You value operational simplicity over cost optimization
• Scaling events happen frequently

Managed wins when:

• Workload is steady and predictable 24/7
• You can right-size instances based on usage patterns
• You need maximum performance tuning
• Cost optimization is primary concern for production workloads

Getting Started with OpenSearch Serverless

Step 1: Create a Collection

Using AWS Console:

1. Navigate to Amazon OpenSearch Service
2. Click “Create collection”
3. Choose collection type (Search, Time series, or Vector)
4. Name your collection
5. Configure encryption settings

Using AWS CLI:

aws opensearchserverless create-collection \
    --name my-collection \
    --type SEARCH \
    --description "My search collection"

Step 2: Configure Security

Set up access policies and encryption:

Network access:

• Public access (with IAM authentication)
• VPC endpoint (private access)

Data access policy:

{
  "Rules": [
    {
      "ResourceType": "collection",
      "Resource": ["collection/my-collection"],
      "Permission": ["aoss:*"]
    },
    {
      "ResourceType": "index",
      "Resource": ["index/my-collection/*"],
      "Permission": ["aoss:*"]
    }
  ],
  "Principal": ["arn:aws:iam::123456789012:user/my-user"]
}

Step 3: Index Data

Use standard OpenSearch APIs:

POST https://my-collection.us-east-1.aoss.amazonaws.com/my-index/_doc
{
  "title": "OpenSearch Serverless Guide",
  "content": "Complete guide to AWS OpenSearch Serverless...",
  "timestamp": "2026-01-15T10:00:00Z"
}

Step 4: Query Data

GET https://my-collection.us-east-1.aoss.amazonaws.com/my-index/_search
{
  "query": {
    "match": {
      "content": "serverless"
    }
  }
}

Best Practices

1. Choose the Right Collection Type

• Search: For application search with low-latency requirements
• Time series: For log analytics with time-based data
• Vector: For ML-powered similarity search

2. Optimize Index Settings

• Use appropriate field types (text vs keyword)
• Disable unnecessary fields from _source
• Configure proper analyzers for text search
• Use doc_values for aggregations

3. Implement Efficient Queries

• Use filters instead of queries when possible (filters are cached)
• Limit result sizes with pagination
• Use search templates for repeated queries
• Profile slow queries and optimize

4. Monitor Usage and Costs

• Set up CloudWatch alarms for OCU usage
• Track costs with AWS Cost Explorer
• Use AWS Budgets for cost control
• Review CloudWatch Logs for performance insights

5. Security Best Practices

• Use VPC endpoints for production workloads
• Implement least-privilege IAM policies
• Enable encryption at rest and in transit
• Regularly audit access logs

Limitations and Considerations

Current Limitations (2026)

• Minimum capacity: 4 OCUs per collection (can’t scale below this)
• Plugin restrictions: Limited plugin support compared to managed OpenSearch
• Configuration: Less control over cluster settings
• Upgrades: AWS controls version upgrades
• Cross-region: No built-in cross-region replication

Not Recommended For

• Extremely cost-sensitive production workloads with steady 24/7 usage
• Applications requiring custom plugins
• Use cases needing deep cluster tuning
• Workloads that must stay on specific OpenSearch versions

Migrating to OpenSearch Serverless

From Managed OpenSearch

1. Create serverless collection
2. Reindex data: Use reindex API or snapshot/restore
3. Update application endpoints
4. Verify functionality
5. Cutover traffic
6. Decommission old domain

From Elasticsearch

1. Assess compatibility: OpenSearch is fork of Elasticsearch 7.10
2. Test applications: Verify API compatibility
3. Migrate data: Use Logstash, snapshot/restore, or custom scripts
4. Update queries: Modify any incompatible queries
5. Switch traffic

Conclusion

OpenSearch Serverless is an excellent choice for teams that want to leverage OpenSearch’s powerful search and analytics capabilities without the operational burden of managing clusters. Its automatic scaling, built-in high availability, and pay-per-use pricing make it particularly attractive for:

• Applications with variable or unpredictable workloads
• Development and testing environments
• Teams without dedicated OpenSearch expertise
• Projects where operational simplicity outweighs cost optimization

While managed OpenSearch remains the better choice for steady, predictable production workloads where cost optimization is critical, OpenSearch Serverless eliminates much of the complexity of running search infrastructure. As AWS continues to enhance the service, expect to see improved cost-efficiency and additional features that further narrow the gap with managed deployments.

For most new OpenSearch projects starting in 2026, OpenSearch Serverless should be your default choice unless you have specific requirements that demand managed infrastructure.