Amazon ElastiCache FAQs

Amazon ElastiCache is a serverless caching service that streamlines deployment, operation, and running of Valkey, Memcached, or Redis OSS caches in the cloud. ElastiCache improves application performance by serving data from RAM instead of slower disk-based databases, delivering microsecond latency with up to 99.99% availability SLA. The service offloads time-consuming tasks like management, monitoring, and operation of caches, enabling your engineering resources to focus on developing applications. Since it is fully compatible with Valkey, Memcached, and Redis OSS, all the code, applications, and popular tools you use today will work with the service. There are no upfront investments required, and you pay only for the resources you use. To get started, see the Amazon ElastiCache documentation.

The caching provided by ElastiCache can be used to 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). Caching improves application performance by storing critical pieces of data in memory for low-latency access. Cached information can include the results of I/O-intensive database queries or the results of computationally intensive calculations.

ElastiCache offers two deployment options: serverless and node-based. With serverless, you get zero infrastructure management, zero downtime maintenance, and instant scaling to any application demand. With node based, you can select specific node types and sizes, giving you fine-grained control over configuration and resource allocation. This option is for users with fixed capacity needs and specific node type requirements.

As a fully managed service, ElastiCache handles complex, time-consuming administrative tasks, so your team can focus on building and optimizing your application. It removes the undifferentiated heavy lifting of caching administrative tasks such as hardware provisioning, software patching, monitoring, and backup and recovery. ElastiCache publishes detailed CloudWatch metrics so you can set alarms for overloaded caches and respond quickly to issues. With ElastiCache Serverless, you don’t have to worry about the underlying infrastructure. It provides a hands-off experience with no disruptions during maintenance and instant scaling capacity when traffic spikes.

ElastiCache works as a front-end caching layer for AWS services like Amazon RDS, Amazon Aurora, Amazon DocumentDB, and Amazon DynamoDB, reducing database load and delivering microsecond read latency. The service can also be used to improve application performance in conjunction with Amazon EC2 and Amazon EMR.

ElastiCache pricing depends on your deployment model. ElastiCache Serverless bills per GB of data stored and per ECPU consumed by your application — with no node-hour charges. Node-based ElastiCache bills per node-hour at rates that vary by instance type, with optional Reserved Node discounts for 1- or 3-year commitments. Cross-Region data transfer for Global Datastore and S3 storage for backups beyond the free tier are billed separately. See the ElastiCache pricing page for current rates.

You don't need to get the number of nodes exactly right with ElastiCache, as you can quickly add or remove nodes later. You can also use ElastiCache Serverless to simplify running a highly available cache. There are two inter-related aspects to be considered for the choice of your initial configuration. First, the total memory required for your data to achieve your target cache-hit rate. Second, the number of nodes required to maintain acceptable application performance without overloading the database backend in the event of node failures.

For example, if your memory requirement is 13 GB, two cache.m7g.large nodes provide better fault tolerance than a single cache.m7g.xlarge. See the ElastiCache node sizing guidance for details.

Yes, when you create a cluster or add nodes, you can distribute nodes across multiple Availability Zones either by specifying the node counts in each AZ or select Spread Nodes Across Zones. If the cluster is in Amazon VPC, nodes can only be placed in AZs included in your cache subnet group. For additional details, refer to networking details.

ElastiCache provides microsecond latency and scales to over billions of operations per second across hundreds of thousands of customers allowing you to handle more concurrent end users without needing to overprovision your data infrastructure thereby reducing costs. For example, paring ElastiCache with RDS for MySQL saves you up to 55% in costs while providing up to 80x faster read performance (versus RDS for MySQL alone). As traffic fluctuates, ElastiCache scales to hundreds of terabytes of data and billions operations per second; with ElastiCache for Valkey you can reach up to 310 TiB of data in a single cluster, or 982 TiB with data tiering. ElastiCache also supports semantic caching, which stores and retrieves responses based on meaning rather than exact key matches reducing the cost and latency of AI workloads that would otherwise make redundant calls to large language models.

