# Scaling node-based clusters


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 cache, you need to provision sufficient hardware for your demand peaks, which can be expensive. By using Amazon ElastiCache you can scale to meet current demand, paying only for what you use. ElastiCache enables you to scale your cache to match demand.

**Note**  
If a Valkey or Redis OSS cluster is replicated across one or more Regions, then those Regions are scaled in order. When scaling up, secondary Regions are scaled first and then the primary Region. When scaling down, the primary Region is first and then any secondary Regions follow.  
When updating the engine version, the order is secondary Region and then primary Region.

**Topics**
+ [

# On-demand scaling for Memcached clusters
](Scaling-self-designed.mem-heading.md)
+ [

# Manual scaling for Memcached clusters
](Scaling.Memcached.manually.md)
+ [

# Scaling for Valkey or Redis OSS (Cluster Mode Disabled) clusters
](scaling-redis-classic.md)
+ [

# Scaling replica nodes for Valkey or Redis OSS (Cluster Mode Disabled)
](Scaling.RedisReplGrps.md)
+ [

# Scaling Valkey or Redis OSS (Cluster Mode Enabled) clusters
](scaling-redis-cluster-mode-enabled.md)

# On-demand scaling for Memcached clusters
On-demand scaling for Memcached clusters

ElastiCache for Memcached offers a fully managed, in-memory caching service that deploys, operates, and vertically scales Memcached in the AWS cloud. 

**On-demand vertical scaling**

With vertical scaling, ElastiCache for Memcached provides a high-performance, distributed memory caching system widely used to speed up dynamic applications by alleviating database load. It stores data and objects in RAM, reducing the need to read from external data sources.

You can apply vertical scaling to existing node-based clusters as well as new ones. This can provide flexibility in resource allocation, allowing users to efficiently adapt to changing workloads without altering cluster architecture. This ability to scale improves performance by increasing cache capacity during high demand periods, and scaling down to optimize costs during low-demand periods. This simplifies operations, eliminates the need to create new clusters for shifting resource requirements, and enables quick responses to traffic fluctuations. Overall, vertical scaling for Memcached node-based clusters can help enhance cost efficiency, improve resource utilization, and even let users change their Memcached instance type. All making it easier for users to align their caching infrastructure with actual application needs. 

**Note**  
Node type modifications are only available for node-based Memcached clusters with engine versions 1.5 or later.
Auto Discovery must be enabled in order to make use of vertical scaling. 

## Setting up on-demand vertical scaling for node-based Memcached clusters
On-demand vertical scaling for Memcached

You can configure on-demand vertical scaling for Memcached with `scale-config`, which contains two parameters: 

1. **ScaleIntervalMinutes:** Time (in minutes) between scaling batches during the Memcached upgrade process

1. **ScalePercentage:** Percentage of nodes to scale concurrently during the Memcached upgrade process

**Converting an existing Memcached node type to a cache that can vertically scale via the CLI**

To convert an existing Memcached node-based cluster to a cache that can vertically scale, you can use `elasticache modify-cache-cluster` via the CLI.

```
aws elasticache modify-cache-cluster \
    --cache-cluster-id <your-cluster-id> \
    --cache-node-type <new-node-type> \
    --scale-config <scale-config> \ 
    --apply-immediately
```

**Setting up vertical scaling with the CLI**

To set up vertical scaling for a node-based Memcached cluster via the CLI, use `elasticache modify-cache-cluster` with `scale-config` and its parameters `ScalePercentage` and `ScaleIntervalMinutes`. 
+ **scale-interval-minutes:**This defines the time (in minutes) between scaling batches. This setting can range from 2-30 minutes. If no value is specified, the default value of 5 minutes is applied.
+ **scale-percentage:**This specifies the percentage of nodes to scale concurrently in each batch. This setting can range from 10-100. The setting is rounded up when dividing, so for example if the result would be 49.5 a setting of 50 is applied. If no value is specified, the default value of 20 is applied.

These configuration options will enable you to fine-tune the scaling process according to your specific needs, balancing between minimizing cluster disruption and optimizing scaling speed. The scale-config parameter will only be applicable for Memcached engine types and will be ignored for other cache engines, ensuring backward compatibility with existing API usage for other clusters.

**API call**

```
aws elasticache modify-cache-cluster \
    --cache-cluster-id <your-cluster-id> \
    --cache-node-type <new-node-type> \
    --scale-config '{
            "ScalePercentage": 30,
            "ScaleIntervalMinutes": 2
          }'
    --apply-immediately
```

**Result:**

Returns the cluster ID and the pending change.

```
{
    "CacheCluster": {
        "CacheNodeType": "old_insance_type",
         ...
         ...
         "PendingModifiedValues": {
            "CacheNodeType": "new_instance_type"
         },
    }
}
```

**List your Memcached cache vertical scaling setting**

You can retrieve scaling options for your Memcached caches, and see what their current options are for vertical scaling. 

**API call**

```
aws elasticache list-allowed-node-type-modifications --cache-cluster-id <your-cluster-id>
```

**Result: **

```
{ 
  "ScaleUpModifications": [
      "cache.x.xxxx", 
      "cache.x.xxxx"
   	  ],
   "ScaleDownModifications": [ 
      "cache.x.xxxx", 
      "cache.x.xxxx", 
      "cache.x.xxxx" 
      ] 
}
```

**Vertical scaling for Memcached with the AWS Management Console**

Follow these steps to use the AWS Management Console to convert a node-based Memcached cluster to a vertically scalable cluster.

1. Sign in to the AWS Management Console and open the ElastiCache console at [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).

1. Select the Memcached cluster to convert.

1. Select the **Modify** tab.

1. Go to the **Cache settings** section, and select the desired **Node type**.

1. Select **Preview changes**, and review the changes.

1. Select **Modify**.

## Automated horizontal scaling for Memcached


ElastiCache now integrates with the AWS Application Auto Scaling (AAS) service to include automated horizontal scaling for Memcached clusters. You can define scaling policies through the AWS Application Auto Scaling service, and automatically adjust the number of nodes in Memcached clusters as needed, based on predefined metrics or schedules.

**Note**  
Automated horizontal scaling is not currently available in the Beijing and Ningxia Regions. 

These are the available methods for automatically horizontally scaling your node-based clusters.
+ **Scheduled Scaling:** Scaling based on a schedule allows you to set your own scaling schedule for predictable load changes. For example, every week the traffic to your web application starts to increase on Wednesday, remains high on Thursday, and starts to decrease on Friday. You can configure Auto Scaling to increase capacity on Wednesday and decrease capacity on Friday. 
+ **Target Tracking:** With target tracking scaling policies, you choose a scaling metric and set a target value. Application Auto Scaling creates and manages the CloudWatch alarms that trigger the scaling policy and calculates the scaling adjustment based on the metric and the target value. The scaling policy adds or removes capacity as required to keep the metric at, or close to, the specified target value. 

**How to set up horizontal scaling for a node-based Memcached cluster via the CLI**

When horizontal scaling a node-based Memcached cluster, you can use a target tracking policy, a scheduled policy, or both.

1. **Register a resource as scalable target**

   Call the `RegisterScalableTarget` API in AWS Application Auto Scaling to register the target for the scalable dimension `elasticache:cache-cluster:Nodes`. 

   **API: ApplicationAutoScaling.RegisterScalableTarget**

   Input:

   ```
   {
   	"ScalableDimension": "elasticache:cache-cluster:Nodes",
   	"ResourceId": "cache-cluster/test-cluster-1",
   	"ServiceNamespace": "elasticache",
   	"MinCapacity": 20,  
   	"MaxCapacity": 50 
   }
   ```

1. **Create a Target tracking scaling policy**

   Next, you can create a target tracking scaling policy for the resource by calling put scaling policy API. 

1. **Predefined Metric**

   Following is a policy that scales along the dimension of Cache Node, using the predefined metric ` ElastiCacheCPUUtilization`, set at 50 for cluster test-cluster-1. When deleting nodes for scale-in, the last n nodes will be removed.

   API: ApplicationAutoScaling.PutScalingPolicy

   Input:

   ```
   {
   	"PolicyName": "cpu50-target-tracking-scaling-policy",
   	"PolicyType": "TargetTrackingScaling",
   	"TargetTrackingScalingPolicyConfiguration": {
   		"TargetValue": 50,
   		"PredefinedMetricSpecification": {
   			"PredefinedMetricType": "ElastiCacheCPUUtilization"
   			},
   		"ScaleOutCooldown": 600,
   		"ScaleInCooldown": 600
   			},
   	"ServiceNamespace": "elasticache",
   	"ScalableDimension": "elasticache:cache-cluster:Nodes",
   	"ResourceId": "cache-cluster/test-cluster-1"
   }
   ```

   Output:

   ```
   {
   	"PolicyARN": "arn:aws:autoscaling:us-west-2:012345678910:scalingPolicy:6d8972f3-efc8-437c-92d1-6270f29a66e7:resource/elasticache/cache-cluster/test-cluster-1:policyName/cpu50-target-tracking-scaling-policy",
   	"Alarms": [
   		{
   		"AlarmARN": "arn:aws:cloudwatch:us-west-2:012345678910:alarm:TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca",
   		"AlarmName": "TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca"
   		},
   		{
   		"AlarmARN": "arn:aws:cloudwatch:us-west-2:012345678910:alarm:TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmLow-1b437334-d19b-4a63-a812-6c67aaf2910d",
   		"AlarmName": "TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmLow-1b437334-d19b-4a63-a812-6c67aaf2910d"
   		}
   	]
   }
   ```

1. **Custom Metric**

   You can also set scaling policy on dimension by using a custom percentage that's based on the Cloudwatch metric.

   Input:

   ```
   {
   	"PolicyName": "cpu50-target-tracking-scaling-policy",
   	"PolicyType": "TargetTrackingScaling",
   	"TargetTrackingScalingPolicyConfiguration": {
   		"CustomizedMetricSpecification": { 
   			"Dimensions": [ 
   				{ 
   				"Name": "MyMetricDimension",
   				"Value": "DimensionValue"
   				}
   				],
   			"MetricName": "MyCustomMetric",
   			"Namespace": "MyNamespace",
   			"Statistic": "Average",
   			"Unit": "Percent"
   			},
   		"TargetValue": 40,
   		"ScaleOutCooldown": 600,
   		"ScaleInCooldown": 600
   		},
   	"ServiceNamespace": "elasticache",
   	"ScalableDimension": "elasticache:cache-cluster:Nodes",
   	"ResourceId": "cache-cluster/test-cluster-1"
   }
   ```

1. **Scheduled Actions**

   When you need to scale out for a particular event and then scale in after the event, you can create two scheduled actions by calling the `PutScheduledAction` API. 

   **Policy 1: Scaling out**

   The `at` command in `--schedule` schedules the action to be run once at a specified date and time in the future. The schedule field also supports rate (minute, hour, day etc) and cron (for cron expression).

   At the date and time specified, Application Auto Scaling updates the `MinCapacity` and `MaxCapacity` values. Application Auto Scaling scales out to MinCapacity to put the cache nodes to 70. 

   **API: ApplicationAutoScaling.PutScheduledAction**

   Input:

   ```
   {
   	"ResourceId": "elasticache:ache-cluster:test-cluster-1",
   	"ScalableDimension": "elasticache:cache-cluster:Nodes",
   		"ScalableTargetAction": { 
   			"MaxCapacity": 100,
   			"MinCapacity": 70
   			},
   	"Schedule": "at(2020-05-20T17:05:00)",
   	"ScheduledActionName": "ScalingOutScheduledAction",
   	"ServiceNamespace": "elasticache",
   }
   ```

   **Policy 2: Scaling in**

   At the date and time specified, Application Auto Scaling updates the table's `MinCapacity` and `MaxCapacity`, and scales in to `MaxCapacity` to return the cache nodes to 60.

   **API: ApplicationAutoScaling.PutScheduledAction**

   Input:

   ```
   {
   	"ResourceId": "elasticache:cache-cluster:test-cluster-1",
   	"ScalableDimension": "elasticache:cache-cluster:Nodes",
   	"ScalableTargetAction": { 
   		"MaxCapacity": 60,
   		"MinCapacity": 40
   		},
   	"Schedule": "at(2020-05-21T17:05:00)",
   	"ScheduledActionName": "ScalingInScheduledAction",
   	"ServiceNamespace": "elasticache",
   }
   ```

1. **View the Scaling Activities**

   You can view the scaling activities using the `DescribeScalingActivities` API. 

   **API: ApplicationAutoScaling.DescribeScalingActivities**

   Output:

   ```
   {
   	"ScalingActivities": [
   		{
   		"ScalableDimension": "elasticache:elasticache:DesiredCount",
   		"Description": "Setting desired count to 30.",
   		"ResourceId": "elasticache/cache-cluster/test-cluster-1",
   		"ActivityId": "4d759079-a31f-4d0c-8468-504c56e2eecf",
   		"StartTime": 1462574194.658,
   		"elasticacheNamespace": "elasticache",
   		"EndTime": 1462574276.686,
   		"Cause": "monitor alarm TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca in state ALARM triggered policy cpu50-target-tracking-scaling-policy",
   		"StatusMessage": "Failed to set desired count to 30",
   		"StatusCode": "Failed"
   		},
   		{
   		"ScalableDimension": "elasticache:elasticache:DesiredCount",
   		"Description": "Setting desired count to 25.",
   		"ResourceId": "elasticache/cache-cluster/test-cluster-1",
   		"ActivityId": "90aff0eb-dd6a-443c-889b-b809e78061c1",
   		"StartTime": 1462574254.223,
   		"elasticacheNamespace": "elasticache",
   		"EndTime": 1462574333.492,
   		"Cause": "monitor alarm TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca in state ALARM triggered policy cpu50-target-tracking-scaling-policy",
   		"StatusMessage": "Successfully set desired count to 25. Change successfully fulfilled by elasticache.",
   		"StatusCode": "Successful"
   		}
   	]
   }
   ```

1. **Edit/Delete Scaling Policy**

   You can edit or delete policies by calling `PutScalingPolicy` API again, or by calling `DeleteScalingPolicy` or `DeleteScheduled` Action. 

1. **De-register scalable targets**

   You can de-register the scalable target through the `DeregisterScalableTarget` API. Deregistering a scalable target deletes the scaling policies and the scheduled actions that are associated with it. 

   **API: ApplicationAutoScaling.DeregisterScalableTarget**

   Input:

   ```
   {
   	"ResourceId": "elasticache/cache-cluster/test-cluster-1",
   	"ServiceNamespace": "elasticache",
   	"ScalableDimension": "elasticache:cache-cluster:Nodes"
   }
   ```

1. **Scaling Policy Cleanup**

