Amazon Elasticache FAQs Amazon Web Service Flashcards

Amazon ElastiCache is a web service that makes it easy to deploy and run Memcached or Redis protocol-compliant server nodes in the cloud. Amazon ElastiCache improves the performance of web applications by allowing you to retrieve information from a fast, managed, in-memory system, instead of relying entirely on slower disk-based databases. The service simplifies and offloads the management, monitoring and operation of in-memory environments, enabling your engineering resources to focus on developing applications. Using Amazon ElastiCache, you can not only improve load and response times to user actions and queries, but also reduce the cost associated with scaling web applications.

Q: What is Amazon ElastiCache?

The in-memory caching provided by Amazon ElastiCache can be used to significantly improve latency and throughput for many read-heavy application workloads (such as social networking, gaming, media sharing and Q&A portals) or compute-intensive workloads (such as a recommendation engine). In-memory caching improves application performance by storing critical pieces of data in memory for low-latency access. Cached information may include the results of I/O-intensive database queries or the results of computationally-intensive calculations.

Q: What is in-memory caching and how does it help my applications?

A: Yes. ElastiCache for Redis can be used as a primary in-memory key-value data store, providing fast, sub millisecond data performance, high availability and scalability up to 250 nodes and 250 shards, giving you up to 170.6 TB of in-memory data. See here for other use cases, such as leaderboards, rate limiting, queues, and chat.

Q: Can I use Amazon ElastiCache for use cases other than caching?

AWS CloudFormation simplifies provisioning and management by providing AWS CloudFormation templates for quick and reliable provisioning of the services or applications. AWS CloudFormation provides comprehensive support for Amazon ElastiCache by providing templates to create cluster (both MemCached and Redis) and Replication Groups. The templates are up to date with the latest ElastiCache Redis announcement for clustered Redis configuration and provide flexibility and ease of use to Amazon ElastiCache customers.

Q: Can I use Amazon ElastiCache through AWS CloudFormation?

Amazon ElastiCache manages the work involved in setting up a distributed in-memory environment, from provisioning the server resources you request to installing the software. Once your environment is up and running, the service automates common administrative tasks such as failure detection and recovery, and software patching. Amazon ElastiCache provides detailed monitoring metrics associated with your nodes, enabling you to diagnose and react to issues very quickly. For example, you can set up thresholds and receive alarms if one of your nodes is overloaded with requests.

Q: What does Amazon ElastiCache manage on my behalf?

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 an instance of the Memcached or Redis protocol-compliant service and has its own DNS name and port. Multiple types of nodes are supported, each with varying amount of associated memory. A Redis shard is a subset of the cluster’s keyspace, that can include a primary node and zero or more read-replicas. For more details on Redis deployments see the Redis section below. The shards add up to form a cluster.

Q: What are Amazon ElastiCache nodes, shards and clusters?

Amazon ElastiCache for Memcached currently supports Memcached 1.5.10, 1.4.34, 1.4.33, 1.4.24, 1.4.14, and 1.4.5.

Q: Which engines does Amazon ElastiCache support?

If you are not already signed up for Amazon ElastiCache, you can click the "Get started" button on the Amazon ElastiCache page and complete the sign-up process. You must have an Amazon Web Services account; if you do not already have one, you will be prompted to create one when you begin the Amazon ElastiCache sign-up process. After you are signed up for ElastiCache, please refer to the Amazon ElastiCache documentation, which includes the Getting Started Guide for Amazon ElastiCache for Redis or Amazon ElastiCache for Memcached.

Q: How do I get started with Amazon ElastiCache?

Clusters are simple to create, using the AWS Management Console, Amazon ElastiCache APIs, or Command Line Tools. To launch a cluster using the AWS Management Console, click on the "Create" button in either the “Memcached” or “Redis” tab. From there, all you need to specify is your Cluster Identifier, Node Type, and Number of Nodes to create a cluster with the amount of memory you require. Alternatively, you can create your cluster using the CreateCacheCluster API or elasticache -create-cache-cluster command. If you do not specify an Availability Zone when creating a cluster, AWS will place it automatically based upon your memory requirements and available capacity.

Q: How do I create a cluster?

Amazon ElastiCache supports Nodes of the following types:

Q: What Node Types can I select?

Once your cluster is available, you can retrieve your node endpoints using the following steps on the AWS Management Console:

Q: How do I access my nodes?

You can think of the Amazon ElastiCache maintenance window as an opportunity to control when software patching occurs, in the event either are requested or required. If a "maintenance" event is scheduled for a given week, it will be initiated and completed at some point during the 60 minute maintenance window you identify.

Q: What is a maintenance window? Will my nodes be available during software maintenance?

You pay only for what you use and there is no minimum fee. Pricing is per Node-hour consumed for each Node Type. Partial Node-hours consumed are billed as full hours. There is no charge for data transfer between Amazon EC2 and Amazon ElastiCache within the same Availability Zone. While standard Amazon EC2 Regional Data Transfer charges apply when transferring data between an Amazon EC2 instance and an Amazon ElastiCache Node in different Availability Zones of the same Region, you are only charged for the Data Transfer in or out of the Amazon EC2 instance. There is no Amazon ElastiCache Data Transfer charge for traffic in or out of the Amazon ElastiCache Node itself. Standard data transfer rates apply for data transferred out from a region. For more information, please visit the pricing page.

Q: How will I be charged and billed for my use of Amazon ElastiCache?

Billing commences for a node as soon as the node is available. Billing continues until the node is terminated, which would occur upon deletion.

Q: When does billing of my Amazon ElastiCache Nodes begin and end?

Node hours are billed for any time your nodes are running in an "Available" state. If you no longer wish to be charged for your node, you must terminate it to avoid being billed for additional node hours.

Q: What defines billable ElastiCache Node hours?

Except as otherwise noted, our prices are exclusive of applicable taxes and duties, including VAT and applicable sales tax. For customers with a Japanese billing address, use of AWS services is subject to Japanese Consumption Tax. Learn more.

Q: Do your prices include taxes?