AWS Availability Zones within the same Region are engineered for low latency network connectivity to other AZs in the same Region, so cross-AZ failover introduces negligible additional cache latency. For optimal performance, architect your application tier with redundancy across the same AZs as your ElastiCache nodes so failover does not leave compute and cache in separate zones. Review AWS Region and AZ architecture guidance when designing for availability.

ElastiCache Serverless is the most automated deployment option for Amazon ElastiCache. It offers zero infrastructure management, zero downtime maintenance, instant scaling to any application demand, and pay-for-use billing. It eases deployment and operation of a cache removing the need for time-consuming capacity planning by continuously monitoring a cache’s compute, memory, and network utilization. Each serverless cache runs in or across multiple Availability Zones (AZs) and provides a 99.99% availability service level agreement (SLA). ElastiCache Serverless supports ElastiCache version 7.2 and above for Valkey, ElastiCache version 1.4.5 and above for Memcached, and ElastiCache versions 4.0.10 to 7.1 for Redis OSS. You only pay for the data you store and the compute resources your application uses with ElastiCache Serverless. Visit the ElastiCache pricing page to learn more.

You can move an existing ElastiCache workload by changing the Valkey, Memcached, or Redis OSS endpoint to your new ElastiCache Serverless cache endpoint in your application. You can migrate existing ElastiCache data to ElastiCache Serverless by specifying the Amazon Simple Storage Service (Amazon S3) location of a backup file. Visit our ElastiCache documentation to learn more about migrating your workloads.

ElastiCache Serverless continuously monitors your cache’s memory, compute, and network utilization to instantly scale. It scales without downtime or performance degradation to the application by allowing the cache to scale up and initiating scale-out in parallel, to meet application requirements just in time. Visit our ElastiCache Serverless documentation to learn more about scaling.

For node-based clusters, you can scale horizontally by adding shards or nodes, or vertically by changing to a larger instance type. Valkey and Redis OSS clusters support online resharding and online vertical scaling using read replicas, so you do not need to take the cluster offline. Memcached clusters support horizontal scaling by adding nodes and vertical scaling by changing the node type. See the ElastiCache scaling node-based clusters documentation for detailed procedures.

Durability is a feature that allows you to use ElastiCache as a persistent data store with microsecond read latency. It provides data protection through a Multi-AZ transactional log, enabling fast recovery and restart during the rare event of a failure. ElastiCache offers two durability options: synchronous writes designed for zero data loss with single-digit millisecond write latency, and asynchronous writes for microsecond write latency at no additional cost. Both options provide microsecond read latency.

With durability, you can use ElastiCache for a broader set of use cases beyond caching where data loss is not acceptable, such as knowledge bases for RAG applications, AI agent long-term memory, AI agent workflow state, payment tokenization, streaming metadata, gaming leaderboards and player state, and real-time inventory management.

With synchronous writes, data is persisted across at least two Availability Zones in the Multi-AZ transactional log before responding to the client. This is designed for zero data loss at single-digit millisecond write latency and microsecond read latency. Synchronous writes is ideal if your application cannot tolerate any data loss.

With asynchronous writes, data is persisted in the Multi-AZ transactional log after responding to the client, maintaining microsecond write latency and microsecond read latency. Your data loss is bounded to up to 10 seconds in the rare event of a failure. Asynchronous writes is ideal for most workloads that prioritize write performance.

There is no additional cost for asynchronous writes beyond standard node-hour pricing. There is an additional cost for synchronous writes. You can learn more on the ElastiCache pricing page.

ElastiCache uses a Multi-AZ transactional log to durably store data across multiple AZs whether you choose synchronous or asynchronous writes. In contrast, Valkey and Redis OSS include an optional append-only file (AOF) feature, which persists data in a file on a node's local disk in a single AZ. Even when AOF is enabled on replica nodes, replication between primary and replicas remains asynchronous, which can result in unbounded data loss and consistency issues during failover.

Running a node as a read replica creates a live, read-only copy of a primary instance and keep them synchronized through replication. This allows you to offload read-heavy workloads from the primary server. When you run a cache with a read replica, the primary serves writes and reads. The replica serves exclusively read traffic and is also available as a warm standby if the primary becomes impaired. ElastiCache allows you to create up to five read replicas for a given primary cache node. Read replicas are only available for Valkey and Redis OSS engines, not Memcached.

