Before learning the solution, it helps to feel the pain that created it.

Why time-based data is special

Many of the biggest Elasticsearch clusters in the world do not store product catalogs or user profiles. They store logs, metrics, security events, traces and clickstreams. This kind of data has a strong feature: it arrives constantly, every record has a timestamp, and old records almost never change. A web server writes a log line, and that line will never be edited again. It is only added, searched, and eventually deleted.

Because the data keeps arriving, the total size only goes up. A company that produces 200 gigabytes of logs a day holds about 6 terabytes after a month and more than 70 terabytes after a year. If every single byte lives on the fastest and priciest disks, the bill grows without limit.

Who actually reads old data?

When something breaks in production, people look at the last few minutes or hours. Dashboards refresh over the last 15 minutes. Alerts check the last five minutes. Only occasionally does someone ask what happened three months ago, perhaps during an audit, a security investigation, or a yearly comparison. So the newest data is read very often, and the oldest data is read very rarely.

That uneven reading pattern is the key insight. If some data is hit thousands of times more than other data, it makes no sense to give both the same expensive hardware. Treating all data equally means either you overspend on old data or you starve the new data of speed.

A few building blocks appear in every later chapter, so let us define them once, plainly.

Why shards matter so much for tiers

The unit that moves between hot, warm and cold machines is the shard. Elasticsearch never moves a single document. It moves whole shards from one node to another. Every decision in this tutorial, from sizing to lifecycle timing, comes back to how many shards you have, how big they are, and where they currently sit.

Why old indices become read-only in spirit

Because time-based data is append-only, once a day or a size limit has passed, Elasticsearch stops writing into that index and starts a fresh one. The old index is now effectively frozen in content, which makes it a perfect candidate to be squeezed, compressed, moved and protected. Without this natural break, tiering would be much harder.

A tier is simply a group of nodes with similar hardware, chosen for how often their data is used.

In a Hot-Warm-Cold architecture, you divide your cluster into groups of nodes. Each group has different hardware and a different purpose. New data lands on the first group. As time passes, Elasticsearch relocates it to the next group, then the next, until it is finally deleted or kept only as a cheap backup. The whole system is a conveyor belt that runs from expensive and fast to cheap and slow.

flowchart LR
  A["New data arrives"] --> B["Hot tier: fast disks, writes and frequent searches"]
  B --> C["Warm tier: fewer writes, still searched"]
  C --> D["Cold tier: rare searches, cheaper storage"]
  D --> E["Frozen tier: object storage, slowest and cheapest"]
  E --> F["Delete when retention ends"]
        

The tiers at a glance

There is also a fifth kind of data node called the content tier. It is for data that is not time-based, such as product catalogs, user records, or the internal system indices Elasticsearch keeps for itself. That data does not age out, so it stays put on the content tier and never joins the conveyor belt.

The hot tier is the front door and the busiest room in the building.

What the hot tier does

Every new document enters through the hot tier. Hot nodes hold the shards that are being actively written to, and they also serve the majority of searches, because the newest data is what people look at most. This tier therefore carries two heavy workloads at the same time: constant indexing and constant querying.

Indexing is expensive. For each incoming document, Elasticsearch analyzes text, builds inverted indexes, writes to a transaction log for safety, and periodically flushes tiny segments to disk. Then background merges combine those small segments into bigger ones. All of this creates heavy disk writes and heavy CPU use.

Why hot nodes need strong hardware

Fast storage is the most important requirement. Solid-state drives, and ideally NVMe drives, keep both writing and searching quick. Hot nodes also want good CPU counts, because indexing and searching are both parallel work, and generous memory, because the operating system uses free memory to cache the files that searches read most often.

In practice, a hot node holds relatively little data per machine compared to other tiers. A common rule of thumb in Elastic’s own sizing guidance is that hot nodes work well with a memory-to-disk ratio around one gigabyte of memory for roughly thirty gigabytes of data, although your own workload should decide the real number.

What lives in the hot tier

Only the current write index of each data stream is actually being written to. Older indices that have already been rolled over may still sit on hot nodes for a short while, because they are still queried constantly. Usually you keep data hot for a few days up to a week or two, depending on how far back your typical dashboards look.

Warm data is like last month’s paperwork in the cabinet by your desk.

What changes when data turns warm

