Get Started with AWS for Free

Create a Free Account
Or Sign In to the Console

AWS Free Tier includes 750hrs of Micro Cache Node with Amazon ElastiCache.

View AWS Free Tier Details »


Q: What is Amazon ElastiCache for Redis?

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 2.6.13, 2.8.6, 2.8.19, 2.8.21, 2.8.22, 2.8.23, 2.8.24, 3.2.4, 3.2.6 and 3.2.10.

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. At this time a cluster can only have one node. In the future, we will increase this limit. 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?

No, Amazon ElastiCache for Redis does not support Redis passwords. This is because of the inherent limitations of passwords stored in a configuration file. Instead of relying on Redis passwords, ElastiCache for Redis clusters are associated with an EC2 security group, and only clients within this security group have access to the Redis server.

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 does it mean to run a Redis Cache Node as a Read Replica?

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.

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 passing its cache cluster identifier to the DeleteCacheCluster API. 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 three to six minutes.

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: What is Multi-AZ for an ElastiCache for Redis replication group?

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.6, 2.8.19, 2.8.21, 2.8.22, 2.8.23 and 2.8.24), 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 and T2 families.

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.


Q: What is Backup and Restore?

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 and t2 family support backup and restore:

Current Generation Cache Nodes:

  • cache.m3.medium
  • cache.m3.large
  • cache.m3.xlarge
  • cache.m3.2xlarge
  • cache.m4.large
  • cache.m4.xlarge
  • cache.m4.2xlarge
  • cache.m4.4xlarge
  • cache.m4.10xlarge
  • cache.r3.large
  • cache.r3.xlarge
  • cache.r3.2xlarge
  • cache.r3.4xlarge
  • cache.r3.8xlarge
  • cache.r4.large
  • cache.r4.xlarge
  • cache.r4.2xlarge
  • cache.r4.4xlarge
  • cache.r4.8xlarge
  • cache.r4.16xlarge

Previous Generation Cache Nodes:

  • cache.m1.small
  • cache.m1.medium
  • cache.m1.large
  • cache.m1.xlarge
  • cache.m2.xlarge
  • cache.m2.2xlarge
  • cache.m2.4xlarge
  • cache.c1.xlarge

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?

Yes.


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 to overprovision clusters based on peak demand, helps improve efficiency, and reduces cost.

Q: How can I use Online Cluster Resizing?

Online Cluster Resizing is available with Redis engine version 3.2.10. To reshard your cluster, select the cluster and specify whether you want to add or remove shards. When you resize the cluster to scale-out, ElastiCache adds shards and migrates slots from existing shards to new shards, in a way such that the slots are uniformly distributed (by count) across shards. Similarly, when resizing the cluster to scale-in, ElastiCache migrates slots to the remaining shards to uniformly distribute the slots and deletes specified shards.

Q: How long does the Online Cluster Resizing take?

The time taken to resize a cluster depends on multiple factors, such as number of slots that need to be migrated across shards, size of data and incoming request rate on the cluster. However, the workflow is optimized to parallelize slot migration, which improves the time taken as you add more shards to scale out the cluster.

Q: Can the cluster be used while cluster resizing is in progress?

Yes, the cluster continues to stay online and serve incoming requests, while resharding is in progress. However, snapshotting a cluster while resharding is not supported to prevent increased load on the cluster.

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 resharding operation?

You can track the progress of the operation by watching the status of the cluster, shards and nodes. During the operation, the cluster, shards and nodes will stay in “modifying” status. Similarly, when shards are being created, deleted or participating in slot migration, the individual shard status will reflect these statuses to show progress. Additionally, the status of end-to-end operation can also be tracked using the progress indicator for the resharding operation, which indicates percentage completed and provides insight into the remaining time for the operation. Lastly, event messages indicate the progress by describing actions being taken (shard creation, slot migration, etc.) during this operation.

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 version 3.2.6 is the initial version that supports 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: 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 store, process, and transmit PHI.

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 and HIPAA. See AWS Services in Scope by Compliance Program for current list of supported complaince programs.

Q: Does it cost extra to use compliance features?

No, there is no additional cost for using compliance features.