OpenSearch Pricing: How Much Does AWS OpenSearch Really Cost?

How Is OpenSearch Priced?

OpenSearch is an open-source search and analytics suite derived from Elasticsearch, used for a range of use cases like log analytics, full-text search, and application monitoring. It is maintained by Amazon and provided free of charge.

The AWS OpenSearch Service is a fully managed service, based on OpenSearch software, that makes it easy to deploy, operate, and scale OpenSearch clusters in the AWS Cloud. It provides several pricing options including a free tier, on-demand pricing, reserved instance pricing, and a serverless option. There are also extra charges for data ingestion and storage.

Understanding Amazon OpenSearch Pricing Tiers

AWS OpenSearch offers several pricing options.

Free Tier

The AWS Free Tier for Amazon OpenSearch Service allows users to get started without any initial cost. Under this plan, customers can use up to 750 hours per month of a t2.small.search or t3.small.search instance. These entry-level instances are typically used for test workloads. T

The Free Tier also includes 10 GB per month of optional Amazon Elastic Block Store (EBS) storage. If the usage exceeds these limits, standard OpenSearch Service rates apply for the extra resources used.

On-Demand Instance Pricing

Amazon OpenSearch Service offers various instance types billed on an hourly basis. These instances are categorized into General Purpose, Compute Optimized, Memory Optimized, Storage Optimized, and OR1.

Here are some examples of the pricing for various instances:

General Purpose Instances

Suitable for diverse workloads with balanced CPU and memory.

• t3.small.search: $0.036 per hour
• m6g.large.search: $0.128 per hour

Compute Optimized Instances

Suitable for compute-intensive workloads.

• c6g.large.search: $0.113 per hour
• c5.large.search: $0.125 per hour

Memory Optimized Instances

Suitable for memory-intensive applications.

• r6g.large.search: $0.167 per hour
• r5.large.search: $0.186 per hour

Storage Optimized Instances

Suitable for workloads requiring high storage throughput.

• i3.large.search: $0.25 per hour
• im4gn.large.search: $0.273 per hour

OR1 Instances: Optimized for OpenSearch workloads.

• or1.medium.search: $0.105 per hour
• or1.large.search: $0.209 per hour

Reserved Instance Pricing

Reserved instances allow users to reserve capacity for a one- or three-year term, providing significant cost savings compared to on-demand pricing. There are three payment options:

No Upfront Reserved Instances (NURI):

• One-year NURIs offer a 31% discount.
• Three-year NURIs offer a 48% discount.

Partial Upfront Reserved Instances (PURI):

• One-year PURIs offer a 33% discount.
• Three-year PURIs offer a 50% discount.

All Upfront Reserved Instances (AURI):

• One-year AURIs offer a 35% discount.
• Three-year AURIs offer a 52% discount.

Example pricing: For the m6g.large.search instance, NURI pricing would be $0 upfront, $64.24 monthly, $0.088 hourly effective rate, 31% savings.

OpenSearch Serverless Pricing

Amazon OpenSearch Serverless charges are based on resource consumption, billed separately for compute and storage:

Compute capacity

• Measured in OpenSearch Compute Units (OCUs), where one OCU includes 6 GB of RAM and corresponding vCPU. 
• A minimum of 2 OCUs is required for the first collection, with variations depending on data size and collection type.

Indexing

$0.24 per OCU per hour.

Search and Query

$0.24 per OCU per hour.

Managed storage

$0.024 per GB per month.

Additional Costs When Using AWS OpenSearch

OpenSearch Ingestion Pricing

OpenSearch Ingestion is billed based on the compute resources used to ingest and transform data:

• Compute capacity: Measured in OCUs, where one OCU includes 8 GB of RAM and 2 vCPUs.
• Ingestion: $0.24 per OCU per hour.

OCUs are billed on an hourly basis with per-minute granularity, and pipelines can be paused to avoid charges.

OpenSearch Service Direct Query Pricing

Direct Query charges are based on the compute resources needed to query external data or maintain indexes:

• Compute capacity: Measured in OCUs, with each OCU comprising 2 vCPUs and 8 GiB of RAM.
• Direct Query: $0.24 per OCU per hour.

Users can set a maximum number of OCU-hours per billing period to control costs.

Amazon EBS Volume Pricing

Amazon OpenSearch Service allows users to select different types of Amazon EBS volumes, with charges based on the chosen storage type:

General Purpose SSD (gp3):

• Storage: $0.122 per GB per month.
• IOPS: $0.008 per provisioned IOPS per month beyond free limits.
• Throughput: $0.064 per provisioned MiB/s per month beyond free limits.

Provisioned IOPS (SSD):

• Storage: $0.169 per GB per month.
• IOPS: $0.088 per IOPS per month.