Once an index is rolled over and its writing stops, it no longer needs the heavy write capacity of hot nodes. It still receives searches, but far fewer than fresh data. Moving it to the warm tier frees the hot nodes to focus on the new incoming flow, which is the whole point of separating the tiers.

Because warm indices are no longer being written to, Elasticsearch can prepare them for a long and quiet life. It can shrink them into fewer shards, merge their segments into one big segment per shard, mark them read-only, and lower their priority for recovery after failures. Each of these steps saves space, memory or cost.

Warm-phase housekeeping

Hardware for warm nodes

Warm nodes trade some speed for capacity. They still want decent storage, often SSD but sometimes high-quality spinning disks, and they hold much more data per node than hot ones. Elastic-style sizing advice often mentions a memory-to-disk ratio in the region of one to a hundred or more for this tier. Fewer CPU cores are needed, because there is almost no indexing work to do.

Cold data is the box in the basement: you know where it is and you can get it, but it is not a quick trip.

What the cold tier is for

Cold data is read only occasionally. Maybe an auditor asks for a quarter-old transaction trail, or a security analyst is investigating an intrusion that started months ago. The requirement is that the data still be searchable with the same tools, but nobody expects it to answer in milliseconds.

Cold nodes are built for low cost per stored gigabyte. They have large, cheaper disks and modest CPU, and a very high amount of data per node. Sizing guides often quote a memory-to-disk ratio in the hundreds to one for this tier. The trade-off is that searches over cold data are slower and can be more affected when many people query at the same time.

Saving money with fewer replicas

In a plain setup, cold indices still keep replica copies, which doubles their storage. Elasticsearch offers a smarter path: searchable snapshots. With this feature, a copy of the index is stored in a snapshot repository, which is cheap object storage or a shared file system, and the cold node mounts that snapshot as if it were a normal index. Because the durable copy already lives in the repository, the cluster can run with no replicas for that index and still recover if a node fails, by fetching the shard back from the snapshot.

The result is that the local storage needed drops to roughly half of a replicated setup. This is why many teams treat the cold tier as the place where a large bill turns into a modest one.

The frozen tier keeps almost nothing on local disks and reaches into cheap object storage only when a search demands it.

How frozen differs from cold

Cold nodes hold a full local copy of each shard. Frozen nodes do not. They use partially mounted searchable snapshots, which means the data stays in the snapshot repository, such as Amazon S3, Google Cloud Storage or Azure Blob Storage, and the node fetches only the pieces a search needs. Those pieces are kept in a local shared cache so repeated reads are quicker.

This changes the economics dramatically. A frozen node can look after far more data than its own disks could ever hold, because the disks only serve as a cache. Object storage is among the cheapest ways to keep bytes, so you can keep years of data searchable at a small fraction of the hot-tier price.

flowchart TD
  U["Search request"] --> F["Frozen node"]
  F --> C{"Needed data in local cache?"}
  C -->|Yes| R["Answer quickly from cache"]
  C -->|No| S["Fetch only needed pieces from object storage"]
  S --> K["Store pieces in shared cache"]
  K --> R
        

What you give up

Searches on frozen data can take seconds or even minutes for large ranges, because network fetches are slower than local disk reads. The tier works best when searches are narrow, for example a small time window or a specific filter, because Elasticsearch can skip whole shards whose time range cannot match. It is also friendly to asynchronous searches, where you submit a request and collect the result a little later.

A tier is not magic. It is just a role label on a node, plus a rule that says which indices may live on nodes with that label.

The role names

In Elasticsearch, every node carries one or more roles. The tier roles are named data_content, data_hot, data_warm, data_cold and data_frozen. If you give a node the role data_hot, it becomes a hot node. If you give another node data_warm, it becomes a warm node. There is also the older generic data role, which makes a node a member of all the tiers except frozen at once, which is convenient for small clusters but gives up the ability to separate them.

How Elasticsearch decides where a shard goes

Each index carries a setting called a tier preference. It is an ordered list such as “prefer cold, then warm, then hot”. Elasticsearch places the shard on a node that belongs to the first tier in the list that has an available node. If no cold node exists, it falls back to the warm tier, and so on. This fallback is a safety net that keeps a small or damaged cluster running rather than leaving shards homeless.

You rarely set this by hand. When a lifecycle policy enters a new phase, it updates the tier preference for you through a built-in migrate step. All you do is define the phases, and the cluster does the wiring.

