# What is Amazon ElastiCache? What is ElastiCache? Welcome to the *Amazon ElastiCache User Guide*. Amazon ElastiCache is a web service that makes it easy to set up, manage, and scale a distributed in-memory data store or cache environment in the cloud. It provides a high-performance, scalable, and cost-effective caching solution. At the same time, it helps remove the complexity associated with deploying and managing a distributed cache environment. You can operate Amazon ElastiCache in two formats. You can get started with a serverless cache or create a node-based cluster. **Note** Amazon ElastiCache works with the Valkey, Memcached, and Redis OSS engines. If you're unsure which engine you want to use, see [Comparing node-based Valkey, Memcached, and Redis OSS clusters](SelectEngine.md) in this guide. ## Serverless caching Serverless caching ElastiCache offers serverless caching, which simplifies adding and operating a cache for your application. ElastiCache Serverless enables you to create a highly available cache in under a minute, and eliminates the need to provision instances or configure nodes or clusters. Developers can create a Serverless cache by specifying the cache name using the ElastiCache console, SDK or CLI. ElastiCache Serverless also removes the need to plan and manage caching capacity. ElastiCache constantly monitors the cache’s memory, compute, and network bandwidth used by your application, and scales to meet the needs of your application. ElastiCache offers a simple endpoint experience for developers, by abstracting the underlying cache infrastructure and cluster design. ElastiCache manages hardware provisioning, monitoring, node replacements, and software patching automatically and transparently, so that you can focus on application development, rather than operating the cache. ElastiCache Serverless is compatible with Valkey 7.2, Memcached 1.6.22 and above, and Redis OSS 7.1 and above. ## Creating a node-based cluster Node-based clusters If you need fine-grained control over your ElastiCache cluster, you can choose to create a node-based Valkey, Memcached, or Redis OSS cluster. ElastiCache enables you to create a node-based cluster by choosing the node-type, number of nodes, and node placement across AWS Availability Zones for your cluster. Since ElastiCache is a fully-managed service, it automatically manages hardware provisioning, monitoring, node replacements, and software patching for your cluster. Creating a node-based cluster offers greater flexibility and control over your clusters. For example, you can choose to operate a cluster with single-AZ availability or multi-AZ availability depending on your needs. You can also choose to run Valkey, Memcached, or Redis OSS in cluster mode enabling horizontal scaling, or without cluster mode for just scaling vertically. When creating a node-based cluster, you are responsible for choosing the type and number of nodes correctly to ensure that your cache has enough capacity as required by your application. You can also choose when to apply new software patches to your Valkey or Redis OSS cluster. When creating a node-based cluster you can choose from multiple supported versions of Valkey, Memcached and Redis OSS. For more information about supported engine versions see [Engine versions and upgrading in ElastiCache](engine-versions.md). # Related services [MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/what-is-memorydb-for-redis.html) When deciding whether to use ElastiCache or MemoryDB consider the following comparisons: + ElastiCache is a service that is commonly used to cache data from other databases and data stores using Valkey, Memcached, or Redis OSS. You should consider ElastiCache for caching workloads where you want to accelerate data access with your existing primary database or data store (microsecond read and write performance). You should also consider ElastiCache for use cases where you want to use Valkey or Redis OSS data structures and APIs to access data stored in a primary database or data store. + ElastiCache can also help you save database costs by storing frequently accessed data in a cache. If your application has high read throughput requirements, you can achieve high scale, fast performance, and lowered data storage costs by using ElastiCache, instead of scaling your underlying database. + MemoryDB is a durable, in-memory database for workloads that require an ultra-fast, primary database. It is compatible with Valkey and Redis OSS. You should consider using MemoryDB if your workload requires a durable database that provides ultra-fast performance (microsecond read and single-digit millisecond write latency). MemoryDB may also be a good fit for your use case if you want to build an application using Valkey or Redis OSS data structures and APIs with a primary, durable database. Finally, you should consider using MemoryDB to simplify your application architecture and lower costs by replacing usage of a database with a cache for durability and performance. [Amazon Relational Database Service](https://aws.amazon.com/rds/) For further background information on the related Amazon Relational Database Service service, see [Amazon RDS](https://docs.aws.amazon.com/rds/) # How ElastiCache works How it works Here you can find an overview of the major components of an ElastiCache deployment. ## Cache and caching engines Cache and caching engines A cache is an in-memory data store that you can use to store cached data. Typically, your application will cache frequently accessed data in a cache to optimize response times. ElastiCache offers two deployment options: serverless caches and node-based clusters. See [Choosing between deployment options](WhatIs.deployment.md). **Note** Amazon ElastiCache works with the Valkey, Memcached, and Redis OSS engines. If you're unsure which engine you want to use, see [Comparing node-based Valkey, Memcached, and Redis OSS clusters](SelectEngine.md) in this guide. **Topics** + [ ### How ElastiCache works ](#WhatIs.HowELCworks) + [ ### Pricing dimensions ](#WhatIs.ELCpricing) + [ ### ElastiCache backups ](#WhatIs.corecomponents.backups-redis) ### How ElastiCache works How ElastiCache works **ElastiCache Serverless** ElastiCache Serverless enables you to create a cache without worrying about capacity planning, hardware management, or cluster design. You simply provide a name for your cache and you receive a single endpoint that you can configure in your Valkey, Memcached, Redis OSS client to begin accessing your cache. **Note** ElastiCache Serverless runs Valkey, Memcached, or Redis OSS in cluster mode and is only compatible with clients that support TLS. **Key Benefits** + **No capacity planning:** ElastiCache Serverless removes the need for you to plan for capacity. ElastiCache Serverless continuously monitors the memory, compute, and network bandwidth utilization of your cache and scales both vertically and horizontally. It allows a cache node to grow in size, while in parallel initiating a scale-out operation to ensure that the cache can scale to meet your application requirements at all times. + **Pay-per-use:** With ElastiCache Serverless, you pay for the data stored and compute utilized by your workload on the cache. See [Pricing dimensions](#WhatIs.ELCpricing). + **High-availability:** ElastiCache Serverless automatically replicates your data across multiple Availability Zones (AZ) for high-availability. It automatically monitors the underlying cache nodes and replaces them in case of failures. It offers a 99.99% availability SLA for every cache. + **Automatic software upgrades:** ElastiCache Serverless automatically upgrades your cache to the latest minor and patch software version without any availability impact to your application. When a new major version is available, ElastiCache will send you a notification. + **Security:** Serverless always encrypts data in transit and at rest. You can use a service managed key or use your own Customer Managed Key to encrypt data at rest. The following diagram illustrates how ElastiCache Serverless works. ![\[A diagram of ElastiCache Serverless cache operation, from availability zones to the Customer VPC and then to the Service VPC.\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/images/ELC-serverless-works1.png) When you create a new serverless cache, ElastiCache creates a Virtual Private Cloud (VPC) Endpoint in the subnets of your choice in your VPC. Your application can connect to the cache through these VPC Endpoints. With ElastiCache Serverless you receive a single DNS endpoint that your application connects to. When you request a new connection to the endpoint, ElastiCache Serverless handles all cache connections through a proxy layer. The proxy layer helps reduce complex client configuration, because the client does not need to rediscover cluster topology in case of changes to the underlying cluster. The proxy layer is a set of proxy nodes that handle connections using a network load balancer. When your application creates a new cache connection, the request is sent to a proxy node by the network load balancer. When your application executes cache commands, the proxy node that is connected to your application executes the requests on a cache node in your cache. The proxy layer abstracts the cluster topology and nodes from your client. This enables ElastiCache to intelligently load balance, scale out and add new cache nodes, replace cache nodes when they fail, and update software on the cache nodes, all without availability impact to your application or having to reset connections. **Node-based clusters** You can create a node-based ElastiCache cluster by choosing a cache node family, size, and number of nodes for your cluster. Creating a node-based cluster gives you finer grained control and enables you to choose the number of shards in your cache and the number of nodes (primary and replica) in each shard. You can choose to operate Valkey or Redis OSS in cluster mode by creating a cluster with multiple shards, or in non-cluster mode with a single shard. **Key Benefits** + **Create a node-based cluster:** With ElastiCache, you can create a node-based cluster and choose where you want to place your cache nodes. For example, if you have an application that wants to trade-off high-availability for low latency, you can choose to deploy your cache nodes in a single AZ. Alternatively, you can create a node-based cluster with nodes across multiple AZs to achieve high-availability. + **Fine-grained control:** When creating a node-based cluster, you have more control over fine-tuning the settings on your cache. For example, you can use [Valkey and Redis OSS parameters](ParameterGroups.Engine.md#ParameterGroups.Redis) or [Memcached specific parameters](ParameterGroups.Engine.md#ParameterGroups.Memcached) to configure the cache engine. + **Scale vertically and horizontally:** You can choose to manually scale your cluster by increasing or decreasing the cache node size when needed. You can also scale horizontally by adding new shards or adding more replicas to your shards. You can also use the Auto-Scaling feature to configure scaling based on a schedule or scaling based on metrics like CPU and Memory usage on the cache. The following diagram illustrates how node-based ElastiCache clusters work. ![\[A diagram of ElastiCache node-based clusters operation, from availability zones to the Customer VPC and then to ElastiCache managed cache nodes.\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/images/ELC-serverless-works2.png) ### Pricing dimensions Pricing You can deploy ElastiCache in two deployment options. When deploying ElastiCache Serverless, you pay for usage for data stored in GB-hours and compute in ElastiCache Processing Units (ECPU). When creating a node-based cluster, you pay per hour of the cache node usage. See pricing details [here](https://aws.amazon.com/elasticache/pricing/). **Data storage** You pay for data stored in ElastiCache Serverless billed in gigabyte-hours (GB-hrs). ElastiCache Serverless continuously monitors the data stored in your cache, sampling multiple times per minute, and calculates an hourly average to determine the cache’s data storage usage in GB-hrs. Each ElastiCache Serverless cache is metered for a minimum of 1 GB of data stored. **ElastiCache Processing Units (ECPUs)** You pay for the requests your application executes on ElastiCache Serverless in ElastiCache Processing Units (ECPUs), a unit that includes both vCPU time and data transferred. + Simple reads and writes require 1 ECPU for each kilobyte (KB) of data transferred. For example, a GET command that transfers up to 1 KB of data consumes 1 ECPU. A SET request that transfers 3.2 KB of data will consume 3.2 ECPUs. + With Valkey and Redis OSS, commands that consume more vCPU time and transfer more data consume ECPUs based on the higher of the two dimensions. For example, if your application uses the HMGET command, consumes 3 times the vCPU time as a simple SET/GET command, and transfers 3.2 KB of data, it will consume 3.2 ECPU. Alternatively, if it transfers only 2 KB of data, it will consume 3 ECPUs. + With Valkey and Redis OSS, commands that require additional vCPU time will consume proportionally more ECPUs. For example, if your application uses the Valkey or Redis OSS [HMGET command](https://valkey.io/commands/hmget/), and consumes 3 times the vCPU time as a simple SET/GET command, then it will consume 3 ECPUs. + With Memcached, commands that operate on multiple items will consume proportionally more ECPUs. For example, if your application performs a multiget on 3 items, it will consume 3 ECPUs. + With Memcached, commands that operate on more items and transfer more data consume ECPUs based on the higher of the two dimensions. For example, if your application uses the GET command, retrieves 3 items, and transfers 3.2 KB of data, it will consume 3.2 ECPU. Alternatively, if it transfers only 2 KB of data, it will consume 3 ECPUs. ElastiCache Serverless emits a new metric called `ElastiCacheProcessingUnits` that helps you understand the ECPUs consumed by your workload. **Node hours** You can create a node-based cluster by choosing the EC2 node family, size, number of nodes, and placement across Availability Zones. When creating a node-based cluster, you pay per hour for each cache node. ### ElastiCache backups Snapshots A *backup* is a point-in-time copy of a serverless cache, or a Valkey or Redis OSS node-based cluster. ElastiCache enables you to take a backup of your data at any time or setup automatic backups. Backups can be used to restore an existing cache or to seed a new cache. Backups consist of all the data in a cache plus some metadata. For more information see [Snapshot and restore](backups.md). # Choosing between deployment options Choosing between deployment options Amazon ElastiCache has two deployment options: + Serverless caching + Node-based clusters For a list of supported commands for both, see [Supported and restricted Valkey, Memcached, and Redis OSS commands](SupportedCommands.md). **Serverless caching** Amazon ElastiCache Serverless simplifies cache creation and instantly scales to support customers' most demanding applications. With ElastiCache Serverless, you can create a highly-available and scalable cache in less than a minute, eliminating the need to provision, plan for, and manage cluster capacity. ElastiCache Serverless automatically stores data redundantly across three Availability Zones and provides a 99.99% availability Service Level Agreement (SLA). Backups from Valkey or Redis OSS node-based clusters can be restored into a serverless configuration. **Node-based clusters** If you need fine-grained control over your Valkey, Memcached, or Redis OSS cluster, you can create a node-based cluster with ElastiCache. You choose the node-type, number of nodes, and node placement across AWS Availability Zones for your cluster. Since ElastiCache is a fully-managed service, it helps manage hardware provisioning, monitoring, node replacements, and software patching for your cluster. Node-based clusters can be designed to provide an up to 99.99% availability SLA. Backups from serverless Valkey or Redis OSS caches can be restored into a node-based cluster. **Choosing between deployment options** Choose serverless caching if: + You are creating a cache for workloads that are either new or difficult to predict. + You have unpredictable application traffic. + You want the easiest way to get started with a cache. Create your own node-based cluster if: + You are already running ElastiCache Serverless and want finer grained control over the type of node running Valkey, Memcached, or Redis OSS, the number of nodes, and the placement of those nodes. + You expect your application traffic to be relatively predictable, and you want fine-grained control over performance, availability, and cost. + You can forecast your capacity requirements to control costs. ## Comparing serverless caching and node-based clusters Comparing features | Feature | Serverless caching | Node-based clusters | | --- | --- | --- | | Cache setup | Create a cache with just a name in under a minute | Provides fine-grained control over cluster design. User can choose node-type, number of nodes, and placement across AWS availability zones | | Supported ElastiCache version | Valkey 7.2 and higher, Redis OSS version 7.1 and higher, Memcached 1.6.22 and higher | Valkey 7.2 and higher, Redis OSS version 4.0 and higher, Memcached 1.4 and higher | | Cluster Mode (Valkey and Redis OSS) | Operates engines in `cluster mode enabled` only. Clients must support `cluster mode enabled` to connect to ElastiCache Serverless. | Can be configured to operate in cluster mode enabled or cluster mode disabled. | | Scaling | Automatically scales engines both vertically and horizontally without any capacity management. | Provides control over scaling, while also requiring monitoring to make sure current capacity is adequately meeting demand. For Valkey and Redis OSS, you can choose to scale vertically by increasing or decreasing the cache node size when needed. You can also scale horizontally, by adding new shards or adding more replicas to your shards. This capability is not available for Memcached. With the Auto-Scaling feature you can also configure scaling based on a schedule, or scale based on metrics like CPU and Memory usage on the cache. | | Client connection | Clients connect to a single endpoint. This enables the underlying cache node topology (scaling, replacements, and upgrades) to change without disconnecting the client. | Clients connect to each individual cache node. If a node is replaced, the client rediscovers cluster topology and re-establishes connections. | | Configurability | No fine-grained configuration available. Customers can configure basic settings including subnets which can access the cache, whether automatic backups are turned on or off, and maximum cache usage limits. | Node-based clusters provide fine-grained configuration options. Customers can use parameter groups for fine-grained control. For a table of these parameter values by node type, see [Engine specific parameters](ParameterGroups.Engine.md). | | Multi-AZ | Data is replicated asynchronously across multiple Availability Zones for higher availability and improved read latency. | Provides an option to create the cluster in a single Availability Zone or across multiple Availability Zones (AZs). When using Valkey or Redis OSS, provides Multi-AZ clusters with data replicated asynchronously across multiple Availability Zones for higher availability and improved read latency. | | Encryption at rest | Always enabled. Customers can use an AWS managed key or a customer managed key in AWS KMS. | Option to enable or disable encryption at rest. When enabled, customers can use an AWS managed key or a customer managed key in AWS KMS. | | Encryption in transit (TLS) | Always enabled. Clients must support TLS connectivity. | Option to enable or disable. | | Backups | Supports automatic and manual backups of caches with no performance impact. Valkey and Redis OSS backups are cross-compatible, and can be restored into an ElastiCache Serverless cache or a node-based cluster. | Supports automatic and manual backups for Valkey and Redis OSS. Clusters may see some performance impact depending on the available reserved memory. For more information, see [Managing reserved memory for Valkey and Redis OSS](redis-memory-management.md). Valkey and Redis OSS backups are cross-compatible, and can be restored into an ElastiCache Serverless cache or a node-based cluster. | | Monitoring | Support cache level metrics including cache hit rate, cache miss rate, data size, and ECPUs consumed. ElastiCache Serverless sends events using EventBridge when significant events happen on your cache. You can choose to monitor, ingest, transform, and act on ElastiCache events using Amazon EventBridge. For more information, see [Serverless cache events](serverless-metrics-events-redis.md#serverless-events). | Node-based ElastiCache clusters emit metrics at each node level, including both host-level metrics and cache metrics. Node-based clusters emit SNS notifications for significant events. See [Metrics for Memcached](CacheMetrics.Memcached.md) and [Metrics for Valkey and Redis OSS](CacheMetrics.Redis.md). | | Availability | 99.99% availability [Service Level Agreement (SLA)](https://aws.amazon.com/elasticache/sla/) | Node-based clusters can be designed to achieve up to 99.99% availability [Service Level Agreement (SLA)](https://aws.amazon.com/elasticache/sla/), depending on the configuration. | | Software upgrades and patching | Automatically upgrades cache software to the latest minor and patch version, without application impact. Customers receive a notification for major version upgrades, and customers can upgrade to the latest major version when they want. | Node-based clusters offer customer-enabled self-service for minor and patching version upgrades, as well as major version upgrades. Managed updates are automatically applied during customer defined maintenance windows. Customers can also choose to apply a minor or patch version upgrade on-demand. | | Global Data Store | Not supported | Supports Global Data Store, which enables cross region replication with single region writes and multi-region reads | | Data Tiering | Not supported | Clusters that are created using nodes from the r6gd family have their data tiered between memory and local SSD (solid state drives) storage. Data tiering provides a price-performance option for Valkey and Redis OSS workloads by utilizing lower-cost solid state drives (SSDs) in each cluster node, in addition to storing data in memory. | | Pricing model | Pay-per-use, based on data stored in GB-hours and requests in ElastiCache Processing Units (ECPU). See pricing details [here](https://aws.amazon.com/elasticache/pricing/). | Pay-per-hour, based on cache node usage. See pricing details [here](https://aws.amazon.com/elasticache/pricing/). | Related topics: + [Creating and managing a node-based ElastiCache clusterCreating and managing a node-based ElastiCache cluster](designing-elasticache-cluster.md) # Amazon ElastiCache resources for first time users ElastiCache resources We recommend that first time users begin by reading the following sections, and refer to them as needed. + **Service highlights and pricing** – The [product detail page](https://aws.amazon.com/elasticache/) provides a general product overview of ElastiCache, service highlights, and pricing. + **ElastiCache videos** – The [ElastiCache Videos](Tutorials.md#tutorial-videos) section has videos that introduce you to Amazon ElastiCache. The videos cover common use cases for ElastiCache and demo how to use ElastiCache to reduce latency and improve throughput for your applications. + **Getting started** – The [Getting started with Amazon ElastiCache](GettingStarted.md) section includes information on creating a cache. It also includes how to authorize access to the cache, connect to a cache node, and delete the cache. + **Performance at scale** – The [Performance at scale with Amazon ElastiCache](https://d0.awsstatic.com/whitepapers/performance-at-scale-with-amazon-elasticache.pdf) whitepaper addresses caching strategies that help your application to perform well at scale. After you complete the preceding sections, read these sections: + [Choosing your node size](CacheNodes.SelectSize.md) You want your nodes to be large enough to accommodate all the data you want to cache. At the same time, you don't want to pay for more cache than you need. You can use this topic to help select the best node size. + [ElastiCache best practices and caching strategies](BestPractices.md) Identify and address issues that can impact the efficiency of your cluster. If you want to use the AWS Command Line Interface (AWS CLI), you can use these documents to help you get started: + [AWS Command Line Interface documentation](https://docs.aws.amazon.com/cli/) This section provides information on downloading the AWS CLI, getting the AWS CLI working on your system, and providing your AWS credentials. + [AWS CLI documentation for ElastiCache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/index.html) This separate document covers all of the AWS CLI for ElastiCache commands, including syntax and examples. You can write application programs to use the ElastiCache API with a variety of popular programming languages. Here are some resources: + [Tools for Amazon Web Services](https://aws.amazon.com/tools/) Amazon Web Services provides a number of software development kits (SDKs) with support for ElastiCache. You can code for ElastiCache using Java, .NET, PHP, Ruby, and other languages. These SDKs can greatly simplify your application development by formatting your requests to ElastiCache, parsing responses, and providing retry logic and error handling. + [Using the ElastiCache API](ProgrammingGuide.md) If you don't want to use the AWS SDKs, you can interact with ElastiCache directly using the Query API. You can find troubleshooting tips and information on creating and authenticating requests and handling responses in this section. + [Amazon ElastiCache API Reference](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/) This separate document covers all of the ElastiCache API operations, including syntax and examples. # AWS Regions and Availability Zones AWS Regions and Availability Zones Amazon cloud computing resources are housed in highly available data center facilities in different areas of the world (for example, North America, Europe, or Asia). Each data center location is called an AWS Region. Each AWS Region contains multiple distinct locations called Availability Zones, or AZs. Each Availability Zone is engineered to be isolated from failures in other Availability Zones. Each is engineered to provide inexpensive, low-latency network connectivity to other Availability Zones in the same AWS Region. By launching instances in separate Availability Zones, you can protect your applications from the failure of a single location. For more information, see [Choosing regions and availability zones](RegionsAndAZs.md). You can create your cluster in several Availability Zones, an option called a Multi-AZ deployment. When you choose this option, Amazon automatically provisions and maintains a secondary standby node instance in a different Availability Zone. Your primary node instance is asynchronously replicated across Availability Zones to the secondary instance. This approach helps provide data redundancy and failover support, eliminate I/O freezes, and minimize latency spikes during system backups. For more information, see [Minimizing downtime in ElastiCache for Valkey and Redis OSS with Multi-AZ](AutoFailover.md). # Common ElastiCache Use Cases and How ElastiCache Can Help Use Cases Whether serving the latest news, a top-10 leaderboard, a product catalog, or selling tickets to an event, speed is the name of the game. The success of your website and business is greatly affected by the speed at which you deliver content. In "[For Impatient Web Users, an Eye Blink Is Just Too Long to Wait](http://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-slow-loading-sites.html?pagewanted=all&_r=0)," the New York Times noted that users can register a 250-millisecond (1/4 second) difference between competing sites. Users tend to opt out of the slower site in favor of the faster site. Tests done at Amazon, cited in [How Webpage Load Time Is Related to Visitor Loss](http://pearanalytics.com/blog/2009/how-webpage-load-time-related-to-visitor-loss/), revealed that for every 100-ms (1/10 second) increase in load time, sales decrease 1 percent. If someone wants data, you can deliver that data much faster if it's cached. That's true whether it's for a webpage or a report that drives business decisions. Can your business afford to not cache your webpages so as to deliver them with the shortest latency possible? It might seem intuitively obvious that you want to cache your most heavily requested items. But why not cache your less frequently requested items? Even the most optimized database query or remote API call is noticeably slower than retrieving a flat key from an in-memory cache. *Noticeably slower* tends to send customers elsewhere. The following examples illustrate some of the ways using ElastiCache can improve overall performance of your application. **Topics** + [ ## In-Memory Data Store ](#elasticache-use-cases-data-store) + [ ## Gaming Leaderboards ](#elasticache-for-redis-use-cases-gaming) + [ ## Messaging (Pub/Sub) ](#elasticache-for-redis-use-cases-messaging) + [ ## Recommendation Data (Hashes) ](#elasticache-for-redis-use-cases-recommendations) + [ ## Semantic caching for generative AI applications ](#elasticache-for-redis-use-cases-semantic-caching) + [ ## ElastiCache Customer Testimonials ](#elasticache-use-cases-testimonials) ## In-Memory Data Store The primary purpose of an in-memory key-value store is to provide ultrafast (submillisecond latency) and inexpensive access to copies of data. Most data stores have areas of data that are frequently accessed but seldom updated. Additionally, querying a database is always slower and more expensive than locating a key in a key-value pair cache. Some database queries are especially expensive to perform. An example is queries that involve joins across multiple tables or queries with intensive calculations. By caching such query results, you pay the price of the query only once. Then you can quickly retrieve the data multiple times without having to re-execute the query. ### What Should I Cache? When deciding what data to cache, consider these factors: **Speed and expense** – It's always slower and more expensive to get data from a database than from a cache. Some database queries are inherently slower and more expensive than others. For example, queries that perform joins on multiple tables are much slower and more expensive than simple, single table queries. If the interesting data requires a slow and expensive query to get, it's a candidate for caching. If getting the data requires a relatively quick and simple query, it might still be a candidate for caching, depending on other factors. **Data and access pattern** – Determining what to cache also involves understanding the data itself and its access patterns. For example, it doesn't make sense to cache data that changes quickly or is seldom accessed. For caching to provide a real benefit, the data should be relatively static and frequently accessed. An example is a personal profile on a social media site. On the other hand, you don't want to cache data if caching it provides no speed or cost advantage. For example, it doesn't make sense to cache webpages that return search results because the queries and results are usually unique. **Staleness** – By definition, cached data is stale data. Even if in certain circumstances it isn't stale, it should always be considered and treated as stale. To tell whether your data is a candidate for caching, determine your application's tolerance for stale data. Your application might be able to tolerate stale data in one context, but not another. For example, suppose that your site serves a publicly traded stock price. Your customers might accept some staleness with a disclaimer that prices might be *n* minutes delayed. But if you serve that stock price to a broker making a sale or purchase, you want real-time data. Consider caching your data if the following is true: + Your data is slow or expensive to get when compared to cache retrieval. + Users access your data often. + Your data stays relatively the same, or if it changes quickly staleness is not a large issue. For more information, see [Caching strategies for Memcached](Strategies.md) ## Gaming Leaderboards With Valkey or Redis OSS sorted sets you can move the computational complexity of leaderboards from your application to your cluster. Leaderboards, such as the top 10 scores for a game, are computationally complex. This is especially true when there is a large number of concurrent players and continually changing scores. Valkey and Redis OSS sorted sets guarantee both uniqueness and element ordering. With sorted sets, each time a new element is added to the sorted set it's reranked in real time. It's then added to the set in its correct numeric order. In the following diagram, you can see how an ElastiCache gaming leaderboard works. ![\[\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/images/ElastiCache-Redis-Gaming.png) **Example Valkey or Redis OSS Leaderboard** In this example, four gamers and their scores are entered into a sorted list using `ZADD`. The command `ZREVRANGEBYSCORE` lists the players by their score, high to low. Next, `ZADD` is used to update June's score by overwriting the existing entry. Finally, `ZREVRANGEBYSCORE` lists the players by their score, high to low. The list shows that June has moved up in the rankings. ``` ZADD leaderboard 132 Robert ZADD leaderboard 231 Sandra ZADD leaderboard 32 June ZADD leaderboard 381 Adam ZREVRANGEBYSCORE leaderboard +inf -inf 1) Adam 2) Sandra 3) Robert 4) June ZADD leaderboard 232 June ZREVRANGEBYSCORE leaderboard +inf -inf 1) Adam 2) June 3) Sandra 4) Robert ``` The following command tells June where she ranks among all the players. Because ranking is zero-based, *ZREVRANK* returns a 1 for June, who is in second position. ``` ZREVRANK leaderboard June 1 ``` For more information, see the [Valkey documentation](https://valkey.io/topics/sorted-sets/) about sorted sets. ## Messaging (Pub/Sub) When you send an email message, you send it to one or more specified recipients. In the Valkey and Redis OSS pub/sub paradigm, you send a message to a specific channel not knowing who, if anyone, receives it. The people who get the message are those who are subscribed to the channel. For example, suppose that you subscribe to the *news.sports.golf* channel. You and all others subscribed to the *news.sports.golf* channel get any messages published to *news.sports.golf*. Pub/sub functionality has no relation to any key space. Therefore, it doesn't interfere on any level. In the following diagram, you can find an illustration of ElastiCache messaging with Valkey and Redis OSS. ![\[\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/images/ElastiCache-Redis-PubSub.png) ### Subscribing To receive messages on a channel, you subscribe to the channel. You can subscribe to a single channel, multiple specified channels, or all channels that match a pattern. To cancel a subscription, you unsubscribe from the channel specified when you subscribed to it. Or, if you subscribed using pattern matching, you unsubscribe using the same pattern that you used before. **Example - Subscription to a Single Channel** To subscribe to a single channel, use the SUBSCRIBE command specifying the channel you want to subscribe to. In the following example, a client subscribes to the *news.sports.golf* channel. ``` SUBSCRIBE news.sports.golf ``` After a while, the client cancels their subscription to the channel using the UNSUBSCRIBE command specifying the channel to unsubscribe from. ``` UNSUBSCRIBE news.sports.golf ``` **Example - Subscriptions to Multiple Specified Channels** To subscribe to multiple specific channels, list the channels with the SUBSCRIBE command. In the following example, a client subscribes to the *news.sports.golf*, *news.sports.soccer*, and *news.sports.skiing* channels. ``` SUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing ``` To cancel a subscription to a specific channel, use the UNSUBSCRIBE command and specify the channel to unsubscribe from. ``` UNSUBSCRIBE news.sports.golf ``` To cancel subscriptions to multiple channels, use the UNSUBSCRIBE command and specify the channels to unsubscribe from. ``` UNSUBSCRIBE news.sports.golf news.sports.soccer ``` To cancel all subscriptions, use `UNSUBSCRIBE` and specify each channel. Or use `UNSUBSCRIBE` and don't specify a channel. ``` UNSUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing ``` or ``` UNSUBSCRIBE ``` **Example - Subscriptions Using Pattern Matching** Clients can subscribe to all channels that match a pattern by using the PSUBSCRIBE command. In the following example, a client subscribes to all sports channels. You don't list all the sports channels individually, as you do using `SUBSCRIBE`. Instead, with the `PSUBSCRIBE` command you use pattern matching. ``` PSUBSCRIBE news.sports.* ``` **Example Canceling Subscriptions** To cancel subscriptions to these channels, use the `PUNSUBSCRIBE` command. ``` PUNSUBSCRIBE news.sports.* ``` + The channel string sent to a [P]SUBSCRIBE command and to the [P]UNSUBSCRIBE command must match. You can't `PSUBSCRIBE` to *news.\$1* and `PUNSUBSCRIBE` from *news.sports.\$1* or `UNSUBSCRIBE` from *news.sports.golf*. + `PSUBSCRIBE` and `PUNSUBSCRIBE` are not available for ElastiCache Serverless. ### Publishing To send a message to all subscribers to a channel, use the `PUBLISH` command, specifying the channel and the message. The following example publishes the message, "It’s Saturday and sunny. I’m headed to the links." to the *news.sports.golf* channel. ``` PUBLISH news.sports.golf "It's Saturday and sunny. I'm headed to the links." ``` A client can't publish to a channel that it is subscribed to. For more information, see [Pub/Sub](https://valkey.io/topics/pubsub) in the Valkey documentation. ## Recommendation Data (Hashes) Using INCR or DECR in Valkey or Redis OSS makes compiling recommendations simple. Each time a user "likes" a product, you increment an *item:productID:like* counter. Each time a user "dislikes" a product, you increment an *item:productID:dislike* counter. Using hashes, you can also maintain a list of everyone who has liked or disliked a product. **Example - Likes and Dislikes** ``` INCR item:38923:likes HSET item:38923:ratings Susan 1 INCR item:38923:dislikes HSET item:38923:ratings Tommy -1 ``` ## Semantic caching for generative AI applications Operating generative AI applications at scale can be challenging due to the cost and latency associated with inference calls to large language models (LLMs). You can use ElastiCache for semantic caching in generative AI applications, allowing you to reduce the cost and latency of LLM inference calls. With semantic caching, you can return a cached response by using vector-based matching to find similarities between current and prior prompts. If a user’s prompt is semantically similar to a prior prompt, a cached response will be returned instead of making a new LLM inference call, reducing the cost of generative AI applications and providing faster responses that improve the user experience. You can control which queries are routed to the cache by configuring similarity thresholds for prompts and applying tag or numeric metadata filters. The inline real-time index updates provided by vector search for ElastiCache help ensure that the cache updates continuously as user prompts and LLM responses flow in. This real-time indexing is crucial to maintain freshness of cached results and cache hit rates, particularly for spiky traffic. In addition, ElastiCache simplifies operations for semantic caching through mature cache primitives such as per-key TTLs, configurable eviction strategies, atomic operations, and rich data structure and scripting support. **Memory for generative AI assistants and agents** You can use ElastiCache to deliver more personalized, context-aware responses by implementing memory mechanisms that surface cross-session conversation history to LLMs. Conversational memory allows generative AI assistants and agents to retain and use past interactions to personalize responses and improve relevancy. However, simply aggregating all prior interactions into the prompt is ineffective since irrelevant extra tokens increase cost, degrade response quality and risk exceeding the LLM’s context window. Instead, you can use vector search to retrieve and provide only the most relevant data in the context for each LLM invocation. ElastiCache for Valkey provides integrations with open-source memory layers, providing built-in connectors to store and retrieve memories for LLM applications and agents. Vector search for ElastiCache provides fast index updates, keeping memory up to date and making new memories immediately searchable. Low latency vector search makes memory lookups fast, enabling them to be implemented in the online path of every request, not just background tasks. Beyond vector search, ElastiCache for Valkey also provides caching primitives for session state, user preferences, and feature flags, providing a single service to store short-lived session state and long-term “memories” in one datastore. **Retrieval augmented generation (RAG)** RAG is the process of providing LLMs with up-to-date information in the prompt to improve the relevance of responses. RAG reduces hallucinations and improves factual accuracy by grounding outputs with real-world data sources. RAG applications use vector search to retrieve semantically relevant content from a knowledge base. Low latency vector search provided by ElastiCache makes it suitable for implementing RAG in workloads that have large datasets with millions of vectors and above. Further, support for online vector index updates makes ElastiCache suitable for assistants with upload workflows that need to ensure any uploaded data is immediately searchable. RAG in agentic AI systems ensures that agents have up-to-date information for accurate actions. Low latency vector search is also crucial for RAG in agentic AI systems where a single query can trigger multiple LLM calls and stack up latency from underlying vector search. The following diagram illustrates an example architecture using ElastiCache to implement a semantic cache, memory mechanisms, and RAG to enhance a generative AI application in production. ![\[Diagram of a semantic search as performed by a generative AI assistant.\]](http://docs.aws.amazon.com/AmazonElastiCache/latest/dg/images/vector-search-gen-ai1.png) **Semantic Search** Vector search retrieves the most relevant text, speech, image, or video data based on closeness in meaning or features. This capability enables machine learning applications that rely on similarity search across diverse data modalities, including recommendation engines, anomaly detection, personalization, and knowledge management systems. Recommendation systems use vector representations to capture complex patterns in user behavior and item characteristics, enabling them to suggest the most relevant content. Vector search for ElastiCache is well suited for these applications because of its near real-time updates and low latency, enabling similarity comparisons that deliver instant, highly relevant recommendations based on live user interactions. ## ElastiCache Customer Testimonials To learn about how businesses like Airbnb, PBS, Esri, and others use Amazon ElastiCache to grow their businesses with improved customer experience, see [How Others Use Amazon ElastiCache](https://aws.amazon.com/elasticache/testimonials/). You can also watch the [Tutorial videos](Tutorials.md#tutorial-videos) for additional ElastiCache customer use cases.