The Frozen Tier: Keeping Rarely Queried Data Cost-Efficient

1. The storage tiering concept and where the frozen tier fits

Storage tiering in Elasticsearch rests on the observation that query frequency and data age tend to correlate closely: fresh data gets queried often, older data increasingly rarely, until eventually only occasional, often purely forensic or regulatory queries remain. Hot, warm and cold tiers differ mainly in hardware quality, but all three still keep the full data locally on cluster nodes, just with different resource allocations.

The frozen tier breaks that pattern: it no longer keeps data locally at all, letting it live entirely in object storage and only fetching the parts an actual query needs. That is a qualitative rather than a purely quantitative difference from the earlier phases, since the savings here come not from hardware tier but from the storage location itself, enabling an entirely different cost structure.

2. How the frozen tier works technically: partially mounted indices

Technically, the frozen tier is built on what are called searchable snapshots, registered in the cluster as partially mounted indices. Unlike a classic index, the actual segment data does not live on local storage but in the snapshot repository, usually S3-compatible object storage. The cluster keeps only metadata plus a small, shared cache locally, through which recently queried data blocks get cached.

When a query hits a frozen index, the cluster first checks whether the needed data blocks already sit in the local cache. If not, exactly those blocks, not the entire index, get fetched from object storage. This targeted, block-level access is what fundamentally distinguishes the frozen tier from a classic restore, where the entire index would always have to be fully retrieved before any query became possible at all.

3. The difference from the cold tier: storage location, not just replica reduction

The cold tier primarily reduces replica count and moves indices to cheaper hardware that still remains locally attached to the cluster. The data stays fully on cluster storage, just with reduced redundancy. The frozen tier goes one decisive step further: here the data no longer permanently lives on cluster storage at all, only in object storage, so the local storage tied up per index drops to almost zero.

This distinction has direct consequences for capacity planning: a cluster with a cold tier still needs enough local storage for every cold index, cheaper storage or not, while a cluster with a frozen tier can theoretically reference petabytes of frozen data without local storage capacity having to grow proportionally. The price is a noticeably higher response time on a cache miss, since data then has to be fetched from object storage first.

4. The latency trade-off for rarely queried data

The central trade-off of the frozen tier is obvious: queries against frozen indices take longer than against hot or warm indices, especially on a cache miss, when data has to be freshly loaded from object storage. Where a query against a hot index typically gets answered in the low single-digit millisecond range, frozen queries against a cold cache can take several seconds, depending on network latency to object storage and the amount of segment data that needs fetching.

This trade-off is entirely acceptable exactly when it matches the actual usage pattern: for ad hoc analysis, rare forensic queries, or regulatory-mandated but practically almost never accessed archive data, a response time of a few seconds is usually perfectly fine. It only becomes a problem when frozen indices get mistakenly used for time-critical, interactive dashboards where users expect an instant answer.

5. Configuration: searchable snapshot mounting and object storage requirements

Moving an index into the frozen tier starts with creating a snapshot of the index, followed by mounting it in frozen mode through the searchable snapshot API. This removes the need to fully restore the index locally beforehand, and the mount operation itself is considerably faster than a classic restore since it only reads metadata. What is required is an object storage repository with sufficient bandwidth, since a too-slow repository immediately shows up in query time on every cache miss.

Additionally, nodes intended for the frozen tier need their own dedicated node role plus a configured shared cache, usually on local SSD storage, whose size directly determines how many recently queried data blocks can be answered without another trip to object storage. An undersized cache means even repeated, similar queries keep getting reloaded from object storage over and over.

POST _snapshot/s3-backup-repo/monthly-snap-2026.05/_mount
{
  "index": "logs-2026.05",
  "renamed_index": "frozen-logs-2026.05",
  "index_settings": {
    "index.number_of_replicas": 0
  }
}

6. Practical fit: archive data versus active search

The frozen tier is an excellent fit for log archives, historical compliance data, old transaction logs or raw analytics data that must be retained for regulatory reasons but practically never gets queried. It also works well for occasional but very broad analyses spanning several years, say a year-over-year comparison in a business analysis, since these queries are rare enough that the extra latency is not a real concern.

For an active product search on a Magento store, for user sessions, or for any query where end customers are waiting for a fast answer, the frozen tier is a poor fit. Aggregations over very large amounts of frozen data should also be used with care, since a broad aggregation may need to fetch a very large number of segment blocks from object storage and can therefore take disproportionately long compared to the same aggregation running against a hot index.

7. Cost comparison: frozen tier versus hot and warm storage

The cost difference between the frozen tier and the earlier phases is substantial, since object storage typically costs only a fraction of what performant, cluster-attached block storage costs per gigabyte. On top of that, local storage for frozen nodes can be reduced drastically, since only a comparatively small, shared cache is needed instead of full index copies, which also lowers the number of frozen nodes required in the first place.

In practice this math pays off most for very large datasets with long retention periods, such as multi-year log archives, where the absolute savings quickly add up to significant amounts. For smaller datasets the advantage becomes less pronounced, since the operational overhead of an additional tier, including its own repository management and cache sizing, needs to be weighed against the actual savings achieved.

8. Practical example: an ILM policy with a frozen phase for a log archive

A complete ILM policy for a log archive combines every phase covered so far consistently: hot for actively written, recent logs, warm for recently completed but occasionally queried indices, and finally frozen for anything older than roughly six months that practically only gets touched during audits or forensic investigations. The delete phase only kicks in after several years, matching the regulatory retention requirement.

This combination substantially lowers the overall cost of log retention without endangering the regulatory availability of the data: an audit team can access a six-year-old log entry at any time, they just have to accept a response time of a few seconds instead of milliseconds, which for this use case is an entirely reasonable trade-off.

"frozen": {
  "min_age": "180d",
  "actions": {
    "searchable_snapshot": {
      "snapshot_repository": "s3-backup-repo"
    }
  }
}

9. Snapshot dependency: why SLM retention must never touch frozen indices

A frozen index is technically just a view over an existing snapshot, not a standalone copy of the data. If that underlying snapshot gets deleted by an independent SLM retention rule while the frozen index still actively references it, future queries against that index fail, since the referenced segment data in object storage simply no longer exists. This coupling is frequently overlooked in practice, since snapshot management and frozen tier configuration are often owned by different teams.

The clean solution is to keep ILM's own transition into the frozen tier separate from a generic, independent SLM backup policy: ILM manages the snapshot it creates for the frozen tier itself and only removes it through the delete_searchable_snapshot action in the delete phase, together with the mounted index. A separate SLM repository used exclusively for regular backups, kept apart from the repository used for frozen snapshots, reliably prevents a misconfigured retention rule from accidentally removing still-needed frozen data.

10. Summary

11. FAQ: Frozen tier in Elasticsearch: the essentials at a glance