1. **Multiple Scaling Policies**

   You can create multiple scaling policies. Following are key callouts on behavior from [Auto scaling target tracking](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html). 
   + You can have multiple target tracking scaling policies for a scalable target, provided that each of them uses a different metric.
   + The intention of Application Auto Scaling is to always prioritize availability, so its behavior differs depending on whether the target tracking policies are ready for scale out or scale in. It will scale out the scalable target if any of the target tracking policies are ready for scale out, but will scale in only if all of the target tracking policies (with the scale-in portion enabled) are ready to scale in. 
   + If multiple policies instruct the scalable target to scale out or in at the same time, Application Auto Scaling scales based on the policy that provides the largest capacity for both scale in and scale out. This provides greater flexibility to cover multiple scenarios and ensures that there is always enough capacity to process your application workloads. 
**Note**  
AWS Application Auto Scaling does not queue scaling policies. Application Auto Scaling will wait for the first scaling to complete, then cooldown, and then repeat the above algorithm.

**Automatically horizontally scale a node-based Memcached cluster via the AWS Management Console**

Follow these steps to use the AWS Management Console to convert an existing node-based Memcached cluster to a horizontally scalable cluster.

1. Sign in to the AWS Management Console and open the ElastiCache console at [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).

1. Select the Memcached cache to convert.

1. Go to the **Autoscaling** tab.

1. Select the scaling policy to apply, by selecting either **Add dynamic scaling** or **Add scheduled scaling**.

1. Fill in the details for the selected policy as needed.

1. Click **Create**.

# Manual scaling for Memcached clusters
Manual scaling for Memcached clusters

Manually horizontally scaling a Memcached cluster in or out is as easy as adding or removing nodes from the cluster. Memcached clusters are composed of 1 to 60 nodes. 

Because you can partition your data across all the nodes in a Memcached cluster, scaling up to a node type with greater memory is seldom required. However, because the Memcached engine does not persist data, if you do scale to a different node type then your new cluster starts out empty unless your application populates it.

To manually vertically scale your Memcached cluster, you must create a new cluster. Memcached clusters always start out empty unless your application populates it. 


**Manually scaling Memcached clusters**  

