# Aged Indices Retained on Hot Storage in OpenSearch Service Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/aged-indices-retained-on-hot-storage-in-opensearch-service Log, metrics and other time-series domains in OpenSearch Service typically write to a new index per day or per rollover, and most queries touch only... By: PointFive Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) The short version Log, metrics and other time-series domains in OpenSearch Service typically write to a new index per day or per rollover, and most queries touch only the last few days. PointFive Research Cloud cost research at PointFive AWS service [AWS OpenSearch](https://www.pointfive.co/efficiency-hub/cloud-services/aws-opensearch) Category [Databases](https://www.pointfive.co/efficiency-hub/service-category/databases) Reference CER-0368 Type Inefficient Configuration ## Explanation Why the waste happens and who it affects. Without an Index State Management (ISM) policy, every older index stays on hot storage, the instance-store or EBS volumes attached to data nodes, until someone deletes it by hand. Hot storage also carries replica copies and reserved space overhead, so months of rarely queried data can drive both the number of data nodes and the size of their volumes. OpenSearch Service offers UltraWarm and cold storage, both backed by Amazon S3 and billed for the data actually stored, for read-only data that is queried less often or only occasionally. Teams often never enable them because the domain was created before these tiers were needed, because they require dedicated master nodes, or because nobody owns the retention decision. Historical data then stays at hot-storage prices, often for longer than any compliance requirement asks. ## Billing model The pricing dimensions that drive this cost. The storage tier an index lives on determines how it is billed. Hot storage Data node instance-hours plus EBS billed per GB-month provisioned, the same price whether the volume is empty or full, with replicas and reserved space consuming part of it UltraWarm An hourly rate per UltraWarm node plus managed storage billed only for the data stored, counting primary shards only Cold storage Managed storage billed for data stored, with no compute cost and no charge if cold storage holds no data Tier migrations No transfer charge for moving data between warm and cold, and only one copy is billed while a migration runs ## How to detect 5 checks to find it in your estate. - List indexes with their creation dates and sizes (for example \_cat/indices sorted by creation.date, or GET \_hot and GET \_warm on UltraWarm domains) and identify time-series indexes older than the window your dashboards and alerts actually query - Check whether index patterns are covered by an ISM policy with warm, cold or delete states, using the ISM explain API or the Index Management page in OpenSearch Dashboards - Compare ClusterUsedSpace and FreeStorageSpace with the share of data held in old indexes to estimate how much hot capacity is serving historical data - On domains with UltraWarm or cold storage enabled, review WarmStorageSpaceUtilization, ColdStorageSpaceUtilization and HotToWarmMigrationSuccessCount to confirm policies are actually moving data - Compare the oldest retained index with the documented retention requirement for that data set ## How to fix 6 ways to remove the waste. - Attach ISM policies that move indexes from hot to UltraWarm to cold and finally delete them, based on index age, size or document count, and use rollover (for example at a fixed size or age) to keep index growth bounded - Enable UltraWarm and cold storage on domains that meet the prerequisites: dedicated master nodes, no T2 or T3 data nodes, OpenSearch or Elasticsearch 6.8 or later for UltraWarm and 7.9 or later for cold storage; enabling either one is a configuration change that causes a blue/green deployment - Move only data that fits the warm tier: warm indexes are read-only unless returned to hot storage, cold indexes must be migrated back to warm before they can be queried, and broad or frequent searches may perform better on hot storage - Use index rollups to summarize older time-series data into coarser intervals before tiering or deletion, where detailed history is not needed - After data leaves the hot tier, reduce the number of data nodes or the EBS volume size so the smaller hot footprint actually lowers the bill - Set delete states that match compliance requirements rather than keeping data indefinitely ## Documentation Vendor references for pricing and configuration. - [Cost optimization techniques for Amazon OpenSearch Service docs.aws.amazon.com](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/cost-optimization.html) - [UltraWarm storage for Amazon OpenSearch Service docs.aws.amazon.com](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ultrawarm.html) - [Cold storage for Amazon OpenSearch Service docs.aws.amazon.com](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/cold-storage.html) - [Amazon OpenSearch Service Pricing aws.amazon.com](https://aws.amazon.com/opensearch-service/pricing/) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - AWS OpenSearch CER-0130 ### [Suboptimal Use of Intel-Based Instances in OpenSearch](https://www.pointfive.co/efficiency-hub/inefficiencies/suboptimal-use-of-intel-based-instances-in-opensearch) AWS Graviton processors are designed to deliver better price-performance than comparable Intel-based instances, often reducing cost by 20-30% at equivalent workload performance. OpenSearch domains running on older Intel-based families... Databases - AWS OpenSearch CER-0147 ### [Outdated Elasticsearch Version Triggering Extended Support Charges](https://www.pointfive.co/efficiency-hub/inefficiencies/outdated-elasticsearch-version-triggering-extended-support-charges) Many legacy workloads still run on older Elasticsearch versions - such as 5.x, 6.0-6.7, or 7.1-7.8 - due to inertia, compatibility constraints, or lack of ownership. Once these versions exceed their standard support window, AWS begins... Databases - AWS OpenSearch CER-0101 ### [Outdated OpenSearch Version Triggering Extended Support Charges](https://www.pointfive.co/efficiency-hub/inefficiencies/outdated-opensearch-version-triggering-extended-support-charges) Domains running outdated OpenSearch versions - particularly Elasticsearch 1.5 through 7.8, OpenSearch 1.0-1.2, and OpenSearch 2.3-2.9, whose standard support ended on November 7, 2025 - begin to incur AWS Extended Support charges once they... Databases --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.