Reserved Nodes or Reserved Instance (RI) is an offering that provides you with a significant discount over on-demand usage when you commit to a one-year or three-year term. With Reserved Nodes, you can make a one-time, up-front payment to create a one or three year reservation to run your node in a specific Region and receive a significant discount off of the ongoing hourly usage charge. There are three Reserved Node types All Upfront, No Upfront and Partial Upfront that enable you to balance the amount you pay upfront with your effective hourly price.

Q: What are Amazon ElastiCache Reserved Nodes?

Functionally, Reserved Nodes and On-Demand Nodes are exactly the same. The only difference is how your Node(s) are billed; with Reserved Nodes, you make a one-time up-front payment and receive a lower ongoing hourly usage rate (compared with On-Demand Nodes) for the duration of the term.

Q: How are Reserved Nodes different from On-Demand Nodes?

You can use the "Purchase Reserved Nodes" option in the AWS Management Console. Alternatively, you can use the API tools to list the reservations available for purchase with the DescribeReservedCacheNodesOfferings API method and then purchase a cache node reservation by calling the PurchaseReservedCacheNodesOffering method.

Q: How do I purchase and create Reserved Nodes?

Yes. Reserved Nodes are purchased for the Region rather than for the Availability Zone. This means that even if capacity is limited in one Availability Zone, reservations can still be purchased in that Region and used in a different Availability Zone within that Region.

Q: Will there always be reservations available for purchase?

You can purchase up to 300 Reserved Nodes. If you wish to run more than 300 Nodes please complete the Amazon ElastiCache Node request form.

Q: How many Reserved Cache can I purchase?

Simply purchase a node reservation with the same node class, within the same region as the node you are currently running and would like to reserve. If the reservation purchase is successful, Amazon ElastiCache will automatically apply your new hourly usage charge to your existing node.

Q: What if I have an existing node that I’d like to convert to a Reserved Node?

Pricing changes associated with a Reserved Node are activated once your request is received while the payment authorization is processed. You can follow the status of your reservation on the AWS Account Activity page or by using the DescribeReservedCacheNodes API. If the one-time payment cannot be successfully authorized by the next billing period, the discounted price will not take effect.

Q: If I sign up for a Reserved Node, when does the term begin? What happens to my node when the term ends?

The Amazon ElastiCache APIs for creating, modifying, and deleting nodes do not distinguish between On-Demand and Reserved Nodes so that you can seamlessly use both. When computing your bill, our system will automatically apply your Reservation(s), such that all eligible nodes are charged at the lower hourly Reserved Cache Node rate.

Q: How do I control which nodes are billed at the Reserved Node rate?

Each Reserved Node is associated with a specific Region, which is fixed for the lifetime of the reservation and cannot be changed. Each reservation can, however, be used in any of the available AZs within the associated Region.

Q: Can I move a Reserved Node from one Region or Availability Zone to another?

No, you cannot cancel your reserved DB instance and the one-time payment (if applicable) is not refundable. You will continue to pay for every hour during your Reserved DB instance term regardless of your usage.

Q: Can I cancel a reservation?

When you purchase an RI under the All Upfront payment option, you pay for the entire term of the RI in one upfront payment. You can choose to pay nothing upfront by choosing the No Upfront option. The entire value of the No Upfront RI is spread across every hour in the term and you will be billed for every hour in the term, regardless of usage. The Partial Upfront payment option is a hybrid of the All Upfront and No Upfront options. You make a small upfront payment, and you are billed a low hourly rate for every hour in the term regardless of usage.

Q: How do the payment options impact my bill?

When not using VPC, Amazon ElastiCache allows you to control access to your clusters through Cache Security Groups. A Security Group acts like a firewall, controlling network access to your cluster. By default, network access is turned off to your clusters. If you want your applications to access your cluster, you must explicitly enable access from hosts in specific EC2 security groups. This process is called ingress.

Q: How do I control access to Amazon ElastiCache?

Yes. You can access an Amazon ElastiCache cluster from an application running in your data center providing there is connectivity between your VPC and the data center either through VPN or Direct Connect. The details are described here.

Q: Can programs running on servers in my own data center access Amazon ElastiCache?

Yes, EC2 instances in a VPC can access Amazon ElastiCache if the ElastiCache cluster was created within the VPC. Details on how to create an Amazon ElastiCache cluster within a VPC are given here.

Q: Can programs running on EC2 instances in a VPC access Amazon ElastiCache?

Amazon VPC lets you create a virtual networking environment in a private, isolated section of the Amazon Web Services (AWS) cloud, where you can exercise complete control over aspects such as private IP address ranges, subnets, routing tables and network gateways. With Amazon VPC, you can define a virtual network topology and customize the network configuration to closely resemble a traditional IP network that you might operate in your own datacenter.

Q: What is Amazon Virtual Private Cloud (VPC) and why may I want to use with Amazon ElastiCache?

For a walk through example of creating an Amazon ElastiCache Cluster in VPC, refer to the Amazon ElastiCache User Guide.

Q: How do I create an Amazon ElastiCache Cluster in VPC?

Creating an Amazon ElastiCache Cluster in an existing VPC is the same as that for a newly created VPC. Here are more details for Redis or Memcached.

Q: How do I create an Amazon ElastiCache Cluster in an existing VPC?

Amazon ElastiCache Nodes, deployed within a VPC, can be accessed by EC2 Instances deployed in the same VPC. If these EC2 Instances are deployed in a public subnet with associated Elastic IPs, you can access the EC2 Instances via the internet.

Q: How do I connect to an ElastiCache Node in VPC?

A Subnet Group is a collection of subnets that you must designate for your Amazon ElastiCache Cluster in a VPC. A Subnet Group is created using the Amazon ElastiCache Console. Each Subnet Group should have at least one subnet. Amazon ElastiCache uses the Subnet Group to select a subnet. The IP Addresses from the selected subnet are then associated with the Node Endpoints. Furthermore, Amazon ElastiCache creates and associates Elastic Network Interfaces to nodes with the previously mentioned IP addresses.

Q: What is a Subnet Group and why do I need one?

An existing Subnet Group can be updated to add more subnets either for existing Availability Zones or for new Availability Zones added since the creation of the ElastiCache Cluster. However, changing the Subnet Group of a deployed cluster is not currently allowed.

Q: Can I change the Subnet Group of my ElastiCache Cluster?