With ElastiCache Serverless, read replicas are automatically maintained by the service. For node-based deployments, there are a variety of scenarios where deploying one or more read replicas for a given primary node might make sense. Common reasons for deploying a read replica include:

· Scaling beyond the compute or network capacity of a single primary node for read-heavy workloads: This excess read traffic can be directed to one or more read replicas.

· Serving read traffic while the primary is unavailable: If your primary node cannot take network requests (for example, scheduled maintenance), you can direct read traffic to your read replicas. For this use case, keep in mind that the data on the read replica might be stale, since the primary instance is unavailable. The read replica can also be used warmed up to restart a failed primary.

· Data protection scenarios: In the unlikely event of primary node failure or that the AZ in which your primary node resides becomes unavailable, you can promote a read replica in a different AZ to become the new primary.

No, your read replica can only be provisioned in any AZ within the same Region as your primary cache node. You can, however, use the Global Datastore to work with fully managed, fast, reliable, and security-focused replication across AWS Regions. Using this feature, you can create cross-Region read replica clusters for ElastiCache to enable low-latency reads and disaster recovery across AWS Regions.

When failing over, ElastiCache flips the DNS record for your cache node to point at the read replica, which is in turn promoted to become the new primary. A new healthy node joins the cluster within six minutes. The node synchronization time varies based on the cluster's workload and size, which impacts the completion time. For Global Datastore cross-Region failovers, promotion can complete in under one minute.

Backup and Restore is a feature for ElastiCache that creates snapshots of your ElastiCache cache and stores them in an Amazon S3 bucket in the same Region as your cache for restoring caches. This is currently supported with ElastiCache for Valkey, ElastiCache for Redis OSS, and ElastiCache Serverless for Memcached. When a backup is initiated, ElastiCache will take a snapshot of a specified cache that can later be used for recovery or archiving. You can initiate a backup any time you choose or set a recurring daily backup with retention period of up to 35 days. When you choose a snapshot to restore, a new ElastiCache cache will be created and populated with the snapshot’s data. ElastiCache snapshots are compatible with the Redis OSS RDB file format. ElastiCache provides one free snapshot for each active ElastiCache cache. Additional storage will be charged based on the space used by the snapshots, starting at $0.085/GiB every month for all AWS Regions. Data transfer for using the snapshots is free of charge. You can use the Backup and Restore feature through the AWS Management Console, ElastiCache APIs, and AWS CLI. You can deactivate and reactivate the feature at any time.

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.

When you delete an ElastiCache cache your manual snapshots are retained. You will also have an option to create a final snapshot before the cache is deleted. Automatic cache snapshots are not retained.

Yes, ElastiCache for Valkey can restore backups from any version of ElastiCache for Redis OSS, because both engines use the Redis RDB file format. This enables seamless migration from Redis OSS to Valkey without re-ingesting data. Create the backup in your Redis OSS cache, then choose it as the seed when creating a new Valkey cache. See the ElastiCache backup and restore documentation for the procedure.

Global Datastore is a feature of node-based ElastiCache that provides fully managed, fast, reliable and security-focused cross-Region replication. With Global Datastore, you can write to your cache in one Region and have the data available for read in up to two other cross-Region replica clusters, thereby enabling low-latency reads and disaster recovery across Regions.Global Datastore replicates data across Regions in under one second, increasing the responsiveness of your applications by providing geolocal reads closer to end users. In the unlikely event of Regional degradation, one of the healthy cross-Region replica caches can be promoted to become the primary with full read and write capabilities. Once initiated, the promotion typically completes in less than a minute, allowing your applications to remain available. Global Datastore is supported on ElastiCache version 7.2 onward for Valkey and ElastiCache version 5.0.6 onward for Redis OSS. ElastiCache for Memcached does not offer Global Datastore.ElastiCache does not charge any premium to use Global Datastore. You pay for the primary and secondary caches in your Global Datastore and for the cross-Region data transfer traffic.

