# Scaling
The amount of data your application needs to process is seldom static. It increases and decreases as your business grows or experiences normal fluctuations in demand. If you self-manage your applications, you need to provision sufficient hardware for your demand peaks, which can be expensive. By using MemoryDB you can scale to meet current demand, paying only for what you use.
The following helps you find the correct topic for the scaling actions that you want to perform.
**Scaling MemoryDB**
| Action | MemoryDB |
| --- | --- |
| Scaling out | [Online resharding for MemoryDB](cluster-resharding-online.md) |
| Changing node types | [Online vertical scaling by modifying node type](cluster-vertical-scaling.md) |
| Changing the number of shards | [Scaling MemoryDB clusters](scaling-cluster.md) |
# Scaling MemoryDB clusters
As demand on your clusters changes, you might decide to improve performance or reduce costs by changing the number of shards in your MemoryDB cluster. We recommend using online horizontal scaling to do so, because it allows your cluster to continue serving requests during the scaling process.
Conditions under which you might decide to rescale your cluster include the following:
+ **Memory pressure:**
If the nodes in your cluster are under memory pressure, you might decide to scale out so that you have more resources to better store data and serve requests.
You can determine whether your nodes are under memory pressure by monitoring the following metrics: *FreeableMemory*, *SwapUsage*, and *BytesUsedForMemoryDB*.
+ **CPU or network bottleneck:**
If latency/throughput issues are plaguing your cluster, you might need to scale out to resolve the issues.
You can monitor your latency and throughput levels by monitoring the following metrics: *CPUUtilization*, *NetworkBytesIn*, *NetworkBytesOut*, *CurrConnections*, and *NewConnections*.
+ **Your cluster is over-scaled:**
Current demand on your cluster is such that scaling in doesn't hurt performance and reduces your costs.
You can monitor your cluster's use to determine whether or not you can safely scale in using the following metrics: *FreeableMemory*, *SwapUsage*, *BytesUsedForMemoryDB*, *CPUUtilization*, *NetworkBytesIn*, *NetworkBytesOut*, *CurrConnections*, and *NewConnections*.
**Performance Impact of Scaling**
When you scale using the offline process, your cluster is offline for a significant portion of the process and thus unable to serve requests. When you scale using the online method, because scaling is a compute-intensive operation, there is some degradation in performance, nevertheless, your cluster continues to serve requests throughout the scaling operation. How much degradation you experience depends upon your normal CPU utilization and your data.
There are two ways to scale your MemoryDB cluster; horizontal and vertical scaling.
+ Horizontal scaling allows you to change the number of shards in the cluster by adding or removing shards. The online resharding process allows scaling in/out while the cluster continues serving incoming requests.
+ Vertical Scaling - Change the node type to resize the cluster. The online vertical scaling allows scaling up/down while the cluster continues serving incoming requests.
If you are reducing the size and memory capacity of the cluster, by either scaling in or scaling down, ensure that the new configuration has sufficient memory for your data and engine overhead.
# Offline resharding for MemoryDB
The main advantage you get from offline shard reconfiguration is that you can do more than merely add or remove shards from your cluster. When you reshard offline, in addition to changing the number of shards in your cluster, you can do the following:
+ Change the node type of your cluster.
+ Upgrade to a newer engine version.
**Note**
Offline resharding is not supported on clusters with data tiering enabled. For more information, see [Data tiering](data-tiering.md)..
The main disadvantage of offline shard reconfiguration is that your cluster is offline beginning with the restore portion of the process and continuing until you update the endpoints in your application. The length of time that your cluster is offline varies with the amount of data in your cluster.
**To reconfigure your shards MemoryDB cluster offline**
1. Create a manual snapshot of your existing MemoryDB cluster. For more information, see [Making manual snapshots](snapshots-manual.md).
1. Create a new cluster by restoring from the snapshot. For more information, see [Restoring from a snapshot](snapshots-restoring.md).
1. Update the endpoints in your application to the new cluster's endpoints. For more information, see [Finding connection endpoints](endpoints.md).
# Online resharding for MemoryDB
By using online resharding and with MemoryDB, you can scale your MemoryDB dynamically with no downtime. This approach means that your cluster can continue to serve requests even while scaling or rebalancing is in process.
You can do the following:
+ **Scale out** – Increase read and write capacity by adding shards to your MemoryDB cluster.
If you add one or more shards to your cluster, the number of nodes in each new shard is the same as the number of nodes in the smallest of the existing shards.
+ **Scale in** – Reduce read and write capacity, and thereby costs, by removing shards from your MemoryDB cluster.
Currently, the following limitations apply to MemoryDB online resharding:
+ There are limitations with slots or keyspaces and large items:
If any of the keys in a shard contain a large item, that key isn't migrated to a new shard when scaling out . This functionality can result in unbalanced shards.
If any of the keys in a shard contain a large item (items greater than 256 MB after serialization), that shard isn't deleted when scaling in. This functionality can result in some shards not being deleted.
+ When scaling out, the number of nodes in any new shards equals the number of nodes in the existing shards.
For more information, see [Best practices: Online cluster resizing](best-practices-online-resharding.md).
You can horizontally scale your MemoryDB clusters using the AWS Management Console, the AWS CLI, and the MemoryDB API.
## Adding shards with online resharding
You can add shards to your MemoryDB cluster using the AWS Management Console, AWS CLI, or MemoryDB API.
### Adding shards (Console)
You can use the AWS Management Console to add one or more shards to your MemoryDB cluster. The following procedure describes the process.
****
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. From the list of clusters, choose the cluster name from which you want to add a shard.
1. Under the **Shards and nodes** tab, choose **Add/Delete shards**
1. In **New number of shards**, enter the the number of shards you want.
1. Choose **Confirm** to keep the changes or **Cancel** to discard.
### Adding shards (AWS CLI)
The following process describes how to reconfigure the shards in your MemoryDB cluster by adding shards using the AWS CLI.
Use the following parameters with `update-cluster`.
**Parameters**
+ `--cluster-name` – Required. Specifies which cluster (cluster) the shard reconfiguration operation is to be performed on.
+ `--shard-configuration` – Required. Allows you to set the number of shards.
+ `ShardCount` – Set this property to specify the number of shards you want.
**Example**
The following example modifies the number of shards in the cluster `my-cluster` to 2.
For Linux, macOS, or Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--shard-configuration \
ShardCount=2
```
For Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--shard-configuration ^
ShardCount=2
```
It returns the following JSON response:
```
{
"Cluster": {
"Name": "my-cluster",
"Status": "updating",
"NumberOfShards": 2,
"AvailabilityMode": "MultiAZ",
"ClusterEndpoint": {
"Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
"Port": 6379
},
"NodeType": "db.r6g.large",
"EngineVersion": "6.2",
"EnginePatchVersion": "6.2.6",
"ParameterGroupName": "default.memorydb-redis6",
"ParameterGroupStatus": "in-sync",
"SubnetGroupName": "my-sg",
"TLSEnabled": true,
"ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster",
"SnapshotRetentionLimit": 0,
"MaintenanceWindow": "wed:03:00-wed:04:00",
"SnapshotWindow": "04:30-05:30",
"DataTiering": "false",
"AutoMinorVersionUpgrade": true
}
}
```
To view the details of the updated cluster once its status changes from *updating* to *available*, use the following command:
For Linux, macOS, or Unix:
```
aws memorydb describe-clusters \
--cluster-name my-cluster
--show-shard-details
```
For Windows:
```
aws memorydb describe-clusters ^
--cluster-name my-cluster
--show-shard-details
```
It will return the following JSON response:
```
{
"Clusters": [
{
"Name": "my-cluster",
"Status": "available",
"NumberOfShards": 2,
"Shards": [
{
"Name": "0001",
"Status": "available",
"Slots": "0-8191",
"Nodes": [
{
"Name": "my-cluster-0001-001",
"Status": "available",
"AvailabilityZone": "us-east-1a",
"CreateTime": "2021-08-21T20:22:12.405000-07:00",
"Endpoint": {
"Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
"Port": 6379
}
},
{
"Name": "my-cluster-0001-002",
"Status": "available",
"AvailabilityZone": "us-east-1b",
"CreateTime": "2021-08-21T20:22:12.405000-07:00",
"Endpoint": {
"Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
"Port": 6379
}
}
],
"NumberOfNodes": 2
},
{
"Name": "0002",
"Status": "available",
"Slots": "8192-16383",
"Nodes": [
{
"Name": "my-cluster-0002-001",
"Status": "available",
"AvailabilityZone": "us-east-1b",
"CreateTime": "2021-08-22T14:26:18.693000-07:00",
"Endpoint": {
"Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
"Port": 6379
}
},
{
"Name": "my-cluster-0002-002",
"Status": "available",
"AvailabilityZone": "us-east-1a",
"CreateTime": "2021-08-22T14:26:18.765000-07:00",
"Endpoint": {
"Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
"Port": 6379
}
}
],
"NumberOfNodes": 2
}
],
"ClusterEndpoint": {
"Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
"Port": 6379
},
"NodeType": "db.r6g.large",
"EngineVersion": "6.2",
"EnginePatchVersion": "6.2.6",
"ParameterGroupName": "default.memorydb-redis6",
"ParameterGroupStatus": "in-sync",
"SubnetGroupName": "my-sg",
"TLSEnabled": true,
"ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster",
"SnapshotRetentionLimit": 0,
"MaintenanceWindow": "wed:03:00-wed:04:00",
"SnapshotWindow": "04:30-05:30",
"ACLName": "my-acl",
"DataTiering": "false",
"AutoMinorVersionUpgrade": true
}
]
}
```
For more information, see [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) in the AWS CLI Command Reference.
### Adding shards (MemoryDB API)
You can use the MemoryDB API to reconfigure the shards in your MemoryDB cluster online by using the `UpdateCluster` operation.
Use the following parameters with `UpdateCluster`.
**Parameters**
+ `ClusterName` – Required. Specifies which cluster the shard reconfiguration operation is to be performed on.
+ `ShardConfiguration` – Required. Allows you to set the number of shards.
+ `ShardCount` – Set this property to specify the number of shards you want.
For more information, see [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
## Removing shards with online resharding
You can remove shards from your MemoryDB cluster using the AWS Management Console, AWS CLI, or MemoryDB API.
### Removing shards (Console)
The following process describes how to reconfigure the shards in your MemoryDB cluster by removing shards using the AWS Management Console.
**Important**
Before removing shards from your cluster, MemoryDB makes sure that all your data will fit in the remaining shards. If the data will fit, shards are deleted from the cluster as requested. If the data won't fit in the remaining shards, the process is terminated and the cluster is left with the same shard configuration as before the request was made.
You can use the AWS Management Console to remove one or more shards from your MemoryDB cluster. You cannot remove all the shards in a cluster. Instead, you must delete the cluster. For more information, see [Step 5: Deleting a cluster](getting-started.md#clusters.delete). The following procedure describes the process for removing one or more shards.
****
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. From the list of clusters, choose the cluster name from which you want to remove a shard.
1. Under the **Shards and nodes** tab, choose **Add/Delete shards**
1. In **New number of shards**, enter the the number of shards you want (with a minimum of 1).
1. Choose **Confirm** to keep the changes or **Cancel** to discard.
### Removing shards (AWS CLI)
The following process describes how to reconfigure the shards in your MemoryDB cluster by removing shards using the AWS CLI.
**Important**
Before removing shards from your cluster, MemoryDB makes sure that all your data will fit in the remaining shards. If the data will fit, shards are deleted from the cluster as requested and their keyspaces mapped into the remaining shards. If the data will not fit in the remaining shards, the process is terminated and the cluster is left with the same shard configuration as before the request was made.
You can use the AWS CLI to remove one or more shards from your MemoryDB cluster. You cannot remove all the shards in a cluster. Instead, you must delete the cluster. For more information, see [Step 5: Deleting a cluster](getting-started.md#clusters.delete).
Use the following parameters with `update-cluster`.
**Parameters**
+ `--cluster-name` – Required. Specifies which cluster (cluster) the shard reconfiguration operation is to be performed on.
+ `--shard-configuration` – Required. Allows you to set the number of shards using the `ShardCount` property:
`ShardCount` – Set this property to specify the number of shards you want.
**Example**
The following example modifies the number of shards in the cluster `my-cluster` to 2.
For Linux, macOS, or Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--shard-configuration \
ShardCount=2
```
For Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--shard-configuration ^
ShardCount=2
```
It returns the following JSON response:
```
{
"Cluster": {
"Name": "my-cluster",
"Status": "updating",
"NumberOfShards": 2,
"AvailabilityMode": "MultiAZ",
"ClusterEndpoint": {
"Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
"Port": 6379
},
"NodeType": "db.r6g.large",
"EngineVersion": "6.2",
"EnginePatchVersion": "6.2.6",
"ParameterGroupName": "default.memorydb-redis6",
"ParameterGroupStatus": "in-sync",
"SubnetGroupName": "my-sg",
"TLSEnabled": true,
"ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster",
"SnapshotRetentionLimit": 0,
"MaintenanceWindow": "wed:03:00-wed:04:00",
"SnapshotWindow": "04:30-05:30",
"DataTiering": "false",
"AutoMinorVersionUpgrade": true
}
}
```
To view the details of the updated cluster once its status changes from *updating* to *available*, use the following command:
For Linux, macOS, or Unix:
```
aws memorydb describe-clusters \
--cluster-name my-cluster
--show-shard-details
```
For Windows:
```
aws memorydb describe-clusters ^
--cluster-name my-cluster
--show-shard-details
```
It will return the following JSON response:
```
{
"Clusters": [
{
"Name": "my-cluster",
"Status": "available",
"NumberOfShards": 2,
"Shards": [
{
"Name": "0001",
"Status": "available",
"Slots": "0-8191",
"Nodes": [
{
"Name": "my-cluster-0001-001",
"Status": "available",
"AvailabilityZone": "us-east-1a",
"CreateTime": "2021-08-21T20:22:12.405000-07:00",
"Endpoint": {
"Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
"Port": 6379
}
},
{
"Name": "my-cluster-0001-002",
"Status": "available",
"AvailabilityZone": "us-east-1b",
"CreateTime": "2021-08-21T20:22:12.405000-07:00",
"Endpoint": {
"Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
"Port": 6379
}
}
],
"NumberOfNodes": 2
},
{
"Name": "0002",
"Status": "available",
"Slots": "8192-16383",
"Nodes": [
{
"Name": "my-cluster-0002-001",
"Status": "available",
"AvailabilityZone": "us-east-1b",
"CreateTime": "2021-08-22T14:26:18.693000-07:00",
"Endpoint": {
"Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
"Port": 6379
}
},
{
"Name": "my-cluster-0002-002",
"Status": "available",
"AvailabilityZone": "us-east-1a",
"CreateTime": "2021-08-22T14:26:18.765000-07:00",
"Endpoint": {
"Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
"Port": 6379
}
}
],
"NumberOfNodes": 2
}
],
"ClusterEndpoint": {
"Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
"Port": 6379
},
"NodeType": "db.r6g.large",
"EngineVersion": "6.2",
"EnginePatchVersion": "6.2.6",
"ParameterGroupName": "default.memorydb-redis6",
"ParameterGroupStatus": "in-sync",
"SubnetGroupName": "my-sg",
"TLSEnabled": true,
"ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster",
"SnapshotRetentionLimit": 0,
"MaintenanceWindow": "wed:03:00-wed:04:00",
"SnapshotWindow": "04:30-05:30",
"ACLName": "my-acl",
"DataTiering": "false",
"AutoMinorVersionUpgrade": true
}
]
}
```
For more information, see [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) in the AWS CLI Command Reference.
### Removing shards (MemoryDB API)
You can use the MemoryDB API to reconfigure the shards in your MemoryDB cluster online by using the `UpdateCluster` operation.
The following process describes how to reconfigure the shards in your MemoryDB cluster by removing shards using the MemoryDB API.
**Important**
Before removing shards rom your cluster, MemoryDB makes sure that all your data will fit in the remaining shards. If the data will fit, shards are deleted from the cluster as requested and their keyspaces mapped into the remaining shards. If the data will not fit in the remaining shards, the process is terminated and the cluster is left with the same shard configuration as before the request was made.
You can use the MemoryDB API to remove one or more shards from your MemoryDB cluster. You cannot remove all the shards in a cluster. Instead, you must delete the cluster. For more information, see [Step 5: Deleting a cluster](getting-started.md#clusters.delete).
Use the following parameters with `UpdateCluster`.
**Parameters**
+ `ClusterName` – Required. Specifies which cluster (cluster) the shard reconfiguration operation is to be performed on.
+ `ShardConfiguration` – Required. Allows you to set the number of shards using the `ShardCount` property:
`ShardCount` – Set this property to specify the number of shards you want.
# Online vertical scaling by modifying node type
By using online vertical scaling with MemoryDB, you can scale your cluster dynamically with minimal downtime. This allows your cluster to serve requests even while scaling.
**Note**
Scaling is not supported between a data tiering cluster (for example, a cluster using an r6gd node type) and a cluster that does not use data tiering (for example, a cluster using an r6g node type). For more information, see [Data tiering](data-tiering.md).
You can do the following:
+ **Scale up** – Increase read and write capacity by adjusting the node type of your MemoryDB cluster to use a larger node type.
MemoryDB dynamically resizes your cluster while remaining online and serving requests.
+ **Scale down** – Reduce read and write capacity by adjusting the node type down to use a smaller node. Again, MemoryDB dynamically resizes your cluster while remaining online and serving requests. In this case, you reduce costs by downsizing the node.
**Note**
The scale up and scale down processes rely on creating clusters with newly selected node types and synchronizing the new nodes with the previous ones. To ensure a smooth scale up/down flow, do the following:
While the vertical scaling process is designed to remain fully online, it does rely on synchronizing data between the old node and the new node. We recommend that you initiate scale up/down during hours when you expect data traffic to be at its minimum.
Test your application behavior during scaling in a staging environment, if possible.
# Online scaling up
**Topics**
+ [Scaling up MemoryDB clusters (Console)](#cluster-vertical-scaling-console)
+ [Scaling up MemoryDB clusters (AWS CLI)](#scaling.scaleUp.cli)
+ [Scaling up MemoryDB clusters (MemoryDB API)](#verticalscaling.scaleup.api)
## Scaling up MemoryDB clusters (Console)
The following procedure describes how to scale up a MemoryDB cluster using the AWS Management Console. During this process, your MemoryDB cluster will continue to serve requests with minimal downtime.
**To scale up a cluster (console)**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. From the list of clusters, choose the cluster.
1. Choose **Actions** and then choose **Modify**.
1. In the **Modify Cluster** dialog:
1. Choose the node type you want to scale to from the **Node type** list. To scale up, select a node type larger than your existing node.
1. Choose **Save changes**.
The cluster's status changes to *modifying*. When the status changes to *available*, the modification is complete and you can begin using the new cluster.
## Scaling up MemoryDB clusters (AWS CLI)
The following procedure describes how to scale up a MemoryDB cluster using the AWS CLI. During this process, your MemoryDB cluster will continue to serve requests with minimal downtime.
**To scale up a MemoryDB cluster (AWS CLI)**
1. Determine the node types you can scale up to by running the AWS CLI `list-allowed-node-type-updates` command with the following parameter.
For Linux, macOS, or Unix:
```
aws memorydb list-allowed-node-type-updates \
--cluster-name my-cluster-name
```
For Windows:
```
aws memorydb list-allowed-node-type-updates ^
--cluster-name my-cluster-name
```
Output from the above command looks something like this (JSON format).
```
{
"ScaleUpNodeTypes": [
"db.r6g.2xlarge",
"db.r6g.large"
],
"ScaleDownNodeTypes": [
"db.r6g.large"
],
}
```
For more information, see [list-allowed-node-type-updates](https://docs.aws.amazon.com/cli/latest/reference/memorydb/list-allowed-node-type-updates.html) in the *AWS CLI Reference*.
1. Modify your cluster to scale up to the new, larger node type, using the AWS CLI `update-cluster` command and the following parameters.
+ `--cluster-name` – The name of the cluster you are scaling up to.
+ `--node-type` – The new node type you want to scale the cluster. This value must be one of the node types returned by the `list-allowed-node-type-updates` command in step 1.
For Linux, macOS, or Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--node-type db.r6g.2xlarge
```
For Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--node-type db.r6g.2xlarge ^
```
For more information, see [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html).
## Scaling up MemoryDB clusters (MemoryDB API)
The following process scales your cluster from its current node type to a new, larger node type using the MemoryDB API. During this process, MemoryDB updates the DNS entries so they point to the new nodes. You can scale auto-failover enabled clusters while the cluster continues to stay online and serve incoming requests.
The amount of time it takes to scale up to a larger node type varies, depending upon your node type and the amount of data in your current cluster.
**To scale up a MemoryDB cluster (MemoryDB API)**
1. Determine which node types you can scale up to using the MemoryDB API `ListAllowedNodeTypeUpdates` action with the following parameter.
+ `ClusterName` – the name of the cluster. Use this parameter to describe a specific cluster rather than all clusters.
```
https://memory-db.us-east-1.amazonaws.com/
?Action=ListAllowedNodeTypeUpdates
&ClusterName=MyCluster
&Version=2021-01-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20210802T192317Z
&X-Amz-Credential=
```
For more information, see [ListAllowedNodeTypeUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListAllowedNodeTypeUpdates.html) in the *MemoryDB API Reference*.
1. Scale your current cluster up to the new node type using the `UpdateCluster` MemoryDB API action and with the following parameters.
+ `ClusterName` – the name of the cluster.
+ `NodeType` – the new, larger node type of the clusters in this cluster. This value must be one of the instance types returned by the `ListAllowedNodeTypeUpdates` action in step 1.
```
https://memory-db.us-east-1.amazonaws.com/
?Action=UpdateCluster
&NodeType=db.r6g.2xlarge
&ClusterName=myCluster
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20210801T220302Z
&Version=2021-01-01
&X-Amz-Algorithm=Amazon4-HMAC-SHA256
&X-Amz-Date=20210801T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20210801T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
For more information, see [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
# Online scaling down
**Topics**
+ [Scaling down MemoryDB clusters (Console)](#cluster-vertical-scaling-down-console)
+ [Scaling down MemoryDB clusters (AWS CLI)](#scaling.scaledown.cli)
+ [Scaling down MemoryDB clusters (MemoryDB API)](#scaling.vertical.scaledown.api)
## Scaling down MemoryDB clusters (Console)
The following procedure describes how to scale down a MemoryDB cluster using the AWS Management Console. During this process, your MemoryDB cluster will continue to serve requests with minimal downtime.
**To scale down a MemoryDB cluster (console)**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. From the list of clusters, choose your preferred cluster.
1. Choose **Actions** and then choose **Modify**.
1. In the **Modify Cluster** dialog:
1. Choose the node type you want to scale to from the **Node type** list. To scale down, select a node type smaller than your existing node. Note that not all node types are available to scale down to.
1. Choose **Save changes**.
The cluster's status changes to *modifying*. When the status changes to *available*, the modification is complete and you can begin using the new cluster.
## Scaling down MemoryDB clusters (AWS CLI)
The following procedure describes how to scale down a MemoryDB cluster using the AWS CLI. During this process, your MemoryDB cluster will continue to serve requests with minimal downtime.
**To scale down a MemoryDB cluster (AWS CLI)**
1. Determine the node types you can scale down to by running the AWS CLI `list-allowed-node-type-updates` command with the following parameter.
For Linux, macOS, or Unix:
```
aws memorydb list-allowed-node-type-updates \
--cluster-name my-cluster-name
```
For Windows:
```
aws memorydb list-allowed-node-type-updates ^
--cluster-name my-cluster-name
```
Output from the above command looks something like this (JSON format).
```
{
"ScaleUpNodeTypes": [
"db.r6g.2xlarge",
"db.r6g.large"
],
"ScaleDownNodeTypes": [
"db.r6g.large"
],
}
```
For more information, see [list-allowed-node-type-updates](https://docs.aws.amazon.com/cli/latest/reference/memorydb/list-allowed-node-type-updates.html).
1. Modify your cluster to scale down to the new, smaller node type, using the `update-cluster` command and the following parameters.
+ `--cluster-name` – The name of the cluster you are scaling down to.
+ `--node-type` – The new node type you want to scale the cluster. This value must be one of the node types returned by the `list-allowed-node-type-updates` command in step 1.
For Linux, macOS, or Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--node-type db.r6g.large
```
For Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--node-type db.r6g.large
```
For more information, see [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html).
## Scaling down MemoryDB clusters (MemoryDB API)
The following process scales your cluster from its current node type to a new, smaller node type using the MemoryDB API. During this process, your MemoryDB cluster will continue to serve requests with minimal downtime.
The amount of time it takes to scale down to a smaller node type varies, depending upon your node type and the amount of data in your current cluster.
**Scaling down (MemoryDB API)**
1. Determine which node types you can scale down to using the [ListAllowedNodeTypeUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListAllowedNodeTypeUpdates.html) API with the following parameter:
+ `ClusterName` – the name of the cluster. Use this parameter to describe a specific cluster rather than all clusters.
```
https://memory-db.us-east-1.amazonaws.com/
?Action=ListAllowedNodeTypeUpdates
&ClusterName=MyCluster
&Version=2021-01-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20210802T192317Z
&X-Amz-Credential=
```
1. Scale your current cluster down to the new node type using the [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) API with the following parameters.
+ `ClusterName` – the name of the cluster.
+ `NodeType` – the new, smaller node type of the clusters in this cluster. This value must be one of the instance types returned by the `ListAllowedNodeTypeUpdates` action in step 1.
```
https://memory-db.us-east-1.amazonaws.com/
?Action=UpdateCluster
&NodeType=db.r6g.2xlarge
&ClusterName=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20210801T220302Z
&Version=2021-01-01
&X-Amz-Algorithm=Amazon4-HMAC-SHA256
&X-Amz-Date=20210801T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20210801T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```