Amazon ElastiCache FAQs

General

Q: What is Amazon ElastiCache?

Amazon ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory cache in the cloud. Amazon ElastiCache improves the performance of web applications by allowing you to retrieve information from a fast, managed, in-memory caching system, instead of relying entirely on slower disk-based databases. The service simplifies and offloads the management, monitoring and operation of in-memory cache 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.

Amazon ElastiCache automates common administrative tasks required to operate a distributed cache environment. Using Amazon ElastiCache, you can add a caching layer to your application architecture in a matter of minutes via a few clicks of the AWS Management Console. Once a cache cluster is provisioned, Amazon ElastiCache automatically detects and replaces failed cache nodes, providing a resilient system that mitigates the risk of overloaded databases, which slow website and application load times. Through integration with Amazon CloudWatch monitoring, Amazon ElastiCache provides enhanced visibility into key performance metrics associated with your cache nodes. Amazon ElastiCache is protocol-compliant with Memcached, a widely adopted memory object caching system, so code, applications, and popular tools that you use today with your existing Memcached environments will work seamlessly with the service. As with all Amazon Web Services, there are no up-front investments required, and you pay only for the resources you use.

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

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 can I cache using Amazon ElastiCache?

You can cache a variety of objects using the service, from the content in persistent data stores (such as Amazon RDS, SimpleDB, 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 does Amazon ElastiCache manage on my behalf?

Amazon ElastiCache manages the work involved in setting up a distributed in-memory cache, from provisioning the server resources you request to installing the caching software. Once your cache 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 Cache 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 Cache Nodes is overloaded with requests.

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

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

Q: What are Cache Nodes and Cache Clusters?

A Cache Node is the smallest building block of an Amazon ElastiCache deployment. It is a fixed-size chunk of secure, network-attached RAM. Each Cache Node runs an instance of the Memcached software and has its own DNS name and port. Multiple types of Cache Nodes are supported, each with varying amount of associated memory.

A Cache Cluster is a collection of one more Cache Nodes, each running an instance of the Memcached service. Most of your operations will be performed at the Cache Cluster level. All Cache Nodes within a Cache Cluster are designed to be of the same Node Type, have the same parameter and security group settings.

Q: How do I get started with Amazon ElastiCache?

If you are not already signed up for Amazon ElastiCache, you can click the "Sign Up Now" button on the Amazon ElastiCache detail 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 our Getting Started Guide.

Once you have familiarized yourself with Amazon ElastiCache, you can launch a Cache Cluster within minutes by using the AWS Management Console or Amazon ElastiCache APIs.

Q: How do I create a Cache Cluster?

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

Q: How do I access my Cache Nodes?

Once your Cache Cluster is available, you can retrieve your Cache Node endpoints using the following steps on the AWS Management Console:

• Navigate to the "Amazon ElastiCache" tab.
• Click on the "(Number of) Nodes" link and navigate to the "Nodes" tab.
• Click on the "Copy Node Endpoint(s)" button.

Alternatively, you can use the DescribeCacheClusters API to retrieve the Endpoint list.

You can then configure the Memcached config file used by your favorite Memcached clients with this endpoint list and use your favorite programming language to add or delete data from your ElastiCache Nodes. In order to allow network requests to your Cache Nodes, you will need to authorize access. For a detailed explanation to get started, please refer to our Getting Started Guide.

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

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 (Cache 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.

Please note that Amazon ElastiCache currently allows access only from the Amazon EC2 network, so in order to use the service, you should have your application servers in Amazon EC2.

Amazon ElastiCache uses DNS entries to allow client applications to locate cache servers (Cache Nodes). The DNS name for a Cache Node remains constant, but the IP address of a Cache Node can change over time, for example, when Cache Nodes are auto replaced after a failure. See this FAQ for recommendations to deal with Cache Node failures.

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

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.

Your Cache Nodes could incur some downtime during your maintenance window if software patching is scheduled. Please refer to Cache Engine Version Management for more details. Patching can be user requested - for example cache software upgrade, or determined as required (if we identify any security vulnerabilities in the system or caching software). Software patching occurs infrequently (typically once every few months) and should seldom require more than a fraction of your maintenance window. If you do not specify a preferred weekly maintenance window when creating your Cache Cluster, a 60 minute default value is assigned. If you wish to modify when maintenance is performed on your behalf, you can do so by modifying your DB Instance in the AWS Management Console or by using the ModifyCacheCluster API. Each of your Cache Clusters can have different preferred maintenance windows, if you so choose.

↑ Top

---

Billing

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

You pay only for what you use and there is no minimum fee. Pricing is per Cache 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. For more information, please visit the pricing page.

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

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

Q: What defines billable ElastiCache Node hours?

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

Q: Do your prices include taxes?

Except as otherwise noted, our prices are exclusive of applicable taxes and duties, including VAT and applicable sales tax.

↑ Top

---

Reserved Cache Nodes

Q: What are Amazon ElastiCache Reserved Cache Nodes?

With Reserved Cache Nodes, you can now make a one-time, up-front payment to create a one or three year reservation to run your Cache Node in a specific Region and receive a significant discount off of the ongoing hourly usage charge. There are three Reserved Cache Node types (Light, Medium, and Heavy Utilization Reserved Cache Nodes) that enable you to balance the amount you pay upfront with your effective hourly price.

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

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

Q: How do I purchase and create Reserved Cache Nodes?

You can use the "Purchase Reserved Cache 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.

Creating a Reserved Cache Node is no different than launching an On-Demand Cache Node. You simply specify the Cache Node class and Region for which you made the reservation. So long as your reservation purchase was successful, Amazon ElastiCache will apply the reduced hourly rate for which you are eligible to the new Cache Node.

Q: Will there always be reservations available for purchase?

Yes. Reserved Cache 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: How many Reserved Cache Nodes can I purchase?

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

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

Simply purchase a Cache Node reservation with the same Cache Node class, within the same Region as the Cache 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 Cache Node.

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

Pricing changes associated with a Reserved Cache 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.

When your reservation term expires, your Reserved Cache Node will revert to the appropriate On-Demand hourly usage rate for your Cache Node class and Region.

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

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

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

Each Reserved Cache 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 cancel a reservation?

The one-time payment for Reserved Cache Nodes is not refundable. However, you can choose to terminate your Cache Node at any time, at which point you will not incur any hourly usage charges if you are using Light and Medium Utilization Reserved Cache Nodes.

Cache Configuration and Scaling

Q: What Cache Node Types can I select??

Amazon ElastiCache supports Cache Nodes of the following memory types:

• cache.m1.small: 1.3 GB
• cache.m1.large: 7.1 GB
• cache.m1.xlarge: 14.6 GB
• cache.m2.xlarge: 16.7 GB
• cache.m2.2xlarge: 33.8 GB
• cache.m2.4xlarge: 68 GB
• cache.c1.xlarge: 6.6 GB

Each Node Type above lists the memory available to Memcached after taking Amazon ElastiCache System Software overhead into account. The total amount of memory in a Cache Cluster is an integer multiple of the memory available for the Cache Node Type selected. For example, a Cache Cluster consisting of ten Cache Nodes of 6 GB each will provide 60 GB of total memory.

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

Though there is no precise answer for this question, with Amazon ElastiCache, you don't need to worry about getting the number of Cache 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:

• The total memory required for your cache to achieve your target cache-hit rate, and
• The number of Cache Nodes required to maintaining acceptable application performance without overloading the database backend in the event of Cache Node failure(s).

The amount of memory required is dependent upon the size of your data set and the access patterns of your application. To improve fault tolerance, once you have a rough idea of the total memory required, divide that memory into enough Cache Nodes such that your application can survive the loss of one or two Cache Nodes. For example, if your memory requirement is 14GB, you may want to use two cache.m1.large nodes instead of using one cache.m1.xlarge node. It is important that other systems such as databases will not be overloaded if the cache-hit rate is temporarily reduced during failure recovery of one or more of Cache Nodes. Please refer to the the Amazon ElastiCache User Guide for more details.

Q: Can a Cache Cluster span multiple Availability Zones?

Not at this time.

Q: How many Cache Nodes can I run in Amazon ElastiCache?

You can run a maximum of 20 Cache Nodes. If you need more Cache Nodes, please fill in the ElastiCache Limit Increase Request form.

Q: How does Amazon ElastiCache respond to Cache Node failure?

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

• Amazon ElastiCache will repair the Cache Node by acquiring new service resources, and will then redirect the Cache Node's existing DNS name to point to the new service resources. Thus, the DNS name for a Cache Node remains constant, but the IP address of a Cache Node can change over time.
• If you associated an SNS topic with your Cache Cluster, when the new Cache Node is configured and ready to be used, Amazon ElastiCache will send an SNS notification to let you know that Cache Node recovery occured. This allows you to optionally arrange for your applications to force the Memcached client library to attempt to reconnect to the repaired Cache Nodes. This may be important, as some Memcached libraries will stop using a server (Cache Node) indefinitely if they encounter communication errors or timeouts with that server.

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

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

↑ Top

---

Security

Q: How do I control access to Amazon ElastiCache?

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

To allow network access to your Cache Cluster, create a Cache Security Group and link the desired EC2 security groups (which in turn specify the EC2 instances allowed) to it. The Cache Security Group can be associated with your Cache Cluster at the time of creation, or using the "Modify" option on the AWS Management Console.

Please note that IP-range based access control is currently not enabled for Cache Clusters. All clients to a Cache Cluster must be within the EC2 network, and authorized via security groups as described above.

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

No. Currently, all clients to an ElastiCache Cluster must be within the Amazon EC2 network, and authorized via security groups as described here.

↑ Top

---

Cache Parameter Groups

Q: What are Cache Parameter groups? How are they helpful?

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

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

Amazon ElastiCache by default chooses the optimal configuration parameters for your Cache 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 see the current setting for my parameters for a given Cache Parameter Group?

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

↑ Top

---

Cache Engine Version Management

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

Amazon ElastiCache allows you to control if and when the Memcached protocol-compliant software powering your Cache 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.

Unless you specify otherwise, your Cache Cluster will automatically be upgraded to new Memcached minor versions as they are supported by Amazon ElastiCache. This patching will occur during your scheduled maintenance window, and will be announced on the Amazon ElastiCache Forum in advance. If you wish to turn off automatic version upgrades, you can do so by selecting the "Auto Minor Version Upgrade" for your Cache Cluster to "No". Since major version upgrades involve some compatibility risk, they will not occur automatically and must be initiated by you.

This approach to cache 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 Cache Engine Version Management functionality is intended to give you as much control as possible over how patching occurs, we may patch your Cache Cluster on your behalf if we determine there is any security vulnerability in the system or cache software.

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

You can specify any currently supported version (minor and/or major) when creating a new Cache Cluster. If you have opted out of automatically scheduled upgrades by selecting the "Auto Minor Version Upgrade" option to "No" but wish to manually initiate an upgrade to a supported minor version or major version release, you can do so using the "Modify" option for your Cache 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 Cache Cluster.

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

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

Q: How does Amazon ElastiCache distinguish between "major" and "minor" version releases?

In the context of Memached, version numbers are organized as follows:

Memcached version = X.Y.Z

X = Major version, Y = Release level, Z = Version number within release series.

From the Amazon ElastiCache standpoint, a version change would be considered major if either major version or release level is being changed. Example: going from 1.4.X -> 1.5.X. A version change would be considered minor if the version number within the release is being changed. Example: going from 1.4.5 -> 1.4.6.

As of today, Amazon ElastiCache supports the Memached major version 1.4. We plan to support additional Memcached major versions in the future.

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

Over time, we plan to support additional Memcached versions for Amazon ElastiCache, both minor and major. 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.

In terms of deprecation policy:

• We intend to support major Memcached version releases, including 1.4, for 2 years after they are initially supported by Amazon ElastiCache.
• We intend to support minor Memcached version releases (e.g., 1.4.5) for at least 1 year after they are initially supported by Amazon ElastiCache.
• After a Memcached major or minor version has been "deprecated", we expect to provide a three month grace period for you to initiate an upgrade to a supported version prior to an automatic upgrade being applied during your scheduled maintenance window.

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

Amazon ElastiCache supports the Memcached text and binary protocol as of version 1.4.5 of Memcached.

↑ Top

---

Compatibility

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

Amazon ElastiCache is ideally suited as a front-end for Amazon Web Services like Amazon RDS and Amazon SimpleDB, 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: Is Amazon ElastiCache better suited to any specific programming language?

Memcached client libraries are available for many, if not all of the popular programming languages. See the list of available clients at the Memcached project page here. If you encounter any issues with specific Memcached clients when using Amazon ElastiCache, please engage us via the Amazon ElastiCache community forum.

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

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).

↑ Top