You can replicate to up to two secondary Regions within a Global Datastore. The caches in secondary Regions can be used to serve low-latency local reads and for disaster recovery in the unlikely event of Regional degradation.

No, you can manually initiate the failover by promoting a secondary cluster to become a primary. The failover and promotion of a secondary cluster typically completes in less than one minute.

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 a primary Region is available in secondary Regions within one second. The RTO of Global Datastore is typically under a minute. Once a failover to a secondary cluster is initiated, ElastiCache typically promotes the secondary to full read and write capabilities in under a minute.

Global Datastore uses encryption in transit for cross-Region traffic to keep your data more secure. Additionally, you can also encrypt your primary and secondary caches using encryption at rest to keep your data better secured. Each primary and secondary cache can have a separate customer-managed AWS KMS key for encryption at rest.

Multi-AZ is a high-availability configuration for ElastiCache that replicates data across multiple Availability Zones and provides automatic failover if a primary node fails. ElastiCache will fail over to a read replica in the event of any loss of availability in primary’s AZ, a loss of network connectivity to the primary, or a compute unit failure on the primary. All ElastiCache Serverless caches run Multi-AZ. An ElastiCache replication group consists of a primary and up to five read replicas. If Multi-AZ is enabled, then at least one replica is required per primary. During certain types of planned maintenance, or in the unlikely event of an ElastiCache node failure or AZ failure, ElastiCache will automatically detect the failure of a primary, select a read replica, and promote it to become the new primary. ElastiCache also propagates the DNS changes of the promoted Read Replica, so if your application is writing to the primary node endpoint, no endpoint change will be needed. The node's DNS endpoint is preserved, so applications using the endpoint don't need reconnection logic changes. If you've associated an SNS topic with your cluster, ElastiCache sends a notification when recovery completes. Multi-AZ is offered in ElastiCache for Valkey and ElastiCache for Redis OSS. Memcached does not support replication or failover natively so Multi-AZ is not offered in ElastiCache for Memcached. For more details on how to handle node failures, visit understanding replication.

The main benefits of running your ElastiCache in Multi-AZ mode are enhanced availability and less need for administration. When running ElastiCache in a Multi-AZ configuration for node-based Redis OSS and Valkey deployments, your caches are eligible for the 99.99% availability SLA. If an ElastiCache primary node failure occurs, the impact on your ability to read and write to the primary is limited to the time it takes for automatic failover to complete. When Multi-AZ is enabled, ElastiCache node failover is automatic and requires no administration.

ElastiCache provides defense in depth across four layers: encryption at rest with AWS Key Management Service (AWS KMS), encryption in transit using Transport Layer Security (TLS), authentication with AWS Identity and Access Management (IAM), and network access control with Amazon Elastic Compute Cloud (Amazon EC2) security groups. Encryption features carry no additional cost. You can enable Role-Based Access Control (RBAC) to grant fine-grained permissions to different application users within the same cache. See the ElastiCache security documentation for configuration steps.

ElastiCache allows you to control network access to your caches at two layers: network and identity. At the network layers, VPC security groups and network ACLs act as firewalls controlling network access to your cache. Network access to your caches is turned off by default. You must explicitly enable access from hosts in specific Amazon EC2 security groups. At the identity layer, IAM authentication and Valkey or Redis OSS RBAC control which users and roles can connect, and which commands they can execute. For more information, see the authenticating with IAM documentation.

ElastiCache supports compliance programs such as SOC 1, SOC 2, SOC 3, ISO, MTCS, C5, PCI DSS, HIPAA, and FedRAMP. There is no additional cost for using compliance features. To process protected health information (PHI), you must have an executed Business Associate Agreement (BAA) with AWS. If you have an executed Business Associate Agreement (BAA) with AWS, you can use ElastiCache to build applications that store and process PHI under HIPAA. If you do not have a BAA in place or have other questions about configuring these technical safeguards you can contact AWS for more detailed guidance. See AWS Services in Scope by Compliance Program for a current list of supported programs.

