---
title: Add or remove data tiers in Elastic Cloud Hosted or Elastic Cloud Enterprise
description: Add or remove warm, cold, or frozen data tiers in Elastic Cloud Hosted or Elastic Cloud Enterprise, including safe removal with shard migration.
url: https://www.elastic.co/elastic/docs-builder/docs/4300/manage-data/lifecycle/data-tiers/manage-data-tiers-ech-ece
products:
- Elastic Cloud Enterprise
- Elastic Cloud Hosted
- Elastic Documentation
- Elasticsearch
applies_to:
- Elastic Cloud Hosted: Generally available
- Elastic Cloud Enterprise: Generally available
---
# Add or remove data tiers in Elastic Cloud Hosted or Elastic Cloud Enterprise
In Elastic Cloud Hosted and Elastic Cloud Enterprise, you add **warm**, **cold**, or **frozen** capacity from the deployment editor, and you remove a tier only after data can migrate away safely. The default configuration includes a shared tier for hot and content data; that tier is required and cannot be removed.
## Add a data tier
Review [Elasticsearch data tiers](https://www.elastic.co/elastic/docs-builder/docs/4300/manage-data/lifecycle/data-tiers) so you choose the right tier for your workload.
### Add capacity when you create a deployment
1. On the **Create deployment** page, click **Advanced Settings**.
2. Click **+ Add capacity** for any data tiers to add.
3. Click **Create deployment** at the bottom of the page to save your changes.
### Add capacity to an existing deployment
1. Log in to the [Elastic Cloud Console](https://cloud.elastic.co?page=docs&placement=docs-body) or ECE [Cloud UI](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui).
2. On the home page, find your deployment.
If you have many deployments, you can instead go to the **Hosted deployments** (Elastic Cloud Hosted) or **Deployments** (Elastic Cloud Enterprise) page. On that page, you can narrow your deployments by name, ID, or choose from several other filters.
3. Select **Manage**.
1. From the navigation menu, select **Edit**.
2. Click **+ Add capacity** for any data tiers to add.
3. Click **Save** at the bottom of the page to save your changes.
## Remove a data tier
Follow this section when you need to remove a warm, cold, or frozen tier from an Elastic Cloud Hosted or Elastic Cloud Enterprise deployment. The shared hot and content tier is required and cannot be removed.
The steps differ depending on whether the tier contains [regular indices](#non-searchable-snapshot-data-tier) or [searchable snapshot](#searchable-snapshot-data-tier) indices, which are common for cold or frozen tiers when using index lifecycle management (ILM).
If you plan to remove multiple tiers, remove them one at a time in this order: frozen, cold, then warm.
### Before you remove a data tier
Disabling a data tier, attempting to scale nodes down in size, reducing availability zones, or reverting an [autoscaling](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/autoscaling) change can all result in cluster instability, cluster inaccessibility, and even data corruption or loss in extreme cases.To avoid this, especially for [production environments](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/production-guidance), and in addition to making configuration changes to your indices and ILM as described in this guide:
- Review the disk size, CPU, JVM memory pressure, and other [performance metrics](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/monitor/access-performance-metrics-on-elastic-cloud) of your deployment **before** attempting to perform the scaling down action.
- Make sure that you have enough resources and [availability zones](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/production-guidance/availability-and-resilience) to handle your workloads after scaling down.
- Check that your [deployment hardware profile](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/deploy/elastic-cloud/ec-change-hardware-profile) (for Elastic Cloud Hosted) or [deployment template](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/deploy/cloud-enterprise/configure-deployment-templates) (for Elastic Cloud Enterprise) is correct for your business use case. For example, if you need to scale due to CPU pressure increases and are using a *Storage Optimized* hardware profile, consider switching to a *CPU Optimized* configuration instead.
- Review the [disk watermarks](https://www.elastic.co/elastic/docs-builder/docs/4300/troubleshoot/elasticsearch/fix-watermark-errors) and confirm that the nodes receiving the relocated shards have enough free disk space to remain below the low disk watermark.
Read [[https://www.elastic.co/cloud/shared-responsibility](https://www.elastic.co/cloud/shared-responsibility)](https://www.elastic.co/cloud/shared-responsibility) for additional details.
If in doubt, reach out to Support.
1. From your deployment page, filter the instance list by the data tier you want to disable and note the instance IDs.
1. Log in to the [Elastic Cloud Console](https://cloud.elastic.co?page=docs&placement=docs-body).
2. From the **Hosted deployments** page, select your deployment.
On the **Hosted deployments** page you can narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list.
3. Filter the list of instances by the data tier you want to disable.
Note the listed instance IDs. In this example, they are **Instance #2** and **Instance #3**.
1. [Log into the Cloud UI](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui).
2. From the **Deployments** page, select your deployment.
Narrow the list by name, ID, or choose from several other filters. To further define the list, use a combination of filters.
3. Filter the list of instances by the data tier you want to disable.
Note the listed instance IDs. In this example, they are **Instance #2** and **Instance #3**.
2. Check whether the instances in the tier you are removing hold shards from regular indices, [searchable snapshot indices](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/tools/snapshot-and-restore/searchable-snapshots), or both:
- **Warm tier:** This tier typically contains regular indices unless you have manually mounted searchable snapshots on it.
- **Cold tier:** This tier can contain regular indices or [fully mounted](/elastic/docs-builder/docs/4300/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-builder/docs/4300/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 contains only [partially mounted](/elastic/docs-builder/docs/4300/deploy-manage/tools/snapshot-and-restore/searchable-snapshots#partially-mounted) searchable snapshots. Check for standard lifecycle-managed indices:
```sh
GET /_cat/indices/partial-*,dlm-frozen-*?expand_wildcards=all
```
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.
3. Review the ILM policies and index templates that can send data to the tier you are removing, and plan the changes required so that they no longer use the tier. This prevents newly created indices and future lifecycle transitions from targeting a tier that is no longer available.
Depending on your configuration, plan to:
- Remove or update ILM phases and actions that move indices to the tier.
- Remove or move any `searchable_snapshot` action that mounts indices on the tier.
- If you use custom allocation filters in policies or templates, remove or update those that target the tier.
Make sure that your plan covers every affected policy and template.
To learn more about ILM or shard allocation filtering, refer to [Create your index lifecycle policy](https://www.elastic.co/elastic/docs-builder/docs/4300/manage-data/lifecycle/index-lifecycle-management/configure-lifecycle-policy), [Managing the index lifecycle](https://www.elastic.co/elastic/docs-builder/docs/4300/manage-data/lifecycle/index-lifecycle-management), and [Shard allocation filters](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/index-level-shard-allocation).
When you have identified the instances, determined which indices are on the tier, and planned the policy and template changes, continue with the procedure that matches that data:
- If the tier contains searchable snapshots, start with [Vacate tier instances containing searchable snapshots](#searchable-snapshot-data-tier).
- If the tier contains regular indices, or fully mounted searchable snapshots that you want to move while keeping them mounted, continue with [Prepare regular indices for tier removal](#non-searchable-snapshot-data-tier).
- After completing all applicable procedures, [disable the data tier](#disable-data-tier-ech-ece).
### Vacate tier instances containing searchable snapshots
This section explains how to vacate instances in a data tier that contains [searchable snapshot indices](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/tools/snapshot-and-restore/searchable-snapshots). How you proceed depends on the mount type:
- **[Partially mounted searchable snapshots](/elastic/docs-builder/docs/4300/deploy-manage/tools/snapshot-and-restore/searchable-snapshots#partially-mounted) on the frozen tier** cannot remain mounted after you disable the tier. For each index, either restore its data as a regular index or delete it.
- **[Fully mounted searchable snapshots](/elastic/docs-builder/docs/4300/deploy-manage/tools/snapshot-and-restore/searchable-snapshots#fully-mounted)** can remain mounted after you disable the tier. To keep them mounted, treat them like regular indices and continue to [Prepare regular indices for tier removal](#non-searchable-snapshot-data-tier). To restore their data as regular indices or delete them, follow the steps in this section for each index.
If any [DLM](https://www.elastic.co/elastic/docs-builder/docs/4300/manage-data/lifecycle/data-stream)-managed data stream uses `frozen_after`, remove this setting from the affected data stream lifecycles and index templates before disabling the frozen tier. This prevents backing indices, including restored indices, from being converted to partially mounted searchable snapshots again.
1. Apply the changes to ILM policies and index templates that you planned in [Before you remove a data tier](#before-you-remove-a-data-tier) so that they no longer create or route searchable snapshot indices to the tier you want to disable. These changes prevent new searchable snapshots from appearing while you process the existing ones.
2. For each partially mounted searchable snapshot, and for each fully mounted searchable snapshot that you do not want to keep mounted, select one of the following options:
- **Preserve the data as a regular index:** Follow [Restore searchable snapshot data to a regular index](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/tools/snapshot-and-restore/restore-searchable-snapshot-to-regular-index). Complete the restore, validation, alias or data stream update, and mounted index cleanup for one index before proceeding to the next.
- **Delete the data:** Record the source snapshot details before deleting the index:
```sh
GET //_settings?filter_path=**.index.store.snapshot.snapshot_name,**.index.store.snapshot.repository_name&expand_wildcards=all
DELETE /
```
If you no longer need the source snapshot, delete it after confirming that it contains no other data you need and that no other mounted index in this or another cluster depends on it:
After you delete the mounted index, deleting its source snapshot permanently removes the data if no other copy exists. Keep the source snapshot if you might need to restore the data later.
```sh
DELETE /_snapshot//
```
After processing all searchable snapshots, continue based on what remains on the tier:
- If the tier also contains regular indices, or fully mounted searchable snapshots that you want to move to another tier while keeping them mounted, continue to [Prepare regular indices for tier removal](#non-searchable-snapshot-data-tier).
- Otherwise, continue to [Disable the data tier](#disable-data-tier-ech-ece).
### Prepare regular indices for tier removal
Use this section to update shard allocation rules for regular indices before you disable the tier. Follow the same steps for fully mounted searchable snapshots that you want to keep mounted. Those snapshots use the same shard allocation rules as regular indices.
When you update the deployment, Elastic Cloud Hosted and Elastic Cloud Enterprise try to move all data from the instances that are removed. Before applying this change, make sure that the relevant shard allocation filters allow the data to move.
1. If you have not already done so, apply the changes to ILM policies and index templates that you planned in [Before you remove a data tier](#before-you-remove-a-data-tier). These changes prevent newly created indices and future lifecycle transitions from targeting the tier. They do not move indices already allocated there. The remaining steps update those indices and start relocating their shards.
Temporarily [stopping ILM](https://www.elastic.co/elastic/docs-builder/docs/4300/manage-data/lifecycle/index-lifecycle-management/start-stop-index-lifecycle-management) can prevent lifecycle transitions while you update the cluster configuration, but it affects every ILM-managed index in the cluster. It pauses actions such as rollover, migration, and deletion. On clusters with sustained ingestion, a long pause can cause indices on the hot tier to grow until the tier runs out of disk space.Keep ILM running unless you understand the effect on your workload. If you stop it, monitor the hot tier and restart ILM as soon as possible. Stopping ILM does not replace updating policies, templates, and index allocation settings.
2. Determine which shards are allocated to the instances you want to remove.
```sh
GET /_cat/shards?v&h=index,shard,prirep,state,node
```
Parse the output, looking for shards allocated to the instances you identified in [Before you remove a data tier](#before-you-remove-a-data-tier). `Instance #2` is shown as `instance-0000000002` in the output.
3. Check and update index allocation rules.
ILM and manual index configurations can use different [index-level shard allocation filters](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/index-level-shard-allocation) to control shard placement. For every index that has shards on the instances you are removing, check its allocation settings and complete the applicable steps:
```sh
GET /my-index/_settings
```
1. Update `_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. Elasticsearch allocates shards to the first tier in the list that has nodes in the cluster and considers later tiers only when none of the preceding tiers have any nodes.
Indices using this method have settings similar to the following example:
```sh
{
...
"routing": {
"allocation": {
"include": {
"_tier_preference": "data_warm,data_hot"
}
}
}
...
}
```
Before disabling the tier, update `_tier_preference` so that the tier where you want the data to move is the first available tier in the list. This change makes the destination tier preferred and starts relocating the shards before the deployment plan removes the tier.
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 disabled from the list. For example, when disabling 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 disabled. For example, when disabling 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"
}
}
}
}
```
Do not use the frozen tier as a fallback for regular indices or fully mounted searchable snapshots. It is reserved for partially mounted searchable snapshots.
2. Review custom allocation rules.
Some custom configurations use [index-level shard allocation filters](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/4300/reference/elasticsearch/index-settings/shard-allocation#index-allocation-settings) in addition to or instead of `_tier_preference`. These filters use `require`, `include`, or `exclude` rules with built-in or custom node attributes to control shard placement.
For example, the following settings use a custom `data` node attribute to require warm nodes:
```sh
{
...
"routing": {
"allocation": {
"require": {
"data": "warm"
}
}
}
...
}
```
A `require` rule is a hard constraint. If no nodes match it, the shard remains unassigned. To remove this requirement:
```sh
PUT /my-index/_settings
{
"index.routing.allocation.require.data": null
}
```
For each affected index, update or remove the custom filters that prevent allocation to the destination tier.
The following example removes all `_name`-based 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
}
```
If these allocation changes start a relocation process, wait until [shard allocation and recovery](https://www.elastic.co/elastic/docs-builder/docs/4300/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery) finish. Use `GET /_cat/allocation?v=true&s=node` to monitor the instances that the plan will remove. Shards might remain if you only removed a `require` rule because that change does not force them to move. The deployment plan relocates them when it disables the tier.If shards that you expect to move remain 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. Refer to [Using the cluster allocation API for troubleshooting](https://www.elastic.co/elastic/docs-builder/docs/4300/troubleshoot/elasticsearch/cluster-allocation-api-examples) for common examples. Common causes include [disk watermarks](https://www.elastic.co/elastic/docs-builder/docs/4300/troubleshoot/elasticsearch/fix-watermark-errors) or the [`index.routing.allocation.total_shards_per_node`](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/4300/reference/elasticsearch/index-settings/total-shards-per-node#total-shards-per-node) limit on the destination nodes.
After updating the allocation rules, continue to [Disable the data tier](#disable-data-tier-ech-ece).
### Disable the data tier
After completing all applicable procedures, confirm that any shard relocations triggered by the allocation changes have finished successfully. Then disable the data tier from the deployment editor.
1. Edit the deployment and disable the data tier.
If autoscaling is enabled, set the maximum size to `0` for the data tier to ensure autoscaling does not re-enable it.
Any remaining shards on the tier being disabled are re-allocated across the remaining cluster nodes while applying the deployment plan. Monitor shard allocation during the data migration phase to ensure all allocation rules have been correctly updated. If the plan fails to migrate data away from the tier, re-examine the allocation rules for the indices that remain on it.
2. Once the plan change completes, confirm that `GET /_cat/nodes?v` shows no nodes associated with the disabled tier and that `GET /_cluster/health` reports `green`.
3. Verify that ILM is running and that no indices report errors related to the disabled 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 disabled tier.
For indices in the `ERROR` step, resolve the underlying cause first. You can then force ILM to retry the failed step immediately:
```sh
POST //_ilm/retry
```
For guidance, refer to [Fix ILM errors](/elastic/docs-builder/docs/4300/troubleshoot/elasticsearch/index-lifecycle-management-errors#ilm-steps-errors).
## Related pages
- [Configure data tiers](/elastic/docs-builder/docs/4300/manage-data/lifecycle/data-tiers#configure-data-tiers)
- [Data tier index allocation](/elastic/docs-builder/docs/4300/manage-data/lifecycle/data-tiers#data-tier-allocation)
- [Index lifecycle management](https://www.elastic.co/elastic/docs-builder/docs/4300/manage-data/lifecycle/index-lifecycle-management)