# Managing nodes in ElastiCache
A node is the smallest building block of an Amazon ElastiCache deployment. It is a fixed-size chunk of secure, network-attached RAM. Each node runs the engine that was chosen when the cluster was created or last modified. Each node has its own Domain Name Service (DNS) name and port. Multiple types of ElastiCache nodes are supported, each with varying amounts of associated memory and computational power.
For a more detailed discussion of which node size to use, see [Choosing your node size](CacheNodes.SelectSize.md).
Generally speaking, due to its support for sharding, Valkey or Redis OSS (cluster mode enabled) deployments have a number of smaller nodes. In contrast, Valkey or Redis OSS (cluster mode disabled) deployments have fewer, larger nodes in a cluster. For a more detailed discussion of which node size to use, see [Choosing your node size](CacheNodes.SelectSize.md).
**Topics**
+ [Viewing ElastiCache Node Status](Nodes.viewing.md)
+ [Valkey or Redis OSS nodes and shards](CacheNodes.NodeGroups.md)
+ [Connecting to nodes](nodes-connecting.md)
+ [Supported node types](CacheNodes.SupportedTypes.md)
+ [Rebooting nodes](nodes.rebooting.md)
+ [Replacing nodes (Valkey and Redis OSS)](CacheNodes.NodeReplacement.md)
+ [Replacing nodes (Memcached)](CacheNodes.NodeReplacement-mc.md)
+ [Reserved nodes](CacheNodes.Reserved.md)
+ [Migrating previous generation nodes](CacheNodes.NodeMigration.md)
Some important operations involving nodes are the following:
+ [Adding nodes to an ElastiCache cluster](Clusters.AddNode.md)
+ [Removing nodes from an ElastiCache cluster](Clusters.DeleteNode.md)
+ [Scaling ElastiCache](Scaling.md)
+ [Finding connection endpoints in ElastiCache](Endpoints.md)
+ [Automatically identify nodes in your cluster (Memcached)](AutoDiscovery.md)
# Viewing ElastiCache Node Status
Using the [ElastiCache console](https://console.aws.amazon.com/elasticache/), you can quickly access the status of your ElastiCache node. The status of an ElastiCache node indicates the health of the node. You can use the following procedures to view the ElastiCache node status in the Amazon ElastiCache console, the AWS CLI command, or the API operation.
The possible status values for ElastiCache nodes are in the following table. This table also shows if you will be billed for the ElastiCache node.
| **Type** | **Billed** | **Description** |
| --- | --- | --- |
| `available` | Billed | The ElastiCache node is healthy and available. |
| `creating` | Not billed | The ElastiCache node is being created. The Node is inaccessible while it is being created. |
| `deleting` | Not billed | The ElastiCache node is being deleted. |
| `modifying` | Billed | The ElastiCache node is being modified because of a customer request to modify the node. |
| `updating` | Billed | An **Updating** state indicates one or more of the following is true of the Amazon ElastiCache node: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Nodes.viewing.html) |
| `rebooting cluster nodes` | Billed | The ElastiCache node is being rebooted because of a customer request or an Amazon ElastiCache process that requires the rebooting of the node. |
| `incompatible_parameters` | Not billed | Amazon ElastiCache can't start the node because the parameters specified in the node's parameter group aren't compatible with the node. Either revert the parameter changes or make them compatible with the node to regain access to your node. For more information about the incompatible parameters, check the [Events](https://us-east-1.console.aws.amazon.com/elasticache/home?region=us-east-1#/events) list for the ElastiCache node. |
| `incompatible_network` | Not billed | An incompatible-network state indicates one or more of the following is true of the Amazon ElastiCache node: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Nodes.viewing.html) |
| `restore_failed` | Not billed | A restore-failed state indicates one of the following is true of the Amazon ElastiCache node: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Nodes.viewing.html) |
| `snapshotting` | Billed | ElastiCache is creating a snapshot of the Valkey or Redis OSS node. |
## Viewing ElastiCache Node Status with the console
To view the status of an ElastiCache Node with the console:
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. In the navigation pane, choose **Redis OSS Clusters** or **Memcached Clusters**. The **Caches page** appears with the list of ElastiCache Nodes. For each node, the status value is displayed.
1. You can then navigate to the **Service Updates** tab for the cache to display the list of service Updates applicable to the cache.
## Viewing ElastiCache Node Status with the AWS CLI
To view ElastiCache node and its status information by using the AWS CLI, use the `describe-cache-cluster` command. For example, the following AWS CLI command displays each ElastiCache node.
```
aws elasticache describe-cache-clusters
```
## Viewing ElastiCache Node Status through the API
To view the status of the ElastiCache node using the Amazon ElastiCache API, call the `DescribeCacheClusteroperation` with the `ShowCacheNodeInfo` flag to retrieve information about the individual cache nodes.
# Valkey or Redis OSS nodes and shards
A shard (in the API and CLI, a node group) is a hierarchical arrangement of nodes, each wrapped in a cluster. Shards support replication. Within a shard, one node functions as the read/write primary node. All the other nodes in a shard function as read-only replicas of the primary node. Valkey, or Redis OSS version 3.2 and later, support multiple shards within a cluster (in the API and CLI, a replication group). This support enables partitioning your data in a Valkey or Redis OSS (cluster mode enabled) cluster.
The following diagram illustrates the differences between a Valkey or Redis OSS (cluster mode disabled) cluster and a Valkey or Redis OSS (cluster mode enabled) cluster.
![\[Image: Valkey or Redis OSS (cluster mode disabled) & Valkey or Redis OSS (cluster mode enabled) shards (API/CLI: node groups)\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/images/ElastiCache-NodeGroups.png)
Valkey or Redis OSS (cluster mode enabled) clusters support replication via shards. The API operation [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) (CLI: [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html)) lists the node groups with the member nodes, the node's role within the node group, and also other information.
When you create a Valkey or Redis OSS cluster, you specify whether you want to create a cluster with clustering enabled. Valkey or Redis OSS (cluster mode disabled) clusters never have more than one shard, which can be scaled horizontally by adding (up to a total of five) or deleting read replica nodes. For more information, see [High availability using replication groups](Replication.md), [Adding a read replica for Valkey or Redis OSS (Cluster Mode Disabled)](Replication.AddReadReplica.md) or [Deleting a read replica for Valkey or Redis OSS (Cluster Mode Disabled)](Replication.RemoveReadReplica.md). Valkey or Redis OSS (cluster mode disabled) clusters can also scale vertically by changing node types. For more information, see [Scaling replica nodes for Valkey or Redis OSS (Cluster Mode Disabled)](Scaling.RedisReplGrps.md).
The node or shard limit can be increased to a maximum of 500 per cluster if the engine is Valkey or Redis OSS version 5.0.6 or higher. For example, you can choose to configure a 500 node cluster that ranges between 83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and no replicas). Make sure there are enough available IP addresses to accommodate the increase. Common pitfalls include the subnets in the subnet group have too small a CIDR range or the subnets are shared and heavily used by other clusters. For more information, see [Creating a subnet group](SubnetGroups.Creating.md).
For versions below 5.0.6, the limit is 250 per cluster.
To request a limit increase, see [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) and choose the limit type **Nodes per cluster per instance type**.
After a Valkey or Redis OSS (cluster mode enabled) cluster is created, it can be altered (scaled in or out). For more information, see [Scaling ElastiCache](Scaling.md) and [Replacing nodes (Valkey and Redis OSS)](CacheNodes.NodeReplacement.md).
When you create a new cluster, you can seed it with data from the old cluster so it doesn't start out empty. This approach works only if the cluster group has the same number of shards as the old cluster. Doing this can be helpful if you need change your node type or engine version. For more information, see [Taking manual backups](backups-manual.md) and [Restoring from a backup into a new cache](backups-restoring.md).
# Connecting to nodes
## Connecting to Valkey or Redis OSS nodes
Before attempting to connect to the Valkey or Redis OSS nodes in your cluster, you must have the endpoints for the nodes. To find the endpoints, see the following:
+ [Finding a Valkey or Redis OSS (Cluster Mode Disabled) Cluster's Endpoints (Console)](Endpoints.md#Endpoints.Find.Redis)
+ [Finding Endpoints for a Valkey or Redis OSS (Cluster Mode Enabled) Cluster (Console)](Endpoints.md#Endpoints.Find.RedisCluster)
+ [Finding Endpoints (AWS CLI)](Endpoints.md#Endpoints.Find.CLI)
+ [Finding Endpoints (ElastiCache API)](Endpoints.md#Endpoints.Find.API)
In the following example, you use the *valkey-cli* utility to connect to a cluster that is running Valkey or Redis OSS.
**Note**
For more information about available commands, see the [Commands](http://valkey.io/commands) webpage.
**To connect to a Valkey or Redis OSS cluster using the *valkey-cli***
1. Connect to your Amazon EC2 instance using the connection utility of your choice.
**Note**
For instructions on how to connect to an Amazon EC2 instance, see the [Amazon EC2 Getting Started Guide](https://docs.aws.amazon.com/AWSEC2/latest/GettingStartedGuide/).
1. To build `valkey-cli`, download and install the GNU Compiler Collection (`gcc`). At the command prompt of your EC2 instance, enter the following command and enter `y` at the confirmation prompt.
```
sudo yum install gcc
```
Output similar to the following appears.
```
Loaded plugins: priorities, security, update-motd, upgrade-helper
Setting up Install Process
Resolving Dependencies
--> Running transaction check
...(output omitted)...
Total download size: 27 M
Installed size: 53 M
Is this ok [y/N]: y
Downloading Packages:
(1/11): binutils-2.22.52.0.1-10.36.amzn1.x86_64.rpm | 5.2 MB 00:00
(2/11): cpp46-4.6.3-2.67.amzn1.x86_64.rpm | 4.8 MB 00:00
(3/11): gcc-4.6.3-3.10.amzn1.noarch.rpm | 2.8 kB 00:00
...(output omitted)...
Complete!
```
1. Download and compile the *valkey-cli* utility. This utility is included in the Valkey software distribution. At the command prompt of your EC2 instance, type the following commands:
**Note**
For Ubuntu systems, before running `make`, run `make distclean`.
```
wget -O valkey-8.0.0.tar.gz https://github.com/valkey-io/valkey/archive/refs/tags/8.0.0.tar.gz
tar xvzf valkey-8.0.0.tar.gz
cd valkey-8.0.0
make distclean # ubuntu systems only
make
```
1. At the command prompt of your EC2 instance, type the following command.
```
src/valkey-cli -c -h mycachecluster.eaogs8.0001.usw2.cache.amazonaws.com -p 6379
```
A Valkey or Redis OSS command prompt similar to the following appears.
```
redis mycachecluster.eaogs8.0001.usw2.cache.amazonaws.com 6379>
```
1. Test the connection by running Valkey or Redis OSS commands.
You are now connected to the cluster and can run Valkey or Redis OSS commands. The following are some example commands with their Valkey or Redis OSS responses.
```
set a "hello" // Set key "a" with a string value and no expiration
OK
get a // Get value for key "a"
"hello"
get b // Get value for key "b" results in miss
(nil)
set b "Good-bye" EX 5 // Set key "b" with a string value and a 5 second expiration
get b
"Good-bye"
// wait 5 seconds
get b
(nil) // key has expired, nothing returned
quit // Exit from valkey-cli
```
For connecting to nodes or clusters which have Secure Sockets Layer (SSL) encryption (in-transit enabled), see [ElastiCache in-transit encryption (TLS)](in-transit-encryption.md).
## Connecting to Memcached nodes
Before attempting to connect to your Memcached cluster, you must have the endpoints for the nodes. To find the endpoints, see the following:
+ [Finding a Cluster's Endpoints (Console) (Memcached)](Endpoints.md#Endpoints.Find.Memcached)
+ [Finding Endpoints (AWS CLI)](Endpoints.md#Endpoints.Find.CLI)
+ [Finding Endpoints (ElastiCache API)](Endpoints.md#Endpoints.Find.API)
In the following example, you use the *telnet* utility to connect to a node that is running Memcached.
**Note**
For more information about Memcached and available Memcached commands, see the [Memcached](http://memcached.org/) website.
**To connect to a node using *telnet***
1. Connect to your Amazon EC2 instance by using the connection utility of your choice.
**Note**
For instructions on how to connect to an Amazon EC2 instance, see the [Amazon EC2 Getting Started Guide](https://docs.aws.amazon.com/AWSEC2/latest/GettingStartedGuide/).
1. Download and install the *telnet* utility on your Amazon EC2 instance. At the command prompt of your Amazon EC2 instance, type the following command and type *y* at the command prompt.
```
sudo yum install telnet
```
Output similar to the following appears.
```
Loaded plugins: priorities, security, update-motd, upgrade-helper
Setting up Install Process
Resolving Dependencies
--> Running transaction check
...(output omitted)...
Total download size: 63 k
Installed size: 109 k
Is this ok [y/N]: y
Downloading Packages:
telnet-0.17-47.7.amzn1.x86_64.rpm | 63 kB 00:00
...(output omitted)...
Complete!
```
1. At the command prompt of your Amazon EC2 instance, type the following command, substituting the endpoint of your node for the one shown in this example.
```
telnet mycachecluster.eaogs8.0001.usw2.cache.amazonaws.com 11211
```
Output similar to the following appears.
```
Trying 128.0.0.1...
Connected to mycachecluster.eaogs8.0001.usw2.cache.amazonaws.com.
Escape character is '^]'.
>
```
1. Test the connection by running Memcached commands.
You are now connected to a node, and you can run Memcached commands. The following is an example.
```
set a 0 0 5 // Set key "a" with no expiration and 5 byte value
hello // Set value as "hello"
STORED
get a // Get value for key "a"
VALUE a 0 5
hello
END
get b // Get value for key "b" results in miss
END
>
```
# Supported node types
ElastiCache supports the following node types. Generally speaking, the current generation types provide more memory and computational power at lower cost when compared to their equivalent previous generation counterparts.
For more information on performance details for each node type, see [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/).
**Note**
Amazon ElastiCache is transitioning T2 instances to previous generation status. You will no longer be able to create new ElastiCache clusters using T2 instances or purchase new T2 reserved nodes. There is no impact to existing T2 clusters or reservations. We recommend upgrading to newer instance types such as T3 or T4g instances for better performance and cost efficiency.
**Note**
The following instance types are supported in the AWS Asia Pacific (Thailand) and Mexico (Central) Regions:
**m7g/r7g:** large, xl, 2xl, 4xl, 8xl, 12xl, and 16xl.
**t3/t4g:** micro, small, and medium.
For information on which node size to use, see [Choosing your node size](CacheNodes.SelectSize.md).
**Topics**
+ [Current Generation (Memcached)](#CacheNodes.CurrentGen-Memcached)
+ [Current Generation (Valkey or Redis OSS)](#CacheNodes.CurrentGen)
+ [Supported node types by AWS Region](#CacheNodes.SupportedTypesByRegion)
+ [Burstable Performance Instances](#CacheNodes.Burstable)
+ [Related Information](#CacheNodes.RelatedInfo)
## Current Generation (Memcached)
The following tables show the baseline and burst bandwidth for instance types that use the network I/O credit mechanism to burst beyond their baseline bandwidth.
**Note**
Instance types with burstable network performance use a network I/O credit mechanism to burst beyond their baseline bandwidth on a best-effort basis.
**General**
| Instance type | Minimum supported Memcached version | Baseline bandwidth (Gbps) | Burst bandwidth (Gbps) |
| --- | --- | --- | --- |
| cache.m7g.large | | 0.937 | 12.5 |
| cache.m7g.xlarge | | 1.876 | 12.5 |
| cache.m7g.2xlarge | | 3.75 | 15 |
| cache.m7g.4xlarge | | 7.5 | 15 |
| cache.m7g.8xlarge | | 15 | N/A |
| cache.m7g.12xlarge | | 22.5 | N/A |
| cache.m7g.16xlarge | | 30 | N/A |
| cache.m6g.large | 1.5.16 | 0.75 | 10.0 |
| cache.m6g.xlarge | 1.5.16 | 1.25 | 10.0 |
| cache.m6g.2xlarge | 1.5.16 | 2.5 | 10.0 |
| cache.m6g.4xlarge | 1.5.16 | 5.0 | 10.0 |
| cache.m6g.8xlarge | 1.5.16 | 12 | N/A |
| cache.m6g.12xlarge | 1.5.16 | 20 | N/A |
| cache.m6g.16xlarge | 1.5.16 | 25 | N/A |
| cache.m5.large | 1.5.16 | 0.75 | 10.0 |
| cache.m5.xlarge | 1.5.16 | 1.25 | 10.0 |
| cache.m5.2xlarge | 1.5.16 | 2.5 | 10.0 |
| cache.m5.4xlarge | 1.5.16 | 5.0 | 10.0 |
| cache.m5.12xlarge | 1.5.16 | N/A | N/A |
| cache.m5.24xlarge | 1.5.16 | N/A | N/A |
| cache.m4.large | 1.5.16 | 0.45 | 1.2 |
| cache.m4.xlarge | 1.5.16 | 0.75 | 2.8 |
| cache.m4.2xlarge | 1.5.16 | 1.0 | 10.0 |
| cache.m4.4xlarge | 1.5.16 | 2.0 | 10.0 |
| cache.m4.10xlarge | 1.5.16 | 5.0 | 10.0 |
| cache.t4g.micro | 1.5.16 | 0.064 | 5.0 |
| cache.t4g.small | 1.5.16 | 0.128 | 5.0 |
| cache.t4g.medium | 1.5.16 | 0.256 | 5.0 |
| cache.t3.micro | 1.5.16 | 0.064 | 5.0 |
| cache.t3.small | 1.5.16 | 0.128 | 5.0 |
| cache.t3.medium | 1.5.16 | 0.256 | 5.0 |
| cache.t2.micro | 1.5.16 | 0.064 | 1.024 |
| cache.t2.small | 1.5.16 | 0.128 | 1.024 |
| cache.t2.medium | 1.5.16 | 0.256 | 1.024 |
**Memory optimized for Memcached**
| Instance type | Minimum supported version | Baseline bandwidth (Gbps) | Burst bandwidth (Gbps) |
| --- | --- | --- | --- |
| cache.r7g.large | | 0.937 | 12.5 |
| cache.r7g.xlarge | | 1.876 | 12.5 |
| cache.r7g.2xlarge | | 3.75 | 15 |
| cache.r7g.4xlarge | | 7.5 | 15 |
| cache.r7g.8xlarge | | 15 | N/A |
| cache.r7g.12xlarge | | 22.5 | N/A |
| cache.r7g.16xlarge | | 30 | N/A |
| cache.r6g.large | 1.5.16 | 0.75 | 10.0 |
| cache.r6g.xlarge | 1.5.16 | 1.25 | 10.0 |
| cache.r6g.2xlarge | 1.5.16 | 2.5 | 10.0 |
| cache.r6g.4xlarge | 1.5.16 | 5.0 | 10.0 |
| cache.r6g.8xlarge | 1.5.16 | 12 | N/A |
| cache.r6g.12xlarge | 1.5.16 | 20 | N/A |
| cache.r6g.16xlarge | 1.5.16 | 25 | N/A |
| cache.r5.large | 1.5.16 | 0.75 | 10.0 |
| cache.r5.xlarge | 1.5.16 | 1.25 | 10.0 |
| cache.r5.2xlarge | 1.5.16 | 2.5 | 10.0 |
| cache.r5.4xlarge | 1.5.16 | 5.0 | 10.0 |
| cache.r5.12xlarge | 1.5.16 | 20 | N/A |
| cache.r5.24xlarge | 1.5.16 | 25 | N/A |
| cache.r4.large | 1.5.16 | 0.75 | 10.0 |
| cache.r4.xlarge | 1.5.16 | 1.25 | 10.0 |
| cache.r4.2xlarge | 1.5.16 | 2.5 | 10.0 |
| cache.r4.4xlarge | 1.5.16 | 5.0 | 10.0 |
| cache.r4.8xlarge | 1.5.16 | 12 | N/A |
| cache.r4.16xlarge | 1.5.16 | 25 | N/A |
**Network optimized for Memcached**
| Instance type | Minimum supported version | Baseline bandwidth (Gbps) | Burst bandwidth (Gbps) |
| --- | --- | --- | --- |
| cache.c7gn.large | 1.6.6 | 6.25 | 30 |
| cache.c7gn.xlarge | 1.6.6 | 12.5 | 40 |
| cache.c7gn.2xlarge | 1.6.6 | 25 | 50 |
| cache.c7gn.4xlarge | 1.6.6 | 50 | N/A |
| cache.c7gn.8xlarge | 1.6.6 | 100 | N/A |
| cache.c7gn.12xlarge | 1.6.6 | 150 | N/A |
| cache.c7gn.16xlarge | 1.6.6 | 200 | N/A |
## Current Generation (Valkey or Redis OSS)
For more information on Previous Generation, please refer to [Previous Generation Nodes](https://aws.amazon.com/elasticache/previous-generation/).
**Note**
Instance types with burstable network performance use a network I/O credit mechanism to burst beyond their baseline bandwidth on a best-effort basis.
**General**
| Instance type | Minimum supported Redis OSS version | Enhanced I/O with Redis OSS 5.0.6\$1 | TLS Offloading with Redis OSS 6.2.5\$1 | Enhanced I/O Multiplexing with Redis OSS 7.0.4\$1 | Baseline bandwidth (Gbps) | Burst bandwidth (Gbps) |
| --- | --- | --- | --- | --- | --- | --- |
| cache.m7g.large | 6.2 | N | N | N | 0.937 | 12.5 |
| cache.m7g.xlarge | 6.2 | Y | Y | Y | 1.876 | 12.5 |
| cache.m7g.2xlarge | 6.2 | Y | Y | Y | 3.75 | 15 |
| cache.m7g.4xlarge | 6.2 | Y | Y | Y | 7.5 | 15 |
| cache.m7g.8xlarge | 6.2 | Y | Y | Y | 15 | N/A |
| cache.m7g.12xlarge | 6.2 | Y | Y | Y | 22.5 | N/A |
| cache.m7g.16xlarge | 6.2 | Y | Y | Y | 30 | N/A |
| cache.m6g.large | 5.0.6 | N | N | N | 0.75 | 10.0 |
| cache.m6g.xlarge | 5.0.6 | Y | Y | Y | 1.25 | 10.0 |
| cache.m6g.2xlarge | 5.0.6 | Y | Y | Y | 2.5 | 10.0 |
| cache.m6g.4xlarge | 5.0.6 | Y | Y | Y | 5.0 | 10.0 |
| cache.m6g.8xlarge | 5.0.6 | Y | Y | Y | 12 | N/A |
| cache.m6g.12xlarge | 5.0.6 | Y | Y | Y | 20 | N/A |
| cache.m6g.16xlarge | 5.0.6 | Y | Y | Y | 25 | N/A |
| cache.m5.large | 3.2.4 | N | N | N | 0.75 | 10.0 |
| cache.m5.xlarge | 3.2.4 | Y | N | N | 1.25 | 10.0 |
| cache.m5.2xlarge | 3.2.4 | Y | Y | Y | 2.5 | 10.0 |
| cache.m5.4xlarge | 3.2.4 | Y | Y | Y | 5.0 | 10.0 |
| cache.m5.12xlarge | 3.2.4 | Y | Y | Y | 12 | N/A |
| cache.m5.24xlarge | 3.2.4 | Y | Y | Y | 25 | N/A |
| cache.m4.large | 3.2.4 | N | N | N | 0.45 | 1.2 |
| cache.m4.xlarge | 3.2.4 | Y | N | N | 0.75 | 2.8 |
| cache.m4.2xlarge | 3.2.4 | Y | Y | Y | 1.0 | 10.0 |
| cache.m4.4xlarge | 3.2.4 | Y | Y | Y | 2.0 | 10.0 |
| cache.m4.10xlarge | 3.2.4 | Y | Y | Y | 5.0 | 10.0 |
| cache.t4g.micro | 3.2.4 | N | N | N | 0.064 | 5.0 |
| cache.t4g.small | 5.0.6 | N | N | N | 0.128 | 5.0 |
| cache.t4g.medium | 5.0.6 | N | N | N | 0.256 | 5.0 |
| cache.t3.micro | 3.2.4 | N | N | N | 0.064 | 5.0 |
| cache.t3.small | 3.2.4 | N | N | N | 0.128 | 5.0 |
| cache.t3.medium | 3.2.4 | N | N | N | 0.256 | 5.0 |
| cache.t2.micro | 3.2.4 | N | N | N | 0.064 | 1.024 |
| cache.t2.small | 3.2.4 | N | N | N | 0.128 | 1.024 |
| cache.t2.medium | 3.2.4 | N | N | N | 0.256 | 1.024 |
**Memory optimized**
| Instance type | Minimum supported Redis OSS version | Enhanced I/O with Redis OSS 5.0.6\$1 | TLS Offloading with Redis OSS 6.2.5\$1 | Enhanced I/O Multiplexing with Redis OSS 7.0.4\$1 | Baseline bandwidth (Gbps) | Burst bandwidth (Gbps) |
| --- | --- | --- | --- | --- | --- | --- |
| cache.r7g.large | 6.2 | N | N | N | 0.937 | 12.5 |
| cache.r7g.xlarge | 6.2 | Y | Y | Y | 1.876 | 12.5 |
| cache.r7g.2xlarge | 6.2 | Y | Y | Y | 3.75 | 15 |
| cache.r7g.4xlarge | 6.2 | Y | Y | Y | 7.5 | 15 |
| cache.r7g.8xlarge | 6.2 | Y | Y | Y | 15 | N/A |
| cache.r7g.12xlarge | 6.2 | Y | Y | Y | 22.5 | N/A |
| cache.r7g.16xlarge | 6.2 | Y | Y | Y | 30 | N/A |
| cache.r6g.large | 5.0.6 | N | N | N | 0.75 | 10.0 |
| cache.r6g.xlarge | 5.0.6 | Y | Y | Y | 1.25 | 10.0 |
| cache.r6g.2xlarge | 5.0.6 | Y | Y | Y | 2.5 | 10.0 |
| cache.r6g.4xlarge | 5.0.6 | Y | Y | Y | 5.0 | 10.0 |
| cache.r6g.8xlarge | 5.0.6 | Y | Y | Y | 12 | N/A |
| cache.r6g.12xlarge | 5.0.6 | Y | Y | Y | 20 | N/A |
| cache.r6g.16xlarge | 5.0.6 | Y | Y | Y | 25 | N/A |
| cache.r5.large | 3.2.4 | N | N | N | 0.75 | 10.0 |
| cache.r5.xlarge | 3.2.4 | Y | N | N | 1.25 | 10.0 |
| cache.r5.2xlarge | 3.2.4 | Y | Y | Y | 2.5 | 10.0 |
| cache.r5.4xlarge | 3.2.4 | Y | Y | Y | 5.0 | 10.0 |
| cache.r5.12xlarge | 3.2.4 | Y | Y | Y | 12 | N/A |
| cache.r5.24xlarge | 3.2.4 | Y | Y | Y | 25 | N/A |
| cache.r4.large | 3.2.4 | N | N | N | 0.75 | 10.0 |
| cache.r4.xlarge | 3.2.4 | Y | N | N | 1.25 | 10.0 |
| cache.r4.2xlarge | 3.2.4 | Y | Y | Y | 2.5 | 10.0 |
| cache.r4.4xlarge | 3.2.4 | Y | Y | Y | 5.0 | 10.0 |
| cache.r4.8xlarge | 3.2.4 | Y | Y | Y | 12 | N/A |
| cache.r4.16xlarge | 3.2.4 | Y | Y | Y | 25 | N/A |
**Memory optimized with data tiering**
| Instance type | Minimum supported Redis OSS version | Enhanced I/O with Redis OSS 5.0.6\$1 | TLS Offloading with Redis OSS 6.2.5\$1 | Enhanced I/O Multiplexing with Redis OSS 7.0.4\$1 | Baseline bandwidth (Gbps) | Burst bandwidth (Gbps) |
| --- | --- | --- | --- | --- | --- | --- |
| cache.r6gd.xlarge | 6.2.0 | Y | N | N | 1.25 | 10 |
| cache.r6gd.2xlarge | 6.2.0 | Y | Y | Y | 2.5 | 10 |
| cache.r6gd.4xlarge | 6.2.0 | Y | Y | Y | 5.0 | 10 |
| cache.r6gd.8xlarge | 6.2.0 | Y | Y | Y | 12 | N/A |
| cache.r6gd.12xlarge | 6.2.0 | Y | Y | Y | 20 | N/A |
| cache.r6gd.16xlarge | 6.2.0 | Y | Y | Y | 25 | N/A |
**Network optimized**
| Instance type | Minimum supported Redis OSS version | Enhanced I/O with Redis OSS 5.0.6\$1 | TLS Offloading with Redis OSS 6.2.5\$1 | Enhanced I/O Multiplexing with Redis OSS 7.0.4\$1 | Baseline bandwidth (Gbps) | Burst bandwidth (Gbps) |
| --- | --- | --- | --- | --- | --- | --- |
| cache.c7gn.large | 6.2 | N | N | N | 6.25 | 30 |
| cache.c7gn.xlarge | 6.2 | Y | Y | Y | 12.5 | 40 |
| cache.c7gn.2xlarge | 6.2 | Y | Y | Y | 25 | 50 |
| cache.c7gn.4xlarge | 6.2 | Y | Y | Y | 50 | N/A |
| cache.c7gn.8xlarge | 6.2 | Y | Y | Y | 100 | N/A |
| cache.c7gn.12xlarge | 6.2 | Y | Y | Y | 150 | N/A |
| cache.c7gn.16xlarge | 6.2 | Y | Y | Y | 200 | N/A |
## Supported node types by AWS Region
Supported node types may vary between AWS Regions. For more details, see [Amazon ElastiCache pricing](https://aws.amazon.com/elasticache/pricing/).
## Burstable Performance Instances
You can launch general-purpose burstable T4g, T3-Standard and T2-Standard cache nodes in Amazon ElastiCache. These nodes provide a baseline level of CPU performance with the ability to burst CPU usage at any time until the accrued credits are exhausted. A *CPU credit* provides the performance of a full CPU core for one minute.
Amazon ElastiCache's T4g, T3 and T2 nodes are configured as standard and suited for workloads with an average CPU utilization that is consistently below the baseline performance of the instance. To burst above the baseline, the node spends credits that it has accrued in its CPU credit balance. If the node is running low on accrued credits, performance is gradually lowered to the baseline performance level. This gradual lowering ensures the node doesn't experience a sharp performance drop-off when its accrued CPU credit balance is depleted. For more information, see [CPU Credits and Baseline Performance for Burstable Performance Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html) in the *Amazon EC2 User Guide*.**
The following table lists the burstable performance node types, the rate at which CPU credits are earned per hour. It also shows the maximum number of earned CPU credits that a node can accrue and the number of vCPUs per node. In addition, it gives the baseline performance level as a percentage of a full core performance (using a single vCPU).
| Node type | CPU credits earned per hour | Maximum earned credits that can be accrued\$1 | vCPUs | Baseline performance per vCPU | Memory (GiB) | Network performance |
| --- | --- | --- | --- | --- | --- | --- |
| t4g.micro | 12 | 288 | 2 | 10% | 0.5 | Up to 5 Gigabit |
| t4g.small | 24 | 576 | 2 | 20% | 1.37 | Up to 5 Gigabit |
| t4g.medium | 24 | 576 | 2 | 20% | 3.09 | Up to 5 Gigabit |
| t3.micro | 12 | 288 | 2 | 10% | 0.5 | Up to 5 Gigabit |
| t3.small | 24 | 576 | 2 | 20% | 1.37 | Up to 5 Gigabit |
| t3.medium | 24 | 576 | 2 | 20% | 3.09 | Up to 5 Gigabit |
| t2.micro | 6 | 144 | 1 | 10% | 0.5 | Low to moderate |
| t2.small | 12 | 288 | 1 | 20% | 1.55 | Low to moderate |
| t2.medium | 24 | 576 | 2 | 20% | 3.22 | Low to moderate |
\$1 The number of credits that can be accrued is equivalent to the number of credits that can be earned in a 24-hour period.
\$1\$1 The baseline performance in the table is per vCPU. Some node sizes that have more than one vCPU. For these, calculate the baseline CPU utilization for the node by multiplying the vCPU percentage by the number of vCPUs.
The following CPU credit metrics are available for T3 and T4g burstable performance instances:
**Note**
These metrics are not available for T2 burstable performance instances.
+ `CPUCreditUsage`
+ `CPUCreditBalance`
For more information on these metrics, see [CPU Credit Metrics](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#cpu-credit-metrics).
In addition, be aware of these details:
+ All current generation node types are created in a virtual private cloud (VPC) based on Amazon VPC by default.
+ Redis OSS append-only files (AOF) aren't supported for T2 instances. Redis OSS configuration variables `appendonly` and `appendfsync` aren't supported on Redis OSS version 2.8.22 and later.
## Related Information
+ [Amazon ElastiCache Product Features and Details](https://aws.amazon.com/elasticache/details)
+ [Memcached Node-Type Specific Parameters for Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached)
+ [Valkey and Redis OSS parameters](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [In Transit Encryption (TLS)](in-transit-encryption.md)
# Rebooting nodes
Some changes require that a Valkey, Memcached, or Redis OSS cluster reboot for the changes to be applied. For example, for some parameters, changing the parameter value in a parameter group is only applied after a reboot.
**Topics**
+ [Rebooting Valkey or Redis OSS nodes (cluster mode disabled only)](#nodes.rebooting.redis)
+ [Rebooting a cluster for Memcached](#Clusters.Rebooting)
## Rebooting Valkey or Redis OSS nodes (cluster mode disabled only)
For Valkey or Redis OSS (cluster mode disabled) clusters, the parameters in parameter groups that are applied only after rebooting are:
+ activerehashing
+ databases
Valkey and Redis OSS nodes can only be updated through the ElastiCache console. You can only reboot a single node at a time. To reboot multiple nodes, you must repeat the process for each node.
**Valkey or Redis OSS (Cluster Mode Enabled) parameter changes**
If you make changes to the following parameters on a Valkey or Redis OSS (cluster mode enabled) cluster, follow the ensuing steps.
activerehashing
databases
Create a manual backup of your cluster. See [Taking manual backups](backups-manual.md).
Delete the Valkey or Redis OSS (cluster mode enabled) cluster. See [Deleting a cluster in ElastiCache](Clusters.Delete.md).
Restore the cluster using the altered parameter group and backup to seed the new cluster. See [Restoring from a backup into a new cache](backups-restoring.md).
Changes to other parameters do not require this.
### Using the AWS Management Console
You can reboot a node using the ElastiCache console.
**To reboot a node (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 list in the upper-right corner, choose the AWS Region that applies.
1. In the left navigation pane, choose **Valkey or Redis OSS**.
A list of clusters running Valkey or Redis OSS appears.
1. Choose the cluster under **Cluster Name**.
1. Under **Node name**, choose the radio button next to the node you want to reboot.
1. Choose **Actions**, and then choose **Reboot node**.
To reboot multiple nodes, repeat steps 2 through 5 for each node that you want to reboot. You do not need to wait for one node to finish rebooting to reboot another.
## Rebooting a cluster for Memcached
When you reboot a Memcached cluster, the cluster flushes all its data and restarts its engine. During this process you cannot access the cluster. Because the cluster flushed all its data, when the cluster is available again, you are starting with an empty cluster.
You are able to reboot a cluster using the ElastiCache console, the AWS CLI, or the ElastiCache API. Whether you use the ElastiCache console, the AWS CLI or the ElastiCache API, you can only initiate rebooting a single cluster. To reboot multiple clusters you must iterate on the process or operation.
### Using the AWS Management Console
You can reboot a cluster using the ElastiCache console.
**To reboot a 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 list in the upper-right corner, choose the AWS Region you are interested in.
1. In the navigation pane, choose the engine running on the cluster that you want to reboot.
A list of clusters running the chosen engine appears.
1. Choose the cluster to reboot by choosing on the box to the left of the cluster's name.
The **Reboot** button becomes active.
If you choose more than one cluster, the **Reboot** button isn't active.
1. Choose **Reboot**.
The reboot cluster confirmation screen appears.
1. To reboot the cluster, choose **Reboot**. The status of the cluster changes to *rebooting cluster nodes*.
To not reboot the cluster, choose **Cancel**.
To reboot multiple clusters, repeat steps 2 through 5 for each cluster that you want to reboot. You do not need to wait for one cluster to finish rebooting to reboot another.
To reboot a specific node, select the node and then choose **Reboot**.
### Using the AWS CLI
To reboot a cluster (AWS CLI), use the `reboot-cache-cluster` CLI operation.
To reboot specific nodes in the cluster, use the `--cache-node-ids-to-reboot` to list the specific clusters to reboot. The following command reboots the nodes 0001, 0002, and 0004 of *my-cluster*.
For Linux, macOS, or Unix:
```
aws elasticache reboot-cache-cluster \
--cache-cluster-id my-cluster \
--cache-node-ids-to-reboot 0001 0002 0004
```
For Windows:
```
aws elasticache reboot-cache-cluster ^
--cache-cluster-id my-cluster ^
--cache-node-ids-to-reboot 0001 0002 0004
```
To reboot all the nodes in the cluster, use the `--cache-node-ids-to-reboot` parameter and list all the cluster's node ids. For more information, see [reboot-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/reboot-cache-cluster.html).
### Using the ElastiCache API
To reboot a cluster using the ElastiCache API, use the `RebootCacheCluster` action.
To reboot specific nodes in the cluster, use the `CacheNodeIdsToReboot` to list the specific clusters to reboot. The following command reboots the nodes 0001, 0002, and 0004 of *my-cluster*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=RebootCacheCluster
&CacheClusterId=my-cluster
&CacheNodeIdsToReboot.member.1=0001
&CacheNodeIdsToReboot.member.2=0002
&CacheNodeIdsToReboot.member.3=0004
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
To reboot all the nodes in the cluster, use the `CacheNodeIdsToReboot` parameter and list all the cluster's node ids. For more information, see [RebootCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RebootCacheCluster.html).
# Replacing nodes (Valkey and Redis OSS)
Amazon ElastiCache frequently upgrades its fleet with patches and upgrades being applied to instances seamlessly. However, from time to time we need to relaunch your ElastiCache nodes to apply mandatory OS updates to the underlying host. These replacements are required to apply upgrades that strengthen security, reliability, and operational performance.
You have the option to manage these replacements yourself at any time before the scheduled node replacement window. When you manage a replacement yourself, your instance receives the OS update when you relaunch the node and your scheduled node replacement is canceled. You might continue to receive alerts indicating that the node replacement is to take place. If you've already manually mitigated the need for the maintenance, you can ignore these alerts.
**Note**
Replacement cache nodes automatically generated by Amazon ElastiCache may have different IP addresses. You are responsible for reviewing your application configuration to ensure that your cache nodes are associated with the appropriate IP addresses.
The following list identifies actions you can take when ElastiCache schedules one of your Valkey or Redis OSS nodes for replacement. To expedite finding the information you need for your situation, choose from the following menu.
+ [Do nothing](#DoNothing) – Let Amazon ElastiCache replace the node as scheduled.
+ [Change your maintenance window](#ChangeWindow) – Change your maintenance window to a better time.
+ Valkey or Redis OSS (cluster mode enabled) Configurations
+ [Replace the only node in any Valkey or Redis OSS cluster](#ReplaceStandalone) – A procedure to replace a node in a Valkey or Redis OSS cluster using backup and restore.
+ [Replace a replica node in any Valkey or Redis OSS cluster](#ReplaceReplica) – A procedure to replace a read-replica in any Valkey or Redis OSS cluster by increasing and decreasing the replica count with no cluster downtime.
+ [Replace any node in a Valkey or Redis OSS (cluster mode enabled) shard](#ReplaceShardNode) – A dynamic procedure with no cluster downtime to replace a node in a Valkey or Redis OSS (cluster mode enabled) cluster by scaling out and scaling in.
+ Valkey or Redis OSS (cluster mode disabled) Configurations
+ [Replace the only node in any Valkey or Redis OSS cluster](#ReplaceStandalone) – Procedure to replace any node in a Valkey or Redis OSS cluster using backup and restore.
+ [Replace a replica node in any Valkey or Redis OSS cluster](#ReplaceReplica) – A procedure to replace a read-replica in any Valkey or Redis OSS cluster by increasing and decreasing the replica count with no cluster downtime.
+ [Replace a node in a Valkey or Redis OSS (cluster mode disabled) cluster](#ReplaceStandaloneClassic) – Procedure to replace a node in a Valkey or Redis OSS (cluster mode disabled) cluster using replication.
+ [Replace a Valkey or Redis OSS (cluster mode disabled) read-replica](#ReplaceReadReplica) – A procedure to manually replace a read-replica in a Valkey or Redis OSS (cluster mode disabled) replication group.
+ [Replace a Valkey or Redis OSS (cluster mode disabled) primary node](#ReplacePrimary) – A procedure to manually replace the primary node in a Valkey or Redis OSS (cluster mode disabled) replication group.
**Valkey and Redis OSS node replacement options**
+ **Do nothing** – If you do nothing, ElastiCache replaces the node as scheduled.
For non-Cluster configurations with autofailover enabled, clusters on Valkey 7.2 and above and Redis OSS 5.0.6 and above complete replacement while the cluster continues to stay online and serve incoming write requests. For auto failover enabled clusters on Redis OSS 4.0.10 or below, you might notice a brief write interruption of up to a few seconds associated with DNS updates.
If the node is a member of an auto failover enabled cluster, ElastiCache for Valkey or Redis OSS provides improved availability during patching, updates, and other maintenance-related node replacements.
For ElastiCache cluster configurations that are set up to use ElastiCache for Valkey or Redis OSS cluster clients, replacement now completes while the cluster serves incoming write requests.
For non-cluster configurations with autofailover enabled, clusters on Valkey 7.2 and above and Redis OSS 5.0.6 and above complete replacement while the cluster continues to stay online and serve incoming write requests. For auto failover enabled clusters on Redis OSS 4.0.10 or below, you might notice a brief write interruption of up to a few seconds associated with DNS updates.
If the node is standalone, Amazon ElastiCache first launches a replacement node and then syncs from the existing node. The existing node isn't available for service requests during this time. Once the sync is complete, the existing node is terminated and the new node takes its place. ElastiCache makes a best effort to retain your data during this operation.
+ **Change your maintenance window** – For scheduled maintenance events, you receive an email or a notification event from ElastiCache. In these cases, if you change your maintenance window before the scheduled replacement time, your node now is replaced at the new time. For more information, see the following:
+ [Modifying an ElastiCache cluster](Clusters.Modify.md)
+ [Modifying a replication group](Replication.Modify.md)
**Note**
The ability to change your replacement window by moving your maintenance window is only available when the ElastiCache notification includes a maintenance window. If the notification does not include a maintenance window, you cannot change your replacement window.
For example, let's say it's Thursday, November 9, at 15:00 and the next maintenance window is Friday, November 10, at 17:00. Following are three scenarios with their outcomes:
+ You change your maintenance window to Fridays at 16:00, after the current date and time and before the next scheduled maintenance window. The node is replaced on Friday, November 10, at 16:00.
+ You change your maintenance window to Saturday at 16:00, after the current date and time and after the next scheduled maintenance window. The node is replaced on Saturday, November 11, at 16:00.
+ You change your maintenance window to Wednesday at 16:00, earlier in the week than the current date and time). The node is replaced next Wednesday, November 15, at 16:00.
For instructions, see [Managing ElastiCache cluster maintenance](maintenance-window.md).
+ **Replace the only node in any Valkey or Redis OSS cluster** – If the cluster does not have any read replicas, you can use the following procedure to replace the node.
**To replace the only node using backup and restore**
1. Create a snapshot of the node's cluster. For instructions, see [Taking manual backups](backups-manual.md).
1. Create a new cluster seeding it from the snapshot. For instructions, see [Restoring from a backup into a new cache](backups-restoring.md).
1. Delete the cluster with the node scheduled for replacement. For instructions, see [Deleting a cluster in ElastiCache](Clusters.Delete.md).
1. In your application, replace the old node's endpoint with the new node's endpoint.
+ **Replace a replica node in any Valkey or Redis OSS cluster** – To replace a replica cluster, increase your replica count. To do this, add a replica then decrease the replica count by removing the replica that you want to replace. This process is dynamic and doesn't have any cluster downtime.
**Note**
If your shard or replication group already has five replicas, reverse steps 1 and 2.
**To replace a replica in any Valkey or Redis OSS cluster**
1. Increase the replica count by adding a replica to the shard or replication group. For more information, see [Increasing the number of replicas in a shard](increase-replica-count.md).
1. Delete the replica you want to replace. For more information, see [Decreasing the number of replicas in a shard](decrease-replica-count.md).
1. Update the endpoints in your application.
+ **Replace any node in a Valkey or Redis OSS (cluster mode enabled) shard** – To replace the node in a cluster with no downtime, use online resharding. First add a shard by scaling out, and then delete the shard with the node to be replaced by scaling in.
**To replace any node in a Valkey or Redis OSS (cluster mode enabled) cluster**
1. Scale out: Add an additional shard with the same configuration as the existing shard with the node to be replaced. For more information, see [Adding shards with online resharding](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online-add).
1. Scale in: Delete the shard with the node to be replaced. For more information, see [Removing shards with online resharding](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online-remove).
1. Update the endpoints in your application.
+ **Replace a node in a Valkey or Redis OSS (cluster mode disabled) cluster** – If the cluster is a Valkey or Redis OSS (cluster mode disabled) cluster without any read replicas, use the following procedure to replace the node.
**To replace the node using replication (cluster mode disabled only)**
1. Add replication to the cluster with the node scheduled for replacement as the primary. Do not enable Multi-AZ on this cluster. For instructions, see [To add replication to a Valkey or Redis OSS cluster with no shards](Clusters.AddNode.md#AddReplication.CON).
1. Add a read-replica to the cluster. For instructions, see [To add nodes to an ElastiCache cluster (console)](Clusters.AddNode.md#AddNode.CON).
1. Promote the newly created read-replica to primary. For instructions, see [Promoting a read replica to primary, for Valkey or Redis OSS (cluster mode disabled) replication groups](Replication.PromoteReplica.md).
1. Delete the node scheduled for replacement. For instructions, see [Removing nodes from an ElastiCache cluster](Clusters.DeleteNode.md).
1. In your application, replace the old node's endpoint with the new node's endpoint.
+ **Replace a Valkey or Redis OSS (cluster mode disabled) read-replica** – If the node is a read-replica, replace the node.
If your cluster has only one replica node and Multi-AZ is enabled, you must disable Multi-AZ before you can delete the replica. For instructions, see [Modifying a replication group](Replication.Modify.md).
**To replace a Valkey or Redis OSS (cluster mode disabled) read replica**
1. Delete the replica that is scheduled for replacement. For instructions, see the following:
+ [Decreasing the number of replicas in a shard](decrease-replica-count.md)
+ [Removing nodes from an ElastiCache cluster](Clusters.DeleteNode.md)
1. Add a new replica to replace the one that is scheduled for replacement. If you use the same name as the replica you just deleted, you can skip step 3. For instructions, see the following:
+ [Increasing the number of replicas in a shard](increase-replica-count.md)
+ [Adding a read replica for Valkey or Redis OSS (Cluster Mode Disabled)](Replication.AddReadReplica.md)
1. In your application, replace the old replica's endpoint with the new replica's endpoint.
1. If you disabled Multi-AZ at the start, re-enable it now. For instructions, see [Enabling Multi-AZ](AutoFailover.md#AutoFailover.Enable).
+ **Replace a Valkey or Redis OSS (cluster mode disabled) primary node** – If the node is the primary node, first promote a read-replica to primary. Then delete the replica that used to be the primary node.
If your cluster has only one replica and Multi-AZ is enabled, you must disable Multi-AZ before you can delete the replica in step 2. For instructions, see [Modifying a replication group](Replication.Modify.md).
**To replace a Valkey or Redis OSS (cluster mode disabled) primary node**
1. Promote a read-replica to primary. For instructions, see [Promoting a read replica to primary, for Valkey or Redis OSS (cluster mode disabled) replication groups](Replication.PromoteReplica.md).
1. Delete the node that is scheduled for replacement (the old primary). For instructions, see [Removing nodes from an ElastiCache cluster](Clusters.DeleteNode.md).
1. Add a new replica to replace the one scheduled for replacement. If you use the same name as the node you just deleted, you can skip changing endpoints in your application.
For instructions, see [Adding a read replica for Valkey or Redis OSS (Cluster Mode Disabled)](Replication.AddReadReplica.md).
1. In your application, replace the old node's endpoint with the new node's endpoint.
1. If you disabled Multi-AZ at the start, re-enable it now. For instructions, see [Enabling Multi-AZ](AutoFailover.md#AutoFailover.Enable).
# Replacing nodes (Memcached)
Amazon ElastiCache for Memcached frequently upgrades its fleet with patches and upgrades being applied to instances seamlessly. However, from time to time we need to relaunch your ElastiCache for Memcached nodes to apply mandatory OS updates to the underlying host. These replacements are required to apply upgrades that strengthen security, reliability, and operational performance.
You have the option to manage these replacements yourself at any time before the scheduled node replacement window. When you manage a replacement yourself, your instance receives the OS update when you relaunch the node and your scheduled node replacement is canceled. You might continue to receive alerts indicating that the node replacement takes place. If you already manually mitigated the need for the maintenance, you can ignore these alerts.
**Note**
Replacement cache nodes automatically generated by Amazon ElastiCache may have different IP addresses. You are responsible for reviewing your application configuration to ensure that your cache nodes are associated with the appropriate IP addresses.
The following list identifies actions you can take when ElastiCache schedules one of your Memcached nodes for replacement.
+ **Do nothing** – If you do nothing, ElastiCache replaces the node as scheduled. When ElastiCache automatically replaces the node with a new node, the new node is initially empty.
+ **Change your maintenance window** – For scheduled maintenance events, you receive an email or a notification event from ElastiCache. In this case, if you change your maintenance window before the scheduled replacement time, your node now is replaced at the new time. For more information, see [Modifying an ElastiCache cluster](Clusters.Modify.md).
**Note**
The ability to change your replacement window by moving your maintenance window is only available when the ElastiCache notification includes a maintenance window. If the notification does not include a maintenance window, you cannot change your replacement window.
For example, let's say it's Thursday, November 9, at 15:00 and the next maintenance window is Friday, November 10, at 17:00. Following are three scenarios with their outcomes:
+ You change your maintenance window to Fridays at 16:00, after the current date and time and before the next scheduled maintenance window. The node is replaced on Friday, November 10, at 16:00.
+ You change your maintenance window to Saturday at 16:00, after the current date and time and after the next scheduled maintenance window. The node is replaced on Saturday, November 11, at 16:00.
+ You change your maintenance window to Wednesday at 16:00, earlier in the week than the current date and time). The node is replaced next Wednesday, November 15, at 16:00.
For instructions, see [Managing ElastiCache cluster maintenance](maintenance-window.md).
+ **Manually replace the node** – If you need to replace the node before the next maintenance window, manually replace the node.
If you manually replace the node, keys are redistributed. This redistribution causes cache misses.
**To manually replace a Memcached node**
1. Delete the node scheduled for replacement. For instructions, see [Removing nodes from an ElastiCache cluster](Clusters.DeleteNode.md).
1. Add a new node to the cluster. For instructions, see [Adding nodes to an ElastiCache cluster](Clusters.AddNode.md).
1. If you are not using auto discovery on this cluster, see your application and replace every instance of the old node's endpoint with the new node's endpoint.
# Reserved nodes
Reserving one or more ElastiCache nodes might be a way for you to reduce costs. Reserved nodes are charged an up front fee that depends upon the node type and the length of reservation— one or three years.
To see if reserved nodes are a cost savings for your use cases, first determine the node size and number of nodes you need. Then estimate the usage of the node, and compare the total cost to you of using On-Demand nodes versus reserved nodes. You can mix and match reserved and On-Demand node usage in your clusters. For pricing information, see [Amazon ElastiCache Pricing](https://aws.amazon.com/elasticache/pricing/).
**Topics**
+ [Managing costs with reserved nodes](#reserved-nodes)
+ [Standard reserved node offerings](#reserved-nodes-standard)
+ [Size flexible reserved nodes](#reserved-nodes-size)
+ [Deleting a reserved node](#reserved-nodes-deleting)
+ [Legacy reserved node offerings](#reserved-nodes-utilization)
+ [Getting info about reserved node offerings](#reserved-nodes-offerings)
+ [Purchasing a reserved node](#reserved-nodes-purchasing)
+ [Getting info about your reserved nodes](#reserved-nodes-describing)
## Managing costs with reserved nodes
Reserving one or more nodes may be a way for you to reduce costs. Reserved nodes are charged an up front fee that depends upon the node type and the length of reservation—one or three years. This charge is much less than the hourly usage charge that you incur with On-Demand nodes.
To see if reserved nodes are a cost savings for your use cases, first determine the node size and number of nodes you need. Then estimate the usage of the node, and compare the total cost to you using On-Demand nodes versus reserved nodes. You can mix and match reserved and On-Demand node usage in your clusters. For pricing information, see [Amazon ElastiCache Pricing](https://aws.amazon.com/elasticache/pricing/).
AWS Region, node type and term length must be chosen at purchase, and cannot be changed later.
You can use the AWS Management Console, the AWS CLI, or the ElastiCache API to list and purchase available reserved node offerings.
For more information on reserved nodes, see [Amazon ElastiCache Reserved Nodes](https://aws.amazon.com/elasticache/reserved-cache-nodes/).
## Standard reserved node offerings
When you purchase a reserved node instance (RI) in Amazon ElastiCache, you can purchase a commitment to getting a discounted rate on a specific node instance type and AWS Region for the duration of the reserved node instance. To use an Amazon ElastiCache reserved node instance, you create a new ElastiCache node instance, just as you would for an on-demand instance.
If the specifications of the new reserve node instance match an existing reserved node instance for your account, you are billed at the discounted rate offered for the reserved node instance. Otherwise, the node instance is billed at an on-demand rate. These standard RIs are available from R5 and M5 instance families onwards.
**Note**
All offering types discussed next are available in one-year and three-year terms.
**Offering Types**
**No Upfront ** RI provides access to a reserved ElastiCache instance without requiring an upfront payment. Your *No Upfront* reserved ElastiCache instance bills a discounted hourly rate for every hour within the term, regardless of usage.
**Partial Upfront** RI requires a part of the reserved ElasticCache instance to be paid upfront. The remaining hours in the term are billed at a discounted hourly rate, regardless of usage. This option is the replacement for the legacy *Heavy Utilization* option, which is explained in the next section.
**All Upfront** RI requires full payment to be made at the start of the RI term. You incur no other costs for the remainder of the term, regardless of the number of hours used.
## Size flexible reserved nodes
All reserved nodes are size flexible. When you purchase a reserved node, one thing that you specify is the node type, for example cache.r6g.xlarge. For more information, about node types, see [Amazon ElastiCache Pricing](https://aws.amazon.com/elasticache/pricing/ ).
If you have a node, and you need to scale it to larger capacity, your reserved node is automatically applied to your scaled node. That is, your reserved nodes are automatically applied to usage of any size in the same node family. Size-flexible reserved nodes are available for nodes with the same AWS Region. Size-flexible reserved nodes can only scale in their node families. For example, a reserved node for a cache.r6g.xlarge can apply to a cache.r6g.2xlarge, but not to a cache.r6gd.large, because cache.r6g and cache.r6gd are different node families.
Size flexibility means that you can move freely between configurations within the same node family. For example, you can move from a r6g.xlarge reserved node (8 normalized units) to two r6g.large reserved nodes (8 normalized units) (2\$14 = 8 normalized units) in the same AWS Region at no extra cost.
### Upgrading nodes from Redis OSS to Valkey
With the launch of Valkey in ElastiCache, you can now apply your Redis OSS reserved node discount to the Valkey cache engine. You can upgrade from Redis OSS to Valkey while still benefitting from existing contracts and reservations. In addition to being able to apply your benefits within the cache node family and engine, you can even receive more incremental value. Valkey is priced at a 20% discount relative to Redis OSS, and with reserved node flexibility, you can use your Redis OSS reserved nodes to cover 20% more running Valkey nodes.
To calculate the discounted rate, each ElastiCache node and engine combination has a normalization factor that’s measured in units. Reserved node units can be applied to any running node within the reserved node’s instance family for a given engine. Redis OSS reserved nodes can additionally apply across engines to cover running Valkey nodes. Because Valkey is priced at a discount relative to Redis OSS and Memcached, its units for a given instance type are lower, which allows a Redis OSS reserved node to cover more Valkey nodes.
As an example, let’s say you have purchased a reserved node for a cache.r7g.4xlarge for the Redis OSS engine (32 units) and are running one cache.r7g.4xlarge Redis OSS node (32 units). If you upgrade the node to Valkey, the normalization factor of the running node drops to 25.6 units, and your existing reserved node provides you with an additional 6.4 units to use against any other running Valkey or Redis OSS node within the cache.r7g family in the Region. You could use this to cover 25% of another cache.r7g.4xlarge Valkey node in the account (25.6 units), or 100% of a cache.r7g.xlarge Valkey node (6.4 units).
### Comparing usage with normalized units
You can compare usage for different reserved node sizes by using normalized units. For example, one hour of usage on two cache.r6g.4xlarge nodes is equivalent to 16 hours of usage on one cache.r6g.large. The following table shows the number of normalized units for each node size:
****
| Node size | Normalized units with Redis OSS or Memcached | Normalized units with Valkey |
| --- | --- | --- |
| micro | 0.5 | 0.4 |
| small | 1 | .8 |
| medium | 2 | 1.6 |
| large | 4 | 3.2 |
| xlarge | 8 | 6.4 |
| 2xlarge | 16 | 12.8 |
| 4xlarge | 32 | 25.6 |
| 6xlarge | 48 | 38.4 |
| 8xlarge | 64 | 51.2 |
| 10xlarge | 80 | 64 |
| 12xlarge | 96 | 76.8 |
| 16xlarge | 128 | 102.4 |
| 24xlarge | 192 | 153.6 |
For example, you purchase a cache.r6gd.xlarge reserved node, and you have two running cache.r6gd.large reserved nodes in your account in the same AWS Region. In this case, the billing benefit is applied in full to both nodes.
![\[Region containing a cache.r6gd.xlarge reserved node with two cache.r6gd.large nodes inside.\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/images/ri1.png)
Alternatively, if you have one cache.r6gd.2xlarge instance running in your account in the same AWS Region, the billing benefit is applied to 50 percent of the usage of the reserved node.
![\[Diagram showing a cache.r6gd.xlarge reserved node region containing a cache.r6gd.2xlarge instance.\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/images/ri2.png)
## Deleting a reserved node
The terms for a reserved node involve a one-year or three-year commitment. You can't cancel a reserved node. However, you can delete a node that is covered by a reserved node discount. The process for deleting a node that is covered by a reserved node discount is the same as for any other node.
If you delete a node that is covered by a reserved node discount, you can launch another node with compatible specifications. In this case, you continue to get the discounted rate during the reservation term (one or three years).
## Legacy reserved node offerings
There are three levels of legacy node reservations—Heavy Utilization, Medium Utilization, and Light Utilization. Nodes can be reserved at any utilization level for either one or three years. The node type, utilization level, and reservation term affect your total costs. Verify the savings that reserved nodes can provide your business by comparing various models before you purchase reserved nodes.
Nodes purchased at one utilization level or term cannot be converted to a different utilization level or term.
**Utilization Levels**
*Heavy Utilization reserved nodes* enable workloads that have a consistent baseline of capacity or run steady-state workloads. Heavy Utilization reserved nodes require a high up-front commitment, but if you plan to run more than 79 percent of the reserved node term you can earn the largest savings (up to 70 percent off of the On-Demand price). With Heavy Utilization reserved nodes, you pay a one-time fee. This is then followed by a lower hourly fee for the duration of the term regardless of whether your node is running.
*Medium Utilization reserved nodes* are the best option if you plan to use your reserved nodes a large amount of the time and you want either a lower one-time fee or to stop paying for your node when you shut it off. Medium Utilization reserved nodes are a more cost-effective option when you plan to run more than 40 percent of the reserved nodes term. This option can save you up to 64 percent off of the On-Demand price. With Medium Utilization reserved nodes, you pay a slightly higher one-time fee than with Light Utilization reserved nodes, and you receive lower hourly usage rates when you run a node.
*Light Utilization reserved nodes* are ideal for periodic workloads that run only a couple of hours a day or a few days per week. Using Light Utilization reserved nodes, you pay a one-time fee followed by a discounted hourly usage fee when your node is running. You can start saving when your node is running more than 17 percent of the reserved node term. You can save up to 56 percent off of the On-Demand rates over the entire term of your reserved node.
**Legacy reserved node offerings**
| Offering | Up-front cost | Usage fee | Advantage |
| --- | --- | --- | --- |
| Heavy Utilization | Highest | Lowest hourly fee. Applied to the whole term whether or not you're using the reserved node. | Lowest overall cost if you plan to run your reserved nodes more than 79 percent of a three-year term. |
| Medium Utilization | Medium | Hourly usage fee charged for each hour the node is running. No hourly charge when the node is not running. | Suitable for elastic workloads or when you expect moderate usage, more than 40 percent of a three-year term. |
| Light Utilization | Lowest | Hourly usage fee charged for each hour the node is running. No hourly charge when the node is not running. Highest hourly fees of all the offering types, but fees apply only when the reserved node is running. | Highest overall cost if you plan to run all of the time. However, this is the lowest overall cost if you plan to use your reserved node infrequently, more than about 15 percent of a three-year term. |
| On-Demand Use (No reserved nodes) | None | Highest hourly fee. Applied whenever the node is running. | Highest hourly cost. |
For more information, see [Amazon ElastiCache Pricing](https://aws.amazon.com/elasticache/pricing/).
## Getting info about reserved node offerings
Before you purchase reserved nodes, you can get information about available reserved node offerings.
The following examples show how to get pricing and information about available reserved node offerings using the AWS Management Console, AWS CLI, and ElastiCache API.
**Topics**
+ [Using the AWS Management Console](#reserved-nodes-offerings-console)
+ [Using the AWS CLI](#reserved-nodes-offerings-cli)
+ [Using the ElastiCache API](#reserved-nodes-offerings-api)
### Getting info about reserved node offerings (Console)
To get pricing and other information about available reserved cluster offerings using the AWS Management Console, use the following procedure.
**To get information about available reserved node offerings**
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. In the navigation pane, choose **Reserved Nodes**.
1. Choose **Purchase Reserved Node**.
1. For **Engine**, choose either Valkey, Memcached, or Redis OSS.
1. To determine the available offerings, make selections for the following options:
+ **Node Type**
+ **Term**
+ **Offering Type**
After you make these selections, the cost per node and total cost of your selections is shown under **Reservation details**.
1. Choose **Cancel** to avoid purchasing these nodes and incurring charges.
### Getting info about reserved node offerings (AWS CLI)
To get pricing and other information about available reserved node offerings for Valkey or Redis OSS, type the following command at a command prompt:
```
1. aws elasticache describe-reserved-cache-nodes-offerings
```
This operation produces output similar to the following (JSON format):
```
{
"ReservedCacheNodesOfferingId": "0xxxxxxxx-xxeb-44ex-xx3c-xxxxxxxx072",
"CacheNodeType": "cache.xxx.large",
"Duration": 94608000,
"FixedPrice": XXXX.X,
"UsagePrice": X.X,
"ProductDescription": "redis",
"OfferingType": "All Upfront",
"RecurringCharges": [
{
"RecurringChargeAmount": X.X,
"RecurringChargeFrequency": "Hourly"
}
]
},
{
"ReservedCacheNodesOfferingId": "0xxxxxxxx-xxeb-44ex-xx3c-xxxxxxxx072",
"CacheNodeType": "cache.xxx.xlarge",
"Duration": 94608000,
"FixedPrice": XXXX.X,
"UsagePrice": X.X,
"ProductDescription": "redis",
"OfferingType": "Partial Upfront",
"RecurringCharges": [
{
"RecurringChargeAmount": X.XXX,
"RecurringChargeFrequency": "Hourly"
}
]
},
{
"ReservedCacheNodesOfferingId": "0xxxxxxxx-xxeb-44ex-xx3c-xxxxxxxx072",
"CacheNodeType": "cache.xxx.large",
"Duration": 31536000,
"FixedPrice": X.X,
"UsagePrice": X.X,
"ProductDescription": "redis",
"OfferingType": "No Upfront",
"RecurringCharges": [
{
"RecurringChargeAmount": X.XXX,
"RecurringChargeFrequency": "Hourly"
}
]
}
```
To get pricing and other information about available reserved node offerings for Memcached, type the following command at a command prompt:
```
{
"ReservedCacheNodesOfferingId": "0xxxxxxxx-xxeb-44ex-xx3c-xxxxxxxx072",
"CacheNodeType": "cache.xxx.large",
"Duration": 94608000,
"FixedPrice": XXXX.X,
"UsagePrice": X.X,
"ProductDescription": "memcached",
"OfferingType": "All Upfront",
"RecurringCharges": [
{
"RecurringChargeAmount": X.X,
"RecurringChargeFrequency": "Hourly"
}
]
},
{
"ReservedCacheNodesOfferingId": "0xxxxxxxx-xxeb-44ex-xx3c-xxxxxxxx072",
"CacheNodeType": "cache.xxx.xlarge",
"Duration": 94608000,
"FixedPrice": XXXX.X,
"UsagePrice": X.X,
"ProductDescription": "memcached",
"OfferingType": "Partial Upfront",
"RecurringCharges": [
{
"RecurringChargeAmount": X.XXXX,
"RecurringChargeFrequency": "Hourly"
}
]
},
{
"ReservedCacheNodesOfferingId": "0xxxxxxxx-xxeb-44ex-xx3c-xxxxxxxx072",
"CacheNodeType": "cache.xx.12xlarge",
"Duration": 31536000,
"FixedPrice": X.X,
"UsagePrice": X.X,
"ProductDescription": "memcached",
"OfferingType": "No Upfront",
"RecurringCharges": [
{
"RecurringChargeAmount": X.XXXX,
"RecurringChargeFrequency": "Hourly"
}
]
}
```
For more information, see [describe-reserved-cache-nodes-offerings](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-reserved-cache-nodes-offerings.html) in the AWS CLI Reference.
### Getting info about reserved node offerings (ElastiCache API)
To get pricing and information about available reserved node offerings, call the `DescribeReservedCacheNodesOfferings` action.
**Example**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReservedCacheNodesOfferings
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
For more information, see [DescribeReservedCacheNodesOfferings](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReservedCacheNodesOfferings.html) in the ElastiCache API Reference.
## Purchasing a reserved node
The following examples show how to purchase a reserved node offering using the AWS Management Console, the AWS CLI, and the ElastiCache API.
**Important**
Following the examples in this section incurs charges on your AWS account that you can't reverse.
**Topics**
+ [Using the AWS Management Console](#reserved-nodes-purchasing-console)
+ [Using the AWS CLI](#reserved-nodes-purchasing-cli)
+ [Using the ElastiCache API](#reserved-nodes-purchasing-api)
### Purchasing a reserved node (Console)
This example shows purchasing a specific reserved node offering, *649fd0c8-cf6d-47a0-bfa6-060f8e75e95f*, with a reserved node ID of *myreservationID*.
The following procedure uses the AWS Management Console to purchase the reserved node offering by offering id.
**To purchase reserved nodes**
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. In the navigation list, choose the **Reserved Nodes** link.
1. Choose the **Purchase reserved nodes** button.
1. For **Engine**, choose Valkey, Memcached, or Redis OSS.
1. To determine the available offerings, make selections for the following options:
+ **Node Type**
+ **Term**
+ **Offering Type**
+ An optional **Reserved node ID**
After you make these selections, the cost per node and total cost of your selections is shown under **Reservation details**.
1. Choose **Purchase**.
### Purchasing a reserved node (AWS CLI)
The following example shows purchasing the specific reserved cluster offering, *649fd0c8-cf6d-47a0-bfa6-060f8e75e95f*, with a reserved node ID of *myreservationID*.
Type the following command at a command prompt:
For Linux, macOS, or Unix:
```
1. aws elasticache purchase-reserved-cache-nodes-offering \
2. --reserved-cache-nodes-offering-id 649fd0c8-cf6d-47a0-bfa6-060f8e75e95f \
3. --reserved-cache-node-id myreservationID
```
For Windows:
```
1. aws elasticache purchase-reserved-cache-nodes-offering ^
2. --reserved-cache-nodes-offering-id 649fd0c8-cf6d-47a0-bfa6-060f8e75e95f ^
3. --reserved-cache-node-id myreservationID
```
The command returns output similar to the following:
```
1. RESERVATION ReservationId Class Start Time Duration Fixed Price Usage Price Count State Description Offering Type
2. RESERVATION myreservationid cache.xx.small 2013-12-19T00:30:23.247Z 1y XXX.XX USD X.XXX USD 1 payment-pending memcached Medium Utilization
```
For more information, see [purchase-reserved-cache-nodes-offering](https://docs.aws.amazon.com/cli/latest/reference/elasticache/purchase-reserved-cache-nodes-offering.html) in the AWS CLI Reference.
### Purchasing a reserved node (ElastiCache API)
The following example shows purchasing the specific reserved node offering, *649fd0c8-cf6d-47a0-bfa6-060f8e75e95f*, with a reserved cluster ID of *myreservationID*.
Call the `PurchaseReservedCacheNodesOffering` operation with the following parameters:
+ `ReservedCacheNodesOfferingId` = `649fd0c8-cf6d-47a0-bfa6-060f8e75e95f`
+ `ReservedCacheNodeID` = `myreservationID`
+ `CacheNodeCount` = `1`
**Example**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=PurchaseReservedCacheNodesOffering
&ReservedCacheNodesOfferingId=649fd0c8-cf6d-47a0-bfa6-060f8e75e95f
&ReservedCacheNodeID=myreservationID
&CacheNodeCount=1
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
For more information, see [PurchaseReservedCacheNodesOffering](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_PurchaseReservedCacheNodesOffering.html) in the ElastiCache API Reference.
## Getting info about your reserved nodes
You can get information about the reserved nodes you've purchased using the AWS Management Console, the AWS CLI, and the ElastiCache API.
**Topics**
+ [Using the AWS Management Console](#reserved-nodes-describing-console)
+ [Using the AWS CLI](#reserved-nodes-describing-cli)
+ [Using the ElastiCache API](#reserved-nodes-describing-api)
### Getting info about your reserved nodes (Console)
The following procedure describes how to use the AWS Management Console to get information about the reserved nodes you purchased.
**To get information about your purchased reserved nodes**
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. In the navigation list, choose the **Reserved nodes** link.
The reserved nodes for your account appear in the Reserved nodes list. You can choose any of the reserved nodes in the list to see detailed information about the reserved node in the detail pane at the bottom of the console.
### Getting info about your reserved nodes (AWS CLI)
To get information about reserved nodes for your AWS account, type the following command at a command prompt:
```
aws elasticache describe-reserved-cache-nodes
```
This operation produces output similar to the following (JSON format):
```
{
"ReservedCacheNodeId": "myreservationid",
"ReservedCacheNodesOfferingId": "649fd0c8-cf6d-47a0-bfa6-060f8e75e95f",
"CacheNodeType": "cache.xx.small",
"DataTiering": "disabled",
"Duration": "31536000",
"ProductDescription": "memcached",
"OfferingType": "Medium Utilization",
"MaxRecords": 0
}
```
For more information, see [describe-reserved-cache-nodes](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-reserved-cache-nodes.html) in the AWS CLI Reference.
### Getting info about your reserved nodes (ElastiCache API)
To get information about reserved nodes for your AWS account, call the `DescribeReservedCacheNodes` operation.
**Example**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReservedCacheNodes
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
For more information, see [DescribeReservedCacheNodes](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReservedCacheNodes.html) in the ElastiCache API Reference.
# Migrating previous generation nodes
Previous generation nodes are node types that are being phased out. If you have no existing clusters using a previous generation node type, ElastiCache does not support the creation of new clusters with that node type.
Due to the limited amount of previous generation node types, we cannot guarantee a successful replacement when a node becomes unhealthy in your cluster(s). In such a scenario, your cluster availability may be negatively impacted.
We recommend that you migrate your cluster(s) to a new node type for better availability and performance. For a recommended node type to migrate to, see [Upgrade Paths](https://aws.amazon.com/ec2/previous-generation/). For a full list of supported node types and previous generation node types in ElastiCache, see [Supported node types](CacheNodes.SupportedTypes.md).
## Migrating nodes on a Valkey or Redis OSS cluster
The following procedure describes how to migrate your Valkey or Redis OSS cluster node type using the ElastiCache Console. During this process, your Valkey or Redis OSS cluster will continue to serve requests with minimal downtime. Depending on your cluster configuration you may see the following downtimes. The following are estimates and may differ based on your specific configurations:
+ Cluster mode disabled (single node) may see approximately 60 seconds, primarily due to DNS propagation.
+ Cluster mode disabled (with replica node) may see approximately 1 second for clusters running Valkey 7.2 and above or Redis OSS 5.0.6 and above. All lower versions can experience approximately 10 seconds.
+ Cluster mode enabled may see approximately 1 second.
**To modify a Valkey or Redis OSS cluster node type using the console:**
1. Sign in to the Console and open the ElastiCache console at [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/home).
1. From the navigation pane, choose **Valkey clusters** or **Redis OSS clusters**.
1. From the list of clusters, choose the cluster you want to migrate.
1. Choose **Actions** and then choose **Modify**.
1. Choose the new node type from the node type list.
1. If you want to perform the migration process right away, choose **Apply immediately**. If **Apply immediately** is not chosen, the migration process is performed during the 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.
*To modify a Valkey or Redis OSS cluster node type using the AWS CLI:*
Use the [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) API as shown following:
For Linux, macOS, or Unix:
```
aws elasticache modify-replication-group /
--replication-group-id my-replication-group /
--cache-node-type new-node-type /
--apply-immediately
```
For Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id my-replication-group ^
--cache-node-type new-node-type ^
--apply-immediately
```
In this scenario, the value of *new-node-type* is the node type you are migrating to. By passing the `--apply-immediately` parameter, the update will be applied immediately when the replication group transitions from **modifying** to **available** status. If **Apply immediately** is not chosen, the migration process is performed during the cluster's next maintenance window.
**Note**
If you are unable to modify the cluster with an `InvalidCacheClusterState` error, you need to remove a restore-failed node first.
### Fixing or removing restore-failed-node(s)
The following procedure describes how to fix or remove restore-failed node(s) from your Valkey or Redis OSS cluster. To learn more on how ElastiCache node(s) enter a restore-failed state, see [Viewing ElastiCache Node Status](Nodes.viewing.md). We recommend first removing any nodes in a restore-failed state, then migrating the remaining previous generation nodes in the ElastiCache cluster to a newer generation node type, and finally adding back the required number of nodes.
To remove restore-failed node (console):
1. Sign in to the Console and open the ElastiCache console at [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/home).
1. From the navigation pane, choose **Valkey clusters** or **Redis OSS clusters**.
1. From the list of clusters, choose the cluster you want to remove a node from.
1. From the list of shards, choose the shard you want to remove a node from. Skip this step if cluster mode is disabled for the cluster.
1. From the list of nodes, choose the node with a status of `restore-failed`.
1. Choose **Actions** and then choose **Delete node**.
Once you remove the restore-failed node(s) from your ElastiCache cluster, you can now migrate to a newer generation type. For more information, see above on [Migrating nodes on a Valkey or Redis OSS cluster](#CacheNodes.NodeMigration.Redis).
To add back nodes to your ElastiCache cluster, see [Adding nodes to an ElastiCache cluster](Clusters.AddNode.md).
## Migrating nodes on a Memcached cluster
To migrate ElastiCache for Memcached to a different node type, you must create a new cluster, which always starts out empty that your application can populate.
**To migrate your ElastiCache for Memcached cluster node type using the ElastiCache Console:**
+ 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).
+ 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)
+ Delete the old cluster. For more information, see [Deleting a cluster in ElastiCache](Clusters.Delete.md)