The basic functionality of Amazon ElastiCache remains the same whether VPC is used or not. Amazon ElastiCache manages automatic failure detection, recovery, scaling, auto discovery, and software patching whether your ElastiCache Cluster is inside or outside a VPC.

Q: How is using Amazon ElastiCache inside a VPC different from using it outside?

No, you cannot move an existing Amazon ElastiCache Cluster from outside VPC into a VPC. You will need to create a new Amazon ElastiCache Cluster inside the VPC.

Q: Can I move my existing ElastiCache Cluster from outside VPC into my VPC?

Currently, direct migration of ElastiCache Cluster from inside to outside VPC is not supported. You will need to create a new Amazon ElastiCache Cluster outside VPC.

Q: Can I move my existing ElastiCache Cluster from inside VPC to outside VPC?

Amazon ElastiCache allows you to control access to your cluster and therefore the nodes using Security Groups in non-VPC deployments. A Security Group acts like a firewall controlling network access to your node. By default, network access is turned off to your nodes. If you want your applications to access your node, you can set your Security Group to allow access from EC2 Instances with specific EC2 Security Group membership or IP ranges. This process is called ingress. Once ingress is configured for a Security Group, the same rules apply to all nodes associated with that Security Group. Security Groups can be configured with the “Security Groups” section of the Amazon ElastiCache Console or using the Amazon ElastiCache APIs.

Q: How do I control network access to my cluster?

You are responsible for modifying routing tables and networking ACLs in your VPC to ensure that your ElastiCache Nodes are reachable from your client instances in the VPC. To learn more see the Amazon ElastiCache for Redis or Amazon ElastiCache for Memcached Documentation.

Q: What precautions should I take to ensure that my ElastiCache Nodes in VPC are accessible by my application?

No, Security Groups are not used when operating in a VPC. Instead they are used in the non VPC settings. When creating a cluster in a VPC you will need to use VPC Security Groups.

Q: Can I use Security Groups to configure the clusters that are part of my VPC?

No, you can only associate VPC security groups that are part of the same VPC as your cluster.

Q: Can I associate a regular EC2 security group with a cluster that is launched within a VPC?

Yes, nodes of an Amazon ElastiCache cluster can span multiple subnets as long as the subnets are part of the same Subnet Group that was associated with the ElastiCache Cluster at creation time.

Q: Can nodes of an ElastiCache cluster span multiple subnets?

A Parameter Group acts as a "container" for engine configuration values that can be applied to one or more clusters. If you create a cluster without specifying a Parameter Group, a default Parameter Group is used. This default group contains engine defaults and Amazon ElastiCache system defaults optimized for the cluster you are running. However, if you want your cluster to run with your custom-specified engine configuration values, you can simply create a new Parameter Group, modify the desired parameters, and modify the cluster to use the new Parameter Group. Once associated, all clusters that use a particular Parameter Group get all the parameter updates to that Parameter Group. For more information on configuring Parameter Groups, please refer to the Amazon ElastiCache for Redis or Amazon ElastiCache for Memcached User Guide.

Q: What are Parameter Groups? How are they helpful?

Amazon ElastiCache by default chooses the optimal configuration parameters for your cluster taking into account the Node Type's memory/compute resource capacity. However, if you want to change them, you can do so using our configuration management APIs. Please note that changing configuration parameters from recommended values can have unintended effects, ranging from degraded performance to system crashes, and should only be attempted by advanced users who wish to assume these risks. For more information on changing parameters, please refer to the Amazon ElastiCache User Guide.

Q: How do I choose the right configuration parameters for my Cluster(s)?

You can use the AWS Management Console, Amazon ElastiCache APIs, or Command Line Tools to see information about your Parameter Groups and their corresponding parameter settings.

Q: How do I see the current setting for my parameters for a given Parameter Group?

You can cache a variety of objects using the service, from the content in persistent data stores (such as Amazon RDS, DynamoDB, or self-managed databases hosted on EC2) to dynamically generated web pages (with Nginx for example), or transient session data that may not require a persistent backing store. You can also use it to implement high-frequency counters to deploy admission control in high volume web applications.

Q: What can I cache using Amazon ElastiCache for Memcached?

Yes, Amazon ElastiCache is an ideal front-end for data stores like Amazon RDS or Amazon DynamoDB, providing a high-performance middle tier for applications with extremely high request rates and/or low latency requirements.

Q: Can I use Amazon ElastiCache for Memcached with an AWS persistent data store such as Amazon RDS or Amazon DynamoDB?

Amazon ElastiCache is protocol-compliant with Memcached. Therefore, you can use standard Memcached operations like get, set, incr and decr in exactly the same way as you would in your existing Memcached deployments. Amazon ElastiCache supports both the text and binary protocols. It also supports most of the standard stats results, which can also be viewed as graphs via CloudWatch. As a result, you can switch to using Amazon ElastiCache without recompiling or re-linking your applications - the libraries you use will continue to work. To configure the cache servers your application accesses, all you will need to do is to update your application's Memcached config file to include the endpoints of the servers (nodes) we provision for you. You can simply use the "Copy Node Endpoints" option on the AWS Management Console or the "DescribeCacheClusters" API to get a list of the endpoints. As with any migration process, we recommend thorough testing of your new Amazon ElastiCache deployment before completing the cut over from your current solution.

Q: I use Memcached today. How do I migrate to Amazon ElastiCache?

Though there is no precise answer for this question, with Amazon ElastiCache, you don't need to worry about getting the number of nodes exactly right, as you can very easily add or remove nodes later. The following two inter-related aspects could be considered for the choice of your initial configuration:

Q: How do I select an appropriate Node Type for my application?

Yes. When creating a cluster or adding nodes to an existing cluster, you can chose the availability zones for the new nodes. You can either specify the requested amount of nodes in each availability zones or select “spread nodes across zones”. If the cluster is in VPC, nodes can only be placed in availability zones that are part of the selected cache subnet group. For additional details please see ElastiCache VPC documentation.

Q: Can a cluster span multiple Availability Zones?

You can run a maximum of 300 nodes per region. If you need more nodes, please fill in the ElastiCache Limit Increase Request form.

Q: How many nodes can I run per region in Amazon ElastiCache Memcached?

The service will detect the node failure and react with the following automatic steps:

