---
title: Configure data tiers for self-managed and Elastic Cloud on Kubernetes deployments
description: Assign or remove Elasticsearch data tier roles on self-managed hosts (elasticsearch.yml) or on Elastic Cloud on Kubernetes (ECK node set config).
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/manage-data/lifecycle/data-tiers/manage-data-tiers-self-managed-eck
products:
  - Elastic Cloud on Kubernetes
  - Elasticsearch
applies_to:
  - Elastic Cloud on Kubernetes: Generally available
  - Self-managed Elastic deployments: Generally available
---

# Configure data tiers for self-managed and Elastic Cloud on Kubernetes deployments
Whether you operate Elasticsearch on your own infrastructure or on Kubernetes with Elastic Cloud on Kubernetes, data tiers are expressed through each node’s [data role](/elastic/docs-content/pull/8213/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles#data-node-role). You choose which tiers the cluster offers by assigning the corresponding `data_*` roles to nodes or to ECK node sets.

## Before you begin

- Review [Elasticsearch data tiers](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/manage-data/lifecycle/data-tiers) so you match tiers to your workload.
- Understand how [node roles](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles) map to hardware and allocation for each tier.


## Assign data tier roles on self-managed hosts

<applies-to>
  - Self-managed Elastic deployments: Generally available
</applies-to>

1. For each node, decide which data tier or tiers it should participate in (for example `data_hot`, `data_warm`, `data_cold`, `data_frozen`, or `data_content`).
2. Set `node.roles` in that node’s [`elasticsearch.yml`](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/stack-settings) to include the corresponding `data_*` roles (and any other roles the node should have, such as `ingest` or `master`).
3. Restart the node or apply your configuration rollout process so the new roles take effect.

For example, the highest-performance nodes in a cluster might be assigned to both the hot and content tiers:
```yaml
node.roles: ["data_hot", "data_content"]
```

<note>
  We recommend you use [dedicated nodes](/elastic/docs-content/pull/8213/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles#data-frozen-node) in the frozen tier.
</note>


## Assign data tier roles in Elastic Cloud on Kubernetes

<applies-to>
  - Elastic Cloud on Kubernetes: Generally available
</applies-to>

Elasticsearch settings that you normally put in `elasticsearch.yml` are set for each `nodeSet` under `spec.nodeSets[?].config` in the Elasticsearch resource manifest. Assign `node.roles` there to define each group of pods’ tiers. For example, you can assign the following tiers:
```yaml
spec:
  nodeSets:
  - name: hot-content
    count: 3
    config:
      node.roles: ["data_hot", "data_content", "ingest"]
```

Some settings are [managed by Elastic Cloud on Kubernetes](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/deploy/cloud-on-k8s/settings-managed-by-eck); avoid overriding those. For the full mapping between manifest structure and Elasticsearch configuration, see [Node configuration](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/deploy/cloud-on-k8s/node-configuration).
<note>
  On Elastic Cloud on Kubernetes, node set and scaling changes try to relocate shards from nodes that are removed, subject to allocation rules, capacity, and [disk watermarks](https://docs-v3-preview.elastic.dev/elastic/elasticsearch/tree/main/reference/elasticsearch/configuration-reference/cluster-level-shard-allocation-routing-settings#disk-based-shard-allocation) on the destination nodes. For more information, refer to the [Elastic Cloud on Kubernetes](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/deploy/cloud-on-k8s) documentation.
</note>


## Remove a data tier

Follow this section when you need to remove the warm, cold, or frozen tier from a self-managed or Elastic Cloud on Kubernetes deployment. The hot and content tiers are required and cannot be removed. If you remove nodes assigned the `data_hot` or `data_content` role, ensure that the corresponding role remains assigned to other nodes.
The steps differ depending on whether the tier holds [regular indices](#remove-regular-indices-self-managed-eck) or [searchable snapshot](#remove-searchable-snapshots-self-managed-eck) indices (typical for cold or frozen when using index lifecycle management (ILM)).

### Before you remove a data tier

<important>
  Removing a data tier reduces the cluster's capacity. This can cause cluster instability, inaccessibility, or data loss if the remaining nodes cannot absorb the data from the removed tier.Before proceeding:
  - Confirm that the remaining tiers have enough disk space, CPU, and memory to absorb the data and workload from the tier you are removing.
  - Review [disk watermarks](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/troubleshoot/elasticsearch/fix-watermark-errors) and ensure the remaining nodes are not close to their limits.
</important>

1. Identify which nodes belong to the data tier you want to remove:
   ```sh
   GET /_nodes?filter_path=nodes.*.name,nodes.*.ip,nodes.*.roles
   ```
   Note the names of the nodes with the corresponding `data_*` role.
   <tip>
   For Elastic Cloud on Kubernetes, also identify every `nodeSet` in your Elasticsearch manifest that has the `data_*` role associated with the tier you want to remove.
   </tip>
2. Check whether the tier you are removing holds regular indices, [searchable snapshots](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/tools/snapshot-and-restore/searchable-snapshots), or both. Use the guidance for the tier you are removing:
   - **Warm tier:** This tier typically holds regular indices. Follow [Remove a tier with regular indices](#remove-regular-indices-self-managed-eck) unless you have manually mounted searchable snapshots on the tier.
- **Cold tier:** This tier can hold regular indices or [fully mounted](/elastic/docs-content/pull/8213/deploy-manage/tools/snapshot-and-restore/searchable-snapshots#fully-mounted) searchable snapshots. Check for standard ILM-managed searchable snapshot indices:
  ```sh
  GET /_cat/indices/restored-*?expand_wildcards=all
  ```
  For each returned index, check its [current data tier preference](/elastic/docs-content/pull/8213/manage-data/lifecycle/data-tiers#data-tier-allocation-value) to determine whether it is on the tier you are removing.
  Exclude any fully mounted indices associated with the hot tier from the removal inventory. The hot tier is required and is not removed by this procedure.
- **Frozen tier:** This tier only holds [partially mounted](/elastic/docs-content/pull/8213/deploy-manage/tools/snapshot-and-restore/searchable-snapshots#partially-mounted) searchable snapshots. Check for standard ILM-managed indices:
  ```sh
  GET /_cat/indices/partial-*?expand_wildcards=all
  ```
   <note>
   Manually mounted searchable snapshots might not use the standard `restored-*` or `partial-*` prefixes. If you mounted snapshots manually, adapt the index names or patterns in these requests to match your configuration.
   </note>
   - If the tier does not contain any searchable snapshot indices, follow [Remove a tier with regular indices](#remove-regular-indices-self-managed-eck).
- If the tier contains searchable snapshot indices, review [Remove a tier with searchable snapshots](#remove-searchable-snapshots-self-managed-eck) and select the appropriate procedure based on how the indices are mounted. If regular indices also remain, restore or move the searchable snapshot indices first, but do not remove the nodes. Then return to the regular indices procedure.

To learn more about ILM or shard allocation filtering, refer to [Create your index lifecycle policy](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/manage-data/lifecycle/index-lifecycle-management/configure-lifecycle-policy), [Managing the index lifecycle](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/manage-data/lifecycle/index-lifecycle-management), and [Shard allocation filters](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/index-level-shard-allocation).

### Remove a tier with regular indices

This section covers the removal of a tier that holds regular indices. The goal is to ensure all shard allocation rules allow the data to move to other tiers, and then vacate and remove the nodes. You also need to temporarily stop ILM to prevent new indices from being routed to the tier while you work.
<note>
  If the tier also holds [fully mounted](/elastic/docs-content/pull/8213/deploy-manage/tools/snapshot-and-restore/searchable-snapshots#fully-mounted) searchable snapshots, you have two options:
  - **To keep them as searchable snapshots on another tier**: apply the same steps in this section. Fully mounted searchable snapshots follow the same shard placement rules as regular indices and can be moved by updating their allocation settings.
  - **To restore them to regular indices on another tier**: follow [Remove a tier with searchable snapshots](#remove-searchable-snapshots-self-managed-eck) to restore the indices and delete the original searchable snapshot indices and source snapshots, but do not remove the nodes yet. Then return to this section to move any regular indices and remove the nodes.
</note>

1. Stop ILM to prevent new indices from being routed to the tier while you work.
   ```sh
   POST /_ilm/stop
   GET /_ilm/status
   ```
   Wait until `operation_mode` is `STOPPED` before proceeding.
2. Determine which shards are allocated to the nodes you want to remove.
   ```sh
   GET /_cat/shards?v&h=index,shard,prirep,state,node
   ```
   Filter the output by the node names you identified in [Before you remove a data tier](#before-remove-data-tier-self-managed-eck).
3. Check and update index allocation rules.
   ILM and manual index configurations use different [index-level shard allocation filters](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/index-level-shard-allocation) to control shard placement. For every index that has shards on the nodes you are removing, check its allocation settings and apply the relevant substeps:
   ```sh
   GET /my-index/_settings
   ```
   1. `_tier_preference` based rules.
   Data tier-based ILM policies use `index.routing.allocation.include._tier_preference` to express shard placement as an ordered list of preferred tiers. Indices using this method have settings similar to the following example:
   ```sh
   {
   ...
       "routing": {
           "allocation": {
               "include": {
                   "_tier_preference": "data_warm,data_hot" 
               }
           }
       }
   ...
   }
   ```
   Before manually vacating the nodes, update `_tier_preference` so that the tier where you want the data to move is the first available tier in the list. This allows Elasticsearch to begin relocating the shards to that tier before the nodes are removed.
   Update the setting based on where you want to move the data:
   - To move the data to an existing fallback tier, remove the tier being removed from the list. For example, when removing the warm tier, change `data_warm,data_hot` to `data_hot`.
- To move the data to a later lifecycle tier, add that tier before the tier being removed. For example, when removing the warm tier, change `data_warm,data_hot` to `data_cold,data_warm,data_hot`.
   The following example moves data from warm to cold:
   ```sh
   PUT /my-index/_settings
   {
       "routing": {
         "allocation": {
           "include": {
               "_tier_preference": "data_cold,data_warm,data_hot" 
           }
         }
       }
   }
   ```
   <note>
   Do not use the frozen tier as a fallback for regular indices. It is reserved for partially mounted searchable snapshots.
   </note>
2. Update node attribute allocation requirement rules.
   Older ILM policies and some custom configurations use `index.routing.allocation.require` to pin shards to nodes with a specific attribute. Indices using this method have settings similar to the following example:
   ```sh
   {
   ...
       "routing": {
           "allocation": {
               "require": {
                   "data": "warm"
               }
           }
       }
   ...
   }
   ```
   Unlike `_tier_preference`, a `require` rule is a hard constraint: if the required nodes are gone, the shard becomes unassigned and Elasticsearch cannot move it automatically. You must remove or redirect these rules before vacating the nodes. To remove the attribute requirement:
   ```sh
   PUT /my-index/_settings
   {
       "routing": {
         "allocation": {
           "require": {
               "data": null
           }
         }
       }
   }
   ```
   Alternatively, redirect the index to a different tier by setting `require` to the desired attribute value. For example, to move an index to nodes with `data` attribute of `cold`:
   ```sh
   PUT /my-index/_settings
   {
       "routing": {
         "allocation": {
           "require": {
               "data": "cold"
           }
         }
       }
   }
   ```
   Adjust the `data` value to match the [custom node attributes](https://docs-v3-preview.elastic.dev/elastic/elasticsearch/tree/main/reference/elasticsearch/configuration-reference/node-settings#custom-node-attributes) and [index-level shard allocation filters](https://docs-v3-preview.elastic.dev/elastic/elasticsearch/tree/main/reference/elasticsearch/index-settings/shard-allocation) your indices already use. You cannot send regular indices to the frozen tier.
   If you remove the `require` rule, Elasticsearch does not re-allocate shards immediately. They move when you vacate the nodes in the next step. If you redirect `require` to a different attribute value, re-allocation starts immediately.
3. Review other custom allocation rules.
   If indices on the nodes being removed use other [index-level shard allocation filters](https://docs-v3-preview.elastic.dev/elastic/elasticsearch/tree/main/reference/elasticsearch/index-settings/shard-allocation#index-allocation-settings), such as `include`, `exclude`, or `require` configurations not covered earlier, update or remove any rules that would prevent shards from moving to the intended nodes. You can preserve rules unrelated to the tier removal.
   The following example removes all `_name`-based custom allocation filters from an index:
   ```sh
   PUT /my-index/_settings
   {
     "index.routing.allocation.require._name": null,
     "index.routing.allocation.include._name": null,
     "index.routing.allocation.exclude._name": null
   }
   ```
4. Vacate the nodes.
   <note>
   On Elastic Cloud on Kubernetes, removing a `nodeSet` from the Elasticsearch manifest causes Elastic Cloud on Kubernetes to migrate data away from its nodes before removing the underlying StatefulSet, as described in [Cluster upgrade patterns](/elastic/docs-content/pull/8213/deploy-manage/deploy/cloud-on-k8s/nodes-orchestration#k8s-upgrade-patterns). If the allocation rules in the previous step are correctly updated, you can skip the manual vacate and proceed directly to removing the `nodeSet`. However, we recommend completing the manual vacate first because it gives you more control and visibility over the relocation process.
   </note>
   To vacate the nodes manually, exclude them from shard allocation by name. Elasticsearch then relocates their remaining shards to other eligible nodes:
   ```sh
   PUT /_cluster/settings
   {
     "persistent": {
       "cluster.routing.allocation.exclude._name": "<node-name-1>,<node-name-2>" 
     }
   }
   ```
   <important>
   Wait until `GET /_cat/allocation?v=true&s=node` shows that no shards remain on those nodes before proceeding. Updating settings starts the relocation process, but you must wait until [shard allocation and recovery](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery) finish. If shards stay on the original tier, use the [cluster allocation explain](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-allocation-explain) API to determine the cause. Common causes include [disk watermarks](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/troubleshoot/elasticsearch/fix-watermark-errors) or [`index.routing.allocation.total_shards_per_node`](https://docs-v3-preview.elastic.dev/elastic/elasticsearch/tree/main/reference/elasticsearch/index-settings/total-shards-per-node#total-shards-per-node) limit reached on the destination nodes.
   </important>
5. Remove the nodes.
   After confirming that no shards remain on the nodes, remove them using the instructions for your deployment type.
   <applies-switch>
   <applies-item title="self:" applies-to="Self-managed Elastic deployments: Generally available">
   Stop the Elasticsearch service on each node to be removed and decommission the host. For step-by-step instructions, refer to [Add or remove Elasticsearch nodes](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/maintenance/add-and-remove-elasticsearch-nodes).
   </applies-item>

   <applies-item title="eck:" applies-to="Elastic Cloud on Kubernetes: Generally available">
   If an `ElasticsearchAutoscaler` policy manages the `nodeSet`, remove the matching policy before removing the `nodeSet` or setting its `count` to `0`. Otherwise, autoscaling might change the `nodeSet` count while you complete this procedure. Refer to [Autoscaling in ECK](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/autoscaling/autoscaling-in-eck).Remove the `nodeSet` from your Elasticsearch manifest, or set its `count` to `0`. If you skipped the manual vacate, Elastic Cloud on Kubernetes migrates the remaining data before safely stopping the pods.
   </applies-item>
   </applies-switch>
6. Wait until `GET /_cat/nodes?v` shows no nodes from the removed tier remaining in the cluster.
   If you ran the manual vacate, remove the deleted node names from the exclusion rule only after the nodes have left the cluster. Restore any `_name` exclusions that existed before the vacate. If none existed, clear the setting:
   ```sh
   PUT /_cluster/settings
   {
     "persistent": {
       "cluster.routing.allocation.exclude._name": null
     }
   }
   ```
   Confirm that `GET /_cluster/health` reports `green`.
7. Review your ILM policies and consider removing references to the deleted tier to keep them consistent with the cluster topology. This is especially important in older clusters where ILM uses node-attribute-based allocation, as those policies cannot run phases that target nodes that no longer exist.
   For guidance on updating policies, refer to [Configure a lifecycle policy](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/manage-data/lifecycle/index-lifecycle-management/configure-lifecycle-policy).
8. Re-enable ILM:
   ```sh
   POST /_ilm/start
   ```
9. Verify that ILM is running and that no indices report errors related to the removed tier:
   ```sh
   GET /_ilm/status
   GET /_all/_ilm/explain?human=true&expand_wildcards=all&only_errors=true
   ```
   Confirm that `operation_mode` is `RUNNING`. Investigate any reported errors and verify that no policy still attempts to allocate data to the removed tier.


### Remove a tier with searchable snapshots

This section explains how to remove a data tier that contains [searchable snapshot indices](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/tools/snapshot-and-restore/searchable-snapshots). Your options for preserving the data depend on how the indices are mounted:
- **[Partially mounted searchable snapshots](/elastic/docs-content/pull/8213/deploy-manage/tools/snapshot-and-restore/searchable-snapshots#partially-mounted) on the frozen tier:** The only way to keep the data available as indices when removing the frozen tier is to restore all partially mounted indices as regular indices on another tier. Follow the steps in this section to restore the indices and remove the original searchable snapshot indices and source snapshots.
- **[Fully mounted searchable snapshots](/elastic/docs-content/pull/8213/deploy-manage/tools/snapshot-and-restore/searchable-snapshots#fully-mounted) on the cold tier:** To keep the indices as searchable snapshots, move them to another tier by following [Remove a tier with regular indices](#remove-regular-indices-self-managed-eck). This works because fully mounted indices follow the same shard allocation rules as regular indices. Alternatively, follow the steps in this section to restore them as regular indices on another tier.

If you do not need to preserve the data, delete the searchable snapshot indices before removing the tier.
The following procedure captures the snapshot metadata, restores the indices as regular indices, removes the original searchable snapshot indices and source snapshots, and then removes the tier's nodes.
<note>
  The [ILM `searchable_snapshot` action](https://docs-v3-preview.elastic.dev/elastic/elasticsearch/tree/main/reference/elasticsearch/index-lifecycle-actions/ilm-searchable-snapshot) typically prefixes the resulting index with `restored-*` for fully mounted indices in the hot or cold phase and `partial-*` for partially mounted indices in the frozen phase. Manually mounted searchable snapshots might not use these prefixes. In the following steps, adapt the index names and patterns to match the indices on the tier you are removing.
</note>

1. Stop ILM to prevent data from migrating to the phase you intend to remove while you work.
   ```sh
   POST /_ilm/stop
   GET /_ilm/status
   ```
   Wait until `operation_mode` is `STOPPED` before proceeding.
2. Using the searchable snapshot indices identified in [Before you remove a data tier](#before-remove-data-tier-self-managed-eck), create an inventory of the indices to restore. For standard ILM configurations, you can use `restored-*` for the cold tier and `partial-*` for the frozen tier. For custom configurations, use individual index names or a pattern that matches the relevant indices. For each index, record the index name, source snapshot name, and snapshot repository.
   ```sh
   GET /<searchable-snapshot-index-name-or-pattern>/_settings?filter_path=**.index.store.snapshot.snapshot_name,**.index.store.snapshot.repository_name&expand_wildcards=all
   ```
3. For each index in the inventory, remove any aliases that were applied to the searchable snapshot index.
   ```sh
   POST /_aliases
   {
     "actions": [
       {
         "remove": {
           "index": "<searchable-snapshot-index-name>",
           "alias": "<alias-name>"
         }
       }
     ]
   }
   ```
   <note>
   If you use a data stream, you can skip this step.
   </note>
4. Restore each index in the inventory from its source snapshot.
   The restore request creates a regular index on the remaining tiers and prevents it from inheriting the previous ILM policy and rollover alias:
   ```sh
   POST /_snapshot/<snapshot_repository_name>/<searchable_snapshot_name>/_restore 
   {
     "indices": "*", 
     "index_settings": {
       "index.routing.allocation.include._tier_preference": "<data_tiers>", 
       "index.number_of_replicas": 1, 
       "index.lifecycle.name": null,
       "index.lifecycle.rollover_alias": null
     }
   }
   ```
   To manage the restored index with a different ILM policy, apply the policy after the restore and configure its rollover alias if required. Refer to [Switch lifecycle policies](/elastic/docs-content/pull/8213/manage-data/lifecycle/index-lifecycle-management/policy-updates#switch-lifecycle-policies).
5. Once all snapshots are restored, use `GET /_cat/indices/<index-pattern>?v=true` to check that the restored indices are `green` and are correctly reflecting the expected `docs.count` and `store.size` values.
   If you are using a data stream, you might need to use `GET /_data_stream/<data-stream-name>` to get the list of the backing indices, and then specify them by using `GET /_cat/indices/<backing-index-name>?v=true` to check. When you restore the backing indices of a data stream, some [considerations](/elastic/docs-content/pull/8213/deploy-manage/tools/snapshot-and-restore/restore-snapshot#considerations) apply, and you might need to manually add the restored indices into your data stream or re-create your data stream.
   
6. After verifying each restored index, delete the corresponding original searchable snapshot index from the inventory.
   ```sh
   DELETE /<searchable-snapshot-index-name>
   ```
7. Delete the source snapshots recorded in the inventory:
   <warning>
   A snapshot created by the ILM `searchable_snapshot` action contains only the managed index, so deleting it after successfully restoring and verifying that index does not affect other indices. This guarantee does not apply to manually created snapshots, which can contain multiple indices or support other mounted searchable snapshot indices. Before deleting a manually created snapshot, verify that it contains no other data you need and supports no other mounted indices.
   </warning>
   ```sh
   DELETE /_snapshot/<snapshot_repository_name>/<searchable_snapshot_name>
   ```
   <tip>
   You can also delete multiple snapshots at once in Kibana. Find **Snapshot and Restore** in the navigation menu or use the [global search field](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/explore-analyze/find-and-organize/find-apps-and-objects), select the **Snapshots** tab, select the snapshots you want to delete, and click **Delete**.
   </tip>
8. Confirm that no shards remain on the data nodes you wish to remove using `GET /_cat/allocation?v=true&s=node`.
9. Remove the nodes.
   After confirming that no shards remain on the nodes, remove them using the instructions for your deployment type.
   <applies-switch>
   <applies-item title="self:" applies-to="Self-managed Elastic deployments: Generally available">
   Stop the Elasticsearch service on each node to be removed and decommission the host. For step-by-step instructions, refer to [Add or remove Elasticsearch nodes](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/maintenance/add-and-remove-elasticsearch-nodes).
   </applies-item>

   <applies-item title="eck:" applies-to="Elastic Cloud on Kubernetes: Generally available">
   If an `ElasticsearchAutoscaler` policy manages the `nodeSet`, remove the matching policy before removing the `nodeSet` or setting its `count` to `0`. Otherwise, autoscaling might change the `nodeSet` count while you complete this procedure. Refer to [Autoscaling in ECK](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/autoscaling/autoscaling-in-eck).Remove the `nodeSet` from your Elasticsearch manifest, or set its `count` to `0`. Elastic Cloud on Kubernetes safely drains and stops the pods.
   </applies-item>
   </applies-switch>
10. Confirm that `GET /_cluster/health` reports `green` and that `GET /_cat/nodes?v` shows no nodes from the removed tier remaining in the cluster.
11. Review your ILM policies and update any phases that target the removed tier. For example, when removing the frozen tier, remove the `frozen` phase. If you want future indices to continue using searchable snapshots, configure the `searchable_snapshot` action in an appropriate remaining phase. Also update any allocation rules that reference the removed tier.
   For guidance on updating policies, refer to [Configure a lifecycle policy](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/manage-data/lifecycle/index-lifecycle-management/configure-lifecycle-policy).
12. Re-enable ILM:
   ```sh
   POST /_ilm/start
   ```
13. Verify that ILM is running and that no indices report errors related to the removed tier:
   ```sh
   GET /_ilm/status
   GET /_all/_ilm/explain?human=true&expand_wildcards=all&only_errors=true
   ```
   Confirm that `operation_mode` is `RUNNING`. Investigate any reported errors and verify that no policy still attempts to allocate data to the removed tier.


## Related pages

- [Configure data tiers](/elastic/docs-content/pull/8213/manage-data/lifecycle/data-tiers#configure-data-tiers)
- [Data tier index allocation](/elastic/docs-content/pull/8213/manage-data/lifecycle/data-tiers#data-tier-allocation)
- [Add or remove Elasticsearch nodes](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8213/deploy-manage/maintenance/add-and-remove-elasticsearch-nodes)