How do I reduce the cost of using OpenSearch Service domains?

5 minute read

I want to reduce the cost of using Amazon OpenSearch Service domains without impacting my domain availability.


Use Reserved Instances

To reduce costs and still follow best practices, you can purchase Reserved Instances for your OpenSearch Service domains. After you purchased a Reserved Instance, the OpenSearch Service domain that uses the same instance type receives billing discounts without any change to the domain.

For more information, see the AWS Pricing Calculator and the Amazon OpenSearch Service FAQs.

Use the latest generation instance type and gp3 Amazon EBS volumes

OpenSearch Service adopts the latest Amazon Elastic Compute Cloud (Amazon EC2) instance types to deliver better performance at lower costs. It's a best practice to use the latest generation instance types for your load. If you're using larger instance types, then scale down to a smaller instance type. Perform load testing, and choose an instance type that's based on your usage and performance requirements. For more information, see On-Demand Instance pricing.

Note: When you change an instance type, OpenSearch Service uses a blue/green deployment. For more information, see Making configuration changes in Amazon OpenSearch Service.

OpenSearch Service data nodes require low latency and high throughput storage to provide fast indexing and query. Using Amazon Elastic Block Store (Amazon EBS) gp3 volumes gives you a higher baseline performance at a lower cost than gp2 volume types. The gp3 volume type is more stable because it doesn't use burst credits. When you use gp3 volumes, you can provision additional IPOS and throughput independent of volume size. The gp3 volume type also doubles the per-data-node volume size limits of the gp2 volume type. With these larger volumes, you increase the amount of storage per data node and reduce the cost of passive data.

Use UltraWarm and cold storage

If you use OpenSearch Service for log analytics, then move your data to UltraWarm or cold storage to reduce storage costs. Use Index State Management (ISM) to migrate data between storage tiers and manage data retention.

UltraWarm uses Amazon Simple Storage Service (Amazon S3) for storage, so the data is immutable and you need to store only a single copy. You pay only for the storage that's equivalent to the size of the primary shards in your index. For more information on using UltraWarm with OpenSearch Service, see UltraWarm storage for Amazon OpenSearch Service.

Cold storage is also backed by Amazon S3. If you need to query cold data, then you can attach it to your existing UltraWarm nodes. Cold data incurs the same managed storage cost as UltraWarm, but objects in cold storage don't consume UltraWarm node resources. Cold storage provides a significant amount of storage capacity without impacting UltraWarm node size or count.

UltraWarm is cost effective when you have approximately 2.5 TiB of data in hot storage. Monitor your fill rate, and move indexes to UltraWarm before you reach that volume of data.

Note: OpenSearch Service doesn't support Reserved Instances for UltraWarm storage nodes.

Follow best practices for availability

Review and implement the best practices for sizing, dedicated primary instances, and Multi-AZ deployments.

Reduce replicas

Important: The best practices in the following sections can expose you to a potential risk of data loss and cluster unavailability.

Every replica in your index adds storage that's equal to the storage in the primary shards. For example, if your primary shards for an index hold 1 TB of data, then the first replica doubles the storage to 2 TB. The second replica triples it to 3 TB. By reducing the replica count to one, you drop your minimum data node and storage needs and see a reduction in storage cost. For more information, see Reducing cost for small Amazon Elasticsearch Service domains and review the Reducing replicas section.

Reduce Availability Zones

You might be using a three-zone deployment, with three data nodes and two replicas. This setup protects your data if one or two Availability Zones (AZs) become unavailable. If you reduce your deployment to two Availability Zones, then you can reduce the minimum data node count to two and replicas to one. However, you risk data loss if more than one Availability Zone becomes unavailable. This applies to small domains where you can reduce the node count to below three. For more information and best practices for larger workloads, see Reducing cost for small Amazon Elasticsearch Service domains and review the Reducing Availability Zones section.

Remove dedicated primary nodes

Dedicated primary nodes provide stability and availability for your OpenSearch Service domains. They hold the cluster state, and then broadcast that state to all nodes in the cluster. They don't process requests themselves.

You can choose not to use dedicated primary nodes so that your data nodes are the eligible primary nodes. For more information on the best practice setups, see Reducing cost for small Amazon Elasticsearch Service domains and review the Removing dedicated primary nodes section.

Related information

What happens when I make a configuration change to my Amazon OpenSearch Service cluster?

AWS OFFICIALUpdated a year ago