Q: How does Amazon ElastiCache respond to node failure?

You could add more nodes to your existing Memcached Cluster by using the "Add Node" option on "Nodes" tab for your Cache Cluster on the AWS Management Console or calling the ModifyCacheCluster API.

Q: If I determine that I need more memory to support my application, how do I increase the total memory with Amazon ElastiCache?

Amazon ElastiCache is ideally suited as a front-end for Amazon Web Services like Amazon RDS and Amazon DynamoDB, providing extremely low latency for high performance applications and offloading some of the request volume while these services provide long lasting data durability. The service can also be used to improve application performance in conjunction with Amazon EC2 and EMR.

Q: How does Amazon ElastiCache interact with other Amazon Web Services?

Memcached client libraries are available for many, if not all of the popular programming languages. For more information on Memcached clients, please see this. If you encounter any issues with specific Memcached clients when using Amazon ElastiCache, please engage us via the Amazon ElastiCache community forum.

Q: Is Amazon ElastiCache better suited to any specific programming language?

Amazon ElastiCache does not require specific client libraries and works with existing Memcached client libraries without recompilation or application re-linking (Memcached 1.4.5 and later); examples include libMemcached (C) and libraries based on it (e.g. PHP, Perl, Python), spyMemcached (Java) and fauna (Ruby).

Q: What popular Memcached libraries are compatible with Amazon ElastiCache?

Auto Discovery is a feature that saves developers time and effort, while reducing complexity of their applications. Auto Discovery enables automatic discovery of cache nodes by clients when they are added to or removed from an Amazon ElastiCache cluster. Until now to handle cluster membership changes, developers must update the list of cache node endpoints manually. Depending on how the client application is architected, typically a client initialization, by shutting down the application and restarting it, is needed resulting in downtime. Through Auto Discovery we are eliminating this complexity. With Auto Discovery, in addition to being backwards protocol-compliant with the Memcached protocol, Amazon ElastiCache provides clients with information on cache cluster membership. A client capable of processing the additional information reconfigures itself, without any initialization, to use the most current nodes of an Amazon ElastiCache cluster.

Q: What is Auto Discovery and what can I do with it?

An Amazon ElastiCache cluster can be created with nodes that are addressable via named endpoints. With Auto Discovery the Amazon ElastiCache cluster is also given a unique Configuration Endpoint which is a DNS Record that is valid for the lifetime of the cluster. This DNS Record contains the DNS Names of the nodes that belong to the cluster. Amazon ElastiCache will ensure that the Configuration Endpoint always points to at least one such “target” node. A query to the target node then returns endpoints for all the nodes of the cluster in question. After this, you can connect to the cluster nodes just as before and use the Memcached protocol commands such as get, set, incr and decr. For more details, see here. To use Auto Discovery, you will need an Auto Discovery capable client. Auto Discovery clients for Java and PHP are available for download from the Amazon ElastiCache console. Upon initialization, the client will automatically determine the current members of the Amazon ElastiCache cluster using the Configuration Endpoint. When you make changes to your cache cluster by adding or removing nodes or if a node is replaced upon failure, the Auto Discovery client automatically determines the changes and you do not need to initialize your clients manually.

Q: How does Auto Discovery work?

To get started, download the Amazon ElastiCache Cluster Client by clicking the “Download ElastiCache Cluster Client” link on the Amazon ElastiCache console. Before you can download, you must have an Amazon ElastiCache account; if you do not already have one, you can sign up from the Amazon ElastiCache detail page. After you download the client, you can begin setting up and activating your Amazon ElastiCache cluster by visiting the Amazon ElastiCache console. More details can be found here.

Q: How can I get started using Auto Discovery?

No, you will not get the Auto Discovery feature with the existing Memcached clients. To use the Auto Discovery feature a client must be able to use a Configuration Endpoint and determine the cluster node endpoints. You may either use the Amazon ElastiCache Cluster Client or extend your existing Memcached client to include the Auto Discovery command set.

Q: If I continue to use my own Memcached clients with my ElastiCache cluster – will I be able to get this feature?

To take advantage of Auto Discovery, an Auto Discovery capable client must be used to connect to an Amazon ElastiCache Cluster. Amazon ElastiCache currently supports Auto Discovery capable clients for both Java and PHP. These can be downloaded from the Amazon ElastiCache console. Our customers can create clients for any other language by building upon the popular Memcached clients available.

Q: What are the minimum hardware / software requirements for Auto Discovery?

You can take any Memcached Client Library and add support for Auto Discovery. If you would like to add or modify your own client to enable Auto Discovery, please refer to the Auto Discovery command set documentation.

Q: How do I modify or write my own Memcached client to support auto-discovery?

Yes, Amazon ElastiCache is still Memcached protocol compliant and does not require you to change your clients. However, for taking advantage of auto-discovery feature, we had to enhance the Memcached client capabilities. If you choose to not use the Amazon ElastiCache Cluster Client, you can continue to use your own clients or modify your own client library to understand the auto-discovery command set.

Q: Can I continue to work with my existing Memcached client if I don’t need Auto-discovery?

Yes, the same Amazon ElastiCache cluster can be connected through an Auto Discovery capable Client and the traditional Memcached client at the same time. Amazon ElastiCache remains 100% Memcached compliant.

Q: Can I have heterogeneous clients when using Auto Discovery?

Yes, you can stop using Auto Discovery anytime. You can disable Auto Discovery by specifying the mode of operation during the Amazon ElastiCache Cluster client initialization. Also, since Amazon ElastiCache continues to support Memcached 100% you may use any Memcached protocol-compliant client as before.

Q: Can I stop using Auto Discovery?

Amazon ElastiCache allows you to control if and when the Memcached protocol-compliant software powering your cluster is upgraded to new versions supported by Amazon ElastiCache. This provides you with the flexibility to maintain compatibility with specific Memcached versions, test new versions with your application before deploying in production, and perform version upgrades on your own terms and timelines. Version upgrades involve some compatibility risk, thus they will not occur automatically and must be initiated by you. This approach to software patching puts you in the driver's seat of version upgrades, but still offloads the work of patch application to Amazon ElastiCache. You can learn more about version management by reading the FAQs that follow. Alternatively, you can refer to the Amazon ElastiCache User Guide. While Engine Version Management functionality is intended to give you as much control as possible over how patching occurs, we may patch your cluster on your behalf if we determine there is any security vulnerability in the system or cache software.