A short history lesson

Before data tiers arrived in version 7.10, engineers built the same idea manually. They tagged nodes with custom attributes, often called box types with values like hot, warm and cold, and wrote allocation rules that said “this index must live on nodes tagged warm”. It worked, but it was easy to misconfigure and every team invented its own naming. Data tiers turned that hand-made pattern into a first-class feature with proper roles and automatic handling.

Having tiers is only half the story. Something must decide, automatically and on time, when each index moves.

What ILM is

Index Lifecycle Management, usually shortened to ILM, is the built-in system that moves indices through phases according to a policy you write once. A policy describes phases, the age at which each phase starts, and the actions to perform in each. After that, ILM checks your indices on a schedule and applies the next step whenever the conditions are met, so nobody needs to run manual jobs at midnight.

The phases

The actions

Inside phases, ILM runs actions. The most important ones are easy to understand once you know what each is for. Rollover starts a new index when the current one is too old or too big. Set priority decides which indices recover first after a restart, with hot data usually first. Shrink reduces the shard count, and force merge reduces the segment count. Read-only locks an index. Migrate moves shards to the right tier. Searchable snapshot converts an index to a snapshot-backed one. Downsample, available for time series data, replaces fine-grained old metrics with coarser summaries. Delete removes the data.

Understanding timing: min age

Each phase has a minimum age. It says how old an index must be before the phase may start. There is one subtle rule that surprises beginners: when rollover is used, the age is measured from the moment of rollover, not from the moment the index was first created. This makes sense, because an index that was actively receiving data for two days should not count those two days as time spent in the warm phase.

ILM does not act instantly. It checks indices on a schedule, by default every ten minutes. So an index might sit a few minutes past its target age before the next action begins. This is normal and rarely matters.

Follow one log line from birth to deletion to see every part of the system working together.

Data streams hide the complexity

Time-based data is normally written into a data stream. A data stream looks like one index to the outside world, so your applications and dashboards use a single name. Behind the scenes it is a chain of hidden backing indices. New documents always go to the newest backing index, called the write index, while earlier ones are read-only and available for searches.

An index template attached to the data stream tells Elasticsearch which lifecycle policy and which settings to use for each new backing index. When an index template and a lifecycle policy are wired together, every new backing index automatically inherits the whole lifecycle with no manual setup.

The journey of one document

flowchart TD
  W["Write index on hot node"] --> Q{"Size or age limit reached?"}
  Q -->|No| W
  Q -->|Yes| R["Rollover: create new write index"]
  R --> O["Old index enters warm phase after min age"]
  O --> CP["Cold phase after its min age"]
  CP --> FP["Frozen phase after its min age"]
  FP --> D["Delete phase at retention end"]
        

Why rollover by size beats rollover by day alone

If you create one index per day, a quiet Sunday produces a tiny index and a busy Monday produces a huge one. Tiny indices waste resources because every shard has fixed overhead, and huge shards are slow to move and recover. Rolling over when a primary shard reaches a target size, such as around fifty gigabytes, keeps shards evenly sized regardless of traffic. Adding a maximum age as a second condition makes sure quiet periods still roll over eventually.

Understanding what happens under the hood makes troubleshooting far less mysterious.

The allocation system

The elected master node keeps the cluster state, which is a map of every index, shard and node. When the tier preference of an index changes, the master runs its allocation logic. A set of rules called allocation deciders looks at each candidate node and answers yes or no: does this node have the right tier role, enough disk space, no conflicting copy of the same shard, and room under any limits?

If the answer is yes for a node, the master instructs it to start receiving the shard. The target node copies the shard’s files from the current holder. Only after the new copy is fully in sync does the master remove the old one. During the whole move, searches continue on the old copy, so users notice nothing.

Disk watermarks

Each node protects itself with disk watermarks. By default, when a node passes about eighty-five percent disk usage, the cluster stops sending it new shards. At about ninety percent, it starts moving shards away. At about ninety-five percent, the affected indices are made read-only to prevent complete disk exhaustion. On a hot node, this can quickly become a crisis if cold-bound data is not moved out fast enough, which is why lifecycle timing matters.

Shrink, merge and why they matter

Shrinking creates a new index with fewer primary shards by hard-linking or copying the files of the old one, so it is efficient but needs all shards of the source on one node first. That is why ILM briefly gathers shards together before shrinking. Force merge rewrites the segments of each shard into a small number, often just one. It temporarily needs extra disk space and causes I/O, which is why it belongs on warm nodes and not on the hot ones under load.