UltraWarm and Cold Storage Pricing

UltraWarm storage offers a cost-effective way to retain large volumes of data with interactive query capabilities. Cold storage is the lowest-cost option for infrequently accessed data:

UltraWarm Instances:

• ultrawarm1.medium.search: $0.238 per hour.
• ultrawarm1.large.search: $2.68 per hour.

Cold Storage

Pricing is primarily based on Amazon S3 storage rates, with charges for compute resources only when data is accessed.

Optimizing AWS OpenSearch Costs 

Here are some of the ways that organizations can optimize their costs on AWS OpenSearch Service.

Implement Cross-Account Access for AWS OpenSearch

Cross-account access allows multiple AWS accounts to share a single OpenSearch domain, leading to cost savings and simpler management. This involves setting up AWS Identity and Access Management (IAM) roles and policies to grant permissions across different accounts. It avoids the need to create and manage multiple clusters across different accounts, reducing infrastructure costs.

For example, a large enterprise with separate accounts for development, testing, and production can benefit from a single, shared OpenSearch domain, which can be accessed securely through IAM roles, ensuring that only authorized users and services have access. Cross-account access also simplifies billing by consolidating usage under one account, making budgeting easier.

Use the Latest OpenSearch Version

Each new version of OpenSearch typically includes performance improvements, bug fixes, and new features that can improve efficiency and reduce operational costs. For example, newer versions often come with better memory management and faster query processing capabilities, which can lower the compute resources required for the same workload.

The latest versions of OpenSearch also include the most recent security patches, reducing the risk of security breaches that could result in costly downtime or data loss. By scheduling regular updates and using AWS tools like Systems Manager for automation, organizations can ensure they are always running the most current version of OpenSearch. 

Minimize Inter-Node Communication

Inter-node communication in an OpenSearch cluster can be resource-intensive, affecting performance and cost. Minimizing this communication aids in optimizing resource use and reducing costs. One approach is to optimize the sharding strategy; properly balanced shards distribute data evenly across nodes, reducing the need for excessive data transfers.

Another strategy is to ensure data locality by keeping related data on the same node as much as possible. This can be achieved by allocating shards and using awareness attributes to control where shards are placed. For example, placing primary and replica shards on different nodes within the same availability zone can reduce latency and improve performance.

Using instance types with high network throughput can also mitigate the costs associated with inter-node communication. Regular monitoring and adjusting the cluster configuration based on workload patterns can help maintain an efficient setup. Tools like AWS CloudWatch can monitor inter-node traffic and inform decisions about cluster adjustments.

Use OpenSearch Curator

OpenSearch Curator helps manage and optimize indices in an OpenSearch cluster. It automates routine index management tasks, such as taking snapshots, deleting old indices, and optimizing existing indices. By regularly deleting outdated indices, organizations can avoid unnecessary storage costs and ensure that the cluster remains performant.

For example, a logging application might generate a large volume of data daily. Using Curator, the organization can automate the deletion of indices older than a certain threshold (e.g., 30 days), keeping storage usage in check. Curator can also automate the process of taking snapshots, ensuring that data is backed up regularly without manual intervention.

Use OpenSearch Rollups

OpenSearch Rollups allow users to summarize and aggregate historical data into smaller, more manageable indices. This is useful for handling large volumes of time-series data, such as logs or metrics, where detailed granularity is only needed for recent data. Rollup indices are smaller than raw data indices, so querying them requires less processing power.

Creating rollup jobs involves defining a rollup index that captures the necessary summaries from the source data. For example, an organization monitoring application performance might roll up detailed metrics from one-second intervals to one-minute intervals after a week. This reduces the amount of data stored while retaining essential trends and patterns.

Consider Third-Party OpenSearch Plugins

Third-party plugins can extend the functionality of OpenSearch and offer features that might not be available in the base version. Integrating these plugins can provide additional cost-saving benefits and performance enhancements. For example, some plugins offer advanced data compression techniques, reducing storage costs by decreasing the disk space required for data.

Other plugins might provide optimized query performance or enhanced security features. Security-focused plugins can offer more granular access control or advanced threat detection capabilities, reducing the risk of security incidents. 

When considering third-party plugins, it is important to evaluate their compatibility with the existing OpenSearch version and their impact on overall system performance. Testing plugins in a staging environment before deploying them in production can help identify any potential issues. 

Managed ELK Stack with Coralogix

Coralogix sets itself apart in observability with its modern architecture, enabling real-time insights into logs, metrics, and traces with built-in cost optimization. Coralogix’s straightforward pricing covers all its platform offerings including APM, RUM, SIEM, infrastructure monitoring and much more. With unparalleled support that features less than 1 minute response times and 1 hour resolution times, Coralogix is a leading choice for thousands of organizations across the globe.