The encryption-at-rest feature for ElastiCache protects data from unauthorized access during disk sync, backup, swap operations, and backups stored in Amazon S3-snapshots. ElastiCache offers default (service-managed) encryption at rest, as well as the ability to use your own symmetric customer-managed AWS KMS keys in AWS KMS. Visit at-rest encryption to learn more.

The encryption-in-transit feature for ElastiCache uses Transport Layer Security (TLS) to protect data between clients and ElastiCache, and between the servers (primary and read replicas) within a cluster. ElastiCache manages TLS certificate issuance and renewal automatically — no operator action is required. Visit ElastiCache in-transit encryption to learn more.

Data tiering in node-based ElastiCache is a price-performance option using lower-cost NVMe solid state drives (SSDs) in each cluster node in addition to storing data in memory. It is ideal for workloads that regularly access up to 20% of their overall dataset and can tolerate additional latency when accessing data on SSD. Data tiering runs on clusters using R6gd nodes and SSDs, which have nearly 5x more total storage capacity and can help you achieve over 60% savings in price. Data tiering is supported for ElastiCache versions 7.2 and above for Valkey and ElastiCache versions 6.2 and above for Redis OSS, but not ElastiCache for Memcached. There are no additional costs beyond the node’s hourly cost and on-demand and reserved nodes pricing apply. For current pricing, see the ElastiCache pricing page. 

Data tiering automatically and transparently moves the least recently used items from memory to locally attached NVMe SSDs when available memory capacity is completely consumed. When an item that moves to SSD is accessed, ElastiCache asynchronously moves it back to memory before serving the request, keeping hot data in RAM and cold data on disk. For configuration details and unsupported features, see the data tiering documentation.

Data tiering is designed to have minimal impact on application performance. Assuming 500-byte string values, you can expect an additional 300µs latency on average for requests to data stored on SSD compared to requests to data in memory. Requests for items already in memory see no latency penalty. Because ElastiCache promotes hot items back to RAM automatically, steady-state latency typically stabilizes near in-memory levels for workloads touching ≤20% of the dataset frequently.

All Valkey and Redis OSS commands are supported with data tiering, and most ElastiCache features work without modification. A small number of features have compatibility limitations on data-tiered clusters. For the current list of unsupported features, see the data tiering documentation.

ElastiCache reserved nodes or Reserved Instances (RIs) are a pricing option that gives you a significant discount over on-demand usage in exchange for a one- or three-year reservation to run your cache in a specific Region. There are three reserved node types – All Upfront, No Upfront, and Partial Upfront – that allow you to balance the amount you pay upfront with your effective hourly price. You can purchase up to 300 reserved nodes in the same Region. If you wish to run more than 300, request a quota increase. ElastiCache Serverless is not compatible with reserved nodes. For current pricing, see the ElastiCache pricing page.

Your Redis OSS reservations automatically apply to Valkey nodes in the same instance family and Region if you upgrade your cache from Redis OSS to Valkey. Since Valkey is priced 20% lower than Redis OSS, if you have an existing Redis OSS reserved node, you can upgrade your cache to the Valkey engine and continue receiving your reservation benefits with 20% more value. For example, if you purchased a reservation for 5 cache.r7g.2xlarge nodes for the Redis OSS engine, then when you upgrade your nodes to the Valkey engine, you can create a sixth cache.r7g.2xlarge node (20% more than 5 nodes) in the same Region at no additional cost.

Yes, ElastiCache reserved nodes offer size flexibility within an instance family (or node family) and AWS Region. This means that your existing discounted reserved node rate will be applied automatically to usage of all sizes in the same node family.

ElastiCache for Valkey gives you a fully managed experience built on open source Valkey, backed by AWS security, operational excellence, and a 99.99% availability SLA. You can further optimize costs on ElastiCache Serverless for Valkey with 33% reduced pricing and a minimum data storage of 100 MB, which is 90% lower than ElastiCache Serverless for Redis OSS. On node-based ElastiCache for Valkey, you can benefit from 20% lower cost per node. Valkey is governed by the Linux Foundation, so you avoid vendor lock-in. You also gain faster scaling and 20% more memory efficiency versus Redis OSS.