Q: Can I control if and when the engine version powering Amazon ElastiCache Cluster is upgraded to new supported versions?

You can specify any currently supported version (minor and/or major) when creating a new cluster. If you wish to initiate an upgrade to a supported engine version release, you can do so using the "Modify" option for your cluster. Simply specify the version you wish to upgrade to via the "Cache Engine Version" field. The upgrade will then be applied on your behalf either immediately (if the "Applied Immediately" option is checked) or during the next scheduled maintenance window for your cluster.

Q: How do I specify which supported Memcached Version my Cluster should run?

Yes. You can do so by creating a new cluster with the new engine version. You can point your development/staging application to this cluster, test it and decide whether or not to upgrade your original cluster.

Q: Can I test my cluster against a new version before upgrading?

Over time, we plan to support additional Memcached versions for Amazon ElastiCache, both major and minor. The number of new version releases supported in a given year will vary based on the frequency and content of the Memcached version releases and the outcome of a thorough vetting of the release by our engineering team. However, as a general guidance, we aim to support new Memcached versions within 3-5 months of their General Availability release.

Q: Does Amazon ElastiCache provide guidelines for supporting new Memcached version releases and/or deprecating versions that are currently supported?

Amazon ElastiCache supports the Memcached text and binary protocol of versions 1.5.10, 1.4.34, 1.4.33, 1.4.24, 1.4.14, and 1.4.5 of Memcached.

Q: Which version of the Memcached wire protocol does Amazon ElastiCache support?

You can upgrade your existing Memcached cluster by using the Modify process. When upgrading from an older version of Memcached to Memcached version 1.4.33 or newer, please ensure that your existing parameter max_chunk_size values satisfies conditions needed for slab_chunk_max parameter. Please review upgrade prerequisites here.

Q: What should I do to upgrade to the latest Memcached version?

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: What is Amazon ElastiCache for 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.6, 5.0.5, 5.0.4, 5.0.3, 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: Is Amazon ElastiCache for Redis protocol-compliant with open source Redis?

An Amazon ElastiCache node is the smallest building block of an ElastiCache for Redis Cluster deployment. Each node supports the Redis protocol with Amazon’s enhancements and has its own endpoint and port. Multiple types of nodes are supported, each with varying amount of CPU capability, and memory capacity.

Q: What are Amazon ElastiCache for Redis nodes and shards?

Yes, you can achieve persistence by snapshotting your Redis data using the Backup and Restore feature. Please see here for details.

Q: Does Amazon ElastiCache for Redis support Redis persistence?

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: How can I migrate from Amazon ElastiCache for Memcached to Amazon ElastiCache for Redis and vice versa?

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: Does Amazon ElastiCache for Redis support Multi-AZ operation?

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: What options does Amazon ElastiCache for Redis provide for node failures?

For Multi-AZ enabled replication groups, the failover behavior is described at the Multi-AZ section of this FAQ.

Q: How does failover work?

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: Are my read replicas available during a primary node failure?

You can configure your Redis installation using a 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 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: How do I configure parameters of my Amazon ElastiCache for Redis nodes?

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 I access Redis through the Amazon ElastiCache console?

Yes, just as you can create Memcached clusters within a VPC, you can create Redis clusters within a VPC as well. 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: Can Amazon ElastiCache for Redis clusters be created in an Amazon VPC?

Yes, Redis AUTH functionality is available on Amazon ElastiCache for Redis. At the time of Redis cluster creation via the console or command line interface, once you enable encryption in-transit, you can use the Redis AUTH command to provide an authentication token for communication with the Redis cluster.

Q. Is Redis AUTH functionality supported in Amazon ElastiCache for Redis?

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 cluster and click “Modify”. In the “Modify” window select your preferred engine version from the available options. If you are upgrading to Redis version 5.0.5 or higher, and using Redis Cluster configurations with Redis Cluster client or using non-Cluster configuration with auto-failover enabled, then the engine version upgrade completes while the cluster stays online and continues serving incoming requests.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. How do I upgrade to a newer engine version?

No. Downgrading to an earlier engine version is not supported.

Q. Can I downgrade to an earlier engine version?

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” window select your preferred node type from the available options.

Q. How do I scale up to a larger node type?

Yes, you can modify your cluster to move to a smaller node type and scale down. You can initiate the scale down in the same manner as scale up. When scaling down, please ensure that you are selecting a node that offers sufficient memory for your application needs. For Redis Cluster configurations and for Redis 5.0.5 and above non-Cluster configurations with autofailover enabled, the scaling completes while the cluster continues to stay online and serve incoming requests.

Q. Can I scale down to a smaller node type?

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. What is the correct metric to use to measure Redis CPU utilization?

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.

Q. Can I have cross-region replicas with Amazon ElastiCache for Redis?

Read Replicas serve two purposes in Redis:

Q: What does it mean to run a Redis node as a 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:

Q: When would I want to consider using a Redis read replica?

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 cluster, you specify the MasterCacheClusterIdentifier. The MasterCacheClusterIdentifier is the cache cluster Identifier of the “primary” node from which you wish to replicate. You then create the read replica cluster within the shard by calling the CreateCacheCluster API specifying the ReplicationGroupIdentifier and the CacheClusterIdentifier of the master node. As with a standard 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 node in a shard and begins replication. As a result, you will experience a brief I/O suspension on your primary node as the snapshot occurs. The I/O suspension typically lasts on the order of one minute.

Q: How do I deploy a read replica node for a given primary node?

Yes. You can create a new cache cluster along with read replicas in minutes using the CreateReplicationGroup API or using the “Create” wizard at the Amazon ElastiCache Management Console and selecting “Multi-AZ Replication”. When creating the cluster, specify an identifier, the total number of desired shard in a cluster a read replicas per shard, along with cahe creation parameters such as node type, engine version, etc. You can also specify the Availability Zone for each shard in the cluster.

Q: Can I create both a primary and read replicas at the same time?

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:

Q: How do I connect to my read replica(s)?

At this time, Amazon ElastiCache allows you to create up to five (5) read replicas for a given primary node.