Recovery priority

When a cluster restarts or a node fails, many shards need to recover at once. Elasticsearch uses the priority setting on indices to decide the order. Hot indices get the highest priority because they are being written to and read the most. Warm indices get a middle value and cold a low value. This ensures the most valuable data becomes healthy first.

Good tiering is mostly good arithmetic done before you buy machines.

Start with the daily data volume

Begin by estimating how much raw data you will ingest per day. Then add the overhead of indexing, which depends on your mappings and the data itself and is often a noticeable fraction on top of raw size. Then multiply by the number of copies you keep, since a replica doubles the space. That gives you the daily storage cost on the hot tier.

Next, apply your retention rules. If data spends seven days hot, twenty-three days warm, sixty days cold and the rest frozen, you can compute the storage needed on each tier by multiplying the daily volume by the days spent there. Cold data using searchable snapshots needs no replicas locally, and frozen data needs only a cache, so their local disk needs are far smaller than their logical size suggests.

Choose a healthy shard size

A widely used guideline is to aim for shards between about ten and fifty gigabytes. Shards that are too small waste memory because every shard has a fixed overhead. Shards that are too large take a long time to move between nodes and to recover after failures. Another practical guideline is to keep the number of shards per node modest relative to the heap, with a common older rule of thumb being about twenty shards per gigabyte of heap as an upper bound. Treat these as starting points and measure your own cluster.

Memory-to-disk ratios

Each tier tolerates a different amount of data per gigabyte of memory. Hot nodes need generous memory for caching and heavy work, so they hold less data per node. Cold nodes serve infrequent queries and can hold many times more. Frozen nodes hold the most logical data, as they mostly rely on object storage. The exact numbers depend on workload, so use published guidance only as a first draft and validate with a realistic test.

A single search can span hot, warm, cold and frozen data without the user knowing.

The request path

A search request arrives at any node in the cluster, which then acts as the coordinating node for that request. It works out which shards must be consulted, sends the query to a copy of each, waits for the partial answers, merges them, and sends the final result back. It does not care which tier a shard is on. To the user, one request returns one merged answer.

sequenceDiagram
  participant U as User
  participant C as Coordinating node
  participant H as Hot shards
  participant W as Warm shards
  participant Z as Cold and frozen shards
  U->>C: Search for last 90 days
  C->>C: Find shards matching the time range
  C->>H: Query recent shards
  C->>W: Query warm shards
  C->>Z: Query cold and frozen shards
  H-->>C: Fast partial results
  W-->>C: Partial results
  Z-->>C: Slower partial results
  C-->>U: Merged final result
        

Why the slowest tier sets the pace

The coordinating node must wait for all involved shards, so the final answer is only as fast as the slowest shard it queried. If a dashboard covers the last ninety days, and a part of that range lives on cold or frozen tiers, the whole panel may load slowly. That is why dashboards for daily operations should look at short recent windows and leave long-range questions to targeted investigations.

Skipping shards that cannot match

Elasticsearch has a cheap pre-check step that asks each shard whether it could possibly contain matches, based on things like the time range stored for the data. Shards that cannot match are skipped before doing the expensive work. This is especially valuable with frozen data, where avoiding a network fetch saves a great deal of time. Well-chosen time filters in every query are therefore one of the best performance habits you can build.

Tiers save money, but they must never save money by losing data.

Replicas differ by tier

Hot data usually keeps at least one replica, because losing the only copy of fresh, valuable data is unacceptable and the replica helps share the search load. Warm data often keeps a replica too. Cold data using fully mounted searchable snapshots can run without replicas, since the snapshot is the safety copy. Frozen data depends entirely on its repository copy, so the repository itself must be protected.

Snapshot lifecycle management

A snapshot is a backup of one or more indices stored in a repository. Snapshot lifecycle management, often called SLM, is the scheduler that takes snapshots on a timetable and deletes old ones after a retention period. Even if you do not use searchable snapshots, regular snapshots of important indices are your protection against bigger disasters such as accidental deletion, a bad deployment, or losing an entire data center.

Availability zones

