Amazon ElastiCache for Redis is a web service that makes it easy to deploy and run Redis protocol-compliant server nodes in the cloud. The service enables the management, monitoring and operation of a Redis node; creation, deletion and modification of the node can be carried out through the ElastiCache console, the command line interface or the web service APIs. Amazon ElastiCache for Redis supports Redis Master / Slave replication.
Q: Is Amazon ElastiCache for Redis protocol-compliant with open source Redis?
Yes, Amazon ElastiCache for Redis is protocol-compliant with open source Redis. Code, applications, drivers and tools a customer uses today with their existing standalone Redis data store will continue to work with ElastiCache for Redis and no code changes will be required for existing Redis deployments migrating to ElastiCache for Redis unless noted. We currently support Redis 5.0.0, 4.0.10, 3.2.10, 3.2.6, 3.2.4, 2.8.24, 2.8.23, 2.8.22, 2.8.21, 2.8.19, 2.8.6, and 2.6.13.
Q: How much does Amazon ElastiCache for Redis cost?
Please see our pricing page for current pricing information.
Q: What are Amazon ElastiCache for Redis nodes, clusters, and replications groups?
An ElastiCache for Redis node is the smallest building block of an Amazon ElastiCache for Redis deployment. Each ElastiCache for Redis node supports the Redis protocol and has its own DNS name and port. Multiple types of ElastiCache for Redis nodes are supported, each with varying amount of CPU capability, and associated memory. An ElastiCache for Redis node may take on a primary or a read replica role. A primary node can be replicated to multiple read replica nodes. An ElastiCache for Redis cluster is a collection of one or more ElastiCache for Redis nodes of the same role; the primary node will be in the primary cluster and the read replica node will be in a read replica cluster. A cluster manages a logical key space, where each node is responsible for a part of the key space. Most of your management operations will be performed at the cluster level. An ElastiCache for Redis replication group encapsulates the primary and read replica clusters for a Redis installation. A replication group will have only one primary cluster and zero or many read replica clusters. All nodes within a replication group (and consequently cluster) will be of the same node type, and have the same parameter and security group settings.
Q: Does Amazon ElastiCache for Redis support Redis persistence?
Yes, you can achieve persistence by snapshotting your Redis data using the Backup and Restore feature. Please see here for details.
Q: How can I migrate from Amazon ElastiCache for Memcached to Amazon ElastiCache for Redis and vice versa?
We currently do not support automatically migrating from Memcached to Redis or vice versa. You may, however, use a Memcached client to read from a Memcached cluster and use a Redis client to write to a Redis cluster. Similarly, you may read from a Redis cluster using a Redis client and use a Memcached client to write to a Memcached cluster. Make sure to consider the differences in data format, and cluster configuration between the two engines.
Q: Does Amazon ElastiCache for Redis support Multi-AZ operation?
Yes, with Amazon ElastiCache for Redis you can create a read replica in another AWS Availability Zone. Upon a failure of the primary node, we will provision a new primary node. In scenarios where the primary node cannot be provisioned, you can decide which read replica to promote to be the new primary. For more details on how to handle node failures see here.
Q: What options does Amazon ElastiCache for Redis provide for node failures?
Amazon ElastiCache for Redis will repair the node by acquiring new service resources, and will then redirect the node's existing DNS name to point to the new service resources. Thus, the DNS name for a Redis node remains constant, but the IP address of a Redis node can change over time. If you have a replication group with one or more read replicas and Multi-AZ is enabled, then in case of primary node failure ElastiCache will automatically detect the failure, select a replica and promote it to become the new primary. It will also propagate the DNS so that you can continue to use the primary endpoint and after the promotion it will point to the newly promoted primary. For more details see the Multi-AZ section of this FAQ. When Redis replication option is selected with Multi-AZ disabled, in case of primary node failure you will be given the option to initiate a failover to a read replica node. The failover target can be in the same zone or another zone. To failback to the original zone, promote the read replica in the original zone to be the primary. You may choose to architect your application to force the Redis client library to reconnect to the repaired Redis server node. This can help as some Redis libraries will stop using a server indefinitely when they encounter communication errors or timeouts.
Q: How does failover work?
For Multi-AZ enabled replication groups, the failover behavior is described at the Multi-AZ section of this FAQ.
If you choose not to enable Multi-AZ, then if Amazon ElastiCache monitors the primary node, and in case the node becomes unavailable or unresponsive, Amazon ElastiCache for Redis will repair the node by acquiring new service resources, and will then redirect the node's existing DNS name to point to the new service resources. Thus, the DNS name for a Redis node remains constant, but the IP address of a Redis node can change over time. However, if the primary node cannot be healed (and your Multi-AZ is disabled) you will have the choice to promote one of the read replicas to be the new primary. See here for how to select a new primary. The DNS record of the primary’s endpoint will be updated to point to the promoted read replica node. A read replica node in the original primary’s AZ will then be created to be a read replica in the replication group and will follow the new primary.
Q: Are my read replicas available during a primary node failure?
Yes, during a primary node failure, the read replicas continue to service requests. After the primary node is restored, either as a healed node or as a promoted read replica, there is a brief period during which the read replicas will not serve any requests as they sync the cache information from the primary.
Q: How do I configure parameters of my Amazon ElastiCache for Redis nodes?
You can configure your Redis installation using a cache parameter group, which must be specified for a Redis cluster. All read replica clusters use the parameter group of their primary cluster. A Redis parameter group acts as a “container” for Redis configuration values that can be applied to one or more Redis primary clusters. If you create a Redis primary cluster without specifying a cache parameter group, a default parameter group is used. This default group contains defaults for the node type you plan to run. However, if you want your Redis primary cluster to run with specified configuration values, you can simply create a new cache parameter group, modify the desired parameters, and modify the primary Redis cluster to use the new parameter group.
Q: Can I access Redis through the Amazon ElastiCache console?
Yes, Redis appears as an Engine option in the ElastiCache console. You can create a new Redis cache cluster with the Launch Wizard by choosing the Redis engine. You can also modify or delete an existing Redis cluster using the ElastiCache console.
Q: Can Amazon ElastiCache for Redis clusters be created in an Amazon VPC?
Yes. If your account is a VPC by default account, your Redis clusters will be created within the default VPC associated with your account. Using the ElastiCache console, you can specify a different VPC when you create your cluster.
Q: Is Redis password functionality supported in Amazon ElastiCache for Redis?
Yes, Amazon ElastiCache for Redis supports Redis passwords via Redis AUTH feature. It is an opt-in feature available in ElastiCache for Redis version 3.2.6 onwards. You must enable encryption in-transit to use Redis AUTH on your ElastiCache for Redis cluster.
Q. How do I upgrade to a newer engine version?
You can easily upgrade to a newer engine version by using the ModifyCacheCluster or ModifyReplicationGroup APIs and specifying your preferred engine version for the EngineVersion parameter. On the ElastiCache console, you can select a cache cluster or replication group and click “Modify”. In the “Modify Cache Cluster” or “Modify Replication Group” window select your preferred engine version from the available options. The engine upgrade process is designed to make a best effort to retain your existing data and requires Redis replication to succeed. For more details on that see here.
Q. Can I downgrade to an earlier engine version?
No. Downgrading to an earlier engine version is not supported.
Q. How do I scale up to a larger node type?
You can easily scale up to a larger node type by using the ModifyCacheCluster or ModifyReplicationGroup APIs and specifying your preferred node type for the CacheNodeType parameter. On the ElastiCache console, you can select a cache cluster or replication group and click “Modify”. In the “Modify Cache Cluster” or “Modify Replication Group” window select your preferred node type from the available options. The scale up process is designed to make a best effort to retain your existing data and requires Redis replication to succeed. For more details on that see here.
Q. Can I scale down to a smaller node type?
Moving to a smaller node type is currently not supported.
Q. What is the correct metric to use to measure Redis CPU utilization?
Amazon ElastiCache provides two metrics to measure CPU utilization for ElastiCache for Redis workloads – EngineCPUUtilization and CPUUtilization. The CPUUtilization metric measures the CPU utilization for the instance (node), and EngineCPUUtilization metric measures the utilization at the Redis process level. You need the EngineCPUUtilization metric in addition to the CPUUtilization metric as the main Redis process is single threaded and uses just one CPU of the multiple CPU cores available on an instance. Therefore, the CPUUtilization metric does not provide precise visibility into the CPU utilization rates at the Redis process level. We recommend that you use both the CPUUtilization and EngineCPUUtilization metrics together to get a detailed understanding of CPU Utilization for your Redis clusters. Both the metrics are available in all AWS regions, and you can access these metric using CloudWatch or via the AWS Management Console.
Q. Can I have cross-region replicas with Amazon ElastiCache for Redis?
Yes, you can create cross region replicas using the Global Datastore feature in Amazon ElastiCache for Redis. Global Datastore provides fully managed, fast, reliable and secure cross-region replication. It allows you to write to your ElastiCache for Redis cluster in one region and have the data available to be read from two other cross-region replica clusters, thereby enabling low-latency reads and disaster recovery across regions.
Read Replicas serve two purposes in Redis:
- Failure Handing
- Read Scaling
When you run a Cache Node with a Read Replica, the “primary” serves both writes and reads. The Read Replica acts as a “standby” which is “promoted” in failover scenarios. After failover, the standby becomes the primary and accepts your cache operations. Read Replicas also make it easy to elastically scale out beyond the capacity constraints of a single Cache Node for read-heavy cache workloads.
Q: When would I want to consider using a Redis read replica?
There are a variety of scenarios where deploying one or more read replicas for a given primary node may make sense. Common reasons for deploying a read replica include:
- Scaling beyond the compute or I/O capacity of a single primary node for read-heavy workloads. This excess read traffic can be directed to one or more read replicas.
- Serving read traffic while the primary is unavailable. If your primary node cannot take I/O requests (e.g. due to I/O suspension for backups or scheduled maintenance), you can direct read traffic to your read replicas. For this use case, keep in mind that the data on the read replica may be “stale” since the primary Instance is unavailable. The read replica can also be used to restart a failed primary warmed up.
- Data protection scenarios; in the unlikely event or primary node failure or that the Availability Zone in which your primary node resides becomes unavailable, you can promote a read replica in a different Availability Zone to become the new primary.
Q: How do I deploy a read replica node for a given primary cache node?
You can create a read replica in minutes using a CreateReplicationGroup API or a few clicks of the Amazon ElastiCache Management Console. When creating a replication group, you specify the MasterCacheClusterIdentifier. The MasterCacheClusterIdentifier is the cache cluster Identifier of the “primary” cache cluster from which you wish to replicate. You then create the read replica cluster within the replication group by calling the CreateCacheCluster API specifying the ReplicationGroupIdentifier and the CacheClusterIdentifier of the master cluster. As with a standard cache cluster, you can also specify the Availability Zone. When you initiate the creation of a read replica, Amazon ElastiCache takes a snapshot of your primary cache cluster and begins replication. As a result, you will experience a brief I/O suspension on your primary cache cluster as the snapshot occurs. The I/O suspension typically lasts on the order of one minute.
The read replicas are as easy to delete as they are to create; simply use the Amazon ElastiCache Management Console or call the DeleteCacheCluster API (specifying the CacheClusterIdentifier for the read replica you wish to delete).
Q: Can I create both a primary and read replicas at the same time?
Yes. You can create a new cache cluster along with read replicas in minutes using the CreateReplicationGroup API or using the “Launch Cache Cluster” wizard at the Amazon ElastiCache Management Console and selecting “Multi-AZ Replication”. When creating the replication group, specify an identifier for the replication group, the total number of desired clusters in the replication group, along with cache creation parameters such as cache node type, cache engine version, etc. You can also specify the Availability Zone for each cluster in the replication group.
Q: How do I connect to my read replica(s)?
You can connect to a read replica just as you would connect to a primary cache node, using the DescribeCacheClusters API or AWS Management Console to retrieve the endpoint(s) for you read replica(s). If you have multiple read replicas, it is up to your application to determine how read traffic will be distributed amongst them. Here are more details:
- Redis (cluster mode disabled) clusters, use the individual Node Endpoints for read operations (In the API/CLI these are referred to as Read Endpoints).
- Redis (cluster mode enabled) clusters, use the cluster's Configuration Endpoint for all operations. You must use a client that supports Redis Cluster (Redis 3.2). You can still read from individual node endpoints (In the API/CLI these are referred to as Read Endpoints).
Q: How many read replicas can I create for a given primary cache node?
At this time, Amazon ElastiCache allows you to create up to five (5) read replicas for a given primary cache node.
Q: What happens to read replicas if failover occurs?
In the event of a failover, any associated and available read replicas should automatically resume replication once failover has completed (acquiring updates from the newly promoted read replica).
Q: Can I create a read replica of another read replica?
Creating a read replica of another read replica is not supported.
Q: Can I promote my read replica into a “standalone” primary cache node?
No, this is not supported. Instead, you may snapshot your ElastiCache for Redis node (you may select the primary or any of the read-replicas). You can then use the snapshot to seed a new ElastiCache for Redis primary.
Q: Will my read replica be kept up-to-date with its primary cache node?
Updates to a primary cache node will automatically be replicated to any associated read replicas. However, with Redis’s asynchronous replication technology, a read replica can fall behind its primary cache node for a variety of reasons. Typical reasons include:
- Write I/O volume to the primary cache node exceeds the rate at which changes can be applied to the read replica
- Network partitions or latency between the primary cache node and a read replica
Read replicas are subject to the strengths and weaknesses of Redis replication. If you are using read replicas, you should be aware of the potential for lag between a read replica and its primary cache node, or “inconsistency”. Click here for guidance on how to find out the “inconsistency” of your read replica.
Q: How do I gain visibility into active read replica(s)?
You can use the standard DescribeCacheClusters API to return a list of all the cache clusters you have deployed (including read replicas), or simply click on the "Cache Clusters" tab of the Amazon ElastiCache Management Console.
Amazon ElastiCache monitors the replication status of your read replicas and updates the Replication State field to Error if replication stops for any reason. You can review the details of the associated error thrown by the Redis engine by viewing the Replication Error field and take an appropriate action to recover from it. You can learn more about troubleshooting replication issues in the Troubleshooting a Read Replica problem section of the Amazon ElastiCache User Guide. If a replication error is fixed, the Replication State changes to Replicating.
Amazon ElastiCache allows you to gain visibility into how far a read replica has fallen behind its primary through the Amazon CloudWatch metric ("Replica Lag") available via the AWS Management Console or Amazon CloudWatch APIs.
Q: My read replica has fallen significantly behind its primary cache node. What should I do?
As discussed in the previous questions, “inconsistency” or lag between a read replica and its primary cache node is common with Redis asynchronous replication. If an existing read replica has fallen too far behind to meet your requirements, you can reboot it. Keep in mind that replica lag may naturally grow and shrink over time, depending on your primary cache node’s steady-state usage pattern.
Q: How do I delete a read replica? Will it be deleted automatically if its primary cache node is deleted?
You can easily delete a read replica with a few clicks of the AWS Management Console or by using DeleteCacheCluster, or DecreaseReplicaCount APIs. If you want to delete the read replica in addition to the primary cache node, you must use the DeleteReplicationGroup API or AWS Management Console.
Q: How much do read replicas cost? When does billing begin and end?
A read replica is billed as a standard cache node and at the same rates. Just like a standard cache node, the rate per “Cache Node hour” for a read replica is determined by the cache node class of the read replica – please see Amazon ElastiCache detail page for up-to-date pricing. You are not charged for the data transfer incurred in replicating data between your primary cache node and read replica. Billing for a read replica begins as soon as the read replica has been successfully created (i.e. when status is listed as “active”). The read replica will continue being billed at standard Amazon ElastiCache cache node hour rates until you issue a command to delete it.
Q: What happens during failover and how long does it take?
Initiated failover is supported by Amazon ElastiCache so that you can resume cache operations as quickly as possible. When failing over, Amazon ElastiCache simply flips the DNS record for your cache node to point at the read replica, which is in turn promoted to become the new primary. We encourage you to follow best practices and implement cache node connection retry at the application layer. Start-to-finish, failover typically completes within sixty seconds.
Q: Can I create a read replica in another region as my primary?
No. Your read replica may only be provisioned in the same or different Availability Zone of the same Region as your cache node primary.
Q: Can I see which Availability Zone my primary is currently located in?
Yes, you can gain visibility into the location of the current primary by using the AWS Management Console or DescribeCacheClusters API.
After failover, my primary is now located in a different Availability Zone than my other AWS resources (e.g. EC2 instances).
Q: Should I be concerned about latency?
Availability Zones are engineered to provide low latency network connectivity to other Availability Zones in the same Region. In addition, you may want to consider architecting your application and other AWS resources with redundancy across multiple Availability Zones so your application will be resilient in the event of an Availability Zone failure.
Q: Can I add and remove read replica nodes for my Redis Cluster environment?
Yes. You can add a remove replica across one or more shards in a Redis Cluster environment. The cluster continues to stay online and serve incoming I/O during this operation.
An ElastiCache for Redis replication group consists of a primary and up to five read replicas. Redis asynchronously replicates the data from the primary to the read replicas. During certain types of planned maintenance, or in the unlikely event of ElastiCache node failure or Availability Zone failure, Amazon ElastiCache will automatically detect the failure of a primary, select a read replica, and promote it to become the new primary. ElastiCache also propagates the DNS changes of the promoted read replica, so if your application is writing to the primary node endpoint, no endpoint change will be needed.
Q: What are the benefits of using Multi-AZ?
The main benefits of running your ElastiCache for Redis in Multi-AZ mode are enhanced availability and smaller need for administration. If an ElastiCache for Redis primary node failure occurs, the impact on your ability to read/write to the primary is limited to the time it takes for automatic failover to complete. When Multi-AZ is enabled, ElastiCache node failover is automatic and requires no administration. You no longer need to monitor your Redis nodes and manually initiate a recovery in the event of a primary node disruption.
Q: How does Multi-AZ work?
You can use Multi-AZ if you are using ElastiCache for Redis and have a replication group consisting of a primary node and one or more read replicas. If the primary node fails, ElastiCache will automatically detect the failure, select one from the available read replicas, and promote it to become the new primary. ElastiCache will propagate the DNS changes of the promoted replica so that your application can keep writing to the primary endpoint. ElastiCache will also spin up a new node to replace the promoted read replica in the same Availability Zone of the failed primary. In case the primary failed due to temporary Availability Zone disruption, the new replica will be launched once that Availability Zone has recovered.
Q: Can I have replicas in the same Availability Zone as the primary?
Yes. Note that placing both the primary and the replica(s) in the same Availability Zone will not make your ElastiCache for Redis replication group resilient to an Availability Zone disruption.
Q: What events would cause Amazon ElastiCache to fail over to a read replica?
Amazon ElastiCache will failover to a read replica in the event of any of the following:
- Loss of availability in primary’s Availability Zone
- Loss of network connectivity to primary
- Compute unit failure on primary
Q: When should I use Multi-AZ?
Using Redis replication in conjunction with Multi-AZ provides increased availability and fault tolerance. Such deployments are a natural fit for use in production environments.
Q: How do I create an ElastiCache for Redis replication group with Multi-AZ enabled?
You can create an ElastiCache for Redis primary and read replicas by clicking Launch Cache Cluster on the ElastiCache Management Console. You can also do so by calling the CreateReplicationGroup API. For existing replication groups (Redis 2.8.24, 2.8.23, 2.8.22, 2.8.21, 2.8.19, and 2.8.6), you can enable Multi-AZ by choosing a replication group and clicking Modify on the ElastiCache Management Console or by using the ModifyReplicationGroup API. Switching a replication group to Multi-AZ is not disruptive to your Redis data and does not interfere your nodes' ability to serve requests.
Q: Which read replica will be promoted in case of primary node failure?
If there are more than one read replicas, the read replica with the smallest asynchronous replication lag to the primary will be promoted.
Q: How much does it cost to use Multi-AZ?
Multi-AZ is free of charge. You only pay for the ElastiCache nodes that you use.
Q: What are the performance implications of Multi-AZ?
ElastiCache currently uses the Redis engine’s native, asynchronous replication and is subject to its strengths and limitations. In particular, when a read replica connects to a primary for the first time, or if the primary changes, the read replica does a full synchronization of the data from the primary, imposing load on itself and the primary. For additional details regarding Redis replication please see here.
Q: What cache node types support Multi-AZ?
All available cache node types in ElastiCache support Multi-AZ except T1 node family.
Q: Will I be alerted when automatic failover occurs?
Yes, Amazon ElastiCache will create an event to inform you that automatic failover occurred. You can use the DescribeEvents API to return information about events related to your ElastiCache node, or click the Events section of the ElastiCache Management Console.
Q: After failover, my primary is now located in a different Availability Zone than my other AWS resources (for example, EC2 instances). Should I be concerned about latency?
Availability Zones are engineered to provide low latency network connectivity to other Availability Zones in the same region. You may consider architecting your application and other AWS resources with redundancy across multiple Availability Zones so your application will be resilient in the event of an Availability Zone disruption.
Q: Where can I get more information about Multi-AZ?
For more information about Multi-AZ, see ElastiCache documentation.
Backup and Restore is a feature that allows customers to create snapshots of their ElastiCache for Redis clusters. ElastiCache stores the snapshots, allowing users to subsequently use them to restore Redis clusters.
Q: What is a snapshot?
A snapshot is a copy of your entire Redis cluster at a specific moment.
Q: Why would I need snapshots?
Creating snapshots can be useful in case of data loss caused by node failure, as well as the unlikely event of a hardware failure. Another common reason to use backups is for archiving purposes. Snapshots are stored in Amazon S3, which is a durable storage, meaning that even a power failure won’t erase your data.
Q: What can I do with a snapshot?
You can use snapshots to warm start an ElastiCache for Redis cluster with preloaded data.
Q: How does Backup and Restore work?
When a backup is initiated, ElastiCache will take a snapshot of a specified Redis cluster that can later be used for recovery or archiving. You can initiate a backup anytime you choose or set a recurring daily backup with retention period of up to 35 days.
When you choose a snapshot to restore, a new ElastiCache for Redis cluster will be created and populated with the snapshot’s data. This way you can create multiple ElastiCache for Redis clusters from a specified snapshot.
Currently, ElastiCache uses Redis’ native mechanism to create and store an RDB file as the snapshot.
Q: Where are my snapshots stored?
The snapshots are stored in S3.
Q: How can I get started using Backup and Restore?
You can select to use the Backup and Restore feature through the AWS Management Console, through the ElastiCache APIs (CreateCacheCluster, ModifyCacheCluster and ModifyReplicationGroup API’s) and CLI. You can deactivate and reactivate the feature anytime you choose.
Q: How do I specify which Redis cluster and node to backup?
Backup and Restore creates snapshots on a cluster basis. Users can specify which ElastiCache for Redis cluster to backup through the AWS Management Console, CLI or through the CreateSnapshot API. In a Replication Group, you can choose to backup the primary or any of the read-replica clusters. We recommend users enable backup on one of the read-replicas, mitigating any latency effect on the Redis primary.
Q: How can I specify when a backup will take place?
Through the AWS Management Console, CLI or APIs you can specify when to start a single backup or a recurring backup. Users are able to:
- Take a snapshot right now (through “Create Snapshot” console button or CreateSnapshot API)
- Set up an automatic daily backup. The backup will take place during your preferred backup window. You can set that up through Creating/Modifying cluster via console or the CreateCacheCluster, ModifyCacheCluster or ModifyReplicationGroup API’s.
Q: What is a backup window and why do I need it?
The preferred backup window is the user-defined period of time during which your ElastiCache for Redis cluster backup will start. This is helpful if you want to backup at a certain time of day or to refrain from backups during a particularly high-utilization period.
Q: What is the performance impact of taking a snapshot?
While taking a snapshot, you may encounter increased latencies for a brief period at the node. Snapshots use Redis’s built-in BGSAVE and are subject to its strengths and limitations. In particular, the Redis process forks and the parent continues to serve requests while the child saves the data on disk and then exits. The forking increases the memory usage for the duration of the snapshot generation. When this memory usage exceeds that of the available memory of the cache node, swapping can get triggered, further slowing down the node. For this reason, we recommend generating snapshots on one of the read replicas (instead of the primary). Also, we suggest setting the reserved-memory parameter to minimize swap usage. See here for more details.
Q: Can I create a snapshot from an ElastiCache for Redis read replica?
Yes. Creating a snapshot from a read replica is the best way to backup your data while minimizing performance impact.
Q: In what regions is the Backup and Restore feature available?
Backup and Restore feature is available in all regions where ElastiCache service is available.
Q: Can I export ElastiCache for Redis snapshots to an S3 bucket owned by me?
Yes. You can export your ElastiCache for Redis snapshots to an authorized S3 bucket in the same region as your cluster. For more details on exporting snapshots and setting the required permissions, please refer to this.
Q: Can I copy snapshots from one region to another?
Yes. You must first copy your snapshot into an authorized S3 bucket of your choice in the same region and then use the S3 PUT object- Copy API to copy it to a bucket in another region. For more details on copying S3 objects, please see this.
Q: I have multiple AWS accounts using ElastiCache for Redis. Can I use ElastiCache snapshots from one account to warm start an ElastiCache for Redis cluster in a different one?
Yes. You must first copy your snapshot into an authorized S3 bucket of your choice in the same region and then grant cross-account bucket permissions to the other account. For more details on S3 cross-account permissions, please see this. Finally, specify the S3 location of your RDB file during cluster creation through the Launch Cache Cluster Wizard in the console or through the CreateCacheCluster API.
Q: How much does it cost to use Backup and Restore?
Amazon ElastiCache provides storage space for one snapshot free of charge for each active ElastiCache for Redis cluster. Additional storage will be charged based on the space used by the snapshots with $0.085/GB every month (same price in all regions). Data transfer for using the snapshots is free of charge.
Q: What is the retention period?
Retention period is the time span during which the automatic snapshots are retained. For example, if a retention period is set for 5, a snapshot that was taken today will be retained for 5 days before being deleted. You can choose to copy one or more automatic snapshots to store them as manual so that they won’t be deleted after the retention period is over.
Q: How do I manage the retention of my automated snapshots?
You can use the AWS Management Console or ModifyCluster API to manage the period of time your automated backups are retained by modifying the RetentionPeriod parameter. If you desire to turn off automated backups altogether, you can do so by setting the retention period to 0 (not recommended).
Q: What happens to my snapshots if I delete my ElastiCache for Redis cluster?
When you delete an ElastiCache for Redis cluster, your manual snapshots are retained. You will also have an option to create a final snapshot before the cluster is deleted. Automatic cache snapshots are not retained.
Q: What cache nodes types support backup and restore capability?
All ElastiCache for Redis instance node types besides t1.micro support backup and restore:
Current Generation Cache Nodes:
Q: Can I use my own RDB snapshots stored in S3 to warm start an ElastiCache for Redis cluster?
Yes. You can specify the S3 location of your RDB file during cluster creation through the Launch Cache Cluster Wizard in the console or through the CreateCacheCluster API.
Q: Can I use the Backup and Restore feature if I am running ElastiCache in a VPC?
Q: What is Online Cluster Resizing?
Amazon ElastiCache for Redis provides the ability to add and remove shards from a running cluster. You can dynamically scale-out or scale-in your Redis cluster workloads to adapt to changes in demand. ElastiCache will resize the cluster by adding or removing shards and redistributing hash slots uniformly across the new shard configuration, all while the cluster continues to stay online and serve requests.
Q: What are the benefits of using Online Cluster Resizing?
The ability to dynamically scale-out and scale-in a cluster can help you manage application variability and meet oscillating demands. You can right-size your clusters by adding or removing shards to scale performance and in-memory capacity. The feature eliminates the need
Q: How can I use Online Cluster Resizing?
Online Cluster Resizing is available with Redis engine version 3.2.10 and above. To
Q: How long does the Online Cluster Resizing take?
The time taken to resize a cluster depends on multiple factors, such as
Q: Can the cluster be used while cluster resizing is in progress?
Yes, the cluster continues to stay online and serve incoming requests, while
Q: Is there any performance impact of this operation on the cluster?
While Online Cluster Resizing provides the benefits to scale out/in with zero downtime, it is a compute-intensive operation and can increase the latency of your client connection. To reduce the load on the cluster during the operation, we recommend that you follow the best practices (described in the documentation).
Q: How can I track the progress of an online
You can track the progress of the operation by watching the status of the cluster,
Q: What is the rebalance operation for ElastiCache for Redis cluster?
The rebalance operation can be used to redistribute slots amongst existing shards to achieve a uniform distribution. This is useful when a cluster is created with manually specified uneven slot distribution or a scale-out/in operation leaves the cluster with uneven distribution. Assuming the slots are identical in their memory and I/O requirements, uniform slot distribution by count is an easy way to load balance across shards.
Q: How does tagging work when a cluster scales-out?
When new nodes are added to scale-out a cluster, the nodes carry the same set of tags that are common across all existing nodes. Additionally, users can modify tags on all nodes and continue to use tagging as before.
Q: Are there any client or application side changes needed to use online cluster resizing?
No. The enhanced slot distribution used in cluster resizing workflow is compliant with Redis cluster client behavior and does not require any application changes. ElastiCache retains cluster endpoints, enabling you to continue using existing clients without any changes.
Q: How much does it cost to use the enhanced Redis engine?
There is no additional charge for using the enhanced Redis engine. As always, you will only be charged for the nodes you use.
Q: What does encryption in-transit for ElastiCache for Redis provide?
The encryption in-transit feature enables you to encrypt all communications between clients and Redis server as well as between the Redis servers (primary and read replica nodes).
Q: What does encryption at-rest for ElastiCache for Redis provide?
Encryption at-rest allows for encryption of data during backups and restore - data backed up and restored on disk and via Amazon S3 is encrypted.
Q: How can I use encryption in-transit, at-rest, and Redis AUTH?
Encryption in-transit, encryption at-rest, and Redis AUTH are all opt-in features. At the time of Redis cluster creation via the console or command line interface, you can specify if you want to enable encryption and Redis AUTH and can proceed to provide an authentication token for communication with the Redis cluster. Once the cluster is setup with encryption enabled, ElastiCache seamlessly manages certificate expiration and renewal without requiring any additional action from the application. Additionally, the Redis clients need to support TLS to avail of the encrypted in-transit traffic.
Q: Is there an Amazon ElastiCache for Redis client that I need to use when using encryption in-transit, or at-rest?
No. Encryption in-transit requires clients to support TLS. Most of the popular Redis clients (such as Lettuce, Predis, go-Redis) provide support for TLS with some configuration settings. You have to make sure that your Redis client of choice is configured to support TLS and continue to use ElastiCache for Redis as before.
Q: Can I enable encryption in-transit and encryption at-rest on my existing ElastiCache for Redis clusters?
No. Encryption in-transit and encryption at-rest support is only available for new clusters and is not supported on existing ElastiCache for Redis clusters. ElastiCache for Redis versions 5.0.0, 4.0.10, and 3.2.6 support these features.
Q: Is there any action needed to renew certificates?
No. ElastiCache manages certification expiration and renewal behind the scene. No user action is necessary for ongoing certificate maintenance.
Q: Can I use my certificates for encryption?
No. Currently, ElastiCache does not provide the ability for you to use your certificates. ElastiCache manages certificates transparently for you.
Q: Which instance types are supported for encryption in transit and encryption at rest?
All current generation instances are supported for encryption in transit and encryption at rest.
Q: Are there additional costs for using encryption?
There are no additional costs for using encryption.
Q: Which compliance programs does ElastiCache for Redis support?
ElastiCache for Redis supports compliance programs such as SOC 1, SOC 2, SOC 3, ISO, MTCS, C5, PCI, HIPAA, and FedRAMP. See AWS Services in Scope by Compliance Program for current list of supported complaince programs.
Q: Is Amazon ElastiCache for Redis PCI compliant?
Yes, the AWS PCI compliance program includes Amazon ElastiCache for Redis as a PCI compliant Service.
To learn more, see the following resources:
To see the current list of compliance programs that Amazon ElastiCache for Redis is in scope for, see AWS Services in Scope by Compliance Program.
Q: Is Amazon ElastiCache for Redis HIPAA eligible?
Yes, Amazon ElastiCache for Redis is a HIPAA Eligible Service and has been added to the AWS Business Associate Addendum (BAA). This means you can use ElastiCache for Redis to help you process, maintain, and store protected health information (PHI) and power healthcare applications.
Q: What do I have to do to use HIPAA eligible ElastiCache for Redis?
If you have an executed Business Associate Agreement (BAA) with AWS, you can use ElastiCache for Redis to build HIPAA-compliant applications. If you do not have a BAA or have other questions about using AWS for your HIPAA-compliant applications, contact us for more information. See Architecting for HIPAA Security and Compliance on Amazon Web Services for information about how to configure Amazon HIPAA Eligible Services to
Q: Is Amazon ElastiCache for Redis FedRAMP authorized?
The AWS FedRAMP compliance program includes Amazon ElastiCache for Redis as a FedRAMP authorized service. United States government customers and their partners can now use the latest version of ElastiCache for Redis to process and store their FedRAMP systems, data, and mission-critical, high-impact workloads in the AWS GovCloud (US) Region, and at moderate impact level in AWS US East/West Regions.
To learn more, see the following resources:
To see the current list of compliance programs that Amazon ElastiCache for Redis is in scope for, see AWS Services in Scope by Compliance Program.
Q: Does it cost extra to use compliance features?
No, there is no additional cost for using compliance features.
Q: What is Global Datastore for Redis?
Global Datastore is a feature of Amazon ElastiCache for Redis that provides fully managed, fast, reliable and secure cross-region replication. With Global Datastore, you can write to your ElastiCache for Redis cluster in one region, and have the data available for read in two other cross-region replica clusters, thereby enabling low-latency reads and disaster recovery across regions.
Designed for real-time applications with a global footprint, Global Datastore for Redis supports cross-region replication latency of typically under one second, increasing the responsiveness of your applications by providing geo-local reads closer to end users. In the unlikely event of regional degradation, one of the healthy cross-region replica clusters can be promoted to become the primary cluster with full read/write capabilities. Once initiated, the promotion typically completes in less than a minute, allowing your applications to remain available.
Q: How many AWS regions can I replicate to?
You can replicate to up to two secondary regions within a Global Datastore for Redis. The clusters in secondary regions can be used to serve low-latency local reads and for disaster recovery, in the unlikely event of a regional degradation.
Q: Which engine versions support Global Datastore for Redis?
Global Datastore is supported on Amazon ElastiCache for Redis 5.0.6 onward. Customers can upgrade engine version to 5.0.6 and use Global Datastore.
Q: How can I create Global Datastore for Redis?
You can setup a Global Datastore by using an existing cluster or creating a new cluster to be used as a primary. You can create a Global Datastore for Redis with just a few clicks on the Amazon ElastiCache Management Console or by downloading the latest AWS SDK or CLI. Global Datastore is not yet supported in AWS CloudFormation.
Q: Does ElastiCache automatically failover a Global Datastore for Redis to promote a secondary cluster in the event when primary cluster (region) is degraded?
No, ElastiCache doesn’t automatically promote a secondary cluster in the event when primary cluster (region) is degraded. You can manually initiate the failover by promoting a secondary cluster to become a primary. The failover and promotion of secondary cluster typically completes in less than one minute.
Q: How do I perform application failover for disaster recovery if my primary cluster experiences degradation of service?
In case your primary cluster in a Global Datastore for Redis experiences degradation of service, you can assign a secondary cluster as your new primary cluster, and then remove the old primary cluster from your Global Datastore. When a secondary cluster is promoted to primary, ElastiCache will reconfigure the old primary (if reachable) as secondary, and setup replication to synchronize all secondary regions with the new primary. If your entire application stack is replicated to another AWS region, you may failover the entire application stack (including your compute resources) to that AWS region. If the rest of your application stack does not require failover, make sure your application has access to the secondary cluster endpoint.
Q: How is my data secured when using Global Datastore for Redis?
Global Datastore for Redis uses encryption in-transit for cross-region traffic to keep your data secure. Additionally, you can also encrypt your primary and secondary clusters using encryption at-rest to keep your end-to-end data secured. Each primary and secondary cluster can have a separate customer managed customer master key (CMK) in AWS Key Management Service (KMS) for encryption at rest.
Q: What Recovery Point Objective (RPO) and Recovery Time Objective (RTO) can I expect with Global Datastore for Redis?
ElastiCache doesn’t provide an SLA for RPO and RTO. The RPO varies based on replication lag between regions, and depends on network latency between regions and cross-region network traffic congestion. The RPO of Global Datastore is typically under one second, so the data written in primary region is available in secondary regions within one second. The RTO of Global Datastore for Redis is typically under a minute. Once a failover to a secondary cluster is initiated, ElastiCache typically promotes the secondary to full read/write capabilities in under a minute.
Q: What is the pricing for Global Datastore for Redis?
Amazon ElastiCache does not charge any premium to use Global Datastore for Redis. You pay for the primary and secondary clusters in your Global Datastore, and the cross-region data transfer traffic.