Q: How many read replicas can I create for a given primary node?

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: What happens to read replicas if failover occurs?

Creating a read replica of another read replica is not supported.

Q: Can I create a read replica of another read replica?

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: Can I promote my read replica into a “standalone” primary node?

Updates to a primary 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:

Q: Will my read replica be kept up-to-date with its primary node?

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 "Redis" tab of the Amazon ElastiCache Management Console.

Q: How do I gain visibility into active read replica(s)?

As discussed in the previous questions, “inconsistency” or lag between a read replica and its primary 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 node’s steady-state usage pattern.

Q: My read replica has fallen significantly behind its primary node. What should I do?

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 do I delete a read replica? Will it be deleted automatically if its primary node is deleted?

A read replica is billed as a standard node and at the same rates. Just like a standard node, the rate per “Node hour” for a read replica is determined by the 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: How much do read replicas cost? When does billing begin and end?

Initiated failover is supported by Amazon ElastiCache so that you can resume operations as quickly as possible. When failing over, Amazon ElastiCache simply flips the DNS record of your ElastiCache's primary endpoint 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: What happens during failover and how long does it take?

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 create a read replica in another region as my primary?

Yes, you can gain visibility into the location of the current primary by using the AWS Management Console or DescribeCacheClusters API.

Q: Can I see which Availability Zone my primary is currently located in?

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: Should I be concerned about latency?

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.

Q: Can I add and remove read replica nodes for my Redis Cluster environment?

No. Reader endpoint is only available for ElastiCache for Redis (cluster mode disabled) clusters.

Q: Is reader endpoint available for ElastiCache for Redis (cluster mode enabled) clusters?

Yes, your cluster's reader endpoint will point to the master node. When you add a new read replica to your cluster, the reader endpoint will be updated to point to the read replica instead.

Q: If I have a single node in my Redis (cluster mode disabled) cluster, will my reader endpoint point to the master node?

No, you cannot perform writes using a reader endpoint.

Q: Can I perform writes using my reader endpoint?

No. During new master node election at failovers, existing connections to a newly promoted master node are not automatically dropped. New connections to the new master node will not be established when you are using a reader endpoint.

Q: Will my existing connections to a read replica that is promoted to a master node after a failover get dropped if I'm connected to a reader endpoint?

Multi-AZ (Multi-Availability Zone) deployments provide enhanced availability for ElastiCache replication groups, making them a natural fit for production workloads. When you provision a Multi-AZ replication group, Amazon ElastiCache automatically creates the primary and replica nodes in separate AZs and asynchronously replicates data between them. In the event of an ElastiCache node failure, Amazon ElastiCache will automatically promote a healthy read replica with the least replication lag to become primary. In the unlikely event of an AZ failure, a replica in another AZ will be promoted to become the primary node. ElastiCache also propagates the DNS changes of the promoted read replica, so your application need not be changed if it is writing to the primary node endpoint.

Q: What is Multi-AZ for ElastiCache for Redis?

The benefits of using Multi-AZ are: (1) High Availability in the unlikely event of an AZ failure (2) ElastiCache SLA (Service Level Agreement) guarantees are available only in the Multi-AZ configuration. For more information about SLA, see ElastiCache documentation.

Q: What are the benefits of using Multi-AZ and when should I use it?

You can create a new Multi-AZ replication group using the ElastiCache console, command line interface or the web service APIs. You will need to place one of your replicas in a different AZ than the AZ of your primary node. You can also create a Multi-AZ replication group for Cluster Mode enabled or disabled.

Q: How do I create a Multi-AZ replication group?

Yes. To configure your existing replication group as Multi-AZ, please verify that at least one replica is placed in a different AZ than the AZ of your primary node. You should also check the Multi-AZ check box on the console to ensure that you are moving to Multi-AZ configuration. Also, using the CreateReplicationGroup API or the ModifyReplicationGroup API you can configure an existing replication group to be Multi-AZ compliant. Moving a replication group to be Multi-AZ does not interfere with its ability to serve requests.

Q: Can I configure an existing replication group to be Multi-AZ?

Yes. However, placing both the primary and replica(s) in the same AZ makes your ElastiCache Redis replication group non Multi-AZ compliant. Your replication group will not be resilient to an AZ disruption and will not be eligible for ElastiCache SLA guarantees. For more information about SLA, see ElastiCache documentation.

Q: Can I have all my replicas in the same AZ as the primary?

No. ElastiCache identifies the replica with the least replication lag and promotes it to be the primary node. If the AZ, to which the primary belongs to fails, then ElastiCache picks a replica in a different AZ. If only the primary node fails then ElastiCache can pick a healthy replica in the same AZ.

Q: Does ElastiCache always failover to a replica in a different AZ?

Yes. Amazon ElastiCache will create an event to inform you that a replica was promoted to a primary. You can use the DescribeEvents API to retrieve information about events related to your ElastiCache node. You can also view events in the Events section of the the ElastiCache Management Console.

Q: Will I be alerted when ElastiCache promotes a replica to a primary?

No. AZs are engineered to provide low latency network connectivity to other AZs in the same region.

Q: After the failover, my primary is now located in a different AZ than my other AWS resources (for example, EC2 instances). Should I be concerned about latency?

Yes. You can trigger a test failover using the TestFailover API on a Multi-AZ enabled replication group. ElastiCache will respond in the same way as a real failure by promoting a healthy read replica to become the new primary. ElastiCache also replaces the failed primary by making it a read replica.

Q: Can I test the Multi-AZ functionality?

Multi-AZ is free of charge. You only pay for the ElastiCache nodes that you use.

Q: How much does it cost to use Multi-AZ?

A: No.

Q: Is there any downtime to configure an existing replication group to be Multi-AZ?

All available node types in ElastiCache, except t1.micro, support Multi-AZ.

Q: What node types support Multi-AZ?

See ElastiCache documentation for additional information on Multi-AZ.

Q: Where can I get more information about Multi-AZ?

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 Backup and Restore?

A snapshot is a copy of your entire Redis cluster at a specific moment.

Q: What is a snapshot?

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: Why would I need snapshots?

You can use snapshots to warm start an ElastiCache for Redis cluster with preloaded data.

Q: What can I do with a snapshot?

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.