In cloud deployments, spreading nodes and replicas across separate availability zones protects against the failure of one zone. Elasticsearch supports awareness settings that keep a shard and its replica in different zones. For the hot tier, this is worth the small cost, because it keeps fresh data safe. For lower tiers, decisions balance cost and risk, and the snapshot repository often provides the durability.

Security follows the data wherever it moves, so it must be built into every tier equally.

Protect the data in motion and at rest

Every connection between nodes should use encrypted transport, and client connections should use encrypted HTTP. When shards move between tiers, they travel across the network, so unencrypted internal traffic would expose data during every relocation. Disks on all tiers, including cold and frozen cache disks, should use encryption at rest, provided by the operating system, the storage layer or the cloud platform.

Protect the snapshot repository

The repository holds a full copy of your data, so it deserves the same care as the cluster. Restrict who can read or delete objects in the bucket using the cloud provider’s access controls, use dedicated credentials for the cluster, enable versioning or object lock where possible, and keep a separate repository for backups so one mistake cannot wipe both.

Control who can see what

Elasticsearch supports role-based access control. Roles can be limited to certain indices, certain fields and even certain documents. A team that should only view application logs can be restricted from seeing security logs, no matter which tier those logs currently live on. Also restrict who may change lifecycle policies, because a wrongly edited policy can delete data early or keep it far too long. Enable audit logging so you can trace who changed what.

A tiered cluster is a moving system, so you need to watch both the machines and the movement.

What to watch on every tier

Useful diagnostic tools

Elasticsearch includes a lifecycle explain feature that tells you, for each index, which phase and step it is in and, if it is stuck, the error message. It also has an allocation explain feature that tells you why a specific shard is not being placed on a node, listing each decider’s reason. Together with the standard cluster health and node statistics views, these answer most “why is my data not moving” questions. Kibana’s stack monitoring pages show the same information in graphs.

Typical stuck situations

Patterns that work in many clusters, and mistakes that show up again and again.

Patterns worth copying

Anti-patterns to avoid

A checklist of habits that separate calm clusters from stressful ones.

These are illustrative examples that show how different organizations might shape their tiers.

The exact numbers above are examples, not rules. Your own values should come from how your users actually search and from the retention required by your business and legal teams.

No architecture is free. Here is an honest summary of what you gain and what you accept.

When you might not need it

If your cluster is small, your data is modest, or your data is not time-based, a single tier may be perfectly fine. A product search index, for example, holds data that does not age, and it belongs on the content tier. Tiering pays off when data is large, grows steadily, and has a clear pattern where old data is read much less often than new data.

No. It is a way of organizing normal Elasticsearch nodes using roles and lifecycle policies. Everything is part of the same cluster.

Not at all. Many teams start with hot and warm only. Add cold and frozen when your volume and retention needs justify them.

The older approach used custom node attributes and manual allocation rules. Data tiers replaced it with built-in roles and automatic handling, which is simpler and less error-prone.

Yes. The coordinating node queries shards wherever they live and merges the answers. The response is limited by the slowest tier involved.

Cold nodes keep a full local copy of the data, while frozen nodes keep the data in object storage and cache only the pieces that searches need. Frozen is cheaper and slower.

Common reasons are that the policy is not attached, rollover has not happened, no warm node has space, or an earlier step failed. Use the lifecycle explain feature to see the exact step and error.

It is where non-time-based data lives, such as catalogs and system indices. That data does not age, so it does not move along the conveyor belt.

No. Searches continue on the existing copy while the new copy is built, and the old one is removed only when the new one is ready.

Long enough to cover the time range most searches use. For many log workloads that is a few days to two weeks, but measure your own users.

Yes, you still want a protected repository and ideally a separate backup repository. The repository copy is your safety net, so it must itself be safe.

Yes, but existing indices keep the policy version they started with until you move them to the updated one, so plan how the change reaches older data.

No. It replaces detailed old metrics with summaries, so you keep the shape of the data at lower resolution and lower cost.

Hot-Warm-Cold architecture is the practical answer to a simple truth: not all data deserves the same treatment. Fresh data is written and read constantly, so it sits on fast, expensive hot nodes. As it ages it moves to warm, cold and frozen tiers, each cheaper and slower than the last, until it is deleted. Lifecycle policies automate the journey, data streams and rollover keep shards well sized, and searchable snapshots let old data stay reachable at a small cost. Get the tier hardware, shard sizes and retention rules right, and you get a cluster that is fast where speed matters and thrifty everywhere else.