ElastiCache for Valkey differs from ElastiCache for Redis OSS in three ways. First, ElastiCache for Valkey delivers faster scaling and 20% more memory efficiency. Second, ElastiCache for Valkey is priced up to 33% lower (Serverless) and 20% lower (node-based). Third, ElastiCache for Valkey uses Valkey, the open source project under the Linux Foundation, which avoids vendor lock-in.

You can upgrade your existing Redis OSS cluster to ElastiCache for Valkey in-place without downtime, and in just a few clicks. You can upgrade from any version of Redis OSS supported on ElastiCache to any version of ElastiCache for Valkey. If you upgrade from Redis OSS versions earlier than 5.0.6, it requires DNS propagation that may experience a failover time of 30 to 60 seconds. For the step-by-step guide, see the engine upgrade documentation; for a full change list, see the ElastiCache version documentation.

After upgrading to ElastiCache version 7.2 for Valkey, you can perform a roll back to ElastiCache version 7.1 for Redis OSS the same way you upgraded—using the AWS Management Console, API, or CloudFormation and AWS CDK. The rollback process preserves your data. For complete instructions, see the ElastiCache User Guide.

You have two options for migrating from self-managed Valkey or Redis OSS on Amazon EC2 to ElastiCache. First, use the online migration capability to replicate data into ElastiCache with minimal disruption — see online migration docs. Second, take a snapshot (RDB) of your self-managed cluster and restore it into ElastiCache for Valkey. Choose online migration when you need continuous replication; choose snapshot restore for simpler, point-in-time migrations.

Yes, your ElastiCache for Redis OSS reserved node discounts apply to ElastiCache for Valkey nodes in the same instance family and Region, and size flexibility extends the discount across all sizes in that family. As Valkey is priced 20% lower, your reservation covers 25% more Valkey capacity than it did for Redis OSS. For worked scenarios, see the reserved node flexibility blog.

ElastiCache is fully compatible with Memcached, which makes migration straightforward. You can use standard Memcached operations like get, set, incr, and decr in the same way as you would in your existing Memcached deployments. ElastiCache supports both the text and binary protocols. To migrate, you should update your application’s Memcached configuration file to include the endpoints of nodes that ElastiCache provisions for you. You can retrieve these endpoints using the Copy Node Endpoints option in the AWS Management Console or the DescribeCacheClusters API.

To simplify ongoing node management, use Auto Discovery. Auto Discovery is a feature in ElastiCache for Memcached that enables automatic discovery of cache nodes by clients when they are added to or removed from an ElastiCache cluster. Each ElastiCache for Memcached cluster has a unique configuration endpoint. When your client connects to this endpoint, ElastiCache returns the current endpoints for all nodes in the cluster. If you add or remove nodes, or if a node is replaced after a failure, an Auto Discovery–capable client detects the change automatically, no application restart or manual endpoint update is required. Auto Discovery clients for .NET, Java, and PHP are available for download from the ElastiCache console. You can also build Auto Discovery support into any Memcached client library by implementing the Auto Discovery command set.

You can access ElastiCache clusters in an Amazon VPC from Amazon EC2 network or from your own data center. For VPC access patterns and DNS behavior details, refer to the ElastiCache documentation. As with any migration, we recommend thorough testing of your new ElastiCache deployment before completing the cutover from your current solution.

Yes, ElastiCache does not apply major or minor engine upgrades automatically so you can control Memcached version upgrades. You choose the engine version at cluster creation and modify it later through the ElastiCache console, AWS CLI, or API. Security patches may be applied during your configured maintenance window. This gives you full control to validate new versions in a test environment before upgrading production.

You can specify any currently supported version (minor 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. Specify the version you wish to upgrade to in 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.

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

Yes, ElastiCache will continue to support previous versions of Redis OSS, including ElastiCache version 7.1 for Redis OSS. Over time, older versions of all engines (including Valkey, Memcached, and Redis OSS) will be deprecated following a standard end-of-life process, with advance notice. For current supported versions, see the ElastiCache version documentation.