Q: How does Backup and Restore work?

The snapshots are stored in S3.

Q: Where are my snapshots stored?

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 can I get started using Backup and Restore?

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 do I specify which Redis cluster and node to backup?

No, snapshots are available only for ElastiCache for Redis.

Q: Does ElastiCache for Memcached support Backup and Restore?

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:

Q: How can I specify when a backup will take place?

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 a backup window and why do I need it?

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 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: What is the performance impact of taking a snapshot?

Yes. Creating a snapshot from a read replica is the best way to backup your data while minimizing performance impact.

Q: Can I create a snapshot from an ElastiCache for Redis read replica?

Backup and Restore feature is available in all regions where ElastiCache service is available.

Q: In what regions is the Backup and Restore feature available?

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 export ElastiCache for Redis snapshots to an S3 bucket owned by me?

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: 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 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: 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?

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: How much does it cost to use Backup and Restore?

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: What is the retention period?

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: How do I manage the retention of my automated snapshots?

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 snapshots are not retained.

Q: What happens to my snapshots if I delete my ElastiCache for Redis cluster?

All ElastiCache for Redis instance node types besides t1.micro family support backup and restore:

Q: What nodes types support backup and restore capability?

Yes. You can specify the S3 location of your RDB file during cluster creation through the "Create Cluster" Wizard in the console or through the CreateCacheCluster API.

Q: Can I use my own RDB snapshots stored in S3 to warm start an ElastiCache for Redis cluster?

Yes.

Q: Can I use the Backup and Restore feature if I am running ElastiCache in a VPC?

ElastiCache for Redis Cluster allows customers to create and run managed Redis Clusters with multiple shards. It is compatible with open source Redis 3.2.4 onwards and comes with a number of enhancements for a more stable and robust experience (see the “enhanced engine” section below for additional details on these enhancements).

Q: What is ElastiCache for Redis Cluster?

Q: Why would I need a scale out Redis environment?

There are three main scenarios for running a scale out Redis environment. First, if the total memory size of your Redis data exceeds or is projected to exceed the memory capacity of a single VM. Second, if the write throughput of your application to Redis exceeds the capacity of a single VM. Third, if you would like to spread the data across multiple shards so that any potential issue that comes up with a single node will have a smaller impact on the overall Redis environment.

Q: Why would I need a scale out Redis environment?

Amazon ElastiCache provides a fully managed distributed in-memory Redis environment, from provisioning server resources to installing the engine software and applying any configuration parameters you choose. It uses enhancements to the Redis engine developed by Amazon, which results in a more robust and stable experience (see “enhanced engine” section for more details). Once your Redis environment is up and running, the service automates common administrative tasks such as failure detection and recovery, backups and software patching. It also provides a robust Multi-AZ solution with automatic failover. In case of a failure of one or more primary nodes in your cluster, Amazon ElastiCache will automatically detect the failure and respond by promoting the most up to date replica to primary. This process is automated and does not mandate any manual work on your behalf. Amazon ElastiCache also provides detailed monitoring metrics associated with your ElastiCache nodes, enabling you to diagnose and respond to issues very quickly.

Q: Why would I run my Redis Cluster workload on Amazon ElastiCache?

Yes, Amazon ElastiCache for Redis Cluster is compatible with open source Redis 3.2.4 onwards. You can use the open source Redis Cluster clients to access scale-out clusters on ElastiCache for Redis.

Q: Is ElastiCache for Redis Cluster compatible with open source Redis?

If you are using Redis 3.2 with cluster_mode parameter disabled, you can simply choose the node or cluster you wish to upgrade and modify the engine version. ElastiCache will provision a Redis 3.2.4 cluster and migrate your data to it, while maintaining the endpoint.

Q: What is the upgrade path from current ElastiCache for Redis 2.8.x to ElastiCache for Redis Cluster (version 3.2.4)?

No. Amazon ElastiCache for Redis provides the flexibility of clustered and non-clustered configuration at the same price. Customers can now enjoy enhanced engine functionality within Amazon ElastiCache for Redis and use full feature support for clustered configuration and scalability at the same price.

Q: Is the pricing for clustered configuration different from non-clustered configuration?

Each shard of an ElastiCache for Redis cluster 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.

Q: What is Multi-AZ for ElastiCache for Redis Cluster?

Redis 3.x works with intelligent clients that store a node map with all the cluster nodes’ endpoints. During a failover, the client updates the node map with the IP endpoint for the new primary. This provides up to 4x faster failover time than with ElastiCache for Redis 2.8.x.

Q: How is Multi-AZ in ElastiCache for Redis Cluster different than in ElastiCache for Redis versions 2.8.x?

You can use Multi-AZ if you are using an ElastiCache for Redis Cluster with each shard having 1 or more read-replicas. If a primary node of a shard fails, ElastiCache will automatically detect the failure, select one of the available read-replicas, and promote it to become the new primary. The Redis 3.x client will update the promoted replica as primary, no application change is required. 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 a temporary Availability Zone failure, the new replica will be launched once that Availability Zone has recovered.

Q: How does Multi-AZ work for Redis Cluster?

An ElastiCache for Redis Cluster backup is a series of snapshots of the cluster’s shards, stored together to keep a copy of your entire Redis data around a certain time frame.

Q: What is a backup in ElastiCache for Redis Cluster?

Since a non-clustered ElastiCache for Redis environment has a single primary node, a backup is a single file which contains a copy of the Redis data. ElastiCache for Redis Cluster can have one or more shards, thus a backup might contain multiple files.

Q: How is a backup in ElastiCache for Redis Cluster different from a snapshot in ElastiCache for Redis?

You cannot manually specify a node to backup within each shard. When initiating a backup, ElastiCache will automatically select the most up-to-date read replica in each shard and take a snapshot of its data.

Q: How do I specify which ElastiCache for Redis nodes to backup in each shard?

When a backup is initiated, ElastiCache will take a backup of a specified cluster; that backup can later be used for recovery or archiving. The backup will include a copy of each of the cluster’s shards, thus a full backup contains a series of files. You can initiate a backup anytime you choose or set a recurring daily backup with retention period of up to 35 days.

Q: How does ElastiCache for Redis Cluster Backup and Restore work?