| Action | Topic | 
| --- | --- | 
|  Scaling out  |  [Adding nodes to a cluster](Clusters.html#AddNode)  | 
|  Scaling in  |  [Deleting nodes from a cluster](Clusters.html#DeleteNode)  | 
|  Changing node types  |  [Manually scaling node-based Memcached clusters vertically](#Scaling.Memcached.Vertically)  | 

**Topics**
+ [

## Manually scaling a node-based Memcached cluster horizontally
](#Scaling.Memcached.Horizontally)
+ [

## Manually scaling node-based Memcached clusters vertically
](#Scaling.Memcached.Vertically)

## Manually scaling a node-based Memcached cluster horizontally


The Memcached engine supports partitioning your data across multiple nodes. Because of this, Memcached clusters scale horizontally easily. To horizontally scale your Memcached cluster, merely add or remove nodes.

The following topics detail how to scale your Memcached cluster out or in by adding or removing nodes.
+ [Adding nodes to a cluster](Clusters.html#AddNode)
+ [Deleting nodes from your cluster](Clusters.html#AddNode)

Each time you change the number of nodes in your Memcached cluster, you must re-map at least some of your keyspace so it maps to the correct node. For more detailed information on load balancing your Memcached cluster, see [Configuring your ElastiCache client for efficient load balancing (Memcached)](BestPractices.LoadBalancing.md).

If you use auto discovery on your Memcached cluster, you do not need to change the endpoints in your application as you add or remove nodes. For more information on auto discovery, see [Automatically identify nodes in your cluster (Memcached)](AutoDiscovery.md) If you do not use auto discovery, each time you change the number of nodes in your Memcached cluster you must update the endpoints in your application.

## Manually scaling node-based Memcached clusters vertically


When you manually scale your Memcached cluster up or down, you must create a new cluster. Memcached clusters always start out empty unless your application populates it. 

**Important**  
If you are scaling down to a smaller node type, be sure that the smaller node type is adequate for your data and overhead. For more information, see [Choosing your node size](CacheNodes.SelectSize.md).

**Topics**
+ [

### Scaling a node-based Memcached cluster vertically (Console)
](#Scaling.Memcached.Vertically.CON)
+ [

### Scaling a node-based Memcached cluster vertically (AWS CLI)
](#Scaling.Memcached.Vertically.CLI)
+ [

### Scaling a node-based Memcached cluster vertically (ElastiCache API)
](#Scaling.Memcached.Vertically.API)

### Scaling a node-based Memcached cluster vertically (Console)


The following procedure walks you through scaling a node-based Memcached cluster vertically using the AWS Management Console.

1. Create a new cluster with the new node type. For more information, see [Creating a Memcached cluster (console)](Clusters.Create-mc.md#Clusters.Create.CON.Memcached).

1. In your application, update the endpoints to the new cluster's endpoints. For more information, see [Finding a Cluster's Endpoints (Console) (Memcached)](Endpoints.md#Endpoints.Find.Memcached).

1. Delete the old cluster. For more information, see [Deleting a new node in Memcached](Clusters.html#Delete.CON.Memcached).

### Scaling a node-based Memcached cluster vertically (AWS CLI)


The following procedure walks you through scaling a node-based Memcached cluster vertically using the AWS CLI.

1. Create a new cluster with the new node type. For more information, see [Creating a cluster (AWS CLI)](Clusters.Create.md#Clusters.Create.CLI).

1. In your application, update the endpoints to the new cluster's endpoints. For more information, see [Finding Endpoints (AWS CLI)](Endpoints.md#Endpoints.Find.CLI).

1. Delete the old cluster. For more information, see [Using the AWS CLI to delete an ElastiCache cluster](Clusters.Delete.md#Clusters.Delete.CLI).

### Scaling a node-based Memcached cluster vertically (ElastiCache API)


The following procedure walks you through scaling a node-based Memcached cluster vertically using the ElastiCache API.

1. Create a new cluster with the new node type. For more information, see [Creating a cluster for Memcached (ElastiCache API)](Clusters.Create-mc.md#Clusters.Create.API.mem-heading)

1. In your application, update the endpoints to the new cluster's endpoints. For more information, see [Finding Endpoints (ElastiCache API)](Endpoints.md#Endpoints.Find.API).

1. Delete the old cluster. For more information, see [Using the ElastiCache API](Clusters.Delete.md#Clusters.Delete.API).

# Scaling for Valkey or Redis OSS (Cluster Mode Disabled) clusters


Valkey or Redis OSS (cluster mode disabled) clusters can be a single-node cluster with 0 shards or multi-node clusters with 1 shard. Single-node clusters use the one node for both reads and writes. Multi-node clusters always have 1 node as the read/write primary node with 0 to 5 read-only replica nodes.

**Topics**
+ [

## Scaling for Valkey or Redis OSS (Cluster Mode Disabled) clusters
](#Scaling.RedisStandalone)


**Scaling Valkey or Redis OSS clusters**  

| Action | Valkey or Redis OSS (cluster mode disabled) | Valkey or Redis OSS (cluster mode enabled) | 
| --- | --- | --- | 
|  Scaling in  |  [Removing nodes from an ElastiCache cluster](Clusters.DeleteNode.md)  |  [Scaling Valkey or Redis OSS (Cluster Mode Enabled) clusters](scaling-redis-cluster-mode-enabled.md)  | 
|  Scaling out  |  [Adding nodes to a cluster](Clusters.html#AddNode)  |  [Online resharding for Valkey or Redis OSS (cluster mode enabled)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)  | 
|  Changing node types  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/scaling-redis-classic.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/scaling-redis-classic.html)  |  [Online vertical scaling by modifying node type](redis-cluster-vertical-scaling.md)  | 
|  Changing the number of node groups  |  Not supported for Valkey or Redis OSS (cluster mode disabled) clusters  |  [Scaling Valkey or Redis OSS (Cluster Mode Enabled) clusters](scaling-redis-cluster-mode-enabled.md)  | 

**Contents**
+ [

## Scaling for Valkey or Redis OSS (Cluster Mode Disabled) clusters
](#Scaling.RedisStandalone)
  + [

### Scaling up single-node Valkey or Redis OSS clusters
](#Scaling.RedisStandalone.ScaleUp)
    + [

#### Scaling up single-node Valkey or Redis OSS (Cluster Mode Disabled) (Console) clusters
](#Scaling.RedisStandalone.ScaleUp.CON)
    + [

#### Scaling up single-node Valkey or Redis OSS clusters (AWS CLI)
](#Scaling.RedisStandalone.ScaleUp.CLI)
    + [

#### Scaling up single-node Valkey or Redis OSS clusters (ElastiCache API)
](#Scaling.RedisStandalone.ScaleUp.API)
  + [

### Scaling down single-node Valkey or Redis OSS clusters
](#Scaling.RedisStandalone.ScaleDown)
    + [

#### Scaling down a single-node Valkey or Redis OSS cluster (Console)
](#Scaling.RedisStandalone.ScaleDown.CON)
    + [

#### Scaling down single-node Valkey or Redis OSS clusters (AWS CLI)
](#Scaling.RedisStandalone.ScaleUpDown-Modify.CLI)
    + [

#### Scaling down single-node Valkey or Redis OSS clusters (ElastiCache API)
](#Scaling.RedisStandalone.ScaleDown.API)

## Scaling for Valkey or Redis OSS (Cluster Mode Disabled) clusters
Scaling single-node clusters for Valkey or Redis OSS (Cluster Mode Disabled)

Valkey or Redis OSS (cluster mode disabled) nodes must be large enough to contain all the cache's data plus the Valkey or Redis OSS overhead. To change the data capacity of your Valkey or Redis OSS (cluster mode disabled) cluster, you must scale vertically; scaling up to a larger node type to increase data capacity, or scaling down to a smaller node type to reduce data capacity.

The ElastiCache scaling up process is designed to make a best effort to retain your existing data and requires successful Valkey or Redis OSS replication. For Valkey or Redis OSS (cluster mode disabled) clusters, we recommend that sufficient memory be made available to Valkey or Redis OSS. 

You cannot partition your data across multiple Valkey or Redis OSS (cluster mode disabled) clusters. However, if you only need to increase or decrease your cluster's read capacity, you can create a Valkey or Redis OSS (cluster mode disabled) cluster with replica nodes and add or remove read replicas. To create a Valkey or Redis OSS (cluster mode disabled) cluster with replica nodes using your single-node Valkey or Redis OSS cluster as the primary cluster, see [Creating a Valkey (cluster mode disabled) cluster (Console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs).

After you create the cluster with replicas, you can increase read capacity by adding read replicas. Later, if you need to, you can reduce read capacity by removing read replicas. For more information, see [Increasing read capacity](Scaling.RedisReplGrps.md#Scaling.RedisReplGrps.ScaleOut) or [Decreasing read capacity](Scaling.RedisReplGrps.md#Scaling.RedisReplGrps.ScaleIn).

In addition to being able to scale read capacity, Valkey or Redis OSS (cluster mode disabled) clusters with replicas provide other business advantages. For more information, see [High availability using replication groups](Replication.md).

**Important**  
If your parameter group uses `reserved-memory` to set aside memory for Valkey or Redis OSS overhead, before you begin scaling be sure that you have a custom parameter group that reserves the correct amount of memory for your new node type. Alternatively, you can modify a custom parameter group so that it uses `reserved-memory-percent` and use that parameter group for your new cluster.  
If you're using `reserved-memory-percent`, doing this is not necessary.   
For more information, see [Managing reserved memory for Valkey and Redis OSS](redis-memory-management.md).

**Topics**
+ [

### Scaling up single-node Valkey or Redis OSS clusters
](#Scaling.RedisStandalone.ScaleUp)
+ [

### Scaling down single-node Valkey or Redis OSS clusters
](#Scaling.RedisStandalone.ScaleDown)

### Scaling up single-node Valkey or Redis OSS clusters
Scaling up single-node Valkey or Redis OSS clusters

When you scale up a single-node Valkey or Redis OSS cluster, ElastiCache performs the following process, whether you use the ElastiCache console, the AWS CLI, or the ElastiCache API.

1. A new cluster with the new node type is spun up in the same Availability Zone as the existing cluster.

1. The cache data in the existing cluster is copied to the new cluster. How long this process takes depends upon your node type and how much data is in the cluster.

1. Reads and writes are now served using the new cluster. Because the new cluster's endpoints are the same as they were for the old cluster, you do not need to update the endpoints in your application. You will notice a brief interruption (a few seconds) of reads and writes from the primary node while the DNS entry is updated.

1. ElastiCache deletes the old cluster. You will notice a brief interruption (a few seconds) of reads and writes from the old node because the connections to the old node will be disconnected. 

**Note**  
For clusters running the r6gd node type, you can only scale to node sizes within the r6gd node family.

As shown in the following table, your Valkey or Redis OSS scale-up operation is blocked if you have an engine upgrade scheduled for the next maintenance window. For more information on Maintenance Windows, see [Managing ElastiCache cluster maintenance](maintenance-window.md).


**Blocked Valkey or Redis OSS operations**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/scaling-redis-classic.html)

If you have a pending operation that is blocking you, you can do one of the following.
+ Schedule your Valkey or Redis OSS scale-up operation for the next maintenance window by clearing the **Apply immediately** check box (CLI use: `--no-apply-immediately`, API use: `ApplyImmediately=false`).
+ Wait until your next maintenance window (or after) to perform your Valkey or Redis OSS scale up operation.
+ Add the Valkey or Redis OSS engine upgrade to this cluster modification with the **Apply Immediately** check box chosen (CLI use: `--apply-immediately`, API use: `ApplyImmediately=true`). This unblocks your scale up operation by causing the engine upgrade to be performed immediately.

You can scale up a single-node Valkey or Redis OSS (cluster mode disabled) cluster using the ElastiCache console, the AWS CLI, or ElastiCache API.

**Important**  
If your parameter group uses `reserved-memory` to set aside memory for Valkey or Redis OSS overhead, before you begin scaling be sure that you have a custom parameter group that reserves the correct amount of memory for your new node type. Alternatively, you can modify a custom parameter group so that it uses `reserved-memory-percent` and use that parameter group for your new cluster.  
If you're using `reserved-memory-percent`, doing this is not necessary.   
For more information, see [Managing reserved memory for Valkey and Redis OSS](redis-memory-management.md).

#### Scaling up single-node Valkey or Redis OSS (Cluster Mode Disabled) (Console) clusters
Scaling up single-node Valkey or Redis OSS clusters (Console)

The following procedure describes how to scale up a single-node Valkey or Redis OSS cluster using the ElastiCache Management Console. During this process, your Valkey or Redis OSS cluster will continue to serve requests with minimal downtime.

**To scale up a single-node Valkey or Redis OSS cluster (console)**

1. Sign in to the AWS Management Console and open the ElastiCache console at [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).

1. From the navigation pane, choose **Valkey or Redis OSS clusters**.

1. From the list of clusters, choose the cluster you want to scale up (it must be running the Valkey or Redis OSS engine, not the clustered Valkey or Redis OSS engine). 

1. Choose **Modify**.

1. In the **Modify Cluster** wizard:

   1. Choose the node type you want to scale to from the **Node type** list.

   1. If you're using `reserved-memory` to manage your memory, from the **Parameter Group** list, choose the custom parameter group that reserves the correct amount of memory for your new node type.

1. If you want to perform the scale up process right away, choose the **Apply immediately** box. If the **Apply immediately** box is not chosen, the scale-up process is performed during this cluster's next maintenance window.

1. Choose **Modify**.

   If you chose **Apply immediately** in the previous step, 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 single-node Valkey or Redis OSS clusters (AWS CLI)


The following procedure describes how to scale up a single-node Valkey or Redis OSS cluster using the AWS CLI. During this process, your Valkey or Redis OSS cluster will continue to serve requests with minimal downtime.

**To scale up a single-node Valkey or Redis OSS cluster (AWS CLI)**

1. Determine the node types you can scale up to by running the AWS CLI `list-allowed-node-type-modifications` command with the following parameter.
   + `--cache-cluster-id`

   For Linux, macOS, or Unix:

   ```
   aws elasticache list-allowed-node-type-modifications \
   	    --cache-cluster-id my-cache-cluster-id
   ```

   For Windows:

   ```
   aws elasticache list-allowed-node-type-modifications ^
   	    --cache-cluster-id my-cache-cluster-id
   ```

   Output from the above command looks something like this (JSON format).

   ```
   {
   	    "ScaleUpModifications": [
   	        "cache.m3.2xlarge", 
   	        "cache.m3.large", 
   	        "cache.m3.xlarge", 
   	        "cache.m4.10xlarge", 
   	        "cache.m4.2xlarge", 
   	        "cache.m4.4xlarge", 
   	        "cache.m4.large", 
   	        "cache.m4.xlarge", 
   	        "cache.r3.2xlarge", 
   	        "cache.r3.4xlarge", 
   	        "cache.r3.8xlarge", 
   	        "cache.r3.large", 
   	        "cache.r3.xlarge"
   	    ]
   	       "ScaleDownModifications": [
   	        "cache.t2.micro", 
   	        "cache.t2.small ", 
   	        "cache.t2.medium ",
               "cache.t1.small ",
   	    ], 
   
   	}
   ```

   For more information, see [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) in the *AWS CLI Reference*.

1. Modify your existing cluster specifying the cluster to scale up and the new, larger node type, using the AWS CLI `modify-cache-cluster` command and the following parameters.
   + `--cache-cluster-id` – The name of the cluster you are scaling up. 
   + `--cache-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-modifications` command in step 1.
   + `--cache-parameter-group-name` – [Optional] Use this parameter if you are using `reserved-memory` to manage your cluster's reserved memory. Specify a custom cache parameter group that reserves the correct amount of memory for your new node type. If you are using `reserved-memory-percent` you can omit this parameter.
   + `--apply-immediately` – Causes the scale-up process to be applied immediately. To postpone the scale-up process to the cluster's next maintenance window, use the `--no-apply-immediately` parameter.

   For Linux, macOS, or Unix:

   ```
   aws elasticache modify-cache-cluster \
   	    --cache-cluster-id my-redis-cache-cluster \
   	    --cache-node-type cache.m3.xlarge \
   	    --cache-parameter-group-name redis32-m2-xl \
   	    --apply-immediately
   ```

   For Windows:

   ```
   aws elasticache modify-cache-cluster ^
   	    --cache-cluster-id my-redis-cache-cluster ^
   	    --cache-node-type cache.m3.xlarge ^
   	    --cache-parameter-group-name redis32-m2-xl ^
   	    --apply-immediately
   ```

   Output from the above command looks something like this (JSON format).

   ```
   {
   	    "CacheCluster": {
   	        "Engine": "redis", 
   	        "CacheParameterGroup": {
   	            "CacheNodeIdsToReboot": [], 
   	            "CacheParameterGroupName": "default.redis6.x", 
   	            "ParameterApplyStatus": "in-sync"
   	        }, 
   	        "SnapshotRetentionLimit": 1, 
   	        "CacheClusterId": "my-redis-cache-cluster", 
   	        "CacheSecurityGroups": [], 
   	        "NumCacheNodes": 1, 
   	        "SnapshotWindow": "00:00-01:00", 
   	        "CacheClusterCreateTime": "2017-02-21T22:34:09.645Z", 
   	        "AutoMinorVersionUpgrade": true, 
   	        "CacheClusterStatus": "modifying", 
   	        "PreferredAvailabilityZone": "us-west-2a", 
   	        "ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/home#client-download:", 
   	        "CacheSubnetGroupName": "default", 
   	        "EngineVersion": "6.0", 
   	        "PendingModifiedValues": {
   	            "CacheNodeType": "cache.m3.2xlarge"
   	        }, 
   	        "PreferredMaintenanceWindow": "tue:11:30-tue:12:30", 
   	        "CacheNodeType": "cache.m3.medium",
   	         "DataTiering": "disabled"
   	    }
   	}
   ```

   For more information, see [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html) in the *AWS CLI Reference*.

1. If you used the `--apply-immediately`, check the status of the new cluster using the AWS CLI `describe-cache-clusters` command with the following parameter. When the status changes to *available*, you can begin using the new, larger cluster.
   + `--cache-cluster-id` – The name of your single-node Valkey or Redis OSS cluster. Use this parameter to describe a particular cluster rather than all clusters.

   ```
   aws elasticache describe-cache-clusters --cache-cluster-id my-redis-cache-cluster
   ```

   For more information, see [describe-cache-clusters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-clusters.html) in the *AWS CLI Reference*.

#### Scaling up single-node Valkey or Redis OSS clusters (ElastiCache API)


The following procedure describes how to scale up a single-node Valkey or Redis OSS cluster using the ElastiCache API. During this process, your Valkey or Redis OSS cluster will continue to serve requests with minimal downtime.

**To scale up a single-node Valkey or Redis OSS cluster (ElastiCache API)**

1. Determine the node types you can scale up to by running the ElastiCache API `ListAllowedNodeTypeModifications` action with the following parameter.
   + `CacheClusterId` – The name of the single-node Valkey or Redis OSS cluster you want to scale up.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=ListAllowedNodeTypeModifications
   	   &CacheClusterId=MyRedisCacheCluster
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) in the *Amazon ElastiCache API Reference*.

1. Modify your existing cluster specifying the cluster to scale up and the new, larger node type, using the `ModifyCacheCluster` ElastiCache API action and the following parameters.
   + `CacheClusterId` – The name of the cluster you are scaling up.
   + `CacheNodeType` – The new, larger node type you want to scale the cluster up to. This value must be one of the node types returned by the `ListAllowedNodeTypeModifications` action in the previous step.
   + `CacheParameterGroupName` – [Optional] Use this parameter if you are using `reserved-memory` to manage your cluster's reserved memory. Specify a custom cache parameter group that reserves the correct amount of memory for your new node type. If you are using `reserved-memory-percent` you can omit this parameter.
   + `ApplyImmediately` – Set to `true` to cause the scale-up process to be performed immediately. To postpone the scale-up process to the cluster's next maintenance window, use `ApplyImmediately``=false`.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=ModifyCacheCluster
   	   &ApplyImmediately=true
   	   &CacheClusterId=MyRedisCacheCluster
   	   &CacheNodeType=cache.m3.xlarge
   	   &CacheParameterGroupName redis32-m2-xl
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) in the *Amazon ElastiCache API Reference*.

1. If you used `ApplyImmediately``=true`, check the status of the new cluster using the ElastiCache API `DescribeCacheClusters` action with the following parameter. When the status changes to *available*, you can begin using the new, larger cluster.
   + `CacheClusterId` – The name of your single-node Valkey or Redis OSS cluster. Use this parameter to describe a particular cluster rather than all clusters.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=DescribeCacheClusters
   	   &CacheClusterId=MyRedisCacheCluster
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [DescribeCacheClusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheClusters.html) in the *Amazon ElastiCache API Reference*.

### Scaling down single-node Valkey or Redis OSS clusters
Scaling down single-node Valkey or Redis OSS clusters

The following sections walk you through how to scale a single-node Valkey or Redis OSS cluster down to a smaller node type. Ensuring that the new, smaller node type is large enough to accommodate all the data and Valkey or Redis OSS overhead is important to the long-term success of your new Valkey or Redis OSS cluster. For more information, see [Ensuring you have enough memory to make a Valkey or Redis OSS snapshot](BestPractices.BGSAVE.md).

**Note**  
For clusters running the r6gd node type, you can only scale to node sizes within the r6gd node family.

**Topics**
+ [

#### Scaling down a single-node Valkey or Redis OSS cluster (Console)
](#Scaling.RedisStandalone.ScaleDown.CON)
+ [

#### Scaling down single-node Valkey or Redis OSS clusters (AWS CLI)
](#Scaling.RedisStandalone.ScaleUpDown-Modify.CLI)
+ [

#### Scaling down single-node Valkey or Redis OSS clusters (ElastiCache API)
](#Scaling.RedisStandalone.ScaleDown.API)

#### Scaling down a single-node Valkey or Redis OSS cluster (Console)


The following procedure walks you through scaling your single-node Valkey or Redis OSS cluster down to a smaller node type using the ElastiCache console.

**Important**  
If your parameter group uses `reserved-memory` to set aside memory for Valkey or Redis OSS overhead, before you begin scaling be sure that you have a custom parameter group that reserves the correct amount of memory for your new node type. Alternatively, you can modify a custom parameter group so that it uses `reserved-memory-percent` and use that parameter group for your new cluster.  
If you're using `reserved-memory-percent`, doing this is not necessary.   
For more information, see [Managing reserved memory for Valkey and Redis OSS](redis-memory-management.md).

**To scale down your single-node Valkey or Redis OSS cluster (console)**

1. Ensure that the smaller node type is adequate for your data and overhead needs. 

1. If your parameter group uses `reserved-memory` to set aside memory for Valkey or Redis OSS overhead, ensure that you have a custom parameter group to set aside the correct amount of memory for your new node type.

   Alternatively, you can modify your custom parameter group to use `reserved-memory-percent`. For more information, see [Managing reserved memory for Valkey and Redis OSS](redis-memory-management.md).

1. Sign in to the AWS Management Console and open the ElastiCache console at [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).

1. From the list of clusters, choose the cluster you want to scale down. This cluster must be running the Valkey or Redis OSS engine and not the clustered Valkey or Redis OSS engine.

1. Choose **Modify**.

1. In the **Modify Cluster** wizard:

   1. Choose the node type you want to scale down to from the **Node type** list.

   1. If you're using `reserved-memory` to manage your memory, from the **Parameter Group** list, choose the custom parameter group that reserves the correct amount of memory for your new node type.

1. If you want to perform the scale-down process right away, choose the **Apply immediately** check box. If the **Apply immediately** check box is left not chosen, the scale-down process is performed during this cluster's next maintenance window.

1. Choose **Modify**.

1. When the cluster’s status changes from *modifying* to *available*, your cluster has scaled to the new node type. There is no need to update the endpoints in your application.

#### Scaling down single-node Valkey or Redis OSS clusters (AWS CLI)


The following procedure describes how to scale down a single-node Valkey or Redis OSS cluster using the AWS CLI. 

**To scale down a single-node Valkey or Redis OSS cluster (AWS CLI)**

1. Determine the node types you can scale down to by running the AWS CLI `list-allowed-node-type-modifications` command with the following parameter.
   + `--cache-cluster-id`

   For Linux, macOS, or Unix:

   ```
   aws elasticache list-allowed-node-type-modifications \
   	    --cache-cluster-id my-cache-cluster-id
   ```

   For Windows:

   ```
   aws elasticache list-allowed-node-type-modifications ^
   	    --cache-cluster-id my-cache-cluster-id
   ```

   Output from the above command looks something like this (JSON format).

   ```
   {
   	    "ScaleUpModifications": [
   	        "cache.m3.2xlarge", 
   	        "cache.m3.large", 
   	        "cache.m3.xlarge", 
   	        "cache.m4.10xlarge", 
   	        "cache.m4.2xlarge", 
   	        "cache.m4.4xlarge", 
   	        "cache.m4.large", 
   	        "cache.m4.xlarge", 
   	        "cache.r3.2xlarge", 
   	        "cache.r3.4xlarge", 
   	        "cache.r3.8xlarge", 
   	        "cache.r3.large", 
   	        "cache.r3.xlarge"
   	    ]
   	       "ScaleDownModifications": [
   	        "cache.t2.micro", 
   	        "cache.t2.small ", 
   	        "cache.t2.medium ",
               "cache.t1.small ",
   	    ], 
   
   	}
   ```

   For more information, see [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) in the *AWS CLI Reference*.

1. Modify your existing cluster specifying the cluster to scale down and the new, smaller node type, using the AWS CLI `modify-cache-cluster` command and the following parameters.
   + `--cache-cluster-id` – The name of the cluster you are scaling down. 
   + `--cache-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-modifications` command in step 1.
   + `--cache-parameter-group-name` – [Optional] Use this parameter if you are using `reserved-memory` to manage your cluster's reserved memory. Specify a custom cache parameter group that reserves the correct amount of memory for your new node type. If you are using `reserved-memory-percent` you can omit this parameter.
   + `--apply-immediately` – Causes the scale-down process to be applied immediately. To postpone the scale-up process to the cluster's next maintenance window, use the `--no-apply-immediately` parameter.

   For Linux, macOS, or Unix:

   ```
   aws elasticache modify-cache-cluster \
   	    --cache-cluster-id my-redis-cache-cluster \
   	    --cache-node-type cache.m3.xlarge \
   	    --cache-parameter-group-name redis32-m2-xl \
   	    --apply-immediately
   ```

   For Windows:

   ```
   aws elasticache modify-cache-cluster ^
   	    --cache-cluster-id my-redis-cache-cluster ^
   	    --cache-node-type cache.m3.xlarge ^
   	    --cache-parameter-group-name redis32-m2-xl ^
   	    --apply-immediately
   ```

   Output from the above command looks something like this (JSON format).

   ```
   {
   	    "CacheCluster": {
   	        "Engine": "redis", 
   	        "CacheParameterGroup": {
   	            "CacheNodeIdsToReboot": [], 
   	            "CacheParameterGroupName": "default.redis6,x", 
   	            "ParameterApplyStatus": "in-sync"
   	        }, 
   	        "SnapshotRetentionLimit": 1, 
   	        "CacheClusterId": "my-redis-cache-cluster", 
   	        "CacheSecurityGroups": [], 
   	        "NumCacheNodes": 1, 
   	        "SnapshotWindow": "00:00-01:00", 
   	        "CacheClusterCreateTime": "2017-02-21T22:34:09.645Z", 
   	        "AutoMinorVersionUpgrade": true, 
   	        "CacheClusterStatus": "modifying", 
   	        "PreferredAvailabilityZone": "us-west-2a", 
   	        "ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/home#client-download:", 
   	        "CacheSubnetGroupName": "default", 
   	        "EngineVersion": "6.0", 
   	        "PendingModifiedValues": {
   	            "CacheNodeType": "cache.m3.2xlarge"
   	        }, 
   	        "PreferredMaintenanceWindow": "tue:11:30-tue:12:30", 
   	        "CacheNodeType": "cache.m3.medium",
   	         "DataTiering": "disabled"
   	    }
   	}
   ```

   For more information, see [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html) in the *AWS CLI Reference*.

1. If you used the `--apply-immediately`, check the status of the new cluster using the AWS CLI `describe-cache-clusters` command with the following parameter. When the status changes to *available*, you can begin using the new, larger cluster.
   + `--cache-cluster-id` – The name of your single-node Valkey or Redis OSS cluster. Use this parameter to describe a particular cluster rather than all clusters.

   ```
   aws elasticache describe-cache-clusters --cache-cluster-id my-redis-cache-cluster
   ```

   For more information, see [describe-cache-clusters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-clusters.html) in the *AWS CLI Reference*.

#### Scaling down single-node Valkey or Redis OSS clusters (ElastiCache API)


The following procedure describes how to scale updown a single-node Valkey or Redis OSS cluster using the ElastiCache API. 

**To scale down a single-node Valkey or Redis OSS cluster (ElastiCache API)**

1. Determine the node types you can scale down to by running the ElastiCache API `ListAllowedNodeTypeModifications` action with the following parameter.
   + `CacheClusterId` – The name of the single-node Valkey or Redis OSS cluster you want to scale down.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=ListAllowedNodeTypeModifications
   	   &CacheClusterId=MyRedisCacheCluster
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) in the *Amazon ElastiCache API Reference*.

1. Modify your existing cluster specifying the cluster to scale up and the new, larger node type, using the `ModifyCacheCluster` ElastiCache API action and the following parameters.
   + `CacheClusterId` – The name of the cluster you are scaling down.
   + `CacheNodeType` – The new, smaller node type you want to scale the cluster down to. This value must be one of the node types returned by the `ListAllowedNodeTypeModifications` action in previous step.
   + `CacheParameterGroupName` – [Optional] Use this parameter if you are using `reserved-memory` to manage your cluster's reserved memory. Specify a custom cache parameter group that reserves the correct amount of memory for your new node type. If you are using `reserved-memory-percent` you can omit this parameter.
   + `ApplyImmediately` – Set to `true` to cause the scale-down process to be performed immediately. To postpone the scale-up process to the cluster's next maintenance window, use `ApplyImmediately``=false`.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=ModifyCacheCluster
   	   &ApplyImmediately=true
   	   &CacheClusterId=MyRedisCacheCluster
   	   &CacheNodeType=cache.m3.xlarge
   	   &CacheParameterGroupName redis32-m2-xl
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) in the *Amazon ElastiCache API Reference*.

1. If you used `ApplyImmediately``=true`, check the status of the new cluster using the ElastiCache API `DescribeCacheClusters` action with the following parameter. When the status changes to *available*, you can begin using the new, smaller cluster.
   + `CacheClusterId` – The name of your single-node Valkey or Redis OSS cluster. Use this parameter to describe a particular cluster rather than all clusters.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=DescribeCacheClusters
   	   &CacheClusterId=MyRedisCacheCluster
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [DescribeCacheClusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheClusters.html) in the *Amazon ElastiCache API Reference*.

# Scaling replica nodes for Valkey or Redis OSS (Cluster Mode Disabled)


A Valkey or Redis OSS cluster with replica nodes (called *replication group* in the API/CLI) provides high availability via replication that has Multi-AZ with automatic failover enabled. A cluster with replica nodes is a logical collection of up to six Valkey or Redis OSS nodes where one node, the Primary, is able to serve both read and write requests. All the other nodes in the cluster are read-only replicas of the Primary. Data written to the Primary is asynchronously replicated to all the read replicas in the cluster. Because Valkey or Redis OSS (cluster mode disabled) does not support partitioning your data across multiple clusters, each node in a Valkey or Redis OSS (cluster mode disabled) replication group contains the entire cache dataset. Valkey or Redis OSS (cluster mode enabled) clusters support partitioning your data across up to 500 shards.

To change the data capacity of your cluster you must scale it up to a larger node type, or down to a smaller node type.

To change the read capacity of your cluster, add more read replicas, up to a maximum of 5, or remove read replicas.

The ElastiCache scaling up process is designed to make a best effort to retain your existing data and requires successful Valkey or Redis OSS replication. For Valkey or Redis OSS clusters with replicas, we recommend that sufficient memory be made available to Valkey or Redis OSS. 

**Topics**
+ [

## Scaling up Valkey or Redis OSS clusters with replicas
](#Scaling.RedisReplGrps.ScaleUp)
+ [

## Scaling down Valkey or Redis OSS clusters with replicas
](#Scaling.RedisReplGrps.ScaleDown)
+ [

## Increasing read capacity
](#Scaling.RedisReplGrps.ScaleOut)
+ [

## Decreasing read capacity
](#Scaling.RedisReplGrps.ScaleIn)

**Related Topics**
+ [High availability using replication groups](Replication.md)
+ [Replication: Valkey and Redis OSS Cluster Mode Disabled vs. Enabled](Replication.Redis-RedisCluster.md)
+ [Minimizing downtime in ElastiCache by using Multi-AZ with Valkey and Redis OSS](AutoFailover.md)
+ [Ensuring you have enough memory to make a Valkey or Redis OSS snapshot](BestPractices.BGSAVE.md)

**Topics**
+ [

## Scaling up Valkey or Redis OSS clusters with replicas
](#Scaling.RedisReplGrps.ScaleUp)
+ [

## Scaling down Valkey or Redis OSS clusters with replicas
](#Scaling.RedisReplGrps.ScaleDown)
+ [

## Increasing read capacity
](#Scaling.RedisReplGrps.ScaleOut)
+ [

## Decreasing read capacity
](#Scaling.RedisReplGrps.ScaleIn)

## Scaling up Valkey or Redis OSS clusters with replicas


Amazon ElastiCache provides console, CLI, and API support for scaling your Valkey or Redis OSS (cluster mode disabled) replication group up. 

When the scale-up process is initiated, ElastiCache does the following:

1. Launches a replication group using the new node type.

1. Copies all the data from the current primary node to the new primary node.

1. Syncs the new read replicas with the new primary node.

1. Updates the DNS entries so they point to the new nodes. Because of this you don't have to update the endpoints in your application. For Valkey 7.2 and above or Redis OSS 5.0.5 and above, you can scale auto failover enabled clusters while the cluster continues to stay online and serve incoming requests. On Redis OSS version 4.0.10 and below, you may notice a brief interruption of reads and writes on previous versions from the primary node while the DNS entry is updated. 

1. Deletes the old nodes (CLI/API: replication group). You will notice a brief interruption (a few seconds) of reads and writes from the old nodes because the connections to the old nodes will be disconnected.

How long this process takes is dependent upon your node type and how much data is in your cluster.

As shown in the following table, your Valkey or Redis OSS scale-up operation is blocked if you have an engine upgrade scheduled for the cluster’s next maintenance window.


**Blocked Valkey or Redis OSS operations**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Scaling.RedisReplGrps.html)

If you have a pending operation that is blocking you, you can do one of the following.
+ Schedule your Valkey or Redis OSS scale-up operation for the next maintenance window by clearing the **Apply immediately** check box (CLI use: `--no-apply-immediately`, API use: `ApplyImmediately=false`).
+ Wait until your next maintenance window (or after) to perform your Valkey or Redis OSS scale-up operation.
+ Add the Valkey or Redis OSS engine upgrade to this cluster modification with the **Apply Immediately** check box chosen (CLI use: `--apply-immediately`, API use: `ApplyImmediately=true`). This unblocks your scale-up operation by causing the engine upgrade to be performed immediately.

The following sections describe how to scale your Valkey or Redis OSS cluster with replicas up using the ElastiCache console, the AWS CLI, and the ElastiCache API.

**Important**  
If your parameter group uses `reserved-memory` to set aside memory for Valkey or Redis OSS overhead, before you begin scaling be sure that you have a custom parameter group that reserves the correct amount of memory for your new node type. Alternatively, you can modify a custom parameter group so that it uses `reserved-memory-percent` and use that parameter group for your new cluster.  
If you're using `reserved-memory-percent`, doing this is not necessary.   
For more information, see [Managing reserved memory for Valkey and Redis OSS](redis-memory-management.md).

### Scaling up a Valkey or Redis OSS cluster with replicas (Console)


The amount of time it takes to scale up to a larger node type varies, depending upon the node type and the amount of data in your current cluster.

The following process scales your cluster with replicas from its current node type to a new, larger node type using the ElastiCache console. During this process, there may be a brief interruption of reads and writes for other versions from the primary node while the DNS entry is updated. you might see less than 1 second downtime for nodes running on 5.0.6 versions and above and a few seconds for older versions. 

**To scale up Valkey or Redis OSS cluster with replicas (console)**

1. Sign in to the AWS Management Console and open the ElastiCache console at [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).

1. From the navigation pane, choose **Valkey clusters** or **Redis OSS clusters**

1. From the list of clusters, choose the cluster you want to scale up. This cluster must be running the Valkey or Redis OSS engine and not the clustered Valkey or Redis OSS engine.

1. Choose **Modify**.

1. In the **Modify Cluster** wizard:

   1. Choose the node type you want to scale to from the **Node type** list. Note that not all node types are available to scale down to.

   1. If you're using `reserved-memory` to manage your memory, from the **Parameter Group** list, choose the custom parameter group that reserves the correct amount of memory for your new node type.

1. If you want to perform the scale-up process right away, choose the **Apply immediately** check box. If the **Apply immediately** check box is left not chosen, the scale-up process is performed during this cluster's next maintenance window.

1. Choose **Modify**.

1. When the cluster’s status changes from *modifying* to *available*, your cluster has scaled to the new node type. There is no need to update the endpoints in your application.

### Scaling up a Valkey or Redis OSS replication group (AWS CLI)


The following process scales your replication group from its current node type to a new, larger node type using the AWS CLI. During this process, ElastiCache updates the DNS entries so they point to the new nodes. Because of this you don't have to update the endpoints in your application. For Valkey 7.2 and above or Redis OSS 5.0.5 and above, you can scale auto failover enabled clusters while the cluster continues to stay online and serve incoming requests. On version 4.0.10 and below, you may notice a brief interruption of reads and writes on previous versions from the primary node while the DNS entry is updated..

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 Valkey or Redis OSS Replication Group (AWS CLI)**

1. Determine which node types you can scale up to by running the AWS CLI `list-allowed-node-type-modifications` command with the following parameter.
   + `--replication-group-id` – the name of the replication group. Use this parameter to describe a particular replication group rather than all replication groups.

   For Linux, macOS, or Unix:

   ```
   aws elasticache list-allowed-node-type-modifications \
   	    --replication-group-id my-repl-group
   ```

   For Windows:

   ```
   aws elasticache list-allowed-node-type-modifications ^
   	    --replication-group-id my-repl-group
   ```

   Output from this operation looks something like this (JSON format).

   ```
   {
   	    "ScaleUpModifications": [
   	        "cache.m3.2xlarge", 
   	        "cache.m3.large", 
   	        "cache.m3.xlarge", 
   	        "cache.m4.10xlarge", 
   	        "cache.m4.2xlarge", 
   	        "cache.m4.4xlarge", 
   	        "cache.m4.large", 
   	        "cache.m4.xlarge", 
   	        "cache.r3.2xlarge", 
   	        "cache.r3.4xlarge", 
   	        "cache.r3.8xlarge", 
   	        "cache.r3.large", 
   	        "cache.r3.xlarge"
   	    ]
   	}
   ```

   For more information, see [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) in the *AWS CLI Reference*.

1. Scale your current replication group up to the new node type using the AWS CLI `modify-replication-group` command with the following parameters.
   + `--replication-group-id` – the name of the replication group.
   + `--cache-node-type` – the new, larger node type of the clusters in this replication group. This value must be one of the instance types returned by the `list-allowed-node-type-modifications` command in the previous step.
   + `--cache-parameter-group-name` – [Optional] Use this parameter if you are using `reserved-memory` to manage your cluster's reserved memory. Specify a custom cache parameter group that reserves the correct amount of memory for your new node type. If you are using `reserved-memory-percent` you can omit this parameter.
   + `--apply-immediately` – Causes the scale-up process to be applied immediately. To postpone the scale-up operation to the next maintenance window, use `--no-apply-immediately`.

   For Linux, macOS, or Unix:

   ```
   aws elasticache modify-replication-group \
   	    --replication-group-id my-repl-group \
   	    --cache-node-type cache.m3.xlarge \
   	    --cache-parameter-group-name redis32-m3-2xl \
   	    --apply-immediately
   ```

   For Windows:

   ```
   aws elasticache modify-replication-group ^
   	    --replication-group-id my-repl-group ^
   	    --cache-node-type cache.m3.xlarge ^
   	    --cache-parameter-group-name redis32-m3-2xl \
   	    --apply-immediately
   ```

   Output from this command looks something like this (JSON format).

   ```
   {
   	"ReplicationGroup": {
   		"Status": "available",
   		"Description": "Some description",
   		"NodeGroups": [{
   			"Status": "available",
   			"NodeGroupMembers": [{
   					"CurrentRole": "primary",
   					"PreferredAvailabilityZone": "us-west-2b",
   					"CacheNodeId": "0001",
   					"ReadEndpoint": {
   						"Port": 6379,
   						"Address": "my-repl-group-001.8fdx4s.0001.usw2.cache.amazonaws.com"
   					},
   					"CacheClusterId": "my-repl-group-001"
   				},
   				{
   					"CurrentRole": "replica",
   					"PreferredAvailabilityZone": "us-west-2c",
   					"CacheNodeId": "0001",
   					"ReadEndpoint": {
   						"Port": 6379,
   						"Address": "my-repl-group-002.8fdx4s.0001.usw2.cache.amazonaws.com"
   					},
   					"CacheClusterId": "my-repl-group-002"
   				}
   			],
   			"NodeGroupId": "0001",
   			"PrimaryEndpoint": {
   				"Port": 6379,
   				"Address": "my-repl-group.8fdx4s.ng.0001.usw2.cache.amazonaws.com"
   			}
   		}],
   		"ReplicationGroupId": "my-repl-group",
   		"SnapshotRetentionLimit": 1,
   		"AutomaticFailover": "disabled",
   		"SnapshotWindow": "12:00-13:00",
   		"SnapshottingClusterId": "my-repl-group-002",
   		"MemberClusters": [
   			"my-repl-group-001",
   			"my-repl-group-002"
   		],
   		"PendingModifiedValues": {}
   	}
   }
   ```

   For more information, see [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) in the *AWS CLI Reference*.

1. If you used the `--apply-immediately` parameter, monitor the status of the replication group using the AWS CLI `describe-replication-group` command with the following parameter. While the status is still in *modifying*, you might see less than 1 second downtime for nodes running on 5.0.6 versions and above and a brief interruption of reads and writes for older versions from the primary node while the DNS entry is updated.
   + `--replication-group-id` – the name of the replication group. Use this parameter to describe a particular replication group rather than all replication groups.

   For Linux, macOS, or Unix:

   ```
   aws elasticache describe-replication-groups \
   	    --replication-group-id my-replication-group
   ```

   For Windows:

   ```
   aws elasticache describe-replication-groups ^
   	    --replication-group-id my-replication-group
   ```

   For more information, see [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html) in the *AWS CLI Reference*.

### Scaling up a Valkey or Redis OSS replication group (ElastiCache API)


The following process scales your replication group from its current node type to a new, larger node type using the ElastiCache API. For Valkey 7.2 and above or Redis OSS 5.0.5 and above, you can scale auto failover enabled clusters while the cluster continues to stay online and serve incoming requests. On version Redis OSS 4.0.10 and below, you may notice a brief interruption of reads and writes on previous versions from the primary node while the DNS entry is updated.

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 Valkey or Redis OSS Replication Group (ElastiCache API)**

1. Determine which node types you can scale up to using the ElastiCache API `ListAllowedNodeTypeModifications` action with the following parameter.
   + `ReplicationGroupId` – the name of the replication group. Use this parameter to describe a specific replication group rather than all replication groups.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=ListAllowedNodeTypeModifications
   	   &ReplicationGroupId=MyReplGroup
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) in the *Amazon ElastiCache API Reference*.

1. Scale your current replication group up to the new node type using the `ModifyReplicationGroup` ElastiCache API action and with the following parameters.
   + `ReplicationGroupId` – the name of the replication group.
   + `CacheNodeType` – the new, larger node type of the clusters in this replication group. This value must be one of the instance types returned by the `ListAllowedNodeTypeModifications` action in th previous step.
   + `CacheParameterGroupName` – [Optional] Use this parameter if you are using `reserved-memory` to manage your cluster's reserved memory. Specify a custom cache parameter group that reserves the correct amount of memory for your new node type. If you are using `reserved-memory-percent` you can omit this parameter.
   + `ApplyImmediately` – Set to `true` to causes the scale-up process to be applied immediately. To postpone the scale-up process to the next maintenance window, use `ApplyImmediately``=false`.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=ModifyReplicationGroup
   	   &ApplyImmediately=true
   	   &CacheNodeType=cache.m3.2xlarge
   	   &CacheParameterGroupName=redis32-m3-2xl
   	   &ReplicationGroupId=myReplGroup
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20141201T220302Z
   	   &Version=2014-12-01
   	   &X-Amz-Algorithm=&AWS;4-HMAC-SHA256
   	   &X-Amz-Date=20141201T220302Z
   	   &X-Amz-SignedHeaders=Host
   	   &X-Amz-Expires=20141201T220302Z
   	   &X-Amz-Credential=<credential>
   	   &X-Amz-Signature=<signature>
   ```

   For more information, see [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) in the *Amazon ElastiCache API Reference*.

1. If you used `ApplyImmediately``=true`, monitor the status of the replication group using the ElastiCache API `DescribeReplicationGroups` action with the following parameters. When the status changes from *modifying* to *available*, you can begin writing to your new, scaled up replication group.
   + `ReplicationGroupId` – the name of the replication group. Use this parameter to describe a particular replication group rather than all replication groups.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=DescribeReplicationGroups
   	   &ReplicationGroupId=MyReplGroup
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) in the *Amazon ElastiCache API Reference*.

## Scaling down Valkey or Redis OSS clusters with replicas


The following sections walk you through how to scale a Valkey or Redis OSS (cluster mode disabled) cluster with replica nodes down to a smaller node type. Ensuring that the new, smaller node type is large enough to accommodate all the data and overhead is very important to success. For more information, see [Ensuring you have enough memory to make a Valkey or Redis OSS snapshot](BestPractices.BGSAVE.md).

**Note**  
For clusters running the r6gd node type, you can only scale to node sizes within the r6gd node family.

**Important**  
If your parameter group uses `reserved-memory` to set aside memory for Valkey or Redis OSS overhead, before you begin scaling be sure that you have a custom parameter group that reserves the correct amount of memory for your new node type. Alternatively, you can modify a custom parameter group so that it uses `reserved-memory-percent` and use that parameter group for your new cluster.  
If you're using `reserved-memory-percent`, doing this is not necessary.   
For more information, see [Managing reserved memory for Valkey and Redis OSS](redis-memory-management.md).

**Topics**

### Scaling down a Valkey or Redis OSS cluster with replicas (Console)


The following process scales your Valkey or Redis OSS cluster with replica nodes to a smaller node type using the ElastiCache console.

**To scale down a Valkey or Redis OSS cluster with replica nodes (console)**

1. Ensure that the smaller node type is adequate for your data and overhead needs. 

1. If your parameter group uses `reserved-memory` to set aside memory for Valkey or Redis OSS overhead, ensure that you have a custom parameter group to set aside the correct amount of memory for your new node type.

   Alternatively, you can modify your custom parameter group to use `reserved-memory-percent`. For more information, see [Managing reserved memory for Valkey and Redis OSS](redis-memory-management.md).

1. Sign in to the AWS Management Console and open the ElastiCache console at [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).

1. From the list of clusters, choose the cluster you want to scale down. This cluster must be running the Valkey or Redis OSS engine and not the clustered Valkey or Redis OSS engine.

1. Choose **Modify**.

1. In the **Modify Cluster** wizard:

   1. Choose the node type you want to scale down to from the **Node type** list.

   1. If you're using `reserved-memory` to manage your memory, from the **Parameter Group** list, choose the custom parameter group that reserves the correct amount of memory for your new node type.

1. If you want to perform the scale-down process right away, choose the **Apply immediately** check box. If the **Apply immediately** check box is left not chosen, the scale-down process is performed during this cluster's next maintenance window.

1. Choose **Modify**.

1. When the cluster’s status changes from *modifying* to *available*, your cluster has scaled to the new node type. There is no need to update the endpoints in your application.

### Scaling down a Valkey or Redis OSS replication group (AWS CLI)


The following process scales your replication group from its current node type to a new, smaller node type using the AWS CLI. During this process, ElastiCache updates the DNS entries so they point to the new nodes. Because of this you don't have to update the endpoints in your application. For Valkey 7.2 above or Redis OSS 5.0.5 and above, you can scale auto failover enabled clusters while the cluster continues to stay online and serve incoming requests. On version 4.0.10 and below, you may notice a brief interruption of reads and writes on previous versions from the primary node while the DNS entry is updated..

However, reads from the read replica clusters continue uninterrupted.

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.

**To scale down a Valkey or Redis OSS Replication Group (AWS CLI)**

1. Determine which node types you can scale down to by running the AWS CLI `list-allowed-node-type-modifications` command with the following parameter.
   + `--replication-group-id` – the name of the replication group. Use this parameter to describe a particular replication group rather than all replication groups.

   For Linux, macOS, or Unix:

   ```
   aws elasticache list-allowed-node-type-modifications \
   	    --replication-group-id my-repl-group
   ```

   For Windows:

   ```
   aws elasticache list-allowed-node-type-modifications ^
   	    --replication-group-id my-repl-group
   ```

   Output from this operation looks something like this (JSON format).

   ```
   {
   	    "ScaleDownModifications": [
   	        "cache.m3.2xlarge", 
   	        "cache.m3.large", 
   	        "cache.m3.xlarge", 
   	        "cache.m4.10xlarge", 
   	        "cache.m4.2xlarge", 
   	        "cache.m4.4xlarge", 
   	        "cache.m4.large", 
   	        "cache.m4.xlarge", 
   	        "cache.r3.2xlarge", 
   	        "cache.r3.4xlarge", 
   	        "cache.r3.8xlarge", 
   	        "cache.r3.large", 
   	        "cache.r3.xlarge"
   	    ]
   	}
   ```

   For more information, see [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) in the *AWS CLI Reference*.

1. Scale your current replication group up to the new node type using the AWS CLI `modify-replication-group` command with the following parameters.
   + `--replication-group-id` – the name of the replication group.
   + `--cache-node-type` – the new, smaller node type of the clusters in this replication group. This value must be one of the instance types returned by the `list-allowed-node-type-modifications` command in the previous step.
   + `--cache-parameter-group-name` – [Optional] Use this parameter if you are using `reserved-memory` to manage your cluster's reserved memory. Specify a custom cache parameter group that reserves the correct amount of memory for your new node type. If you are using `reserved-memory-percent` you can omit this parameter.
   + `--apply-immediately` – Causes the scale-up process to be applied immediately. To postpone the scale-up operation to the next maintenance window, use `--no-apply-immediately`.

   For Linux, macOS, or Unix:

   ```
   aws elasticache modify-replication-group \
   	    --replication-group-id my-repl-group \
   	    --cache-node-type cache.t2.small  \
   	    --cache-parameter-group-name redis32-m3-2xl \
   	    --apply-immediately
   ```

   For Windows:

   ```
   aws elasticache modify-replication-group ^
   	    --replication-group-id my-repl-group ^
   	    --cache-node-type cache.t2.small  ^
   	    --cache-parameter-group-name redis32-m3-2xl \
   	    --apply-immediately
   ```

   Output from this command looks something like this (JSON format).

   ```
   {"ReplicationGroup": {
   	        "Status": "available", 
   	        "Description": "Some description", 
   	        "NodeGroups": [
   	            {
   	                "Status": "available", 
   	                "NodeGroupMembers": [
   	                    {
   	                        "CurrentRole": "primary", 
   	                        "PreferredAvailabilityZone": "us-west-2b", 
   	                        "CacheNodeId": "0001", 
   	                        "ReadEndpoint": {
   	                            "Port": 6379, 
   	                            "Address": "my-repl-group-001.8fdx4s.0001.usw2.cache.amazonaws.com"
   	                        }, 
   	                        "CacheClusterId": "my-repl-group-001"
   	                    }, 
   	                    {
   	                        "CurrentRole": "replica", 
   	                        "PreferredAvailabilityZone": "us-west-2c", 
   	                        "CacheNodeId": "0001", 
   	                        "ReadEndpoint": {
   	                            "Port": 6379, 
   	                            "Address": "my-repl-group-002.8fdx4s.0001.usw2.cache.amazonaws.com"
   	                        }, 
   	                        "CacheClusterId": "my-repl-group-002"
   	                    }
   	                ], 
   	                "NodeGroupId": "0001", 
   	                "PrimaryEndpoint": {
   	                    "Port": 6379, 
   	                    "Address": "my-repl-group.8fdx4s.ng.0001.usw2.cache.amazonaws.com"
   	                }
   	            }
   	        ], 
   	        "ReplicationGroupId": "my-repl-group", 
   	        "SnapshotRetentionLimit": 1, 
   	        "AutomaticFailover": "disabled", 
   	        "SnapshotWindow": "12:00-13:00", 
   	        "SnapshottingClusterId": "my-repl-group-002", 
   	        "MemberClusters": [
   	            "my-repl-group-001", 
   	            "my-repl-group-002", 
   	        ], 
   	        "PendingModifiedValues": {}
   	    }
   	}
   ```

   For more information, see [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) in the *AWS CLI Reference*.

1. If you used the `--apply-immediately` parameter, monitor the status of the replication group using the AWS CLI `describe-replication-group` command with the following parameter. When the status changes from *modifying* to *available*, you can begin writing to your new, scaled down replication group.
   + `--replication-group-id` – the name of the replication group. Use this parameter to describe a particular replication group rather than all replication groups.

   For Linux, macOS, or Unix:

   ```
   aws elasticache describe-replication-group \
   	    --replication-group-id my-replication-group
   ```

   For Windows:

   ```
   aws elasticache describe-replication-groups ^
   	    --replication-group-id my-replication-group
   ```

   For more information, see [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html) in the *AWS CLI Reference*.

### Scaling down a Valkey or Redis OSS replication group (ElastiCache API)


The following process scales your replication group from its current node type to a new, smaller node type using the ElastiCache API. During this process, ElastiCache updates the DNS entries so they point to the new nodes. Because of this you don't have to update the endpoints in your application. For Valkey 7.2 and above or Redis OSS 5.0.5 and above, you can scale auto failover enabled clusters while the cluster continues to stay online and serve incoming requests. On Redis OSS version 4.0.10 and below, you may notice a brief interruption of reads and writes on previous versions from the primary node while the DNS entry is updated.. However, reads from the read replica clusters continue uninterrupted.

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.

**To scale down a Valkey or Redis OSS Replication Group (ElastiCache API)**

1. Determine which node types you can scale down to using the ElastiCache API `ListAllowedNodeTypeModifications` action with the following parameter.
   + `ReplicationGroupId` – the name of the replication group. Use this parameter to describe a specific replication group rather than all replication groups.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=ListAllowedNodeTypeModifications
   	   &ReplicationGroupId=MyReplGroup
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) in the *Amazon ElastiCache API Reference*.

1. Scale your current replication group up to the new node type using the `ModifyReplicationGroup` ElastiCache API action and with the following parameters.
   + `ReplicationGroupId` – the name of the replication group.
   + `CacheNodeType` – the new, smaller node type of the clusters in this replication group. This value must be one of the instance types returned by the `ListAllowedNodeTypeModifications` action in the previous step.
   + `CacheParameterGroupName` – [Optional] Use this parameter if you are using `reserved-memory` to manage your cluster's reserved memory. Specify a custom cache parameter group that reserves the correct amount of memory for your new node type. If you are using `reserved-memory-percent` you can omit this parameter.
   + `ApplyImmediately` – Set to `true` to causes the scale-up process to be applied immediately. To postpone the scale-down process to the next maintenance window, use `ApplyImmediately``=false`.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=ModifyReplicationGroup
   	   &ApplyImmediately=true
   	   &CacheNodeType=cache.m3.2xlarge
   	   &CacheParameterGroupName=redis32-m3-2xl
   	   &ReplicationGroupId=myReplGroup
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20141201T220302Z
   	   &Version=2014-12-01
   	   &X-Amz-Algorithm=&AWS;4-HMAC-SHA256
   	   &X-Amz-Date=20141201T220302Z
   	   &X-Amz-SignedHeaders=Host
   	   &X-Amz-Expires=20141201T220302Z
   	   &X-Amz-Credential=<credential>
   	   &X-Amz-Signature=<signature>
   ```

   For more information, see [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) in the *Amazon ElastiCache API Reference*.

1. If you used `ApplyImmediately``=true`, monitor the status of the replication group using the ElastiCache API `DescribeReplicationGroups` action with the following parameters. When the status changes from *modifying* to *available*, you can begin writing to your new, scaled down replication group.
   + `ReplicationGroupId` – the name of the replication group. Use this parameter to describe a particular replication group rather than all replication groups.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=DescribeReplicationGroups
   	   &ReplicationGroupId=MyReplGroup
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) in the *Amazon ElastiCache API Reference*.

## Increasing read capacity


To increase read capacity, add read replicas (up to a maximum of five) to your Valkey or Redis OSS replication group.

You can scale your Valkey or Redis OSS cluster’s read capacity using the ElastiCache console, the AWS CLI, or the ElastiCache API. For more information, see [Adding a read replica for Valkey or Redis OSS (Cluster Mode Disabled)](Replication.AddReadReplica.md).

## Decreasing read capacity


To decrease read capacity, delete one or more read replicas from your Valkey or Redis OSS cluster with replicas (called *replication group* in the API/CLI). If the cluster is Multi-AZ with automatic failover enabled, you cannot delete the last read replica without first disabling Multi-AZ. For more information, see [Modifying a replication group](Replication.Modify.md).

For more information, see [Deleting a read replica for Valkey or Redis OSS (Cluster Mode Disabled)](Replication.RemoveReadReplica.md).

# Scaling Valkey or Redis OSS (Cluster Mode Enabled) clusters


As demand on your clusters changes, you might decide to improve performance or reduce costs by changing the number of shards in your Valkey or Redis OSS (cluster mode enabled) 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 *BytesUsedForCache*.
+ **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*, *BytesUsedForCache*, *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 Valkey or Redis OSS (cluster mode enabled) cluster; horizontal and vertical scaling.
+ Horizontal scaling allows you to change the number of node groups (shards) in the replication group by adding or removing node groups (shards). The online resharding process allows scaling in/out while the cluster continues serving incoming requests. 

  Configure the slots in your new cluster differently than they were in the old cluster. Offline method only.
+ 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 Valkey or Redis OSS overhead. 

For more information, see [Choosing your node size](CacheNodes.SelectSize.md).

**Contents**
+ [

## Offline resharding for Valkey or Redis OSS (cluster mode enabled)
](#redis-cluster-resharding-offline)
+ [

## Online resharding for Valkey or Redis OSS (cluster mode enabled)
](#redis-cluster-resharding-online)
  + [

### Adding shards with online resharding
](#redis-cluster-resharding-online-add)
  + [

### Removing shards with online resharding
](#redis-cluster-resharding-online-remove)
    + [

#### Removing shards (Console)
](#redis-cluster-resharding-online-remove-console)
    + [

#### Removing shards (AWS CLI)
](#redis-cluster-resharding-online-remove-cli)
    + [

#### Removing shards (ElastiCache API)
](#redis-cluster-resharding-online-remove-api)
  + [

### Online shard rebalancing
](#redis-cluster-resharding-online-rebalance)
    + [

#### Online Shard Rebalancing (Console)
](#redis-cluster-resharding-online-rebalance-console)
    + [

#### Online shard rebalancing (AWS CLI)
](#redis-cluster-resharding-online-rebalance-cli)
    + [

#### Online shard rebalancing (ElastiCache API)
](#redis-cluster-resharding-online-rebalance-api)
+ [

# Online vertical scaling by modifying node type
](redis-cluster-vertical-scaling.md)
  + [

## Online scaling up
](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
    + [

### Scaling up Valkey or Redis OSS clusters (Console)
](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-console)
    + [

### Scaling up Valkey or Redis OSS clusters (AWS CLI)
](redis-cluster-vertical-scaling.md#Scaling.RedisStandalone.ScaleUp.CLI)
    + [

### Scaling up Valkey or Redis OSS clusters (ElastiCache API)
](redis-cluster-vertical-scaling.md#VeticalScaling.RedisReplGrps.ScaleUp.API)
  + [

## Online scaling down
](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-down)
    + [

### Scaling down Valkey or Redis OSS clusters (Console)
](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-down-console)
    + [

### Scaling down Valkey or Redis OSS clusters (AWS CLI)
](redis-cluster-vertical-scaling.md#Scaling.RedisStandalone.ScaleDown.CLI)
    + [

### Scaling down Valkey or Redis OSS clusters (ElastiCache API)
](redis-cluster-vertical-scaling.md#Scaling.Vertical.ScaleDown.API)

## Offline resharding for Valkey or Redis OSS (cluster mode enabled)


The main advantage you get from offline shard reconfiguration is that you can do more than merely add or remove shards from your replication group. When you reshard and rebalance offline, in addition to changing the number of shards in your replication group, you can do the following:

**Note**  
Offline resharding is not supported on Valkey or Redis OSS clusters with data tiering enabled. For more information, see [Data tiering in ElastiCache](data-tiering.md).
+ Change the node type of your replication group.
+ Specify the Availability Zone for each node in the replication group.
+ Upgrade to a newer engine version.
+ Specify the number of replica nodes in each shard independently.
+ Specify the keyspace for each shard.

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 Valkey or Redis OSS (cluster mode enabled) cluster offline**

1. Create a manual backup of your existing Valkey or Redis OSS cluster. For more information, see [Taking manual backups](backups-manual.md).

1. Create a new cluster by restoring from the backup. For more information, see [Restoring from a backup into a new cache](backups-restoring.md).

1. Update the endpoints in your application to the new cluster's endpoints. For more information, see [Finding connection endpoints in ElastiCache](Endpoints.md).

## Online resharding for Valkey or Redis OSS (cluster mode enabled)


By using online resharding and shard rebalancing with ElastiCache Valkey 7.2 or newer, or Redis OSS version 3.2.10 or newer, you can scale your Valkey or Redis OSS (cluster mode enabled) cluster 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 (node groups) to your Valkey or Redis OSS (cluster mode enabled) cluster (replication group).

  If you add one or more shards to your replication group, 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 Valkey or Redis OSS (cluster mode enabled) cluster.
+ **Rebalance** – Move the keyspaces among the shards in your Valkey or Redis OSS (cluster mode enabled) cluster so they are as equally distributed among the shards as possible.

You can't do the following:
+ **Configure shards independently:**

  You can't specify the keyspace for shards independently. To do this, you must use the offline process.

Currently, the following limitations apply to ElastiCache online resharding and rebalancing:
+ These processes require Valkey 7.2 and newer or Redis OSS 3.2.10 or newer. For information on upgrading your engine version, see [Version Management for ElastiCache](VersionManagement.md).
+ 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 or rebalancing. 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 smallest existing shard.
+ When scaling out, any tags that are common to all existing shards are copied to the new shards.
+ When scaling out a Global Data Store cluster, ElastiCache will not automatically replicate Functions from one of the existing nodes to the new node(s). We recommend loading your Functions in the new shard(s) after scaling out your cluster so that every shards have the same functions. 

**Note**  
In ElastiCache for Valkey 7.2 and above, and ElastiCache for Redis OSS version 7 and above: When scaling out your cluster, ElastiCache will automatically replicate the Functions loaded in one of the existing nodes (selected at random) to the new node(s). If your application uses [Functions](https://valkey.io/topics/functions-intro/), we recommend loading all of your functions to all the shards before scaling out so that your cluster does not end up with different function definitions on different shards.

For more information, see [Online cluster resizing](best-practices-online-resharding.md).

You can horizontally scale or rebalance your Valkey or Redis OSS (cluster mode enabled) clusters using the AWS Management Console, the AWS CLI, and the ElastiCache API.

### Adding shards with online resharding


You can add shards to your Valkey or Redis OSS (cluster mode enabled) cluster using the AWS Management Console, AWS CLI, or ElastiCache API. When you add shards to a Valkey or Redis OSS (cluster mode enabled) cluster, any tags on the existing shards are copied over to the new shards.

**Topics**

#### Adding shards (Console)
Using the AWS Management Console

You can use the AWS Management Console to add one or more shards to your Valkey or Redis OSS (cluster mode enabled) cluster. The following procedure describes the process.

**To add shards to your Valkey or Redis OSS (cluster mode enabled) cluster**

1. Open the ElastiCache console at [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).

1. From the navigation pane, choose **Valkey clusters** or **Redis OSS clusters**.

1. Locate and choose the name, not the box to the left of the cluster's name, of the Valkey or Redis OSS (cluster mode enabled) cluster that you want to add shards to.
**Tip**  
Valkey or Redis OSS (cluster mode enabled) show **Clustered Valkey** or **Clustered Redis OSS** in the **Mode** column

1. Choose **Add shard**.

   1. For **Number of shards to be added**, choose the number of shards you want added to this cluster.

   1. For **Availability zone(s)**, choose either **No preference** or **Specify availability zones**.

   1. If you chose **Specify availability zones**, for each node in each shard, select the node's Availability Zone from the list of Availability Zones.

   1. Choose **Add**.

#### Adding shards (AWS CLI)
Using the AWS CLI

The following process describes how to reconfigure the shards in your Valkey or Redis OSS (cluster mode enabled) cluster by adding shards using the AWS CLI.

Use the following parameters with `modify-replication-group-shard-configuration`.

**Parameters**
+ `--apply-immediately` – Required. Specifies the shard reconfiguration operation is to be started immediately.
+ `--replication-group-id` – Required. Specifies which replication group (cluster) the shard reconfiguration operation is to be performed on.
+ `--node-group-count` – Required. Specifies the number of shards (node groups) to exist when the operation is completed. When adding shards, the value of `--node-group-count` must be greater than the current number of shards.

  Optionally, you can specify the Availability Zone for each node in the replication group using `--resharding-configuration`.
+ `--resharding-configuration` – Optional. A list of preferred Availability Zones for each node in each shard in the replication group. Use this parameter only if the value of `--node-group-count` is greater than the current number of shards. If this parameter is omitted when adding shards, Amazon ElastiCache selects the Availability Zones for the new nodes.

The following example reconfigures the keyspaces over four shards in a Valkey or Redis OSS (cluster mode enabled) cluster named `my-cluster`. The example also specifies the Availability Zone for each node in each shard. The operation begins immediately.

**Example - Adding Shards**  
For Linux, macOS, or Unix:  

```
aws elasticache modify-replication-group-shard-configuration \
    --replication-group-id my-cluster \
    --node-group-count 4 \
    --resharding-configuration \
        "PreferredAvailabilityZones=us-east-2a,us-east-2c" \
        "PreferredAvailabilityZones=us-east-2b,us-east-2a" \
        "PreferredAvailabilityZones=us-east-2c,us-east-2d" \
        "PreferredAvailabilityZones=us-east-2d,us-east-2c" \
    --apply-immediately
```
For Windows:  

```
aws elasticache modify-replication-group-shard-configuration ^
    --replication-group-id my-cluster ^
    --node-group-count 4 ^
    --resharding-configuration ^
        "PreferredAvailabilityZones=us-east-2a,us-east-2c" ^
        "PreferredAvailabilityZones=us-east-2b,us-east-2a" ^
        "PreferredAvailabilityZones=us-east-2c,us-east-2d" ^
        "PreferredAvailabilityZones=us-east-2d,us-east-2c" ^
    --apply-immediately
```

For more information, see [modify-replication-group-shard-configuration](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group-shard-configuration.html) in the AWS CLI documentation.

#### Adding shards (ElastiCache API)
Using the ElastiCache API

You can use the ElastiCache API to reconfigure the shards in your Valkey or Redis OSS (cluster mode enabled) cluster online by using the `ModifyReplicationGroupShardConfiguration` operation.

Use the following parameters with `ModifyReplicationGroupShardConfiguration`.

**Parameters**
+ `ApplyImmediately=true` – Required. Specifies the shard reconfiguration operation is to be started immediately.
+ `ReplicationGroupId` – Required. Specifies which replication group (cluster) the shard reconfiguration operation is to be performed on.
+ `NodeGroupCount` – Required. Specifies the number of shards (node groups) to exist when the operation is completed. When adding shards, the value of `NodeGroupCount` must be greater than the current number of shards.

  Optionally, you can specify the Availability Zone for each node in the replication group using `ReshardingConfiguration`.
+ `ReshardingConfiguration` – Optional. A list of preferred Availability Zones for each node in each shard in the replication group. Use this parameter only if the value of `NodeGroupCount` is greater than the current number of shards. If this parameter is omitted when adding shards, Amazon ElastiCache selects the Availability Zones for the new nodes.

The following process describes how to reconfigure the shards in your Valkey or Redis OSS (cluster mode enabled) cluster by adding shards using the ElastiCache API.

**Example - Adding Shards**  
The following example adds node groups to the Valkey or Redis OSS (cluster mode enabled) cluster `my-cluster`, so there are a total of four node groups when the operation completes. The example also specifies the Availability Zone for each node in each shard. The operation begins immediately.  

```
https://elasticache.us-east-2.amazonaws.com/
    ?Action=ModifyReplicationGroupShardConfiguration
    &ApplyImmediately=true
    &NodeGroupCount=4
    &ReplicationGroupId=my-cluster
    &ReshardingConfiguration.ReshardingConfiguration.1.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2a 
    &ReshardingConfiguration.ReshardingConfiguration.1.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2c 
    &ReshardingConfiguration.ReshardingConfiguration.2.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2b 
    &ReshardingConfiguration.ReshardingConfiguration.2.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2a 
    &ReshardingConfiguration.ReshardingConfiguration.3.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2c 
    &ReshardingConfiguration.ReshardingConfiguration.3.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2d 
    &ReshardingConfiguration.ReshardingConfiguration.4.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2d 
    &ReshardingConfiguration.ReshardingConfiguration.4.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2c 
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20171002T192317Z
    &X-Amz-Credential=<credential>
```

For more information, see [ModifyReplicationGroupShardConfiguration](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html) in the ElastiCache API Reference.

### Removing shards with online resharding


You can remove shards from your Valkey or Redis OSS (cluster mode enabled) cluster using the AWS Management Console, AWS CLI, or ElastiCache API.

**Topics**
+ [

#### Removing shards (Console)
](#redis-cluster-resharding-online-remove-console)
+ [

#### Removing shards (AWS CLI)
](#redis-cluster-resharding-online-remove-cli)
+ [

#### Removing shards (ElastiCache API)
](#redis-cluster-resharding-online-remove-api)

#### Removing shards (Console)
Using the AWS Management Console

The following process describes how to reconfigure the shards in your Valkey or Redis OSS (cluster mode enabled) cluster by removing shards using the AWS Management Console.

Before removing node groups (shards) from your replication group, ElastiCache makes sure that all your data will fit in the remaining shards. If the data will fit, the specified shards are deleted from the replication group as requested. If the data won't fit in the remaining node groups, the process is terminated and the replication group is left with the same node group configuration as before the request was made.

You can use the AWS Management Console to remove one or more shards from your Valkey or Redis OSS (cluster mode enabled) cluster. You cannot remove all the shards in a replication group. Instead, you must delete the replication group. For more information, see [Deleting a replication group](Replication.DeletingRepGroup.md). The following procedure describes the process for deleting one or more shards.

**To remove shards from your Valkey or Redis OSS (cluster mode enabled) cluster**

1. Open the ElastiCache console at [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).

1. From the navigation pane, choose **Valkey clusters** or **Redis OSS clusters**.

1. Locate and choose the name, not the box to the left of the cluster's name, of the Valkey or Redis OSS (cluster mode enabled) cluster you want to remove shards from.
**Tip**  
Valkey or Redis OSS (cluster mode enabled) clusters have a value of 1 or greater in the **Shards** column.

1. From the list of shards, choose the box to the left of the name of each shard that you want to delete.

1. Choose **Delete shard**.

#### Removing shards (AWS CLI)
Using the AWS CLI

The following process describes how to reconfigure the shards in your Valkey or Redis OSS (cluster mode enabled) cluster by removing shards using the AWS CLI.

**Important**  
Before removing node groups (shards) from your replication group, ElastiCache makes sure that all your data will fit in the remaining shards. If the data will fit, the specified shards (`--node-groups-to-remove`) are deleted from the replication group as requested and their keyspaces mapped into the remaining shards. If the data will not fit in the remaining node groups, the process is terminated and the replication group is left with the same node group configuration as before the request was made.

You can use the AWS CLI to remove one or more shards from your Valkey or Redis OSS (cluster mode enabled) cluster. You cannot remove all the shards in a replication group. Instead, you must delete the replication group. For more information, see [Deleting a replication group](Replication.DeletingRepGroup.md).

Use the following parameters with `modify-replication-group-shard-configuration`.

**Parameters**
+ `--apply-immediately` – Required. Specifies the shard reconfiguration operation is to be started immediately.
+ `--replication-group-id` – Required. Specifies which replication group (cluster) the shard reconfiguration operation is to be performed on.
+ `--node-group-count` – Required. Specifies the number of shards (node groups) to exist when the operation is completed. When removing shards, the value of `--node-group-count` must be less than the current number of shards.

  
+ `--node-groups-to-remove` – Required when `--node-group-count` is less than the current number of node groups (shards). A list of shard (node group) IDs to remove from the replication group.

The following procedure describes the process for deleting one or more shards.

**Example - Removing Shards**  
The following example removes two node groups from the Valkey or Redis OSS (cluster mode enabled) cluster `my-cluster`, so there are a total of two node groups when the operation completes. The keyspaces from the removed shards are distributed evenly over the remaining shards.  
For Linux, macOS, or Unix:  

```
aws elasticache modify-replication-group-shard-configuration \
    --replication-group-id my-cluster \
    --node-group-count 2 \
    --node-groups-to-remove "0002" "0003" \
    --apply-immediately
```
For Windows:  

```
aws elasticache modify-replication-group-shard-configuration ^
    --replication-group-id my-cluster ^
    --node-group-count 2 ^
    --node-groups-to-remove "0002" "0003" ^
    --apply-immediately
```

#### Removing shards (ElastiCache API)
Using the ElastiCache API

You can use the ElastiCache API to reconfigure the shards in your Valkey or Redis OSS (cluster mode enabled) cluster online by using the `ModifyReplicationGroupShardConfiguration` operation.

The following process describes how to reconfigure the shards in your Valkey or Redis OSS (cluster mode enabled) cluster by removing shards using the ElastiCache API.

**Important**  
Before removing node groups (shards) from your replication group, ElastiCache makes sure that all your data will fit in the remaining shards. If the data will fit, the specified shards (`NodeGroupsToRemove`) are deleted from the replication group as requested and their keyspaces mapped into the remaining shards. If the data will not fit in the remaining node groups, the process is terminated and the replication group is left with the same node group configuration as before the request was made.

You can use the ElastiCache API to remove one or more shards from your Valkey or Redis OSS (cluster mode enabled) cluster. You cannot remove all the shards in a replication group. Instead, you must delete the replication group. For more information, see [Deleting a replication group](Replication.DeletingRepGroup.md).

Use the following parameters with `ModifyReplicationGroupShardConfiguration`.

**Parameters**
+ `ApplyImmediately=true` – Required. Specifies the shard reconfiguration operation is to be started immediately.
+ `ReplicationGroupId` – Required. Specifies which replication group (cluster) the shard reconfiguration operation is to be performed on.
+ `NodeGroupCount` – Required. Specifies the number of shards (node groups) to exist when the operation is completed. When removing shards, the value of `NodeGroupCount` must be less than the current number of shards.
+ `NodeGroupsToRemove` – Required when `--node-group-count` is less than the current number of node groups (shards). A list of shard (node group) IDs to remove from the replication group.

The following procedure describes the process for deleting one or more shards.

**Example - Removing Shards**  
The following example removes two node groups from the Valkey or Redis OSS (cluster mode enabled) cluster `my-cluster`, so there are a total of two node groups when the operation completes. The keyspaces from the removed shards are distributed evenly over the remaining shards.  

```
https://elasticache.us-east-2.amazonaws.com/
    ?Action=ModifyReplicationGroupShardConfiguration
    &ApplyImmediately=true
    &NodeGroupCount=2
    &ReplicationGroupId=my-cluster
    &NodeGroupsToRemove.member.1=0002
    &NodeGroupsToRemove.member.2=0003
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20171002T192317Z
    &X-Amz-Credential=<credential>
```

### Online shard rebalancing
Rebalancing Shards

You can rebalance shards in your Valkey or Redis OSS (cluster mode enabled) cluster using the AWS Management Console, AWS CLI, or ElastiCache API.

**Topics**
+ [

#### Online Shard Rebalancing (Console)
](#redis-cluster-resharding-online-rebalance-console)
+ [

#### Online shard rebalancing (AWS CLI)
](#redis-cluster-resharding-online-rebalance-cli)
+ [

#### Online shard rebalancing (ElastiCache API)
](#redis-cluster-resharding-online-rebalance-api)

#### Online Shard Rebalancing (Console)
Using the AWS Management Console

The following process describes how to reconfigure the shards in your Valkey or Redis OSS (cluster mode enabled) cluster by rebalancing shards using the AWS Management Console.

**To rebalance the keyspaces among the shards on your Valkey or Redis OSS (cluster mode enabled) cluster**

1. Open the ElastiCache console at [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).

1. From the navigation pane, choose **Valkey clusters** or **Redis OSS clusters**.

1. Choose the name, not the box to the left of the name, of the Valkey or Redis OSS (cluster mode enabled) cluster that you want to rebalance.
**Tip**  
Valkey or Redis OSS (cluster mode enabled) clusters have a value of 1 or greater in the **Shards** column.

1. Choose **Rebalance**.

1. When prompted, choose **Rebalance**. You might see a message similar to this one: *Slots in the replication group are uniformly distributed. Nothing to do. (Service: AmazonElastiCache; Status Code: 400; Error Code: InvalidReplicationGroupState; Request ID: 2246cebd-9721-11e7-8d5b-e1b0f086c8cf)*. If you do, choose **Cancel**.

#### Online shard rebalancing (AWS CLI)
Using the AWS CLI

Use the following parameters with `modify-replication-group-shard-configuration`.

**Parameters**
+ `-apply-immediately` – Required. Specifies the shard reconfiguration operation is to be started immediately.
+ `--replication-group-id` – Required. Specifies which replication group (cluster) the shard reconfiguration operation is to be performed on.
+ `--node-group-count` – Required. To rebalance the keyspaces across all shards in the cluster, this value must be the same as the current number of shards.

The following process describes how to reconfigure the shards in your Valkey or Redis OSS (cluster mode enabled) cluster by rebalancing shards using the AWS CLI.

**Example - Rebalancing the Shards in a Cluster**  
The following example rebalances the slots in the Valkey or Redis OSS (cluster mode enabled) cluster `my-cluster` so that the slots are distributed as equally as possible. The value of `--node-group-count` (`4`) is the number of shards currently in the cluster.  
For Linux, macOS, or Unix:  

```
aws elasticache modify-replication-group-shard-configuration \
    --replication-group-id my-cluster \
    --node-group-count 4 \
    --apply-immediately
```
For Windows:  

```
aws elasticache modify-replication-group-shard-configuration ^
    --replication-group-id my-cluster ^
    --node-group-count 4 ^
    --apply-immediately
```

#### Online shard rebalancing (ElastiCache API)
Using the ElastiCache API

You can use the ElastiCache API to reconfigure the shards in your Valkey or Redis OSS (cluster mode enabled) cluster online by using the `ModifyReplicationGroupShardConfiguration` operation.

Use the following parameters with `ModifyReplicationGroupShardConfiguration`.

**Parameters**
+ `ApplyImmediately=true` – Required. Specifies the shard reconfiguration operation is to be started immediately.
+ `ReplicationGroupId` – Required. Specifies which replication group (cluster) the shard reconfiguration operation is to be performed on.
+ `NodeGroupCount` – Required. To rebalance the keyspaces across all shards in the cluster, this value must be the same as the current number of shards.

The following process describes how to reconfigure the shards in your Valkey or Redis OSS (cluster mode enabled) cluster by rebalancing the shards using the ElastiCache API.

**Example - Rebalancing a Cluster**  
The following example rebalances the slots in the Valkey or Redis OSS (cluster mode enabled) cluster `my-cluster` so that the slots are distributed as equally as possible. The value of `NodeGroupCount` (`4`) is the number of shards currently in the cluster.  

```
https://elasticache.us-east-2.amazonaws.com/
    ?Action=ModifyReplicationGroupShardConfiguration
    &ApplyImmediately=true
    &NodeGroupCount=4
    &ReplicationGroupId=my-cluster
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20171002T192317Z
    &X-Amz-Credential=<credential>
```

# Online vertical scaling by modifying node type
Online vertical scaling by modifying node type

By using online vertical scaling with Valkey version 7.2 or newer, or Redis OSS version 3.2.10 or newer, you can scale your Valkey or Redis OSS clusters dynamically with minimal downtime. This allows your Valkey or Redis OSS 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 in ElastiCache](data-tiering.md).

You can do the following:
+ **Scale up** – Increase read and write capacity by adjusting the node type of your Valkey or Redis OSS cluster to use a larger node type.

  ElastiCache 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, ElastiCache 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:  
Ensure you have sufficient ENI (Elastic Network Interface) capacity. If scaling down, ensure the smaller node has sufficient memory to absorb expected traffic.   
For best practices on memory management, see [Managing reserved memory for Valkey and Redis OSS](redis-memory-management.md). 
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. 

**Contents**
+ [

## Online scaling up
](#redis-cluster-vertical-scaling-scaling-up)
  + [

### Scaling up Valkey or Redis OSS clusters (Console)
](#redis-cluster-vertical-scaling-console)
  + [

### Scaling up Valkey or Redis OSS clusters (AWS CLI)
](#Scaling.RedisStandalone.ScaleUp.CLI)
  + [

### Scaling up Valkey or Redis OSS clusters (ElastiCache API)
](#VeticalScaling.RedisReplGrps.ScaleUp.API)
+ [

## Online scaling down
](#redis-cluster-vertical-scaling-scaling-down)
  + [

### Scaling down Valkey or Redis OSS clusters (Console)
](#redis-cluster-vertical-scaling-down-console)
  + [

### Scaling down Valkey or Redis OSS clusters (AWS CLI)
](#Scaling.RedisStandalone.ScaleDown.CLI)
  + [

### Scaling down Valkey or Redis OSS clusters (ElastiCache API)
](#Scaling.Vertical.ScaleDown.API)

## Online scaling up
Online scaling up

**Topics**
+ [

### Scaling up Valkey or Redis OSS clusters (Console)
](#redis-cluster-vertical-scaling-console)
+ [

### Scaling up Valkey or Redis OSS clusters (AWS CLI)
](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [

### Scaling up Valkey or Redis OSS clusters (ElastiCache API)
](#VeticalScaling.RedisReplGrps.ScaleUp.API)

### Scaling up Valkey or Redis OSS clusters (Console)
Using the AWS Management Console

The following procedure describes how to scale up a Valkey or Redis OSS cluster using the ElastiCache Management Console. During this process, your cluster will continue to serve requests with minimal downtime.

**To scale up a Valkey or Redis OSS cluster (console)**

1. Sign in to the AWS Management Console and open the ElastiCache console at [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).

1. From the navigation pane, choose **Valkey clusters** or **Redis OSS clusters**.

1. From the list of clusters, choose the cluster. 

1. Choose **Modify**.

1. In the **Modify Cluster** wizard:

   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. If you want to perform the scale-up process right away, choose the **Apply immediately** box. If the **Apply immediately** box is not chosen, the scale-up process is performed during this cluster's next maintenance window.

1. Choose **Modify**.

   If you chose **Apply immediately** in the previous step, 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 Valkey or Redis OSS clusters (AWS CLI)


The following procedure describes how to scale up a Valkey or Redis OSS cluster using the AWS CLI. During this process, your cluster will continue to serve requests with minimal downtime.

**To scale up a Valkey or Redis OSS cluster (AWS CLI)**

1. Determine the node types you can scale up to by running the AWS CLI `list-allowed-node-type-modifications` command with the following parameter.

   For Linux, macOS, or Unix:

   ```
   aws elasticache list-allowed-node-type-modifications \
   	    --replication-group-id my-replication-group-id
   ```

   For Windows:

   ```
   aws elasticache list-allowed-node-type-modifications ^
   	    --replication-group-id my-replication-group-id
   ```

   Output from the above command looks something like this (JSON format).

   ```
   {
   	    "ScaleUpModifications": [
   	        "cache.m3.2xlarge", 
   	        "cache.m3.large", 
   	        "cache.m3.xlarge", 
   	        "cache.m4.10xlarge", 
   	        "cache.m4.2xlarge", 
   	        "cache.m4.4xlarge", 
   	        "cache.m4.large", 
   	        "cache.m4.xlarge", 
   	        "cache.r3.2xlarge", 
   	        "cache.r3.4xlarge", 
   	        "cache.r3.8xlarge", 
   	        "cache.r3.large", 
   	        "cache.r3.xlarge"
   	    ]
   	       "ScaleDownModifications": [
   	        "cache.t2.micro", 
   	        "cache.t2.small ", 
   	        "cache.t2.medium",
   	       	"cache.t1.small "
   	    ], 
   }
   ```

   For more information, see [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) in the *AWS CLI Reference*.

1. Modify your replication group to scale up to the new, larger node type, using the AWS CLI `modify-replication-group` command and the following parameters.
   + `--replication-group-id` – The name of the replication group you are scaling up to. 
   + `--cache-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-modifications` command in step 1.
   + `--cache-parameter-group-name` – [Optional] Use this parameter if you are using `reserved-memory` to manage your cluster's reserved memory. Specify a custom cache parameter group that reserves the correct amount of memory for your new node type. If you are using `reserved-memory-percent` you can omit this parameter.
   + `--apply-immediately` – Causes the scale-up process to be applied immediately. To postpone the scale-up process to the cluster's next maintenance window, use the `--no-apply-immediately` parameter.

   For Linux, macOS, or Unix:

   ```
   aws elasticache modify-replication-group  \
   	    --replication-group-id my-redis-cluster \
   	    --cache-node-type cache.m3.xlarge \	    
   	    --apply-immediately
   ```

   For Windows:

   ```
   aws elasticache modify-replication-group ^
   	    --replication-group-id my-redis-cluster ^
   	    --cache-node-type cache.m3.xlarge ^	   
   	    --apply-immediately
   ```

   Output from the above command looks something like this (JSON format).

   ```
   {
   		"ReplicationGroup": {
           "Status": "modifying",
           "Description": "my-redis-cluster",
           "NodeGroups": [
               {
                   "Status": "modifying",
                   "Slots": "0-16383",
                   "NodeGroupId": "0001",
                   "NodeGroupMembers": [
                       {
                           "PreferredAvailabilityZone": "us-east-1f",
                           "CacheNodeId": "0001",
                           "CacheClusterId": "my-redis-cluster-0001-001"
                       },
                       {
                           "PreferredAvailabilityZone": "us-east-1d",
                           "CacheNodeId": "0001",
                           "CacheClusterId": "my-redis-cluster-0001-002"
                       }
                   ]
               }
           ],
           "ConfigurationEndpoint": {
               "Port": 6379,
               "Address": "my-redis-cluster.r7gdfi.clustercfg.use1.cache.amazonaws.com"
           },
           "ClusterEnabled": true,
           "ReplicationGroupId": "my-redis-cluster",
           "SnapshotRetentionLimit": 1,
           "AutomaticFailover": "enabled",
           "SnapshotWindow": "07:30-08:30",
           "MemberClusters": [
               "my-redis-cluster-0001-001",
               "my-redis-cluster-0001-002"
           ],
           "CacheNodeType": "cache.m3.xlarge",
            "DataTiering": "disabled"
           "PendingModifiedValues": {}
       }
   }
   ```

   For more information, see [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) in the *AWS CLI Reference*.

1. If you used the `--apply-immediately`, check the status of the cluster using the AWS CLI `describe-cache-clusters` command with the following parameter. When the status changes to *available*, you can begin using the new, larger cluster node.

### Scaling up Valkey or Redis OSS clusters (ElastiCache API)


The following process scales your cluster from its current node type to a new, larger node type using the ElastiCache API. During this process, ElastiCache updates the DNS entries so they point to the new nodes. Because of this you don't have to update the endpoints in your application. For Valkey 7.2 and above Redis OSS 5.0.5 and above, you can scale auto failover enabled clusters while the cluster continues to stay online and serve incoming requests. On version Redis OSS 4.0.10 and below, you may notice a brief interruption of reads and writes on previous versions from the primary node while the DNS entry is updated..

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 Valkey or Redis OSS Cache Cluster (ElastiCache API)**

1. Determine which node types you can scale up to using the ElastiCache API `ListAllowedNodeTypeModifications` action with the following parameter.
   + `ReplicationGroupId` – the name of the replication group. Use this parameter to describe a specific replication group rather than all replication groups.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=ListAllowedNodeTypeModifications
   	   &ReplicationGroupId=MyReplGroup
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) in the *Amazon ElastiCache API Reference*.

1. Scale your current replication group up to the new node type using the `ModifyReplicationGroup` ElastiCache API action and with the following parameters.
   + `ReplicationGroupId` – the name of the replication group.
   + `CacheNodeType` – the new, larger node type of the clusters in this replication group. This value must be one of the instance types returned by the `ListAllowedNodeTypeModifications` action in the previous step.
   + `CacheParameterGroupName` – [Optional] Use this parameter if you are using `reserved-memory` to manage your cluster's reserved memory. Specify a custom cache parameter group that reserves the correct amount of memory for your new node type. If you are using `reserved-memory-percent` you can omit this parameter.
   + `ApplyImmediately` – Set to `true` to causes the scale-up process to be applied immediately. To postpone the scale-up process to the next maintenance window, use `ApplyImmediately``=false`.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=ModifyReplicationGroup
   	   &ApplyImmediately=true
   	   &CacheNodeType=cache.m3.2xlarge
   	   &CacheParameterGroupName=redis32-m3-2xl
   	   &ReplicationGroupId=myReplGroup
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20141201T220302Z
   	   &Version=2014-12-01
   	   &X-Amz-Algorithm=&AWS;4-HMAC-SHA256
   	   &X-Amz-Date=20141201T220302Z
   	   &X-Amz-SignedHeaders=Host
   	   &X-Amz-Expires=20141201T220302Z
   	   &X-Amz-Credential=<credential>
   	   &X-Amz-Signature=<signature>
   ```

   For more information, see [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) in the *Amazon ElastiCache API Reference*.

1. If you used `ApplyImmediately``=true`, monitor the status of the replication group using the ElastiCache API `DescribeReplicationGroups` action with the following parameters. When the status changes from *modifying* to *available*, you can begin writing to your new, scaled up replication group.
   + `ReplicationGroupId` – the name of the replication group. Use this parameter to describe a particular replication group rather than all replication groups.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=DescribeReplicationGroups
   	   &ReplicationGroupId=MyReplGroup
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) in the *Amazon ElastiCache API Reference*.

## Online scaling down
Online scaling down

**Topics**
+ [

### Scaling down Valkey or Redis OSS clusters (Console)
](#redis-cluster-vertical-scaling-down-console)
+ [

### Scaling down Valkey or Redis OSS clusters (AWS CLI)
](#Scaling.RedisStandalone.ScaleDown.CLI)
+ [

### Scaling down Valkey or Redis OSS clusters (ElastiCache API)
](#Scaling.Vertical.ScaleDown.API)

### Scaling down Valkey or Redis OSS clusters (Console)
Using the AWS Management Console

The following procedure describes how to scale down a Valkey or Redis OSS cluster using the ElastiCache Management Console. During this process, your Valkey or Redis OSS cluster will continue to serve requests with minimal downtime.

**To scale Down a Valkey or Redis OSS cluster (console)**

1. Sign in to the AWS Management Console and open the ElastiCache console at [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).

1. From the navigation pane, choose **Valkey clusters** or **Redis OSS clusters**.

1. From the list of clusters, choose your preferred cluster. 

1. Choose **Modify**.

1. In the **Modify Cluster** wizard:

   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. If you want to perform the scale down process right away, choose the **Apply immediately** box. If the **Apply immediately** box is not chosen, the scale-down process is performed during this cluster's next maintenance window.

1. Choose **Modify**.

   If you chose **Apply immediately** in the previous step, 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 Valkey or Redis OSS clusters (AWS CLI)


The following procedure describes how to scale down a Valkey or Redis OSS cluster using the AWS CLI. During this process, your cluster will continue to serve requests with minimal downtime.

**To scale down a Valkey or Redis OSS cluster (AWS CLI)**

1. Determine the node types you can scale down to by running the AWS CLI `list-allowed-node-type-modifications` command with the following parameter.

   For Linux, macOS, or Unix:

   ```
   aws elasticache list-allowed-node-type-modifications \
   	    --replication-group-id my-replication-group-id
   ```

   For Windows:

   ```
   aws elasticache list-allowed-node-type-modifications ^
   	    --replication-group-id my-replication-group-id
   ```

   Output from the above command looks something like this (JSON format).

   ```
   {
   	    "ScaleUpModifications": [
   	        "cache.m3.2xlarge", 
   	        "cache.m3.large", 
   	        "cache.m3.xlarge", 
   	        "cache.m4.10xlarge", 
   	        "cache.m4.2xlarge", 
   	        "cache.m4.4xlarge", 
   	        "cache.m4.large", 
   	        "cache.m4.xlarge", 
   	        "cache.r3.2xlarge", 
   	        "cache.r3.4xlarge", 
   	        "cache.r3.8xlarge", 
   	        "cache.r3.large", 
   	        "cache.r3.xlarge"
   	    ]
   	
   	       "ScaleDownModifications": [
   	        "cache.t2.micro", 
   	        "cache.t2.small ", 
   	        "cache.t2.medium ",
     	      "cache.t1.small"
   	    ]
   }
   ```

   For more information, see [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) in the *AWS CLI Reference*.

1. Modify your replication group to scale down to the new, smaller node type, using the AWS CLI `modify-replication-group` command and the following parameters.
   + `--replication-group-id` – The name of the replication group you are scaling down to. 
   + `--cache-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-modifications` command in step 1.
   + `--cache-parameter-group-name` – [Optional] Use this parameter if you are using `reserved-memory` to manage your cluster's reserved memory. Specify a custom cache parameter group that reserves the correct amount of memory for your new node type. If you are using `reserved-memory-percent` you can omit this parameter.
   + `--apply-immediately` – Causes the scale-up process to be applied immediately. To postpone the scale-down process to the cluster's next maintenance window, use the `--no-apply-immediately` parameter.

   For Linux, macOS, or Unix:

   ```
   aws elasticache modify-replication-group  \
   	    --replication-group-id my-redis-cluster \
   	    --cache-node-type cache.t2.micro \	    
   	    --apply-immediately
   ```

   For Windows:

   ```
   aws elasticache modify-replication-group ^
   	    --replication-group-id my-redis-cluster ^
   	    --cache-node-type cache.t2.micro ^	   
   	    --apply-immediately
   ```

   Output from the above command looks something like this (JSON format).

   ```
   {	
   		"ReplicationGroup": {
           "Status": "modifying",
           "Description": "my-redis-cluster",
           "NodeGroups": [
               {
                   "Status": "modifying",
                   "Slots": "0-16383",
                   "NodeGroupId": "0001",
                   "NodeGroupMembers": [
                       {
                           "PreferredAvailabilityZone": "us-east-1f",
                           "CacheNodeId": "0001",
                           "CacheClusterId": "my-redis-cluster-0001-001"
                       },
                       {
                           "PreferredAvailabilityZone": "us-east-1d",
                           "CacheNodeId": "0001",
                           "CacheClusterId": "my-redis-cluster-0001-002"
                       }
                   ]
               }
           ],
           "ConfigurationEndpoint": {
               "Port": 6379,
               "Address": "my-redis-cluster.r7gdfi.clustercfg.use1.cache.amazonaws.com"
           },
           "ClusterEnabled": true,
           "ReplicationGroupId": "my-redis-cluster",
           "SnapshotRetentionLimit": 1,
           "AutomaticFailover": "enabled",
           "SnapshotWindow": "07:30-08:30",
           "MemberClusters": [
               "my-redis-cluster-0001-001",
               "my-redis-cluster-0001-002"
           ],
           "CacheNodeType": "cache.t2.micro",
            "DataTiering": "disabled"
           "PendingModifiedValues": {}
       }
   }
   ```

   For more information, see [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) in the *AWS CLI Reference*.

1. If you used the `--apply-immediately`, check the status of the cluster using the AWS CLI `describe-cache-clusters` command with the following parameter. When the status changes to *available*, you can begin using the new, smaller cluster node.

### Scaling down Valkey or Redis OSS clusters (ElastiCache API)


The following process scales your replication group from its current node type to a new, smaller node type using the ElastiCache API. During this process, your Valkey or Redis OSS 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 (ElastiCache API)**

1. Determine which node types you can scale down to using the ElastiCache API `ListAllowedNodeTypeModifications` action with the following parameter.
   + `ReplicationGroupId` – the name of the replication group. Use this parameter to describe a specific replication group rather than all replication groups.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=ListAllowedNodeTypeModifications
   	   &ReplicationGroupId=MyReplGroup
   	   &Version=2015-02-02
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20150202T192317Z
   	   &X-Amz-Credential=<credential>
   ```

   For more information, see [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) in the *Amazon ElastiCache API Reference*.

1. Scale your current replication group down to the new node type using the `ModifyReplicationGroup` ElastiCache API action and with the following parameters.
   + `ReplicationGroupId` – the name of the replication group.
   + `CacheNodeType` – the new, smaller node type of the clusters in this replication group. This value must be one of the instance types returned by the `ListAllowedNodeTypeModifications` action in the previous step.
   + `CacheParameterGroupName` – [Optional] Use this parameter if you are using `reserved-memory` to manage your cluster's reserved memory. Specify a custom cache parameter group that reserves the correct amount of memory for your new node type. If you are using `reserved-memory-percent` you can omit this parameter.
   + `ApplyImmediately` – Set to `true` to causes the scale-down process to be applied immediately. To postpone the scale-down process to the next maintenance window, use `ApplyImmediately``=false`.

   ```
   https://elasticache.us-west-2.amazonaws.com/
   	   ?Action=ModifyReplicationGroup
   	   &ApplyImmediately=true
   	   &CacheNodeType=cache.t2.micro
   	   &CacheParameterGroupName=redis32-m3-2xl
   	   &ReplicationGroupId=myReplGroup
   	   &SignatureVersion=4
   	   &SignatureMethod=HmacSHA256
   	   &Timestamp=20141201T220302Z
   	   &Version=2014-12-01
   	   &X-Amz-Algorithm=&AWS;4-HMAC-SHA256
   	   &X-Amz-Date=20141201T220302Z
   	   &X-Amz-SignedHeaders=Host
   	   &X-Amz-Expires=20141201T220302Z
   	   &X-Amz-Credential=<credential>
   	   &X-Amz-Signature=<signature>
   ```

   For more information, see [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) in the *Amazon ElastiCache API Reference*.