When you initiate a backup, ElastiCache will trigger backups of all of the shards of your cluster at the same time. In rare cases there might be a need to retake a snapshot of one or more nodes that did not complete successfully the first time. ElastiCache does that automatically and no user intervention is required. But in such a case, while each individual snapshot is a point-in-time representation of the node it was taken from, not all the cluster’s snapshots would be taken at the same time.

Q: Is the backup in ElastiCache for Redis Cluster a point-in-time snapshot?

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:

Q: How can I specify when a backup will take place?

Yes. You can specify the S3 location of your RDB files during cluster creation through the Create Cluster Wizard in the console or through the CreateReplicationGroup API. ElastiCache will automatically parse the Redis key-space of the RDB snapshot and redistribute it among the shards of the new cluster.

Q: Can I use my own RDB snapshots stored in S3 to pre-seed a scale out ElastiCache for Redis Cluster environment?

The engine within ElastiCache for Redis is fully compatible with open source Redis but also comes with enhancements that improve robustness and stability. Some of the enhancements are:

Q: How is the engine within ElastiCache for Redis different from open-source Redis?

To use the enhanced engine from the Amazon ElastiCache management console, just select an engine compatible with Redis engine version 2.8.22 or higher when creating a cluster. From that point on you will be using the enhanced engine. You can also use the enhanced engine through the ElastiCache API or AWS CLI by specifying the engine version when running the CreateCacheCluster API.

Q: How do I use the enhanced engine?

No. The enhanced engine is fully compatible with open-source Redis, thus you can enjoy its improved robustness and stability without the need to make any changes to your application code.

Q: Do I need to change my application code to use the enhanced engine on ElastiCache?

There is no additional charge for using the enhanced engine. As always, you will only be charged for the nodes you use.

Q: How much does it cost to use the enhanced engine?

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 is 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: What are the benefits of using Online Cluster Resizing?

Online Cluster Resizing is available with Redis engine version 3.2.10 and up. 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 can I use Online Cluster Resizing?

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: How long does the Online Cluster Resizing take?

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: Can the cluster be used while cluster resizing is in progress?

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: Is there any performance impact of this operation on the cluster?

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: How can I track the progress of an online resharding operation?

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: What is the rebalance operation for ElastiCache for Redis cluster?

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: How does tagging work when a cluster scales-out?

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: Are there any client or application side changes needed to use online cluster resizing?

There is no additional charge for using the enhanced Redis engine. As always, you will only be charged for the nodes you use.

Q: How much does it cost to use the enhanced Redis engine?

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 in-transit for ElastiCache for Redis provide?

Encryption at-rest allows for encryption of all data on disk during backups, restore and swap, as well as backups created and stored in Amazon S3.

Q: What does encryption at-rest for ElastiCache for Redis provide?

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: How can I use encryption in-transit, at-rest, and Redis AUTH?

Yes, Amazon ElastiCache for Redis supports AWS KMS to provide encryption at rest using customer managed customer master keys (CMKs) in AWS KMS. You can use your own CMKs to encrypt data at rest in ElastiCache for Redis. Customer managed CMKs are CMKs in your AWS account that you create, own and manage. For more information, see Amazon ElastiCache User Guide.

Q: Does Amazon ElastiCache for Redis support AWS Key Management Service (KMS)?

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: 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 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.3, 5.0.0, 4.0.10, and 3.2.6 support these features.

Q: Can I enable encryption in-transit and encryption at-rest on my existing ElastiCache for Redis clusters?

No. ElastiCache manages certification expiration and renewal behind the scene. No user action is necessary for ongoing certificate maintenance.

Q: Is there any action needed to renew certificates?

No. Currently, ElastiCache does not provide the ability for you to use your certificates. ElastiCache manages certificates transparently for you.

Q: Can I use my certificates for encryption?

Encryption in transit and encryption at rest are supported on R5, R4, R3, M5, M4, M3 and T2 node families

Q: Which node types are supported for encryption in transit and encryption at rest?

There are no additional costs for using encryption.

Q: Are there 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: Which compliance programs does ElastiCache for Redis support?

Yes, the AWS PCI compliance program includes Amazon ElastiCache for Redis as a PCI compliant Service.

Q: Is Amazon ElastiCache for Redis PCI compliant?

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: Is Amazon ElastiCache for Redis HIPAA eligible?

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: What do I have to do to use HIPAA eligible ElastiCache for Redis?

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.

Q: Is Amazon ElastiCache for Redis FedRAMP authorized?

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

Q: Does it cost extra to use compliance features?

ElastiCache for Redis provides this as a self-service feature to apply the latest security updates to your Redis clusters that are in scope of supported compliance programs – HIPAA, PCI and FedRAMP. Using this feature gives you more control to plan ahead on when to apply the service updates and mitigate any unintended impact to your business applications such as data loss, and cluster unavailability at peak times. The feature also updates you on the progress as it applies the updates to your selected Redis clusters in real time, giving you more control of when to stop or continue the updates. For more details on this feature see Self-Service Updates in Amazon ElastiCache. To see the requirements of each compliance regime on Amazon ElastiCache for Redis, see ElastiCache for Redis Compliance.

Q: How is Service Updates feature related to Compliance?

Yes, this feature is available to everyone and benefits all customers who want to keep their Redis replication groups up-to-date with latest security updates at all times.

Q: Can I use Service Updates feature even if I am not interested in Compliance?

No, this feature enables you to apply specific updates to your Redis fleet in ElastiCache. Amazon ElastiCache service will continue to apply upgrades that strengthen security, reliability, and operational performance as necessary in your maintenance windows.

Q: Does Service Updates feature replace ElastiCache service maintenance activities?

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.

Q: What is Global Datastore for Redis?

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: How many AWS regions can I replicate to?

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: Which engine versions support 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: How can I create Global Datastore for Redis?

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: Does ElastiCache automatically failover a Global Datastore for Redis to promote a secondary cluster in the event when primary cluster (region) is degraded?

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 do I perform application failover for disaster recovery if my primary cluster experiences degradation of service?

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: How is my data secured when using 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 Recovery Point Objective (RPO) and Recovery Time Objective (RTO) can I expect with 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.

Q: What is the pricing for Global Datastore for Redis?