Redis Ug
Redis Ug
User Guide
API Version 2015-02-02
Amazon ElastiCache for Redis User Guide
Amazon's trademarks and trade dress may not be used in connection with any product or service that is not
Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or
discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may
or may not be affiliated with, connected to, or sponsored by Amazon.
Amazon ElastiCache for Redis User Guide
Table of Contents
Comparing Memcached and Redis ........................................................................................................ 1
What is ElastiCache for Redis? ............................................................................................................. 5
Overview of ElastiCache for Redis ................................................................................................ 5
Overview of ElastiCache for Redis ................................................................................................ 6
Overview of AWS Regions and Availability Zones ........................................................................... 6
Security .................................................................................................................................... 7
Monitoring ................................................................................................................................ 7
ElastiCache resources .................................................................................................................. 8
Components and features ......................................................................................................... 10
Nodes ............................................................................................................................. 10
ElastiCache for Redis shards .............................................................................................. 10
ElastiCache for Redis clusters ............................................................................................. 11
ElastiCache for Redis replication ......................................................................................... 12
AWS Regions and availability zones .................................................................................... 29
ElastiCache for Redis endpoints ......................................................................................... 29
Parameter groups ............................................................................................................. 30
ElastiCache for Redis security ............................................................................................. 30
Security groups ................................................................................................................ 30
Subnet groups ................................................................................................................. 31
ElastiCache for Redis backups ............................................................................................ 31
Events ............................................................................................................................. 31
ElastiCache for Redis terminology .............................................................................................. 32
Tools for managing your implementation .................................................................................... 34
Using the AWS Management Console ................................................................................. 34
Using the AWS CLI ........................................................................................................... 34
Using the AWS SDK .......................................................................................................... 34
Using the ElastiCache API .................................................................................................. 34
Additional resources ......................................................................................................... 34
Common ElastiCache Use Cases and How ElastiCache Can Help ...................................................... 35
In-Memory Data Store ...................................................................................................... 35
Gaming Leaderboards (Redis Sorted Sets) ............................................................................ 36
Messaging (Redis Pub/Sub) ................................................................................................ 37
Recommendation Data (Redis Hashes) ................................................................................. 39
Other Redis Uses .............................................................................................................. 40
ElastiCache Customer Testimonials ..................................................................................... 40
Getting started with ElastiCache for Redis ........................................................................................... 41
Setting up ............................................................................................................................... 41
Create your AWS account .................................................................................................. 41
Getting an AWS Access Key ............................................................................................... 42
Configuring Your Credentials ............................................................................................. 42
Downloading and Configuring the AWS CLI ......................................................................... 43
Set up your permissions (new ElastiCache users only) ............................................................ 43
Step 1: Create a subnet group ................................................................................................... 44
Step 2: Create a cluster ............................................................................................................. 46
Creating a Redis (cluster mode disabled) cluster (Console) ..................................................... 47
Step 3: Authorize access to the cluster ........................................................................................ 52
Step 4: Connect to the cluster's node ......................................................................................... 54
Find your node endpoints ................................................................................................. 54
Step 5: Deleting a cluster .......................................................................................................... 61
Tutorials and videos ................................................................................................................. 62
Videos ............................................................................................................................. 63
Where do I go from here? ......................................................................................................... 66
Getting Started with ElastiCache and AWS SDKs .................................................................................. 68
Python and ElastiCache ............................................................................................................. 68
IAM Permissions Required for ElastiCache for Redis Auto Scaling .......................................... 397
Service-linked role .......................................................................................................... 398
Auto Scaling Best Practices .............................................................................................. 398
Using Auto Scaling with shards ........................................................................................ 399
Using Auto Scaling with replicas ....................................................................................... 412
Configuring engine parameters using parameter groups .............................................................. 423
Parameter management .................................................................................................. 424
Parameter group tiers ..................................................................................................... 425
Creating a parameter group ............................................................................................. 425
Listing parameter groups by name ................................................................................... 429
Listing a parameter group's values .................................................................................... 434
Modifying a parameter group .......................................................................................... 435
Deleting a parameter group ............................................................................................. 439
Redis-specific parameters ................................................................................................ 441
Security ......................................................................................................................................... 469
Data protection ...................................................................................................................... 469
Data security in Amazon ElastiCache ................................................................................. 470
Internetwork traffic privacy ...................................................................................................... 501
Amazon VPCs and ElastiCache security .............................................................................. 502
Amazon ElastiCache API and interface VPC endpoints (AWS PrivateLink) ................................ 521
Subnets and subnet groups ............................................................................................. 523
Security groups: EC2-Classic ............................................................................................. 532
Identity and access management .............................................................................................. 538
Authentication ............................................................................................................... 539
Access control ................................................................................................................ 539
Overview of managing access .......................................................................................... 541
Logging and monitoring in Elasticache ...................................................................................... 577
Log delivery ................................................................................................................... 578
Monitoring use ............................................................................................................... 587
Logging Amazon ElastiCache API calls with AWS CloudTrail .................................................. 603
Monitoring events .......................................................................................................... 606
Compliance validation ............................................................................................................. 617
ElastiCache for Redis compliance ...................................................................................... 618
Resilience .............................................................................................................................. 621
Mitigating Failures .......................................................................................................... 622
Infrastructure security ............................................................................................................. 624
Self-service updates ................................................................................................................ 625
Managing the service updates .......................................................................................... 625
Troubleshooting ..................................................................................................................... 634
Security groups .............................................................................................................. 634
Network ACLs ................................................................................................................ 634
Route tables .................................................................................................................. 636
DNS resolution ............................................................................................................... 636
Identifying issues with server-side diagnostics .................................................................... 636
Network connectivity validation ....................................................................................... 640
Network-related limits .................................................................................................... 641
CPU Usage ..................................................................................................................... 642
Connections being terminated from the server side ............................................................ 644
Client-side troubleshooting for Amazon EC2 instances ......................................................... 645
Dissecting the time taken to complete a single request ....................................................... 645
Quotas .......................................................................................................................................... 648
Reference ...................................................................................................................................... 649
Using the ElastiCache API ........................................................................................................ 649
Using the query API ........................................................................................................ 649
Available libraries ........................................................................................................... 651
Troubleshooting applications ........................................................................................... 652
Set up the AWS CLI for ElastiCache .......................................................................................... 652
On the surface, the engines look similar. Each of them is an in-memory key-value store. However, in
practice there are significant differences.
Choose Redis with a version of ElastiCache for Redis if the following apply for you:
You want the ability to tier data between memory and SSD using the r6gd node type. For more
information, see Data tiering.
• ElastiCache for Redis version 6.0 (Enhanced)
You want to use Redis streams, a log data structure that allows producers to append new items in real
time and also allows consumers to consume messages either in a blocking or non-blocking fashion.
Supports both encryption and dynamically adding or removing shards from your Redis (cluster mode
enabled) cluster.
Supports the ability to dynamically add or remove shards from your Redis (cluster mode enabled)
cluster.
Important
Currently ElastiCache for Redis 3.2.10 doesn't support encryption.
If you need the functionality of earlier Redis versions plus the following features, choose ElastiCache
for Redis 3.2.6:
• In-transit encryption. For more information, see Amazon ElastiCache for Redis In-Transit Encryption.
• At-rest encryption. For more information, see Amazon ElastiCache for Redis At-Rest Encryption.
• HIPAA eligibility certification. For more information, see HIPAA Eligibility for Amazon ElastiCache for
Redis.
If you need the functionality of Redis 2.8.x plus the following features, choose Redis 3.2.4 (clustered
mode):
• You need to partition your data across two to 500 node groups (clustered mode only).
• You need geospatial indexing (clustered mode or non-clustered mode).
• You don't need to support multiple databases.
• ElastiCache for Redis (non-clustered mode) 2.8.x and 3.2.4 (Enhanced)
If the following apply for you, choose Redis 2.8.x or Redis 3.2.4 (non-clustered mode):
• You need complex data types, such as strings, hashes, lists, sets, sorted sets, and bitmaps.
• You need to sort or rank in-memory datasets.
• You need persistence of your key store.
• You need to replicate your data from the primary to one or more read replicas for read intensive
applications.
• You need automatic failover if your primary node fails.
• You need publish and subscribe (pub/sub) capabilities—to inform clients about events on the server.
• You need backup and restore capabilities.
• You need to support multiple databases.
Comparison summary of Memcached, Redis (cluster mode disabled), and Redis (cluster mode
enabled)
Compliance certifications
Compliance
Certification
No 3.2.6, 4.0.10 and later 3.2.6, 4.0.10 and later
FedRAMP
No 3.2.6, 4.0.10 and later 3.2.6, 4.0.10 and later
HIPAA
No 3.2.6, 4.0.10 and later 3.2.6, 4.0.10 and later
PCI DSS
Multi-threaded Yes No No
Notes:
string, sets, sorted sets, lists, hashes, bitmaps, hyperloglog, geospatial indexes
After you choose the engine for your cluster, we recommend that you use the most recent version of
that engine. For more information, see Supported ElastiCache for Memcached Versions or Supported
ElastiCache for Redis Versions.
ElastiCache for Redis has multiple features that help make the service more reliable for critical
production deployments:
that access up to 20 percent of their overall dataset regularly, and for applications that can tolerate
additional latency when accessing data on SSD. For more information, see Data tiering (p. 121).
Clusters
The basic building block of ElastiCache for Redis is the cluster. A cluster is a collection of one or more
cache nodes, all of which run an instance of the Redis cache engine software. When you create a cluster,
you specify the engine and version for all of the nodes to use. Your ElastiCache for Redis instances are
designed to be accessed through an Amazon EC2 instance. You can create and modify a cluster by using
the AWS CLI, the ElastiCache for Redis API, or the AWS Management Console.
Each ElastiCache for Redis cluster runs a Redis engine version. Each Redis engine version has its own
supported features. Additionally, each Redis engine version has a set of parameters in a parameter group
that control the behavior of the clusters that it manages.
The computation and memory capacity of a cluster is determined by its instance, or node, class. You can
select the node type that best meets your needs. If your needs change over time, you can change node
types. For information, see Supported node types.
You can also leverage data-tiering when considering your node type needs. Data tiering is a feature
where some least frequently used data is stored on disk to mitigate against memory limitations on
applications that can tolerate additional latency when data on SSD (solid state drives) is accessed.
Note
For pricing information on ElastiCache instance classes, see Amazon ElastiCache pricing.
Cluster node storage comes in two types: Standard and memory-optimized. They differ in performance
characteristics and price, allowing you to tailor your storage performance and cost to your needs.
Each instance has minimum and maximum storage requirements depending on the storage type. It's
important to have sufficient storage so that your clusters have room to grow. Also, sufficient storage
makes sure that features have room to write content or log entries.
You can run a cluster on a virtual private cloud (VPC) using the Amazon Virtual Private Cloud (Amazon
VPC) service. When you use a VPC, you have control over your virtual networking environment. You
can choose your own IP address range, create subnets, and configure routing and access control lists.
ElastiCache manages backups, software patching, automatic failure detection, and recovery. There's no
additional cost to run your cluster in a VPC. For more information on using Amazon VPC with ElastiCache
for Redis, see Amazon VPCs and ElastiCache security.
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. 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 Redis with Multi-AZ.
Security
A security group controls the access to a cluster. It does so by allowing access to IP address ranges or
Amazon EC2 instances that you specify. For more information about security groups, see Security in
ElastiCache for Redis.
• Service highlights and pricing – The product detail page provides a general product overview of
ElastiCache, service highlights, and pricing.
• ElastiCache videos – The ElastiCache Videos (p. 63) 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 for Redis (p. 41) section includes
information on creating a cache cluster. It also includes how to authorize access to the cache cluster,
connect to a cache node, and delete the cache cluster.
• Performance at scale – The Performance at scale with Amazon ElastiCache whitepaper addresses
caching strategies that help your application to perform well at scale.
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.
• Caching strategies and best practices (p. 215)
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:
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
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:
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 (p. 649)
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
API Version 2015-02-02
8
Amazon ElastiCache for Redis User Guide
ElastiCache resources
This separate document covers all of the ElastiCache API operations, including syntax and examples.
Topics
• ElastiCache nodes (p. 10)
• ElastiCache for Redis shards (p. 10)
• ElastiCache for Redis clusters (p. 11)
• ElastiCache for Redis replication (p. 12)
• AWS Regions and availability zones (p. 29)
• ElastiCache for Redis endpoints (p. 29)
• ElastiCache parameter groups (p. 30)
• ElastiCache for Redis security (p. 30)
• ElastiCache security groups (p. 30)
• ElastiCache subnet groups (p. 31)
• ElastiCache for Redis backups (p. 31)
• ElastiCache events (p. 31)
ElastiCache nodes
A node is the smallest building block of an ElastiCache deployment. A node can exist in isolation form or
in some relationship to other nodes.
A node is a fixed-size chunk of secure, network-attached RAM. Each node runs an instance of the engine
and version that was chosen when you created your cluster. If necessary, you can scale the nodes in a
cluster up or down to a different instance type. For more information, see Scaling ElastiCache for Redis
clusters (p. 345).
Every node within a cluster is the same instance type and runs the same cache engine. Each cache node
has its own Domain Name Service (DNS) name and port. Multiple types of cache nodes are supported,
each with varying amounts of associated memory. For a list of supported node instance types, see
Supported node types (p. 99).
You can purchase nodes on a pay-as-you-go basis, where you only pay for your use of a node. Or you can
purchase reserved nodes at a much-reduced hourly rate. If your usage rate is high, purchasing reserved
nodes can save you money. Suppose that your cluster is almost always in use, and you occasionally add
nodes to handle use spikes. In this case, you can purchase a number of reserved nodes to run most of the
time. You can then purchase pay-as-you-go nodes for the times you occasionally need to add nodes. For
more information on reserved nodes, see ElastiCache reserved nodes (p. 107).
Redis (cluster mode enabled) clusters can have up to 500 shards, with your data partitioned across
the shards. The node or shard limit can be increased to a maximum of 500 per cluster if the Redis
engine version is 5.0.6 or higher. For example, you can choose to configure a 500 node cluster that
ranges between 83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and
no replicas). Make sure there are enough available IP addresses to accommodate the increase. Common
pitfalls include the subnets in the subnet group have too small a CIDR range or the subnets are shared
and heavily used by other clusters. For more information, see Creating a subnet group (p. 525). For
versions below 5.0.6, the limit is 250 per cluster.
To request a limit increase, see AWS Service Limits and choose the limit type Nodes per cluster per
instance type.
A multiple node shard implements replication by having one read/write primary node and 1–5 replica
nodes. For more information, see High availability using replication groups (p. 246).
For more information on shards, see Working with shards (p. 183).
• Creating a cluster
• Modifying a cluster
• Taking snapshots of a cluster (all versions of Redis)
• Deleting a cluster
• Viewing the elements in a cluster
• Adding or removing cost allocation tags to and from a cluster
Information about ElastiCache limits, such as the maximum number of nodes or clusters. To exceed
certain of these limits, you can make a request using the Amazon ElastiCache cache node request form.
• Mitigating Failures (p. 622)
Information about improving the fault tolerance of your clusters and replication groups.
Redis clusters
Redis (cluster mode enabled) clusters can have up to 500 shards, with your data partitioned across
the shards. The node or shard limit can be increased to a maximum of 500 per cluster if the Redis
engine version is 5.0.6 or higher. For example, you can choose to configure a 500 node cluster that
ranges between 83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and
no replicas). Make sure there are enough available IP addresses to accommodate the increase. Common
pitfalls include the subnets in the subnet group have too small a CIDR range or the subnets are shared
and heavily used by other clusters. For more information, see Creating a subnet group (p. 525). For
versions below 5.0.6, the limit is 250 per cluster.
To request a limit increase, see AWS Service Limits and choose the limit type Nodes per cluster per
instance type.
Redis (cluster mode disabled) clusters always contain just one shard (in the API and CLI, one node group).
A Redis shard contains one to six nodes. If there is more than one node in a shard, the shard supports
replication. In this case, one node is the read/write primary node and the others are read-only replica
nodes.
For improved fault tolerance, we recommend having at least two nodes in a Redis cluster and enabling
Multi-AZ. For more information, see Mitigating Failures (p. 622).
As demand upon your Redis (cluster mode disabled) cluster changes, you can scale up or down. To do
this, you move your cluster to a different node instance type. If your application is read intensive, we
recommend adding read-only replicas Redis (cluster mode disabled) cluster. By doing this, you can spread
the reads across a more appropriate number of nodes.
You can also use data-tiering. More frequently accessed data is stored in memory and less frequently
accessed data is stored on disk. The advantage of using data tiering is that it decreases memory needs.
For more information, see Data tiering (p. 121).
ElastiCache supports changing a Redis (cluster mode disabled) cluster's node type to a larger node type
dynamically. For information on scaling up or down, see Scaling single-node clusters for Redis (Cluster
Mode Disabled) (p. 347) or Scaling Redis (Cluster Mode Disabled) clusters with replica nodes (p. 360).
Replication is implemented by grouping from two to six nodes in a shard (in the API and CLI, called
a node group). One of these nodes is the read/write primary node. All the other nodes are read-only
replica nodes.
Each replica node maintains a copy of the data from the primary node. Replica nodes use asynchronous
replication mechanisms to keep synchronized with the primary node. Applications can read from any
node in the cluster but can write only to primary nodes. Read replicas enhance scalability by spreading
reads across multiple endpoints. Read replicas also improve fault tolerance by maintaining multiple
copies of the data. Locating read replicas in multiple Availability Zones further improves fault tolerance.
For more information on fault tolerance, see Mitigating Failures (p. 622).
Redis (cluster mode disabled) clusters support one shard (in the API and CLI, called a node group).
Redis (cluster mode enabled) clusters can have up to 500 shards, with your data partitioned across
the shards. The node or shard limit can be increased to a maximum of 500 per cluster if the Redis
engine version is 5.0.6 or higher. For example, you can choose to configure a 500 node cluster that
ranges between 83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and
no replicas). Make sure there are enough available IP addresses to accommodate the increase. Common
pitfalls include the subnets in the subnet group have too small a CIDR range or the subnets are shared
and heavily used by other clusters. For more information, see Creating a subnet group (p. 525). For
versions below 5.0.6, the limit is 250 per cluster.
To request a limit increase, see AWS Service Limits and choose the limit type Nodes per cluster per
instance type.
Replication from the API and CLI perspective uses different terminology to maintain compatibility with
previous versions, but the results are the same. The following table shows the API and CLI terms for
implementing replication.
Comparing Replication: Redis (cluster mode disabled) and Redis (cluster mode enabled)
In the following table, you can find a comparison of the features of Redis (cluster mode disabled) and
Redis (cluster mode enabled) replication groups.
Shards (node groups) 1 1–500
Notes:
If any primary has no replicas and the primary fails, you lose all that primary's data.
You can use backup and restore to migrate to Redis (cluster mode enabled).
You can use backup and restore to resize your Redis (cluster mode enabled) cluster.
All of the shards (in the API and CLI, node groups) and nodes must reside in the same AWS Region.
However, you can provision the individual nodes in multiple Availability Zones within that AWS Region.
Read replicas guard against potential data loss because your data is replicated over two or more nodes
—the primary and one or more read replicas. For greater reliability and faster recovery, we recommend
that you create one or more read replicas in different Availability Zones. In addition, enable Multi-AZ
instead of using Redis Append Only File (AOF). AOF is disabled when Multi-AZ is enabled. For more
information, see Minimizing downtime in ElastiCache for Redis with Multi-AZ (p. 253).
You can also leverage Global datastores. By using the Global Datastore for Redis feature, you can work
with fully managed, fast, reliable, and secure replication across AWS Regions. Using this feature, you
can create cross-Region read replica clusters for ElastiCache for Redis to enable low-latency reads and
disaster recovery across AWS Regions. For more information, see
By using the Global Datastore for Redis feature, you can work with fully managed, fast,
reliable, and secure replication across AWS Regions. Using this feature, you can create cross-
Region read replica clusters for ElastiCache for Redis to enable low-latency reads and disaster
recovery across AWS Regions.
In the following sections, you can find a description of how to work with global datastores.
Topics
Overview
Each global datastore is a collection of one or more clusters that replicate to one another.
• Primary (active) cluster – A primary cluster accepts writes that are replicated to all
clusters within the global datastore. A primary cluster also accepts read requests.
• Secondary (passive) cluster – A secondary cluster only accepts read requests and
replicates data updates from a primary cluster. A secondary cluster needs to be in a
different AWS Region than the primary cluster.
When you create a global datastore in ElastiCache, ElastiCache for Redis automatically
replicates your data from the primary cluster to the secondary cluster. You choose the AWS
Region where the Redis data should be replicated and then create a secondary cluster in that
AWS Region. ElastiCache then sets up and manages automatic, asynchronous replication of
data between the two clusters.
AWS Region. A global datastore can help increase the responsiveness of your application by
serving low-latency, geolocal reads across AWS Regions.
• Disaster recovery – If your primary cluster in a global datastore experiences degradation,
you can promote a secondary cluster as your new primary cluster. You can do so by
connecting to any AWS Region that contains a secondary cluster.
The following diagram shows how global datastores can work.
• Global datastores are supported in the following AWS Regions: Asia Pacific (Seoul) Region,
Asia Pacific (Tokyo) Region, Asia Pacific (Singapore) Region, Asia Pacific (Sydney) Region,
Asia Pacific (Mumbai) Region, Europe (Frankfurt) Region, EU (Paris) Region, Europe
(London) Region, Europe (Ireland) Region, US East (N. Virginia) Region, US East (Ohio)
Region, US West (N. California) Region, US West (Oregon) Region, South America (São
Paulo) Region, AWS GovCloud (US-West), AWS GovCloud (US-East), Canada (Central)
Region, China (Beijing) Region and China (Ningxia) Region.
• To use global datastores, use Redis engine version 5.0.6 or higher and R5, R6g, R6gd, M5 or
M6g node types.
• All clusters—primary and secondary—in your global datastore should have the same
number of primary nodes, node type, engine version, and number of shards (in case of
cluster-mode enabled). Each cluster in your global datastore can have a different number
of read replicas to accommodate the read traffic local to that cluster.
Replication must be enabled if you plan to use an existing single-node cluster.
• You can set up replication for a primary cluster from one AWS Region to a secondary
cluster in up to two other AWS Regions.
Note
The exception to this are China (Beijing) Region and China (Ningxia) regions, where
replication can only occur between the two regions.
• You can work with global datastores only in VPC clusters. For more information, see
Access Patterns for Accessing an ElastiCache Cluster in an Amazon VPC (p. 507). Global
datastores aren't supported when you use EC2-Classic. For more information, see EC2-
Classic in the Amazon EC2 User Guide for Linux Instances.
Note
At this time, you can't use global datastores in Using local zones with ElastiCache
(p. 91).
• ElastiCache doesn't support autofailover from one AWS Region to another. When needed,
you can promote a secondary cluster manually. For an example, see Promoting the
secondary cluster to primary (p. 240).
• To bootstrap from existing data, use an existing cluster as primary to create a global
datastore. We don't support adding an existing cluster as secondary. The process of adding
the cluster as secondary wipes data, which may result in data loss.
• Parameter updates are applied to all clusters when you modify a local parameter group of
a cluster belonging to a global datastore.
• You can scale regional clusters both vertically (scaling up and down) and horizontally
(scaling in and out). You can scale the clusters by modifying the global datastore. All the
regional clusters in the global datastore are then scaled without interruption. For more
information, see Scaling ElastiCache for Redis clusters (p. 345).
• Global datastores support encryption at rest, encryption in transit, and Redis AUTH.
• Global datastores support AWS KMS keys. For more information, see AWS key management
service concepts in the AWS Key Management Service Developer Guide.
• Security for cross-Region communication is provided through VPC peering. For more
information, see What is VPC peering? in the Amazon VPC Peering Guide.
Note
Global datastores support pub/sub messaging with the following stipulations:
1. Create a primary cluster, either by using an existing cluster or creating a new cluster. The
engine must be Redis 5.0.6 or later.
2. Add up to two secondary clusters in different AWS Regions, again using the Redis 5.0.6
engine or later.
The following procedures guide you on how to create a global datastore for Redis and
perform other operations using the ElastiCache for Redis console.
Topics
• Creating a global datastore using an existing cluster (p. 234)
• Creating a new global datastore using a new primary cluster (p. 236)
• Viewing global datastore details (p. 237)
• Adding a Region to a global datastore (p. 238)
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Redis and then choose a cluster.
3. For Actions, choose Setup Global Datastore.
4. On the Setup Global Datastore page, do the following:
• Enter a value for Global Datastore Name suffix: This suffix is used to generate a
unique name for the global datastore. You can search for the global datastore by using
the suffix that you specify here.
• (Optional) Enter a Description value.
5. Under Secondary cluster details, choose a different AWS Region where the cluster will
be stored.
6. Under Redis settings, enter a value for Name and, optionally, for Description for the
cluster.
7. Keep the following options as they are. They're prepopulated to match the primary
cluster configuration, you can't change them.
• Engine version
• Node type
• Parameter group
Note
ElastiCache autogenerates a new parameter group from values of the
provided parameter group and applies the new parameter group to the
cluster. Use this new parameter group to modify parameters on a global
datastore. Each autogenerated parameter group is associated with one and
only one cluster and, therefore, only one global datastore.
• Number of shards
• Encryption at rest – Enables encryption of data stored on disk. For more information,
see Encryption at rest.
Note
You can supply a different encryption key by choosing Customer Managed
AWS KMS key and choosing the key. For more information, see Using
Customer Managed AWS KMS keys.
• Encryption in-transit – Enables encryption of data on the wire. For more information,
see Encryption in transit. For Redis engine version 6.0 onwards, if you enable
encryption in-transit you are prompted to specify one of the following Access Control
options:
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore and then choose Create.
3. Under Create Global Datastore, do the following:
a. Enter a value for Global Datastore Name suffix. ElastiCache uses the suffix to
generate a unique name for the global datastore. You can search for the global
datastore by using the suffix that you specify here.
b. (Optional) Enter a value for Global Datastore Description.
4. Under Primary cluster details, for Region, choose an available AWS Region.
5. Follow the steps at Creating a Redis (cluster mode enabled) cluster (console).
Note
When you select a parameter group to set the engine configuration values,
that parameter group is applied to all clusters in the global datastore. On
the Parameter Groups page, the yes/no Global attribute indicates whether a
parameter group is part of a global datastore.
6. After you have successfully created the cluster in the previous step, choose Next to
configure your secondary cluster details, which are outlined in the previous section
beginning with Step 5.
7. The following options are prepopulated to match the primary cluster configuration and
cannot be changed:
• Engine version
• Instance type
• Node type
• Number of shards
• Parameter group
Note
ElastiCache autogenerates a new parameter group from values of the
provided parameter group and applies the new parameter group to the
cluster. Use this new parameter group to modify parameters on a global
datastore. Each autogenerated parameter group is associated with one and
only one cluster and, therefore, only one global datastore.
• Encryption at rest – Enables encryption of data stored on disk. For more information,
see Encryption at rest.
Note
You can supply a different encryption key by choosing Customer Managed
AWS KMS key and choosing the key. For more information, see Using
Customer Managed AWS KMS keys.
• Encryption in-transit – Enables encryption of data on the wire. For more information,
see Encryption in transit. For Redis engine version 6.4 and above, if you enable
encryption in-transit you are prompted to specify one of the following Access Control
options:
• No Access Control – This is the default setting. This indicates no restrictions on user
access to the cluster.
• User Group Access Control List – Choose a user group with a defined set of users
that can access the cluster. For more information, see Managing User Groups with
the Console and CLI (p. 495).
• Redis AUTH Default User – An authentication mechanism for Redis server. For more
information, see Redis AUTH.
Note
For Redis versions between 4.0.2, when Encryption in-transit was first
supported, and 6.0.4, Redis AUTH is the sole option.
The remaining secondary cluster settings are pre-populated with the same values as the
primary cluster, but the following can be updated to meet specific requirements for that
cluster:
• Port
• Number of replicas
• Subnet group
• Preferred Availability Zone(s)
• Security groups
• Customer Managed (AWS KMS key)
• Redis AUTH Token
• Enable automatic backups
• Backup retention period
• Backup window
• Maintenance window
• Topic for SNS notification
8. Choose Create. This sets the status of the global datastore to Creating. After the primary
cluster and secondary clusters are associated with the global datastore, the status
changes to Available. You have a primary cluster that accepts reads and writes and a
secondary cluster that accepts reads replicated from the primary cluster.
The Redis page is also updated to indicate whether a cluster is part of a global datastore,
including the following:
• Global Datastore – The name of the global datastore to which the cluster belongs.
• Global Datastore Role – The role of the cluster, either primary or secondary.
You can add up to one additional secondary cluster in a different AWS Region. For more
information, see Adding a Region to a global datastore (p. 238).
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore and then choose an available global
datastore.
You can then examine the following global datastore properties:
• Primary-Only - This status indicates the global datastore contains only a primary cluster.
Either all secondary clusters are deleted or not successfully created.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore, and then for Global Datastore Name
choose a global datastore.
3. Choose Add Region, and choose the AWS Region where the secondary cluster is to
reside.
4. Under Redis settings, enter a value for Name and, optionally, for Description for the
cluster.
5. Keep the following options as they are. They're prepopulated to match the primary
cluster configuration, and you can't change them.
• Engine version
• Instance type
• Node type
• Number of shards
• Parameter group
Note
ElastiCache autogenerates a new parameter group from values of the
provided parameter group and applies the new parameter group to the
cluster. Use this new parameter group to modify parameters on a global
datastore. Each autogenerated parameter group is associated with one and
only one cluster and, therefore, only one global datastore.
• Encryption at rest
Note
You can supply a different encryption key by choosing Customer Managed
AWS KMS key and choosing the key.
• Encryption in transit
• Redis AUTH
6. (Optional) Update the remaining secondary cluster settings. These are prepopulated
with the same values as the primary cluster, but you can update them to meet specific
requirements for that cluster:
• Port
• Number of replicas
• Subnet group
• Preferred Availability Zone(s)
• Security groups
• Customer Managed AWS KMS key)
• Redis AUTH Token
• Enable automatic backups
• Backup retention period
• Backup window
• Maintenance window
• Topic for SNS notification
7. Choose Add.
Modifying a global datastore
You can modify properties of regional clusters. Only one modify operation can be in progress
on a global datastore, with the exception of promoting a secondary cluster to primary. For
more information, see Promoting the secondary cluster to primary (p. 240).
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore, and then for Global Datastore Name,
choose a global datastore.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore under Redis.
3. Choose the global datastore name to view the details.
4. Choose the Secondary cluster.
5. Choose Promote to primary.
You're then prompted to confirm your decision with the following warning: Promoting
a region to primary will make the cluster in this region as read/
writable. Are you sure you want to promote the secondary cluster to
primary?
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore under Redis.
3. Choose a global datastore.
4. Choose the Region you want to remove.
5. Choose Remove region.
Note
This option is only available for secondary clusters.
You're then be prompted to confirm your decision with the following warning:
Removing the region will remove your only available cross region
replica for the primary cluster. Your primary cluster will no
longer be set up for disaster recovery and improved read latency in
remote region. Are you sure you want to remove the selected region
from the global datastore?
6. Choose Confirm if you want to continue the promotion or Cancel if you don't.
If you choose confirm, the AWS Region is removed and the secondary cluster no longer
receives replication updates.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore under Redis.
3. Under Global Datastore Name choose the global datastore you want to delete and then
choose Delete.
You're then be prompted to confirm your decision with the following warning: Are you
sure you want to delete this Global Datastore?
4. Choose Delete.
1. Download the AWS CLI on the AWS command line interface webpage.
2. Follow the instructions for Installing the AWS CLI and Configuring the AWS CLI in the
AWS Command Line Interface User Guide.
Using the AWS CLI with global datastores
Use the following CLI operations to work with global datastores:
• create-global-replication-group
aws elasticache create-global-replication-group \
--global-replication-group-id-suffix my global datastore \
--primary-replication-group-id sample-repl-group \
--global-replication-group-description an optional description of the global
datastore
• modify-global-replication-group
aws elasticache modify-global-replication-group \
--global-replication-group-id my global datastore \
--automatic-failover-enabled \
--cache-node-type node type \
--cache-parameter-group-name parameter group name \
--engine-version engine version \
-—apply-immediately \
--global-replication-group-description description
• delete-global-replication-group
aws elasticache delete-global-replication-group \
--global-replication-group-id my global datastore \
--retain-primary-replication-group defaults to true
• disassociate-global-replication-group
aws elasticache disassociate-global-replication-group \
--global-replication-group-id my global datastore \
--replication-group-id my secondary cluster \
--replication-group-region the AWS Region in which the secondary cluster
resides
• failover-global-replication-group
aws elasticache failover-replication-group \
--global-replication-group-id my global datastore \
--primary-region The AWS Region of the primary cluster \
--primary-replication-group-id The name of the global datastore, including
the suffix.
• increase-node-groups-in-global-replication-group
aws elasticache increase-node-groups-in-global-replication-group \
--apply-immediately yes \
--global-replication-group-id global-replication-group-name \
--node-group-count 3
• decrease-node-groups-in-global-replication-group
aws elasticache decrease-node-groups-in-global-replication-group \
--apply-immediately yes \
--global-replication-group-id global-replication-group-name \
--node-group-count 3
• rebalance-shards-in-global-replication-group
aws elasticache rebalance-shards-in-global-replication-group \
--apply-immediately yes \
--global-replication-group-id global-replication-group-name
You can also use help to describe a specific command and learn more about its usage:
(p. 231).
• AOF is not supported on node type cache.t1.micro and cache.t2. For nodes of these types, the
appendonly parameter value is ignored.
• Multi-AZ is not supported on node types T1.
For more information on AOF and Multi-AZ, see Mitigating Failures (p. 622).
By default, the AWS SDKs, AWS CLI, ElastiCache API, and ElastiCache console reference the US West
(Oregon) Region. As ElastiCache expands availability to new AWS Regions, new endpoints for these
AWS Regions are also available. You can use these in your HTTP requests, the AWS SDKs, AWS CLI, and
ElastiCache console.
Each AWS Region is designed to be completely isolated from the other AWS Regions. Within each are
multiple Availability Zones. By launching your nodes in different Availability Zones, you can achieve the
greatest possible fault tolerance. For more information about AWS Regions and Availability Zones, see
Choosing regions and availability zones (p. 87). In the following diagram, you can see a high-level
view of how AWS Regions and Availability Zones work.
For information on AWS Regions supported by ElastiCache and their endpoints, see Supported regions &
endpoints (p. 88).
The read endpoint in a Redis (cluster mode disabled) cluster always points to a specific node. Whenever
you add or remove a read replica, you must update the associated node endpoint in your application.
For a list of supported parameters, their default values, and which ones can be modified, see
DescribeEngineDefaultParameters (CLI: describe-engine-default-parameters).
For more detailed information on ElastiCache parameter groups, see Configuring engine parameters
using parameter groups (p. 423).
By default, all new ElastiCache for Redis clusters are launched in an Amazon Virtual Private Cloud
(Amazon VPC) environment. You can use subnet groups to grant cluster access from Amazon EC2
instances running on specific subnets. If you choose to run your cluster outside of Amazon VPC, you
can create security groups. These enable you to authorize Amazon EC2 instances running within specific
Amazon EC2 security groups.
In addition to restricting node access, ElastiCache for Redis supports TLS and in-place encryption for
nodes running specified versions of ElastiCache for Redis. For more information, see the following:
With ElastiCache, you can control access to your clusters using security groups. A security group acts like
a firewall, controlling network access to your cluster. By default, network access to your clusters is turned
off. If you want your applications to access your cluster, explicitly enable access from hosts in specific
Amazon EC2 security groups. After ingress rules are configured, the same rules apply to all clusters
associated with that security group.
To allow network access to your cluster, first create a security group. Then use the
AuthorizeCacheSecurityGroupIngress API action or the authorize-cache-security-group-ingress AWS CLI
command to authorize the desired Amazon EC2 security group. Doing this in turn specifies the Amazon
EC2 instances allowed. You can associate the security group with your cluster at the time of creation. You
can also do this by using the ElastiCache Management Console, the ModifyCacheCluster API operation, or
the modify-cache-cluster AWS CLI command.
Important
Access control based on IP ranges is currently not enabled for clusters. All clients to a cluster
must be within the Amazon EC2 network, and authorized by using security groups as described
previously.
For more information about security groups, see Security groups: EC2-Classic (p. 532).
If you create a cluster in an Amazon VPC, then you must specify a cache subnet group. ElastiCache uses
that cache subnet group to choose a subnet and IP addresses within that subnet to associate with your
cache nodes.
For more information about cache subnet group usage in an Amazon VPC environment, see the
following:
Depending upon the version of Redis running on your cluster, the backup process requires differing
amounts of reserved memory to succeed. For more information, see the following:
ElastiCache events
When important events happen on a cache cluster, ElastiCache sends notification to a specific Amazon
SNS topic. These events can include such things as failure or success in adding a node, a security group
modification, and others. By monitoring for key events, you can know the current state of your clusters
and in many cases take corrective action.
For more information on ElastiCache events, see Monitoring ElastiCache events (p. 606).
At the same time, we began using terminology in the ElastiCache console that is used in this new
functionality and common across the industry. These changes mean that at some points, the
terminology used in the API and CLI might be different from the terminology used in the console. The
following list identifies terms that might differ between the API and CLI and the console.
There is a one-to-one relationship between a node and a cache cluster when there are no replica
nodes. Thus, the ElastiCache console often used the terms interchangeably. The console now uses
the term node throughout. The one exception is the Create Cluster button, which launches the
process to create a cluster with or without replica nodes.
The ElastiCache API and AWS CLI continue to use the terms as they have in the past.
Cluster vs. replication group
The console now uses the term cluster for all ElastiCache for Redis clusters. The console uses the
term cluster in all these circumstances:
• When the cluster is a single node Redis cluster.
• When the cluster is a Redis (cluster mode disabled) cluster that supports replication within a single
shard (in the API and CLI, called a node group).
• When the cluster is a Redis (cluster mode enabled) cluster that supports replication within 1-90
shards or up to 500 with a limit increase request. To request a limit increase, see AWS service limits
and choose the limit type Nodes per cluster per instance type.
The following diagram illustrates the various topologies of ElastiCache for Redis clusters from the
console's perspective.
The ElastiCache API and AWS CLI operations still distinguish single node ElastiCache for Redis
clusters from multi-node replication groups. The following diagram illustrates the various
ElastiCache for Redis topologies from the ElastiCache API and AWS CLI perspective.
A global datastore is a collection of one or more clusters that replicate to one another across
Regions, whereas a replication group replicates data across a cluster mode enabled cluster with
multiple shards. A global datastore consists of the following:
• Primary (active) cluster – A primary cluster accepts writes that are replicated to all clusters within
the global datastore. A primary cluster also accepts read requests.
• Secondary (passive) cluster – A secondary cluster only accepts read requests and replicates data
updates from a primary cluster. A secondary cluster needs to be in a different AWS Region than
the primary cluster.
For information on global datastores, see Replication across AWS Regions using global
datastores (p. 231).
Additional resources
For more detailed information on managing your Amazon ElastiCache for Redis deployment, see the
following:
In "For Impatient Web Users, an Eye Blink Is Just Too Long to Wait," 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, 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 (p. 35)
• Gaming Leaderboards (Redis Sorted Sets) (p. 36)
• Messaging (Redis Pub/Sub) (p. 37)
• Recommendation Data (Redis Hashes) (p. 39)
• Other Redis Uses (p. 40)
• ElastiCache Customer Testimonials (p. 40)
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.
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. Redis sorted sets
guarantee both uniqueness and element ordering. Using Redis 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 for Redis gaming leaderboard works.
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.
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.
For more information, see the Redis documentation about sorted sets.
Redis 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 for Redis messaging.
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.
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
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.
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.
To cancel all subscriptions, use UNSUBSCRIBE and specify each channel. Or use UNSUBSCRIBE and don't
specify a channel.
or
UNSUBSCRIBE
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.*
PUNSUBSCRIBE news.sports.*
Important
The channel string sent to a [P]SUBSCRIBE command and to the [P]UNSUBSCRIBE command
must match. You can't PSUBSCRIBE to news.* and PUNSUBSCRIBE from news.sports.* or
UNSUBSCRIBE from news.sports.golf.
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."
INCR item:38923:likes
You can also watch the ElastiCache Videos (p. 63) for additional ElastiCache customer use cases.
Amazon ElastiCache supports high availability through the use of Redis replication groups. For
information about Redis replication groups and how to create them, see High availability using
replication groups (p. 246).
Beginning with Redis version 3.2, ElastiCache Redis supports partitioning your data across multiple node
groups, with each node group implementing a replication group. This exercise creates a standalone Redis
cluster.
Topics
• Setting up (p. 41)
• Step 1: Create a subnet group (p. 44)
• Step 2: Create a cluster (p. 46)
• Step 3: Authorize access to the cluster (p. 52)
• Step 4: Connect to the cluster's node (p. 54)
• Step 5: Deleting a cluster (p. 61)
• ElastiCache tutorials and videos (p. 62)
• Where do I go from here? (p. 66)
Setting up
Following, you can find topics that describe the one-time actions you must take to start using
ElastiCache.
Topics
• Create your AWS account (p. 41)
• Getting an AWS Access Key (p. 42)
• Configuring Your Credentials (p. 42)
• Downloading and Configuring the AWS CLI (p. 43)
• Set up your permissions (new ElastiCache users only) (p. 43)
If you don't already have an AWS account, create one now. AWS accounts are free. You are not charged
for signing up for an AWS service, only for using AWS services.
1. Open https://portal.aws.amazon.com/billing/signup.
2. Follow the online instructions.
Part of the sign-up procedure involves receiving a phone call and entering a verification code on the
phone keypad.
1. Sign in to the AWS Management Console and open the IAM console at https://
console.aws.amazon.com/iam/.
2. In the navigation pane, choose Users.
3. Choose the name of the user whose access keys you want to create, and then choose the Security
credentials tab.
4. In the Access keys section, choose Create access key.
5. To view the new access key pair, choose Show. You will not have access to the secret access key again
after this dialog box closes. Your credentials will look something like this:
Related topics:
There are several ways to do this. For example, you can manually create the credentials file to store your
access key ID and secret access key. You also can use the aws configure command of the AWS CLI
to automatically create the file. Alternatively, you can use environment variables. For more information
about configuring your credentials, see the programming-specific AWS SDK developer guide at Tools to
Build on AWS.
You might decide not to use the default policy and instead to use a custom-managed policy. In this case,
make sure that you have either permissions to call iam:createServiceLinkedRole or that you have
created the ElastiCache service-linked role.
When you create a new subnet group, note the number of available IP addresses. If the subnet has very
few free IP addresses, you might be constrained as to how many more nodes you can add to the cluster.
To resolve this issue, you can assign one or more subnets to a subnet group so that you have a sufficient
number of IP addresses in your cluster's Availability Zone. After that, you can add more nodes to your
cluster.
The following procedures show you how to create a subnet group called mysubnetgroup (console), the
AWS CLI, and the ElastiCache API.
1. Sign in to the AWS Management Console, and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation list, choose Subnet Groups.
3. Choose Create Subnet Group.
4. In the Create Subnet Group wizard, do the following. When all the settings are as you want them,
choose Yes, Create.
Your new subnet group appears in the Subnet Groups list of the ElastiCache console. At the bottom of
the window you can choose the subnet group to see details, such as all of the subnets associated with
this group.
For Windows:
{
"CacheSubnetGroup": {
"VpcId": "vpc-37c3cd17",
"CacheSubnetGroupDescription": "Testing",
"Subnets": [
{
"SubnetIdentifier": "subnet-53df9c3a",
"SubnetAvailabilityZone": {
"Name": "us-west-2a"
}
}
],
"CacheSubnetGroupName": "mysubnetgroup"
}
}
• CacheSubnetGroupName=mysubnetgroup
• CacheSubnetGroupDescription==Testing
• SubnetIds.member.1=subnet-53df9c3a
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheSubnetGroup
&CacheSubnetGroupDescription=Testing
&CacheSubnetGroupName=mysubnetgroup
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&SubnetIds.member.1=subnet-53df9c3a
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Credential=<credential>
&X-Amz-Date=20141201T220302Z
&X-Amz-Expires=20141201T220302Z
&X-Amz-Signature=<signature>
&X-Amz-SignedHeaders=Host
The cluster you create will be live, and not running in a sandbox. You will incur the standard ElastiCache
usage fees for the instance until you delete it. The total charges will be minimal (typically less than a
dollar) if you complete the exercise described here in one sitting and delete your cluster when you are
finished. For more information about ElastiCache usage rates, see Amazon ElastiCache.
Your cluster is launched in a virtual private cloud (VPC) based on the Amazon VPC service.
If you choose a node type from the r6gd family, data tiering will automatically be enabled. For
more information, see Data tiering.
For more information, see Choosing your node size (p. 127).
g. For Number of replicas, choose the number of read replicas that you want for this cluster.
If you choose to have one or more replicas, the Multi-AZ check box is available. For more
information, see Mitigating Failures when Running Redis (p. 622). We strongly suggest that
you enable Multi-AZ, which helps ensure your eligibility for service level agreement (SLA)
compliance. For more information on SLA compliance, see Amazon ElastiCache Service Level
Agreement on the AWS website.
If you enter 0, the Multi-AZ check box is not enabled. The cluster that you create looks like the
following. This is a Redis (cluster mode disabled) cluster with no replica nodes.
If you choose one or more replicas, the cluster that you create looks something like the
following. This is a Redis (cluster mode disabled) cluster with replica nodes.
a. For Subnet group, choose the subnet group you created in the previous section to apply to this
cluster. If you enabled Multi-AZ, the subnet group must contain at least two subnets that reside
in different availability zones.
If you are using Using local zones with ElastiCache (p. 91), you must create or choose a
subnet that is in the local zone. Multi-AZ is automatically disabled. Local Zones don't support
global datastores at this time.
For more information, see Subnets and subnet groups (p. 523).
b. For Availability zone(s), you have two options:
• No preference – ElastiCache chooses the Availability Zones for your cluster's nodes.
• Specify availability zones – Under Under availability zones placement, a list of your nodes
appears allowing you to specify the Availability Zone for each node in your cluster. You can
choose a different Availability Zone from the list to the right of each node name.
• If you have Multi-AZ enabled, you must place at least two nodes in different Availability
Zones.
For more information, see Choosing regions and availability zones (p. 87).
c. For Security groups, choose the security groups that you want for this cluster. A security group
acts as a firewall to control network access to your cluster. You can choose use the Default
security group for your VPC or create a new one.
• Encryption at rest – Enables encryption of data stored on disk. For more information, see
encryption at rest.
Note
You have the option to supply a different encryption key by choosing Customer
Managed AWS KMS key and choosing the key. For more information, see Using
Customer Managed AWS KMS keys
• Encryption in-transit – Enables encryption of data on the wire. For more information, see
encryption in transit. For Redis engine version 6.0 onward, if you enable encryption in transit
you're prompted to specify one of the following Access Control options:
API Version 2015-02-02
48
Amazon ElastiCache for Redis User Guide
Creating a Redis (cluster mode disabled) cluster (Console)
• No Access Control – This is the default setting. This indicates no restrictions on user access
to the cluster.
• User Group Access Control List – Choose a user group with a defined set of users that can
access the cluster. For more information, see Managing User Groups with the Console and
CLI (p. 495).
• Redis AUTH Default User – An authentication mechanism for Redis server. For more
information, see Redis AUTH.
Note
For Redis versions between 3.2.6 onward, excluding version 3.2.10, Redis AUTH is the
sole option.
e. (Optional) For Logs:
For more information, see Seeding a new cluster with an externally created backup (p. 337).
g. (Optional) For regularly scheduled automatic backups, choose Enable automatic backups,
and then enter the number of days that you want an automatic backup retained before it is
automatically deleted. If you don't want regularly scheduled automatic backups, clear the
Enable automatic backups check box. In either case, you always have the option to create
manual backups, which must be deleted manually.
For more information on Redis backup and restore, see Backup and restore for ElastiCache for
Redis (p. 310).
h. For Maintenance window, choose a maintenance window. The maintenance window is the time,
generally an hour in length, each week when ElastiCache schedules system maintenance for
your cluster.
You can enable ElastiCache to choose the day and time for your maintenance window (No
preference). Or you can choose the day, time, and duration yourself (Specify maintenance
window). If you choose Specify maintenance window, choose the Start day, Start time, and
Duration (in hours) for your maintenance window. All times are UTC times.
As soon as your cluster's status is available, you can grant Amazon EC2 access to it, connect to it, and
begin using it. For more information, see Step 3: Authorize access to the cluster (p. 52) and Step 4:
Connect to the cluster's node (p. 54).
Important
As soon as your cluster becomes available, you're billed for each hour or partial hour that the
cluster is active, even if you're not actively using it. To stop incurring charges for this cluster, you
must delete it. See Deleting a cluster (p. 165).
The following CLI code creates a Redis (cluster mode disabled) cache cluster with no replicas.
For Windows:
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheCluster
&CacheClusterId=my-cluster
&CacheNodeType=cache.r4.large
&CacheParameterGroup=default.redis3.2
&Engine=redis
&EngineVersion=3.2.4
&NumCacheNodes=1
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SnapshotArns.member.1=arn%3Aaws%3As3%3A%3A%3AmyS3Bucket%2Fdump.rdb
&Timestamp=20150508T220302Z
&Version=2015-02-02
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Credential=<credential>
&X-Amz-Date=20150508T220302Z
&X-Amz-Expires=20150508T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Signature=<signature>
• To use the console, see Creating a Redis (cluster mode enabled) cluster (Console) (p. 132).
• To use the AWS CLI, see Creating a Redis (cluster mode enabled) cluster (AWS CLI) (p. 137).
• To use the ElastiCache API, seeCreating a cache cluster in Redis (cluster mode enabled) (ElastiCache
API) (p. 138).
All ElastiCache clusters are designed to be accessed from an Amazon EC2 instance. The most common
scenario is to access an ElastiCache cluster from an Amazon EC2 instance in the same Amazon Virtual
Private Cloud (Amazon VPC), which will be the case for this exercise.
By default, network access to your cluster is limited to the user account that was used to create it. Before
you can connect to a cluster from an EC2 instance, you must authorize the EC2 instance to access the
cluster. The steps required depend upon whether you launched your cluster into EC2-VPC or EC2-Classic.
The most common use case is when an application deployed on an EC2 instance needs to connect to a
cluster in the same VPC. The simplest way to manage access between EC2 instances and clusters in the
same VPC is to do the following:
1. Create a VPC security group for your cluster. This security group can be used to restrict access to the
cluster instances. For example, you can create a custom rule for this security group that allows TCP
access using the port you assigned to the cluster when you created it and an IP address you will use
to access the cluster.
The default port for Redis clusters and replication groups is 6379.
Important
Amazon ElastiCache security groups are only applicable to clusters that are not running
in an Amazon Virtual Private Cloud environment (VPC). If you are running in an Amazon
Virtual Private Cloud, Security Groups is not available in the console navigation pane.
If you are running your ElastiCache nodes in an Amazon VPC, you control access to your
clusters with Amazon VPC security groups, which are different from ElastiCache security
groups. For more information about using ElastiCache in an Amazon VPC, see Amazon VPCs
and ElastiCache security (p. 502)
2. Create a VPC security group for your EC2 instances (web and application servers). This security group
can, if needed, allow access to the EC2 instance from the Internet via the VPC's routing table. For
example, you can set rules on this security group to allow TCP access to the EC2 instance over port
22.
3. Create custom rules in the security group for your Cluster that allow connections from the security
group you created for your EC2 instances. This would allow any member of the security group to
access the clusters.
Note
If you are planning to use Local Zones, ensure that you have enabled them. When you create a
subnet group in that local zone, your VPC is extended to that Local Zone and your VPC will treat
the subnet as any subnet in any other Availability Zone. All relevant gateways and route tables
will be automatically adjusted.
To create a rule in a VPC security group that allows connections from another security group
1. Sign in to the AWS Management Console and open the Amazon VPC console at https://
console.aws.amazon.com/vpc.
2. In the navigation pane, choose Security Groups.
3. Select or create a security group that you will use for your Cluster instances. Under Inbound
Rules, select Edit Inbound Rules and then select Add Rule. This security group will allow access to
members of another security group.
4. From Type choose Custom TCP Rule.
a. For Port Range, specify the port you used when you created your cluster.
The default port for Redis clusters and replication groups is 6379.
b. In the Source box, start typing the ID of the security group. From the list select the security
group you will use for your Amazon EC2 instances.
5. Choose Save when you finish.
Once you have enabled access, you are now ready to connect to the node, as discussed in the next
section.
For information on accessing your ElastiCache cluster from a different Amazon VPC, a different AWS
Region, or even your corporate network, see the following:
• Access Patterns for Accessing an ElastiCache Cluster in an Amazon VPC (p. 507)
• Accessing ElastiCache resources from outside AWS (p. 171)
This section assumes that you've created an Amazon EC2 instance and can connect to it. For instructions
on how to do this, see the Amazon EC2 Getting Started Guide.
An Amazon EC2 instance can connect to a cluster node only if you have authorized it to do so.
The primary endpoint is a DNS name that always resolves to the primary node in the cluster. The primary
endpoint is immune to changes to your cluster, such as promoting a read replica to the primary role.
For write activity, we recommend that your applications connect to the primary endpoint instead of
connecting directly to the primary.
A reader endpoint will evenly split incoming connections to the endpoint between all read replicas in a
ElastiCache for Redis cluster. Additional factors such as when the application creates the connections or
how the application (re)-uses the connections will determine the traffic distribution. Reader endpoints
keep up with cluster changes in real-time as replicas are added or removed. You can place your
ElastiCache for Redis cluster’s multiple read replicas in different AWS Availability Zones (AZ) to ensure
high availability of reader endpoints.
Note
A reader endpoint is not a load balancer. It is a DNS record that will resolve to an IP address of
one of the replica nodes in a round robin fashion.
For read activity, applications can also connect to any node in the cluster. Unlike the primary endpoint,
node endpoints resolve to specific endpoints. If you make a change in your cluster, such as adding or
deleting a replica, you must update the node endpoints in your application.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Redis.
The clusters screen will appear with a list of Redis (cluster mode disabled) and Redis (cluster mode
enabled) clusters. Choose the cluster you created in the Creating a Redis (cluster mode disabled)
cluster (Console) (p. 47) section.
3. To find the cluster's Primary and/or Reader endpoints, choose the box to the left of cluster's name.
Primary and Reader endpoints for a Redis (cluster mode disabled) cluster
If there is only one node in the cluster, there is no primary endpoint and you can continue at the
next step.
4. If the Redis (cluster mode disabled) cluster has replica nodes, you can find the cluster's replica node
endpoints by choosing the cluster's name.
The nodes screen appears with each node in the cluster, primary and replicas, listed with its
endpoint.
a. One endpoint at a time, find then highlight the endpoint you want to copy.
b. Right-click the highlighted endpoint, then choose Copy from the context menu.
The highlighted endpoint is now copied to your clipboard. For information on using the endpoint to
connect to a node, see Connecting to nodes (p. 97).
A Redis (cluster mode disabled) primary endpoint looks something like the following. There is a
difference depending upon whether or not In-Transit encryption is enabled.
clusterName.xxxxxx.nodeId.regionAndAz.cache.amazonaws.com:port
redis-01.7abc2d.0001.usw2.cache.amazonaws.com:6379
master.clusterName.xxxxxx.regionAndAz.cache.amazonaws.com:port
master.ncit.ameaqx.use1.cache.amazonaws.com:6379
Now that you have the endpoint you need, copy it to your clipboard for use in connecting to the cluster
in the next step.
To further explore how to find your endpoints, see the relevant topics for the engine and cluster type
you're running.
The following example uses Amazon EC2 instances running Amazon Linux and Amazon Linux 2. For
details on installing and compiling redis-cli with other Linux distributions, see the documentation for
your specific operating system..
Note
This process covers testing a connection using redis-cli utility for unplanned use only. For a list
of supported Redis clients, see the Redis documentation. For examples of using the AWS SDKs
with ElastiCache, see Getting Started with ElastiCache and AWS SDKs (p. 68).
1. Connect to your Amazon EC2 instance using the connection utility of your choice. For instructions on
how to connect to an Amazon EC2 instance, see the Amazon EC2 Getting Started Guide.
2. Download and install redis-cli utility by running following commands:
Amazon Linux 2
Amazon Linux
sudo yum install gcc jemalloc-devel openssl-devel tcl tcl-devel clang wget
sudo wget http://download.redis.io/redis-stable.tar.gz
sudo tar xvzf redis-stable.tar.gz
cd redis-stable
Note
If the cluster you are connecting to isn't encrypted, you don't need the Build_TLS=yes
option.
Note
In the preceding command, option -c enables cluster mode following -ASK and -MOVED
redirections.
cluster-endpoint:port number
2. You can now run Redis commands. Note that redirection occurs because you enabled it using the -c
option. If redirection isn't enabled, the command returns the MOVED error. For more information on
the MOVED error, see Redis cluster specification.
set x Hi
-> Redirected to slot [16287] located at 172.31.28.122:6379
OK
set y Hello
OK
get y
"Hello"
set z Bye
-> Redirected to slot [8157] located at 172.31.9.201:6379
OK
get z
"Bye"
get x
-> Redirected to slot [16287] located at 172.31.28.122:6379
"Hi"
In the following examples, be sure to replace cluster-endpoint and port number with the endpoint
of your cluster and your port number. (The default port for Redis is 6379.)
The following example connects to a cluster that has only encryption enabled:
The following example connects to a cluster that has only encryption enabled:
After you connect to the cluster, you can run the Redis commands as shown in the preceding examples
for unencrypted clusters.
Redis-cli alternative
If the cluster isn't cluster mode enabled and you need to make a connection to the cluster for a short
test but without going through the redis-cli compilation, you can use telnet or openssl. In the following
example commands, be sure to replace cluster-endpoint and port number with the endpoint of
your cluster and your port number. (The default port for Redis is 6379.)
The following example connects to an encryption and/or authentication enabled cluster mode disabled
cluster:
If the cluster has a password set, first connect to the cluster. After connecting, authenticate the cluster
using the following command, then press the Enter key. In the following example, replace your-
password with the password for your cluster.
Auth your-password
The following example connects to a cluster mode disabled cluster that doesn't have encryption or
authentication enabled:
In the following example, you use the redis-cli utility to connect to a cluster that is not encryption
enabled and running Redis. For more information about Redis and available Redis commands, see Redis
commands on the Redis website.
1. Connect to your Amazon EC2 instance using the connection utility of your choice. For instructions on
how to connect to an Amazon EC2 instance, see the Amazon EC2 Getting Started Guide.
2. Copy and paste the link https://github.com/microsoftarchive/redis/releases/download/
win-3.0.504/Redis-x64-3.0.504.zip in an Internet browser to download the zip file for the Redis
client from the available release at GitHub https://github.com/microsoftarchive/redis/releases/tag/
win-3.0.504
Open the Command Prompt and change to the Redis directory and run the command c:
\Redis>redis-cli -h Redis_Cluster_Endpoint -p 6379.
For example:
You are now connected to the cluster and can run Redis commands like the following.
set a "hello" // Set key "a" with a string value and no expiration
OK
get a // Get value for key "a"
"hello"
get b // Get value for key "b" results in miss
(nil)
set b "Good-bye" EX 5 // Set key "b" with a string value and a 5 second expiration
"Good-bye"
get b // Get value for key "b"
"Good-bye"
// wait >= 5 seconds
get b
(nil) // key has expired, nothing returned
quit // Exit from redis-cli
Note
In the preceding command, option -c enables cluster mode following -ASK and -MOVED
redirections.
cluster-endpoint:port number
API Version 2015-02-02
59
Amazon ElastiCache for Redis User Guide
Find your node endpoints
2. You can now run Redis commands. Note that redirection occurs because you enabled it using the -c
option. If redirection isn't enabled, the command returns the MOVED error. For more information on
the MOVED error, see Redis cluster specification.
set x Hi
-> Redirected to slot [16287] located at 172.31.28.122:6379
OK
set y Hello
OK
get y
"Hello"
set z Bye
-> Redirected to slot [8157] located at 172.31.9.201:6379
OK
get z
"Bye"
get x
-> Redirected to slot [16287] located at 172.31.28.122:6379
"Hi"
In the following examples, be sure to replace cluster-endpoint and port number with the endpoint
of your cluster and your port number. (The default port for Redis is 6379.)
The following example connects to a cluster that has only encryption enabled:
The following example connects to a cluster that has only encryption enabled:
After you connect to the cluster, you can run the Redis commands as shown in the preceding examples
for unencrypted clusters.
To delete a cluster
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the ElastiCache console dashboard, choose Redis.
As soon as your cluster is no longer listed in the list of clusters, you stop incurring charges for it.
The delete-cache-cluster CLI action only deletes one cache cluster. To delete multiple cache
clusters, call delete-cache-cluster for each cache cluster that you want to delete. You do not need
to wait for one cache cluster to finish deleting before deleting another.
--cache-cluster-id my-cluster \
--region us-east-2
For Windows:
For more information, see the AWS CLI for ElastiCache topic delete-cache-cluster.
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteCacheCluster
&CacheClusterId=my-cluster
&Region us-east-2
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20150202T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20150202T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
The DeleteCacheCluster API operation only deletes one cache cluster. To delete multiple cache
clusters, call DeleteCacheCluster for each cache cluster that you want to delete. You do not need to
wait for one cache cluster to finish deleting before deleting another.
For more information, see the ElastiCache API reference topic DeleteCacheCluster.
ElastiCache Videos
Following, you can find videos to help you learn basic and advanced Amazon ElastiCache concepts. For
information about AWS Training, see AWS Training & Certification.
Topics
• Introductory Videos (p. 63)
• Advanced Videos (p. 64)
Introductory Videos
The following videos introduce you to Amazon ElastiCache.
Topics
• AWS re:Invent 2020: What’s new in Amazon ElastiCache (p. 63)
• AWS re:Invent 2019: What’s new in Amazon ElastiCache (p. 63)
• AWS re:Invent 2017: What’s new in Amazon ElastiCache (p. 63)
• DAT204—Building Scalable Applications on AWS NoSQL Services (re:Invent 2015) (p. 63)
• DAT207—Accelerating Application Performance with Amazon ElastiCache (AWS re:Invent
2013) (p. 63)
various scenarios and use cases that can benefit by enabling caching, and discuss the features provided
by Amazon ElastiCache.
Advanced Videos
The following videos cover more advanced Amazon ElastiCache topics.
Topics
• Design for success with Amazon ElastiCache best practices (re:Invent 2020) (p. 64)
• Supercharge your real-time apps with Amazon ElastiCache (re:Invent 2019) (p. 64)
• Best practices: migrating Redis clusters from Amazon EC2 to ElastiCache (re:Invent 2019) (p. 64)
• Scaling a Fantasy Sports Platform with Amazon ElastiCache & Amazon Aurora STP11 (re:Invent
2018) (p. 65)
• Reliable & Scalable Redis in the Cloud with Amazon ElastiCache (re:Invent 2018) (p. 65)
• ElastiCache Deep Dive: Design Patterns for In-Memory Data Stores (re:Invent 2018) (p. 65)
• DAT305—Amazon ElastiCache Deep Dive (re:Invent 2017) (p. 65)
• DAT306—Amazon ElastiCache Deep Dive (re:Invent 2016) (p. 65)
• DAT317—How IFTTT uses ElastiCache for Redis to Predict Events (re:Invent 2016) (p. 66)
• DAT407—Amazon ElastiCache Deep Dive (re:Invent 2015) (p. 66)
• SDD402—Amazon ElastiCache Deep Dive (re:Invent 2014) (p. 66)
• DAT307—Deep Dive into Amazon ElastiCache Architecture and Design Patterns (re:Invent
2013) (p. 66)
Design for success with Amazon ElastiCache best practices (re:Invent 2020)
With the explosive growth of business-critical, real-time applications built on Redis, availability,
scalability, and security have become top considerations. Learn best practices for setting up Amazon
ElastiCache for success with online scaling, high availability across Multi-AZ deployments, and security
configurations.
Design for success with Amazon ElastiCache best practices (re:Invent 2020)
Online Migration tool, see a demo, and, more importantly, learn hands-on best practices for a smooth
migration to Amazon ElastiCache.
Best practices: migrating Redis clusters from Amazon EC2 to ElastiCache (re:Invent 2019)
Scaling a Fantasy Sports Platform with Amazon ElastiCache & Amazon Aurora
STP11 (re:Invent 2018)
Dream11 is India’s leading sports-tech startup. It has a growing base of 40 million+ users playing
multiple sports, including fantasy cricket, football, and basketball, and it currently serves one million
concurrent users, who produce three million requests per minute under a 50-millisecond response time.
In this talk, Dream11 CTO Amit Sharma explains how the company uses Amazon Aurora and Amazon
ElastiCache to handle flash traffic, which can triple within a 30-second response window. Sharma also
talks about scaling transactions without locking, and he shares the steps for handling flash traffic—
thereby serving five million daily active users. Complete Title: AWS re:Invent 2018: Scaling a Fantasy
Sports Platform with Amazon ElastiCache & Amazon Aurora (STP11)
Scaling a Fantasy Sports Platform with Amazon ElastiCache & Amazon Aurora STP11 (re:Invent 2018)
Reliable & Scalable Redis in the Cloud with Amazon ElastiCache (re:Invent 2018)
This session covers the features and enhancements in our Redis-compatible service, Amazon ElastiCache
for Redis. We cover key features, such as Redis 5, scalability and performance improvements, security and
compliance, and much more. We also discuss upcoming features and customer case studies.
Reliable & Scalable Redis in the Cloud with Amazon ElastiCache (re:Invent 2018)
ElastiCache Deep Dive: Design Patterns for In-Memory Data Stores (re:Invent
2018)
In this session, we provide a behind the scenes peek to learn about the design and architecture of
Amazon ElastiCache. See common design patterns with our Redis and Memcached offerings and
how customers use them for in-memory data processing to reduce latency and improve application
throughput. We review ElastiCache best practices, design patterns, and anti-patterns.
ElastiCache Deep Dive: Design Patterns for In-Memory Data Stores (re:Invent 2018)
memory operations to reduce latency and improve application throughput. During this session, we
review ElastiCache best practices, design patterns, and anti-patterns.
DAT317—How IFTTT uses ElastiCache for Redis to Predict Events (re:Invent 2016)
DAT307 - Deep Dive into Amazon ElastiCache Architecture and Design Patterns (AWS re:Invent 2013).
After you complete the Getting Started exercise, you can read these sections to learn more about
ElastiCache administration:
You want your cache 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. Use this topic to help you choose the best
node size.
• Caching strategies and best practices (p. 215)
Identify and address issues that can affect the efficiency of your cluster.
• Create ElastiCache clusters (cluster mode enabled and cluster mode disabled)
• Check if users or user groups exist, otherwise create them (Redis 6.0 onwards only)
• Connect to ElastiCache
• Perform operations such as setting and getting strings, reading from and writing to steams and
publishing and subscribing from Pub/Sub channel.
As you work through this tutorial, you can refer to the AWS SDK for Python (Boto) documentation. The
following section is specific to ElastiCache:
Tutorial Prerequisites
• Set up an AWS access key to use the AWS SDKs. For more information, see Setting up (p. 41).
• Install Python 3.0 or later. For more information, see https://www.python.org/downloads. For
instructions, see Quickstart in the Boto 3 documentation.
Topics
• Create a cluster mode disabled cluster (p. 69)
• Create a cluster mode disabled cluster with TLS and RBAC (p. 70)
• Create a cluster mode enabled cluster (p. 71)
• Create a cluster mode enabled cluster with TLS and RBAC (p. 72)
import boto3
import logging
logging.basicConfig(level=logging.INFO)
client = boto3.client('elasticache')
def
create_cluster_mode_disabled(CacheNodeType='cache.t3.small',EngineVersion='6.0',NumCacheClusters=2,Rep
cache cluster',ReplicationGroupId=None):
"""Creates an Elasticache Cluster with cluster mode disabled
:param CacheNodeType: Node type used on the cluster. If not specified, cache.t3.small
will be used
Refer to https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/
CacheNodes.SupportedTypes.html for supported node types
:param EngineVersion: Engine version to be used. If not specified, latest will be used.
:param NumCacheClusters: Number of nodes in the cluster. Minimum 1 (just a primary
node) and maximun 6 (1 primary and 5 replicas).
If not specified, cluster will be created with 1 primary and 1 replica.
:param ReplicationGroupDescription: Description for the cluster.
:param ReplicationGroupId: Name for the cluster
:return: dictionary with the API results
"""
if not ReplicationGroupId:
return 'ReplicationGroupId parameter is required'
response = client.create_replication_group(
AutomaticFailoverEnabled=True,
CacheNodeType=CacheNodeType,
Engine='redis',
EngineVersion=EngineVersion,
NumCacheClusters=NumCacheClusters,
ReplicationGroupDescription=ReplicationGroupDescription,
ReplicationGroupId=ReplicationGroupId,
SnapshotRetentionLimit=30,
)
return response
if __name__ == '__main__':
logging.info(elasticacheResponse)
python CreateClusterModeDisabledCluster.py
Copy the following program and paste it into a file named ClusterModeDisabledWithRBAC.py.
import boto3
import logging
logging.basicConfig(level=logging.INFO)
client = boto3.client('elasticache')
def
create_cluster_mode_disabled_rbac(CacheNodeType='cache.t3.small',EngineVersion='6.0',NumCacheClusters=
cache cluster',ReplicationGroupId=None, UserGroupIds=None,
SecurityGroupIds=None,CacheSubnetGroupName=None):
"""Creates an Elasticache Cluster with cluster mode disabled and RBAC
:param CacheNodeType: Node type used on the cluster. If not specified, cache.t3.small
will be used
Refer to https://docs..amazon.com/AmazonElastiCache/latest/red-ug/
CacheNodes.SupportedTypes.html for supported node types
:param EngineVersion: Engine version to be used. If not specified, latest will be used.
:param NumCacheClusters: Number of nodes in the cluster. Minimum 1 (just a primary
node) and maximun 6 (1 primary and 5 replicas).
If not specified, cluster will be created with 1 primary and 1 replica.
:param ReplicationGroupDescription: Description for the cluster.
:param ReplicationGroupId: Mandatory name for the cluster.
:param UserGroupIds: Mandatory list of user groups to be assigned to the cluster.
:param SecurityGroupIds: List of security groups to be assigned. If not defined,
default will be used
:param CacheSubnetGroupName: subnet group where the cluster will be placed. If not
defined, default will be used.
:return: dictionary with the API results
"""
if not ReplicationGroupId:
return {'Error': 'ReplicationGroupId parameter is required'}
elif not isinstance(UserGroupIds,(list)):
return {'Error': 'UserGroupIds parameter is required and must be a list'}
params={'AutomaticFailoverEnabled': True,
'CacheNodeType': CacheNodeType,
'Engine': 'redis',
'EngineVersion': EngineVersion,
'NumCacheClusters': NumCacheClusters,
'ReplicationGroupDescription': ReplicationGroupDescription,
'ReplicationGroupId': ReplicationGroupId,
'SnapshotRetentionLimit': 30,
'TransitEncryptionEnabled': True,
'UserGroupIds':UserGroupIds
}
if isinstance(SecurityGroupIds,(list)):
params.update({'SecurityGroupIds':SecurityGroupIds})
if CacheSubnetGroupName:
params.update({'CacheSubnetGroupName':CacheSubnetGroupName})
response = client.create_replication_group(**params)
return response
if __name__ == '__main__':
response=create_cluster_mode_disabled_rbac(
CacheNodeType='cache.m6g.large',
EngineVersion='6.0',
NumCacheClusters=3,
ReplicationGroupDescription='Redis cluster mode disabled with replicas',
ReplicationGroupId='redis202104',
UserGroupIds=[
'mygroup'
],
SecurityGroupIds=[
'sg-7cc73803'
],
CacheSubnetGroupName='default'
)
logging.info(response)
python ClusterModeDisabledWithRBAC.py
import boto3
import logging
logging.basicConfig(level=logging.INFO)
client = boto3.client('elasticache')
def
create_cluster_mode_enabled(CacheNodeType='cache.t3.small',EngineVersion='6.0',NumNodeGroups=1,Replica
ReplicationGroupDescription='Sample cache with cluster mode
enabled',ReplicationGroupId=None):
"""Creates an Elasticache Cluster with cluster mode enabled
:param CacheNodeType: Node type used on the cluster. If not specified, cache.t3.small
will be used
Refer to https://docs..amazon.com/AmazonElastiCache/latest/red-ug/
CacheNodes.SupportedTypes.html for supported node types
:param EngineVersion: Engine version to be used. If not specified, latest will be used.
:param NumNodeGroups: Number of shards in the cluster. Minimum 1 and maximun 90.
If not specified, cluster will be created with 1 shard.
:param ReplicasPerNodeGroup: Number of replicas per shard. If not specified 1 replica
per shard will be created.
"""
if not ReplicationGroupId:
return 'ReplicationGroupId parameter is required'
response = client.create_replication_group(
AutomaticFailoverEnabled=True,
CacheNodeType=CacheNodeType,
Engine='redis',
EngineVersion=EngineVersion,
ReplicationGroupDescription=ReplicationGroupDescription,
ReplicationGroupId=ReplicationGroupId,
# Creates a cluster mode enabled cluster with 1 shard(NumNodeGroups), 1 primary node
(implicit) and 2 replicas (replicasPerNodeGroup)
NumNodeGroups=NumNodeGroups,
ReplicasPerNodeGroup=ReplicasPerNodeGroup,
CacheParameterGroupName='default.redis6.0.cluster.on'
)
return response
logging.info(response)
python ClusterModeEnabled.py
Copy the following program and paste it into a file named ClusterModeEnabledWithRBAC.py.
import boto3
import logging
logging.basicConfig(level=logging.INFO)
client = boto3.client('elasticache')
def
create_cluster_mode_enabled(CacheNodeType='cache.t3.small',EngineVersion='6.0',NumNodeGroups=1,Replica
:param CacheNodeType: Node type used on the cluster. If not specified, cache.t3.small
will be used
Refer to https://docs..amazon.com/AmazonElastiCache/latest/red-ug/
CacheNodes.SupportedTypes.html for supported node types
:param EngineVersion: Engine version to be used. If not specified, latest will be used.
:param NumNodeGroups: Number of shards in the cluster. Minimum 1 and maximun 90.
If not specified, cluster will be created with 1 shard.
:param ReplicasPerNodeGroup: Number of replicas per shard. If not specified 1 replica
per shard will be created.
:param ReplicationGroupDescription: Description for the cluster.
:param ReplicationGroupId: Name for the cluster.
:param CacheParameterGroupName: Parameter group to be used. Must be compatible with the
engine version and cluster mode enabled.
:return: dictionary with the API results
"""
if not ReplicationGroupId:
return 'ReplicationGroupId parameter is required'
elif not isinstance(UserGroupIds,(list)):
return {'Error': 'UserGroupIds parameter is required and must be a list'}
params={'AutomaticFailoverEnabled': True,
'CacheNodeType': CacheNodeType,
'Engine': 'redis',
'EngineVersion': EngineVersion,
'ReplicationGroupDescription': ReplicationGroupDescription,
'ReplicationGroupId': ReplicationGroupId,
'SnapshotRetentionLimit': 30,
'TransitEncryptionEnabled': True,
'UserGroupIds':UserGroupIds,
'NumNodeGroups': NumNodeGroups,
'ReplicasPerNodeGroup': ReplicasPerNodeGroup,
'CacheParameterGroupName': CacheParameterGroupName
}
response = client.create_replication_group(**params)
return response
if __name__ == '__main__':
# Creates a cluster mode enabled cluster
response = create_cluster_mode_enabled(
CacheNodeType='cache.m6g.large',
EngineVersion='6.0',
ReplicationGroupDescription='Redis cluster mode enabled with replicas',
ReplicationGroupId='redis2021',
# Creates a cluster mode enabled cluster with 1 shard(NumNodeGroups), 1 primary
(implicit) and 2 replicas (replicasPerNodeGroup)
NumNodeGroups=2,
ReplicasPerNodeGroup=1,
UserGroupIds=[
'mygroup'
],
SecurityGroupIds=[
'sg-7cc73803'
],
CacheSubnetGroupName='default'
logging.info(response)
python ClusterModeEnabledWithRBAC.py
Copy the following program and paste it into a file named UserAndUserGroups.py.
import boto3
import logging
logging.basicConfig(level=logging.INFO)
client = boto3.client('elasticache')
def check_user_exists(UserId):
"""Checks if UserId exists
def check_group_exists(UserGroupId):
"""Checks if UserGroupID exists
try:
response = client.describe_user_groups(
UserGroupId=UserGroupId
)
if response['UserGroups'][0]['UserGroupId'].lower() == UserGroupId.lower():
return True
except Exception as e:
if e.response['Error']['Code'] == 'UserGroupNotFound':
logging.info(e.response['Error'])
return False
else:
raise
def create_user(UserId=None,UserName=None,Password=None,AccessString=None):
"""Creates a new user
Returns the ARN for the newly created user or the error message
:param UserId: Elasticache user ID. User IDs must be unique
:param UserName: Elasticache user name. Elasticache allows multiple users with the same
name as long as the associated user ID is unique.
:param Password: Password for user. Must have at least 16 chars.
:param AccessString: Access string with the permissions for the user. For details refer
to https://docs..amazon.com/AmazonElastiCache/latest/red-ug/Clusters.RBAC.html#Access-
string
:return: user ARN
"""
try:
response = client.create_user(
UserId=UserId,
UserName=UserName,
Engine='Redis',
Passwords=[Password],
AccessString=AccessString,
NoPasswordRequired=False
)
return response['ARN']
except Exception as e:
logging.info(e.response['Error'])
return e.response['Error']
if __name__ == '__main__':
groupName='mygroup2'
userName = 'myuser2'
userId=groupName+'-'+userName
response=create_user(UserId=tmpUserId,
UserName=tmpUserName,Password='MyStrongPasswordWithNumbers',AccessString='on ~* +@all')
logging.info(response)
# assigns the new user ID to the user group
if not check_group_exists(groupName):
UserIds = [ userId , groupName+'-default']
response=create_group(UserGroupId=groupName,UserIds=UserIds)
logging.info(response)
python UserAndUserGroups.py
Connecting to Elasticache
The following examples use the Redis client to connect to ElastiCache.
Topics
• Connecting to a cluster mode disabled cluster (p. 76)
• Connecting to a cluster mode enabled cluster (p. 76)
logging.basicConfig(level=logging.INFO)
redis = Redis(host='primary.xxx.yyyyyy.zzz1.cache.amazonaws.com', port=6379,
decode_responses=True, ssl=True, username='myuser', password='MyPassword0123456789')
if redis.ping():
logging.info("Connected to Redis")
python ConnectClusterModeDisabled.py
logging.basicConfig(level=logging.INFO)
redis = RedisCluster(startup_nodes=[{"host":
"xxx.yyy.clustercfg.zzz1.cache.amazonaws.com","port": "6379"}],
decode_responses=True,skip_full_coverage_check=True)
if redis.ping():
logging.info("Connected to Redis")
python ConnectClusterModeEnabled.py
Usage examples
The following examples use the boto3 SDK for ElastiCache to work with ElastiCache.
Topics
• Set and Get strings (p. 77)
• Set and Get a hash with multiple items (p. 77)
• Publish (write) and subscribe (read) from a Pub/Sub channel (p. 78)
• Write and read from a stream (p. 78)
import time
import logging
logging.basicConfig(level=logging.INFO,format='%(asctime)s: %(message)s')
keyName='mykey'
currTime=time.ctime(time.time())
# Set the key 'mykey' with the current date and time as value.
# The Key will expire and removed from cache in 60 seconds.
redis.set(keyName, currTime, ex=60)
python SetAndGetStrings.py
import logging
import time
logging.basicConfig(level=logging.INFO,format='%(asctime)s: %(message)s')
keyName='mykey'
keyValues={'datetime': time.ctime(time.time()), 'epochtime': time.time()}
# Set the hash 'mykey' with the current date and time in human readable format (datetime
field) and epoch number (epochtime field).
redis.hset(keyName, mapping=keyValues)
python SetAndGetHash.py
import logging
import time
def handlerFunction(message):
"""Prints message got from PubSub channel to the log output
Return None
:param message: message to log
"""
logging.info(message)
logging.basicConfig(level=logging.INFO)
redis = Redis(host="redis202104053.tihewd.ng.0001.use1.cache.amazonaws.com", port=6379,
decode_responses=True)
# Creates a new thread to watch for messages while the main process continues with its
routines
thread = subscriber.run_in_thread(sleep_time=0.01)
# Publishes several messages. Subscriber thread will read and print on log.
while True:
redis.publish('mychannel',time.ctime(time.time()))
time.sleep(1)
python PubAndSub.py
import time
import threading
logging.basicConfig(level=logging.INFO)
def writeMessage(streamName):
"""Starts a loop writting the current time and thread name to 'streamName'
def readMessage(groupName=None,streamName=None):
"""Starts a loop reading from 'streamName'
Multiple threads will read from the same stream consumer group. Consumer group is used
to coordinate data distribution.
Once a thread acknowleges the message, it won't be provided again. If message wasn't
acknowledged, it can be served to another thread.
readerID=threading.currentThread().getName()
while True:
try:
# Check if the stream has any message
if redis.xlen(streamName)>0:
# Check if if the messages are new (not acknowledged) or not (already
processed)
streamData=redis.xreadgroup(groupName,readerID,{streamName:'>'},count=1)
if len(streamData) > 0:
msgId,message = streamData[0][1][0]
logging.info("{}: Got {} from ID {}".format(readerID,message,msgId))
#Do some processing here. If the message has been processed sucessfuly,
acknowledge it and (optional) delete the message.
redis.xack(streamName,groupName,msgId)
logging.info("Stream message ID {} read and processed successfuly by
{}".format(msgId,readerID))
redis.xdel(streamName,msgId)
else:
pass
except:
raise
time.sleep(0.5)
# Creates the stream 'mystream' and consumer group 'myworkergroup' where multiple threads
will write/read.
try:
redis.xgroup_create('mystream','myworkergroup',mkstream=True)
except exceptions.ResponseError as e:
logging.info("Consumer group already exists. Will continue despite the error:
{}".format(e))
except:
raise
python ReadWriteStream.py
Overview
To migrate your data from Redis running on Amazon EC2 to Amazon ElastiCache requires an existing
or newly created Amazon ElastiCache deployment. The deployment must have a configuration that is
ready for migration. It also should be in line with the configuration that you want, including attributes
like instance type and number of replicas.
Online migration is designed for data migration from hosted Redis on Amazon EC2 to ElastiCache for
Redis and not between ElastiCache for Redis clusters.
Important
We strongly recommend you read the following sections in their entirety before beginning the
online migration process.
The migration begins when you call the StartMigration API operation or AWS CLI command. The
migration process makes the primary node of the ElastiCache for Redis cluster a replica to your source
Redis cluster on EC2. Using Redis replication, data is synced between your source Redis and ElastiCache.
After the data is in sync, you are nearly ready to cut over to ElastiCache. At this point, you make changes
on the application side so your application can call ElastiCache post-migration.
After the client-side changes are ready, call the CompleteMigration API operation. This API operation
promotes your ElastiCache deployment to your primary Redis deployment with primary and replica
nodes (as applicable). Now you can redirect your client application to start writing data to ElastiCache.
Throughout the migration, you can check the status of replication by running the redis-cli INFO
command on your Redis on EC2 nodes and on the ElastiCache primary node.
Migration steps
The following topics outline the process for migrating your data:
• Preparing your source and target Redis nodes for migration (p. 81)
• Starting migration (p. 82)
• Verifying the data migration progress (p. 83)
• Completing the data migration (p. 84)
1. Identify the target ElastiCache deployment and make sure that you can migrate data to it.
An existing or newly created ElastiCache deployment should meet the following requirements for
migration:
At a minimum, all the following in the target ElastiCache deployment should be comptatible with
your Redis configuration for Redis replication:
Starting migration
After all prerequisites are complete, you can begin data migration using the AWS Management Console,
ElastiCache API, or AWS CLI. The following example shows using the CLI.
Start migration by calling the start-migration command with the following parameters:
As you run this command, the ElastiCache primary node configures itself to become a replica of your
Redis on EC2 instance. The status of ElastiCache cluster changes to migrating and data starts migrating
from your Redis on EC2 instance to the ElastiCache primary node. Depending on the size of the data and
load on your Redis instance, the migration can take a while to complete. You can check the progress of
the migration by running the redis-cli INFO command on your Redis on EC2 instance and ElastiCache
primary node.
After successful replication, all writes to your Redis on EC2 instance propagate to the ElastiCache
cluster. You can use ElastiCache nodes for reads. However, you can't write to the ElastiCache cluster. If
the ElastiCache primary node has other replica nodes connected to it, these replica nodes continue to
replicate from the ElastiCache primary node. This way, all the data from your Redis on EC2 instance gets
replicated to all the nodes in ElastiCache cluster.
If the ElastiCache primary node can't become a replica of your Redis on EC2 instance, it retries several
times before eventually promoting itself back to primary. The status of ElastiCache cluster then
changes to available, and a replication group event about the failure to initiate the migration is sent. To
troubleshoot such a failure, check the following:
• Look at the replication group event. Use any specific information from the event to fix the migration
failure.
• If the event doesn’t provide any specific information, make sure that you have followed the guidelines
in Preparing your source and target Redis nodes for migration (p. 81).
• Ensure that the routing configuration for your VPC and subnets allows traffic between ElastiCache
nodes and your Redis on EC2 instance.
• Ensure the security group attached to your Redis on EC2 instance allows input bound traffic from
ElastiCache nodes.
• Check Redis logs for your Redis on EC2 instance for more information about failures specific to
replication.
• Verify that Redis master_link_status is up in the INFO command on ElastiCache primary node.
You can also find this information in the ElastiCache console. Select the cluster and under CloudWatch
metrics, observe Master Link Health Status. After the value reaches 1, the data is in sync.
• You can check that for the ElastiCache replica has an online state by running the INFO command on
your Redis on EC2 instance. Doing this also provides information about replication lag.
• Verify low client output buffer by using the CLIENT LIST Redis command on your Redis on EC2
instance.
After the migration is complete, the ElastiCache cluster shows the status of in-sync. This status means
that all data is now replicated. The data is in sync with any new writes coming to the primary node of
your Redis instance.
As you run this command, the ElastiCache primary node stops replicating from your Redis instance and
promotes it to primary. This promotion typically completes within minutes. To confirm the promotion to
primary, check for the event Complete Migration successful for test-cluster. At this point,
you can direct your application to ElastiCache writes and reads. ElastiCache cluster status should change
from migrating to available.
If the promotion to primary fails, the ElastiCache primary node continues to replicate from your Redis on
EC2 instance. The ElastiCache cluster continues to be in migrating status, and a replication group event
message about the failure is sent. To troubleshoot this failure, look at the following:
• Check the replication group event. Use specific information from the event to fix the failure.
• You might get an event message about data not in sync. If so, make sure that the ElastiCache primary
can replicate from your Redis on EC2 instance and both are in sync. If you still want to stop the
migration, you can run the preceding command with the —force option.
• You might get an event message if one of the ElastiCache nodes is undergoing a replacement. You can
retry the complete the migration step after the replacement is complete.
• Your Redis engine version should be 5.0.5 or higher. We don’t recommend migrating to Redis
version 5.0.5. Redis version 5.0.6 offers enhanced stability and security.
• Your Redis cluster should be in cluster-mode disabled configuration.
• Your Redis on EC2 instance should not have Redis AUTH enabled.
• Redis config protected-mode should be set to no.
• If you have bind configuration in your Redis config, then it should be updated to allow requests
from ElastiCache nodes.
• The number of databases should be the same between the ElastiCache node and your Redis on
EC2 instance. This value is set using databases in the Redis config.
• Redis commands that perform data modification should not be renamed to allow replication of
the data to succeed.
• To replicate the data from your Redis cluster to ElastiCache, make sure that there is sufficient CPU
and memory to handle this additional load. This load comes from the RDB file created by your
Redis cluster and transferred over the network to ElastiCache node.
• The cluster is in available status.
3. With your cluster selected, choose Migrate Data from Endpoint for Actions.
4. In the Migrate Data from Endpoint dialog box, enter either the IP address or the name of the EC2
instance, and the port where your Redis on EC2 instance is available.
Important
The IP address must be exact. If you enter the address incorrectly, the migration fails.
As the cluster begins migration, it changes to Modifying and then Migrating status.
6. Monitor the migration progress by choosing Events on the navigation pane.
At any point during the migration process, you can stop migration. To do so, choose your cluster and
choose Stop Data Migration for Actions. The cluster then goes to Available status.
If the migration succeeds, the cluster goes to Available status and the event log shows the following:
If the migration fails, the cluster goes to Available status and the event log shows the following:
AWS Regions are large and widely dispersed into separate geographic locations. Availability Zones
are distinct locations within an AWS Region that are engineered to be isolated from failures in other
Availability Zones. They provide inexpensive, low-latency network connectivity to other Availability
Zones in the same AWS Region.
Important
Each region is completely independent. Any ElastiCache activity you initiate (for example,
creating clusters) runs only in your current default region.
To create or work with a cluster in a specific region, use the corresponding regional service endpoint. For
service endpoints, see Supported regions & endpoints (p. 88).
Topics
• Supported regions & endpoints (p. 88)
• Locating your nodes (p. 91)
• Using local zones with ElastiCache (p. 91)
• Using Outposts (p. 92)
By default, the AWS SDKs, AWS CLI, ElastiCache API, and ElastiCache console reference the US-West
(Oregon) region. As ElastiCache expands availability to new regions, new endpoints for these regions are
also available to use in your HTTP requests, the AWS SDKs, AWS CLI, and the console.
Each region is designed to be completely isolated from the other regions. Within each region are
multiple Availability Zones (AZ). By launching your nodes in different AZs you are able to achieve the
greatest possible fault tolerance. For more information on regions and Availability Zones, see Choosing
regions and availability zones (p. 87) at the top of this topic.
us-east-1
us-west-1
us-west-2
ap-south-1
ap-northeast-1
ap-northeast-2
ap-northeast-3
ap-southeast-1
ap-southeast-2
eu-central-1
eu-north-1
sa-east-1
ap-east-1
af-south-1
For information on using the AWS GovCloud (US) with ElastiCache, see
Services in the AWS GovCloud (US) region: ElastiCache.
Some regions support a subset of node types. For a table of supported node types by AWS Region, see
Supported node types by AWS Region (p. 101).
For a table of AWS products and services by region, see Products and Services by Region.
By locating the nodes in different AZs, you eliminate the chance that a failure, such as a power outage, in
one AZ will cause your entire system to fail. Testing has demonstrated that there is no significant latency
difference between locating all nodes in one AZ or spreading them across multiple AZs.
You can specify an AZ for each node when you create a cluster or by adding nodes when you modify an
existing cluster. For more information, see the following:
By using Local Zones, you can place resources such as an ElastiCache cluster in multiple locations close to
your users.
When you create an ElastiCache cluster, you can choose a subnet in a Local Zone. Local Zones have their
own connections to the internet and support AWS-DC-long;. Thus, resources created in a Local Zone can
serve local users with very low-latency communications. For more information, see AWS Local Zones.
A Local Zone is represented by an AWS Region code followed by an identifier that indicates the location,
for example us-west-2-lax-1a.
At this time, the available Local Zones are us-west-2-lax-1a and us-west-2-lax-1b.
For more information, see Enabling Local Zones in the Amazon EC2 User Guide.
2. Create a subnet in the Local Zone.
For more information, see Creating a subnet in your VPC in the Amazon VPC User Guide.
3. Create an ElastiCache subnet group in the Local Zone.
When you create an ElastiCache subnet group, choose the Availability Zone group for the Local
Zone.
For more information, see Creating a subnet group in the ElastiCache User Guide.
4. Create an ElastiCache for Redis cluster that uses the ElastiCache subnet in the Local Zone. For more
information, see one of the following topics:
Using Outposts
AWS Outposts is a fully managed service that extends AWS infrastructure, services, APIs, and tools to
customer premises. By providing local access to AWS managed infrastructure, AWS Outposts enables
customers to build and run applications on premises using the same programming interfaces as in AWS
Regions, while using local compute and storage resources for lower latency and local data processing
needs. An Outpost is a pool of AWS compute and storage capacity deployed at a customer site. AWS
operates, monitors, and manages this capacity as part of an AWS Region. You can create subnets on your
Outpost and specify them when you create AWS resources such as ElastiCache clusters.
Note
In this version, the following limitations apply:
The autogenerated names of the read replicas follow the same pattern as that of the primary
cluster's name, with a dash and sequential three-digit number added to the end, beginning
with -002. For example, if your replication group is named MyGroup, then the names of
the secondaries would be MyGroup-002, MyGroup-003, MyGroup-004, MyGroup-005,
MyGroup-006.
2. Under Advanced Redis settings:
• Availability Zone: This will represent the Outpost, using an ARN (Amazon Resource Name) and the
AWS Resource Number.
• Outpost name: The name of the AWS Outpost.
1. Download the AWS CLI on the AWS Command Line Interface webpage.
2. Follow the instructions for Installing the AWS CLI and Configuring the AWS CLI in the AWS Command
Line Interface User Guide.
• create-cache-cluster – Using this operation, the outpost-mode parameter accepts a value that
specifies whether the nodes in the cache cluster are created in a single Outpost or across multiple
Outposts.
Note
At this time, only single-outpost mode is supported.
Managing nodes
A node is the smallest building block of an Amazon ElastiCache deployment. It is a fixed-size chunk
of secure, network-attached RAM. Each node runs the engine that was chosen when the cluster or
replication group was created or last modified. Each node has its own Domain Name Service (DNS) name
and port. Multiple types of ElastiCache nodes are supported, each with varying amounts of associated
memory and computational power.
Generally speaking, due to its support for sharding, Redis (cluster mode enabled) deployments have
a number of smaller nodes. In contrast, Redis (cluster mode disabled) deployments have fewer, larger
nodes in a cluster. For a more detailed discussion of which node size to use, see Choosing your node
size (p. 127).
Topics
• Redis nodes and shards (p. 95)
• Connecting to nodes (p. 97)
• Supported node types (p. 99)
• Rebooting nodes (cluster mode disabled only) (p. 102)
• Replacing nodes (p. 103)
• ElastiCache reserved nodes (p. 107)
• Migrating previous generation nodes (p. 117)
The following diagram illustrates the differences between a Redis (cluster mode disabled) cluster and a
Redis (cluster mode enabled) cluster.
Both Redis (cluster mode disabled) and Redis (cluster mode enabled) support replication via shards. The
API operation DescribeReplicationGroups (CLI: describe-replication-groups) lists the node groups with
the member nodes, the node's role within the node group, and also other information.
When you create a Redis cluster, you specify whether you want to create a cluster with clustering
enabled. Redis (cluster mode disabled) clusters never have more than one shard, which can be scaled
horizontally by adding (up to a total of five) or deleting read replica nodes. For more information, see
High availability using replication groups (p. 246), Adding a read replica, for Redis (Cluster Mode
Disabled) replication groups (p. 306) or Deleting a read replica, for Redis (Cluster Mode Disabled)
replication groups (p. 308). Redis (cluster mode disabled) clusters can also scale vertically by changing
node types. For more information, see Scaling Redis (Cluster Mode Disabled) clusters with replica
nodes (p. 360).
The node or shard limit can be increased to a maximum of 500 per cluster if the Redis engine version
is 5.0.6 or higher. For example, you can choose to configure a 500 node cluster that ranges between
83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and no replicas). Make
sure there are enough available IP addresses to accommodate the increase. Common pitfalls include the
subnets in the subnet group have too small a CIDR range or the subnets are shared and heavily used by
other clusters. For more information, see Creating a subnet group (p. 525).
To request a limit increase, see AWS Service Limits and choose the limit type Nodes per cluster per
instance type.
After a Redis (cluster mode enabled) cluster is created, it can be altered (scaled in or out). For more
information, see Scaling ElastiCache for Redis clusters (p. 345) and Replacing nodes (p. 103).
When you create a new cluster, you can seed it with data from the old cluster so it doesn't start out
empty. This approach works only if the cluster group has the same number of shards as the old cluster.
Doing this can be helpful if you need change your node type or engine version. For more information, see
Making manual backups (p. 315) and Restoring from a backup with optional cluster resizing (p. 334).
Connecting to nodes
Before attempting to connect to the nodes in your Redis cluster, you must have the endpoints for the
nodes. To find the endpoints, see the following:
• Finding a Redis (Cluster Mode Disabled) Cluster's Endpoints (Console) (p. 176)
• Finding Endpoints for a Redis (Cluster Mode Enabled) Cluster (Console) (p. 178)
• Finding Endpoints (AWS CLI) (p. 180)
• Finding Endpoints (ElastiCache API) (p. 183)
In the following example, you use the redis-cli utility to connect to a cluster that is running Redis.
Note
For more information about Redis and available Redis commands, see the http://redis.io/
commands webpage.
1. Connect to your Amazon EC2 instance using the connection utility of your choice.
Note
For instructions on how to connect to an Amazon EC2 instance, see the Amazon EC2 Getting
Started Guide.
2. To build redis-cli, download and install the GNU Compiler Collection (gcc). At the command
prompt of your EC2 instance, enter the following command and enter y at the confirmation prompt.
...(output omitted)...
...(output omitted)...
Complete!
3. Download and compile the redis-cli utility. This utility is included in the Redis software distribution.
At the command prompt of your EC2 instance, type the following commands:
Note
For Ubuntu systems, before running make, run make distclean.
wget http://download.redis.io/redis-stable.tar.gz
4. At the command prompt of your EC2 instance, type the following command.
You are now connected to the cluster and can run Redis commands. The following are some example
commands with their Redis responses.
set a "hello" // Set key "a" with a string value and no expiration
OK
get a // Get value for key "a"
"hello"
get b // Get value for key "b" results in miss
(nil)
set b "Good-bye" EX 5 // Set key "b" with a string value and a 5 second expiration
get b
"Good-bye"
// wait 5 seconds
get b
(nil) // key has expired, nothing returned
quit // Exit from redis-cli
For connecting to nodes or clusters which have Secure Sockets Layer (SSL) encryption (in-transit
enabled), see ElastiCache for Redis in-transit encryption (TLS) (p. 471).
ElastiCache supports the following node types. Generally speaking, the current generation types provide
more memory and computational power at lower cost when compared to their equivalent previous
generation counterparts.
For more information on performance details for each node type, see Amazon EC2 Instance Types.
• General purpose:
• Current generation:
M6g node types (available only for Redis engine version 5.0.6 onward).
T4g node types (available only for Redis engine version 6.0 onward).
R6gd node types (available only for Redis engine version 6.2 onward). For more information, see
Data tiering (p. 121).
You can launch general-purpose burstable T4g, T3-Standard and T2-Standard cache nodes in Amazon
ElastiCache. These nodes provide a baseline level of CPU performance with the ability to burst CPU
usage at any time until the accrued credits are exhausted. A CPU credit provides the performance of a full
CPU core for one minute.
Amazon ElastiCache's T4g, T3 and T2 nodes are configured as standard and suited for workloads with
an average CPU utilization that is consistently below the baseline performance of the instance. To burst
above the baseline, the node spends credits that it has accrued in its CPU credit balance. If the node is
running low on accrued credits, performance is gradually lowered to the baseline performance level. This
gradual lowering ensures the node doesn't experience a sharp performance drop-off when its accrued
CPU credit balance is depleted. For more information, see CPU Credits and Baseline Performance for
Burstable Performance Instances in the Amazon EC2 User Guide.
The following table lists the burstable performance node types, the rate at which CPU credits are earned
per hour. It also shows the maximum number of earned CPU credits that a node can accrue and the
number of vCPUs per node. In addition, it gives the baseline performance level as a percentage of a full
core performance (using a single vCPU).
Node
CPU credits earned per Maximum vCPUs Baseline Memory Network
type
hour earned performance (GiB) performance
credits per vCPU
that can be
accrued*
t4g.micro
12 288 2 10% 0.5 Up to 5
Gigabit
t4g.small
24 576 2 20% 1.37 Up to 5
Gigabit
t4g.medium
24 576 2 20% 3.09 Up to 5
Gigabit
t3.micro
12 288 2 10% 0.5 Up to 5
Gigabit
t3.small
24 576 2 20% 1.37 Up to 5
Gigabit
Node
CPU credits earned per Maximum vCPUs Baseline Memory Network
type
hour earned performance (GiB) performance
credits per vCPU
that can be
accrued*
t3.medium
24 576 2 20% 3.09 Up to 5
Gigabit
t2.micro
6 144 1 10% 0.5 Low to
moderate
t2.small
12 288 1 20% 1.55 Low to
moderate
t2.medium
24 576 2 20% 3.22 Low to
moderate
* The number of credits that can be accrued is equivalent to the number of credits that can be earned in
a 24-hour period.
** The baseline performance in the table is per vCPU. Some node sizes that have more than one vCPU.
For these, calculate the baseline CPU utilization for the node by multiplying the vCPU percentage by the
number of vCPUs.
The following CPU credit metrics are available for T3 burstable performance instances:
Note
These metrics are not available for T2 burstable performance instances.
• CPUCreditUsage
• CPUCreditBalance
• All current generation node types are created in a virtual private cloud (VPC) based on Amazon VPC by
default.
• Redis append-only files (AOF) aren't supported for T1 or T2 instances.
• Redis Multi-AZ isn't supported on T1 instances.
• Redis configuration variables appendonly and appendfsync aren't supported on Redis version
2.8.22 and later.
Note
Supported engine versions vary by AWS Region. The latest engine versions are supported in
all AWS Regions. To find the available engine versions in your AWS Region, see Supported
ElastiCache for Redis versions (p. 189).
For a complete list of node types and specifications, see the following:
• activerehashing
• databases
You are able to reboot a node using only the ElastiCache console. You can only reboot a single node at a
time. To reboot multiple nodes you must repeat the process for each node.
Redis (Cluster Mode Enabled) parameter changes
If you make changes to the following parameters on a Redis (cluster mode enabled) cluster,
follow the ensuing steps.
• activerehashing
• databases
1. Create a manual backup of your cluster. See Making manual backups (p. 315).
2. Delete the Redis (cluster mode enabled) cluster. See Deleting a cluster (p. 165).
3. Restore the cluster using the altered parameter group and backup to seed the new cluster.
See Restoring from a backup with optional cluster resizing (p. 334).
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the list in the upper-right corner, choose the AWS Region that applies.
3. In the left navigation pane, choose Redis.
To reboot multiple nodes, repeat steps 2 through 5 for each node that you want to reboot. You do not
need to wait for one node to finish rebooting to reboot another.
Replacing nodes
Amazon ElastiCache for Redis frequently upgrades its fleet with patches and upgrades being applied
to instances seamlessly. However, from time to time we need to relaunch your ElastiCache for Redis
nodes to apply mandatory OS updates to the underlying host. These replacements are required to apply
upgrades that strengthen security, reliability, and operational performance.
You have the option to manage these replacements yourself at any time before the scheduled node
replacement window. When you manage a replacement yourself, your instance receives the OS update
when you relaunch the node and your scheduled node replacement is canceled. You might continue to
receive alerts indicating that the node replacement is to take place. If you've already manually mitigated
the need for the maintenance, you can ignore these alerts.
Note
Replacement cache nodes automatically generated by Amazon ElastiCache may have different IP
addresses. You are responsible for reviewing your application configuration to ensure that your
cache nodes are associated with the appropriate IP addresses.
The following list identifies actions you can take when ElastiCache schedules one of your Redis nodes for
replacement. To expedite finding the information you need for your situation, choose from the following
menu.
• Do nothing (p. 103) – Let Amazon ElastiCache replace the node as scheduled.
• Change your maintenance window (p. 104) – Change your maintenance window to a better time.
• Redis (cluster mode enabled) Configurations
• Replace the only node in any Redis cluster (p. 104) – A procedure to replace a node in a Redis
cluster using backup and restore.
• Replace a replica node in any Redis cluster (p. 105) – A procedure to replace a read-replica in any
Redis cluster by increasing and decreasing the replica count with no cluster downtime.
• Replace any node in a Redis (cluster mode enabled) shard (p. 105) – A dynamic procedure with
no cluster downtime to replace a node in a Redis (cluster mode enabled) cluster by scaling out and
scaling in.
• Redis (cluster mode disabled) Configurations
• Replace the only node in any Redis cluster (p. 104) – Procedure to replace any node in a Redis
cluster using backup and restore.
• Replace a replica node in any Redis cluster (p. 105) – A procedure to replace a read-replica in any
Redis cluster by increasing and decreasing the replica count with no cluster downtime.
• Replace a node in a Redis (cluster mode disabled) cluster (p. 105) – Procedure to replace a node in
a Redis (cluster mode disabled) cluster using replication.
• Replace a Redis (cluster mode disabled) read-replica (p. 105) – A procedure to manually replace a
read-replica in a Redis (cluster mode disabled) replication group.
• Replace a Redis (cluster mode disabled) primary node (p. 106) – A procedure to manually replace
the primary node in a Redis (cluster mode disabled) replication group.
If the node is a member of an auto failover enabled cluster, ElastiCache for Redis provides improved
availability during patching, updates, and other maintenance-related node replacements.
API Version 2015-02-02
103
Amazon ElastiCache for Redis User Guide
Replacing nodes
For ElastiCache for Redis Cluster configurations that are set up to use ElastiCache for Redis Cluster
clients, replacement now completes while the cluster serves incoming write requests.
For non-Cluster configurations with autofailover enabled, clusters on Redis 5.0.5 and above complete
replacement while the cluster continues to stay online and serve incoming write requests. For auto
failover enabled clusters on Redis 5.0.4 or below, you might notice a brief write interruption of up to a
few seconds associated with DNS updates.
If the node is standalone, Amazon ElastiCache first launches a replacement node and then syncs from
the existing node. The existing node isn't available for service requests during this time. Once the sync
is complete, the existing node is terminated and the new node takes its place. ElastiCache makes a best
effort to retain your data during this operation.
• Change your maintenance window – For scheduled maintenance events, you receive an email or a
notification event from ElastiCache. In these cases, if you change your maintenance window before the
scheduled replacement time, your node now is replaced at the new time. For more information, see the
following:
• Modifying an ElastiCache cluster (p. 149)
• Modifying a replication group (p. 294)
Note
The ability to change your replacement window by moving your maintenance window is only
available when the ElastiCache notification includes a maintenance window. If the notification
does not include a maintenance window, you cannot change your replacement window.
For example, let's say it's Thursday, November 9, at 15:00 and the next maintenance window is Friday,
November 10, at 17:00. Following are three scenarios with their outcomes:
• You change your maintenance window to Fridays at 16:00, after the current date and time and
before the next scheduled maintenance window. The node is replaced on Friday, November 10, at
16:00.
• You change your maintenance window to Saturday at 16:00, after the current date and time and
after the next scheduled maintenance window. The node is replaced on Saturday, November 11, at
16:00.
• You change your maintenance window to Wednesday at 16:00, earlier in the week than the current
date and time). The node is replaced next Wednesday, November 15, at 16:00.
• Replace the only node in any Redis cluster – If the cluster does not have any read replicas, you can
use the following procedure to replace the node.
1. Create a snapshot of the node's cluster. For instructions, see Making manual backups (p. 315).
2. Create a new cluster seeding it from the snapshot. For instructions, see Restoring from a backup
with optional cluster resizing (p. 334).
3. Delete the cluster with the node scheduled for replacement. For instructions, see Deleting a
cluster (p. 165).
4. In your application, replace the old node's endpoint with the new node's endpoint.
API Version 2015-02-02
104
Amazon ElastiCache for Redis User Guide
Replacing nodes
• Replace a replica node in any Redis cluster – To replace a replica cluster, increase your replica count.
To do this, add a replica then decrease the replica count by removing the replica that you want to
replace. This process is dynamic and doesn't have any cluster downtime.
Note
If your shard or replication group already has five replicas, reverse steps 1 and 2.
1. Increase the replica count by adding a replica to the shard or replication group. For more
information, see Increasing the number of replicas in a shard (p. 298).
2. Delete the replica you want to replace. For more information, see Decreasing the number of
replicas in a shard (p. 302).
3. Update the endpoints in your application.
• Replace any node in a Redis (cluster mode enabled) shard – To replace the node in a cluster with no
downtime, use online resharding. First add a shard by scaling out, and then delete the shard with the
node to be replaced by scaling in.
1. Scale out: Add an additional shard with the same configuration as the existing shard with the node
to be replaced. For more information, see Adding shards with online resharding (p. 377).
2. Scale in: Delete the shard with the node to be replaced. For more information, see Removing
shards with online resharding (p. 380).
3. Update the endpoints in your application.
• Replace a node in a Redis (cluster mode disabled) cluster – If the cluster is a Redis (cluster mode
disabled) cluster without any read replicas, use the following procedure to replace the node.
1. Add replication to the cluster with the node scheduled for replacement as the primary. Do not
enable Multi-AZ on this cluster. For instructions, see To add replication to a Redis cluster with no
shards (p. 152).
2. Add a read-replica to the cluster. For instructions, see To add nodes to a cluster
(console) (p. 152).
3. Promote the newly created read-replica to primary. For instructions, see Promoting a read replica
to primary, for Redis (cluster mode disabled) replication groups (p. 309).
4. Delete the node scheduled for replacement. For instructions, see Removing nodes from a
cluster (p. 158).
5. In your application, replace the old node's endpoint with the new node's endpoint.
• Replace a Redis (cluster mode disabled) read-replica – If the node is a read-replica, replace the node.
If your cluster has only one replica node and Multi-AZ is enabled, you must disable Multi-AZ before
you can delete the replica. For instructions, see Modifying a replication group (p. 294).
1. Delete the replica that is scheduled for replacement. For instructions, see the following:
• Decreasing the number of replicas in a shard (p. 302)
• Removing nodes from a cluster (p. 158)
2. Add a new replica to replace the one that is scheduled for replacement. If you use the same name
as the replica you just deleted, you can skip step 3. For instructions, see the following:
• Increasing the number of replicas in a shard (p. 298)
• Adding a read replica, for Redis (Cluster Mode Disabled) replication groups (p. 306)
3. In your application, replace the old replica's endpoint with the new replica's endpoint.
4. If you disabled Multi-AZ at the start, re-enable it now. For instructions, see Enabling Multi-AZ
(p. 253).
• Replace a Redis (cluster mode disabled) primary node – If the node is the primary node, first
promote a read-replica to primary. Then delete the replica that used to be the primary node.
If your cluster has only one replica and Multi-AZ is enabled, you must disable Multi-AZ before you can
delete the replica in step 2. For instructions, see Modifying a replication group (p. 294).
1. Promote a read-replica to primary. For instructions, see Promoting a read replica to primary, for
Redis (cluster mode disabled) replication groups (p. 309).
2. Delete the node that is scheduled for replacement (the old primary). For instructions, see
Removing nodes from a cluster (p. 158).
3. Add a new replica to replace the one scheduled for replacement. If you use the same name as the
node you just deleted, you can skip changing endpoints in your application.
For instructions, see Adding a read replica, for Redis (Cluster Mode Disabled) replication
groups (p. 306).
4. In your application, replace the old node's endpoint with the new node's endpoint.
5. If you disabled Multi-AZ at the start, re-enable it now. For instructions, see Enabling Multi-AZ
(p. 253).
To see if reserved nodes are a cost savings for your use cases, first determine the node size and number
of nodes you need. Then estimate the usage of the node, and compare the total cost to you of using On-
Demand nodes versus reserved nodes. You can mix and match reserved and On-Demand node usage in
your clusters. For pricing information, see Amazon ElastiCache Pricing.
To see if reserved nodes are a cost savings for your use cases, first determine the node size and number
of nodes you need. Then estimate the usage of the node, and compare the total cost to you using On-
Demand nodes versus reserved nodes. You can mix and match reserved and On-Demand node usage in
your clusters. For pricing information, see Amazon ElastiCache Pricing.
AWS Region, Cache Node Class, and term length must be chosen at purchase, and cannot be changed
later.
You can use the AWS Management Console, the AWS CLI, or the ElastiCache API to list and purchase
available reserved node offerings.
For more information on reserved nodes, see Amazon ElastiCache Reserved Cache Nodes.
Topics
• Standard reserved node cache offerings (p. 107)
• Legacy reserved node cache offerings (p. 108)
• Getting info about reserved node offerings (p. 110)
• Purchasing a reserved node (p. 113)
• Getting info about your reserved nodes (p. 116)
The new node instance that you create must exactly match the specifications of the reserved node
instance. If the specifications of the new node instance match an existing reserved node instance for
your account, you are billed at the discounted rate offered for the reserved node instance. Otherwise, the
node instance is billed at an on-demand rate. These standard RIs are available from R5 and M5 instance
families onwards.
Note
All three offering types discussed next are available in one-year and three-year terms.
Offering Types
No Upfront RI provides access to a reserved ElastiCache instance without requiring an upfront payment.
Your No Upfront reserved ElastiCache instance bills a discounted hourly rate for every hour within the
term, regardless of usage.
Partial Upfront RI requires a part of the reserved ElasticCache instance to be paid upfront. The
remaining hours in the term are billed at a discounted hourly rate, regardless of usage. This option is the
replacement for the legacy Heavy Utilization option, which is explained in the next section.
All Upfront RI requires full payment to be made at the start of the RI term. You incur no other costs for
the remainder of the term, regardless of the number of hours used.
Nodes purchased at one utilization level or term cannot be converted to a different utilization level or
term.
Utilization Levels
Heavy Utilization reserved nodes enable workloads that have a consistent baseline of capacity or run
steady-state workloads. Heavy Utilization reserved nodes require a high up-front commitment, but if
you plan to run more than 79 percent of the reserved node term you can earn the largest savings (up to
70 percent off of the On-Demand price). With Heavy Utilization reserved nodes, you pay a one-time fee.
This is then followed by a lower hourly fee for the duration of the term regardless of whether your node
is running.
Medium Utilization reserved nodes are the best option if you plan to use your reserved nodes a large
amount of the time and you want either a lower one-time fee or to stop paying for your node when you
shut it off. Medium Utilization reserved nodes are a more cost-effective option when you plan to run
more than 40 percent of the reserved nodes term. This option can save you up to 64 percent off of the
On-Demand price. With Medium Utilization reserved nodes, you pay a slightly higher one-time fee than
with Light Utilization reserved nodes, and you receive lower hourly usage rates when you run a node.
Light Utilization reserved nodes are ideal for periodic workloads that run only a couple of hours a day
or a few days per week. Using Light Utilization reserved nodes, you pay a one-time fee followed by a
discounted hourly usage fee when your node is running. You can start saving when your node is running
more than 17 percent of the reserved node term. You can save up to 56 percent off of the On-Demand
rates over the entire term of your reserved node.
The following examples show how to get pricing and information about available reserved node
offerings using the AWS Management Console, AWS CLI, and ElastiCache API.
Topics
• Getting info about reserved node offerings (Console) (p. 110)
• Getting info about reserved node offerings (AWS CLI) (p. 110)
• Getting info about reserved node offerings (ElastiCache API) (p. 111)
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Reserved Cache Nodes.
3. Choose Purchase Reserved Cache Node.
4. For Product Description, choose Redis.
5. To determine the available offerings, make selections for the next three lists:
After you make these selections, the cost per node and total cost of your selections is shows in the
Purchase Reserved Cache Nodes wizard.
6. Choose Cancel to avoid purchasing these nodes and incurring charges.
{
"ReservedCacheNodesOfferings": [
{
"OfferingType": "Heavy Utilization",
"FixedPrice": 4328.0,
"ReservedCacheNodesOfferingId": "0192caa9-daf2-4159-b1e5-a79bb1916695",
"UsagePrice": 0.0,
"RecurringCharges": [
{
"RecurringChargeAmount": 0.491,
"RecurringChargeFrequency": "Hourly"
}
],
"ProductDescription": "memcached",
"Duration": 31536000,
"CacheNodeType": "cache.r3.4xlarge"
},
{
"OfferingType": "Heavy Utilization",
"FixedPrice": 4132.0,
"ReservedCacheNodesOfferingId": "fb766e0a-79d7-4e8f-a780-a2a6ed5ed439",
"UsagePrice": 0.0,
"RecurringCharges": [
{
"RecurringChargeAmount": 0.182,
"RecurringChargeFrequency": "Hourly"
}
],
"ProductDescription": "redis",
"Duration": 94608000,
"CacheNodeType": "cache.r3.2xlarge"
}
]
}
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReservedCacheNodesOfferings
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
<DescribeReservedCacheNodesOfferingsResponse xmlns="http://elasticache.us-
west-2.amazonaws.com/doc/2013-06-15/">
<DescribeReservedCacheNodesOfferingsResult>
<ReservedCacheNodesOfferings>
<ReservedCacheNodesOffering>
<Duration>31536000</Duration>
<OfferingType>Medium Utilization</OfferingType>
<CurrencyCode>USD</CurrencyCode>
<RecurringCharges/>
<FixedPrice>1820.0</FixedPrice>
<ProductDescription>memcached</ProductDescription>
<UsagePrice>0.368</UsagePrice>
<ReservedCacheNodesOfferingId>438012d3-4052-4cc7-b2e3-8d3372e0e706</
ReservedCacheNodesOfferingId>
<CacheNodeType>cache.m1.large</CacheNodeType>
</ReservedCacheNodesOffering>
<ReservedCacheNodesOffering>
</ReservedCacheNodesOffering>
</ReservedCacheNodesOfferings>
</DescribeReservedCacheNodesOfferingsResult>
<ResponseMetadata>
<RequestId>5e4ec40b-2978-11e1-9e6d-771388d6ed6b</RequestId>
</ResponseMetadata>
</DescribeReservedCacheNodesOfferingsResponse>
Topics
• Purchasing a reserved node (Console) (p. 113)
• Purchasing a reserved node (AWS CLI) (p. 113)
• Purchasing a reserved node (ElastiCache API) (p. 114)
The following procedure uses the AWS Management Console to purchase the reserved node offering by
offering id.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation list, choose the Reserved Cache Nodes link.
3. Choose the Purchase Reserved Cache Node button.
4. Choose the node type from the Product Description drop-down list box.
5. Choose the node class from the Cache Node Class drop-down list box.
6. Choose length of time you want to reserve the node for from the Term drop-down list box.
7. Do either one of the following:
• Choose the offering type from the Offering Type drop-down list box.
• Enter a reserved node ID in the Reserved Cache Node ID text box.
Note
The Reserved Cache Node ID is a unique customer-specified identifier to track this
reservation. If this box is left blank, ElastiCache automatically generates an identifier
for the reservation.
8. Choose the Next button.
The Purchase Reserved Cache Node dialog box shows a summary of the reserved node attributes
that you've chosen and the payment due.
9. Choose the Yes, Purchase button to proceed and purchase the reserved node.
Important
When you choose Yes, Purchase you incur the charges for the reserved nodes you selected.
To avoid incurring these charges, choose Cancel.
For Windows:
• ReservedCacheNodesOfferingId = 649fd0c8-cf6d-47a0-bfa6-060f8e75e95f
• ReservedCacheNodeID = myreservationID
• CacheNodeCount = 1
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=PurchaseReservedCacheNodesOffering
&ReservedCacheNodesOfferingId=649fd0c8-cf6d-47a0-bfa6-060f8e75e95f
&ReservedCacheNodeID=myreservationID
&CacheNodeCount=1
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
<PurchaseReservedCacheNodesOfferingResponse xmlns="http://elasticache.us-
west-2.amazonaws.com/doc/2013-06-15/">
<PurchaseReservedCacheNodesOfferingResult>
<ReservedCacheNode>
<OfferingType>Medium Utilization</OfferingType>
<CurrencyCode>USD</CurrencyCode>
<RecurringCharges/>
<ProductDescription>memcached</ProductDescription>
<ReservedCacheNodesOfferingId>649fd0c8-cf6d-47a0-bfa6-060f8e75e95f</
ReservedCacheNodesOfferingId>
<State>payment-pending</State>
<ReservedCacheNodeId>myreservationID</ReservedCacheNodeId>
<CacheNodeCount>10</CacheNodeCount>
<StartTime>2013-07-18T23:24:56.577Z</StartTime>
<Duration>31536000</Duration>
<FixedPrice>123.0</FixedPrice>
<UsagePrice>0.123</UsagePrice>
<CacheNodeType>cache.m1.small</CacheNodeType>
</ReservedCacheNode>
</PurchaseReservedCacheNodesOfferingResult>
<ResponseMetadata>
<RequestId>7f099901-29cf-11e1-bd06-6fe008f046c3</RequestId>
</ResponseMetadata>
</PurchaseReservedCacheNodesOfferingResponse>
Topics
• Getting info about your reserved nodes (Console) (p. 116)
• Getting info about your reserved nodes (AWS CLI) (p. 116)
• Getting info about your reserved nodes (ElastiCache API) (p. 116)
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation list, choose the Reserved Cache Nodes link.
The reserved nodes for your account appear in the Reserved Cache Nodes list. You can choose any of
the reserved nodes in the list to see detailed information about the reserved node in the detail pane
at the bottom of the console.
{
"ReservedCacheNodeId": "myreservationid",
"ReservedCacheNodesOfferingId": "649fd0c8-cf6d-47a0-bfa6-060f8e75e95f",
"CacheNodeType": "cache.m1.small",
"DataTiering": "disabled"
"Duration": "31536000",
"ProductDescription": "memcached",
"OfferingType": "Medium Utilization",
"MaxRecords": 0
}
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReservedCacheNodes
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
<DescribeReservedCacheNodesResponse xmlns="http://elasticache.us-west-2.amazonaws.com/
doc/2013-06-15/">
<DescribeReservedCacheNodesResult>
<ReservedCacheNodes>
<ReservedCacheNode>
<OfferingType>Medium Utilization</OfferingType>
<CurrencyCode>USD</CurrencyCode>
<RecurringCharges/>
<ProductDescription>memcached</ProductDescription>
<ReservedCacheNodesOfferingId>649fd0c8-cf6d-47a0-bfa6-060f8e75e95f</
ReservedCacheNodesOfferingId>
<State>payment-failed</State>
<ReservedCacheNodeId>myreservationid</ReservedCacheNodeId>
<CacheNodeCount>1</CacheNodeCount>
<StartTime>2010-12-15T00:25:14.131Z</StartTime>
<Duration>31536000</Duration>
<FixedPrice>227.5</FixedPrice>
<UsagePrice>0.046</UsagePrice>
<CacheNodeType>cache.m1.small</CacheNodeType>
</ReservedCacheNode>
<ReservedCacheNode>
</ReservedCacheNode>
</ReservedCacheNodes>
</DescribeReservedCacheNodesResult>
<ResponseMetadata>
<RequestId>23400d50-2978-11e1-9e6d-771388d6ed6b</RequestId>
</ResponseMetadata>
</DescribeReservedCacheNodesResponse>
Due to the limited amount of previous generation node types, we cannot guarantee a successful
replacement when a node becomes unhealthy in your cluster(s). In such a scenario, your cluster
availability may be negatively impacted.
We recommend that you migrate your cluster(s) to a new node type for better availability and
performance. For a recommended node type to migrate to, see Upgrade Paths. For a full list of
supported node types and previous generation node types in ElastiCache, see Supported node
types (p. 99).
• Cluster mode disabled (single node) may see approximately 60 seconds, primarily due to DNS
propagation.
• Cluster mode disabled (with replica node) may see approximately 1 second for clusters running Redis
5.0.5 and above. All lower version can experience approximately 10 seconds.
• Cluster mode enabled may see approximately 1 second.
For Windows:
In this scenario, the value of new-node-type is the node type you are migrating to. By passing the --
apply-immediately parameter, the update will be applied immediately when the replication group
transitions from modifying to available status. If Apply immediately is not chosen, the migration
process is performed during the cluster's next maintenance window.
Note
If you are unable to modify the cluster with an InvalidCacheClusterState error, you
need to remove a restore-failed node first. For more information, see Remove restore-failed-
node (p. 119).
Once you have completed that process, you can then modify the node type using the previous
steps.
Remove restore-failed-node
The following procedure describes how to remove restore-failed node from your Redis cluster. To remove
restore-failed node (console):
1. Sign in to the AWS Management Console and open the Amazon EC2 console at https://
console.aws.amazon.com/ec2/.
2. Choose Instances in the navigation pane.
3. Choose your instance and go to Description.
4. If VPC ID is blank, the instance is running on the EC2-Classic platform.
For information on migrating your EC2-Classic instance to a VPC, see Migrating an EC2-Classic cluster
into a VPC (p. 513).
Managing clusters
A cluster is a collection of one or more cache nodes, all of which run an instance of the Redis cache
engine software. When you create a cluster, you specify the engine and version for all of the nodes to
use.
The following diagram illustrates a typical Redis cluster. Redis clusters can contain a single node or up to
six nodes inside a shard (API/CLI: node group), A single-node Redis (cluster mode disabled) cluster has
no shard, and a multi-node Redis (cluster mode disabled) cluster has a single shard. Redis (cluster mode
enabled) clusters can have up to 500 shards, with your data partitioned across the shards. The node
or shard limit can be increased to a maximum of 500 per cluster if the Redis engine version is 5.0.6 or
higher. For example, you can choose to configure a 500 node cluster that ranges between 83 shards (one
primary and 5 replicas per shard) and 500 shards (single primary and no replicas). Make sure there are
enough available IP addresses to accommodate the increase. Common pitfalls include the subnets in the
subnet group have too small a CIDR range or the subnets are shared and heavily used by other clusters.
For more information, see Creating a subnet group (p. 525). For versions below 5.0.6, the limit is 250
per cluster.
To request a limit increase, see AWS Service Limits and choose the limit type Nodes per cluster per
instance type.
When you have multiple nodes in a shard, one of the nodes is a read/write primary node. All other nodes
in the shard are read-only replicas.
Most ElastiCache operations are performed at the cluster level. You can set up a cluster with a specific
number of nodes and a parameter group that controls the properties for each node. All nodes within
a cluster are designed to be of the same node type and have the same parameter and security group
settings.
Every cluster must have a cluster identifier. The cluster identifier is a customer-supplied name for the
cluster. This identifier specifies a particular cluster when interacting with the ElastiCache API and AWS
CLI commands. The cluster identifier must be unique for that customer in an AWS Region.
ElastiCache supports multiple engine versions. Unless you have specific reasons, we recommend using
the latest version.
ElastiCache clusters are designed to be accessed using an Amazon EC2 instance. If you launch your
cluster in a virtual private cloud (VPC) based on the Amazon VPC service, you can access it from outside
AWS. For more information, see Accessing ElastiCache resources from outside AWS (p. 171).
For a list of supported Redis versions, see Supported ElastiCache for Redis Versions.
Data tiering
Clusters that comprise a replication group and use a node type from the r6gd family have their data
tiered between memory and local SSD (solid state drives) storage. Data tiering provides a new price-
performance option for Redis workloads by utilizing lower-cost solid state drives (SSDs) in each cluster
node in addition to storing data in memory. It is ideal for workloads that access up to 20 percent of their
overall dataset regularly, and for applications that can tolerate additional latency when accessing data
on SSD.
On clusters with data tiering, ElastiCache monitors the last access time of every item it stores. When
available memory (DRAM) is fully consumed, ElastiCache uses a least-recently used (LRU) algorithm
to automatically move infrequently accessed items from memory to SSD. When data on SSD is
subsequently accessed, ElastiCache automatically and asynchronously moves it back to memory before
processing the request. If you have a workload that accesses only a subset of its data regularly, data
tiering is an optimal way to scale your capacity cost-effectively.
For example, assuming 500-byte String values, you can expect an additional 300 microseconds of latency
on average for requests to data stored on SSD compared to requests to data in memory.
With the largest data tiering node size (cache.r6gd.16xlarge), you can store up to 1 petabyte in a single
500-node cluster (500 TB when using 1 read replica). Data tiering is compatible with all Redis commands
and data structures supported in ElastiCache. You don't need any client-side changes to use this feature.
Topics
• Limitations (p. 121)
• Data tiering pricing (p. 122)
• Monitoring (p. 122)
• Using data tiering (p. 122)
• Restoring data from backup into clusters with data tiering enabled (p. 123)
Limitations
Data tiering has the following limitations:
• You can only use data tiering on clusters that are part of a replication group.
• The node type you use must be from the r6gd family, which is available in the following regions: us-
east-2, us-east-1, us-west-2, us-west-1, eu-west-1, eu-central-1, ap-northeast-1, ap-
southeast-1, ap-southeast-2.
• You must use the Redis 6.2 or later engine.
• You cannot restore a backup of an r6gd cluster into another cluster unless it also uses r6gd.
• You cannot export a backup to Amazon S3 for data-tiering clusters.
• Online migration is not supported for clusters running on the r6gd node type.
• Scaling is not supported from a data tiering cluster (for example, a cluster using an r6gd node type) to
a cluster that does not use data tiering (for example, a cluster using an r6g node type).
• Auto scaling is not supported for clusters running using data tiering.
• Data tiering only supports volatile-lru, allkeys-lru and noeviction maxmemory policies.
• Forkless save is not supported. For more information, see How synchronization and backup are
implemented (p. 265).
• Items larger than 128 MiB are not moved to SSD.
Monitoring
ElastiCache for Redis offers metrics designed specifically to monitor the performance clusters that use
data tiering. For more information, see Metrics for Redis clusters that use data tiering at Metrics for
Redis (p. 589).
For more information on creating a cluster, see Creating a cluster (p. 129).
You cannot opt out of data tiering when selecting a node type from the r6gd family. If you set the --no-
data-tiering-enabled parameter, the operation will fail.
For Windows:
After running this operation, you will see a response similar to the following:
{
"ReplicationGroup": {
"ReplicationGroupId": "redis-dt-cluster",
"Description": "Redis cluster with data tiering",
"Status": "creating",
"PendingModifiedValues": {},
"MemberClusters": [
"redis-dt-cluster"
],
"AutomaticFailover": "disabled",
"DataTiering": "enabled",
"SnapshotRetentionLimit": 0,
"SnapshotWindow": "06:00-07:00",
"ClusterEnabled": false,
"CacheNodeType": "cache.r6gd.xlarge",
"TransitEncryptionEnabled": false,
"AtRestEncryptionEnabled": false
}
}
Restoring data from backup into clusters with data tiering enabled (console)
To restore a backup to a new cluster with data tiering enabled (console)
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Backups.
3. In the list of backups, choose the box to the left of the backup name you want to restore from.
4. Choose Restore.
5. Complete the Restore Cluster dialog box. Be sure to complete all the Required fields and any of the
others you want to change from the defaults.
For more information on creating a cluster, see Creating a cluster (p. 129).
Restoring data from backup into clusters with data tiering enabled (AWS CLI)
When creating a replication group using the AWS CLI, data tiering is by default used by selecting a
node type from the r6gd family, such as cache.r6gd.xlarge and setting the --data-tiering-enabled
parameter.
You cannot opt out of data tiering when selecting a node type from the r6gd family. If you set the --no-
data-tiering-enabled parameter, the operation will fail.
After running this operation, you will see a response similar to the following:
{
"ReplicationGroup": {
"ReplicationGroupId": "redis-dt-cluster",
"Description": "Redis cluster with data tiering",
"Status": "creating",
"PendingModifiedValues": {},
"MemberClusters": [
"redis-dt-cluster"
],
"AutomaticFailover": "disabled",
"DataTiering": "enabled",
"SnapshotRetentionLimit": 0,
"SnapshotWindow": "06:00-07:00",
"ClusterEnabled": false,
"CacheNodeType": "cache.r6gd.xlarge",
"TransitEncryptionEnabled": false,
"AtRestEncryptionEnabled": false
}
Preparing a cluster
Following, you can find instructions on creating a cluster using the ElastiCache console, the AWS CLI, or
the ElastiCache API.
You can also create an ElastiCache cluster using AWS CloudFormation. For more information, see
AWS::ElastiCache::CacheCluster in the AWS Cloud Formation User Guide, which includes guidance on how
to implement that approach.
Whenever you create a cluster or replication group, it is a good idea to do some preparatory work so you
won't need to upgrade or make changes right away.
Topics
• Determining your requirements (p. 125)
• Choosing your node size (p. 127)
Knowing the answers to the following questions helps make creating your cluster go smoother:
For guidance on choosing an instance node type, see Choosing your node size (p. 127).
• Will you launch your cluster in a virtual private cloud (VPC) based on Amazon VPC?
Important
If you're going to launch your cluster in a VPC, make sure to create a subnet group in the
same VPC before you start creating a cluster. For more information, see Subnets and subnet
groups (p. 523).
ElastiCache is designed to be accessed from within AWS using Amazon EC2. However, if you
launch in a VPC based on Amazon VPC and your cluster is in an VPC, you can provide access
from outside AWS. For more information, see Accessing ElastiCache resources from outside
AWS (p. 171).
• Do you need to customize any parameter values?
If you do, create a custom parameter group. For more information, see Creating a parameter
group (p. 425).
For more information, see Security groups: EC2-Classic (p. 532) and Security in Your VPC.
• How do you intend to implement fault tolerance?
Topics
• Memory and processor requirements (p. 126)
Scaling requirements
All clusters can be scaled up by creating a new cluster with the new, larger node type. When you scale up
a Redis cluster, you can seed it from a backup and avoid having the new cluster start out empty.
For more information, see Scaling ElastiCache for Redis clusters (p. 345) in this guide.
Access requirements
By design, Amazon ElastiCache clusters are accessed from Amazon EC2 instances. Network access to
an ElastiCache cluster is limited to the user account that created the cluster. Therefore, before you can
access a cluster from an Amazon EC2 instance, you must authorize the Amazon EC2 instance to access
the cluster. The steps to do this vary, depending upon whether you launched into EC2-VPC or EC2-
Classic.
If you launched your cluster into EC2-VPC you need to grant network ingress to the cluster. If you
launched your cluster into EC2-Classic you need to grant the Amazon Elastic Compute Cloud security
group associated with the instance access to your ElastiCache security group. For detailed instructions,
see Step 3: Authorize access to the cluster (p. 52) in this guide.
• Do you have workloads that access a small percentage of their data regularly?
If this is the case and you are running on Redis engine version 6.2 or later, you can leverage data
tiering by choosing the r6gd node type. With data tiering, least-recently used data is stored in
SSD. When it is retrieved there is a small latency cost, which is balanced by cost savings. For more
information, see Data tiering (p. 121).
To get a general estimate, take the size of the items that you want to cache. Multiply this size by the
number of items that you want to keep in the cache at the same time. To get a reasonable estimation
of the item size, first serialize your cache items, then count the characters. Then divide this over the
number of shards in your cluster.
Redis versions before 2.8.22 require you to reserve more memory for failover, snapshot, synchronizing,
and promoting a replica to primary operations. This requirement occurs because you must have
sufficient memory available for all writes that occur during the process.
Redis version 2.8.22 and later use a forkless save process that requires less available memory than the
earlier process.
Write heavy applications can require significantly more available memory, memory not used by data,
when taking snapshots or failing over. Whenever the BGSAVE process is performed, you must have
sufficient memory that is unused by data to accommodate all the writes that transpire during the
BGSAVE process. Examples are when taking a snapshot, when syncing a primary cluster with a replica
in a cluster, and when enabling the append-only file (AOF) feature. Another is when promoting a
replica to primary (if you have Multi-AZ enabled). The worst case is when all of your data is rewritten
during the process. In this case, you need a node instance size with twice as much memory as needed
for data alone.
For more detailed information, see Ensuring that you have enough memory to create a Redis
snapshot (p. 221).
• Will your implementation be a standalone Redis (cluster mode disabled) cluster or a Redis (cluster
mode enabled) cluster with multiple shards?
If you're implementing a Redis (cluster mode disabled) cluster, your node type must be able to
accommodate all your data plus the necessary overhead as described in the previous bullet.
For example, suppose that you estimate that the total size of all your items is 12 GB. In this case,
you can use a cache.m3.xlarge node with 13.3 GB of memory or a cache.r3.large node
with 13.5 GB of memory. However, you might need more memory for BGSAVE operations. If your
application is write-heavy, double the memory requirements to at least 24 GB. Thus, use either a
cache.m3.2xlarge with 27.9 GB of memory or a cache.r3.xlarge with 30.5 GB of memory.
If you're implementing a Redis (cluster mode enabled) cluster with multiple shards, then the node type
must be able to accommodate bytes-for-data-and-overhead / number-of-shards bytes of
data.
For example, suppose that you estimate that the total size of all your items to be 12 GB and you have
two shards. In this case, you can use a cache.m3.large node with 6.05 GB of memory (12 GB / 2).
However, you might need more memory for BGSAVE operations. If your application is write-heavy,
double the memory requirements to at least 12 GB per shard. Thus, use either a cache.m3.xlarge
with 13.3 GB of memory or a cache.r3.large with 13.5 GB of memory.
• Are you using Local Zones?
Local Zones enable you to place resources such as an ElastiCache cluster in multiple locations close to
your users. But when you choose your node size, be aware that the available node sizes are limited to
the following at this time, regardless of capacity requirements:
• Current generation:
While your cluster is running, you can monitor the memory usage, processor utilization, cache hits, and
cache misses metrics that are published to CloudWatch. You might notice that your cluster doesn't have
the hit rate that you want or that keys are being evicted too often. In these cases, you can choose a
different node size with larger CPU and memory specifications.
When monitoring CPU usage, remember the Redis is single-threaded. Thus, multiply the reported CPU
usage by the number of CPU cores to get that actual usage. For example, a four-core CPU reporting a 20-
percent usage rate is actually the one core Redis is running at 80 percent utilization.
Creating a cluster
The following examples show how to create a Redis cluster using the AWS Management Console, AWS
CLI and ElastiCache API.
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the list in the upper-right corner, choose the AWS Region that you want to launch this cluster
in.
3. Choose Redis from the navigation pane.
4. Choose Create.
5. For Cluster engine, choose Redis. Make sure the Cluster Mode enabled check box is cleared.
6. Complete the Redis settings section.
If you choose a node type from the r6gd family, data tiering will automatically be enabled. For
more information, see Data tiering.
For more information, see Choosing your node size (p. 127).
API Version 2015-02-02
129
Amazon ElastiCache for Redis User Guide
Creating a cluster
If you choose a node type from the r6gd family, you will automatically enable data-tiering,
which splits data storage between memory and SSD. For more information, see Data
tiering (p. 121).
h. For Number of replicas, choose the number of read replicas that you want for this cluster.
If you choose to have one or more replicas, the Multi-AZ check box is available. For more
information, see Mitigating Failures when Running Redis (p. 622). We strongly suggest that
you enable Multi-AZ, which helps ensure your eligibility for service level agreement (SLA)
compliance. For more information on SLA compliance, see Amazon ElastiCache Service Level
Agreement on the AWS website.
If you enter 0, the Multi-AZ check box is not enabled. The cluster that you create looks like the
following. This is a Redis (cluster mode disabled) cluster with no replica nodes.
If you choose one or more replicas, the cluster that you create looks something like the
following. This is a Redis (cluster mode disabled) cluster with replica nodes.
a. For Subnet group, create a new subnet group or choose an existing one that you want to apply
to this cluster. If you enabled Multi-AZ, the subnet group must contain at least two subnets that
reside in different availability zones.
If you are using Using local zones with ElastiCache (p. 91), you must create or choose a subnet
that is in the local zone. Multi-AZ is automatically disabled. Local Zones don't support global
datastores at this time.
For more information, see Subnets and subnet groups (p. 523).
b. For Availability zone(s), you have two options:
• No preference – ElastiCache chooses the Availability Zones for your cluster's nodes.
• Specify availability zones – Under Under availability zones placement, a list of your nodes
appears allowing you to specify the Availability Zone for each node in your cluster. You can
choose a different Availability Zone from the list to the right of each node name.
• If you have Multi-AZ enabled, you must place at least two nodes in different Availability
Zones.
For more information, see Choosing regions and availability zones (p. 87).
c. For Security groups, choose the security groups that you want for this cluster. A security group
acts as a firewall to control network access to your cluster. You can choose use the Default
security group for your VPC or create a new one.
• Encryption at rest – Enables encryption of data stored on disk. For more information, see
encryption at rest.
Note
You have the option to supply a different encryption key by choosing Customer
Managed AWS KMS key and choosing the key. For more information, see Using
customer managed keys from AWS KMS
• Encryption in-transit – Enables encryption of data on the wire. For more information, see
encryption in transit. For Redis engine version 6.0 onward, if you enable encryption in transit
you're prompted to specify one of the following Access Control options:
• No Access Control – This is the default setting. This indicates no restrictions on user access
to the cluster.
• User Group Access Control List – Choose a user group with a defined set of users that can
access the cluster. For more information, see Managing User Groups with the Console and
CLI (p. 495).
• Redis AUTH Default User – An authentication mechanism for Redis server. For more
information, see Redis AUTH.
Note
For Redis versions between 3.2.6 onward, excluding version 3.2.10, Redis AUTH is the
sole option.
e. (Optional) For Logs:
For more information, see Seeding a new cluster with an externally created backup (p. 337).
g. (Optional) For regularly scheduled automatic backups, choose Enable automatic backups,
and then enter the number of days that you want an automatic backup retained before it is
automatically deleted. If you don't want regularly scheduled automatic backups, clear the
Enable automatic backups check box. In either case, you always have the option to create
manual backups, which must be deleted manually.
For more information on Redis backup and restore, see Backup and restore for ElastiCache for
Redis (p. 310).
h. For Maintenance window, choose a maintenance window. The maintenance window is the time,
generally an hour in length, each week when ElastiCache schedules system maintenance for
your cluster.
You can enable ElastiCache to choose the day and time for your maintenance window (No
preference). Or you can choose the day, time, and duration yourself (Specify maintenance
window). If you choose Specify maintenance window, choose the Start day, Start time, and
Duration (in hours) for your maintenance window. All times are UTC times.
i. For Notifications, choose an existing Amazon Simple Notification Service (Amazon SNS) topic,
or choose manual ARN input and enter the topic Amazon Resource Name (ARN). If you use
Amazon SNS, you can push notifications to internet-connected smart devices. The default is to
disable notifications. For more information, see https://aws.amazon.com/sns/.
8. Review all your entries and choices, then go back and make any needed corrections. When you're
ready, choose Create to launch your cluster.
As soon as your cluster's status is available, you can grant Amazon EC2 access to it, connect to it, and
begin using it. For more information, see Step 3: Authorize access to the cluster (p. 52) and Step 4:
Connect to the cluster's node (p. 54).
Important
As soon as your cluster becomes available, you're billed for each hour or partial hour that the
cluster is active, even if you're not actively using it. To stop incurring charges for this cluster, you
must delete it. See Deleting a cluster (p. 165).
You can create a Redis (cluster mode enabled) cluster (API/CLI: replication group) using the ElastiCache
management console, the AWS CLI for ElastiCache, and the ElastiCache API.
To create a Redis (cluster mode enabled) cluster using the ElastiCache console
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the list in the upper-right corner, choose the AWS Region that you want to launch this cluster
in.
3. Choose Redis from the navigation pane.
4. Choose Create.
5. For Cluster engine, choose Redis, and then choose Cluster Mode enabled. These choices create a
Redis (cluster mode enabled) cluster that looks something like the following.
Redis (cluster mode enabled) cluster created with replication and data partitioning
6. Complete the Redis settings section.
Important
For more information on doing so, see Upgrading engine versions (p. 198). However,
you can't downgrade to older engine versions except by deleting the existing cluster
and creating it again.
d. If you choose Data tiering, make sure you are using an r6gd node type. For more information,
see Data tiering (p. 121).
e. In Port, use the default port, 6379. If you have a reason to use a different port, enter the port
number.
f. For Parameter group, choose a parameter group or create a new one. Parameter groups control
the runtime parameters of your cluster. For more information on parameter groups, see Redis-
specific parameters (p. 441) and Creating a parameter group (p. 425).
g. For Node type, choose the down arrow ( ). In the Change node type dialog box, choose a value
for Instance family for the node type that you want. Then choose the node type that you want
to use for this cluster, and then choose Save.
For more information, see Choosing your node size (p. 127).
h. For Number of shards, choose the number of shards (partitions/node groups) that you want for
this Redis (cluster mode enabled) cluster.
For some versions of Redis (cluster mode enabled), you can change the number of shards in your
cluster dynamically:
• Redis 3.2.10 and later – If your cluster is running Redis 3.2.10 or later versions, you can
change the number of shards in your cluster dynamically. For more information, see Scaling
clusters in Redis (Cluster Mode Enabled) (p. 375).
• Other Redis versions – If your cluster is running a version of Redis before version 3.2.10,
there's another approach. To change the number of shards in your cluster in this case, create
a new cluster with the new number of shards. For more information, see Restoring from a
backup with optional cluster resizing (p. 334).
i. For Replicas per shard, choose the number of read replica nodes that you want in each shard.
• If you have Multi-AZ enabled, make sure that you have at least one replica per shard.
• The number of replicas is the same for each shard when creating the cluster using the
console.
• The number of read replicas per shard is fixed and cannot be changed. If you find you need
more or fewer replicas per shard (API/CLI: node group), you must create a new cluster
with the new number of replicas. For more information, see Seeding a new cluster with an
externally created backup (p. 337).
j. For Subnet group, create a new subnet group or choose an existing one that you want to apply
to this cluster. If you enabled Multi-AZ, the subnet group must contain at least two subnets that
reside in different availability zones.
If you are using Using local zones with ElastiCache (p. 91), you must create or choose a subnet
that is in the local zone. Multi-AZ is automatically disabled. Local Zones don't support global
datastores at this time.
For more information, see Subnets and subnet groups (p. 523).
7. Click Advanced Redis settings and complete the section.
a. For Slots and keyspaces, choose how you want your keys distributed over your shards
(partitions). There are 16,384 keys to be distributed (numbered 0 through 16383).
• Equal distribution – ElastiCache distributes your keyspace as equally as possible over your
shards.
• Custom distribution – You specify the range of keys for each shard in the table below
Availability zone(s).
b. For Availability zone(s), you have two options:
• Specify availability zones – You specify the Availability Zone for each cluster.
If you chose to specify the Availability Zones, for each cluster in each shard, choose the
Availability Zone from the list.
For more information, see Choosing regions and availability zones (p. 87).
For more information on security groups, see Security groups for your VPC in the Amazon VPC
User Guide.
d. Encrypt your data, you have the following options:
• Encryption at rest – Enables encryption of data stored on disk. For more information, see
Encryption at Rest.
Note
You have the option to supply a different encryption key by choosing Customer
Managed AWS KMS key and choosing the key. For more information, see Using
customer managed keys from AWS KMS.
• Encryption in-transit – Enables encryption of data on the wire. For more information, see
encryption in transit. For Redis engine version 6.0 and above, if you enable Encryption in-
transit you will be prompted to specify one of the following Access Control options:
• No Access Control – This is the default setting. This indicates no restrictions on user access
to the cluster.
• User Group Access Control List – Select a user group with a defined set of users that can
access the cluster. For more information, see Managing User Groups with the Console and
CLI (p. 495).
• Redis AUTH Default User – An authentication mechanism for Redis server. For more
information, see Redis AUTH.
• Redis AUTH – An authentication mechanism for Redis server. For more information, see Redis
AUTH.
Note
For Redis versions between 3.2.6 onward, excluding version 3.2.10, Redis AUTH is the
sole option.
e. (Optional) For Logs:
For more information, see Seeding a new cluster with an externally created backup (p. 337).
For Redis (cluster mode enabled), make sure that you have a separate .rdb file for each node
group.
g. For regularly scheduled automatic backups, select Enable automatic backups and then enter
the number of days that you want each automatic backup retained before it is automatically
deleted. If you don't want regularly scheduled automatic backups, clear the Enable automatic
backups check box. In either case, you always have the option to create manual backups.
For more information on Redis backup and restore, see Backup and restore for ElastiCache for
Redis (p. 310).
h. (Optional_ Specify a maintenance window. The maintenance window is the time, generally an
hour in length, each week when ElastiCache schedules system maintenance for your cluster. You
can allow ElastiCache to choose the day and time for your maintenance window (No preference),
or you can choose the day, time, and duration yourself (Specify maintenance window). If you
choose Specify maintenance window from the lists, choose the Start day, Start time, and
Duration (in hours) for your maintenance window. All times are UCT times.
To create the equivalent using the ElastiCache API or AWS CLI instead of the ElastiCache console, see the
following:
• API: CreateReplicationGroup
• CLI: create-replication-group
As soon as your cluster's status is available, you can grant EC2 access to it, connect to it, and begin using
it. For more information, see Step 3: Authorize access to the cluster (p. 52) and Step 4: Connect to the
cluster's node (p. 54).
Important
As soon as your cluster becomes available, you're billed for each hour or partial hour that the
cluster is active, even if you're not actively using it. To stop incurring charges for this cluster, you
must delete it. See Deleting a cluster (p. 165).
Creating a cache cluster for Redis (cluster mode disabled) (AWS CLI)
Example – A Redis (cluster mode disabled) Cluster with no read replicas
The following CLI code creates a Redis (cluster mode disabled) cache cluster with no replicas.
Note
When creating cluster using a node type from the r6gd family, you must pass the data-
tiering-enabled parameter.
For Windows:
For more information, see the AWS CLI for ElastiCache reference topic create-replication-group.
Topics
• Creating a Redis (cluster mode disabled) cache cluster (ElastiCache API) (p. 138)
• Creating a cache cluster in Redis (cluster mode enabled) (ElastiCache API) (p. 138)
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheCluster
&CacheClusterId=my-cluster
&CacheNodeType=cache.r4.large
&CacheParameterGroup=default.redis3.2
&Engine=redis
&EngineVersion=3.2.4
&NumCacheNodes=1
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SnapshotArns.member.1=arn%3Aaws%3As3%3A%3A%3AmyS3Bucket%2Fdump.rdb
&Timestamp=20150508T220302Z
&Version=2015-02-02
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Credential=<credential>
&X-Amz-Date=20150508T220302Z
&X-Amz-Expires=20150508T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Signature=<signature>
For more information, see the ElastiCache API reference topic CreateReplicationGroup.
The following procedure details how to view the details of a Redis (cluster mode disabled) cluster using
the ElastiCache console.
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the ElastiCache console dashboard, choose Redis to display a list of all your clusters that are
running any version of Redis.
3. To see details of a cluster, select the check box to the left of the cluster's name. Make sure that you
select a cluster running the Redis engine, not Clustered Redis. Doing this displays details about the
cluster, including the cluster's primary endpoint.
4. To view node information:
The following procedure details how to view the details of a Redis (cluster mode enabled) cluster using
the ElastiCache console.
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the list in the upper-right corner, choose the AWS Region you are interested in.
3. In the ElastiCache console dashboard, choose Redis to display a list of all your clusters that are
running any version of Redis.
4. To see details of a Redis (cluster mode enabled) cluster, choose the box to the left of the cluster's
name. Make sure you choose a cluster running the Clustered Redis engine, not just Redis.
The screen expands below the cluster and display details about the cluster, including the cluster's
configuration endpoint.
5. To see a listing of the cluster's shards and the number of nodes in each shard, choose the cluster's
name.
Doing this displays information about each node, including each node's endpoint that you need
to use to read data from the cluster.
c. To view metrics on one or more nodes, choose the box by the node's ID, and then choose a time
range for the metrics for Time range. Choosing multiple nodes generates overlay graphs.
Example
For Windows:
{
"CacheClusters": [
{
"CacheClusterStatus": "available",
"SecurityGroups": [
{
"Status": "active",
"SecurityGroupId": "sg-dbe93fa2"
}
],
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"Engine": "redis",
"PreferredMaintenanceWindow": "wed:12:00-wed:13:00",
"CacheSubnetGroupName": "default",
"SnapshotWindow": "08:30-09:30",
"TransitEncryptionEnabled": false,
"AtRestEncryptionEnabled": false,
"CacheClusterId": "my-cluster1",
"CacheClusterCreateTime": "2018-02-26T21:06:43.420Z",
"PreferredAvailabilityZone": "us-west-2c",
"AuthTokenEnabled": false,
"PendingModifiedValues": {},
"CacheNodeType": "cache.r4.large",
"DataTiering": "disabled"
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"ParameterApplyStatus": "in-sync",
"CacheParameterGroupName": "default.redis3.2"
},
"SnapshotRetentionLimit": 0,
"AutoMinorVersionUpgrade": true,
"EngineVersion": "3.2.10",
"CacheSecurityGroups": [],
"NumCacheNodes": 1
}
{
"CacheClusters": [
{
"SecurityGroups": [
{
"Status": "active",
"SecurityGroupId": "sg-dbe93fa2"
}
],
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"AuthTokenEnabled": false,
"CacheSubnetGroupName": "default",
"SnapshotWindow": "12:30-13:30",
"AutoMinorVersionUpgrade": true,
"CacheClusterCreateTime": "2018-02-26T21:13:24.250Z",
"CacheClusterStatus": "available",
"AtRestEncryptionEnabled": false,
"PreferredAvailabilityZone": "us-west-2a",
"TransitEncryptionEnabled": false,
"ReplicationGroupId": "my-cluster2",
"Engine": "redis",
"PreferredMaintenanceWindow": "sun:08:30-sun:09:30",
"CacheClusterId": "my-cluster2-001",
"PendingModifiedValues": {},
"CacheNodeType": "cache.r4.large",
"DataTiering": "disabled"
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"ParameterApplyStatus": "in-sync",
"CacheParameterGroupName": "default.redis3.2"
},
"SnapshotRetentionLimit": 0,
"EngineVersion": "3.2.10",
"CacheSecurityGroups": [],
"NumCacheNodes": 1
},
{
"SecurityGroups": [
{
"Status": "active",
"SecurityGroupId": "sg-dbe93fa2"
}
],
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"AuthTokenEnabled": false,
"CacheSubnetGroupName": "default",
"SnapshotWindow": "12:30-13:30",
"AutoMinorVersionUpgrade": true,
"CacheClusterCreateTime": "2018-02-26T21:13:24.250Z",
"CacheClusterStatus": "available",
"AtRestEncryptionEnabled": false,
"PreferredAvailabilityZone": "us-west-2b",
"TransitEncryptionEnabled": false,
"ReplicationGroupId": "my-cluster2",
"Engine": "redis",
"PreferredMaintenanceWindow": "sun:08:30-sun:09:30",
"CacheClusterId": "my-cluster2-002",
"PendingModifiedValues": {},
"CacheNodeType": "cache.r4.large",
"DataTiering": "disabled"
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"ParameterApplyStatus": "in-sync",
"CacheParameterGroupName": "default.redis3.2"
},
"SnapshotRetentionLimit": 0,
"EngineVersion": "3.2.10",
"CacheSecurityGroups": [],
"NumCacheNodes": 1
},
{
"SecurityGroups": [
{
"Status": "active",
"SecurityGroupId": "sg-dbe93fa2"
}
],
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"AuthTokenEnabled": false,
"CacheSubnetGroupName": "default",
"SnapshotWindow": "12:30-13:30",
"AutoMinorVersionUpgrade": true,
"CacheClusterCreateTime": "2018-02-26T21:13:24.250Z",
"CacheClusterStatus": "available",
"AtRestEncryptionEnabled": false,
"PreferredAvailabilityZone": "us-west-2c",
"TransitEncryptionEnabled": false,
"ReplicationGroupId": "my-cluster2",
"Engine": "redis",
"PreferredMaintenanceWindow": "sun:08:30-sun:09:30",
"CacheClusterId": "my-cluster2-003",
"PendingModifiedValues": {},
"CacheNodeType": "cache.r4.large",
"DataTiering": "disabled"
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"ParameterApplyStatus": "in-sync",
"CacheParameterGroupName": "default.redis3.2"
},
"SnapshotRetentionLimit": 0,
"EngineVersion": "3.2.10",
"CacheSecurityGroups": [],
"NumCacheNodes": 1
}
{
"CacheClusters": [
{
"SecurityGroups": [
{
"Status": "active",
"SecurityGroupId": "sg-dbe93fa2"
}
],
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"AuthTokenEnabled": true,
"CacheSubnetGroupName": "default",
"SnapshotWindow": "12:30-13:30",
"AutoMinorVersionUpgrade": true,
"CacheClusterCreateTime": "2018-02-26T21:17:01.439Z",
"CacheClusterStatus": "available",
"AtRestEncryptionEnabled": true,
"PreferredAvailabilityZone": "us-west-2a",
"TransitEncryptionEnabled": true,
"ReplicationGroupId": "my-cluster3",
"Engine": "redis",
"PreferredMaintenanceWindow": "thu:11:00-thu:12:00",
"CacheClusterId": "my-cluster3-0001-001",
"PendingModifiedValues": {},
"CacheNodeType": "cache.r4.large",
"DataTiering": "disabled"
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"ParameterApplyStatus": "in-sync",
"CacheParameterGroupName": "default.redis3.2.cluster.on"
},
"SnapshotRetentionLimit": 0,
"EngineVersion": "3.2.6",
"CacheSecurityGroups": [],
"NumCacheNodes": 1
},
{
"SecurityGroups": [
{
"Status": "active",
"SecurityGroupId": "sg-dbe93fa2"
}
],
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"AuthTokenEnabled": true,
"CacheSubnetGroupName": "default",
"SnapshotWindow": "12:30-13:30",
"AutoMinorVersionUpgrade": true,
"CacheClusterCreateTime": "2018-02-26T21:17:01.439Z",
"CacheClusterStatus": "available",
"AtRestEncryptionEnabled": true,
"PreferredAvailabilityZone": "us-west-2b",
"TransitEncryptionEnabled": true,
"ReplicationGroupId": "my-cluster3",
"Engine": "redis",
"PreferredMaintenanceWindow": "thu:11:00-thu:12:00",
"CacheClusterId": "my-cluster3-0001-002",
"PendingModifiedValues": {},
"CacheNodeType": "cache.r4.large",
"DataTiering": "disabled"
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"ParameterApplyStatus": "in-sync",
"CacheParameterGroupName": "default.redis3.2.cluster.on"
},
"SnapshotRetentionLimit": 0,
"EngineVersion": "3.2.6",
"CacheSecurityGroups": [],
"NumCacheNodes": 1
},
{
"SecurityGroups": [
{
"Status": "active",
"SecurityGroupId": "sg-dbe93fa2"
}
],
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"AuthTokenEnabled": true,
"CacheSubnetGroupName": "default",
"SnapshotWindow": "12:30-13:30",
"AutoMinorVersionUpgrade": true,
"CacheClusterCreateTime": "2018-02-26T21:17:01.439Z",
"CacheClusterStatus": "available",
"AtRestEncryptionEnabled": true,
"PreferredAvailabilityZone": "us-west-2c",
"TransitEncryptionEnabled": true,
"ReplicationGroupId": "my-cluster3",
"Engine": "redis",
"PreferredMaintenanceWindow": "thu:11:00-thu:12:00",
"CacheClusterId": "my-cluster3-0001-003",
"PendingModifiedValues": {},
"CacheNodeType": "cache.r4.large",
"DataTiering": "disabled"
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"ParameterApplyStatus": "in-sync",
"CacheParameterGroupName": "default.redis3.2.cluster.on"
},
"SnapshotRetentionLimit": 0,
"EngineVersion": "3.2.6",
"CacheSecurityGroups": [],
"NumCacheNodes": 1
},
{
"SecurityGroups": [
{
"Status": "active",
"SecurityGroupId": "sg-dbe93fa2"
}
],
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"AuthTokenEnabled": true,
"CacheSubnetGroupName": "default",
"SnapshotWindow": "12:30-13:30",
"AutoMinorVersionUpgrade": true,
"CacheClusterCreateTime": "2018-02-26T21:17:01.439Z",
"CacheClusterStatus": "available",
"AtRestEncryptionEnabled": true,
"PreferredAvailabilityZone": "us-west-2b",
"TransitEncryptionEnabled": true,
"ReplicationGroupId": "my-cluster3",
"Engine": "redis",
"PreferredMaintenanceWindow": "thu:11:00-thu:12:00",
"CacheClusterId": "my-cluster3-0002-001",
"PendingModifiedValues": {},
"CacheNodeType": "cache.r4.large",
"DataTiering": "disabled"
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"ParameterApplyStatus": "in-sync",
"CacheParameterGroupName": "default.redis3.2.cluster.on"
},
"SnapshotRetentionLimit": 0,
"EngineVersion": "3.2.6",
"CacheSecurityGroups": [],
"NumCacheNodes": 1
},
{
"SecurityGroups": [
{
"Status": "active",
"SecurityGroupId": "sg-dbe93fa2"
}
],
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"AuthTokenEnabled": true,
"CacheSubnetGroupName": "default",
"SnapshotWindow": "12:30-13:30",
"AutoMinorVersionUpgrade": true,
"CacheClusterCreateTime": "2018-02-26T21:17:01.439Z",
"CacheClusterStatus": "available",
"AtRestEncryptionEnabled": true,
"PreferredAvailabilityZone": "us-west-2c",
"TransitEncryptionEnabled": true,
"ReplicationGroupId": "my-cluster3",
"Engine": "redis",
"PreferredMaintenanceWindow": "thu:11:00-thu:12:00",
"CacheClusterId": "my-cluster3-0002-002",
"PendingModifiedValues": {},
"CacheNodeType": "cache.r4.large",
"DataTiering": "disabled"
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"ParameterApplyStatus": "in-sync",
"CacheParameterGroupName": "default.redis3.2.cluster.on"
},
"SnapshotRetentionLimit": 0,
"EngineVersion": "3.2.6",
"CacheSecurityGroups": [],
"NumCacheNodes": 1
},
{
"SecurityGroups": [
{
"Status": "active",
"SecurityGroupId": "sg-dbe93fa2"
}
],
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"AuthTokenEnabled": true,
"CacheSubnetGroupName": "default",
"SnapshotWindow": "12:30-13:30",
"AutoMinorVersionUpgrade": true,
"CacheClusterCreateTime": "2018-02-26T21:17:01.439Z",
"CacheClusterStatus": "available",
"AtRestEncryptionEnabled": true,
"PreferredAvailabilityZone": "us-west-2a",
"TransitEncryptionEnabled": true,
"ReplicationGroupId": "my-cluster3",
"Engine": "redis",
"PreferredMaintenanceWindow": "thu:11:00-thu:12:00",
"CacheClusterId": "my-cluster3-0002-003",
"PendingModifiedValues": {},
"CacheNodeType": "cache.r4.large",
"DataTiering": "disabled"
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"ParameterApplyStatus": "in-sync",
"CacheParameterGroupName": "default.redis3.2.cluster.on"
},
"SnapshotRetentionLimit": 0,
"EngineVersion": "3.2.6",
"CacheSecurityGroups": [],
"NumCacheNodes": 1
}
]
}
For more information, see the AWS CLI for ElastiCache topic describe-cache-clusters.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=my-cluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&MaxRecords=25
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see the ElastiCache API reference topic DescribeCacheClusters.
We recommend that you have your maintenance window fall at the time of lowest usage. Thus it might
need modification from time to time.
When you change a cluster's parameters, the change is applied to the cluster either immediately or
after the cluster is restarted. This is true whether you change the cluster's parameter group itself or a
parameter value within the cluster's parameter group. To determine when a particular parameter change
is applied, see the Changes Take Effect column in the tables for Redis-specific parameters (p. 441).
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the list in the upper-right corner, choose the AWS Region where the cluster that you want to
modify is located.
3. In the navigation pane, choose the engine running on the cluster that you want to modify.
• Description
• Engine Version Compatibility
Important
You can upgrade to newer engine versions. If you upgrade major engine versions,
for example from 5.0.6 to 6.0, you need to select a parameter group family that
is compatible with the new engine version. For more information on doing so, see
Upgrading engine versions (p. 198). However, you can't downgrade to older engine
versions except by deleting the existing cluster and creating it again.
• VPC Security Group(s)
• Parameter Group
• Node Type
Note
If the cluster is using a node type from the r6gd family, you can only choose a different
node size from within that family. If you choose a node type from the r6gd family, data
tiering will automatically be enabled. For more information, see Data tiering.
• Multi-AZ
• Auto failover (cluster mode disabled only)
• Enable Automatic Backups
• Backup Node Id
• Backup Retention Period
• Backup Window
The Apply Immediately box applies only to node type and engine version modifications. To apply
changes immediately, choose the Apply Immediately check box. If this box is not chosen, node
type and engine version modifications are applied during the next maintenance window. Other
modifications, such as changing the maintenance window, are applied immediately.
7. Choose Modify.
1. From the list of clusters, choose the cluster you want to modify. Choose the Cluster name and not
the checkbox beside it.
2. On the Cluster name page, choose the Logs tab.
3. To enable/disable slow logs, choose either Enable slow logs or Disable slow logs.
4. To change your configuration, choose Modify slow logs:
For Windows:
The --apply-immediately parameter applies only to modifications in node type, engine version,
and changing the number of nodes in a cluster. If you want to apply any of these changes immediately,
use the --apply-immediately parameter. If you prefer postponing these changes to your next
maintenance window, use the --no-apply-immediately parameter. Other modifications, such as
changing the maintenance window, are applied immediately.
For more information, see the AWS CLI for ElastiCache topic modify-cache-cluster.
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheCluster
&CacheClusterId=my-cluster
&PreferredMaintenanceWindow=sun:23:00-mon:02:00
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150901T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20150202T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20150901T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
The ApplyImmediately parameter applies only to modifications in node type, engine version, and
changing the number of nodes in a cluster. If you want to apply any of these changes immediately,
set the ApplyImmediately parameter to true. If you prefer postponing these changes to your next
maintenance window, set the ApplyImmediately parameter to false. Other modifications, such as
changing the maintenance window, are applied immediately.
For more information, see the ElastiCache API reference topic ModifyCacheCluster.
You can use the ElastiCache Management Console, the AWS CLI or ElastiCache API to add nodes to your
cluster.
Topics
The following procedure adds replication to a single-node Redis that does not have replication enabled.
When you add replication, the existing node becomes the primary node in the replication-enabled
cluster. After replication is added, you can add up to 5 replica nodes to the cluster.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Redis.
The following is true of a Redis cluster that does not have replication enabled:
If the cluster has any shards, replication is already enabled on it and you can continue at To add
nodes to a cluster (console) (p. 152).
4. Choose Add replication.
5. In Add Replication, enter a description for this replication-enabled cluster.
6. Choose Add.
As soon as the cluster's status returns to available you can continue at the next procedure and add
replicas to the cluster.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose the engine running on the cluster that you want to add nodes to.
If your cluster is a Redis (cluster mode enabled) cluster, see Scaling clusters in Redis (Cluster Mode
Enabled) (p. 375).
If your cluster is a Redis (cluster mode disabled) cluster with zero shards, first complete the steps at
To add replication to a Redis cluster with no shards (p. 152).
4. Choose Add node.
5. Complete the information requested in the Add Node dialog box.
6. Choose the Apply Immediately - Yes button to add this node immediately, or choose No to add this
node during the cluster's next maintenance window.
Scenario 4 Create Create The new create request is added to the pending create
request.
To determine what operations are pending, choose the Description tab and check to see how many
pending creations or deletions are shown. You cannot have both pending creations and pending
deletions.
After a few moments, the new nodes should appear in the nodes list with a status of creating. If
they don't appear, refresh your browser page. When the node's status changes to available the new
node is able to be used.
To add nodes to a cluster using the AWS CLI, use the AWS CLI operation increase-replica-count
with the following parameters:
• --replication-group-id The ID of the replicationn group that you want to add nodes to.
• --new-replica-count specifies the number of nodes that you want in this replication group after
the modification is applied. To add nodes to this cluster, --new-replica-count must be greater
than the current number of nodes in this cluster.
• --apply-immediately or --no-apply-immediately which specifies whether to add these nodes
immediately or at the next maintenance window.
For Windows:
{
"ReplicationGroup": {
"ReplicationGroupId": "node-test",
"Description": "node-test",
"Status": "modifying",
"PendingModifiedValues": {},
"MemberClusters": [
"node-test-001",
"node-test-002",
"node-test-003",
"node-test-004",
"node-test-005"
],
"NodeGroups": [
{
"NodeGroupId": "0001",
"Status": "modifying",
"PrimaryEndpoint": {
"Address": "node-test.zzzzzz.ng.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"ReaderEndpoint": {
"Address": "node-test.zzzzzz.ng.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"NodeGroupMembers": [
{
"CacheClusterId": "node-test-001",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Address": "node-
test-001.zzzzzz.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"PreferredAvailabilityZone": "us-west-2a",
"CurrentRole": "primary"
},
{
"CacheClusterId": "node-test-002",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Address": "node-
test-002.zzzzzz.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"PreferredAvailabilityZone": "us-west-2c",
"CurrentRole": "replica"
},
{
"CacheClusterId": "node-test-003",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Address": "node-
test-003.zzzzzz.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"PreferredAvailabilityZone": "us-west-2b",
"CurrentRole": "replica"
}
]
}
],
"SnapshottingClusterId": "node-test-002",
"AutomaticFailover": "enabled",
"MultiAZ": "enabled",
"SnapshotRetentionLimit": 1,
"SnapshotWindow": "07:30-08:30",
"ClusterEnabled": false,
"CacheNodeType": "cache.r5.large",
"DataTiering": "disabled"
"TransitEncryptionEnabled": false,
"AtRestEncryptionEnabled": false,
"ARN": "arn:aws:elasticache:us-west-2:123456789012:replicationgroup:node-test"
}
}
• ReplicationGroupId The ID of the cluster that you want to add nodes to.
• NewReplicaCount The NewReplicaCount parameter specifies the number of nodes
that you want in this cluster after the modification is applied. To add nodes to this cluster,
NewReplicaCount must be greater than the current number of nodes in this cluster. If this value
is less than the current number of nodes, use the DecreaseReplicaCount API with the number
of nodes to remove from the cluster.
• ApplyImmediately Specifies whether to add these nodes immediately or at the next
maintenance window.
• Region Specifies the AWS Region of the cluster that you want to add nodes to.
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=IncreaseReplicaCount
&ApplyImmediately=true
&NumCacheNodes=4
&ReplicationGroupId=my-replication-group
&Region=us-east-2
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the list in the upper-right corner, choose the AWS Region of the cluster that you want to
remove nodes from.
3. In the navigation pane, choose the engine running on the cluster that you want to remove a node.
Scenario 1 Delete Delete The new delete request, pending or immediate, replaces
the pending delete request.
Scenario 2 Delete Create The new create request, pending or immediate, replaces
the pending delete request.
Scenario 3 Create Delete The new delete request, pending or immediate, replaces
the pending create request.
Scenario 4 Create Create The new create request is added to the pending create
request.
To determine what operations are pending, choose the Description tab and check to see how many
pending creations or deletions are shown. You cannot have both pending creations and pending
deletions.
To remove nodes from a cluster using the command-line interface, use the command decrease-
replica-count with the following parameters:
• --replication-group-id The ID of the replication group that you want to remove nodes from.
• --new-replica-count The --new-replica-count parameter specifies the number of nodes
that you want in this cluster after the modification is applied.
• --replicas-to-remove A list of node IDs that you want removed from this cluster.
• --apply-immediately or --no-apply-immediately Specifies whether to remove these
nodes immediately or at the next maintenance window.
• --region Specifies the AWS Region of the cluster that you want to remove nodes from.
Note
You can pass only one of --replicas-to-remove or --new-replica-count
parameters when calling this operation.
For Windows:
{
"ReplicationGroup": {
"ReplicationGroupId": "node-test",
"Description": "node-test"
},
"Status": "modifying",
"PendingModifiedValues": {},
"MemberClusters": [
"node-test-001",
"node-test-002",
"node-test-003",
"node-test-004",
"node-test-005",
"node-test-006"
],
"NodeGroups": [
{
"NodeGroupId": "0001",
"Status": "modifying",
"PrimaryEndpoint": {
"Address": "node-test.zzzzzz.ng.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"ReaderEndpoint": {
"Address": "node-test-ro.zzzzzz.ng.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"NodeGroupMembers": [
{
"CacheClusterId": "node-test-001",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Address": "node-
test-001.zzzzzz.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"PreferredAvailabilityZone": "us-west-2a",
"CurrentRole": "primary"
},
{
"CacheClusterId": "node-test-002",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Address": "node-
test-002.zzzzzz.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"PreferredAvailabilityZone": "us-west-2c",
"CurrentRole": "replica"
},
{
"CacheClusterId": "node-test-003",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Address": "node-
test-003.zzzzzz.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"PreferredAvailabilityZone": "us-west-2b",
"CurrentRole": "replica"
},
{
"CacheClusterId": "node-test-004",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Address": "node-
test-004.zzzzzz.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"PreferredAvailabilityZone": "us-west-2c",
"CurrentRole": "replica"
},
{
"CacheClusterId": "node-test-005",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Address": "node-
test-005.zzzzzz.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"PreferredAvailabilityZone": "us-west-2b",
"CurrentRole": "replica"
},
{
"CacheClusterId": "node-test-006",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Address": "node-
test-006.zzzzzz.0001.usw2.cache.amazonaws.com",
"Port": 6379
},
"PreferredAvailabilityZone": "us-west-2b",
"CurrentRole": "replica"
}
]
}
],
"SnapshottingClusterId": "node-test-002",
"AutomaticFailover": "enabled",
"MultiAZ": "enabled",
"SnapshotRetentionLimit": 1,
"SnapshotWindow": "07:30-08:30",
"ClusterEnabled": false,
"CacheNodeType": "cache.r5.large",
"DataTiering": "disabled"
"TransitEncryptionEnabled": false,
"AtRestEncryptionEnabled": false,
"ARN": "arn:aws:elasticache:us-west-2:123456789012:replicationgroup:node-test"
}
}
Alternatively, you could call decrease-replica-count and instead of passing in the --new-
replica-count parameter, you could pass the --replicas-to-remove parameter, as shown
following:
For Windows:
• ReplicationGroupId The ID of the replication group that you want to remove nodes from.
• ReplicasToRemove The ReplicasToRemove parameter specifies the number of nodes that you
want in this cluster after the modification is applied.
• ApplyImmediately Specifies whether to remove these nodes immediately or at the next
maintenance window.
• Region Specifies the AWS Region of the cluster that you want to remove a node from.
The following example immediately removes nodes 0004 and 0005 from the cluster my-cluster.
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ReplicationGroupId=my-replication-group
&ApplyImmediately=true
&ReplicasToRemove=node-test-003
&Region us-east-2
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the list in the upper-right corner, choose the AWS Region that you want to cancel a pending
add or delete node operation in.
3. In the navigation pane, choose the engine running on the cluster that has pending operations that
you want to cancel. A list of clusters running the chosen engine appears.
4. In the list of clusters, choose the name of the cluster, not the box to the left of the cluster's name,
that has pending operations that you want to cancel.
5. To determine what operations are pending, choose the Description tab and check to see how many
pending creations or deletions are shown. You cannot have both pending creations and pending
deletions.
Deleting a cluster
As long as a cluster is in the available state, you are being charged for it, whether or not you are actively
using it. To stop incurring charges, delete the cluster.
Warning
When you delete an ElastiCache for Redis cluster, your manual snapshots are retained. You can
also create a final snapshot before the cluster is deleted. Automatic cache snapshots are not
retained.
To delete a cluster
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the ElastiCache console dashboard, choose the engine the cluster that you want to delete is
running.
As soon as your cluster is no longer listed in the list of clusters, you stop incurring charges for it.
The delete-cache-cluster CLI action only deletes one cache cluster. To delete multiple cache
clusters, call delete-cache-cluster for each cache cluster that you want to delete. You do not need
to wait for one cache cluster to finish deleting before deleting another.
For Windows:
For more information, see the AWS CLI for ElastiCache topic delete-cache-cluster.
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteCacheCluster
&CacheClusterId=my-cluster
&Region us-east-2
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20150202T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20150202T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
The DeleteCacheCluster API operation only deletes one cache cluster. To delete multiple cache
clusters, call DeleteCacheCluster for each cache cluster that you want to delete. You do not need to
wait for one cache cluster to finish deleting before deleting another.
For more information, see the ElastiCache API reference topic DeleteCacheCluster.
If you launched your ElastiCache instance in an Amazon Virtual Private Cloud (Amazon VPC), you can
access your ElastiCache instance from an Amazon EC2 instance in the same Amazon VPC. Or, by using
VPC peering, you can access your ElastiCache instance from an Amazon EC2 in a different Amazon VPC.
If you launched your ElastiCache instance in EC2 Classic, you allow the EC2 instance to access your cluster
by granting the Amazon EC2 security group associated with the instance access to your cache security
group. By default, access to a cluster is restricted to the account that launched the cluster.
Topics
• Determine the cluster's platform (p. 167)
• Grant access to your cluster or replication group (p. 169)
For more information, see Detecting Your Supported Platforms and Whether You Have a Default VPC.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. To see a list of your clusters running the Redis engine, in the left navigation pane, choose Redis.
3. In the list of clusters, expand the cluster you want to authorize access to by choosing the box to the
left of the cluster name.
4. Locate Subnet group:.
• If the Subnet group has a name, as shown here, you launched your cluster in EC2-VPC and
should continue at You launched your cluster into EC2-VPC (p. 169).
• If there is a dash (-) instead of a Subnet group name, you launched your cluster in EC2-Classic
and should continue at You launched your cluster running in EC2-Classic (p. 170).
For more information, see Detecting Your Supported Platforms and Whether You Have a Default VPC.
For Windows:
JSON output from this command will look something like this. Some of the output is omitted to
save space.
{
"CacheClusters": [
{
"Engine": "redis",
"AuthTokenEnabled": false,
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"CacheParameterGroupName": "default.redis3.2",
"ParameterApplyStatus": "in-sync"
},
"CacheClusterId": "my-cluster-001",
"CacheSecurityGroups": [],
"NumCacheNodes": 1,
"AtRestEncryptionEnabled": false,
"CacheClusterCreateTime": "2018-01-16T20:09:34.449Z",
"ReplicationGroupId": "my-cluster",
"AutoMinorVersionUpgrade": true,
"CacheClusterStatus": "available",
"PreferredAvailabilityZone": "us-east-2a",
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"SecurityGroups": [
{
"Status": "active",
"SecurityGroupId": "sg-e8c03081"
}
],
"TransitEncryptionEnabled": false,
"CacheSubnetGroupName": "default",
"EngineVersion": "3.2.10",
"PendingModifiedValues": {},
"PreferredMaintenanceWindow": "sat:05:30-sat:06:30",
"CacheNodeType": "cache.t2.medium",
"DataTiering": "disabled"
}
]
}
• If there is a value for CacheSubnetGroupName, you launched your cluster in EC2-VPC and
should continue at You launched your cluster into EC2-VPC (p. 169).
• If there is no value for CacheSubnetGroupName, you launched your cluster in EC2-Classic and
should continue at You launched your cluster running in EC2-Classic (p. 170).
1. Sign in to the AWS Management Console and open the Amazon EC2 console at https://
console.aws.amazon.com/ec2/.
2. In the navigation pane, under Network & Security, choose Security Groups.
3. From the list of security groups, choose the security group for your Amazon VPC. Unless you created
a security group for ElastiCache use, this security group will be named default.
4. Choose the Inbound tab, and then do the following:
a. Choose Edit.
b. Choose Add rule.
c. In the Type column, choose Custom TCP rule.
d. In the Port range box, type the port number for your cluster node. This number must be the
same one that you specified when you launched the cluster. The default port for Redis is 6379.
e. In the Source box, choose Anywhere which has the port range (0.0.0.0/0) so that any Amazon
EC2 instance that you launch within your Amazon VPC can connect to your ElastiCache nodes.
Important
Opening up the ElastiCache cluster to 0.0.0.0/0 does not expose the cluster to the
Internet because it has no public IP address and therefore cannot be accessed from
outside the VPC. However, the default security group may be applied to other Amazon
EC2 instances in the customer’s account, and those instances may have a public IP
address. If they happen to be running something on the default port, then that service
could be exposed unintentionally. Therefore, we recommend creating a VPC Security
Group that will be used exclusively by ElastiCache. For more information, see Custom
Security Groups.
f. Choose Save.
When you launch an Amazon EC2 instance into your Amazon VPC, that instance will be able to connect
to your ElastiCache cluster.
API Version 2015-02-02
169
Amazon ElastiCache for Redis User Guide
Grant access to your cluster or replication group
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. To see a list of security groups, from the left navigation pane, choose Security Groups.
Important
If Security Groups is not listed in the navigation pane, you launched your cluster in EC2-
VPC rather than EC2-Classic and should follow the instructions at You launched your cluster
into EC2-VPC (p. 169).
3. Choose the box to the left of default security group.
4. From the list at the bottom of the screen, choose the EC2 Security Group Name you want to
authorize.
5. To authorize access, choose Add.
Amazon EC2 instances that are associated with the security group are now authorized to connect to
your ElastiCache cluster.
To revoke a security group's access, locate the security group in the list of authorized security groups, and
then choose Remove.
For more information on ElastiCache Security Groups, see Security groups: EC2-Classic (p. 532).
Using the AWS Client VPN, you allow external access to your Elasticache nodes with the following
benefits:
Topics
• Create a certificate authority (p. 171)
• Configuring AWS client VPN components (p. 172)
• Configure the VPN client (p. 174)
To submit the server's certificates to ACM using the AWS CLI, run the following command: aws
acm import-certificate --certificate fileb://easy-rsa/pki/issued/server.crt
--private-key fileb://easy-rsa/pki/private/server.key --certificate-chain
file://easy-rsa/pki/ca.crt --region region
Under Virtual Private Network, select Client VPN Endpoints and do the following:
Example output:
"ClientVpnEndpointId": "cvpn-endpoint-0123456789abcdefg",
"Status": { "Code": "pending-associate" }, "DnsName": "cvpn-
endpoint-0123456789abcdefg.prod.clientvpn.us-east-1.amazonaws.com" }
• Select the new VPN endpoint, and then select the Associations tab.
• Select Associate and specify the following options.
• VPC: Select the Elasticache Cluster's VPC.
• Select one of the Elasticache cluster's networks. If in doubt, review the networks in the Subnet
Groups on the Elasticache dashboard.
• Select Associate. If necessary, repeat the steps for the remaining networks.
Example output:
The VPN Enpoint will automatically adopt the VPC's default security group. Check the inbound and
outbound rules and confirm if the security group allows the traffic from the VPN network (defined on the
VPN Endpoint settings) to the Elasticache networks on the service ports (by default, 6379 for Redis and
11211 for Memcached).
If you need to change the security group assigned to the VPN Endpoint, proceed as follows:
Example output:
"SecurityGroupIds": [ "sg-0123456789abdcdef" ] }
Note
The ElastiCache security group also needs to allow traffic coming from the VPN clients. The
clients' addresses will be masked with the VPN Endpoint address, according to the VPC Network.
Therefore, consider the VPC network (not the VPN Clients' network) when creating the inbound
rule on the Elasticache security group.
On the Authorization tab, select Authorize Ingress and specify the following:
• Destination network to enable access: Either use 0.0.0.0/0 to allow access to any network (including
the Internet) or restrict the the Elasticache networks/hosts.
• Under Grant access to:, select Allow access to all users.
• Select Add Authorization Rules.
Example output:
If you need to browse the Internet through the VPN, you need to create an additional route. Select the
Route Table tab and then select Create Route:
Example output:
• cert: add a new line with the parameter cert pointing to the client1.domain.tld.crt file. Use the
full path to the file. Example: cert /home/user/.cert/client1.domain.tld.crt
• cert: key: add a new line with the parameter key pointing to the client1.domain.tld.key file. Use
the full path to the file. Example: key /home/user/.cert/client1.domain.tld.key
Establish the VPN connection with the command: sudo openvpn --config downloaded-client-
config.ovpn
Revoking access
If you need to invalidate the access from a particular client key, the key needs to be revoked in the CA.
Then submit the revocation list to AWS Client VPN.
• cd easy-rsa
• ./easyrsa3/easyrsa revoke client1.domain.tld
• Enter "yes" to continue, or any other input to abort.
• Select the Client VPN Endpoint and then select Actions -> Import Client Certificate CRL.
• Paste the contents of the crl.pem file.
Example output:
• Redis standalone node, use the node's endpoint for both read and write operations.
• Redis (cluster mode disabled) clusters, use the Primary Endpoint for all write operations. Use the
Reader Endpoint to evenly split incoming connections to the endpoint between all read replicas.
Use the individual Node Endpoints for read operations (In the API/CLI these are referred to as Read
Endpoints).
• Redis (cluster mode enabled) clusters, use the cluster's Configuration Endpoint for all operations that
support cluster mode enabled commands. You must use a client that supports Redis Cluster (Redis
3.2). You can still read from individual node endpoints (In the API/CLI these are referred to as Read
Endpoints).
The following sections guide you through discovering the endpoints you'll need for the engine you're
running.
The primary endpoint is a DNS name that always resolves to the primary node in the cluster. The primary
endpoint is immune to changes to your cluster, such as promoting a read replica to the primary role. For
write activity, we recommend that your applications connect to the primary endpoint.
A reader endpoint will evenly split incoming connections to the endpoint between all read replicas in a
ElastiCache for Redis cluster. Additional factors such as when the application creates the connections or
how the application (re)-uses the connections will determine the traffic distribution. Reader endpoints
keep up with cluster changes in real-time as replicas are added or removed. You can place your
ElastiCache for Redis cluster’s multiple read replicas in different AWS Availability Zones (AZ) to ensure
high availability of reader endpoints.
Note
A reader endpoint is not a load balancer. It is a DNS record that will resolve to an IP address of
one of the replica nodes in a round robin fashion.
For read activity, applications can also connect to any node in the cluster. Unlike the primary endpoint,
node endpoints resolve to specific endpoints. If you make a change in your cluster, such as adding or
deleting a replica, you must update the node endpoints in your application.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Redis.
The clusters screen will appear with a list of Redis (cluster mode disabled) and Redis (cluster mode
enabled) clusters.
3. To find the cluster's Primary and/or Reader endpoints, choose the box to the left of cluster's name.
Primary and Reader endpoints for a Redis (cluster mode disabled) cluster
If there is only one node in the cluster, there is no primary endpoint and you can continue at the
next step.
4. If the Redis (cluster mode disabled) cluster has replica nodes, you can find the cluster's replica node
endpoints by choosing the cluster's name.
The nodes screen appears with each node in the cluster, primary and replicas, listed with its
endpoint.
a. One endpoint at a time, find then highlight the endpoint you want to copy.
b. Right-click the highlighted endpoint, then choose Copy from the context menu.
The highlighted endpoint is now copied to your clipboard. For information on using the endpoint to
connect to a node, see Connecting to nodes (p. 97).
A Redis (cluster mode disabled) primary endpoint looks something like the following. There is a
difference depending upon whether or not In-Transit encryption is enabled.
clusterName.xxxxxx.nodeId.regionAndAz.cache.amazonaws.com:port
redis-01.7abc2d.0001.usw2.cache.amazonaws.com:6379
master.clusterName.xxxxxx.regionAndAz.cache.amazonaws.com:port
master.ncit.ameaqx.use1.cache.amazonaws.com:6379
The following procedure demonstrates how to find and copy Redis (cluster mode enabled) cluster
endpoints.
To find the configuration endpoint for a Redis (cluster mode enabled) cluster
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Redis.
To find the node endpoints for a Redis (cluster mode enabled) cluster
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Redis.
1. Find the endpoint you want to copy using one of the preceeding procedures.
2. Highlight the endpoint that you want to copy.
3. Right-click the highlighted endpoint and choose Copy from the context menu.
The highlighted endpoint is now copied to your clipboard. For information on using the endpoint to
connect to a node, see Connecting to nodes (p. 97).
A Redis (cluster mode enabled) configuration endpoint looks something like the following.
clusterName.xxxxxx.regionAndAz.cache.amazonaws.com:port
rce.ameaqx.use1.cache.amazonaws.com:6379
clustercfg.clusterName.xxxxxx.regionAndAz.cache.amazonaws.com:port
clustercfg.rce.ameaqx.use1.cache.amazonaws.com:6379
Topics
• Finding Endpoints for Nodes and Clusters (AWS CLI) (p. 180)
• Finding the Endpoints for Replication Groups (AWS CLI) (p. 181)
Example
The following command retrieves the cluster information for the single-node Redis (cluster mode
disabled) cluster mycluster.
Important
The parameter --cache-cluster-id can be used with single-node Redis (cluster mode
disabled) cluster id or specific node ids in Redis replication groups. The --cache-cluster-id
of a Redis replication group is a 4-digit value such as 0001. If --cache-cluster-id is the id
of a cluster (node) in a Redis replication group, the replication-group-id is included in the
output.
For Windows:
Output from the above operation should look something like this (JSON format).
{
"CacheClusters": [
{
"CacheClusterStatus": "available",
"SecurityGroups": [
{
"SecurityGroupId": "sg-77186e0d",
"Status": "active"
}
],
"CacheNodes": [
{
"CustomerAvailabilityZone": "us-east-1b",
"CacheNodeCreateTime": "2018-04-25T18:19:28.241Z",
"CacheNodeStatus": "available",
"CacheNodeId": "0001",
"Endpoint": {
"Address": "redis-cluster.ameaqx.0001.use1.cache.amazonaws.com",
"Port": 6379
},
"ParameterGroupStatus": "in-sync"
}
],
"AtRestEncryptionEnabled": false,
"CacheClusterId": "redis-cluster",
"TransitEncryptionEnabled": false,
"CacheParameterGroup": {
"ParameterApplyStatus": "in-sync",
"CacheNodeIdsToReboot": [],
"CacheParameterGroupName": "default.redis3.2"
},
"NumCacheNodes": 1,
"PreferredAvailabilityZone": "us-east-1b",
"AutoMinorVersionUpgrade": true,
"Engine": "redis",
"AuthTokenEnabled": false,
"PendingModifiedValues": {},
"PreferredMaintenanceWindow": "tue:08:30-tue:09:30",
"CacheSecurityGroups": [],
"CacheSubnetGroupName": "default",
"CacheNodeType": "cache.t2.small",
"DataTiering": "disabled"
"EngineVersion": "3.2.10",
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"CacheClusterCreateTime": "2018-04-25T18:19:28.241Z"
}
]
}
The following operation retrieves the primary endpoint and reader endpoint for the replication group
myreplgroup. Use the primary endpoint for all write operations.
For Windows:
Output from this operation should look something like this (JSON format).
{
"ReplicationGroups": [
{
"Status": "available",
"Description": "test",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "myreplgroup-001.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "myreplgroup-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "myreplgroup-002.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "myreplgroup-002"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "myreplgroup-003.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "myreplgroup-003"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "myreplgroup.1abc4d.ng.0001.usw2.cache.amazonaws.com"
},
"ReaderEndpoint": {
"Port": 6379,
"Address": "myreplgroup-ro.1abc4d.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "myreplgroup",
"AutomaticFailover": "enabled",
"SnapshottingClusterId": "myreplgroup-002",
"MemberClusters": [
"myreplgroup-001",
"myreplgroup-002",
"myreplgroup-003"
],
"PendingModifiedValues": {}
}
]
}
For more information, see describe-replication-groups in the AWS CLI Command Reference.
Topics
• Finding Endpoints for Nodes and Clusters (ElastiCache API) (p. 183)
• Finding Endpoints for Replication Groups (ElastiCache API) (p. 183)
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=mycluster
&ShowCacheNodeInfo=true
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=<credential>
The following operation retrieves the primary endpoint (PrimaryEndpoint), reader endpoint
(ReaderEndpoint) and individual node endpoints (ReadEndpoint) for the replication group
myreplgroup. Use the primary endpoint for all write operations.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=myreplgroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=<credential>
The cluster's data is partitioned across the cluster's shards. If there is more than one node in a shard, the
shard implements replication with one node being the read/write primary node and the other nodes
read-only replica nodes.
The node or shard limit can be increased to a maximum of 500 per cluster if the Redis engine version
is 5.0.6 or higher. For example, you can choose to configure a 500 node cluster that ranges between
83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and no replicas). Make
sure there are enough available IP addresses to accommodate the increase. Common pitfalls include the
subnets in the subnet group have too small a CIDR range or the subnets are shared and heavily used by
other clusters. For more information, see Creating a subnet group (p. 525).
To request a limit increase, see AWS service limits and choose the limit type Nodes per cluster per
instance type.
When you create a Redis (cluster mode enabled) cluster using the ElastiCache console, you specify
the number of shards in the cluster and the number of nodes in the shards. For more information, see
Creating a Redis (cluster mode enabled) cluster (Console) (p. 132). If you use the ElastiCache API or AWS
CLI to create a cluster (called replication group in the API/CLI), you can configure the number of nodes in
a shard (API/CLI: node group) independently. For more information, see the following:
• API: CreateReplicationGroup
• CLI: create-replication-group
Each node in a shard has the same compute, storage and memory specifications. The ElastiCache API
lets you control shard-wide attributes, such as the number of nodes, security settings, and system
maintenance windows.
For more information, see Offline resharding and shard rebalancing for Redis (cluster mode
enabled) (p. 376) and Online resharding and shard rebalancing for Redis (cluster mode
enabled) (p. 377).
Finding a shard's ID
You can find a shard's ID using the AWS Management Console, the AWS CLI or the ElastiCache API.
Topics
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Redis, then choose the name of the Redis (cluster mode enabled)
replication group you want to find the shard IDs for.
3. In the Shard Name column, the shard ID is the last four digits of the shard name.
• --replication-group-id—An optional parameter which when used limits the output to the
details of the specified replication group. If this parameter is omitted, the details of up to 100
replication groups is returned.
Example
This command returns the details for sample-repl-group.
For Windows:
Output from this command looks something like this. The shard (node group) ids are highlighted here
to make finding them easier.
{
"ReplicationGroups": [
{
"Status": "available",
"Description": "2 shards, 2 nodes (1 + 1 replica)",
"NodeGroups": [
{
"Status": "available",
"Slots": "0-8191",
"NodeGroupId": "0001",
"NodeGroupMembers": [
{
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"CacheClusterId": "sample-repl-group-0001-001"
},
{
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"CacheClusterId": "sample-repl-group-0001-002"
}
]
},
{
"Status": "available",
"Slots": "8192-16383",
"NodeGroupId": "0002",
"NodeGroupMembers": [
{
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"CacheClusterId": "sample-repl-group-0002-001"
},
{
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"CacheClusterId": "sample-repl-group-0002-002"
}
]
}
],
"ConfigurationEndpoint": {
"Port": 6379,
"Address": "sample-repl-group.9dcv5r.clustercfg.usw2.cache.amazonaws.com"
},
"ClusterEnabled": true,
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotWindow": "13:00-14:00",
"MemberClusters": [
"sample-repl-group-0001-001",
"sample-repl-group-0001-002",
"sample-repl-group-0002-001",
"sample-repl-group-0002-002"
],
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled"
"PendingModifiedValues": {}
}
]
}
• ReplicationGroupId—An optional parameter which when used limits the output to the details of
the specified replication group. If this parameter is omitted, the details of up to xxx replication groups
is returned.
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroup
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
Topics
• Engine versions and upgrading (p. 188)
• Tagging your ElastiCache resources (p. 204)
• Caching strategies and best practices (p. 215)
• Managing maintenance (p. 230)
• Replication across AWS Regions using global datastores (p. 231)
• High availability using replication groups (p. 246)
• Backup and restore for ElastiCache for Redis (p. 310)
• Scaling ElastiCache for Redis clusters (p. 345)
• Auto Scaling ElastiCache for Redis clusters (p. 394)
• Configuring engine parameters using parameter groups (p. 423)
Topics
• Supported ElastiCache for Redis versions (p. 189)
• Redis versions end of life schedule (p. 197)
• Upgrading engine versions (p. 198)
• Major version behavior and compatibility differences (p. 200)
Note
Because the newer Redis versions provide a better and more stable user experience, Redis
versions 5.0.0, 5.0.3, 5.0.4 and 5.0.5 as well as 2.6.13, 2.8.6, and 2.8.19 are deprecated when
using the ElastiCache console. We recommend against using these Redis versions. If you need to
use one of them, work with the AWS CLI or ElastiCache API.
For more information, see the following topics:
You can't use this action to You can't use this action to
create a replication group create a replication group
with cluster mode enabled. with cluster mode enabled.
Modify Cluster Using the AWS CLI (p. 150) Using the ElastiCache
API (p. 151)
You can't use this action to
create a replication group You can't use this action to
with cluster mode enabled. create a replication group
with cluster mode enabled.
Modify Replication Group Using the AWS CLI (p. 294) Using the ElastiCache
API (p. 295)
With this version, we also introduce support for data tiering on cluster nodes containing locally attached
NVMe SSD. For more information, see Data tiering (p. 121).
You specify the engine version by using 6.2. ElastiCache for Redis will automatically invoke the preferred
patch version of Redis 6.2 that is available. For example, when you create/modify a cache cluster, you
set the --engine-version parameter to 6.2. The cluster will be launched with the current available
preferred patch version of Redis 6.2 at the creation/modification time. Specifying engine version 6.x in
the API will result in the latest minor version of Redis 6.
For existing 6.0 clusters, you can opt-in to the next auto minor version upgrade by setting the
AutoMinorVersionUpgrade parameter to yes in the CreateCacheCluster, ModifyCacheCluster,
CreateReplicationGroup or ModifyReplicationGroup APIs. ElastiCache for Redis will upgrade
the minor version of your existing 6.0 clusters to 6.2 using self-service updates. For more information,
see Self-service updates in Amazon ElastiCache.
For more information on the Redis 6.2 release, see Redis 6.2 Release Notes at Redis on GitHub.
Beginning with Redis 6.0, ElastiCache for Redis will offer a single version for each Redis OSS minor
release, rather than offering multiple patch versions. ElastiCache for Redis will automatically manage the
patch version of your running cache clusters, ensuring improved performance and enhanced security.
You can also opt-in to the next auto minor version upgrade by setting the AutoMinorVersionUpgrade
parameter to yes and ElastiCache for Redis will manage the minor version upgrade, through self-service
updates. For more information, see Self-service updates in Amazon ElastiCache (p. 625).
You specify the engine version by using 6.0. ElastiCache for Redis will automatically invoke the preferred
patch version of Redis 6.0 that is available. For example, when you create/modify a cache cluster, you
set the --engine-version parameter to 6.0. The cluster will be launched with the current available
preferred patch version of Redis 6.0 at the creation/modification time. Any request with a specific patch
version value will be rejected, an exception will be thrown and the process will fail.
For more information on the Redis 6.0 release, see Redis 6.0 Release Notes at Redis on GitHub.
For more information, see Redis 5.0.6 Release Notes at Redis on GitHub.
For more information, see Redis 5.0.5 Release Notes at Redis on GitHub.
For more information, see Redis 5.0.4 Release Notes at Redis on GitHub.
• Bug fixes to improve sorted set edge cases, accurate memory usage and more. For more information,
see Redis 5.0.3 release notes.
• Ability to rename commands: ElastiCache for Redis 5.0.3 includes a new parameter called rename-
commands that allows you to rename potentially dangerous or expensive Redis commands that might
cause accidental data loss, such as FLUSHALL or FLUSHDB. This is similar to the rename-command
configuration in open source Redis. However, ElastiCache has improved the experience by providing
a fully managed workflow. The command name changes are applied immediately, and automatically
propagated across all nodes in the cluster that contain the command list. There is no intervention
required on your part, such as rebooting nodes.
The following examples demonstrate how to modify existing parameter groups. They include the
rename-commands parameter, which is a space-separated list of commands you want to rename:
In this example, the rename-commands parameter is used to rename the flushall command to
restrictedflushall.
To revert any change, re-run the command and exclude any renamed values from the
ParameterValue list that you want to retain, as shown following:
In this case, the flushall command is renamed to restrictedflushall and any other renamed
commands revert to their original command names.
Note
When renaming commands, you are restricted to the following limitations:
• All renamed commands should be alphanumeric.
• The maximum length of new command names is 20 alphanumeric characters.
• When renaming commands, ensure that you update the parameter group associated with
your cluster.
• To prevent a command's use entirely, use the keyword blocked, as shown following:
For more information on the parameter changes and a list of what commands are eligible for
renaming, see Redis 5.0.3 parameter changes (p. 444).
• Redis Streams: This models a log data structure that allows producers to append new items in real
time. It also allows consumers to consume messages either in a blocking or nonblocking fashion.
Streams also allow consumer groups, which represent a group of clients to cooperatively consume
different portions of the same stream of messages, similar to Apache Kafka. For more information, see
Introduction to Redis Streams.
• Support for a family of stream commands, such as XADD, XRANGE and XREAD. For more information,
see Redis Streams Commands.
• A number of new and renamed parameters. For more information, see Redis 5.0.0 parameter
changes (p. 445).
• A new Redis metric, StreamBasedCmds.
• Slightly faster snapshot time for Redis nodes.
Important
Amazon ElastiCache for Redis has back-ported two critical bug fixes from Redis open source
version 5.0.1. They are listed following:
Both of these bug fixes are included in ElastiCache for Redis support for Redis engine version
5.0.0 and are consumed in future version updates.
• Both online cluster resizing and encryption in a single ElastiCache for Redis version. For more
information, see the following:
• Scaling clusters in Redis (Cluster Mode Enabled) (p. 375)
• Online resharding and shard rebalancing for Redis (cluster mode enabled) (p. 377)
• Data security in Amazon ElastiCache (p. 470)
• A number of new parameters. For more information, see Redis 4.0.10 parameter changes (p. 448).
• Support for family of memory commands, such as MEMORY. For more information, see Redis
Commands (search on MEMO).
• Support for memory defragmentation while online thus allowing more efficient memory utilization
and more memory available for your data.
• Support for asynchronous flushes and deletes. ElastiCache for Redis supports commands like UNLINK,
FLUSHDB and FLUSHALL to run in a different thread from the main thread. Doing this helps improve
performance and response times for your applications by freeing memory asynchronously.
• A new Redis metric, ActiveDefragHits. For more information, see Metrics for Redis.
Redis (cluster mode disabled) users running Redis version 3.2.10 can use the console to upgrade their
clusters via online upgrade.
** Required for FedRAMP, HIPAA, and PCI DSS compliant applications. For more information, see
ElastiCache for Redis compliance (p. 618).
** Required for FedRAMP, HIPAA, and PCI DSS compliant applications. For more information, see
ElastiCache for Redis compliance (p. 618).
• Online resharding and shard rebalancing for Redis (cluster mode enabled) (p. 377)
• Best practices: Online cluster resizing (p. 229)
* See Restoring from a backup with optional cluster resizing (p. 334)
Notes:
• Partitioning – the ability to split your data across 2 to 500 node groups (shards) with replication
support for each node group.
• Geospatial indexing – Redis 3.2.4 introduces support for geospatial indexing via six GEO commands.
For more information, see the Redis GEO* command documentation Redis Commands: GEO on the
Redis Commands page (filtered for GEO).
For information about additional Redis 3 features, see Redis 3.2 release notes and Redis 3.0 release
notes.
Currently ElastiCache managed Redis (cluster mode enabled) does not support the following Redis 3.2
features:
• Replica migration
• Cluster rebalancing
• Lua debugger
• cluster meet
• cluster replicate
• cluster flushslots
• cluster addslots
• cluster delslots
• cluster setslot
• cluster saveconfig
• cluster forget
• cluster failover
• cluster bumpepoch
• cluster set-config-epoch
• cluster reset
For information about Redis 3.2.4 parameters, see Redis 3.2.4 parameter changes (p. 451).
For more information on Redis 2.8.23 parameters, see Redis 2.8.23 (enhanced) added
parameters (p. 455) in the ElastiCache User Guide.
• Support for forkless backups and synchronizations, which allows you to allocate less memory for
backup overhead and more for your application. For more information, see How synchronization and
backup are implemented (p. 265). The forkless process can impact both latency and throughput.
When there is high write throughput, when a replica re-syncs, it can be unreachable for the entire time
it is syncing.
• If there is a failover, replication groups now recover faster because replicas perform partial syncs with
the primary rather than full syncs whenever possible. Additionally, both the primary and replicas no
longer use the disk during syncs, providing further speed gains.
• Support for two new CloudWatch metrics.
• ReplicationBytes – The number of bytes a replication group's primary cluster is sending to the
read replicas.
• SaveInProgress – A binary value that indicates whether or not there is a background save process
running.
For more information, see Monitoring use with CloudWatch Metrics (p. 587).
• A number of critical bug fixes in replication PSYNC behavior. For more information, see Redis 2.8
release notes.
• To maintain enhanced replication performance in Multi-AZ replication groups and for increased cluster
stability, non-ElastiCache replicas are no longer supported.
• To improve data consistency between the primary cluster and replicas in a replication group, the
replicas no longer evict keys independent of the primary cluster.
• Redis configuration variables appendonly and appendfsync are not supported on Redis version
2.8.22 and later.
• In low-memory situations, clients with a large output buffer might be disconnected from a replica
cluster. If disconnected, the client needs to reconnect. Such situations are most likely to occur for
PUBSUB clients.
• Support for HyperLogLog. For more information, see Redis new data structure: HyperLogLog.
• The sorted set data type now has support for lexicographic range queries with the new commands
ZRANGEBYLEX, ZLEXCOUNT, and ZREMRANGEBYLEX.
• To prevent a primary node from sending stale data to replica nodes, the master SYNC fails if a
background save (bgsave) child process is aborted.
• Support for the HyperLogLogBasedCommands CloudWatch metric. For more information, see Metrics
for Redis (p. 589).
The following table summarizes each version and its announced EOL date, as well as the recommended
upgrade target version.
Source
Source Minor Versions Recommended Upgrade EOL Date
Major Target
Version
Version
2.8.24, 2.8.23, 2.8.22, 2.8.21, Version 6.2 or higher January 13, 2023
2 2.8.12, 2.8.6, 2.6.13
Note
For US-ISO-EAST-1,
US-ISO-WEST-1,
and US-ISOB-
EAST-1 Regions, we
recommend 5.0.6 or
higher.
Because version upgrades might involve some compatibility risk, they don't occur automatically. You
must initiate them.
You initiate engine version upgrades to your cluster or replication group by modifying it and specifying a
new engine version. For more information, see the following:
• Engine version management is designed so that you can have as much control as possible over how
patching occurs. However, ElastiCache reserves the right to patch your cluster on your behalf in the
unlikely event of a critical security vulnerability in the system or cache software.
• Beginning with Redis 6.0, ElastiCache for Redis will offer a single version for each Redis OSS minor
release, rather than offering multiple patch versions.
• Starting with Redis engine version 5.0.5, you can upgrade your cluster version with minimal downtime.
The cluster is available for reads during the entire upgrade and is available for writes for most of the
upgrade duration, except during the failover operation which lasts a few seconds.
• You can also upgrade your ElastiCache clusters with versions earlier than 5.0.5. The process involved is
the same but may incur longer failover time during DNS propagation (30s-1m).
• ElastiCache for Redis doesn't support switching between Redis (cluster mode disabled) and Redis
(cluster mode enabled).
• The Amazon ElastiCache for Redis engine upgrade process is designed to make a best effort to retain
your existing data and requires successful Redis replication.
• You can't upgrade directly from Redis (cluster mode disabled) to Redis (cluster mode enabled) when
you upgrade your engine. The following procedure shows you how to upgrade from Redis (cluster
mode disabled) to Redis (cluster mode enabled).
To upgrade from a Redis (cluster mode disabled) to Redis (cluster mode enabled) engine
version
1. Make a backup of your Redis (cluster mode disabled) cluster or replication group. For more
information, see Making manual backups (p. 315).
2. Use the backup to create and seed a Redis (cluster mode enabled) cluster with one shard (node
group). Specify the new engine version and enable cluster mode when creating the cluster or
replication group. For more information, see Seeding a new cluster with an externally created
backup (p. 337).
3. Delete the old Redis (cluster mode disabled) cluster or replication group. For more information,
see Deleting a cluster (p. 165) or Deleting a replication group (p. 296).
4. Scale the new Redis (cluster mode enabled) cluster or replication group to the number of shards
(node groups) that you need. For more information, see Scaling clusters in Redis (Cluster Mode
Enabled) (p. 375)
• When upgrading major engine versions, for example from 5.0.6 to 6.0, you need to also choose a new
parameter group that is compatible with the new engine version.
• For single Redis clusters and clusters with Multi-AZ disabled, we recommend that sufficient memory
be made available to Redis as described in Ensuring that you have enough memory to create a Redis
snapshot (p. 221). In these cases, the primary is unavailable to service requests during the upgrade
process.
• For Redis clusters with Multi-AZ enabled, we also recommend that you schedule engine upgrades
during periods of low incoming write traffic. When upgrading to Redis 5.0.6 or above, the primary
cluster continues to be available to service requests during the upgrade process.
Clusters and replication groups with multiple shards are processed and patched as follows:
• All shards are processed in parallel. Only one upgrade operation is performed on a shard at any time.
• In each shard, all replicas are processed before the primary is processed. If there are fewer replicas in
a shard, the primary in that shard might be processed before the replicas in other shards are finished
processing.
• Across all the shards, primary nodes are processed in series. Only one primary node is upgraded at a
time.
• If encryption is enabled on your current cluster or replication group, you cannot upgrade to an engine
version that does not support encryption, such as from 3.2.6 to 3.2.10.
Using the AWS Management Console (p. 149) Using the AWS Management Console (p. 294)
Using the AWS CLI (p. 150) Using the AWS CLI (p. 294)
Using the ElastiCache API (p. 151) Using the ElastiCache API (p. 295)
Immediate scale up
Scale up and engine upgrade
Immediate engine upgrade
• Schedule your Redis engine upgrade operation for the next maintenance window by clearing the
Apply immediately check box.
With the CLI, use --no-apply-immediately. With the API, use ApplyImmediately=false.
• Wait until your next maintenance window (or after) to perform your Redis engine upgrade
operation.
• Add the Redis scale up operation to this cluster modification with the Apply Immediately check
box chosen.
With the CLI, use --apply-immediately. With the API, use ApplyImmediately=true.
This approach effectively cancels the engine upgrade during the next maintenance window by
performing it immediately.
We recommend always staying on the latest patch version within a given MAJOR.MINOR version in order
to have the latest performance and stability improvements. Beginning with Redis 6.0, ElastiCache for
Redis will offer a single version for each Redis OSS minor release, rather than offering multiple patch
versions. ElastiCache for Redis will automatically manage the patch version of your running cache
clusters, ensuring improved performance and enhanced security.
We also recommend periodically upgrading to the latest major version, since most major improvements
are not back ported to older versions. When doing an upgrade that spans major or minor versions, please
consider the following list which includes behavior and backwards incompatible changes released with
Redis over time.
• Starting in Redis 2.8.22, Redis AOF is no longer supported in ElastiCache for Redis. We recommend
using MemoryDB when data needs to be persisted durably.
• Starting in Redis 2.8.22, ElastiCache for Redis no longer supports attaching replicas to primaries
hosted within ElastiCache. While upgrading, external replicas will be disconnected and they will be
unable to reconnect. We recommend using client-side caching, made available in Redis 6.0 as an
alternative to external replicas.
• The TTL and PTTL commands now return -2 if the key does not exist and -1 if it exists but has no
associated expire. Redis 2.6 and previous versions used to return -1 for both the conditions.
• SORT with ALPHA now sorts according to local collation locale if no STORE option is used.
• Slow log now logs an additional two arguments, the client name and address. This change should be
backwards compatible unless you are explicitly relying on each slow log entry containing 3 values.
• The CLUSTER NODES command now returns a slight different format, which is not backwards
compatible. We recommend that clients don’t use this command for learning about the nodes present
in a cluster, and instead they should use CLUSTER SLOTS.
• Scripts are by replicated by effects instead of re-executing the script on the replica. This generally
improves performance but may increase the amount of data replicated between primaries and replicas.
There is an option to revert back to the previous behavior that is only available in ElastiCache for Redis
5.0.
• If you are upgrading from Redis 4.0, some commands in LUA scripts will return arguments in a
different order than they did in earlier versions. In Redis 4.0, Redis would order some responses
lexographically in order to make the responses deterministic, this ordering is not applied when scripts
are replicated by effects.
• Starting in Redis 5.0.3, ElastiCache for Redis will offload some IO work to background cores on
instance types with more than 4 VCPUs. This may change the performance characteristics Redis and
change the values of some metrics. For more information, see
The following CloudWatch metrics offer good insight into ElastiCache performance. In
most cases, we recommend that you set CloudWatch alarms for these metrics so that you
can take corrective action before performance issues occur.
Metrics to Monitor
For smaller node types with 2vCPUs or less, use the CPUUtilization metric to
monitor your workload.
Generally speaking, we suggest you set your threshold at 90% of your available CPU.
Because Redis is single-threaded, the actual threshold value should be calculated as a
fraction of the node's total capacity. For example, suppose you are using a node type
that has two cores. In this case, the threshold for CPUUtilization would be 90/2, or 45%.
You will need to determine your own threshold, based on the number of cores in the
cache node that you are using. If you exceed this threshold, and your main workload
is from read requests, scale your cache cluster out by adding read replicas. If the
main workload is from write requests, depending on your cluster configuration, we
recommend that you:
• Redis (cluster mode disabled) clusters: scale up by using a larger cache instance type.
• Redis (cluster mode enabled) clusters: add more shards to distribute the write
workload across more primary nodes.
Tip
Instead of using the Host-Level metric CPUUtilization, Redis users might
be able to use the Redis metric EngineCPUUtilization, which reports the
percentage of usage on the Redis engine core. To see if this metric is available
on your nodes and for more information, see Metrics for Redis.
For larger node types with 4vCPUs or more, you may want to use the
EngineCPUUtilization metric, which reports the percentage of usage on the Redis
engine core. To see if this metric is available on your nodes and for more information, see
Metrics for Redis.
EngineCPUUtilization
For larger node types with 4vCPUs or more, you may want to use the
EngineCPUUtilization metric, which reports the percentage of usage on the Redis
engine core. To see if this metric is available on your nodes and for more information, see
Metrics for Redis.
For more information, see the CPUs section at Monitoring best practices with Amazon
ElastiCache for Redis using Amazon CloudWatch.
SwapUsage
This is a host-level metric reported in bytes. For more information, see Host-Level
Metrics (p. 587).
This metric should not exceed 300 MB. If it does, see the following topics:
• Ensuring that you have enough memory to create a Redis snapshot (p. 221)
CurrConnections
This is a cache engine metric. We recommend that you determine your own alarm
threshold for this metric based on your application needs.
For more information, see the Connections section at Monitoring best practices with
Amazon ElastiCache for Redis using Amazon CloudWatch.
Memory
Memory is a core aspect of Redis. Understanding the memory utilization of your
cluster is necessary to avoid data loss and accommodate future growth of your dataset.
Statistics about the memory utilization of a node are available in the memory section of
the Redis INFO command.
For more information, see the Memory section at Monitoring best practices with Amazon
ElastiCache for Redis using Amazon CloudWatch.
Network
One of the determining factors for the network bandwidth capacity of your cluster is the
node type you have selected. For more information about the network capacity of your
node, see Amazon ElastiCache pricing.
For more information, see the Network section at Monitoring best practices with
Amazon ElastiCache for Redis using Amazon CloudWatch.
Latency
You can measure a command’s latency with a set of CloudWatch metrics that provide
aggregated latencies per data structure. These latency metrics are calculated using the
commandstats statistic from the Redis INFO command.
For more information, see the Latency section at Monitoring best practices with Amazon
ElastiCache for Redis using Amazon CloudWatch.
Replication
The volume of data being replicated is visible via the ReplicationBytes metric.
Although this metric is representative of the write load on the replication group,
it doesnt provide insights into replication health. For this purpose, you can use the
ReplicationLag metric.
For more information, see the Replication section at Monitoring best practices with
Amazon ElastiCache for Redis using Amazon CloudWatch.
(p. 597) to understand if you need to change which metrics you watch.
• The maximum number of allowed databases has been decreased from 1.2 million to 10 thousand. The
default value is 16, and we discourage using values much larger than this as we’ve found performance
and memory concerns.
• Set AutoMinorVersionUpgrade parameter to yes, and ElastiCache for Redis will manage the minor
version upgrade through self-service updates. This will be handled through standard customer-
notification channels via a self-service update campaign. For more information, see Self-service
updates in ElastiCache.
• The ACL flags of the TIME, ECHO, ROLE, and LASTSAVE commands were changed. This may cause
commands that were previously allowed to be rejected and vice versa.
Note
None of these commands modify or give access to data.
• When upgrading from Redis 6.0, the ordering of key/value pairs returned from a map response to a lua
script are changed. If your scripts use redis.setresp() or return a map (new in Redis 6.0), consider
the implications that the script may break on upgrades.
Tag basics
A tag is a label that you assign to an AWS resource. Each tag consists of a key and an optional value, both
of which you define. Tags enable you to categorize your AWS resources in different ways, for example, by
purpose or owner. For example, you could define a set of tags for your account's ElastiCache clusters that
helps you track each instance's owner and user group.
We recommend that you devise a set of tag keys that meets your needs for each resource type. Using
a consistent set of tag keys makes it easier for you to manage your resources. You can search and filter
the resources based on the tags you add. For more information about how to implement an effective
resource tagging strategy, see the AWS whitepaper Tagging Best Practices.
Tags don't have any semantic meaning to ElastiCache and are interpreted strictly as a string of
characters. Also, tags are not automatically assigned to your resources. You can edit tag keys and values,
and you can remove tags from a resource at any time. You can set the value of a tag to null. If you add
a tag that has the same key as an existing tag on that resource, the new value overwrites the old value. If
you delete a resource, any tags for the resource are also deleted. Furthermore, if you add or delete tags
on a replication group, all nodes in that replication group will also have their tags added or removed.
You can work with tags using the AWS Management Console, the AWS CLI, and the ElastiCache API.
If you're using IAM, you can control which users in your AWS account have permission to create, edit, or
delete tags. For more information, see Resource-level permissions (p. 549).
creation). The console may organize resources according to the Name tag, but this tag doesn't have any
semantic meaning to the ElastiCache service.
Additionally, some resource-creating actions enable you to specify tags for a resource when the resource
is created. If tags cannot be applied during resource creation, we roll back the resource creation process.
This ensures that resources are either created with tags or not created at all, and that no resources are
left untagged at any time. By tagging resources at the time of creation, you can eliminate the need to
run custom tagging scripts after resource creation.
If you're using the Amazon ElastiCache API, the AWS CLI, or an AWS SDK, you can use the Tags
parameter on the relevant ElastiCache API action to apply tags. They are:
• CreateCacheCluster
• CreateReplicationGroup
• CopySnapshot
• CreateCacheParameterGroup
• CreateCacheSecurityGroup
• CreateCacheSubnetGroup
• CreateSnapshot
• CreateUserGroup
• CreateUser
• PurchaseReservedCacheNodesOffering
The following table describes the ElastiCache resources that can be tagged, and the resources that can
be tagged on creation using the ElastiCache API, the AWS CLI, or an AWS SDK.
Resource
Supports tags Supports tagging on creation
parametergroup
Yes Yes
securitygroup
Yes Yes
subnetgroup
Yes Yes
replicationgroup
Yes Yes
cluster
Yes Yes
reserved-
Yes Yes
instance
snapshot
Yes Yes
user
Yes Yes
usergroup
Yes Yes
Note
You cannot tag Global Datastores.
You can apply tag-based resource-level permissions in your IAM policies to the ElastiCache API actions
that support tagging on creation to implement granular control over the users and groups that can
tag resources on creation. Your resources are properly secured from creation—tags that are applied
immediately to your resources. Therefore any tag-based resource-level permissions controlling the use of
resources are immediately effective. Your resources can be tracked and reported on more accurately. You
can enforce the use of tagging on new resources, and control which tag keys and values are set on your
resources.
For more information about tagging your resources for billing, see Monitoring costs with cost allocation
tags (p. 210).
• CreateReplicationGroup:
• If the --primary-cluster-id and --tags parameters are included in the request, the request
tags will be added to the replication group and propagate to all cache clusters in the replication
group. If the primary cache cluster has existing tags, these will be overwritten with the request tags
to have consistent tags across all nodes.
If there are no request tags, the primary cache cluster tags will be added to the replication group
and propagated to all cache clusters.
• CreateCacheCluster :
• If the --replication-group-id is supplied:
If tags are included in the request, the cache cluster will be tagged only with those tags. If no tags
are included in the request, the cache cluster will inherit the replication group tags instead of the
primary cache cluster's tags.
• If the --snapshot-name is supplied:
If tags are included in the request, the cache cluster will be tagged only with those tags. If no tags
are included in the request, the snapshot tags will be added to the cache cluster.
• If the --global-replication-group-id is supplied:
If tags are included in the request, the request tags will be added to the replication group and
propagate to all nodes.
• CreateSnapshot :
• If the --replication-group-id is supplied:
If tags are included in the request, only the request tags will be added to the snapshot. If no tags are
included in the request, the replication group tags will be added to the snapshot.
• If the --cache-cluster-id is supplied:
If tags are included in the request, only the request tags will be added to the snapshot. If no tags are
included in the request, the cache cluster tags will be added to the snapshot.
• For automatic snapshots:
If tags are included in the request, only the request tags will be added to the snapshot. If no tags are
included in the request, the source snapshot tags will be added to the copied snapshot.
• AddTagsToResource and RemoveTagsFromResource :
Tags will be added/removed from the replication group and the action will be propagated to all
clusters in the replication group.
API Version 2015-02-02
206
Amazon ElastiCache for Redis User Guide
Tagging your ElastiCache resources
Note
AddTagsToResource and RemoveTagsFromResource cannot be used for default parameter
and security groups.
• IncreaseReplicaCount and ModifyReplicationGroupShardConfiguration: All new nodes added to the
replication group will have the same tags applied as the replication group.
Tag restrictions
The following basic restrictions apply to tags:
You can't terminate, stop, or delete a resource based solely on its tags; you must specify the resource
identifier. For example, to delete snapshots that you tagged with a tag key called DeleteMe, you
must use the DeleteSnapshot action with the resource identifiers of the snapshots, such as
snap-1234567890abcdef0.
For more information on ElastiCache resources you can tag, see Resources you can tag (p. 204).
For this case, if you add tags on request, even if the replication group contains tags, the snapshot will
receive only the request tags.
--replication-group-id testing-tags \
--snapshot-name bkp-testing-tags-rg \
--tags Key="work",Value="foo"
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:AddTagsToResource",
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "XYZ"
}
}
}
]
}
2. Allowing to RemoveTagsFromResource action from a replication group if it contains the tags Project
and Service and keys are different from Project and Service.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:RemoveTagsFromResource",
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Service": "Elasticache",
"aws:ResourceTag/Project": "XYZ"
},
"ForAnyValue:StringNotEqualsIgnoreCase": {
"aws:TagKeys": [
"Project",
"Service"
]
}
}
}
]
}
3. Allowing AddTagsToResource to any resource only if tags are different from Project and Service.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:AddTagsToResource",
"Resource": [
"arn:aws:elasticache:*:*:*:*"
],
"Condition": {
"ForAnyValue:StringNotEqualsIgnoreCase": {
"aws:TagKeys": [
"Service",
"Project"
]
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "elasticache:CreateReplicationGroup",
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": "Foo"
}
}
}
]
}
5. Denying CopySnapshot action if source snapshot has tag Project=XYZ and request tag is
Service=Elasticache.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "elasticache:CopySnapshot",
"Resource": [
"arn:aws:elasticache:*:*:snapshot:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "XYZ",
"aws:RequestTag/Service": "Elasticache"
}
}
}
]
}
An ElastiCache cost allocation tag is a key-value pair that you define and associate with an ElastiCache
resource. The key and value are case-sensitive. You can use a tag key to define a category, and the tag
value can be an item in that category. For example, you might define a tag key of CostCenter and a tag
value of 10010, indicating that the resource is assigned to the 10010 cost center. You can also use tags
to designate resources as being used for test or production by using a key such as Environment and
values such as test or production. We recommend that you use a consistent set of tag keys to make it
easier to track costs associated with your resources.
Use cost allocation tags to organize your AWS bill to reflect your own cost structure. To do this, sign up
to get your AWS account bill with tag key values included. Then, to see the cost of combined resources,
organize your billing information according to resources with the same tag key values. For example, you
can tag several resources with a specific application name, and then organize your billing information to
see the total cost of that application across several services.
You can also combine tags to track costs at a greater level of detail. For example, to track your service
costs by region you might use the tag keys Service and Region. On one resource you might have
the values ElastiCache and Asia Pacific (Singapore), and on another resource the values
ElastiCache and Europe (Frankfurt). You can then see your total ElastiCache costs broken out by
region. For more information, see Use Cost Allocation Tags in the AWS Billing and Cost Management User
Guide.
You can add ElastiCache cost allocation tags to Redis nodes. When you add, list, modify, copy, or remove
a tag, the operation is applied only to the specified node.
• Cost allocation tags are applied to ElastiCache resources which are specified in CLI and API operations
as an ARN. The resource-type will be a "cluster".
• The tag value is the optional value of the tag. The value's string value can be from 1 to 256 Unicode
characters in length and cannot be prefixed with aws:. The string can contain only the set of Unicode
letters, digits, blank spaces, underscores ( _ ), periods ( . ), colons ( : ), backslashes ( \ ), equal signs ( = ),
plus signs ( + ), hyphens ( - ), or at signs ( @ ).
• An ElastiCache resource can have a maximum of 50 tags.
• Values do not have to be unique in a tag set. For example, you can have a tag set where the keys
Service and Application both have the value ElastiCache.
AWS does not apply any semantic meaning to your tags. Tags are interpreted strictly as character strings.
AWS does not automatically set any tags on any ElastiCache resource.
Cost allocation tags are applied to ElastiCache for Redis nodes. The node to be tagged is specified using
an ARN (Amazon Resource Name).
Topics
• Listing tags using the AWS CLI (p. 211)
• Adding tags using the AWS CLI (p. 212)
• Modifying tags using the AWS CLI (p. 212)
• Removing tags using the AWS CLI (p. 213)
The following code uses the AWS CLI to list the tags on the Redis node my-cluster-001 in the my-
cluster cluster in region us-west-2.
For Windows:
Output from this operation will look something like the following, a list of all the tags on the resource.
{
"TagList": [
{
"Value": "10110",
"Key": "CostCenter"
},
{
"Value": "EC2",
"Key": "Service"
}
]
}
If there are no tags on the resource, the output will be an empty TagList.
{
"TagList": []
For more information, see the AWS CLI for ElastiCache list-tags-for-resource.
The following code uses the AWS CLI to add the keys Service and Region with the values
elasticache and us-west-2 respectively to the node my-cluster-001 in the cluster my-cluster in
region us-west-2.
For Windows:
Output from this operation will look something like the following, a list of all the tags on the resource
following the operation.
{
"TagList": [
{
"Value": "elasticache",
"Key": "Service"
},
{
"Value": "us-west-2",
"Key": "Region"
}
]
}
For more information, see the AWS CLI for ElastiCache add-tags-to-resource.
You can also use the AWS CLI to add tags to a cluster when you create a new cluster by using the
operation create-cache-cluster. You cannot add tags when creating a cluster using the ElastiCache
management console. After the cluster is created, you can then use the console to add tags to the
cluster.
To modify tags:
• Use add-tags-to-resource to either add a new tag and value or to change the value associated with an
existing tag.
Output from either operation will be a list of tags and their values on the specified cluster.
The following code uses the AWS CLI to remove the tags with the keys Service and Region from the
node my-cluster-001 in the cluster my-cluster in the us-west-2 region.
For Windows:
Output from this operation will look something like the following, a list of all the tags on the resource
following the operation.
{
"TagList": []
}
For more information, see the AWS CLI for ElastiCache remove-tags-from-resource.
Cost allocation tags are applied to ElastiCache for Memcached clusters. The cluster to be tagged is
specified using an ARN (Amazon Resource Name).
Topics
• Listing tags using the ElastiCache API (p. 213)
• Adding tags using the ElastiCache API (p. 214)
• Modifying tags using the ElastiCache API (p. 214)
• Removing tags using the ElastiCache API (p. 214)
The following code uses the ElastiCache API to list the tags on the resource my-cluster-001 in the us-
west-2 region.
https://elasticache.us-west-2.amazonaws.com/
?Action=ListTagsForResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
The following code uses the ElastiCache API to add the keys Service and Region with the values
elasticache and us-west-2 respectively to the resource my-cluster-001 in the us-west-2 region.
https://elasticache.us-west-2.amazonaws.com/
?Action=AddTagsToResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Tags.member.1.Key=Service
&Tags.member.1.Value=elasticache
&Tags.member.2.Key=Region
&Tags.member.2.Value=us-west-2
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see AddTagsToResource in the Amazon ElastiCache API Reference.
• Use AddTagsToResource operation to either add a new tag and value or to change the value of an
existing tag.
• Use RemoveTagsFromResource to remove tags from the resource.
Output from either operation will be a list of tags and their values on the specified resource.
The following code uses the ElastiCache API to remove the tags with the keys Service and Region
from the node my-cluster-001 in the cluster my-cluster in region us-west-2.
https://elasticache.us-west-2.amazonaws.com/
?Action=RemoveTagsFromResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&TagKeys.member.1=Service
&TagKeys.member.2=Region
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
Topics
• Caching strategies (p. 215)
• Restricted Redis Commands (p. 220)
• Ensuring that you have enough memory to create a Redis snapshot (p. 221)
• Managing Reserved Memory (p. 223)
• Mitigating failure issues when using Redis AOF (p. 228)
• Best practices: Online cluster resizing (p. 229)
• Best practices: Minimizing downtime during maintenance (p. 230)
• Best practices: Redis clients and ElastiCache for Redis (p. 230)
Caching strategies
In the following topic, you can find strategies for populating and maintaining your cache.
What strategies to implement for populating and maintaining your cache depend upon what data you
cache and the access patterns to that data. For example, you likely don't want to use the same strategy
for both a top-10 leaderboard on a gaming site and trending news stories. In the rest of this section, we
discuss common cache maintenance strategies and their advantages and disadvantages.
Topics
• Lazy loading (p. 215)
• Write-through (p. 217)
• Adding TTL (p. 218)
• Related topics (p. 219)
Lazy loading
As the name implies, lazy loading is a caching strategy that loads data into the cache only when
necessary. It works as described following.
Amazon ElastiCache is an in-memory key-value store that sits between your application and the data
store (database) that it accesses. Whenever your application requests data, it first makes the request to
the ElastiCache cache. If the data exists in the cache and is current, ElastiCache returns the data to your
application. If the data doesn't exist in the cache or has expired, your application requests the data from
your data store. Your data store then returns the data to your application. Your application next writes
the data received from the store to the cache. This way, it can be more quickly retrieved the next time it's
requested.
A cache hit occurs when data is in the cache and isn't expired:
Because most data is never requested, lazy loading avoids filling up the cache with data that isn't
requested.
• Node failures aren't fatal for your application.
When a node fails and is replaced by a new, empty node, your application continues to function,
though with increased latency. As requests are made to the new node, each cache miss results in a
query of the database. At the same time, the data copy is added to the cache so that subsequent
requests are retrieved from the cache.
• There is a cache miss penalty. Each cache miss results in three trips:
1. Initial request for data from the cache
2. Query of the database for the data
3. Writing the data to the cache
These misses can cause a noticeable delay in data getting to the application.
• Stale data.
If data is written to the cache only when there is a cache miss, data in the cache can become stale.
This result occurs because there are no updates to the cache when data is changed in the database. To
address this issue, you can use the Write-through (p. 217) and Adding TTL (p. 218) strategies.
// *****************************************
// function that returns a customer's record.
// Attempts to retrieve the record from the cache.
// If it is retrieved, the record is returned to the application.
// If the record is not retrieved from the cache, it is
customer_record = cache.get(customer_id)
if (customer_record == null)
return customer_record
For this example, the application code that gets the data is the following.
customer_record = get_customer(12345)
Write-through
The write-through strategy adds data or updates data in the cache whenever data is written to the
database.
Because the data in the cache is updated every time it's written to the database, the data in the cache
is always current.
• Write penalty vs. read penalty.
Which adds latency to the process. That said, end users are generally more tolerant of latency when
updating data than when retrieving data. There is an inherent sense that updates are more work and
thus take longer.
• Missing data.
If you spin up a new node, whether due to a node failure or scaling out, there is missing data. This
data continues to be missing until it's added or updated on the database. You can minimize this by
implementing lazy loading (p. 215) with write-through.
• Cache churn.
Most data is never read, which is a waste of resources. By adding a time to live (TTL) value (p. 218),
you can minimize wasted space.
// *****************************************
// function that saves a customer's record.
// *****************************************
save_customer(customer_id, values)
For this example, the application code that gets the data is the following.
save_customer(12345,{"address":"123 Main"})
Adding TTL
Lazy loading allows for stale data but doesn't fail with empty nodes. Write-through ensures that data is
always fresh, but can fail with empty nodes and can populate the cache with superfluous data. By adding
a time to live (TTL) value to each write, you can have the advantages of each strategy. At the same time,
you can and largely avoid cluttering up the cache with extra data.
Time to live (TTL) is an integer value that specifies the number of seconds until the key expires. Redis can
specify seconds or milliseconds for this value. When an application attempts to read an expired key, it
is treated as though the key is not found. The database is queried for the key and the cache is updated.
This approach doesn't guarantee that a value isn't stale. However, it keeps data from getting too stale
and requires that values in the cache are occasionally refreshed from the database.
// *****************************************
// function that saves a customer's record.
// The TTL value of 300 means that the record expires
// 300 seconds (5 minutes) after the set command
// and future reads will have to query the database.
// *****************************************
save_customer(customer_id, values)
return success
// *****************************************
// function that returns a customer's record.
// Attempts to retrieve the record from the cache.
// If it is retrieved, the record is returned to the application.
// If the record is not retrieved from the cache, it is
// retrieved from the database,
// added to the cache, and
// returned to the application.
// The TTL value of 300 means that the record expires
// 300 seconds (5 minutes) after the set command
// and subsequent reads will have to query the database.
// *****************************************
get_customer(customer_id)
customer_record = cache.get(customer_id)
if (customer_record != null)
if (customer_record.TTL < 300)
return customer_record // return the record and exit function
For this example, the application code that gets the data is the following.
save_customer(12345,{"address":"123 Main"})
customer_record = get_customer(12345)
Related topics
• In-Memory Data Store (p. 35)
• Choosing an Engine and Version
• Scaling ElastiCache for Redis clusters (p. 345)
• acl setuser
• acl load
• acl save
• acl deluser
• bgrewriteaof
• bgsave
• cluster addslot
• cluster delslot
• cluster setslot
• config
• debug
• migrate
• replicaof
• save
• slaveof
• shutdown
• sync
Redis 2.8.22 introduces a forkless save process that allows you to allocate more of your memory to your
application's use without incurring increased swap usage during synchronizations and saves. For more
information, see How synchronization and backup are implemented (p. 265).
When you work with Redis ElastiCache, Redis calls a background write command in a number of cases:
Whenever Redis executes a background write process, you must have sufficient available memory to
accommodate the process overhead. Failure to have sufficient memory available causes the process to
fail. Because of this, it is important to choose a node instance type that has sufficient memory when
creating your Redis cluster.
As long as you have sufficient memory available to record all write operations while the data is being
persisted to disk, you should have no insufficient memory issues. You are likely to experience insufficient
memory issues if any of the following are true:
• Your application performs many write operations, thus requiring a large amount of available memory
to accept the new or updated data.
• You have very little memory available in which to write new or updated data.
• You have a large dataset that takes a long time to persist to disk, thus requiring a large number of
write operations.
The following diagram illustrates memory use when executing a background write process.
For information on the impact of doing a backup on performance, see Performance impact of
backups (p. 312).
For more information on regions and Availability Zones, see Choosing regions and availability
zones (p. 87).
The maxmemory value indicates the memory available to you for data and operational overhead. Because
you cannot modify the reserved-memory parameter in the default parameter group, you must create
a custom parameter group for the cluster. The default value for reserved-memory is 0, which allows
Redis to consume all of maxmemory with data, potentially leaving too little memory for other uses,
such as a background write process. For maxmemory values by node instance type, see Redis node-type
specific parameters (p. 465).
You can also use reserved-memory parameter to reduce the amount of memory Redis uses on the box.
For information on creating and modifying parameter groups, see Creating a parameter group (p. 425)
and Modifying a parameter group (p. 435).
Topics
• How Much Reserved Memory Do You Need? (p. 223)
• Parameters to Manage Reserved Memory (p. 223)
• Specifying Your Reserved Memory Management Parameter (p. 226)
When using clusters with data tiering, we recommend increasing maxmemory to up to half your node's
available memory if your workload is write-heavy.
• Ensuring that you have enough memory to create a Redis snapshot (p. 221)
• How synchronization and backup are implemented (p. 265)
• Data tiering (p. 121)
Depending upon when you became an ElastiCache customer, one or the other of these parameters is the
default memory management parameter. This parameter applies when you create a new Redis cluster or
replication group and use a default parameter group.
• For customers who started before March 16, 2017 – When you create a Redis cluster or replication
group using the default parameter group, your memory management parameter is reserved-
memory. In this case, zero (0) bytes of memory are reserved.
• For customers who started on or after March 16, 2017 – When you create a Redis cluster or replication
group using the default parameter group, your memory management parameter is reserved-
memory-percent. In this case, 25 percent of your node's maxmemory value is reserved for nondata
purposes.
After reading about the two Redis memory management parameters, you might prefer to use the one
that isn't your default or with nondefault values. If so, you can change to the other reserved memory
management parameter.
To change the value of that parameter, you can create a custom parameter group and modify it to use
your preferred memory management parameter and value. You can then use the custom parameter
group whenever you create a new Redis cluster or replication group. For existing clusters or replication
groups, you can modify them to use your custom parameter group.
Changing reserved-memory so you have sufficient memory available for backups and failovers requires
you to create a custom parameter group. In this custom parameter group, you set reserved-memory
to a value appropriate for the Redis version running on your cluster and cluster's node type. For more
information, see How Much Reserved Memory Do You Need? (p. 223)
The ElastiCache for Redis parameter reserved-memory is specific to ElastiCache for Redis and isn't part
of the Redis distribution.
The following procedure shows how to use reserved-memory to manage the memory on your Redis
cluster.
1. Create a custom parameter group specifying the parameter group family matching the engine
version you’re running—for example, specifying the redis2.8 parameter group family. For more
information, see Creating a parameter group (p. 425).
2. Calculate how many bytes of memory to reserve for Redis overhead. You can find the value of
maxmemory for your node type at Redis node-type specific parameters (p. 465).
3. Modify the custom parameter group so that the parameter reserved-memory is the number of
bytes you calculated in the previous step. The following AWS CLI example assumes you’re running
a version of Redis before 2.8.22 and need to reserve half of the node’s maxmemory. For more
information, see Modifying a parameter group (p. 435).
You need a separate custom parameter group for each node type that you use, because each node
type has a different maxmemory value. Thus, each node type needs a different value for reserved-
memory.
4. Modify your Redis cluster or replication group to use your custom parameter group.
The following CLI example modifies the cluster my-redis-cluster to use the custom parameter
group redis28-m3xl beginning immediately. For more information, see Modifying an ElastiCache
cluster (p. 149).
The following CLI example modifies the replication group my-redis-repl-grp to use the custom
parameter group redis28-m3xl beginning immediately. For more information, Modifying a
replication group (p. 294).
The ElastiCache for Redis parameter reserved-memory-percent is specific to ElastiCache for Redis
and isn't part of the Redis distribution.
If your cluster is using a node type from the r6gd family and your memory usage reaches 75 percent,
data-tiering will automatically be triggered. For more information, see Data tiering (p. 121).
To use reserved-memory-percent to manage the memory on your ElastiCache for Redis cluster, do
one of the following:
• If you are running Redis 2.8.22 or later, assign the default parameter group to your cluster. The default
25 percent should be adequate. If not, take the steps described following to change the value.
• If you are running a version of Redis before 2.8.22, you probably need to reserve more memory than
reserved-memory-percent's default 25 percent. To do so, use the following procedure.
1. Create a custom parameter group specifying the parameter group family matching the engine
version you’re running—for example, specifying the redis2.8 parameter group family. A custom
parameter group is necessary because you can't modify a default parameter group. For more
information, see Creating a parameter group (p. 425).
3. Use this custom parameter group for any Redis clusters or replication groups running a version of
Redis older than 2.8.22.
The following CLI example modifies the Redis cluster my-redis-cluster to use the custom
parameter group redis28-50 beginning immediately. For more information, see Modifying an
ElastiCache cluster (p. 149).
The following CLI example modifies the Redis replication group my-redis-repl-grp to use the
custom parameter group redis28-50 beginning immediately. For more information, see Modifying
a replication group (p. 294).
To specify reserved-memory-percent
The following CLI example modifies the custom parameter group redis32-cluster-on so that
it uses reserved-memory-percent to manage reserved memory. A value must be assigned to
ParameterValue for the parameter group to use the ParameterName parameter for reserved memory
management. For more information, see Modifying a parameter group (p. 435).
To specify reserved-memory
The following CLI example modifies the custom parameter group redis32-m3xl so that it uses
reserved-memory to manage reserved memory. A value must be assigned to ParameterValue for the
parameter group to use the ParameterName parameter for reserved memory management. Because
the engine version is newer than 2.8.22, we set the value to 3565158400 which is 25 percent of a
cache.m3.xlarge’s maxmemory. For more information, see Modifying a parameter group (p. 435).
You enable AOF because an AOF file is useful in recovery scenarios. In case of a node restart or service
crash, Redis replays the updates from an AOF file, thereby recovering the data lost due to the restart or
crash.
Warning
AOF cannot protect against all failure scenarios. For example, if a node fails due to a hardware
fault in an underlying physical server, ElastiCache provisions a new node on a different server. In
this case, the AOF file is no longer available and cannot be used to recover the data. Thus, Redis
restarts with a cold cache.
• Test your application – Test your application behavior during resharding in a staging environment if
possible.
• Get early notification for scaling issues – Resharding is a compute-intensive operation. Because of
this , we recommend keeping CPU utilization under 80 percent on multicore instances and less than
50 percent on single core instances during resharding. Monitor ElastiCache for Redis metrics and
initiate resharding before your application starts observing scaling issues. Useful metrics to track are
CPUUtilization, NetworkBytesIn, NetworkBytesOut, CurrConnections, NewConnections,
FreeableMemory, SwapUsage, and BytesUsedForCacheItems.
• Ensure sufficient free memory is available before scaling in – If you're scaling in, ensure that free
memory available on the shards to be retained is at least 1.5 times the memory used on the shards
you plan to remove.
• Initiate resharding during off-peak hours – This practice helps to reduce the latency and throughput
impact on the client during the resharding operation. It also helps to complete resharding faster as
more resources can be used for slot redistribution.
• Review client timeout behavior – Some clients might observe higher latency during online cluster
resizing. Configuring your client library with a higher timeout can help by giving the system time to
connect even under higher load conditions on server. In some cases, you might open a large number
of connections to the server. In these cases, consider adding exponential backoff to reconnect logic.
Doing this can help prevent a burst of new connections hitting the server at the same time.
• Avoid expensive commands – Avoid running any computationally and I/O intensive operations, such
as the KEYS and SMEMBERS commands. We suggest this approach because these operations increase
the load on the cluster and have an impact on the performance of the cluster. Instead, use the SCAN
and SSCAN commands.
• Follow Lua best practices – Avoid long running Lua scripts, and always declare keys used in Lua
scripts up front. We recommend this approach to determine that the Lua script is not using cross slot
commands. Ensure that the keys used in Lua scripts belong to the same slot.
• Scale-in might be partially successful if insufficient memory is available on target shards. If such a
result occurs, review available memory and retry the operation, if necessary.
• Slots with large items are not migrated. In particular, slots with items larger than 256 MB post-
serialization are not migrated.
• The BRPOPLPUSH command is not supported if it operates on the slot being migrated. FLUSHALL and
FLUSHDB commands are not supported inside Lua scripts during a resharding operation.
For read activity, applications can also connect to any node in the cluster. Unlike the primary endpoint,
node endpoints resolve to specific endpoints. If you make a change in your cluster, such as adding or
deleting a replica, you must update the node endpoints in your application.
If autofailover is enabled in the cluster, the primary node might change. Therefore, the application
should confirm the role of the node and update all the read endpoints. Doing this helps ensure that
you aren't causing a major load on the primary. With autofailover disabled, the role of the node doesn't
change. However, the downtime in managed or unmanaged operations is higher as compared to clusters
with auto failover enabled.
Avoid directing read requests to read replicas only. If you configure your client to direct read requests to
read replicas only, ensure that you have at least two read replicas to avoid any read interruption during
maintenance.
Managing maintenance
Every cluster and replication group has a weekly maintenance window during which any system
changes are applied. If you don't specify a preferred maintenance window when you create or modify a
cluster or replication group, ElastiCache assigns a 60-minute maintenance window within your region's
maintenance window on a randomly chosen day of the week.
The 60-minute maintenance window is chosen at random from an 8-hour block of time per region. The
following table lists the time blocks for each region from which the default maintenance windows are
assigned. You may choose a preferred maintenance window outside the region's maintenance window
block.
The maintenance window should fall at the time of lowest usage and thus might need modification from
time to time. You can modify your cluster or replication group to specify a time range of up to 24 hours
in duration during which any maintenance activities you have requested should occur. Any deferred or
pending cluster modifications you requested occur during this time.
More information
For information on your maintenance window and node replacement, see the following:
In the following sections, you can find a description of how to work with global datastores.
Topics
• Overview (p. 232)
• Prerequisites and limitations (p. 233)
• Using global datastores (console) (p. 234)
• Using global datastores (CLI) (p. 242)
Overview
Each global datastore is a collection of one or more clusters that replicate to one another.
• Primary (active) cluster – A primary cluster accepts writes that are replicated to all clusters within the
global datastore. A primary cluster also accepts read requests.
• Secondary (passive) cluster – A secondary cluster only accepts read requests and replicates data
updates from a primary cluster. A secondary cluster needs to be in a different AWS Region than the
primary cluster.
When you create a global datastore in ElastiCache, ElastiCache for Redis automatically replicates your
data from the primary cluster to the secondary cluster. You choose the AWS Region where the Redis data
should be replicated and then create a secondary cluster in that AWS Region. ElastiCache then sets up
and manages automatic, asynchronous replication of data between the two clusters.
• Geolocal performance – By setting up remote replica clusters in additional AWS Regions and
synchronizing your data between them, you can reduce latency of data access in that AWS Region.
A global datastore can help increase the responsiveness of your application by serving low-latency,
geolocal reads across AWS Regions.
• Disaster recovery – If your primary cluster in a global datastore experiences degradation, you can
promote a secondary cluster as your new primary cluster. You can do so by connecting to any AWS
Region that contains a secondary cluster.
• Global datastores are supported in the following AWS Regions: Asia Pacific (Seoul) Region, Asia Pacific
(Tokyo) Region, Asia Pacific (Singapore) Region, Asia Pacific (Sydney) Region, Asia Pacific (Mumbai)
Region, Europe (Frankfurt) Region, EU (Paris) Region, Europe (London) Region, Europe (Ireland) Region,
US East (N. Virginia) Region, US East (Ohio) Region, US West (N. California) Region, US West (Oregon)
Region, South America (São Paulo) Region, AWS GovCloud (US-West), AWS GovCloud (US-East),
Canada (Central) Region, China (Beijing) Region and China (Ningxia) Region.
• To use global datastores, use Redis engine version 5.0.6 or higher and R5, R6g, R6gd, M5 or M6g node
types.
• All clusters—primary and secondary—in your global datastore should have the same number of
primary nodes, node type, engine version, and number of shards (in case of cluster-mode enabled).
Each cluster in your global datastore can have a different number of read replicas to accommodate the
read traffic local to that cluster.
Note
Global datastores support pub/sub messaging with the following stipulations:
• For cluster-mode disabled, pub/sub is fully supported. Events published on the primary
cluster of the primary AWS Region are propagated to secondary AWS Regions.
1. Create a primary cluster, either by using an existing cluster or creating a new cluster. The engine must
be Redis 5.0.6 or later.
2. Add up to two secondary clusters in different AWS Regions, again using the Redis 5.0.6 engine or later.
The following procedures guide you on how to create a global datastore for Redis and perform other
operations using the ElastiCache for Redis console.
Topics
• Creating a global datastore using an existing cluster (p. 234)
• Creating a new global datastore using a new primary cluster (p. 236)
• Viewing global datastore details (p. 237)
• Adding a Region to a global datastore (p. 238)
• Modifying a global datastore (p. 240)
• Promoting the secondary cluster to primary (p. 240)
• Removing a Region from a global datastore (p. 241)
• Deleting a global datastore (p. 241)
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Redis and then choose a cluster.
3. For Actions, choose Setup Global Datastore.
4. On the Setup Global Datastore page, do the following:
• Enter a value for Global Datastore Name suffix: This suffix is used to generate a unique name for
the global datastore. You can search for the global datastore by using the suffix that you specify
here.
• (Optional) Enter a Description value.
5. Under Secondary cluster details, choose a different AWS Region where the cluster will be stored.
6. Under Redis settings, enter a value for Name and, optionally, for Description for the cluster.
7. Keep the following options as they are. They're prepopulated to match the primary cluster
configuration, you can't change them.
• Engine version
• Node type
• Parameter group
Note
ElastiCache autogenerates a new parameter group from values of the provided parameter
group and applies the new parameter group to the cluster. Use this new parameter group
to modify parameters on a global datastore. Each autogenerated parameter group is
associated with one and only one cluster and, therefore, only one global datastore.
• Number of shards
• Encryption at rest – Enables encryption of data stored on disk. For more information, see
Encryption at rest.
Note
You can supply a different encryption key by choosing Customer Managed AWS KMS
key and choosing the key. For more information, see Using Customer Managed AWS KMS
keys.
• Encryption in-transit – Enables encryption of data on the wire. For more information, see
Encryption in transit. For Redis engine version 6.0 onwards, if you enable encryption in-transit you
are prompted to specify one of the following Access Control options:
• No Access Control – This is the default setting. This indicates no restrictions.
• User Group Access Control List – Choose a user group with a defined set of users and
permissions on available operations. For more information, see Managing User Groups with the
Console and CLI (p. 495).
• Redis AUTH Default User – An authentication mechanism for Redis server. For more
information, see Redis AUTH.
8. (Optional) As needed, update the remaining secondary cluster settings. These are prepopulated with
the same values as the primary cluster, but you can update them to meet specific requirements for
that cluster.
• Port
• Number of replicas
• Subnet group
• Preferred Availability Zone(s)
• Security groups
• Customer Managed (AWS KMS key)
• Redis AUTH Token
• Enable automatic backups
• Backup retention period
• Backup window
• Maintenance window
• Topic for SNS notification
9. Choose Create. Doing this sets the status of the global datastore to Creating. The status transitions
to Modifying after the primary cluster is associated to the global datastore and the secondary
cluster is in Associating status.
After the primary cluster and secondary clusters are associated with the global datastore, the status
changes to Available. At this point, you have a primary cluster that accepts reads and writes and
secondary clusters that accept API Version
reads 2015-02-02
replicated from the primary cluster.
235
Amazon ElastiCache for Redis User Guide
Using global datastores (console)
The Redis page is updated to indicate whether a cluster is part of a global datastore, including:
• Global Datastore – The name of the global datastore to which the cluster belongs.
• Global Datastore Role – The role of the cluster, either primary or secondary.
You can add up to one additional secondary cluster in a different AWS Region. For more information, see
Adding a Region to a global datastore (p. 238).
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore and then choose Create.
3. Under Create Global Datastore, do the following:
a. Enter a value for Global Datastore Name suffix. ElastiCache uses the suffix to generate a unique
name for the global datastore. You can search for the global datastore by using the suffix that
you specify here.
b. (Optional) Enter a value for Global Datastore Description.
4. Under Primary cluster details, for Region, choose an available AWS Region.
5. Follow the steps at Creating a Redis (cluster mode enabled) cluster (console).
Note
When you select a parameter group to set the engine configuration values, that parameter
group is applied to all clusters in the global datastore. On the Parameter Groups page, the
yes/no Global attribute indicates whether a parameter group is part of a global datastore.
6. After you have successfully created the cluster in the previous step, choose Next to configure your
secondary cluster details, which are outlined in the previous section beginning with Step 5.
7. The following options are prepopulated to match the primary cluster configuration and cannot be
changed:
• Engine version
• Instance type
• Node type
• Number of shards
• Parameter group
Note
ElastiCache autogenerates a new parameter group from values of the provided parameter
group and applies the new parameter group to the cluster. Use this new parameter group
to modify parameters on a global datastore. Each autogenerated parameter group is
associated with one and only one cluster and, therefore, only one global datastore.
• Encryption at rest – Enables encryption of data stored on disk. For more information, see
Encryption at rest.
Note
You can supply a different encryption key by choosing Customer Managed AWS KMS
key and choosing the key. For more information, see Using Customer Managed AWS KMS
keys.
• Encryption in-transit – Enables encryption of data on the wire. For more information, see
Encryption in transit. For Redis engine version 6.4 and above, if you enable encryption in-transit
you are prompted to specify one of the following Access Control options:
• No Access Control – This is the default setting. This indicates no restrictions on user access to
the cluster.
• User Group Access Control List – Choose a user group with a defined set of users that can
access the cluster. For more information, see Managing User Groups with the Console and
CLI (p. 495).
• Redis AUTH Default User – An authentication mechanism for Redis server. For more
information, see Redis AUTH.
Note
For Redis versions between 4.0.2, when Encryption in-transit was first supported, and 6.0.4,
Redis AUTH is the sole option.
The remaining secondary cluster settings are pre-populated with the same values as the primary
cluster, but the following can be updated to meet specific requirements for that cluster:
• Port
• Number of replicas
• Subnet group
• Preferred Availability Zone(s)
• Security groups
• Customer Managed (AWS KMS key)
• Redis AUTH Token
• Enable automatic backups
• Backup retention period
• Backup window
• Maintenance window
• Topic for SNS notification
8. Choose Create. This sets the status of the global datastore to Creating. After the primary cluster
and secondary clusters are associated with the global datastore, the status changes to Available.
You have a primary cluster that accepts reads and writes and a secondary cluster that accepts reads
replicated from the primary cluster.
The Redis page is also updated to indicate whether a cluster is part of a global datastore, including
the following:
• Global Datastore – The name of the global datastore to which the cluster belongs.
• Global Datastore Role – The role of the cluster, either primary or secondary.
You can add up to one additional secondary cluster in a different AWS Region. For more information, see
Adding a Region to a global datastore (p. 238).
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. Global
On the navigation pane, chooseAPI Datastore
Version and then choose an available global datastore.
2015-02-02
237
Amazon ElastiCache for Redis User Guide
Using global datastores (console)
The Global Datastore page also lists the individual clusters that make up the global datastore and the
following properties for each:
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore, and then for Global Datastore Name choose a
global datastore.
3. Choose Add Region, and choose the AWS Region where the secondary cluster is to reside.
4. Under Redis settings, enter a value for Name and, optionally, for Description for the cluster.
5. Keep the following options as they are. They're prepopulated to match the primary cluster
configuration, and you can't change them.
• Engine version
• Instance type
• Node type
• Number of shards
• Parameter group
Note
ElastiCache autogenerates a new parameter group from values of the provided parameter
group and applies the new parameter group to the cluster. Use this new parameter group
to modify parameters on a global datastore. Each autogenerated parameter group is
associated with one and only one cluster and, therefore, only one global datastore.
• Encryption at rest
Note
You can supply a different encryption key by choosing Customer Managed AWS KMS key
and choosing the key.
• Encryption in transit
• Redis AUTH
6. (Optional) Update the remaining secondary cluster settings. These are prepopulated with the same
values as the primary cluster, but you can update them to meet specific requirements for that
cluster:
• Port
• Number of replicas
• Subnet group
• Preferred Availability Zone(s)
• Security groups
• Customer Managed AWS KMS key)
• Redis AUTH Token
• Enable automatic backups
• Backup retention period
• Backup window
• Maintenance window
• Topic for SNS notification
7. Choose Add.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore, and then for Global Datastore Name, choose a
global datastore.
3. Choose Modify and choose among the following options:
• Add shards – Enter the number of shards to add and optionally specify one or more Availability
Zones.
• Delete shards – Choose shards to be deleted in each AWS Region.
• Rebalance shards – Rebalance the slot distribution to ensure uniform distribution across existing
shards in the cluster.
To modify a global datastore's parameters, modify the parameter group of any member cluster for
the global datastore. ElastiCache applies this change to all clusters within that global datastore
automatically. To modify the parameter group of that cluster, use the Redis console or the
ModifyCacheCluster API operation. For more information, see Modifying a parameter group (p. 435).
When you modify the parameter group of any cluster contained within a global datastore, it is applied to
all the clusters within that global datastore.
To reset an entire parameter group or specific parameters, use the ResetCacheParameterGroup API
operation.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore under Redis.
You're then prompted to confirm your decision with the following warning: Promoting a region
to primary will make the cluster in this region as read/writable. Are you
sure you want to promote the secondary cluster to primary?
The current primary cluster in primary region will become secondary and
will stop accepting writes after this operation completes. Please ensure you
update your application stack to direct traffic to the new primary region.
6. Choose Confirm if you want to continue the promotion or Cancel if you don't.
If you choose to confirm, your global datastore moves to a Modifying state and is unavailable until the
promotion is complete.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore under Redis.
3. Choose a global datastore.
4. Choose the Region you want to remove.
5. Choose Remove region.
Note
This option is only available for secondary clusters.
You're then be prompted to confirm your decision with the following warning: Removing the
region will remove your only available cross region replica for the primary
cluster. Your primary cluster will no longer be set up for disaster recovery
and improved read latency in remote region. Are you sure you want to remove
the selected region from the global datastore?
6. Choose Confirm if you want to continue the promotion or Cancel if you don't.
If you choose confirm, the AWS Region is removed and the secondary cluster no longer receives
replication updates.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the navigation pane, choose Global Datastore under Redis.
3. Under Global Datastore Name choose the global datastore you want to delete and then choose
Delete.
You're then be prompted to confirm your decision with the following warning: Are you sure you
want to delete this Global Datastore?
4. Choose Delete.
1. Download the AWS CLI on the AWS command line interface webpage.
2. Follow the instructions for Installing the AWS CLI and Configuring the AWS CLI in the AWS Command
Line Interface User Guide.
• create-global-replication-group
Amazon ElastiCache automatically applies a prefix to the global datastore ID when it is created.
Each AWS Region has its own prefix. For instance, a global datastore ID created in the US West
(N. California) Region begins with "dsdfu" along with the suffix name that you provide. The suffix,
combined with the autogenerated prefix, guarantees uniqueness of the global datastore name across
multiple Regions.
The following table lists each AWS Region and its global datastore ID prefix.
us-east-2
us-east-1
us-west-1
us-west-2
ca-central-1
ap-south-1
ap-northeast-1
ap-northeast-2
ap-northeast-3
ap-southeast-1
ap-southeast-2
eu-central-1
eu-west-1
eu-west-2
eu-west-3
sa-east-1
cn-north-1
cn-northwest-1
ap-east-1
us-gov-west-1
• create-replication-group – Use this operation to create secondary clusters for a global datastore by
supplying the name of the global datastore to the --global-replication-group-id parameter.
"PrimaryClusterId",
"AutomaticFailoverEnabled",
"NumNodeGroups",
"CacheParameterGroupName",
"CacheNodeType",
"Engine",
"EngineVersion",
"CacheSecurityGroupNames",
"EnableTransitEncryption",
"AtRestEncryptionEnabled",
"SnapshotArns",
"SnapshotName"
• describe-global-replication-groups
• modify-global-replication-group
• delete-global-replication-group
• disassociate-global-replication-group
• failover-global-replication-group
• increase-node-groups-in-global-replication-group
• decrease-node-groups-in-global-replication-group
• rebalance-shards-in-global-replication-group
You can also use help to describe a specific command and learn more about its usage:
As seen in the following graphic, the replication structure is contained within a shard (called node group
in the API/CLI) which is contained within a Redis cluster. Redis (cluster mode disabled) clusters always
have one shard. Redis (cluster mode enabled) clusters can have up to 500 shards with the cluster's data
partitioned across the shards. You can create a cluster with higher number of shards and lower number
of replicas totaling up to 90 nodes per cluster. This cluster configuration can range from 90 shards and 0
replicas to 15 shards and 5 replicas, which is the maximum number of replicas allowed.
The node or shard limit can be increased to a maximum of 500 per cluster if the Redis engine version
is 5.0.6 or higher. For example, you can choose to configure a 500 node cluster that ranges between
83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and no replicas). Make
sure there are enough available IP addresses to accommodate the increase. Common pitfalls include the
subnets in the subnet group have too small a CIDR range or the subnets are shared and heavily used by
other clusters. For more information, see Creating a subnet group (p. 525).
To request a limit increase, see AWS Service Limits and choose the limit type Nodes per cluster per
instance type.
Redis (cluster mode disabled) cluster has one shard and 0 to 5 replica nodes
If the cluster with replicas has Multi-AZ enabled and the primary node fails, the primary fails over to a
read replica. Because the data is updated on the replica nodes asynchronously, there may be some data
loss due to latency in updating the replica nodes. For more information, see Mitigating Failures when
Running Redis (p. 622).
Topics
• Understanding Redis replication (p. 248)
• Replication: Redis (Cluster Mode Disabled) vs. Redis (Cluster Mode Enabled) (p. 250)
• Minimizing downtime in ElastiCache for Redis with Multi-AZ (p. 253)
• How synchronization and backup are implemented (p. 265)
• Creating a Redis replication group (p. 266)
• Viewing a replication group's details (p. 288)
• Finding replication group endpoints (p. 293)
• Modifying a replication group (p. 294)
• Deleting a replication group (p. 296)
• Changing the number of replicas (p. 297)
• Promoting a read replica to primary, for Redis (cluster mode disabled) replication groups (p. 309)
• With a single shard that contains all of the cluster's data in each node—Redis (cluster mode disabled)
• With data partitioned across up to 500 shards—Redis (cluster mode enabled)
Each shard in a replication group has a single read/write primary node and up to 5 read-only replica
nodes. You can create a cluster with higher number of shards and lower number of replicas totaling up to
90 nodes per cluster. This cluster configuration can range from 90 shards and 0 replicas to 15 shards and
5 replicas, which is the maximum number of replicas allowed.
The node or shard limit can be increased to a maximum of 500 per cluster if the Redis engine version
is 5.0.6 or higher. For example, you can choose to configure a 500 node cluster that ranges between
83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and no replicas). Make
sure there are enough available IP addresses to accommodate the increase. Common pitfalls include the
subnets in the subnet group have too small a CIDR range or the subnets are shared and heavily used by
other clusters. For more information, see Creating a subnet group (p. 525).
To request a limit increase, see AWS Service Limits and choose the limit type Nodes per cluster per
instance type.
Topics
• Redis (Cluster Mode Disabled) (p. 248)
• Redis (cluster mode enabled) (p. 249)
Redis (cluster mode disabled) cluster with a single shard and replica nodes
You can use Redis (cluster mode disabled) clusters with replica nodes to scale your Redis solution for
ElastiCache to handle applications that are read-intensive or to support large numbers of clients that
simultaneously read from the same cluster.
All of the nodes in a Redis (cluster mode disabled) cluster must reside in the same region.
When you add a read replica to a cluster, all of the data from the primary is copied to the new node.
From that point on, whenever data is written to the primary, the changes are asynchronously propagated
to all the read replicas.
To improve fault tolerance and reduce write downtime, enable Multi-AZ with Automatic Failover for your
Redis (cluster mode disabled) cluster with replicas. For more information, see Minimizing downtime in
ElastiCache for Redis with Multi-AZ (p. 253).
You can change the roles of the nodes within the Redis (cluster mode disabled) cluster, with the primary
and one of the replicas exchanging roles. You might decide to do this for performance tuning reasons.
For example, with a web application that has heavy write activity, you can choose the node that has the
lowest network latency. For more information, see Promoting a read replica to primary, for Redis (cluster
mode disabled) replication groups (p. 309).
The node or shard limit can be increased to a maximum of 500 per cluster if the Redis engine version
is 5.0.6 or higher. For example, you can choose to configure a 500 node cluster that ranges between
83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and no replicas). Make
sure there are enough available IP addresses to accommodate the increase. Common pitfalls include the
subnets in the subnet group have too small a CIDR range or the subnets are shared and heavily used by
other clusters. For more information, see Creating a subnet group (p. 525).
To request a limit increase, see AWS Service Limits and choose the limit type Nodes per cluster per
instance type.
Each read replica in a shard maintains a copy of the data from the shard's primary. Asynchronous
replication mechanisms are used to keep the read replicas synchronized with the primary. Applications
can read from any node in the cluster. Applications can write only to the primary nodes. Read replicas
enhance read scalability and guard against data loss. Data is partitioned across the shards in a Redis
(cluster mode enabled) cluster.
Applications use the Redis (cluster mode enabled) cluster's configuration endpoint to connect with the
nodes in the cluster. For more information, see Finding connection endpoints (p. 175).
Redis (cluster mode enabled) cluster with multiple shards and replica nodes
All of the nodes in a Redis (cluster mode enabled) cluster must reside in the same region. To improve
fault tolerance, you can provision both primaries and read replicas in multiple Availability Zones within
that region.
resizing (p. 334). The number of shards in a Redis (cluster mode enabled) cluster can be changed
dynamically, while the cluster continues to serve read and write requests. For more information, see
Online resharding and shard rebalancing for Redis (cluster mode enabled) (p. 377).
Redis (cluster mode disabled) and Redis (cluster mode enabled) clusters
The following table summarizes important differences between Redis (cluster mode disabled) and Redis
(cluster mode enabled) clusters.
Comparing Redis (Cluster Mode Disabled) and Redis (Cluster Mode Enabled) Clusters
Data Partitioning No Yes
Shards 1 1 to 500
Snapshots (Backups) Yes, creating a single .rdb file. Yes, creating a unique .rdb file
for each shard.
Restore Yes, using a single .rdb file from Yes, using .rdb files from either a
a Redis (cluster mode disabled) Redis (cluster mode disabled) or
cluster. a Redis (cluster mode enabled)
cluster.
Engine upgradeable Yes, with some limits. For more Yes, with some limits. For more
information, see Upgrading information, see Upgrading
engine versions (p. 198). engine versions (p. 198).
Encryption Versions 3.2.6 and 4.0.10 and Versions 3.2.6 and 4.0.10 and
later. later.
HIPAA Eligible Version 3.2.6 and 4.0.10 and Version 3.2.6 and 4.0.10 and
later. later.
PCI DSS Compliant Version 3.2.6 and 4.0.10 and Version 3.2.6 and 4.0.10 and
later. later.
• Scaling v. partitioning – Business needs change. You need to either provision for peak demand or
scale as demand changes. Redis (cluster mode disabled) supports scaling. You can scale read capacity
by adding or deleting replica nodes, or you can scale capacity by scaling up to a larger node type. Both
of these operations take time. For more information, see Scaling Redis (Cluster Mode Disabled) clusters
with replica nodes (p. 360).
Redis (cluster mode enabled) supports partitioning your data across up to 500 node groups. You
can dynamically change the number of shards as your business needs change. One advantage of
partitioning is that you spread your load over a greater number of endpoints, which reduces access
bottlenecks during peak demand. Additionally, you can accommodate a larger data set since the data
can be spread across multiple servers. For information on scaling your partitions, see Scaling clusters in
Redis (Cluster Mode Enabled) (p. 375).
• Node size v. number of nodes – Because a Redis (cluster mode disabled) cluster has only one shard,
the node type must be large enough to accommodate all the cluster's data plus necessary overhead.
On the other hand, because you can partition your data across several shards when using a Redis
(cluster mode enabled) cluster, the node types can be smaller, though you need more of them. For
more information, see Choosing your node size (p. 127).
• Reads v. writes – If the primary load on your cluster is applications reading data, you can scale a Redis
(cluster mode disabled) cluster by adding and deleting read replicas. However, there is a maximum of
5 read replicas. If the load on your cluster is write-heavy, you can benefit from the additional write
endpoints of a Redis (cluster mode enabled) cluster with multiple shards.
Whichever type of cluster you choose to implement, be sure to choose a node type that is adequate for
your current and future needs.
This replacement results in some downtime for the cluster, but if Multi-AZ is enabled, the downtime is
minimized. The role of primary node will automatically fail over to one of the read replicas. There is no
need to create and provision a new primary node, because ElastiCache will handle this transparently.
This failover and replica promotion ensure that you can resume writing to the new primary as soon as
promotion is complete.
ElastiCache also propagates the Domain Name Service (DNS) name of the promoted replica. It does
so because then if your application is writing to the primary endpoint, no endpoint change is required
in your application. If you are reading from individual endpoints, make sure that you change the read
endpoint of the replica promoted to primary to the new replica's endpoint.
In case of planned node replacements initiated due to maintenance updates or self-service updates, be
aware of the following:
• For ElastiCache for Redis Cluster, the planned node replacements complete while the cluster serves
incoming write requests.
• For Redis Cluster mode disabled clusters with Multi-AZ enabled that run on the 5.0.5 or later engine,
the planned node replacements complete while the cluster serves incoming write requests.
• For Redis Cluster mode disabled clusters with Multi-AZ enabled that run on the 5.0.4 or earlier engine,
you might notice a brief write interruption associated with DNS updates. This interruption might take
up to a few seconds. This process is much faster than recreating and provisioning a new primary, which
is what occurs if you don't enable Multi-AZ.
You can enable Multi-AZ using the ElastiCache Management Console, the AWS CLI, or the ElastiCache
API.
Enabling ElastiCache Multi-AZ on your Redis cluster (in the API and CLI, replication group) improves your
fault tolerance. This is true particularly in cases where your cluster's read/write primary cluster becomes
unreachable or fails for any reason. Multi-AZ is only supported on Redis clusters that have more than one
node in each shard.
Topics
• Enabling Multi-AZ (p. 253)
• Failure scenarios with Multi-AZ responses (p. 257)
• Testing automatic failover (p. 260)
• Limitations on Redis Multi-AZ (p. 263)
Enabling Multi-AZ
You can enable Multi-AZ when you create or modify a cluster (API or CLI, replication group) using the
ElastiCache console, AWS CLI, or the ElastiCache API.
You can enable Multi-AZ only on Redis (cluster mode disabled) clusters that have at least one available
read replica. Clusters without read replicas do not provide high availability or fault tolerance. For
information about creating a cluster with replication, see Creating a Redis replication group (p. 266).
For information about adding a read replica to a cluster with replication, see Adding a read replica, for
Redis (Cluster Mode Disabled) replication groups (p. 306).
Topics
• Enabling Multi-AZ (Console) (p. 254)
• Enabling Multi-AZ (AWS CLI) (p. 254)
• Enabling Multi-AZ (ElastiCache API) (p. 255)
For more information on this process, see Creating a Redis (cluster mode disabled) cluster
(Console) (p. 47). Be sure to have one or more replicas and enable Multi-AZ.
For more information on this process, see Modifying a Cluster Using the AWS Management
Console (p. 149).
For Windows:
The JSON output from this command should look something like the following.
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "One shard, two nodes",
"NodeGroups": [
{
"Status": "modifying",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis12-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis12-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "redis12",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabling",
"MultiAZ": "enabled",
"SnapshotWindow": "07:00-08:00",
"SnapshottingClusterId": "redis12-002",
"MemberClusters": [
"redis12-001",
"redis12-002"
],
"PendingModifiedValues": {}
}
}
For more information, see these topics in the AWS CLI Command Reference:
• create-cache-cluster
• create-replication-group
• modify-replication-group in the AWS CLI Command Reference.
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&AutoFailover=true
&MultiAZEnabled=true
&ReplicationGroupId=redis12
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20140401T192317Z
&X-Amz-Credential=<credential>
For more information, see these topics in the ElastiCache API Reference:
• CreateCacheCluster
• CreateReplicationGroup
• ModifyReplicationGroup
When Multi-AZ is enabled, ElastiCache continually monitors the state of the primary node. If the primary
node fails, one of the following actions is performed depending on the type of failure.
Topics
• Failure scenarios when only the primary node fails (p. 257)
• Failure scenarios when the primary node and some read replicas fail (p. 258)
• Failure scenarios when the entire cluster fails (p. 258)
When only the primary node fails, ElastiCache Multi-AZ does the following:
Writes can resume as soon as the promotion process is complete, typically just a few seconds. If your
application is writing to the primary endpoint, you don't need to change the endpoint for writes or
reads. ElastiCache propagates the DNS name of the promoted replica.
3. A replacement read replica is launched and provisioned.
The replacement read replica is launched in the Availability Zone that the failed primary node was in
so that the distribution of nodes is maintained.
4. The replicas sync with the new primary node.
• Primary endpoint – You don't need to make any changes to your application, because the DNS name
of the new primary node is propagated to the primary endpoint.
• Read endpoint – The reader endpoint is automatically updated to point to the new replica nodes.
For information about finding the endpoints of a cluster, see the following topics:
• Finding a Redis (Cluster Mode Disabled) Cluster's Endpoints (Console) (p. 176)
• Finding the Endpoints for Replication Groups (AWS CLI) (p. 181)
• Finding Endpoints for Replication Groups (ElastiCache API) (p. 183)
Failure scenarios when the primary node and some read replicas fail
If the primary and at least one read replica fails, the available replica with the least replication lag is
promoted to primary cluster. New read replicas are also created and provisioned in the same Availability
Zones as the failed nodes and replica that was promoted to primary.
When the primary node and some read replicas fail, ElastiCache Multi-AZ does the following:
1. The failed primary node and failed read replicas are taken offline.
2. The available replica with the least replication lag is promoted to primary node.
Writes can resume as soon as the promotion process is complete, typically just a few seconds. If your
application is writing to the primary endpoint, there is no need to change the endpoint for writes.
ElastiCache propagates the DNS name of the promoted replica.
3. Replacement replicas are created and provisioned.
The replacement replicas are created in the Availability Zones of the failed nodes so that the
distribution of nodes is maintained.
4. All clusters sync with the new primary node.
Make the following changes to your application after the new nodes are available:
• Primary endpoint – Don't make any changes to your application. The DNS name of the new primary
node is propagated to the primary endpoint.
• Read endpoint – The read endpoint is automatically updated to point to the new replica nodes.
For information about finding the endpoints of a replication group, see the following topics:
• Finding a Redis (Cluster Mode Disabled) Cluster's Endpoints (Console) (p. 176)
• Finding the Endpoints for Replication Groups (AWS CLI) (p. 181)
• Finding Endpoints for Replication Groups (ElastiCache API) (p. 183)
In this scenario, all the data in the cluster is lost due to the failure of every node in the cluster. This
occurrence is rare.
When the entire cluster fails, ElastiCache Multi-AZ does the following:
1. The failed primary node and read replicas are taken offline.
2. A replacement primary node is created and provisioned.
3. Replacement replicas are created and provisioned.
The replacements are created in the Availability Zones of the failed nodes so that the distribution of
nodes is maintained.
Because the entire cluster failed, data is lost and all the new nodes start cold.
Because each of the replacement nodes has the same endpoint as the node it's replacing, you don't need
to make any endpoint changes in your application.
For information about finding the endpoints of a replication group, see the following topics:
• Finding a Redis (Cluster Mode Disabled) Cluster's Endpoints (Console) (p. 176)
• Finding the Endpoints for Replication Groups (AWS CLI) (p. 181)
• Finding Endpoints for Replication Groups (ElastiCache API) (p. 183)
We recommend that you create the primary node and read replicas in different Availability Zones to raise
your fault tolerance level.
• You can use this operation to test automatic failover on up to five shards (called node groups in the
ElastiCache API and AWS CLI) in any rolling 24-hour period.
• If you call this operation on shards in different clusters (called replication groups in the API and CLI),
you can make the calls concurrently.
• In some cases, you might call this operation multiple times on different shards in the same Redis
(cluster mode enabled) replication group. In such cases, the first node replacement must complete
before a subsequent call can be made.
• To determine whether the node replacement is complete, check events using the Amazon ElastiCache
console, the AWS CLI, or the ElastiCache API. Look for the following events related to automatic
failover, listed here in order of likely occurrence:
1. Replication group message: Test Failover API called for node group <node-group-
id>
2. Cache cluster message: Failover from primary node <primary-node-id> to replica
node <node-id> completed
3. Replication group message: Failover from primary node <primary-node-id> to
replica node <node-id> completed
4. Cache cluster message: Recovering cache nodes <node-id>
5. Cache cluster message: Finished recovery for cache nodes <node-id>
Topics
• Testing automatic failover using the AWS Management Console (p. 260)
• Testing automatic failover using the AWS CLI (p. 261)
• Testing automatic failover using the ElastiCache API (p. 263)
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Redis.
3. From the list of Redis clusters, choose the box to the left of the cluster you want to test. This cluster
must have at least one read replica node.
API Version 2015-02-02
260
Amazon ElastiCache for Redis User Guide
Minimizing downtime with Multi-AZ
4. In the Details area, confirm that this cluster is Multi-AZ enabled. If the cluster isn't Multi-AZ enabled,
either choose a different cluster or modify this cluster to enable Multi-AZ. For more information, see
Using the AWS Management Console (p. 149).
During the failover process, the console continues to show the node's status as available. To track
the progress of your failover test, choose Events from the console navigation pane. On the Events
tab, watch for events that indicate your failover has started (Test Failover API called) and
completed (Recovery completed).
Parameters
• --replication-group-id – Required. The replication group (on the console, cluster) that is to be
tested.
• --node-group-id – Required. The name of the node group you want to test automatic failover on.
You can test a maximum of five node groups in a rolling 24-hour period.
The following example uses the AWS CLI to test automatic failover on the node group redis00-0003 in
the Redis (cluster mode enabled) cluster redis00.
--replication-group-id redis00 \
--node-group-id redis00-0003
For Windows:
Output from the preceding command looks something like the following.
{
"ReplicationGroup": {
"Status": "available",
"Description": "1 shard, 3 nodes (1 + 2 replicas)",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-002"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-003"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ClusterEnabled": false,
"ReplicationGroupId": "redis1x3",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"MultiAZ": "enabled",
"SnapshotWindow": "11:30-12:30",
"SnapshottingClusterId": "redis1x3-002",
"MemberClusters": [
"redis1x3-001",
"redis1x3-002",
"redis1x3-003"
],
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled"
"PendingModifiedValues": {}
}
}
To track the progress of your failover, use the AWS CLI describe-events operation.
Parameters
• ReplicationGroupId – Required. The replication group (on the console, cluster) to be tested.
• NodeGroupId – Required. The name of the node group that you want to test automatic failover on.
You can test a maximum of five node groups in a rolling 24-hour period.
The following example tests automatic failover on the node group redis00-0003 in the replication
group (on the console, cluster) redis00.
https://elasticache.us-west-2.amazonaws.com/
?Action=TestFailover
&NodeGroupId=redis00-0003
&ReplicationGroupId=redis00
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20140401T192317Z
&X-Amz-Credential=<credential>
To track the progress of your failover, use the ElastiCache DescribeEvents API operation.
When choosing the replica to promote to primary, ElastiCache for Redis chooses the replica with
the least replication lag. In other words, it chooses the replica that is most current. Doing so helps
minimize the amount of lost data. The replica with the least replication lag can be in the same or
different Availability Zone from the failed primary node.
• When you manually promote read replicas to primary on Redis (cluster mode disabled), you can do so
only when Multi-AZ and automatic failover are disabled. To promote a read replica to primary, take the
following steps:
1. Disable Multi-AZ on the cluster.
2. Disable automatic failover on the cluster. You can do this using the Redis console by clearing the
Auto failover check box for the replication group. You can do this using the AWS CLI by setting the
AutomaticFailoverEnabled property to false when calling the ModifyReplicationGroup
operation.
3. Promote the read replica to primary.
4. Re-enable Multi-AZ.
• ElastiCache for Redis Multi-AZ and append-only file (AOF) are mutually exclusive. If you enable one,
you can't enable the other.
• A node's failure can be caused by the rare event of an entire Availability Zone failing. In this case, the
replica replacing the failed primary is created only when the Availability Zone is back up. For example,
consider a replication group with the primary in AZ-a and replicas in AZ-b and AZ-c. If the primary fails,
the replica with the least replication lag is promoted to primary cluster. Then, ElastiCache creates a
new replica in AZ-a (where the failed primary was located) only when AZ-a is back up and available.
• A customer-initiated reboot of a primary doesn't trigger automatic failover. Other reboots and failures
do trigger automatic failover.
• When the primary is rebooted, it's cleared of data when it comes back online. When the read replicas
see the cleared primary cluster, they clear their copy of the data, which causes data loss.
• After a read replica has been promoted, the other replicas sync with the new primary. After the initial
sync, the replicas' content is deleted and they sync the data from the new primary. This sync process
causes a brief interruption, during which the replicas are not accessible. The sync process also causes a
temporary load increase on the primary while syncing with the replicas. This behavior is native to Redis
and isn't unique to ElastiCache Multi-AZ. For details about this Redis behavior, see Replication on the
Redis website.
Important
For Redis version 2.8.22 and later, you can't create external replicas.
For Redis versions before 2.8.22, we recommend that you don't connect an external Redis replica
to an ElastiCache for Redis cluster that is Multi-AZ enabled. This unsupported configuration
can create issues that prevent ElastiCache from properly performing failover and recovery. To
connect an external Redis replica to an ElastiCache cluster, make sure that Multi-AZ isn't enabled
before you make the connection.
During the forkless process, if the write loads are heavy, writes to the cluster are delayed to ensure that
you don't accumulate too many changes and thus prevent a successful snapshot.
1. Fork, and in the background process, serialize the cluster data to disk. This creates a point-in-time
snapshot.
2. In the foreground, accumulate a change log in the client output buffer.
Important
If the change log exceeds the client output buffer size, the backup or synchronization
fails. For more information, see Ensuring that you have enough memory to create a Redis
snapshot (p. 221).
3. Finally, transmit the cache data and then the change log to the replica node.
Option 1: Creating a Replication Group Using an Available Redis (Cluster Mode Disabled)
Cluster (p. 267)
Use this option to leverage an existing single-node Redis (cluster mode disabled) cluster. You specify
this existing node as the primary node in the new cluster, and then individually add 1 to 5 read
replicas to the cluster. If the existing cluster is active, read replicas synchronize with it as they
are created. See Creating a Replication Group Using an Available Redis (Cluster Mode Disabled)
Cluster (p. 267).
Important
You cannot create a Redis (cluster mode enabled) cluster using an existing cluster. To create
a Redis (cluster mode enabled) cluster (API/CLI: replication group) using the ElastiCache
console, see Creating a Redis (cluster mode enabled) cluster (Console) (p. 132).
Option 2: Creating a Redis replication group from scratch (p. 272)
Use this option if you don't already have an available Redis (cluster mode disabled) cluster to use
as the cluster's primary node, or if you want to create a Redis (cluster mode enabled) cluster. See
Creating a Redis replication group from scratch (p. 272).
The following procedure can only be used if you have a Redis (cluster mode disabled) single-node cluster.
This cluster's node becomes the primary node in the new cluster. If you do not have a Redis (cluster mode
disabled) cluster that you can use as the new cluster's primary, see Creating a Redis replication group
from scratch (p. 272).
Creating a replication group using an available Redis cache cluster (AWS CLI)
There are two steps to creating a replication group with read replicas when using an available Redis
Cache Cluster for the primary when using the AWS CLI.
When using the AWS CLI you create a replication group specifying the available standalone node as the
cluster's primary node, --primary-cluster-id and the number of nodes you want in the cluster using
the CLI command, create-replication-group. Include the following parameters.
--replication-group-id
The name of the replication group you are creating. The value of this parameter is used as the basis
for the names of the added nodes with a sequential 3-digit number added to the end of the --
replication-group-id. For example, sample-repl-group-001.
Redis (cluster mode disabled) replication group naming constraints are as follows:
• Must contain 1–40 alphanumeric characters or hyphens.
• Must begin with a letter.
• Can't contain two consecutive hyphens.
• Can't end with a hyphen.
--replication-group-description
The number of nodes you want in this cluster. This value includes the primary node. This parameter
has a maximum value of six.
--primary-cluster-id
The name of the available Redis (cluster mode disabled) cluster's node that you want to be the
primary node in this replication group.
The following command creates the replication group sample-repl-group using the available Redis
(cluster mode disabled) cluster redis01 as the replication group's primary node. It creates 2 new nodes
which are read replicas. The settings of redis01 (that is, parameter group, security group, node type,
engine version, and so on.) will be applied to all nodes in the replication group.
For Windows:
For additional information and parameters you might want to use, see the AWS CLI topic create-
replication-group.
After the replication group is created, add one to five read replicas to it using the create-cache-
cluster command, being sure to include the following parameters.
--cache-cluster-id
The name of the cluster you are adding to the replication group.
--replication-group-id
The name of the replication group to which you are adding this cache cluster.
Repeat this command for each read replica you want to add to the replication group, changing only the
value of the --cache-cluster-id parameter.
Note
Remember, a replication group cannot have more than five read replicas. Attempting to add a
read replica to a replication group that already has five read replicas causes the operation to fail.
The following code adds the read replica my-replica01 to the replication group sample-repl-group.
The settings of the primary cluster–parameter group, security group, node type, and so on.–will be
applied to nodes as they are added to the replication group.
For Windows:
--cache-cluster-id my-replica01 ^
--replication-group-id sample-repl-group
{
"ReplicationGroup": {
"Status": "creating",
"Description": "demo cluster with replicas",
"ClusterEnabled": false,
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "disabled",
"SnapshotWindow": "00:00-01:00",
"SnapshottingClusterId": "redis01",
"MemberClusters": [
"sample-repl-group-001",
"sample-repl-group-002",
"redis01"
],
"CacheNodeType": "cache.m4.large",
"DataTiering": "disabled"
"PendingModifiedValues": {}
}
}
• create-replication-group
• modify-replication-group
ReplicationGroupId
The name of the replication group you are creating. The value of this parameter is used as the
basis for the names of the added nodes with a sequential 3-digit number added to the end of the
ReplicationGroupId. For example, sample-repl-group-001.
Redis (cluster mode disabled) replication group naming constraints are as follows:
• Must contain 1–40 alphanumeric characters or hyphens.
• Must begin with a letter.
• Can't contain two consecutive hyphens.
• Can't end with a hyphen.
ReplicationGroupDescription
The number of nodes you want in this cluster. This value includes the primary node. This parameter
has a maximum value of six.
PrimaryClusterId
The name of the available Redis (cluster mode disabled) cluster that you want to be the primary
node in this cluster.
The following command creates the cluster with replicas sample-repl-group using the available Redis
(cluster mode disabled) cluster redis01 as the replication group's primary node. It creates 2 new nodes
which are read replicas. The settings of redis01 (that is, parameter group, security group, node type,
engine version, and so on.) will be applied to all nodes in the replication group.
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&Engine=redis
&EngineVersion=3.2.4
&ReplicationGroupDescription=Demo%20cluster%20with%20replicas
&ReplicationGroupId=sample-repl-group
&PrimaryClusterId=redis01
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
• CreateReplicationGroup
• ModifyReplicationGroup
After the replication group is created, add one to five read replicas to it using the
CreateCacheCluster operation, being sure to include the following parameters.
CacheClusterId
The name of the cluster you are adding to the replication group.
ReplicationGroupId
The name of the replication group to which you are adding this cache cluster.
Repeat this operation for each read replica you want to add to the replication group, changing only the
value of the CacheClusterId parameter.
The following code adds the read replica myReplica01 to the replication group myReplGroup The
settings of the primary cluster–parameter group, security group, node type, and so on.–will be applied to
nodes as they are added to the replication group.
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheCluster
&CacheClusterId=myReplica01
&ReplicationGroupId=myReplGroup
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2015-02-02
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Credential=[your-access-key-id]/20150202/us-west-2/elasticache/aws4_request
&X-Amz-Date=20150202T170651Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=[signature-value]
For additional information and parameters you might want to use, see the ElastiCache API topic
CreateCacheCluster.
Before you continue, decide whether you want to create a Redis (cluster mode disabled) or a Redis
(cluster mode enabled) replication group. For guidance in deciding, see Replication: Redis (Cluster Mode
Disabled) vs. Redis (Cluster Mode Enabled) (p. 250).
Topics
• Creating a Redis (Cluster Mode Disabled) replication group from scratch (p. 273)
• Creating a replication group in Redis (Cluster Mode Enabled) from scratch (p. 280)
To create a Redis (cluster mode disabled) replication group from scratch, take one of the following
approaches:
Creating a Redis (Cluster Mode Disabled) replication group from scratch (AWS CLI)
The following procedure creates a Redis (cluster mode disabled) replication group using the AWS CLI.
When you create a Redis (cluster mode disabled) replication group from scratch, you create the
replication group and all its nodes with a single call to the AWS CLI create-replication-group
command. Include the following parameters.
--replication-group-id
Redis (cluster mode disabled) replication group naming constraints are as follows:
• Must contain 1–40 alphanumeric characters or hyphens.
• Must begin with a letter.
• Can't contain two consecutive hyphens.
• Can't end with a hyphen.
--replication-group-description
The number of nodes you want created with this replication group, primary and read replicas
combined.
ElastiCache supports the following node types. Generally speaking, the current generation types
provide more memory and computational power at lower cost when compared to their equivalent
previous generation counterparts.
For more information on performance details for each node type, see Amazon EC2 Instance Types.
• General purpose:
• Current generation:
M6g node types (available only for Redis engine version 5.0.6 onward).
T4g node types (available only for Redis engine version 6.0 onward).
R6gd node types (available only for Redis engine version 6.2 onward). For more information,
see Data tiering (p. 121).
(R6g node types are available only for Redis engine version 5.0.6 onward.)
--data-tiering-enabled
Set this parameter if you are using an r6gd node type. If you don't want data tiering, set --no-
data-tiering-enabled. For more information, see Data tiering (p. 121).
--cache-parameter-group
Specify a parameter group that corresponds to your engine version. If you are running Redis
3.2.4 or later, specify the default.redis3.2 parameter group or a parameter group derived
from default.redis3.2 to create a Redis (cluster mode disabled) replication group. For more
information, see Redis-specific parameters (p. 441).
--engine
redis
--engine-version
To have the richest set of features, choose the latest engine version.
The names of the nodes will be derived from the replication group name by postpending -00# to
the replication group name. For example, using the replication group name myReplGroup, the
name for the primary will be myReplGroup-001 and the read replicas myReplGroup-002 through
myReplGroup-006.
If you want to enable in-transit or at-rest encryption on this replication group, add either or both of the
--transit-encryption-enabled or --at-rest-encryption-enabled parameters and meet the
following conditions.
The following operation creates a Redis (cluster mode disabled) replication group sample-repl-group
with three nodes, a primary and two replicas.
For Windows:
--engine-version 3.2.4
{
"ReplicationGroup": {
"Status": "creating",
"Description": "Demo cluster with replicas",
"ClusterEnabled": false,
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 0,
"AutomaticFailover": "disabled",
"SnapshotWindow": "01:30-02:30",
"MemberClusters": [
"sample-repl-group-001",
"sample-repl-group-002",
"sample-repl-group-003"
],
"CacheNodeType": "cache.m4.large",
"DataTiering": "disabled"
"PendingModifiedValues": {}
}
}
For additional information and parameters you might want to use, see the AWS CLI topic create-
replication-group.
Creating a Redis (cluster mode disabled) replication group from scratch (ElastiCache API)
The following procedure creates a Redis (cluster mode disabled) replication group using the ElastiCache
API.
When you create a Redis (cluster mode disabled) replication group from scratch, you create the
replication group and all its nodes with a single call to the ElastiCache API CreateReplicationGroup
operation. Include the following parameters.
ReplicationGroupId
Redis (cluster mode enabled) replication group naming constraints are as follows:
• Must contain 1–40 alphanumeric characters or hyphens.
• Must begin with a letter.
• Can't contain two consecutive hyphens.
• Can't end with a hyphen.
ReplicationGroupDescription
The total number of nodes you want created with this replication group, primary and read replicas
combined.
ElastiCache supports the following node types. Generally speaking, the current generation types
provide more memory and computational power at lower cost when compared to their equivalent
previous generation counterparts.
For more information on performance details for each node type, see Amazon EC2 Instance Types.
• General purpose:
• Current generation:
M6g node types (available only for Redis engine version 5.0.6 onward).
T4g node types (available only for Redis engine version 6.0 onward).
R6gd node types (available only for Redis engine version 6.2 onward). For more information,
see Data tiering (p. 121).
(R6g node types are available only for Redis engine version 5.0.6 onward.)
Note
For region availability, see Supported node types by AWS Region (p. 101).
Set this parameter if you are using an r6gd node type. If you don't want data tiering, set --no-
data-tiering-enabled. For more information, see Data tiering (p. 121).
CacheParameterGroup
Specify a parameter group that corresponds to your engine version. If you are running Redis
3.2.4 or later, specify the default.redis3.2 parameter group or a parameter group derived
from default.redis3.2 to create a Redis (cluster mode disabled) replication group. For more
information, see Redis-specific parameters (p. 441).
Engine
redis
EngineVersion
3.2.4
The names of the nodes will be derived from the replication group name by postpending -00# to
the replication group name. For example, using the replication group name myReplGroup, the
name for the primary will be myReplGroup-001 and the read replicas myReplGroup-002 through
myReplGroup-006.
If you want to enable in-transit or at-rest encryption on this replication group, add either or both of the
TransitEncryptionEnabled=true or AtRestEncryptionEnabled=true parameters and meet the
following conditions.
The following operation creates the Redis (cluster mode disabled) replication group myReplGroup with
three nodes, a primary and two replicas.
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&CacheNodeType=cache.m4.large
&CacheParameterGroup=default.redis3.2
&Engine=redis
&EngineVersion=3.2.4
&NumCacheClusters=3
&ReplicationGroupDescription=test%20group
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For additional information and parameters you might want to use, see the ElastiCache API topic
CreateReplicationGroup.
The node or shard limit can be increased to a maximum of 500 per cluster if the Redis engine version
is 5.0.6 or higher. For example, you can choose to configure a 500 node cluster that ranges between
83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and no replicas). Make
sure there are enough available IP addresses to accommodate the increase. Common pitfalls include the
subnets in the subnet group have too small a CIDR range or the subnets are shared and heavily used by
other clusters. For more information, see Creating a subnet group (p. 525).
To request a limit increase, see AWS Service Limits and choose the limit type Nodes per cluster per
instance type.
To create a Redis (cluster mode enabled) cluster, see Creating a Redis (cluster mode enabled) cluster
(Console) (p. 132). Be sure to enable cluster mode, Cluster Mode enabled (Scale Out), and specify at
least two shards and one replica node in each.
Creating a Redis (Cluster Mode Enabled) replication group from scratch (AWS CLI)
The following procedure creates a Redis (cluster mode enabled) replication group using the AWS CLI.
When you create a Redis (cluster mode enabled) replication group from scratch, you create the
replication group and all its nodes with a single call to the AWS CLI create-replication-group
command. Include the following parameters.
--replication-group-id
Redis (cluster mode enabled) replication group naming constraints are as follows:
• Must contain 1–40 alphanumeric characters or hyphens.
• Must begin with a letter.
• Can't contain two consecutive hyphens.
• Can't end with a hyphen.
--replication-group-description
ElastiCache supports the following node types. Generally speaking, the current generation types
provide more memory and computational power at lower cost when compared to their equivalent
previous generation counterparts.
For more information on performance details for each node type, see Amazon EC2 Instance Types.
• General purpose:
• Current generation:
M6g node types (available only for Redis engine version 5.0.6 onward).
T4g node types (available only for Redis engine version 6.0 onward).
R6gd node types (available only for Redis engine version 6.2 onward). For more information,
see Data tiering (p. 121).
(R6g node types are available only for Redis engine version 5.0.6 onward.)
Note
For region availability, see Supported node types by AWS Region (p. 101).
Set this parameter if you are using an r6gd node type. If you don't want data tiering, set --no-
data-tiering-enabled. For more information, see Data tiering (p. 121).
--cache-parameter-group
redis
--engine-version
3.2.4
--num-node-groups
The number of node groups in this replication group. Valid values are 1 to 500.
Note
The node/shard limit can be increased to a maximum of 500 per cluster. To request a limit
increase, see AWS Service Limits and select limit type "Nodes per cluster per instance type”.
--replicas-per-node-group
The number of replica nodes in each node group. Valid values are 0 to 5.
If you want to enable in-transit or at-rest encryption on this replication group, add either or both of the
--transit-encryption-enabled or --at-rest-encryption-enabled parameters and meet the
following conditions.
The following operation creates the Redis (cluster mode enabled) replication group sample-repl-
group with three node groups/shards (--num-node-groups), each with three nodes, a primary and two
read replicas (--replicas-per-node-group).
For Windows:
{
"ReplicationGroup": {
"Status": "creating",
"Description": "Demo cluster with replicas",
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 0,
"AutomaticFailover": "enabled",
"SnapshotWindow": "05:30-06:30",
"MemberClusters": [
"sample-repl-group-0001-001",
"sample-repl-group-0001-002",
"sample-repl-group-0001-003",
"sample-repl-group-0002-001",
"sample-repl-group-0002-002",
"sample-repl-group-0002-003",
"sample-repl-group-0003-001",
"sample-repl-group-0003-002",
"sample-repl-group-0003-003"
],
"PendingModifiedValues": {}
}
}
When you create a Redis (cluster mode enabled) replication group from scratch, you are able to configure
each shard in the cluster using the --node-group-configuration parameter as shown in the
following example which configures two node groups (Console: shards). The first shard has two nodes, a
primary and one read replica. The second shard has three nodes, a primary and two read replicas.
--node-group-configuration
The configuration for each node group. The --node-group-configuration parameter consists of
the following fields.
• PrimaryAvailabilityZone – The Availability Zone where the primary node of this node group
is located. If this parameter is omitted, ElastiCache chooses the Availability Zone for the primary
node.
Example: us-west-2a.
• ReplicaAvailabilityZones – A comma separated list of Availability Zones where the
read replicas are located. The number of Availability Zones in this list must match the value of
ReplicaCount. If this parameter is omitted, ElastiCache chooses the Availability Zones for the
replica nodes.
Example: "us-west-2a,us-west-2b,us-west-2c"
• ReplicaCount – The number of replica nodes in this node group.
• Slots – A string that specifies the keyspace for the node group. The string is in the format
startKey-endKey. If this parameter is omitted, ElastiCache allocates keys equally among the
node groups.
Example: "0-4999"
The following operation creates the Redis (cluster mode enabled) replication group new-group with
two node groups/shards (--num-node-groups). Unlike the preceding example, each node group is
configured differently from the other node group (--node-group-configuration).
For Windows:
{
"ReplicationGroup": {
"Status": "creating",
"Description": "Sharded replication group",
"ReplicationGroupId": "rc-rg",
"SnapshotRetentionLimit": 8,
"AutomaticFailover": "enabled",
"SnapshotWindow": "10:00-11:00",
"MemberClusters": [
"rc-rg-0001-001",
"rc-rg-0001-002",
"rc-rg-0002-001",
"rc-rg-0002-002",
"rc-rg-0002-003"
],
"PendingModifiedValues": {}
}
}
For additional information and parameters you might want to use, see the AWS CLI topic create-
replication-group.
Creating a replication group in Redis (Cluster Mode Enabled) from scratch (ElastiCache API)
The following procedure creates a Redis (cluster mode enabled) replication group using the ElastiCache
API.
When you create a Redis (cluster mode enabled) replication group from scratch, you create the
replication group and all its nodes with a single call to the ElastiCache API CreateReplicationGroup
operation. Include the following parameters.
ReplicationGroupId
Redis (cluster mode enabled) replication group naming constraints are as follows:
• Must contain 1–40 alphanumeric characters or hyphens.
• Must begin with a letter.
• Can't contain two consecutive hyphens.
• Can't end with a hyphen.
ReplicationGroupDescription
The number of node groups you want created with this replication group. Valid values are 1 to 500.
ReplicasPerNodeGroup
The number of replica nodes in each node group. Valid values are 1 to 5.
NodeGroupConfiguration
The configuration for each node group. The NodeGroupConfiguration parameter consists of the
following fields.
• PrimaryAvailabilityZone – The Availability Zone where the primary node of this node group
is located. If this parameter is omitted, ElastiCache chooses the Availability Zone for the primary
node.
Example: us-west-2a.
• ReplicaAvailabilityZones – A list of Availability Zones where the read replicas are located.
The number of Availability Zones in this list must match the value of ReplicaCount. If this
parameter is omitted, ElastiCache chooses the Availability Zones for the replica nodes.
• ReplicaCount – The number of replica nodes in this node group.
• Slots – A string that specifies the keyspace for the node group. The string is in the format
startKey-endKey. If this parameter is omitted, ElastiCache allocates keys equally among the
node groups.
Example: "0-4999"
CacheNodeType
ElastiCache supports the following node types. Generally speaking, the current generation types
provide more memory and computational power at lower cost when compared to their equivalent
previous generation counterparts.
For more information on performance details for each node type, see Amazon EC2 Instance Types.
• General purpose:
• Current generation:
M6g node types (available only for Redis engine version 5.0.6 onward).
T4g node types (available only for Redis engine version 6.0 onward).
R6gd node types (available only for Redis engine version 6.2 onward). For more information,
see Data tiering (p. 121).
(R6g node types are available only for Redis engine version 5.0.6 onward.)
Set this parameter if you are using an r6gd node type. If you don't want data tiering, set --no-
data-tiering-enabled. For more information, see Data tiering (p. 121).
CacheParameterGroup
redis
EngineVersion
3.2.4
If you want to enable in-transit or at-rest encryption on this replication group, add either or both of the
TransitEncryptionEnabled=true or AtRestEncryptionEnabled=true parameters and meet the
following conditions.
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&CacheNodeType=cache.m4.large
&CacheParemeterGroup=default.redis3.2.cluster.on
&Engine=redis
&EngineVersion=3.2.4
&NumNodeGroups=3
&ReplicasPerNodeGroup=2
&ReplicationGroupDescription=test%20group
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For additional information and parameters you might want to use, see the ElastiCache API topic
CreateReplicationGroup.
Viewing Details for a Redis (Cluster Mode Disabled) Replication Group (Console)
To view the details of a Redis (cluster mode disabled) cluster with replicas using the ElastiCache console,
see the topic Viewing details of a Redis (Cluster Mode Disabled) cluster (Console) (p. 139).
Viewing details for a Redis (Cluster Mode Disabled) replication group (AWS CLI)
For an AWS CLI example that displays a Redis (cluster mode disabled) replication group's details, see
Viewing a replication group's details (AWS CLI) (p. 289).
Viewing details for a Redis (Cluster Mode Enabled) cluster (AWS CLI)
For an ElastiCache CLI example that displays a Redis (cluster mode enabled) replication group's details,
see Viewing a replication group's details (AWS CLI) (p. 289).
Viewing details for a Redis (Cluster Mode Enabled) Cluster (ElastiCache API)
For an ElastiCache API example that displays a Redis (cluster mode enabled) replication group's details,
see Viewing a replication group's details (ElastiCache API) (p. 291).
Optional Parameters
• --replication-group-id – Use this parameter to list the details of a specific replication group. If
the specified replication group has more than one node group, results are returned grouped by node
group.
• --max-items – Use this parameter to limit the number of replication groups listed. The value of --
max-items cannot be less than 20 or greater than 100.
Example
The following code lists the details for up to 100 replication groups.
Output from this operation should look something like this (JSON format).
{
"ReplicationGroups": [
{
"Status": "available",
"Description": "test",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "rg-name-001.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "rg-name-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "rg-name-002.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "rg-name-002"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "rg-name-003.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "rg-name-003"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "rg-name.1abc4d.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "rg-name",
"AutomaticFailover": "enabled",
"SnapshottingClusterId": "rg-name-002",
"MemberClusters": [
"rg-name-001",
"rg-name-002",
"rg-name-003"
],
"PendingModifiedValues": {}
},
{
... some output omitted for brevity
}
]
}
For more information, see the AWS CLI for ElastiCache topic describe-replication-groups.
Optional Parameters
• ReplicationGroupId – Use this parameter to list the details of a specific replication group. If the
specified replication group has more than one node group, results are returned grouped by node
group.
• MaxRecords – Use this parameter to limit the number of replication groups listed. The value of
MaxRecords cannot be less than 20 or greater than 100. The default is 100.
Example
The following code list the details for up to 100 replication groups.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&MaxRecords=25
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see the ElastiCache API reference topic DescribeReplicationGroups.
Redis (cluster mode disabled) clusters with replicas have three types of endpoints; the primary endpoint,
the reader endpoint and the node endpoints. The primary endpoint is a DNS name that always resolves
to the primary node in the cluster. The primary endpoint is immune to changes to your cluster, such as
promoting a read replica to the primary role. For write activity, we recommend that your applications
connect to the primary endpoint, not the primary node.
A reader endpoint will evenly split incoming connections to the endpoint between all read replicas in an
ElastiCache for Redis cluster. Additional factors such as when the application creates the connections or
how the application (re)-uses the connections will determine the traffic distribution. Reader endpoints
keep up with cluster changes in real-time as replicas are added or removed. You can place your
ElastiCache for Redis cluster’s multiple read replicas in different AWS Availability Zones (AZ) to ensure
high availability of reader endpoints.
Note
A reader endpoint is not a load balancer. It is a DNS record that will resolve to an IP address of
one of the replica nodes in a round robin fashion.
For read activity, applications can also connect to any node in the cluster. Unlike the primary endpoint,
node endpoints resolve to specific endpoints. If you make a change in your cluster, such as adding or
deleting a replica, you must update the node endpoints in your application.
Redis (cluster mode enabled) clusters with replicas, because they have multiple shards (API/CLI: node
groups), which mean they also have multiple primary nodes, have a different endpoint structure than
Redis (cluster mode disabled) clusters. Redis (cluster mode enabled) has a configuration endpoint which
"knows" all the primary and node endpoints in the cluster. Your application connects to the configuration
endpoint. Whenever your application writes to or reads from the cluster's configuration endpoint, Redis,
behind the scenes, determines which shard the key belongs to and which endpoint in that shard to use. It
is all quite transparent to your application.
You can find the endpoints for a cluster using the ElastiCache console, the AWS CLI, or the ElastiCache
API.
To find the endpoints for your replication group, see one of the following topics:
• Finding a Redis (Cluster Mode Disabled) Cluster's Endpoints (Console) (p. 176)
• Finding Endpoints for a Redis (Cluster Mode Enabled) Cluster (Console) (p. 178)
• Finding the Endpoints for Replication Groups (AWS CLI) (p. 181)
• Finding Endpoints for Replication Groups (ElastiCache API) (p. 183)
Other modifications to a Redis (cluster mode enabled) cluster require that you create a cluster
with the new cluster incorporating the changes.
• You can upgrade Redis (cluster mode disabled) and Redis (cluster mode enabled) clusters and
replication groups to newer engine versions. However, you can't downgrade to earlier engine
versions except by deleting the existing cluster or replication group and creating it again. For
more information, see Upgrading engine versions (p. 198).
You can modify a Redis (cluster mode disabled) cluster's settings using the ElastiCache console, the AWS
CLI, or the ElastiCache API. Currently, ElastiCache supports a limited number of modifications on a Redis
(cluster mode enabled) replication group. Other modifications require you create a backup of the current
replication group then using that backup to seed a new Redis (cluster mode enabled) replication group.
Topics
• Using the AWS Management Console (p. 294)
• Using the AWS CLI (p. 294)
• Using the ElastiCache API (p. 295)
For Windows:
For more information on the AWS CLI modify-replication-group command, see modify-replication-
group.
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&AutomaticFailoverEnabled=true
&Mutli-AZEnabled=true
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
A prompt asks you to confirm your decision. Enter y (yes) to start the operation immediately. After the
process starts, it is irreversible.
After you begin deleting this replication group, all of its nodes will be deleted as
well.
Are you sure you want to delete this replication group? [Ny]y
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteReplicationGroup
&ReplicationGroupId=my-repgroup
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
Note
If you set the RetainPrimaryCluster parameter to true, all of the read replicas will be
deleted, but the primary cluster will be retained.
To dynamically change the number of replicas in your Redis replication group, choose the operation from
the following table that fits your situation.
Topics
• Using the AWS Management Console (p. 298)
• Using the AWS CLI (p. 298)
• Using the ElastiCache API (p. 300)
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Redis, and then choose the name of the replication group that you
want to add replicas to.
3. Choose the box for each shard that you want to add replicas to.
4. Choose Add replicas.
5. Complete the Add Replicas to Shards page:
• For New number of replicas/shard, enter the number of replicas that you want all of your
selected shards to have. This value must be greater than or equal to Current Number of Replicas
per shard and less than or equal to five. We recommend at least two replicas as a working
minimum.
• For Availability Zones, choose either No preference to have ElastiCache chose an Availability
Zone for each new replica, or Specify Availability Zones to choose an Availability Zone for each
new replica.
If you choose Specify Availability Zones, for each new replica specify an Availability Zone using
the list.
6. Choose Add to add the replicas or Cancel to cancel the operation.
• --replication-group-id – Required. Identifies which replication group you want to increase the
number of replicas in.
• --apply-immediately or --no-apply-immediately – Required. Specifies whether to increase
the replica count immediately (--apply-immediately) or at the next maintenance window (--no-
apply-immediately). Currently, --no-apply-immediately is not supported.
• --new-replica-count – Optional. Specifies the number of replica nodes you want when finished,
up to a maximum of five. Use this parameter for Redis (cluster mode disabled) replication groups
where there is only one node group or Redis (cluster mode enabled) group, or where you want all node
groups to have the same number of replicas. If this value is not larger than the current number of
replicas in the node group, the call fails with an exception.
• --replica-configuration – Optional. Allows you to set the number of replicas and Availability
Zones for each node group independently. Use this parameter for Redis (cluster mode enabled) groups
where you want to configure each node group independently.
Important
You must include either the --new-replica-count or --replica-configuration
parameter, but not both, in your call.
Example
The following example increases the number of replicas in the replication group sample-repl-group
to three. When the example is finished, there are three replicas in each node group. This number applies
whether this is a Redis (cluster mode disabled) group with a single node group or a Redis (cluster mode
enabled) group with multiple node groups.
For Windows:
The following example increases the number of replicas in the replication group sample-repl-
group to the value specified for the two specified node groups. Given that there are multiple node
groups, this is a Redis (cluster mode enabled) replication group. When specifying the optional
PreferredAvailabilityZones, the number of Availability Zones listed must equal the value of
NewReplicaCount plus 1 more. This approach accounts for the primary node for the group identified
by NodeGroupId.
NodeGroupId=0001,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-
east-1c,us-east-1b \
NodeGroupId=0003,NewReplicaCount=3,PreferredAvailabilityZones=us-east-1a,us-
east-1b,us-east-1c,us-east-1c \
--apply-immediately
For Windows:
For more information about increasing the number of replicas using the CLI, see increase-replica-count in
the Amazon ElastiCache Command Line Reference.
• ReplicationGroupId – Required. Identifies which replication group you want to increase the
number of replicas in.
• ApplyImmediately – Required. Specifies whether to increase the replica count immediately
(ApplyImmediately=True) or at the next maintenance window (ApplyImmediately=False).
Currently, ApplyImmediately=False is not supported.
• NewReplicaCount – Optional. Specifies the number of replica nodes you want when finished, up to a
maximum of five. Use this parameter for Redis (cluster mode disabled) replication groups where there
is only one node group, or Redis (cluster mode enabled) groups where you want all node groups to
have the same number of replicas. If this value is not larger than the current number of replicas in the
node group, the call fails with an exception.
• ReplicaConfiguration – Optional. Allows you to set the number of replicas and Availability Zones
for each node group independently. Use this parameter for Redis (cluster mode enabled) groups where
you want to configure each node group independently.
Important
You must include either the NewReplicaCount or ReplicaConfiguration parameter, but
not both, in your call.
Example
The following example increases the number of replicas in the replication group sample-repl-group
to three. When the example is finished, there are three replicas in each node group. This number applies
whether this is a Redis (cluster mode disabled) group with a single node group or a Redis (cluster mode
enabled) group with multiple node groups.
https://elasticache.us-west-2.amazonaws.com/
?Action=IncreaseReplicaCount
&ApplyImmediately=True
&NewReplicaCount=3
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
The following example increases the number of replicas in the replication group sample-repl-
group to the value specified for the two specified node groups. Given that there are multiple node
groups, this is a Redis (cluster mode enabled) replication group. When specifying the optional
PreferredAvailabilityZones, the number of Availability Zones listed must equal the value of
NewReplicaCount plus 1 more. This approach accounts for the primary node, for the group identified
by NodeGroupId.
https://elasticache.us-west-2.amazonaws.com/
?Action=IncreaseReplicaCount
&ApplyImmediately=True
&ReplicaConfiguration.ConfigureShard.1.NodeGroupId=0001
&ReplicaConfiguration.ConfigureShard.1.NewReplicaCount=2
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-
east-1a
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-
east-1c
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.3=us-
east-1b
&ReplicaConfiguration.ConfigureShard.2.NodeGroupId=0003
&ReplicaConfiguration.ConfigureShard.2.NewReplicaCount=3
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-
east-1a
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-
east-1b
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.3=us-
east-1c
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.4=us-
east-1c
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information about increasing the number of replicas using the API, see IncreaseReplicaCount in
the Amazon ElastiCache API Reference.
• For Redis (cluster mode disabled), you can decrease the number of replicas to one if Multi-AZ is
enabled, and to zero if it isn't enabled.
• For Redis (cluster mode enabled), you can decrease the number of replicas to zero. However, you can't
fail over to a replica if your primary node fails.
You can use the AWS Management Console, the AWS CLI or the ElastiCache API to decrease the number
of replicas in a node group (shard) or replication group.
Topics
• Using the AWS Management Console (p. 302)
• Using the AWS CLI (p. 302)
• Using the ElastiCache API (p. 304)
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Redis, then choose the name of the replication group from which you
want to delete replicas.
3. Choose the box for each shard you want to remove a replica node from.
4. Choose Delete replicas.
5. Complete the Delete Replicas from Shards page:
a. For New number of replicas/shard, enter the number of replicas that you want the selected
shards to have. This number must be greater than or equal to 1. We recommend at least two
replicas per shard as a working minimum.
b. Choose Delete to delete the replicas or Cancel to cancel the operation.
Important
• If you don’t specify the replica nodes to be deleted, ElastiCache for Redis automatically
selects replica nodes for deletion. While doing so, ElastiCache for Redis attempts to retain the
Multi-AZ architecture for your replication group followed by retaining replicas with minimum
replication lag with the primary.
• You can't delete the primary or primary nodes in a replication group. If you specify a primary
node for deletion, the operation fails with an error event indicating that the primary node was
selected for deletion.
• --replication-group-id – Required. Identifies which replication group you want to decrease the
number of replicas in.
• --apply-immediately or --no-apply-immediately – Required. Specifies whether to decrease
the replica count immediately (--apply-immediately) or at the next maintenance window (--no-
apply-immediately). Currently, --no-apply-immediately is not supported.
• --new-replica-count – Optional. Specifies the number of replica nodes that you want. The value
of --new-replica-count must be a valid value less than the current number of replicas in the node
groups. For minimum permitted values, see Decreasing the number of replicas in a shard (p. 302). If
the value of --new-replica-count doesn't meet this requirement, the call fails.
• --replicas-to-remove – Optional. Contains a list of node IDs specifying the replica nodes to
remove.
• --replica-configuration – Optional. Allows you to set the number of replicas and Availability
Zones for each node group independently. Use this parameter for Redis (cluster mode enabled) groups
where you want to configure each node group independently.
Important
You must include one and only one of the --new-replica-count, --replicas-to-remove,
or --replica-configuration parameters.
Example
The following example uses --new-replica-count to decrease the number of replicas in the
replication group sample-repl-group to one. When the example is finished, there is one replica in
each node group. This number applies whether this is a Redis (cluster mode disabled) group with a single
node group or a Redis (cluster mode enabled) group with multiple node groups.
For Windows:
The following example decreases the number of replicas in the replication group sample-repl-group
by removing two specified replicas (0001 and 0003) from the node group.
For Windows:
The following example uses --replica-configuration to decrease the number of replicas in the
replication group sample-repl-group to the value specified for the two specified node groups. Given
that there are multiple node groups, this is a Redis (cluster mode enabled) replication group. When
specifying the optional PreferredAvailabilityZones, the number of Availability Zones listed must
equal the value of NewReplicaCount plus 1 more. This approach accounts for the primary node for the
group identified by NodeGroupId.
For Windows:
For more information about decreasing the number of replicas using the CLI, see decrease-replica-count
in the Amazon ElastiCache Command Line Reference.
• ReplicationGroupId – Required. Identifies which replication group you want to decrease the
number of replicas in.
• ApplyImmediately – Required. Specifies whether to decrease the replica count immediately
(ApplyImmediately=True) or at the next maintenance window (ApplyImmediately=False).
Currently, ApplyImmediately=False is not supported.
• NewReplicaCount – Optional. Specifies the number of replica nodes you want. The value of
NewReplicaCount must be a valid value less than the current number of replicas in the node groups.
For minimum permitted values, see Decreasing the number of replicas in a shard (p. 302). If the value
of --new-replica-count doesn't meet this requirement, the call fails.
• ReplicasToRemove – Optional. Contains a list of node IDs specifying the replica nodes to remove.
• ReplicaConfiguration – Optional. Contains a list of node groups that allows you to set the number
of replicas and Availability Zones for each node group independently. Use this parameter for Redis
(cluster mode enabled) groups where you want to configure each node group independently.
Important
You must include one and only one of the NewReplicaCount, ReplicasToRemove, or
ReplicaConfiguration parameters.
Example
The following example uses NewReplicaCount to decrease the number of replicas in the replication
group sample-repl-group to one. When the example is finished, there is one replica in each node
group. This number applies whether this is a Redis (cluster mode disabled) group with a single node
group or a Redis (cluster mode enabled) group with multiple node groups.
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ApplyImmediately=True
&NewReplicaCount=1
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
The following example decreases the number of replicas in the replication group sample-repl-group
by removing two specified replicas (0001 and 0003) from the node group.
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ApplyImmediately=True
&ReplicasToRemove.ReplicaToRemove.1=0001
&ReplicasToRemove.ReplicaToRemove.2=0003
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
The following example uses ReplicaConfiguration to decrease the number of replicas in the
replication group sample-repl-group to the value specified for the two specified node groups. Given
that there are multiple node groups, this is a Redis (cluster mode enabled) replication group. When
specifying the optional PreferredAvailabilityZones, the number of Availability Zones listed must
equal the value of NewReplicaCount plus 1 more. This approach accounts for the primary node for the
group identified by NodeGroupId.
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ApplyImmediately=True
&ReplicaConfiguration.ConfigureShard.1.NodeGroupId=0001
&ReplicaConfiguration.ConfigureShard.1.NewReplicaCount=1
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-
east-1a
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-
east-1c
&ReplicaConfiguration.ConfigureShard.2.NodeGroupId=0003
&ReplicaConfiguration.ConfigureShard.2.NewReplicaCount=2
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-
east-1a
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-
east-1b
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.4=us-
east-1c
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information about decreasing the number of replicas using the API, see DecreaseReplicaCount
in the Amazon ElastiCache API Reference.
As your read traffic increases, you might want to spread those reads across more nodes and reduce the
read pressure on any one node. In this topic, you can find how to add a read replica to a Redis (cluster
mode disabled) cluster.
A Redis (cluster mode disabled) replication group can have a maximum of five read replicas. If you
attempt to add a read replica to a replication group that already has five read replicas, the operation
fails.
For information about adding replicas to a Redis (cluster mode enabled) replication group, see the
following:
You can add a read replica to a Redis (cluster mode disabled) cluster using the ElastiCache Console, the
AWS CLI, or the ElastiCache API.
Related topics
The following example creates the cluster my-read replica and adds it to the replication group my-
replication-group. The node types, parameter groups, security groups, maintenance window, and
other settings for the read replica are the same as for the other nodes in my-replication-group.
For Windows:
For more information on adding a read replica using the CLI, see create-cache-cluster in the Amazon
ElastiCache Command Line Reference.
The following example creates the cluster myReadReplica and adds it to the replication group
myReplicationGroup. The node types, parameter groups, security groups, maintenance window, and
other settings for the read replica are the same as for the other nodes myReplicationGroup.
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheCluster
&CacheClusterId=myReadReplica
&ReplicationGroupId=myReplicationGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information on adding a read replica using the API, see CreateCacheCluster in the Amazon
ElastiCache API Reference.
As read traffic on your Redis replication group changes, you might want to add or remove read replicas.
Removing a node from a Redis (cluster mode disabled) replication group is the same as just deleting a
cluster, though there are restrictions:
• You cannot remove the primary from a replication group. If you want to delete the primary, do the
following:
1. Promote a read replica to primary. For more information on promoting a read replica to
primary, see Promoting a read replica to primary, for Redis (cluster mode disabled) replication
groups (p. 309).
2. Delete the old primary. For a restriction on this method, see the next point.
• If Multi-AZ is enabled on a replication group, you can't remove the last read replica from the
replication group. In this case, do the following:
1. Modify the replication group by disabling Multi-AZ. For more information, see Modifying a
replication group (p. 294).
2. Delete the read replica.
You can remove a read replica from a Redis (cluster mode disabled) replication group using the
ElastiCache console, the AWS CLI for ElastiCache, or the ElastiCache API.
For directions on deleting a cluster from a Redis replication group, see the following:
You can promote a Redis (cluster mode disabled) read replica to primary using the AWS Management
Console, the AWS CLI, or the ElastiCache API. You can't promote a read replica to primary while Multi-AZ
with Automatic Failover is enabled on the Redis (cluster mode disabled) replication group. To promote
a Redis (cluster mode disabled) replica to primary on a Multi-AZ enabled replication group, do the
following:
1. Modify the replication group to disable Multi-AZ (doing this doesn't require that all your clusters be
in the same Availability Zone). For more information, see Modifying a replication group (p. 294).
2. Promote the read replica to primary.
3. Modify the replication group to re-enable Multi-AZ.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. If the replica you want to promote is a member of a Redis (cluster mode disabled) replication group
where Multi-AZ is enabled, modify the replication group to disable Multi-AZ before you proceed. For
more information, see Modifying a replication group (p. 294).
3. Choose Redis, then from the list of clusters, choose the replication group that you want to modify.
This replication group must be running the "Redis" engine, not the "Clustered Redis" engine, and
must have two or more nodes.
4. From the list of nodes, choose the replica node you want to promote to primary, then for Actions,
choose Promote.
5. In the Promote Read Replica dialog box, do the following:
a. For Apply Immediately, choose Yes to promote the read replica immediately, or No to promote
it at the cluster's next maintenance window.
b. Choose Promote to promote the read replica or Cancel to cancel the operation.
6. If the cluster was Multi-AZ enabled before you began the promotion process, wait until the
replication group's status is available, then modify the cluster to re-enable Multi-AZ. For more
information, see Modifying a replication group (p. 294).
The following AWS CLI command modifies the replication group sample-repl-group, making the read
replica my-replica-1 the primary in the replication group.
For Windows:
For more information on modifying a replication group, see modify-replication-group in the Amazon
ElastiCache Command Line Reference.
The following ElastiCache API action modifies the replication group myReplGroup, making the read
replica myReplica-1 the primary in the replication group.
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ReplicationGroupId=myReplGroup
&PrimaryClusterId=myReplica-1
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
For more information on modifying a replication group, see ModifyReplicationGroup in the Amazon
ElastiCache API Reference.
Beginning with Redis version 2.8.22, the backup method is selected based upon available memory. If
there is sufficient available memory, a child process is spawned that writes all changes to the cache's
reserved memory while the cache is being backed up. Depending on the number of writes to the cache
during the backup process, this child process can consume all reserved memory, causing the backup to
fail.
If there is insufficient memory available, a forkless, cooperative background process is employed. The
forkless method can affect both latency and throughput. For more information, see How synchronization
and backup are implemented (p. 265).
For more information about the performance impact of the backup process, see Performance impact of
backups (p. 312).
Following, you can find an overview of working with backup and restore.
Important
Though it's rare, sometimes the backup process fails to create a backup, including final backups.
Insufficient reserved memory is often the cause of backup failures. Therefore, make sure that
you have sufficient reserved memory before attempting a backup. If you have insufficient
memory, you can either evict some keys or increase the value of reserved-memory-percent.
For more information, see the following:
• Ensuring that you have enough memory to create a Redis snapshot (p. 221)
• Managing Reserved Memory (p. 223)
If you plan to delete cluster and it's important to preserve the data, you can take an extra
precaution. To do this, create a manual backup first, verify that its status is available, and then
delete the cluster. Doing this makes sure that if the backup fails, you still have the cluster data
available. You can retry making a backup, following the best practices outlined preceding.
Topics
• Backup constraints (p. 311)
• Backup costs (p. 312)
• Performance impact of backups (p. 312)
• Backups when running Redis 2.8.22 and later (p. 312)
• Backups when running Redis versions before 2.8.22 (p. 312)
• Improving backup performance (p. 312)
• Scheduling automatic backups (p. 314)
• Making manual backups (p. 315)
• Creating a final backup (p. 321)
• Describing backups (p. 324)
• Copying a backup (p. 326)
• Exporting a backup (p. 328)
• Restoring from a backup with optional cluster resizing (p. 334)
• Seeding a new cluster with an externally created backup (p. 337)
Backup constraints
Consider the following constraints when planning or making backups:
• At this time, backup and restore are supported only for clusters running on Redis.
• For Redis (cluster mode disabled) clusters, backup and restore aren't supported on cache.t1.micro
nodes. All other cache node types are supported.
• For Redis (cluster mode enabled) clusters, backup and restore are supported for all node types.
• During any contiguous 24-hour period, you can create no more than 20 manual backups per node in
the cluster.
• Redis (cluster mode enabled) only supports taking backups on the cluster level (for the API or CLI, the
replication group level). Redis (cluster mode enabled) doesn't support taking backups at the shard
level (for the API or CLI, the node group level).
• During the backup process, you can't run any other API or CLI operations on the cluster.
• If using clusters with data tiering, you cannot export a backup to Amazon S3.
• You can restore a backup of a cluster using the r6gd node type only to clusters using the r6gd node
type.
Backup costs
Using ElastiCache, you can store one backup for each active Redis cluster free of charge. Storage space
for additional backups is charged at a rate of $0.085/GB per month for all AWS Regions. There are no
data transfer fees for creating a backup, or for restoring data from a backup to a Redis cluster.
If the write load is high during a forkless backup, writes to the cache are delayed. This delay makes sure
that you don't accumulate too many changes and thus prevent a successful backup.
While the backup is being written, additional cache node memory is used for new writes. If this
additional memory usage exceeds the node's available memory, processing can become slow due to
excessive paging, or fail.
• Create backups from a read replica – If you are running Redis in a node group with more than one
node, you can take a backup from the primary node or one of the read replicas. Because of the system
resources required during BGSAVE, we recommend that you create backups from one of the read
replicas. While the backup is being created from the replica, the primary node remains unaffected
by BGSAVE resource requirements. The primary node can continue serving requests without slowing
down.
To do this, see Creating a manual backup (Console) (p. 315) and in the Cluster Name field in the
Create Backup window, choose a replica instead of the default primary node.
If you delete a replication group and request a final backup, ElastiCache always takes the backup from
the primary node. This ensures that you capture the very latest Redis data, before the replication group
is deleted.
When you schedule automatic backups, you should plan the following settings:
• Backup window – A period during each day when ElastiCache begins creating a backup. The minimum
length for the backup window is 60 minutes. You can set the backup window for any time when it's
most convenient for you, or for a time of day that avoids doing backups during particularly high-
utilization periods.
• Backup retention limit – The number of days the backup is retained in Amazon S3. For example, if you
set the retention limit to 5, then a backup taken today is retained for 5 days. When the retention limit
expires, the backup is automatically deleted.
The maximum backup retention limit is 35 days. If the backup retention limit is set to 0, automatic
backups are disabled for the cluster.
You can enable or disable automatic backups on an existing Redis cluster or replication group by
modifying it using the ElastiCache console, the AWS CLI, or the ElastiCache API.
You can enable or disable automatic backups when creating a Redis cluster or replication group using
the ElastiCache console, the AWS CLI, or the ElastiCache API. You can enable automatic backups when
you create a Redis cluster by checking the Enable Automatic Backups box in the Advanced Redis
Settings section. For more information, see step 2 of Creating a Redis (cluster mode disabled) cluster
(Console) (p. 129). You can enable automatic backups when you create a Redis replication group if
you are not using an existing cluster as the primary cluster. For more information, see Creating a Redis
replication group from scratch (p. 272).
Manual backups are useful for testing and archiving. For example, suppose that you've developed a set of
baseline data for testing purposes. You can create a manual backup of the data and restore it whenever
you want. After you test an application that modifies the data, you can reset the data by creating a new
cluster and restoring from your baseline backup. When the cluster is ready, you can test your applications
against the baseline data again—and repeat this process as often as needed.
In addition to directly creating a manual backup, you can create a manual backup in one of the following
ways:
• Copying a backup (p. 326) It does not matter whether the source backup was created automatically
or manually.
• Creating a final backup (p. 321) Create a backup immediately before deleting a cluster or node.
You can create a manual backup of a node using the AWS Management Console, the AWS CLI, or the
ElastiCache API.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Redis.
The status of the cluster changes to snapshotting. When the status returns to available the backup is
complete.
• --cache-cluster-id
• If the cluster you're backing up has no replica nodes, --cache-cluster-id is the name of the
cluster you are backing up, for example mycluster.
• If the cluster you're backing up has one or more replica nodes, --cache-cluster-id is the name
of the node in the cluster that you want to use for the backup. For example, the name might be
mycluster-002.
Use this parameter only when backing up a Redis (cluster mode disabled) cluster.
• --replication-group-id – Name of the Redis (cluster mode enabled) cluster (CLI/API: a replication
group) to use as the source for the backup. Use this parameter when backing up a Redis (cluster mode
enabled) cluster.
• --snapshot-name – Name of the snapshot to be created.
Example 1: Backing up a Redis (Cluster Mode Disabled) cluster that has no replica nodes
The following AWS CLI operation creates the backup bkup-20150515 from the Redis (cluster mode
disabled) cluster myNonClusteredRedis that has no read replicas.
For Windows:
Example 2: Backing up a Redis (Cluster Mode Disabled) cluster with replica nodes
The following AWS CLI operation creates the backup bkup-20150515 from the Redis (cluster mode
disabled) cluster myNonClusteredRedis. This backup has one or more read replicas.
For Windows:
Example Output: Backing Up a Redis (Cluster Mode Disabled) Cluster with Replica Nodes
{
"Snapshot": {
"Engine": "redis",
"CacheParameterGroupName": "default.redis3.2",
"VpcId": "vpc-91280df6",
"CacheClusterId": "myNonClusteredRedis-001",
"SnapshotRetentionLimit": 0,
"NumCacheNodes": 1,
"SnapshotName": "bkup-20150515",
"CacheClusterCreateTime": "2017-01-12T18:59:48.048Z",
"AutoMinorVersionUpgrade": true,
"PreferredAvailabilityZone": "us-east-1c",
"SnapshotStatus": "creating",
"SnapshotSource": "manual",
"SnapshotWindow": "08:30-09:30",
"EngineVersion": "3.2.4",
"NodeSnapshots": [
{
"CacheSize": "",
"CacheNodeId": "0001",
"CacheNodeCreateTime": "2017-01-12T18:59:48.048Z"
}
],
"CacheSubnetGroupName": "default",
"Port": 6379,
"PreferredMaintenanceWindow": "wed:07:30-wed:08:30",
"CacheNodeType": "cache.m3.2xlarge",
"DataTiering": "disabled"
}
}
For Windows:
--snapshot-name bkup-20150515
{
"Snapshot": {
"Engine": "redis",
"CacheParameterGroupName": "default.redis3.2.cluster.on",
"VpcId": "vpc-91280df6",
"NodeSnapshots": [
{
"CacheSize": "",
"NodeGroupId": "0001"
},
{
"CacheSize": "",
"NodeGroupId": "0002"
}
],
"NumNodeGroups": 2,
"SnapshotName": "bkup-20150515",
"ReplicationGroupId": "myClusteredRedis",
"AutoMinorVersionUpgrade": true,
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotStatus": "creating",
"SnapshotSource": "manual",
"SnapshotWindow": "10:00-11:00",
"EngineVersion": "3.2.4",
"CacheSubnetGroupName": "default",
"ReplicationGroupDescription": "2 shards 2 nodes each",
"Port": 6379,
"PreferredMaintenanceWindow": "sat:03:30-sat:04:30",
"CacheNodeType": "cache.r3.large",
"DataTiering": "disabled"
}
}
Related topics
For more information, see create-snapshot in the AWS CLI Command Reference.
• CacheClusterId
• If the cluster you're backing up has no replica nodes, CacheClusterId is the name of the cluster you
are backing up, for example mycluster.
• If the cluster you're backing up has one or more replica nodes, CacheClusterId is the name of the
node in the cluster that you want to use for the backup, for example mycluster-002.
Only use this parameter when backing up a Redis (cluster mode disabled) cluster.
• ReplicationGroupId – Name of the Redis (cluster mode enabled) cluster (CLI/API: a replication
group) to use as the source for the backup. Use this parameter when backing up a Redis (cluster mode
enabled) cluster.
• SnapshotName – Name of the snapshot to be created.
Example 1: Backing up a Redis (Cluster Mode Disabled) cluster that has no replica nodes
The following ElastiCache API operation creates the backup bkup-20150515 from the Redis (cluster
mode disabled) cluster myNonClusteredRedis that has no read replicas.
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateSnapshot
&CacheClusterId=myNonClusteredRedis
&SnapshotName=bkup-20150515
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
Example 2: Backing up a Redis (Cluster Mode Disabled) cluster with replica nodes
The following ElastiCache API operation creates the backup bkup-20150515 from the Redis (cluster
mode disabled) cluster myNonClusteredRedis which has one or more read replicas.
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateSnapshot
&CacheClusterId=myNonClusteredRedis-001
&SnapshotName=bkup-20150515
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
The following ElastiCache API operation creates the backup bkup-20150515 from the Redis (cluster
mode enabled) cluster myClusteredRedis. Note the use of ReplicationGroupId instead of
CacheClusterId to identify the source.
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateSnapshot
&ReplicationGroupId=myClusteredRedis
&SnapshotName=bkup-20150515
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see CreateSnapshot in the Amazon ElastiCache API Reference.
Related topics
For more information, see CreateSnapshot in the Amazon ElastiCache API Reference.
To create a final backup when deleting a Redis cluster, on the delete dialog box (step 5), choose Yes and
give the backup a name.
Related topics
Topics
• When deleting a Redis cluster with no read replicas (p. 321)
• When deleting a Redis cluster with read replicas (p. 321)
The following code creates the final backup bkup-20150515-final when deleting the cluster
myRedisCluster.
For Windows:
For more information, see delete-cache-cluster in the AWS CLI Command Reference.
The following code takes the final backup bkup-20150515-final when deleting the replication group
myReplGroup.
For Windows:
For more information, see delete-replication-group in the AWS CLI Command Reference.
Topics
• When deleting a Redis cluster (p. 322)
• When deleting a Redis replication group (p. 322)
The following ElastiCache API operation creates the backup bkup-20150515-final when deleting the
cluster myRedisCluster.
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteCacheCluster
&CacheClusterId=myRedisCluster
&FinalSnapshotIdentifier=bkup-20150515-final
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see DeleteCacheCluster in the Amazon ElastiCache API Reference.
The following ElastiCache API operation creates the backup bkup-20150515-final when deleting the
replication group myReplGroup.
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteReplicationGroup
&FinalSnapshotIdentifier=bkup-20150515-final
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see DeleteReplicationGroup in the Amazon ElastiCache API Reference.
Describing backups
The following procedures show you how to display a list of your backups. If you desire, you can also view
the details of a particular backup.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Backups.
3. Use the Filter list to display manual, automatic, or all backups.
4. To see the details of a particular backup, choose the box to the left of the backup's name.
Examples
The following operation uses the parameter --max-records to list up to 20 backups associated with
your account. Omitting the parameter --max-records lists up to 50 backups.
The following operation uses the parameter --cache-cluster-id to list only the backups associated
with the cluster my-cluster.
The following operation uses the parameter --snapshot-name to display the details of the backup my-
backup.
For more information, see describe-snapshots in the AWS CLI Command Reference.
Examples
The following operation uses the parameter MaxRecords to list up to 20 backups associated with your
account. Omitting the parameter MaxRecords lists up to 50 backups.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeSnapshots
&MaxRecords=20
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
The following operation uses the parameter CacheClusterId to list all backups associated with the
cluster MyCluster.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeSnapshots
&CacheClusterId=MyCluster
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
The following operation uses the parameter SnapshotName to display the details for the backup
MyBackup.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeSnapshots
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&SnapshotName=MyBackup
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
Copying a backup
You can make a copy of any backup, whether it was created automatically or manually. You can also
export your backup so you can access it from outside ElastiCache. For guidance on exporting your
backup, see Exporting a backup (p. 328).
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. To see a list of your backups, from the left navigation pane choose Backups.
3. From the list of backups, choose the box to the left of the name of the backup you want to copy.
4. Choose Copy.
5. In the Create Copy of the Backup? dialog box, do the following:
a. In the New backup name box, type a name for your new backup.
b. Leave the optional Target S3 Bucket box blank. This field should only be used to export
your backup and requires special S3 permissions. For information on exporting a backup, see
Exporting a backup (p. 328).
c. Choose Copy.
Parameters
For Windows:
Parameters
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=CopySnapshot
&SourceSnapshotName=automatic.my-redis-primary-2014-03-27-03-15
&TargetSnapshotName=my-backup-copy
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
For more information, see CopySnapshot in the Amazon ElastiCache API Reference.
Exporting a backup
Amazon ElastiCache supports exporting your ElastiCache backup to an Amazon Simple Storage Service
(Amazon S3) bucket, which gives you access to it from outside ElastiCache. You can export a backup
using the ElastiCache console, the AWS CLI, or the ElastiCache API.
Exporting a backup can be helpful if you need to launch a cluster in another AWS Region. You can export
your data in one AWS Region, copy the .rdb file to the new AWS Region, and then use that .rdb file to
seed the new cluster instead of waiting for the new cluster to populate through use. For information
about seeding a new cluster, see Seeding a new cluster with an externally created backup (p. 337).
Another reason you might want to export your cluster's data is to use the .rdb file for offline processing.
Important
• The ElastiCache backup and the Amazon S3 bucket that you want to copy it to must be in the
same AWS Region.
Before you can export a backup to an Amazon S3 bucket, you must have an Amazon S3 bucket in the
same AWS Region as the backup. Grant ElastiCache access to the bucket. The first two steps show you
how to do this.
Warning
The following scenarios expose your data in ways that you might not want:
• When another person has access to the Amazon S3 bucket that you exported your backup
to.
To control access to your backups, only allow access to the Amazon S3 bucket to those whom
you want to access your data. For information about managing access to an Amazon S3
bucket, see Managing access in the Amazon S3 Developer Guide.
• When another person has permissions to use the CopySnapshot API operation.
Users or groups that have permissions to use the CopySnapshot API operation can
create their own Amazon S3 buckets and copy backups to them. To control access to your
backups, use an AWS Identity and Access Management (IAM) policy to control who has the
ability to use the CopySnapshot API. For more information about using IAM to control
the use of ElastiCache API operations, see Identity and access management in Amazon
ElastiCache (p. 538) in the ElastiCache User Guide.
Topics
• Step 1: Create an Amazon S3 bucket (p. 328)
• Step 2: Grant ElastiCache access to your Amazon S3 bucket (p. 329)
• Step 3: Export an ElastiCache backup (p. 330)
1. Sign in to the AWS Management Console and open the Amazon S3 console at https://
console.aws.amazon.com/s3/.
2. Choose Create Bucket.
3. In Create a Bucket - Select a Bucket Name and Region, do the following:
The name of your Amazon S3 bucket must be DNS-compliant. Otherwise, ElastiCache can't
access your backup file. The rules for DNS compliance are:
For more information about creating an Amazon S3 bucket, see Creating a bucket in the Amazon Simple
Storage Service User Guide.
To create the proper permissions on an Amazon S3 bucket, take the steps described following.
1. Sign in to the AWS Management Console and open the Amazon S3 console at https://
console.aws.amazon.com/s3/.
2. Choose the name of the Amazon S3 bucket that you want to copy the backup to. This should be the
S3 bucket that you created in Step 1: Create an Amazon S3 bucket (p. 328).
3. Choose the Permissions tab and under Permissions, choose Access control list (ACL) and then
choose Edit.
4. Add grantee Canonical Id
540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353 with the
following options:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListAllMyBuckets",
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject",
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::*"
}]
}
The following process uses the ElastiCache console to export a backup to an Amazon S3 bucket so that
you can access it from outside ElastiCache. The Amazon S3 bucket must be in the same AWS Region as
the ElastiCache backup.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. To see a list of your backups, from the left navigation pane choose Backups.
3. From the list of backups, choose the box to the left of the name of the backup you want to export.
4. Choose Copy.
5. In Create a Copy of the Backup?, do the following:
a. In New backup name box, type a name for your new backup.
The name must be between 1 and 1,000 characters and able to be UTF-8 encoded.
ElastiCache adds an instance identifier and .rdb to the value that you enter here. For example,
if you enter my-exported-backup, ElastiCache creates my-exported-backup-0001.rdb.
b. From the Target S3 Location list, choose the name of the Amazon S3 bucket that you
want to copy your backup to (the bucket that you created in Step 1: Create an Amazon S3
bucket (p. 328)).
The Target S3 Location must be an Amazon S3 bucket in the backup's AWS Region with the
following permissions for the export process to succeed.
For more information, see Step 2: Grant ElastiCache access to your Amazon S3 bucket (p. 329).
c. Choose Copy.
API Version 2015-02-02
330
Amazon ElastiCache for Redis User Guide
Exporting a backup
Note
If your S3 bucket does not have the permissions needed for ElastiCache to export a backup to
it, you receive one of the following error messages. Return to Step 2: Grant ElastiCache access
to your Amazon S3 bucket (p. 329) to add the permissions specified and retry exporting your
backup.
If you want to copy your backup to another AWS Region, use Amazon S3 to copy it. For more
information, see Copying an object in the Amazon Simple Storage Service User Guide.
Export the backup to an Amazon S3 bucket using the copy-snapshot CLI operation with the following
parameters:
Parameters
The name must be between 1 and 1,000 characters and able to be UTF-8 encoded.
ElastiCache adds an instance identifier and .rdb to the value you enter here. For example, if you enter
my-exported-backup, ElastiCache creates my-exported-backup-0001.rdb.
• --target-bucket – Name of the Amazon S3 bucket where you want to export the backup. A copy of
the backup is made in the specified bucket.
The --target-bucket must be an Amazon S3 bucket in the backup's AWS Region with the following
permissions for the export process to succeed.
• Object access – Read and Write.
• Permissions access – Read.
For more information, see Step 2: Grant ElastiCache access to your Amazon S3 bucket (p. 329).
For Windows:
--target-snapshot-name my-exported-backup ^
--target-bucket my-s3-bucket
Note
If your S3 bucket does not have the permissions needed for ElastiCache to export a backup to
it, you receive one of the following error messages. Return to Step 2: Grant ElastiCache access
to your Amazon S3 bucket (p. 329) to add the permissions specified and retry exporting your
backup.
For more information, see copy-snapshot in the AWS CLI Command Reference.
If you want to copy your backup to another AWS Region, use Amazon S3 copy. For more information, see
Copying an object in the Amazon Simple Storage Service User Guide.
Export the backup to an Amazon S3 bucket using the CopySnapshot API operation with these
parameters.
Parameters
The name must be between 1 and 1,000 characters and able to be UTF-8 encoded.
ElastiCache adds an instance identifier and .rdb to the value that you enter here. For example, if you
enter my-exported-backup, you get my-exported-backup-0001.rdb.
• TargetBucket – Name of the Amazon S3 bucket where you want to export the backup. A copy of the
backup is made in the specified bucket.
The TargetBucket must be an Amazon S3 bucket in the backup's AWS Region with the following
permissions for the export process to succeed.
• Object access – Read and Write.
• Permissions access – Read.
For more information, see Step 2: Grant ElastiCache access to your Amazon S3 bucket (p. 329).
The following example makes a copy of an automatic backup to the Amazon S3 bucket my-s3-bucket.
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=CopySnapshot
&SourceSnapshotName=automatic.my-redis-primary-2016-06-27-03-15
&TargetBucket=my-s3-bucket
&TargetSnapshotName=my-backup-copy
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2016-01-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
Note
If your S3 bucket does not have the permissions needed for ElastiCache to export a backup to
it, you receive one of the following error messages. Return to Step 2: Grant ElastiCache access
to your Amazon S3 bucket (p. 329) to add the permissions specified and retry exporting your
backup.
For more information, see CopySnapshot in the Amazon ElastiCache API Reference.
If you want to copy your backup to another AWS Region, use Amazon S3 copy to copy the exported
backup to the Amazon S3 bucket in another AWS Region. For more information, see Copying an object in
the Amazon Simple Storage Service User Guide.
The Amazon ElastiCache for Redis restore process supports the following:
• Upgrading from a Redis (cluster mode disabled) cluster to a Redis (cluster mode enabled) cluster
running Redis version 3.2.4.
• Migrating from one or more .rdb backup files you created from your self-managed Redis clusters to a
single ElastiCache for Redis (cluster mode enabled) cluster.
Important
• You cannot restore from a backup created using a Redis (cluster mode enabled) cluster to a
Redis (cluster mode disabled) cluster.
• Redis (cluster mode enabled) clusters do not support multiple databases. Therefore, when
restoring to a Redis (cluster mode enabled) your restore fails if the .rdb file references more
than one database.
• You cannot restore a backup from a cluster that uses data tiering (for example, r6gd node
type) into a cluster that does not use data tiering (for example, r6g node type).
Whether you make any changes when restoring a cluster from a backup is governed by choices that you
make. You make these choices in the Restore Cluster dialog box when using the ElastiCache console to
restore. You make these choices by setting parameter values when using the AWS CLI or ElastiCache API
to restore.
During the restore operation, ElastiCache creates the new cluster, and then populates it with data from
the backup file. When this process is complete, the Redis cluster is warmed up and ready to accept
requests.
Important
Before you proceed, be sure you have created a backup of the cluster you want to restore from.
For more information, see Making manual backups (p. 315).
If you want to restore from an externally created backup, see Seeding a new cluster with an
externally created backup (p. 337).
The following procedures show you how to restore a backup to a new cluster using the ElastiCache
console, the AWS CLI, or the ElastiCache API.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Backups.
3. In the list of backups, choose the box to the left of the backup name you want to restore from.
4. Choose Restore.
5. Complete the Restore Cluster dialog box. Be sure to complete all the "Required" fields and any of
the others you want to change from the defaults.
• Creating a cluster (AWS CLI) (p. 137) in the ElastiCache User Guide.
• create-cache-cluster in the AWS CLI Command Reference.
• Creating a Redis replication group from scratch (p. 272) in the ElastiCache User Guide.
• create-replication-group in the AWS CLI Command Reference.
• Creating a cluster (ElastiCache API) (p. 137) in the ElastiCache User Guide.
• CreateCacheCluster in the ElastiCache API Reference.
• Creating a Redis replication group from scratch (p. 272) in the ElastiCache User Guide.
• CreateReplicationGroup in the ElastiCache API Reference.
To seed a new Redis cluster from a Redis backup created within Amazon ElastiCache, see Restoring from
a backup with optional cluster resizing (p. 334).
When you use a Redis .rdb file to seed a new Redis cluster, you can do the following:
• Upgrade from a nonpartitioned cluster to a Redis (cluster mode enabled) cluster running Redis version
3.2.4.
• Specify a number of shards (called node groups in the API and CLI) in the new cluster. This number can
be different from the number of shards in the cluster that was used to create the backup file.
• Specify a different node type for the new cluster—larger or smaller than that used in the cluster that
made the backup. If you scale to a smaller node type, be sure that the new node type has sufficient
memory for your data and Redis overhead. For more information, see Ensuring that you have enough
memory to create a Redis snapshot (p. 221).
• Distribute your keys in the slots of the new Redis (cluster mode enabled) cluster differently than in the
cluster that was used to create the backup file.
Note
You can't seed a Redis (cluster mode disabled) cluster from an .rdb file created from a Redis
(cluster mode enabled) cluster.
Important
• You must ensure that your Redis backup data doesn't exceed the resources of the node. For
example, you can't upload an .rdb file with 5 GB of Redis data to a cache.m3.medium node
that has 2.9 GB of memory.
If the backup is too large, the resulting cluster has a status of restore-failed. If this
happens, you must delete the cluster and start over.
For a complete listing of node types and specifications, see Redis node-type specific
parameters (p. 465) and Amazon ElastiCache product features and details.
• You can encrypt a Redis .rdb file with Amazon S3 server-side encryption (SSE-S3) only. For
more information, see Protecting data using server-side encryption.
Following, you can find topics that walk you through migrating your Redis cluster from outside
ElastiCache for Redis to ElastiCache for Redis.
BGSAVE is asynchronous and does not block other clients while processing. For more information,
see BGSAVE at the Redis website.
SAVE is synchronous and blocks other processes until finished. For more information, see SAVE at
the Redis website.
For additional information on creating a backup, see Redis persistence at the Redis website.
1. Sign in to the AWS Management Console and open the Amazon S3 console at https://
console.aws.amazon.com/s3/.
2. Follow the instructions for creating an Amazon S3 bucket in Creating a bucket in the Amazon Simple
Storage Service User Guide.
The name of your Amazon S3 bucket must be DNS-compliant. Otherwise, ElastiCache can't access
your backup file. The rules for DNS compliance are:
You must create your Amazon S3 bucket in the same AWS Region as your new ElastiCache for Redis
cluster. This approach makes sure that the highest data transfer speed when ElastiCache reads
your .rdb file from Amazon S3.
Note
To keep your data as secure as possible, make the permissions on your Amazon S3 bucket as
restrictive as you can. At the same time, the permissions still need to allow the bucket and
its contents to be used to seed your new Redis cluster.
1. Sign in to the AWS Management Console and open the Amazon S3 console at https://
console.aws.amazon.com/s3/.
2. Choose the name of the bucket to upload your .rdb file to.
Make note of both the bucket name and the folder name.
1. Sign in to the AWS Management Console and open the Amazon S3 console at https://
console.aws.amazon.com/s3/.
2. Choose the name of the Amazon S3 bucket you created in Step 2.
3. Choose the name of the folder you created in Step 2.
4. Choose Upload.
5. Choose Add files.
6. Browse to find the file or files you want to upload, then choose the file or files. To choose multiple
files, hold down the Ctrl key while choosing each file name.
7. Choose Open.
8. Confirm the correct file or files are listed in the Upload dialog box, and then choose Upload.
Note the path to your .rdb file. For example, if your bucket name is myBucket and the path is
myFolder/redis.rdb, enter myBucket/myFolder/redis.rdb. You need this path to seed the new
cluster with the data in this backup.
For additional information, see Bucket restrictions and limitations in the Amazon Simple Storage Service
User Guide.
AWS Regions introduced before March 20, 2019, are enabled by default. You can begin working in these
AWS Regions immediately. Regions introduced after March 20, 2019, such as Asia Pacific (Hong Kong)
and Middle East (Bahrain), are disabled by default. You must enable, or opt in, to these Regions before
you can use them, as described in Managing AWS regions in AWS General Reference.
• For a default Region, use the procedure in Grant ElastiCache read access to the .rdb file in a default
Region (p. 339).
• For an opt-in Region, use the procedure in Grant ElastiCache read access to the .rdb file in an opt-in
Region (p. 340).
and Middle East (Bahrain), are disabled by default. You must enable, or opt in, to these Regions before
you can use them, as described in Managing AWS regions in AWS General Reference.
To grant ElastiCache read access to the backup file in an AWS Region enabled by default
1. Sign in to the AWS Management Console and open the Amazon S3 console at https://
console.aws.amazon.com/s3/.
2. Choose the name of the S3 bucket that contains your .rdb file.
3. Choose the name of the folder that contains your .rdb file.
4. Choose the name of your .rdb backup file. The name of the selected file appears above the tabs at
the top of the page.
5. Choose Permissions.
6. If aws-scs-s3-readonly or one of the canonical IDs in the following list is not listed as a user, do the
following:
40fa568277ad703bd160f66ae4f83fc9dfdfd06c2f1b5060ca22442ac3ef8be6
Important
The backup must be located in an S3 bucket in AWS GovCloud (US) for you to
download it to a Redis cluster in AWS GovCloud (US).
• AWS Regions enabled by default:
540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353
c. Set the permissions on the bucket by choosing Yes for the following:
• List/write object
• Read/write object ACL permissions
d. Choose Save.
7. Choose Overview, and then choose Download.
1. Sign in to the AWS Management Console and open the Amazon S3 console at https://
console.aws.amazon.com/s3/.
2. Choose the name of the S3 bucket that contains your .rdb file.
3. Choose the name of the folder that contains your .rdb file.
4. Choose the name of your .rdb backup file. The name of the selected file appears above the tabs at
the top of the page.
The following is an example of what the updated policy might look like.
{
"Version": "2012-10-17",
"Id": "Policy15397346",
"Statement": [
{
"Sid": "Stmt15399483",
"Effect": "Allow",
"Principal": {
"Service": "ap-east-1.elasticache-snapshot.amazonaws.com"
},
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketAcl"
],
"Resource": [
"arn:aws:s3:::example-bucket",
"arn:aws:s3:::example-bucket/backup1.rdb",
"arn:aws:s3:::example-bucket/backup2.rdb"
]
}
]
}
Step 5: Seed the ElastiCache cluster with the .rdb file data
Now you are ready to create an ElastiCache cluster and seed it with the data from the .rdb file. To create
the cluster, follow the directions at Creating a cluster (p. 129) or Creating a Redis replication group from
scratch (p. 272). Be sure to choose Redis as your cluster engine.
The method you use to tell ElastiCache where to find the Redis backup you uploaded to Amazon S3
depends on the method you use to create the cluster:
Seed the ElastiCache for Redis cluster or replication group with the .rdb file data
After you choose the Redis engine, expand the Advanced Redis settings section and locate Import
data to cluster. In the Seed RDB file S3 location box, type in the Amazon S3 path for the files(s). If
you have multiple .rdb files, type in the path for each file in a comma separated list. The Amazon S3
path looks something like myBucket/myFolder/myBackupFilename.rdb.
• Using the AWS CLI
Important
When seeding a Redis (cluster mode enabled) cluster, you must configure each node
group (shard) in the new cluster or replication group. Use the parameter --node-group-
configuration (API: NodeGroupConfiguration) to do this. For more information, see the
following:
During the process of creating your cluster, the data in your Redis backup is written to the cluster.
You can monitor the progress by viewing the ElastiCache event messages. To do this, see the
ElastiCache console and choose Cache Events. You can also use the AWS ElastiCache command line
interface or ElastiCache API to obtain event messages. For more information, see Viewing ElastiCache
events (p. 610).
Tagging backups
You can assign your own metadata to each backup in the form of tags. Tags enable you to categorize
your backups in different ways, for example, by purpose, owner, or environment. This is useful when you
have many resources of the same type—you can quickly identify a specific resource based on the tags
that you've assigned to it. For more information, see Resources you can tag (p. 204).
Cost allocation tags are a means of tracking your costs across multiple AWS services by grouping your
expenses on invoices by tag values. To learn more about cost allocation tags, see Use cost allocation tags.
Using the ElastiCache console, the AWS CLI, or ElastiCache API you can add, list, modify, remove, or copy
cost allocation tags on your backups. For more information, see Monitoring costs with cost allocation
tags (p. 210).
Deleting a backup
An automatic backup is automatically deleted when its retention limit expires. If you delete a cluster, all
of its automatic backups are also deleted. If you delete a replication group, all of the automatic backups
from the clusters in that group are also deleted.
ElastiCache provides a deletion API operation that lets you delete a backup at any time, regardless
of whether the backup was created automatically or manually. Because manual backups don't have a
retention limit, manual deletion is the only way to remove them.
You can delete a backup using the ElastiCache console, the AWS CLI, or the ElastiCache API.
To delete a backup
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Backups.
For more information, see delete-snapshot in the AWS CLI Command Reference.
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteSnapshot
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SnapshotId=myBackup
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=<credential>
For more information, see DeleteSnapshot in the Amazon ElastiCache API Reference.
If you require data durability, you can enable the Redis append-only file feature (AOF). When this feature
is enabled, the node writes all of the commands that change cache data to an append-only file. When
a node is rebooted and the cache engine starts, the AOF is "replayed." The result is a warm Redis cache
with all of the data intact.
AOF is disabled by default. To enable AOF for a cluster running Redis, you must create a parameter group
with the appendonly parameter set to yes. You then assign that parameter group to your cluster. You
can also modify the appendfsync parameter to control how often Redis writes to the AOF file.
Important
Append-only files (AOF) aren't supported for cache.t1.micro and cache.t2.* nodes. For nodes of
these types, the appendonly parameter value is ignored.
For Multi-AZ replication groups, AOF isn't enabled.
AOF isn't supported on Redis versions 2.8.22 and later.
Warning
AOF can't protect against all failure scenarios. For example, if a node fails due to a hardware
fault in an underlying physical server, ElastiCache provisions a new node on a different server.
In this case, the AOF file is no longer available and can't be used to recover the data. Thus, Redis
restarts with a cold cache.
For greater reliability and faster recovery, we recommend that you create one or more read
replicas in different Availability Zones for your cluster. Enable Multi-AZ on your replication group
instead of using AOF. AOF isn't enabled for Multi-AZ replication groups.
For more information on mitigating failures, see Mitigating Failures when Running
Redis (p. 622).
The following helps you find the correct topic for the scaling actions that you want to perform.
Changing the number of node Not supported for Redis (cluster Scaling clusters in Redis (Cluster
groups mode disabled) clusters Mode Enabled) (p. 375)
Topics
• Scaling clusters for Redis (Cluster Mode Disabled) (p. 347)
• Scaling clusters in Redis (Cluster Mode Enabled) (p. 375)
Contents
• Scaling single-node clusters for Redis (Cluster Mode Disabled) (p. 347)
• Scaling up single-node clusters for Redis (Cluster Mode Disabled) (p. 349)
• Scaling up single-node clusters for Redis (Cluster Mode Disabled)
(Console) (p. 350)
• Scaling up single-node Redis cache clusters (AWS CLI) (p. 350)
• Scaling up single-node Redis cache clusters (ElastiCache API) (p. 352)
• Scaling down single-node Redis clusters (p. 355)
• Scaling down a single-node Redis cluster (Console) (p. 355)
• Scaling down single-node Redis cache clusters (AWS CLI) (p. 356)
• Scaling down single-node Redis cache clusters (ElastiCache API) (p. 358)
• Scaling Redis (Cluster Mode Disabled) clusters with replica nodes (p. 360)
• Scaling up Redis clusters with replicas (p. 361)
• Scaling down Redis clusters with replicas (p. 367)
• Increasing read capacity (p. 373)
• Decreasing read capacity (p. 374)
The ElastiCache for Redis scaling up process is designed to make a best effort to retain your existing data
and requires successful Redis replication. For Redis (cluster mode disabled) Redis clusters, we recommend
that sufficient memory be made available to Redis.
You cannot partition your data across multiple Redis (cluster mode disabled) clusters. However, if you
only need to increase or decrease your cluster's read capacity, you can create a Redis (cluster mode
disabled) cluster with replica nodes and add or remove read replicas. To create a Redis (cluster mode
disabled) cluster with replica nodes using your single-node Redis cache cluster as the primary cluster, see
Creating a Redis (cluster mode disabled) cluster (Console) (p. 47).
After you create the cluster with replicas, you can increase read capacity by adding read replicas. Later,
if you need to, you can reduce read capacity by removing read replicas. For more information, see
Increasing read capacity (p. 373) or Decreasing read capacity (p. 374).
In addition to being able to scale read capacity, Redis (cluster mode disabled) clusters with replicas
provide other business advantages. For more information, see High availability using replication
groups (p. 246).
Important
If your parameter group uses reserved-memory to set aside memory for Redis overhead,
before you begin scaling be sure that you have a custom parameter group that reserves the
correct amount of memory for your new node type. Alternatively, you can modify a custom
parameter group so that it uses reserved-memory-percent and use that parameter group for
your new cluster.
Topics
• Scaling up single-node clusters for Redis (Cluster Mode Disabled) (p. 349)
• Scaling down single-node Redis clusters (p. 355)
1. A new cache cluster with the new node type is spun up in the same Availability Zone as the existing
cache cluster.
2. The cache data in the existing cache cluster is copied to the new cache cluster. How long this process
takes depends upon your node type and how much data is in the cache cluster.
3. Reads and writes are now served using the new cache cluster. Because the new cache cluster's
endpoints are the same as they were for the old cache cluster, you do not need to update the
endpoints in your application. You will notice a brief interruption (a few seconds) of reads and writes
from the primary node while the DNS entry is updated.
4. ElastiCache deletes the old cache cluster. You will notice a brief interruption (a few seconds) of reads
and writes from the old node because the connections to the old node will be disconnected.
Note
For clusters running the r6gd node type, you can only scale to node sizes within the r6gd node
family.
As shown in the following table, your Redis scale-up operation is blocked if you have an engine upgrade
scheduled for the next maintenance window. For more information on Maintenance Windows, see
Managing maintenance (p. 230).
If you have a pending operation that is blocking you, you can do one of the following.
• Schedule your Redis scale-up operation for the next maintenance window by clearing the Apply
immediately check box (CLI use: --no-apply-immediately, API use: ApplyImmediately=false).
• Wait until your next maintenance window (or after) to perform your Redis scale up operation.
• Add the Redis engine upgrade to this cache cluster modification with the Apply Immediately check
box chosen (CLI use: --apply-immediately, API use: ApplyImmediately=true). This unblocks
your scale up operation by causing the engine upgrade to be performed immediately.
You can scale up a single-node Redis (cluster mode disabled) cluster using the ElastiCache console, the
AWS CLI, or ElastiCache API.
Important
If your parameter group uses reserved-memory to set aside memory for Redis overhead,
before you begin scaling be sure that you have a custom parameter group that reserves the
correct amount of memory for your new node type. Alternatively, you can modify a custom
parameter group so that it uses reserved-memory-percent and use that parameter group for
your new cluster.
The following procedure describes how to scale up a single-node Redis cluster using the ElastiCache
Management Console. During this process, your Redis cluster will continue to serve requests with
minimal downtime.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Redis.
3. From the list of clusters, choose the cluster you want to scale up (it must be running the Redis
engine, not the Clustered Redis engine).
4. Choose Modify.
5. In the Modify Cluster wizard:
a. Choose the node type you want to scale to from the Node type list.
b. If you're using reserved-memory to manage your memory, from the Parameter Group list,
choose the custom parameter group that reserves the correct amount of memory for your new
node type.
6. If you want to perform the scale up process right away, choose the Apply immediately box. If the
Apply immediately box is not chosen, the scale-up process is performed during this cluster's next
maintenance window.
7. Choose Modify.
If you chose Apply immediately in the previous step, the cluster's status changes to modifying.
When the status changes to available, the modification is complete and you can begin using the new
cluster.
The following procedure describes how to scale up a single-node Redis cache cluster using the AWS CLI.
During this process, your Redis cluster will continue to serve requests with minimal downtime.
1. Determine the node types you can scale up to by running the AWS CLI list-allowed-node-
type-modifications command with the following parameter.
• --cache-cluster-id
For Windows:
Output from the above command looks something like this (JSON format).
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium ",
"cache.t1.small ",
],
• --cache-cluster-id – The name of the cache cluster you are scaling up.
• --cache-node-type – The new node type you want to scale the cache cluster. This value
must be one of the node types returned by the list-allowed-node-type-modifications
command in step 1.
• --cache-parameter-group-name – [Optional] Use this parameter if you are using reserved-
memory to manage your cluster's reserved memory. Specify a custom cache parameter group
that reserves the correct amount of memory for your new node type. If you are using reserved-
memory-percent you can omit this parameter.
• --apply-immediately – Causes the scale-up process to be applied immediately. To postpone
the scale-up process to the cluster's next maintenance window, use the --no-apply-
immediately parameter.
For Windows:
--apply-immediately
Output from the above command looks something like this (JSON format).
{
"CacheCluster": {
"Engine": "redis",
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"CacheParameterGroupName": "default.redis3.2",
"ParameterApplyStatus": "in-sync"
},
"SnapshotRetentionLimit": 1,
"CacheClusterId": "my-redis-cache-cluster",
"CacheSecurityGroups": [],
"NumCacheNodes": 1,
"SnapshotWindow": "00:00-01:00",
"CacheClusterCreateTime": "2017-02-21T22:34:09.645Z",
"AutoMinorVersionUpgrade": true,
"CacheClusterStatus": "modifying",
"PreferredAvailabilityZone": "us-west-2a",
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"CacheSubnetGroupName": "default",
"EngineVersion": "3.2.4",
"PendingModifiedValues": {
"CacheNodeType": "cache.m3.2xlarge"
},
"PreferredMaintenanceWindow": "tue:11:30-tue:12:30",
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled"
}
}
• --cache-cache cluster-id – The name of your single-node Redis cache cluster. Use this
parameter to describe a particular cache cluster rather than all cache clusters.
The following procedure describes how to scale up a single-node Redis cache cluster using the
ElastiCache API. During this process, your Redis cluster will continue to serve requests with minimal
downtime.
1. Determine the node types you can scale up to by running the ElastiCache API
ListAllowedNodeTypeModifications action with the following parameter.
• CacheClusterId – The name of the single-node Redis cache cluster you want to scale up.
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
• CacheClusterId – The name of the cache cluster you are scaling up.
• CacheNodeType – The new, larger node type you want to scale the cache cluster up to. This value
must be one of the node types returned by the ListAllowedNodeTypeModifications action
in step 1.
• CacheParameterGroupName – [Optional] Use this parameter if you are using reserved-
memory to manage your cluster's reserved memory. Specify a custom cache parameter group
that reserves the correct amount of memory for your new node type. If you are using reserved-
memory-percent you can omit this parameter.
• ApplyImmediately – Set to true to cause the scale-up process to be performed
immediately. To postpone the scale-up process to the cluster's next maintenance window, use
ApplyImmediately=false.
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheCluster
&ApplyImmediately=true
&CacheClusterId=MyRedisCacheCluster
&CacheNodeType=cache.m3.xlarge
&CacheParameterGroupName redis32-m2-xl
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see ModifyCacheCluster in the Amazon ElastiCache API Reference.
3. If you used ApplyImmediately=true, check the status of the new cache cluster using the
ElastiCache API DescribeCacheClusters action with the following parameter. When the status
changes to available, you can begin using the new, larger cache cluster.
• CacheClusterId – The name of your single-node Redis cache cluster. Use this parameter to
describe a particular cache cluster rather than all cache clusters.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see DescribeCacheClusters in the Amazon ElastiCache API Reference.
Topics
• Scaling down a single-node Redis cluster (Console) (p. 355)
• Scaling down single-node Redis cache clusters (AWS CLI) (p. 356)
• Scaling down single-node Redis cache clusters (ElastiCache API) (p. 358)
The following procedure walks you through scaling your single-node Redis cluster down to a smaller
node type using the ElastiCache console.
Important
If your parameter group uses reserved-memory to set aside memory for Redis overhead,
before you begin scaling be sure that you have a custom parameter group that reserves the
correct amount of memory for your new node type. Alternatively, you can modify a custom
parameter group so that it uses reserved-memory-percent and use that parameter group for
your new cluster.
If you're using reserved-memory-percent, doing this is not necessary.
For more information, see Managing Reserved Memory (p. 223).
1. Ensure that the smaller node type is adequate for your data and overhead needs.
2. If your parameter group uses reserved-memory to set aside memory for Redis overhead, ensure
that you have a custom parameter group to set aside the correct amount of memory for your new
node type.
Alternatively, you can modify your custom parameter group to use reserved-memory-percent.
For more information, see Managing Reserved Memory (p. 223).
3. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
4. From the list of clusters, choose the cluster you want to scale down. This cluster must be running the
Redis engine and not the Clustered Redis engine.
5. Choose Modify.
6. In the Modify Cluster wizard:
a. Choose the node type you want to scale down to from the Node type list.
b. If you're using reserved-memory to manage your memory, from the Parameter Group list,
choose the custom parameter group that reserves the correct amount of memory for your new
node type.
7. If you want to perform the scale-down process right away, choose the Apply immediately check
box. If the Apply immediately check box is left not chosen, the scale-down process is performed
during this cluster's next maintenance window.
8. Choose Modify.
9. When the cluster’s status changes from modifying to available, your cluster has scaled to the new
node type. There is no need to update the endpoints in your application.
The following procedure describes how to scale down a single-node Redis cache cluster using the AWS
CLI.
1. Determine the node types you can scale down to by running the AWS CLI list-allowed-node-
type-modifications command with the following parameter.
• --cache-cluster-id
For Windows:
Output from the above command looks something like this (JSON format).
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium ",
"cache.t1.small ",
],
• --cache-cluster-id – The name of the cache cluster you are scaling down.
• --cache-node-type – The new node type you want to scale the cache cluster. This value
must be one of the node types returned by the list-allowed-node-type-modifications
command in step 1.
• --cache-parameter-group-name – [Optional] Use this parameter if you are using reserved-
memory to manage your cluster's reserved memory. Specify a custom cache parameter group
that reserves the correct amount of memory for your new node type. If you are using reserved-
memory-percent you can omit this parameter.
• --apply-immediately – Causes the scale-down process to be applied immediately. To
postpone the scale-up process to the cluster's next maintenance window, use the --no-apply-
immediately parameter.
For Windows:
Output from the above command looks something like this (JSON format).
{
"CacheCluster": {
"Engine": "redis",
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"CacheParameterGroupName": "default.redis3.2",
"ParameterApplyStatus": "in-sync"
},
"SnapshotRetentionLimit": 1,
"CacheClusterId": "my-redis-cache-cluster",
"CacheSecurityGroups": [],
"NumCacheNodes": 1,
"SnapshotWindow": "00:00-01:00",
"CacheClusterCreateTime": "2017-02-21T22:34:09.645Z",
"AutoMinorVersionUpgrade": true,
"CacheClusterStatus": "modifying",
"PreferredAvailabilityZone": "us-west-2a",
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/
home#client-download:",
"CacheSubnetGroupName": "default",
"EngineVersion": "3.2.4",
"PendingModifiedValues": {
"CacheNodeType": "cache.m3.2xlarge"
},
"PreferredMaintenanceWindow": "tue:11:30-tue:12:30",
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled"
}
}
• --cache-cache cluster-id – The name of your single-node Redis cache cluster. Use this
parameter to describe a particular cache cluster rather than all cache clusters.
The following procedure describes how to scale updown a single-node Redis cache cluster using the
ElastiCache API.
1. Determine the node types you can scale down to by running the ElastiCache API
ListAllowedNodeTypeModifications action with the following parameter.
• CacheClusterId – The name of the single-node Redis cache cluster you want to scale down.
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
• CacheClusterId – The name of the cache cluster you are scaling down.
• CacheNodeType – The new, smaller node type you want to scale the cache cluster down to. This
value must be one of the node types returned by the ListAllowedNodeTypeModifications
action in step 1.
• CacheParameterGroupName – [Optional] Use this parameter if you are using reserved-
memory to manage your cluster's reserved memory. Specify a custom cache parameter group
that reserves the correct amount of memory for your new node type. If you are using reserved-
memory-percent you can omit this parameter.
• ApplyImmediately – Set to true to cause the scale-down process to be performed
immediately. To postpone the scale-up process to the cluster's next maintenance window, use
ApplyImmediately=false.
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheCluster
&ApplyImmediately=true
&CacheClusterId=MyRedisCacheCluster
&CacheNodeType=cache.m3.xlarge
&CacheParameterGroupName redis32-m2-xl
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see ModifyCacheCluster in the Amazon ElastiCache API Reference.
3. If you used ApplyImmediately=true, check the status of the new cache cluster using the
ElastiCache API DescribeCacheClusters action with the following parameter. When the status
changes to available, you can begin using the new, smaller cache cluster.
• CacheClusterId – The name of your single-node Redis cache cluster. Use this parameter to
describe a particular cache cluster rather than all cache clusters.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see DescribeCacheClusters in the Amazon ElastiCache API Reference.
To change the data capacity of your cluster you must scale it up to a larger node type, or down to a
smaller node type.
To change the read capacity of your cluster, add more read replicas, up to a maximum of 5, or remove
read replicas.
The ElastiCache scaling up process is designed to make a best effort to retain your existing data and
requires successful Redis replication. For Redis clusters with replicas, we recommend that sufficient
memory be made available to Redis.
Related Topics
Topics
• Scaling up Redis clusters with replicas (p. 361)
• Scaling down Redis clusters with replicas (p. 367)
• Increasing read capacity (p. 373)
• Decreasing read capacity (p. 374)
How long this process takes is dependent upon your node type and how much data is in your cluster.
As shown in the following table, your Redis scale-up operation is blocked if you have an engine upgrade
scheduled for the cluster’s next maintenance window.
If you have a pending operation that is blocking you, you can do one of the following.
• Schedule your Redis scale-up operation for the next maintenance window by clearing the Apply
immediately check box (CLI use: --no-apply-immediately, API use: ApplyImmediately=false).
• Wait until your next maintenance window (or after) to perform your Redis scale-up operation.
• Add the Redis engine upgrade to this cache cluster modification with the Apply Immediately check
box chosen (CLI use: --apply-immediately, API use: ApplyImmediately=true). This unblocks
your scale-up operation by causing the engine upgrade to be performed immediately.
The following sections describe how to scale your Redis cluster with replicas up using the ElastiCache
console, the AWS CLI, and the ElastiCache API.
Important
If your parameter group uses reserved-memory to set aside memory for Redis overhead,
before you begin scaling be sure that you have a custom parameter group that reserves the
correct amount of memory for your new node type. Alternatively, you can modify a custom
parameter group so that it uses reserved-memory-percent and use that parameter group for
your new cluster.
If you're using reserved-memory-percent, doing this is not necessary.
For more information, see Managing Reserved Memory (p. 223).
The amount of time it takes to scale up to a larger node type varies, depending upon the node type and
the amount of data in your current cluster.
The following process scales your cluster with replicas from its current node type to a new, larger node
type using the ElastiCache console. During this process, there may be a brief interruption of reads and
writes for other versions from the primary node while the DNS entry is updated. you might see less than
1 second downtime for nodes running on 5.0.5 versions and above and a few seconds for older versions.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Redis
3. From the list of clusters, choose the cluster you want to scale up. This cluster must be running the
Redis engine and not the Clustered Redis engine.
4. Choose Modify.
5. In the Modify Cluster wizard:
a. Choose the node type you want to scale to from the Node type list. Note that not all node types
are available to scale down to.
b. If you're using reserved-memory to manage your memory, from the Parameter Group list,
choose the custom parameter group that reserves the correct amount of memory for your new
node type.
6. If you want to perform the scale-up process right away, choose the Apply immediately check box. If
the Apply immediately check box is left not chosen, the scale-up process is performed during this
cluster's next maintenance window.
7. Choose Modify.
8. When the cluster’s status changes from modifying to available, your cluster has scaled to the new
node type. There is no need to update the endpoints in your application.
The following process scales your replication group from its current node type to a new, larger node type
using the AWS CLI. During this process, ElastiCache for Redis updates the DNS entries so they point to
the new nodes. Because of this you don't have to update the endpoints in your application. For Redis
5.0.5 and above, you can scale auto failover enabled clusters while the cluster continues to stay online
and serve incoming requests. On version 5.0.4 and below, you may notice a brief interruption of reads
and writes on previous versions from the primary node while the DNS entry is updated..
The amount of time it takes to scale up to a larger node type varies, depending upon your node type and
the amount of data in your current cache cluster.
1. Determine which node types you can scale up to by running the AWS CLI list-allowed-node-
type-modifications command with the following parameter.
• --replication-group-id – the name of the replication group. Use this parameter to describe
a particular replication group rather than all replication groups.
--replication-group-id my-repl-group
For Windows:
Output from this operation looks something like this (JSON format).
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
}
For Windows:
--apply-immediately
Output from this command looks something like this (JSON format).
{
"ReplicationGroup": {
"Status": "available",
"Description": "Some description",
"NodeGroups": [{
"Status": "available",
"NodeGroupMembers": [{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-001.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-002.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "my-repl-group.8fdx4s.ng.0001.usw2.cache.amazonaws.com"
}
}],
"ReplicationGroupId": "my-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "disabled",
"SnapshotWindow": "12:00-13:00",
"SnapshottingClusterId": "my-repl-group-002",
"MemberClusters": [
"my-repl-group-001",
"my-repl-group-002"
],
"PendingModifiedValues": {}
}
}
• --replication-group-id – the name of the replication group. Use this parameter to describe
a particular replication group rather than all replication groups.
For Windows:
The following process scales your replication group from its current node type to a new, larger node type
using the ElastiCache API. For Redis 5.0.5 and above, you can scale auto failover enabled clusters while
the cluster continues to stay online and serve incoming requests. On version 5.0.4 and below, you may
notice a brief interruption of reads and writes on previous versions from the primary node while the DNS
entry is updated.
The amount of time it takes to scale up to a larger node type varies, depending upon your node type and
the amount of data in your current cache cluster.
1. Determine which node types you can scale up to using the ElastiCache API
ListAllowedNodeTypeModifications action with the following parameter.
• ReplicationGroupId – the name of the replication group. Use this parameter to describe a
specific replication group rather than all replication groups.
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.m3.2xlarge
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
For more information, see ModifyReplicationGroup in the Amazon ElastiCache API Reference.
3. If you used ApplyImmediately=true, monitor the status of the replication group using the
ElastiCache API DescribeReplicationGroups action with the following parameters. When the
status changes from modifying to available, you can begin writing to your new, scaled up replication
group.
• ReplicationGroupId – the name of the replication group. Use this parameter to describe a
particular replication group rather than all replication groups.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see DescribeReplicationGroups in the Amazon ElastiCache API Reference.
1. Ensure that the smaller node type is adequate for your data and overhead needs.
2. If your parameter group uses reserved-memory to set aside memory for Redis overhead, ensure
that you have a custom parameter group to set aside the correct amount of memory for your new
node type.
Alternatively, you can modify your custom parameter group to use reserved-memory-percent.
For more information, see Managing Reserved Memory (p. 223).
3. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
4. From the list of clusters, choose the cluster you want to scale down. This cluster must be running the
Redis engine and not the Clustered Redis engine.
5. Choose Modify.
6. In the Modify Cluster wizard:
a. Choose the node type you want to scale down to from the Node type list.
b. If you're using reserved-memory to manage your memory, from the Parameter Group list,
choose the custom parameter group that reserves the correct amount of memory for your new
node type.
7. If you want to perform the scale-down process right away, choose the Apply immediately check
box. If the Apply immediately check box is left not chosen, the scale-down process is performed
during this cluster's next maintenance window.
8. Choose Modify.
9. When the cluster’s status changes from modifying to available, your cluster has scaled to the new
node type. There is no need to update the endpoints in your application.
5.0.5 and above, you can scale auto failover enabled clusters while the cluster continues to stay online
and serve incoming requests. On version 5.0.4 and below, you may notice a brief interruption of reads
and writes on previous versions from the primary node while the DNS entry is updated..
However, reads from the read replica cache clusters continue uninterrupted.
The amount of time it takes to scale down to a smaller node type varies, depending upon your node type
and the amount of data in your current cache cluster.
1. Determine which node types you can scale down to by running the AWS CLI list-allowed-node-
type-modifications command with the following parameter.
• --replication-group-id – the name of the replication group. Use this parameter to describe
a particular replication group rather than all replication groups.
For Windows:
Output from this operation looks something like this (JSON format).
{
"ScaleDownModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
}
that reserves the correct amount of memory for your new node type. If you are using reserved-
memory-percent you can omit this parameter.
• --apply-immediately – Causes the scale-up process to be applied immediately. To postpone
the scale-up operation to the next maintenance window, use --no-apply-immediately.
For Windows:
Output from this command looks something like this (JSON format).
{"ReplicationGroup": {
"Status": "available",
"Description": "Some description",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-
group-001.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-
group-002.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "my-repl-group.8fdx4s.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "my-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "disabled",
"SnapshotWindow": "12:00-13:00",
"SnapshottingClusterId": "my-repl-group-002",
"MemberClusters": [
"my-repl-group-001",
"my-repl-group-002",
],
"PendingModifiedValues": {}
}
}
• --replication-group-id – the name of the replication group. Use this parameter to describe
a particular replication group rather than all replication groups.
For Windows:
The following process scales your replication group from its current node type to a new, smaller node
type using the ElastiCache API. During this process, ElastiCache for Redis updates the DNS entries so they
point to the new nodes. Because of this you don't have to update the endpoints in your application. For
Redis 5.0.5 and above, you can scale auto failover enabled clusters while the cluster continues to stay
online and serve incoming requests. On version 5.0.4 and below, you may notice a brief interruption of
reads and writes on previous versions from the primary node while the DNS entry is updated.. However,
reads from the read replica cache clusters continue uninterrupted.
The amount of time it takes to scale down to a smaller node type varies, depending upon your node type
and the amount of data in your current cache cluster.
1. Determine which node types you can scale down to using the ElastiCache API
ListAllowedNodeTypeModifications action with the following parameter.
• ReplicationGroupId – the name of the replication group. Use this parameter to describe a
specific replication group rather than all replication groups.
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.m3.2xlarge
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
For more information, see ModifyReplicationGroup in the Amazon ElastiCache API Reference.
3. If you used ApplyImmediately=true, monitor the status of the replication group using the
ElastiCache API DescribeReplicationGroups action with the following parameters. When
the status changes from modifying to available, you can begin writing to your new, scaled down
replication group.
• ReplicationGroupId – the name of the replication group. Use this parameter to describe a
particular replication group rather than all replication groups.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see DescribeReplicationGroups in the Amazon ElastiCache API Reference.
You can scale your Redis cluster’s read capacity using the ElastiCache console, the AWS CLI, or the
ElastiCache API. For more information, see Adding a read replica, for Redis (Cluster Mode Disabled)
replication groups (p. 306).
For more information, see Deleting a read replica, for Redis (Cluster Mode Disabled) replication groups
(p. 308).
Conditions under which you might decide to rescale your cluster include the following:
• Memory pressure:
If the nodes in your cluster are under memory pressure, you might decide to scale out so that you have
more resources to better store data and serve requests.
You can determine whether your nodes are under memory pressure by monitoring the following
metrics: FreeableMemory, SwapUsage, and BytesUseForCache.
• CPU or network bottleneck:
If latency/throughput issues are plaguing your cluster, you might need to scale out to resolve the
issues.
You can monitor your latency and throughput levels by monitoring the following metrics:
CPUUtilization, NetworkBytesIn, NetworkBytesOut, CurrConnections, and NewConnections.
• Your cluster is over-scaled:
Current demand on your cluster is such that scaling in doesn't hurt performance and reduces your
costs.
You can monitor your cluster's use to determine whether or not you can safely scale in using the
following metrics: FreeableMemory, SwapUsage, BytesUseForCache, CPUUtilization, NetworkBytesIn,
NetworkBytesOut, CurrConnections, and NewConnections.
When you scale using the offline process, your cluster is offline for a significant portion of the process
and thus unable to serve requests. When you scale using the online method, because scaling is a
compute-intensive operation, there is some degradation in performance, nevertheless, your cluster
continues to serve requests throughout the scaling operation. How much degradation you experience
depends upon your normal CPU utilization and your data.
There are two ways to scale your Redis (cluster mode enabled) cluster; horizontal and vertical scaling.
• Horizontal scaling allows you to change the number of node groups (shards) in the replication group
by adding or removing node groups (shards). The online resharding process allows scaling in/out while
the cluster continues serving incoming requests.
Configure the slots in your new cluster differently than they were in the old cluster. Offline method
only.
• Vertical Scaling - Change the node type to resize the cluster. The online vertical scaling allows scaling
up/down while the cluster continues serving incoming requests.
If you are reducing the size and memory capacity of the cluster, by either scaling in or scaling down,
ensure that the new configuration has sufficient memory for your data and Redis overhead.
For more information, see Choosing your node size (p. 127).
Contents
• Offline resharding and shard rebalancing for Redis (cluster mode enabled) (p. 376)
• Online resharding and shard rebalancing for Redis (cluster mode enabled) (p. 377)
• Adding shards with online resharding (p. 377)
• Removing shards with online resharding (p. 380)
• Removing shards (Console) (p. 380)
• Removing shards (AWS CLI) (p. 381)
• Removing shards (ElastiCache API) (p. 382)
• Online shard rebalancing (p. 383)
• Online Shard Rebalancing (Console) (p. 383)
• Online shard rebalancing (AWS CLI) (p. 383)
• Online shard rebalancing (ElastiCache API) (p. 384)
• Online vertical scaling by modifying node type (p. 385)
• Online scaling up (p. 385)
• Scaling up Redis cache clusters (Console) (p. 386)
• Scaling up Redis cache clusters (AWS CLI) (p. 350)
• Scaling up Redis cache clusters (ElastiCache API) (p. 388)
• Online scaling down (p. 390)
• Scaling down Redis cache clusters (Console) (p. 390)
• Scaling down Redis cache clusters (AWS CLI) (p. 390)
• Scaling down Redis cache clusters (ElastiCache API) (p. 392)
The main disadvantage of offline shard reconfiguration is that your cluster is offline beginning with the
restore portion of the process and continuing until you update the endpoints in your application. The
length of time that your cluster is offline varies with the amount of data in your cluster.
1. Create a manual backup of your existing Redis cluster. For more information, see Making manual
backups (p. 315).
2. Create a new cluster by restoring from the backup. For more information, see Restoring from a
backup with optional cluster resizing (p. 334).
3. Update the endpoints in your application to the new cluster's endpoints. For more information, see
Finding connection endpoints (p. 175).
• Scale out – Increase read and write capacity by adding shards (node groups) to your Redis (cluster
mode enabled) cluster (replication group).
If you add one or more shards to your replication group, the number of nodes in each new shard is the
same as the number of nodes in the smallest of the existing shards.
• Scale in – Reduce read and write capacity, and thereby costs, by removing shards from your Redis
(cluster mode enabled) cluster.
• Rebalance – Move the keyspaces among the shards in your ElastiCache for Redis (cluster mode
enabled) cluster so they are as equally distributed among the shards as possible.
You can't specify the keyspace for shards independently. To do this, you must use the offline process.
Currently, the following limitations apply to ElastiCache for Redis online resharding and rebalancing:
• These processes require Redis engine version 3.2.10 or newer. For information on upgrading your
engine version, see Upgrading engine versions (p. 198).
• There are limitations with slots or keyspaces and large items:
If any of the keys in a shard contain a large item, that key isn't migrated to a new shard when scaling
out or rebalancing. This functionality can result in unbalanced shards.
If any of the keys in a shard contain a large item (items greater than 256 MB after serialization), that
shard isn't deleted when scaling in. This functionality can result in some shards not being deleted.
• When scaling out, the number of nodes in any new shards equals the number of nodes in the smallest
existing shard.
• When scaling out, any tags that are common to all existing shards are copied to the new shards.
For more information, see Best practices: Online cluster resizing (p. 229).
You can horizontally scale or rebalance your ElastiCache for Redis (cluster mode enabled) clusters using
the AWS Management Console, the AWS CLI, and the ElastiCache API.
a. For Number of shards to be added, choose the number of shards you want added to this
cluster.
b. For Availability zone(s), choose either No preference or Specify availability zones.
c. If you chose Specify availability zones, for each node in each shard, select the node's
Availability Zone from the list of Availability Zones.
d. Choose Add.
Parameters
Optionally, you can specify the Availability Zone for each node in the replication group using --
resharding-configuration.
• --resharding-configuration – Optional. A list of preferred Availability Zones for each node in
each shard in the replication group. Use this parameter only if the value of --node-group-count is
greater than the current number of shards. If this parameter is omitted when adding shards, Amazon
ElastiCache selects the Availability Zones for the new nodes.
The following example reconfigures the keyspaces over four shards in the Redis (cluster mode enabled)
cluster my-cluster. The example also specifies the Availability Zone for each node in each shard. The
operation begins immediately.
--replication-group-id my-cluster \
--node-group-count 4 \
--resharding-configuration \
"PreferredAvailabilityZones=us-east-2a,us-east-2c" \
"PreferredAvailabilityZones=us-east-2b,us-east-2a" \
"PreferredAvailabilityZones=us-east-2c,us-east-2d" \
"PreferredAvailabilityZones=us-east-2d,us-east-2c" \
--apply-immediately
For Windows:
You can use the ElastiCache API to reconfigure the shards in your Redis (cluster mode enabled) cluster
online by using the ModifyReplicationGroupShardConfiguration operation.
Parameters
Optionally, you can specify the Availability Zone for each node in the replication group using
ReshardingConfiguration.
• ReshardingConfiguration – Optional. A list of preferred Availability Zones for each node in
each shard in the replication group. Use this parameter only if the value of NodeGroupCount is
greater than the current number of shards. If this parameter is omitted when adding shards, Amazon
ElastiCache selects the Availability Zones for the new nodes.
The following process describes how to reconfigure the shards in your Redis (cluster mode enabled)
cluster by adding shards using the ElastiCache API.
The following example adds node groups to the Redis (cluster mode enabled) cluster my-cluster, so
there are a total of four node groups when the operation completes. The example also specifies the
Availability Zone for each node in each shard. The operation begins immediately.
https://elasticache.us-east-2.amazonaws.com/
?Action=ModifyReplicationGroupShardConfiguration
&ApplyImmediately=true
&NodeGroupCount=4
&ReplicationGroupId=my-cluster
&ReshardingConfiguration.ReshardingConfiguration.1.PreferredAvailabilityZones.AvailabilityZone.1=us-
east-2a
&ReshardingConfiguration.ReshardingConfiguration.1.PreferredAvailabilityZones.AvailabilityZone.2=us-
east-2c
&ReshardingConfiguration.ReshardingConfiguration.2.PreferredAvailabilityZones.AvailabilityZone.1=us-
east-2b
&ReshardingConfiguration.ReshardingConfiguration.2.PreferredAvailabilityZones.AvailabilityZone.2=us-
east-2a
&ReshardingConfiguration.ReshardingConfiguration.3.PreferredAvailabilityZones.AvailabilityZone.1=us-
east-2c
&ReshardingConfiguration.ReshardingConfiguration.3.PreferredAvailabilityZones.AvailabilityZone.2=us-
east-2d
&ReshardingConfiguration.ReshardingConfiguration.4.PreferredAvailabilityZones.AvailabilityZone.1=us-
east-2d
&ReshardingConfiguration.ReshardingConfiguration.4.PreferredAvailabilityZones.AvailabilityZone.2=us-
east-2c
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20171002T192317Z
&X-Amz-Credential=<credential>
Topics
• Removing shards (Console) (p. 380)
• Removing shards (AWS CLI) (p. 381)
• Removing shards (ElastiCache API) (p. 382)
The following process describes how to reconfigure the shards in your Redis (cluster mode enabled)
cluster by removing shards using the AWS Management Console.
Before removing node groups (shards) from your replication group, ElastiCache makes sure that all
your data will fit in the remaining shards. If the data will fit, the specified shards are deleted from
the replication group as requested. If the data won't fit in the remaining node groups, the process is
terminated and the replication group is left with the same node group configuration as before the
request was made.
You can use the AWS Management Console to remove one or more shards from your Redis (cluster
mode enabled) cluster. You cannot remove all the shards in a replication group. Instead, you must delete
the replication group. For more information, see Deleting a replication group (p. 296). The following
procedure describes the process for deleting one or more shards.
The following process describes how to reconfigure the shards in your Redis (cluster mode enabled)
cluster by removing shards using the AWS CLI.
Important
Before removing node groups (shards) from your replication group, ElastiCache makes sure that
all your data will fit in the remaining shards. If the data will fit, the specified shards (--node-
groups-to-remove) are deleted from the replication group as requested and their keyspaces
mapped into the remaining shards. If the data will not fit in the remaining node groups, the
process is terminated and the replication group is left with the same node group configuration
as before the request was made.
You can use the AWS CLI to remove one or more shards from your Redis (cluster mode enabled) cluster.
You cannot remove all the shards in a replication group. Instead, you must delete the replication group.
For more information, see Deleting a replication group (p. 296).
Parameters
The following procedure describes the process for deleting one or more shards.
The following example removes two node groups from the Redis (cluster mode enabled) cluster my-
cluster, so there are a total of two node groups when the operation completes. The keyspaces from
the removed shards are distributed evenly over the remaining shards.
--replication-group-id my-cluster \
--node-group-count 2 \
--node-groups-to-remove "0002" "0003" \
--apply-immediately
For Windows:
You can use the ElastiCache API to reconfigure the shards in your Redis (cluster mode enabled) cluster
online by using the ModifyReplicationGroupShardConfiguration operation.
The following process describes how to reconfigure the shards in your Redis (cluster mode enabled)
cluster by removing shards using the ElastiCache API.
Important
Before removing node groups (shards) from your replication group, ElastiCache makes sure
that all your data will fit in the remaining shards. If the data will fit, the specified shards
(NodeGroupsToRemove) are deleted from the replication group as requested and their
keyspaces mapped into the remaining shards. If the data will not fit in the remaining node
groups, the process is terminated and the replication group is left with the same node group
configuration as before the request was made.
You can use the ElastiCache API to remove one or more shards from your Redis (cluster mode enabled)
cluster. You cannot remove all the shards in a replication group. Instead, you must delete the replication
group. For more information, see Deleting a replication group (p. 296).
Parameters
The following procedure describes the process for deleting one or more shards.
The following example removes two node groups from the Redis (cluster mode enabled) cluster my-
cluster, so there are a total of two node groups when the operation completes. The keyspaces from
the removed shards are distributed evenly over the remaining shards.
https://elasticache.us-east-2.amazonaws.com/
?Action=ModifyReplicationGroupShardConfiguration
&ApplyImmediately=true
&NodeGroupCount=2
&ReplicationGroupId=my-cluster
&NodeGroupsToRemove.member.1=0002
&NodeGroupsToRemove.member.2=0003
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20171002T192317Z
&X-Amz-Credential=<credential>
Topics
• Online Shard Rebalancing (Console) (p. 383)
• Online shard rebalancing (AWS CLI) (p. 383)
• Online shard rebalancing (ElastiCache API) (p. 384)
The following process describes how to reconfigure the shards in your Redis (cluster mode enabled)
cluster by rebalancing shards using the AWS Management Console.
To rebalance the keyspaces among the shards on your Redis (cluster mode enabled) cluster
Parameters
The following process describes how to reconfigure the shards in your Redis (cluster mode enabled)
cluster by rebalancing shards using the AWS CLI.
For Windows:
Parameters
The following process describes how to reconfigure the shards in your Redis (cluster mode enabled)
cluster by rebalancing the shards using the ElastiCache API.
https://elasticache.us-east-2.amazonaws.com/
?Action=ModifyReplicationGroupShardConfiguration
&ApplyImmediately=true
&NodeGroupCount=4
&ReplicationGroupId=my-cluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20171002T192317Z
&X-Amz-Credential=<credential>
• Scale up – Increase read and write capacity by adjusting the node type of your Redis cluster to use a
larger node type.
ElastiCache dynamically resizes your cluster while remaining online and serving requests.
• Scale down – Reduce read and write capacity by adjusting the node type down to use a smaller node.
Again, ElastiCache dynamically resizes your cluster while remaining online and serving requests. In this
case, you reduce costs by downsizing the node.
Note
The scale up and scale down processes rely on creating clusters with newly selected node types
and synchronizing the new nodes with the previous ones. To ensure a smooth scale up/down
flow, do the following:
• Ensure you have sufficient ENI (Elastic Network Interface) capacity. If scaling down, ensure the
smaller node has sufficient memory to absorb expected traffic.
For best practices on memory management, see Managing Reserved Memory (p. 223).
• While the vertical scaling process is designed to remain fully online, it does rely on
synchronizing data between the old node and the new node. We recommend that you initiate
scale up/down during hours when you expect data traffic to be at its minimum.
• Test your application behavior during scaling in a staging environment, if possible.
Contents
• Online scaling up (p. 385)
• Scaling up Redis cache clusters (Console) (p. 386)
• Scaling up Redis cache clusters (AWS CLI) (p. 350)
• Scaling up Redis cache clusters (ElastiCache API) (p. 388)
• Online scaling down (p. 390)
• Scaling down Redis cache clusters (Console) (p. 390)
• Scaling down Redis cache clusters (AWS CLI) (p. 390)
• Scaling down Redis cache clusters (ElastiCache API) (p. 392)
Online scaling up
Topics
• Scaling up Redis cache clusters (Console) (p. 386)
• Scaling up Redis cache clusters (AWS CLI) (p. 350)
• Scaling up Redis cache clusters (ElastiCache API) (p. 388)
API Version 2015-02-02
385
Amazon ElastiCache for Redis User Guide
Scaling clusters in Redis (Cluster Mode Enabled)
The following procedure describes how to scale up a Redis cluster using the ElastiCache Management
Console. During this process, your Redis cluster will continue to serve requests with minimal downtime.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Redis.
3. From the list of clusters, choose the cluster.
4. Choose Modify.
5. In the Modify Cluster wizard:
• Choose the node type you want to scale to from the Node type list. To scale up, select a node
type larger than your existing node.
6. If you want to perform the scale-up process right away, choose the Apply immediately box. If the
Apply immediately box is not chosen, the scale-up process is performed during this cluster's next
maintenance window.
7. Choose Modify.
If you chose Apply immediately in the previous step, the cluster's status changes to modifying.
When the status changes to available, the modification is complete and you can begin using the new
cluster.
The following procedure describes how to scale up a Redis cache cluster using the AWS CLI. During this
process, your Redis cluster will continue to serve requests with minimal downtime.
1. Determine the node types you can scale up to by running the AWS CLI list-allowed-node-
type-modifications command with the following parameter.
For Windows:
Output from the above command looks something like this (JSON format).
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium",
"cache.t1.small "
],
}
• --replication-group-id – The name of the replication group you are scaling up to.
• --cache-node-type – The new node type you want to scale the cache cluster. This value
must be one of the node types returned by the list-allowed-node-type-modifications
command in step 1.
• --cache-parameter-group-name – [Optional] Use this parameter if you are using reserved-
memory to manage your cluster's reserved memory. Specify a custom cache parameter group
that reserves the correct amount of memory for your new node type. If you are using reserved-
memory-percent you can omit this parameter.
• --apply-immediately – Causes the scale-up process to be applied immediately. To postpone
the scale-up process to the cluster's next maintenance window, use the --no-apply-
immediately parameter.
For Windows:
Output from the above command looks something like this (JSON format).
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "my-redis-cluster",
"NodeGroups": [
{
"Status": "modifying",
"Slots": "0-16383",
"NodeGroupId": "0001",
"NodeGroupMembers": [
{
"PreferredAvailabilityZone": "us-east-1f",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-001"
},
{
"PreferredAvailabilityZone": "us-east-1d",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-002"
}
]
}
],
"ConfigurationEndpoint": {
"Port": 6379,
"Address": "my-redis-cluster.r7gdfi.clustercfg.use1.cache.amazonaws.com"
},
"ClusterEnabled": true,
"ReplicationGroupId": "my-redis-cluster",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotWindow": "07:30-08:30",
"MemberClusters": [
"my-redis-cluster-0001-001",
"my-redis-cluster-0001-002"
],
"CacheNodeType": "cache.m3.xlarge",
"DataTiering": "disabled"
"PendingModifiedValues": {}
}
}
The amount of time it takes to scale up to a larger node type varies, depending upon your node type and
the amount of data in your current cache cluster.
1. Determine which node types you can scale up to using the ElastiCache API
ListAllowedNodeTypeModifications action with the following parameter.
• ReplicationGroupId – the name of the replication group. Use this parameter to describe a
specific replication group rather than all replication groups.
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.m3.2xlarge
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
For more information, see ModifyReplicationGroup in the Amazon ElastiCache API Reference.
3. If you used ApplyImmediately=true, monitor the status of the replication group using the
ElastiCache API DescribeReplicationGroups action with the following parameters. When the
status changes from modifying to available, you can begin writing to your new, scaled up replication
group.
• ReplicationGroupId – the name of the replication group. Use this parameter to describe a
particular replication group rather than all replication groups.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
For more information, see DescribeReplicationGroups in the Amazon ElastiCache API Reference.
The following procedure describes how to scale down a Redis cluster using the ElastiCache Management
Console. During this process, your Redis cluster will continue to serve requests with minimal downtime.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the navigation pane, choose Redis.
3. From the list of clusters, choose your preferred cluster.
4. Choose Modify.
5. In the Modify Cluster wizard:
• Choose the node type you want to scale to from the Node type list. To scale down, select a
node type smaller than your existing node. Note that not all node types are available to scale
down to.
6. If you want to perform the scale down process right away, choose the Apply immediately box. If the
Apply immediately box is not chosen, the scale-down process is performed during this cluster's next
maintenance window.
7. Choose Modify.
If you chose Apply immediately in the previous step, the cluster's status changes to modifying.
When the status changes to available, the modification is complete and you can begin using the new
cluster.
The following procedure describes how to scale down a Redis cache cluster using the AWS CLI. During
this process, your Redis cluster will continue to serve requests with minimal downtime.
1. Determine the node types you can scale down to by running the AWS CLI list-allowed-node-
type-modifications command with the following parameter.
For Windows:
Output from the above command looks something like this (JSON format).
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium ",
"cache.t1.small"
]
}
• --replication-group-id – The name of the replication group you are scaling down to.
• --cache-node-type – The new node type you want to scale the cache cluster. This value
must be one of the node types returned by the list-allowed-node-type-modifications
command in step 1.
• --cache-parameter-group-name – [Optional] Use this parameter if you are using reserved-
memory to manage your cluster's reserved memory. Specify a custom cache parameter group
that reserves the correct amount of memory for your new node type. If you are using reserved-
memory-percent you can omit this parameter.
• --apply-immediately – Causes the scale-up process to be applied immediately. To postpone
the scale-down process to the cluster's next maintenance window, use the --no-apply-
immediately parameter.
For Windows:
--replication-group-id my-redis-cluster ^
--cache-node-type cache.t2.micro ^
--apply-immediately
Output from the above command looks something like this (JSON format).
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "my-redis-cluster",
"NodeGroups": [
{
"Status": "modifying",
"Slots": "0-16383",
"NodeGroupId": "0001",
"NodeGroupMembers": [
{
"PreferredAvailabilityZone": "us-east-1f",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-001"
},
{
"PreferredAvailabilityZone": "us-east-1d",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-002"
}
]
}
],
"ConfigurationEndpoint": {
"Port": 6379,
"Address": "my-redis-cluster.r7gdfi.clustercfg.use1.cache.amazonaws.com"
},
"ClusterEnabled": true,
"ReplicationGroupId": "my-redis-cluster",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotWindow": "07:30-08:30",
"MemberClusters": [
"my-redis-cluster-0001-001",
"my-redis-cluster-0001-002"
],
"CacheNodeType": "cache.t2.micro",
"DataTiering": "disabled"
"PendingModifiedValues": {}
}
}
The following process scales your replication group from its current node type to a new, smaller node
type using the ElastiCache API. During this process, your Redis cluster will continue to serve requests
with minimal downtime.
The amount of time it takes to scale down to a smaller node type varies, depending upon your node type
and the amount of data in your current cache cluster.
1. Determine which node types you can scale down to using the ElastiCache API
ListAllowedNodeTypeModifications action with the following parameter.
• ReplicationGroupId – the name of the replication group. Use this parameter to describe a
specific replication group rather than all replication groups.
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.t2.micro
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
For more information, see ModifyReplicationGroup in the Amazon ElastiCache API Reference.
• Redis (cluster mode enabled) clusters running Redis engine version 6.0 onwards
• Instance type families - R5, R6g, M5, M6g
• Instance sizes - Large, XLarge, 2XLarge
• Auto Scaling in ElastiCache for Redis is not supported for clusters running in Global datastores,
Outposts or Local Zones.
• AWS Auto Scaling for ElastiCache for Redis is not available in the following regions: China (Beijing),
China (Ningxia), AWS GovCloud (US-West) and AWS GovCloud (US-East).
You can use the AWS Management Console to apply a scaling policy based on a predefined metric.
A predefined metric is defined in an enumeration so that you can specify it by name in code or
use it in the AWS Management Console. Custom metrics are not available for selection using the AWS
Management Console. Alternatively, you can use either the AWS CLI or the Application Auto Scaling API
to apply a scaling policy based on a predefined or custom metric.
• Shards – Automatically add/remove shards in the cluster similar to manual online resharding. In this
case, ElastiCache for Redis auto scaling triggers scaling on your behalf.
• Replicas – Automatically add/remove replicas in the cluster similar to manual Increase/Decrease
replica operations. ElastiCache for Redis auto scaling adds/removes replicas uniformly across all shards
in the cluster.
ElastiCache for Redis supports the following types of automatic scaling policies:
• Target tracking scaling policies (p. 400) – Increase or decrease the number of shards/replicas that
your service runs based on a target value for a specific metric. This is similar to the way that your
thermostat maintains the temperature of your home. You select a temperature and the thermostat
does the rest.
• Scheduled scaling for Application ElastiCache for Redis auto scaling – Increase or decrease the number
of shards/replicas that your service runs based on the date and time.
The following steps summarize the ElastiCache for Redis auto scaling process as shown in the previous
diagram:
1. You create an ElastiCache for Redis auto scaling policy for your ElastiCache for Redis Replication
Group.
2. ElastiCache for Redis auto scaling creates a pair of CloudWatch alarms on your behalf. Each pair
represents your upper and lower boundaries for metrics. These CloudWatch alarms are triggered
when the cluster's actual utilization deviates from your target utilization for a sustained period of
time. You can view the alarms in the console.
3. If the configured metric value exceeds your target utilization (or falls below the target) for a specific
length of time, CloudWatch triggers an alarm that invokes ElastiCache for Redis auto scaling to
evaluate your scaling policy.
4. ElastiCache for Redis auto scaling issues a Modify request to adjust your cluster capacity.
5. ElastiCache for Redis processes the Modify request, dynamically increasing (or decreasing) the
cluster Shards/Replicas capacity so that it approaches your target utilization.
To understand how ElastiCache for Redis Auto Scaling works, suppose that you have a cluster named
UsersCluster. By monitoring the CloudWatch metrics for UsersCluster, you determine the Max
shards that the cluster requires when traffic is at its peak and Min Shards when traffic is at its lowest
point. You also decide a target value for CPU utilization for the UsersCluster cluster. ElastiCache
for Redis auto scaling uses its target tracking algorithm to ensure that the provisioned shards of
UsersCluster is adjusted as required so that utilization remains at or near to the target value.
Note
Scaling may take noticeable time and will require extra cluster resources for shards to rebalance.
ElastiCache for Redis Auto Scaling modifies resource settings only when the actual workload
stays elevated (or depressed) for a sustained period of several minutes. The ElastiCache for Redis
auto scaling target-tracking algorithm seeks to keep the target utilization at or near your chosen
value over the long term.
• A target metric – The CloudWatch metric that ElastiCache for Redis Auto Scaling uses to determine
when and how much to scale.
• Minimum and maximum capacity – The minimum and maximum number of shards or replicas to use
for scaling.
Important
While creating Auto scaling policy , if current capacity is higher than max capacity configured,
we scaleIn to the MaxCapacity during policy creation. Similarly if current capacity is lower
than min capacity configured, we scaleOut to the MinCapacity.
• A cooldown period – The amount of time, in seconds, after a scale-in or scale-out activity completes
before another scale-out activity can start.
• A service-linked role – An AWS Identity and Access Management (IAM) role that is linked to a specific
AWS service. A service-linked role includes all of the permissions that the service requires to call other
AWS services on your behalf. ElastiCache for Redis Auto Scaling automatically generates this role,
AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG, for you.
• Enable or disable scale-in activities - Ability to enable or disable scale-in activities for a policy.
Topics
• Target metric for Auto Scaling (p. 396)
• Minimum and maximum capacity (p. 396)
• Cool down period (p. 397)
• Enable or disable scale-in activities (p. 397)
For example, consider a scaling policy that uses the predefined average
ElastiCachePrimaryEngineCPUUtilization metric. Such a policy can keep CPU utilization at, or
close to, a specified percentage of utilization, such as 70 percent.
Note
For each cluster, you can create only one Auto Scaling policy for each target metric.
You can specify the maximum number of shards that can be scaled to by ElastiCache for Redis auto
scaling. This value must be less than or equal to 250 with a minimum of 1. You can also specify the
minimum number of shards to be managed by ElastiCache for Redis auto scaling. This value must be at
least 1, and equal to or less than the value specified for the maximum shards 250.
Replicas
You can specify the maximum number of replicas to be managed by ElastiCache for Redis auto scaling.
This value must be less than or equal to 5. You can also specify the minimum number of replicas to be
managed by ElastiCache for Redis auto scaling. This value must be at least 1, and equal to or less than
the value specified for the maximum replicas 5.
To determine the minimum and maximum number of shards/replicas that you need for typical traffic,
test your Auto Scaling configuration with the expected rate of traffic to your model.
Note
ElastiCache for Redis auto scaling policies increase cluster capacity until it reaches your defined
maximum size or until service limits apply. To request a limit increase, see AWS Service Limits
and choose the limit type Nodes per cluster per instance type.
Important
Scaling-in occurs when there is no traffic. If a variant’s traffic becomes zero, ElastiCache for
Redis automatically scales in to the minimum number of instances specified.
• A scale-in activity reduces the number of shards/replicas in your ElastiCache for Redis cluster. A scale-
in cooldown period specifies the amount of time, in seconds, after a scale-in activity completes before
another scale-in activity can start.
• A scale-out activity increases the number of shards/replicas in your ElastiCache for Redis cluster.
A scale-out cooldown period specifies the amount of time, in seconds, after a scale-out activity
completes before another scale-out activity can start.
When a scale-in or a scale-out cooldown period is not specified, the default for scale-out is 600 seconds
and for scale-in 900 seconds.
for Redis, alarms are created with CloudWatch, and scaling policies are created with Application Auto
Scaling. In addition to the standard IAM permissions for creating and updating clusters, the IAM user
that accesses ElastiCache for Redis Auto Scaling settings must have the appropriate permissions for the
services that support dynamic scaling. IAM users must have permissions to use the actions shown in the
following example policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"application-autoscaling:*",
"elasticache:DescribeReplicationGroups",
"elasticache:ModifyReplicationGroupShardConfiguration",
"elasticache:IncreaseReplicaCount",
"elasticache:DecreaseReplicaCount",
"elasticache:DescribeCacheClusters",
"elasticache:DescribeCacheParameters",
"cloudwatch:DeleteAlarms",
"cloudwatch:DescribeAlarmHistory",
"cloudwatch:DescribeAlarms",
"cloudwatch:DescribeAlarmsForMetric",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics",
"cloudwatch:PutMetricAlarm",
"cloudwatch:DisableAlarmActions",
"cloudwatch:EnableAlarmActions",
"iam:CreateServiceLinkedRole",
"sns:CreateTopic",
"sns:Subscribe",
"sns:Get*",
"sns:List*"
],
"Resource": "arn:aws:iam::123456789012:role/autoscaling-roles-for-cluster"
}
]
}
Service-linked role
The ElastiCache for Redis auto scaling service also needs permission to describe your clusters and
CloudWatch alarms, and permissions to modify your ElastiCache for Redis target capacity on your behalf.
If you enable Auto Scaling for your ElastiCache for Redis cluster, it creates a service-linked role named
AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG. This service-linked role grants
ElastiCache for Redis auto scaling permission to describe the alarms for your policies, to monitor the
current capacity of the fleet, and to modify the capacity of the fleet. The service-linked role is the default
role for ElastiCache for Redis auto scaling. For more information, see Service-linked roles for ElastiCache
for Redis auto scaling in the Application Auto Scaling User Guide.
1. Use just one tracking metric – Identify if your cluster has CPU- or memory-intensive workloads and
use a corresponding predefined metric to define Scaling Policy. We recommend you avoid multiple
policies per dimension on the cluster. ElastiCache for Redis Auto scaling will scale out the scalable
target if any of the target tracking policies are ready for scale out, but will scale in only if all of the
target tracking policies (with the scale-in portion enabled) are ready to scale in. If multiple policies
instruct the scalable target to scale out or in at the same time, it scales based on the policy that
provides the largest capacity for both scale in and scale out.
2. Use just one dimension – Identify if your cluster has a write- or read-heavy workload and use
corresponding dimension(shards/replicas) to define scaling policy. Having policies on multiple
dimensions for the same cluster can have repercussions on scaling actions. For example, if you create
scaling policies on engine CPU for both shards and replicas, and if a scale-out action is triggered on
a shard dimension which adds new shards along with their replicas, this increase in new replicas can
impact scaling policy of replica dimension that can trigger scale-in of replicas and vise versa. Avg
metric is used across cluster nodes for the Predefined Metrics.
3. Customized Metrics for Target Tracking – Be cautious when using customized metrics for Target
Tracking as Auto scaling is best suited to scale-out/in proportional to change in metrics choosen for
the policy. If such metrics that don't change proprtionally to the scaling actions are used for policy
creation, it might lead to continous scale-out or scale-in actions which might affect availability or cost.
4. Scheduled Scaling – If you identify that your workload is deterministic (reaches high/low at a specific
time), we recommend using Scheduled Scaling and configure your target capacity according to the
need. Target Tracking is best suitable for non-deterministic workloads and for the cluster to operate at
the required target metric by scaling out when you need more resources and scaling in when you need
less.
5. Disable Scale-In – Auto scaling on Target Tracking is best suited for clusters with gradual increase/
decrease of workloads as spikes/dip in metrics can trigger consecutive scale-out/in oscillations. In
order to avoid such oscillations, you can start with scale-in disabled and later you can always manually
scale-in to your need.
6. Test your application – We recommend you test your application with your estimated Min/Max
workloads to determine absolute Min,Max shards/replicas required for the cluster while creating
Scaling policies to avoid availability issues. Auto scaling can scale out to the Max and scale-in to the
Min threshold configured for the target.
7. Defining Target Value – You can analyze corresponding CloudWatch metrics for cluster utilization
over a four-week period to determine the target value threshold. If you are still not sure of of what
value to choose, we recommend starting with a minimum supported predefined metric value.
8. AutoScaling on Target Tracking is best suited for clusters with uniform distribution of workloads
across shards/replicas dimension. Having non-uniform distribution can lead to:
• Scaling when not required due to workload spike/dip on a few hot shards/replicas.
• Not scaling when required due to overall avg close to target even though having hot shards/
replicas.
• There are limitations on Auto scaling Supported Configurations, so we recommend you not change
configuration of a replication group that is registered for Auto scaling. The following are examples:
• Manually modifying instance type to unsupported types.
• Associating the replication group to a Global datastore.
• Changing ReservedMemoryPercent parameter.
• Manually increasing/decreasing shards/replicas beyond the Min/Max capacity configured during
policy creation.
For example, consider a scaling policy that uses the predefined average
ElastiCachePrimaryEngineCPUUtilization metric with configured target value. Such a policy can
keep CPU utilization at, or close to the specified target value.
• if your Target breaches by 30 percent, ElastiCache for Redis scales out by 30 percent, which results in
65 shards per cluster.
• if your Target breaches by 10 percent, ElastiCache for Redis scales out by default Minimum of 20
percent, which results in 60 shards per cluster.
For a scale-in example, if you have selected a Target value of 60 percent, ElastiCache for Redis won't auto
scale-in until the metric is less than or equal to 45 percent (25 percent below the Target 60 percent).
• A target tracking scaling policy assumes that it should perform scale out when the specified metric is
above the target value. You cannot use a target tracking scaling policy to scale out when the specified
metric is below the target value. ElastiCache for Redis scales out shards by a minimum of 20 percent
deviation of target of existing shards in the cluster.
• A target tracking scaling policy does not perform scaling when the specified metric has insufficient
data. It does not perform scale-in because it does not interpret insufficient data as low utilization.
• You may see gaps between the target value and the actual metric data points. This is because
ElastiCache for Redis Auto Scaling always acts conservatively by rounding up or down when it
determines how much capacity to add or remove. This prevents it from adding insufficient capacity or
removing too much capacity.
• To ensure application availability, the service scales out proportionally to the metric as fast as it can,
but scales in more conservatively.
• You can have multiple target tracking scaling policies for an ElastiCache for Redis cluster, provided
that each of them uses a different metric. The intention of ElastiCache for Redis Auto Scaling is to
always prioritize availability, so its behavior differs depending on whether the target tracking policies
are ready for scale out or scale in. It will scale out the service if any of the target tracking policies are
ready for scale out, but will scale in only if all of the target tracking policies (with the scale-in portion
enabled) are ready to scale in.
• Do not edit or delete the CloudWatch alarms that ElastiCache for Redis Auto Scaling manages for
a target tracking scaling policy. ElastiCache for Redis Auto Scaling deletes the alarms automatically
when you delete the scaling policy.
• ElastiCache for Redis Auto Scaling doesn't prevent you from manually modifying cluster shards. These
manual adjustments don't affect any existing CloudWatch alarms that are attached to the scaling
policy but can impact metrics that may trigger these CloudWatch alarms.
• These CloudWatch alarms managed by Auto Scaling are defined over the AVG metric across all the
shards in the cluster. So, having hot shards can result in either scenario of:
• scaling when not required due to load on a few hot shards triggering a CloudWatch alarm
• not scaling when required due to aggregated AVG across all shards affecting alarm not to breach.
• ElastiCache for Redis default limits on Nodes per cluster still applies. So, when opting for Auto Scaling
and if you expect maximum nodes to be more than default limit, request a limit increase at AWS
Service Limits and choose the limit type Nodes per cluster per instance type.
• Ensure that you have enough ENIs (Elastic Network Interfaces) available in your VPC, which are
required during scale-out. For more information, see Elastic network interfaces.
• If there is not enough capacity available from EC2, ElastiCache for Redis Auto Scaling would not scale
would not scale out and be delayed til the capacity is available.
• ElastiCache for Redis Auto Scaling during scale-in will not remove shards with slots having an item size
larger than 256 MB post-serialization.
• During scale-in it will not remove shards if insufficient memory available on resultant shard
configuration.
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Redis.
3. Choose the cluster that you want to add a policy to.
4. Choose the Manage Auto Scaling policies from the Actions dropdown.
5. Choose the Auto Scaling policies tab.
6. In the Add Scaling policy dialog box, choose Dynamic scaling.
7. For Policy name enter a policy name.
8. For Scalable Dimension choose shards.
9. For the target metric, choose one of the following:
• Primary CPU Utilization to create a policy based on the average CPU utilization.
• Memory to create a policy based on the average database memory.
10. For the target value, choose one of the following:
• If you chose Primary CPU Utilization, type the percentage of CPU utilization that you want to
maintain on Elasticache shards. This value must be greater than or equal to 35 and less than or
equal to 70.
• If you chose Memory to create a policy based on the average database memory. type the
percentage of Redis memory that you want to maintain on ElastiCache for Redis shards. This value
must be greater than or equal to 35 and less than or equal to 70.
Cluster shards are added or removed to keep the metric close to the specified value.
11. (Optional) Scale-in or scale-out cooldown periods are not supported from the console. Use the AWS
CLI to modify the cooldown values.
12. For Minimum capacity, type the minimum number of shards that the ElastiCache for Redis Auto
Scaling policy is required to maintain.
13. For Maximum capacity, type the maximum number of shards that the ElastiCache for Redis Auto
Scaling policy is required to maintain. This value must be less than or equal to 250.
14. Choose Add policy.
To register your ElastiCache for Redis cluster, use the register-scalable-target command with the
following parameters:
Example
In the following example, you register an ElastiCache for Redis cluster named myscalablecluster. The
registration indicates that the cluster should be dynamically scaled to have from one to ten shards.
--min-capacity 1 \
--max-capacity 10 \
For Windows:
To register your Elasticache cluster, use the register-scalable-target command with the following
parameters:
Example
In the following example, you register an ElastiCache for Redis cluster named myscalablecluster with
the Application Auto Scaling API. This registration indicates that the cluster should be dynamically scaled
to have from one to 5 replicas.
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.RegisterScalableTarget
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:NodeGroups",
"MinCapacity": 1,
"MaxCapacity": 5
}
that text file when invoking the AWS CLI or the Application Auto Scaling API. For more information
about policy configuration syntax, see TargetTrackingScalingPolicyConfiguration in the Application Auto
Scaling API Reference.
The following options are available for defining a target-tracking scaling policy configuration:
Topics
• Using a predefined metric (p. 404)
• Using a custom metric (p. 404)
• Using cooldown periods (p. 405)
• Disabling scale-in activity (p. 405)
• Applying a scaling policy (p. 406)
Currently, ElastiCache for Redis supports the following predefined metrics in ElastiCache for Redis
NodeGroup Auto Scaling:
For more information about the EngineCPUUtilization and DatabaseMemory metrics, see
Monitoring use with CloudWatch Metrics (p. 587). To use a predefined metric in your scaling policy,
you create a target tracking configuration for your scaling policy. This configuration must include a
PredefinedMetricSpecification for the predefined metric and a TargetValue for the target
value of that metric.
Example
The following example describes a typical policy configuration for target-tracking scaling for an
ElastiCache for Redis cluster. In this configuration, the ElastiCachePrimaryEngineCPUUtilization
predefined metric is used to adjust the ElastiCache for Redis cluster based on an average CPU utilization
of 40 percent across all primary nodes in the cluster.
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
}
}
Example
The following example describes a target-tracking configuration for a scaling policy. In this configuration,
a custom metric adjusts an ElastiCache for Redis cluster based on an average CPU utilization of 50
percent across all shards in an cluster named my-db-cluster.
{
"TargetValue": 50,
"CustomizedMetricSpecification":
{
"MetricName": "EngineCPUUtilization",
"Namespace": "AWS/ElastiCache",
"Dimensions": [
{
"Name": "RelicationGroup","Value": "my-db-cluster"
},
{
"Name": "Role","Value": "PRIMARY"
}
],
"Statistic": "Average",
"Unit": "Percent"
}
}
The following example describes a target-tracking configuration for a scaling policy. In this configuration,
the ElastiCachePrimaryEngineCPUUtilization predefined metric is used to adjust an ElastiCache
for Redis cluster based on an average CPU utilization of 40 percent across all primary nodes in that
cluster. The configuration provides a scale-in cooldown period of 10 minutes and a scale-out cooldown
period of 5 minutes.
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
You can specify a Boolean value for DisableScaleIn to enable or disable scale in activity for your
cluster. For more information, see TargetTrackingScalingPolicyConfiguration in the Application Auto
Scaling API Reference.
The following example describes a target-tracking configuration for a scaling policy. In this configuration,
the ElastiCachePrimaryEngineCPUUtilization predefined metric adjusts an ElastiCache for Redis
cluster based on an average CPU utilization of 40 percent across all primary nodes in that cluster. The
configuration disables scale-in activity for the scaling policy.
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"DisableScaleIn": true
}
To apply a scaling policy to your ElastiCache for Redis cluster, use the put-scaling-policy command with
the following parameters:
In the following example, you apply a target-tracking scaling policy named myscalablepolicy to an
ElastiCache for Redis cluster named myscalablecluster with ElastiCache for Redis auto scaling. To do
so, you use a policy configuration saved in a file named config.json.
For Windows:
--target-tracking-scaling-policy-configuration file://config.json
To apply a scaling policy to your ElastiCache for Redis cluster, use the PutScalingPolicy AWS CLI
command with the following parameters:
In the following example, you apply a target-tracking scaling policy named myscalablepolicy to an
ElastiCache for Redis cluster named myscalablecluster with ElastiCache for Redis auto scaling. You
use a policy configuration based on the ElastiCachePrimaryEngineCPUUtilization predefined
metric.
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.PutScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:NodeGroups",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
}
}
}
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
• When using the AWS CLI, specify the name of the policy you want to edit in the --policy-name
parameter. Specify new values for the parameters you want to change.
• When using the Application Auto Scaling API, specify the name of the policy you want to edit in the
PolicyName parameter. Specify new values for the parameters you want to change.
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Redis.
3. Choose the cluster whose Auto Scaling policy you want to edit.
4. Choose the Auto Scaling policies tab.
5. In the Auto Scaling policies section, choose the Auto Scaling policy, and then choose Delete from
the Actions menu.
In the following example, you delete a target-tracking scaling policy named myscalablepolicy from
an ElastiCache for Redis cluster named myscalablecluster.
For Windows:
In the following example, you delete a target-tracking scaling policy named myscalablepolicy from
an ElastiCache for Redis cluster named myscalablecluster.
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.DeleteScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:NodeGroups"
}
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 3
MinCapacity: 1
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:NodeGroups'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-
service-role/elasticache.application-autoscaling.amazonaws.com/
AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScalingPolicy:
Type: "AWS::ApplicationAutoScaling::ScalingPolicy"
Properties:
ScalingTargetId: !Ref ScalingTarget
ServiceNamespace: elasticache
PolicyName: testpolicy
PolicyType: TargetTrackingScaling
ScalableDimension: 'elasticache:replication-group:NodeGroups'
TargetTrackingScalingPolicyConfiguration:
PredefinedMetricSpecification:
PredefinedMetricType: ElastiCachePrimaryEngineCPUUtilization
TargetValue: 20
Scheduled scaling
Scaling based on a schedule enables you to scale your application in response to predictable changes
in demand. To use scheduled scaling, you create scheduled actions, which tell ElastiCache for Redis to
perform scaling activities at specific times. When you create a scheduled action, you specify an existing
ElastiCache for Redis cluster, when the scaling activity should occur, minimum capacity, and maximum
capacity. You can create scheduled actions that scale one time only or that scale on a recurring schedule.
You can only create a scheduled action for ElastiCache for Redis clusters that already exist. You can't
create a scheduled action at the same time that you create a cluster.
For more information on terminology for scheduled action creation, management, and deletion, see
Commonly used commands for scheduled action creation, management, and deletion
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Redis.
3. Choose the cluster that you want to add a policy for.
4. Choose the Manage Auto Scaling policie from the Actions dropdown.
5. Choose the Auto Scaling policies tab.
6. In the Auto scaling policies section, the Add Scaling policy dialog box appears. Choose Scheduled
scaling.
7. For Policy Name, enter the policy name.
8. For Scalable Dimension, choose Shards.
9. For Target Shards, choose the value.
10. For Recurrence, choose Recurring.
11. For Frequency, choose the respective value.
12. For Start Date and Start time, choose the time from when the policy will go into effect.
13. Choose Add Policy.
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Redis.
3. Choose the cluster that you want to add a policy for.
4. Choose the Manage Auto Scaling policie from the Actions dropdown.
5. Choose the Auto Scaling policies tab.
6. In the Auto scaling policies section, the Add Scaling policy dialog box appears. Choose Scheduled
scaling.
7. For Policy Name, enter the policy name.
8. For Scalable Dimension, choose Shards.
9. For Target Shards, choose the value.
10. For Recurrence, choose One Time.
11. For Start Date and Start time, choose the time from when the policy will go into effect.
12. For End Date choose the date until when the policy would be in effect.
13. Choose Add Policy.
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Redis.
3. Choose the cluster that you want to add a policy for.
4. Choose the Manage Auto Scaling policie from the Actions dropdown.
5. Choose the Auto Scaling policies tab.
6. In the Auto scaling policies section, choose the auto scaling policy, and then choose Delete from
the Actions dialog.
• put-scheduled-action
• describe-scheduled-actions
• delete-scheduled-action
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 3
MinCapacity: 1
If your Target breaches by 30 percent, ElastiCache for Redis scales out by 1 replica (max(0.3, default 1))
across all shards. which results in 5 shards with 2 replicas each,
For a scale-in example, if you have selected Target value of 60 percent, ElastiCache for Redis won't auto
scale-in until the metric is less than or equal to 45 percent (25 percent below the Target 60 percent).
• A target tracking scaling policy assumes that it should perform scale out when the specified metric is
above the target value. You cannot use a target tracking scaling policy to scale out when the specified
metric is below the target value. ElastiCache for Redis scales out replicas by maximum of (% deviation
rounded off from Target, default 1) of existing replicas across all shards in the cluster.
• A target tracking scaling policy does not perform scaling when the specified metric has insufficient
data. It does not perform scale in because it does not interpret insufficient data as low utilization.
• You may see gaps between the target value and the actual metric data points. This is because
ElastiCache for Redis Auto Scaling always acts conservatively by rounding up or down when it
determines how much capacity to add or remove. This prevents it from adding insufficient capacity or
removing too much capacity.
• To ensure application availability, the service scales out proportionally to the metric as fast as it can,
but scales in more gradually with max scale in of 1 replica across the shards in the cluster.
• You can have multiple target tracking scaling policies for an ElastiCache for Redis cluster, provided
that each of them uses a different metric. The intention of ElastiCache for Redis Auto Scaling is to
always prioritize availability, so its behavior differs depending on whether the target tracking policies
are ready for scale out or scale in. It will scale out the service if any of the target tracking policies are
ready for scale out, but will scale in only if all of the target tracking policies (with the scale-in portion
enabled) are ready to scale in.
• Do not edit or delete the CloudWatch alarms that ElastiCache for Redis Auto Scaling manages for
a target tracking scaling policy. ElastiCache for Redis Auto Scaling deletes the alarms automatically
when you delete the scaling policy or deleting the cluster.
• ElastiCache for Redis Auto Scaling doesn't prevent you from manually modifying replicas across
shards. These manual adjustments don't affect any existing CloudWatch alarms that are attached to
the scaling policy but can impact metrics that may trigger these CloudWatch alarms.
• These CloudWatch alarms managed by Auto Scaling are defined over the AVG metric across all the
shards in the cluster. So, having hot shards can result in either scenario of:
• scaling when not required due to load on a few hot shards triggering a CloudWatch alarm
• not scaling when required due to aggregated AVG across all shards affecting alarm not to breach.
• ElastiCache for Redis default limits on Nodes per cluster still applies. So, when opting for Auto Scaling
and if you expect maximum nodes to be more than default limit, request a limit increase at AWS
Service Limits and choose the limit type Nodes per cluster per instance type.
• Ensure that you have enough ENIs (Elastic Network Interfaces) available in your VPC, which are
required during scale-out. For more information, see Elastic network interfaces.
• If there is not enough capacity available from EC2, ElastiCache for Redis Auto Scaling would not scale
out until the capacity is available or if you manually modify the cluster to the instance types that have
enough capacity.
• ElastiCache for Redis Auto Scaling doesn't support scaling of replicas with a cluster having
ReservedMemoryPercent less than 25 percent. For more information, see Managing Reserved
Memory.
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Redis.
3. Choose the ElastiCache for Redis cluster that you want to add a policy for.
4. Select the Manage Auto Scaling policies from Actions dropdown.
5. Choose the Auto Scaling policies tab.
6. In the Auto scaling policies section, the Add Scaling policy dialog box appears. Choose Dynamic
scaling.
Before you can use ElastiCache for Redis auto scaling with an ElastiCache for Redis cluster, you register
your cluster with ElastiCache for Redis auto scaling. You do so to define the scaling dimension and limits
to be applied to that cluster. ElastiCache for Redis auto scaling dynamically scales the ElastiCache for
Redis cluster along the elasticache:replication-group:Replicas scalable dimension, which
represents the number of cluster replicas per shard.
To register your Elasticache cluster, use the register-scalable-target command with the following
parameters:
Example
In the following example, you register an ElastiCache for Redis cluster named myscalablecluster. The
registration indicates that the cluster should be dynamically scaled to have from one to 5 replicas.
--min-capacity 1 \
--max-capacity 5 \
For Windows:
To register your Elasticache cluster, use the register-scalable-target command with the following
parameters:
Example
In the following example, you register an ElastiCache for Redis cluster named myscalablecluster with
the Application Auto Scaling API. This registration indicates that the cluster should be dynamically scaled
to have from one to 5 replicas.
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.RegisterScalableTarget
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:Replicas",
"MinCapacity": 1,
"MaxCapacity": 5
}
that text file when invoking the AWS CLI or the Application Auto Scaling API. For more information about
policy configuration syntax, see TargetTrackingScalingPolicyConfiguration in the Application Auto Scaling
API Reference.
The following options are available for defining a target-tracking scaling policy configuration:
Topics
• Using a predefined metric (p. 416)
• Using a custom metric (p. 416)
• Using cooldown periods (p. 417)
• Disabling scale-in activity (p. 417)
• Applying a scaling policy to an ElastiCache for Redis cluster (p. 417)
To use a predefined metric in your scaling policy, you create a target tracking configuration for
your scaling policy. This configuration must include a PredefinedMetricSpecification for the
predefined metric and a TargetValue for the target value of that metric.
Example
The following example describes a target-tracking configuration for a scaling policy. In this configuration,
a custom metric adjusts an ElastiCache for Redis cluster based on an average CPU utilization of 50
percent across all replicas in an cluster named my-db-cluster.
{"TargetValue": 50,
"CustomizedMetricSpecification":
{"MetricName": "EngineCPUUtilization",
"Namespace": "AWS/ElastiCache",
"Dimensions": [
{"Name": "RelicationGroup","Value": "my-db-cluster"},
{"Name": "Role","Value": "REPLICA"}
],
"Statistic": "Average",
"Unit": "Percent"
}
}
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
You can specify a Boolean value for DisableScaleIn to enable or disable scale in activity for your
cluster. For more information about DisableScaleIn, see TargetTrackingScalingPolicyConfiguration in
the Application Auto Scaling API Reference.
Example
The following example describes a target-tracking configuration for a scaling policy. In this configuration,
the ElastiCacheReplicaEngineCPUUtilization predefined metric adjusts an ElastiCache for
Redis cluster based on an average CPU utilization of 40 percent across all replicas in that cluster. The
configuration disables scale-in activity for the scaling policy.
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"DisableScaleIn": true
}
To apply a scaling policy to your ElastiCache for Redis cluster, use the put-scaling-policy command with
the following parameters:
• --resource-id – The resource identifier for the ElastiCache for Redis cluster. For this parameter, the
resource type is ReplicationGroup and the unique identifier is the name of the ElastiCache for Redis
cluster, for example replication-group/myscalablecluster.
• --service-namespace – Set this value to elasticache.
• --scalable-dimension – Set this value to elasticache:replication-group:Replicas.
• --target-tracking-scaling-policy-configuration – The target-tracking scaling policy configuration to use
for the ElastiCache for Redis cluster.
Example
In the following example, you apply a target-tracking scaling policy named myscalablepolicy to an
ElastiCache for Redis cluster named myscalablecluster with ElastiCache for Redis auto scaling. To do
so, you use a policy configuration saved in a file named config.json.
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"DisableScaleIn": true
}
For Windows:
To apply a scaling policy to your ElastiCache for Redis cluster with the Application Auto Scaling API, use
the PutScalingPolicy Application Auto Scaling API operation with the following parameters:
Example
In the following example, you apply a target-tracking scaling policy named scalablepolicy to an
ElastiCache for Redis cluster named myscalablecluster with ElastiCache for Redis auto scaling. You
use a policy configuration based on the ElastiCacheReplicaEngineCPUUtilization predefined
metric.
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.PutScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:Replicas",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
}
}
}
You can only edit policies with type Predefined metrics by using the AWS Management Console
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Redis
3. Choose the cluster whose auto scaling policy you want to edit.
4. Choose the Auto Scaling policies tab.
5. In the Auto scaling policies section, choose the auto scaling policy, and then choose Edit from the
Actions dialog box.
6. Make changes to the policy.
7. Choose Update policy.
Editing a scaling policy using the AWS CLI or the Application Auto Scaling API
You can use the AWS CLI or the Application Auto Scaling API to edit a scaling policy in the same way that
you apply a scaling policy:
• When using the Application Auto Scaling API, specify the name of the policy you want to edit in the
PolicyName parameter. Specify new values for the parameters you want to change.
For more information, see Applying a scaling policy to an ElastiCache for Redis cluster (p. 417).
You can only edit policies with type Predefined metrics by using the AWS Management Console
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Redis
3. Choose the cluster whose auto scaling policy you want to delete.
4. Choose the Auto Scaling policies tab.
5. In the Auto scaling policies section, choose the auto scaling policy, and then choose Delete from
the Actions dialog box.
Deleting a scaling policy using the AWS CLI or the Application Auto Scaling API
You can use the AWS CLI or the Application Auto Scaling API to delete a scaling policy from an
Elasticache cluster.
CLI
To delete a scaling policy from your ElastiCache for Redis cluster, use the delete-scaling-policy command
with the following parameters:
Example
In the following example, you delete a target-tracking scaling policy named myscalablepolicy from
an ELC; cluster named myscalablecluster.
For Windows:
API
To delete a scaling policy from your ElastiCache for Redis cluster, use the DeleteScalingPolicy Application
Auto Scaling API operation with the following parameters:
In the following example, you delete a target-tracking scaling policy named myscalablepolicy from
an ElastiCache for Redis cluster named myscalablecluster with the Application Auto Scaling API.
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.DeleteScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:Replicas"
}
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 0
MinCapacity: 0
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:Replicas'
ServiceNamespace: elasticache
ScalingPolicy:
Type: "AWS::ApplicationAutoScaling::ScalingPolicy"
Properties:
ScalingTargetId: !Ref ScalingTarget
ServiceNamespace: elasticache
PolicyName: testpolicy
PolicyType: TargetTrackingScaling
ScalableDimension: 'elasticache:replication-group:Replicas'
TargetTrackingScalingPolicyConfiguration:
PredefinedMetricSpecification:
PredefinedMetricType: ElastiCacheReplicaEngineCPUUtilization
TargetValue: 20
Scheduled scaling
Scaling based on a schedule enables you to scale your application in response to predictable changes
in demand. To use scheduled scaling, you create scheduled actions, which tell ElastiCache for Redis to
perform scaling activities at specific times. When you create a scheduled action, you specify an existing
ElastiCache for Redis cluster, when the scaling activity should occur, minimum capacity, and maximum
capacity. You can create scheduled actions that scale one time only or that scale on a recurring schedule.
You can only create a scheduled action for ElastiCache for Redis clusters that already exist. You can't
create a scheduled action at the same time that you create a cluster.
For more information on terminology for scheduled action creation, management, and deletion, see
Commonly used commands for scheduled action creation, management, and deletion
• put-scheduled-action
• describe-scheduled-actions
• delete-scheduled-action
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 0
MinCapacity: 0
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:Replicas'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-
service-role/elasticache.application-autoscaling.amazonaws.com/
AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScheduledActions:
- EndTime: '2020-12-31T12:00:00.000Z'
ScalableTargetAction:
MaxCapacity: '5'
MinCapacity: '2'
ScheduledActionName: First
Schedule: 'cron(0 18 * * ? *)'
As you would expect, some parameter values, such as maxmemory, are determined by the engine
and node type. For a table of these parameter values by node type, see Redis node-type specific
parameters (p. 465).
Topics
• Parameter management (p. 424)
• Cache parameter group tiers (p. 425)
• Creating a parameter group (p. 425)
• Listing parameter groups by name (p. 429)
• Listing a parameter group's values (p. 434)
• Modifying a parameter group (p. 435)
• Deleting a parameter group (p. 439)
• Redis-specific parameters (p. 441)
Parameter management
Parameters are grouped together into named parameter groups for easier parameter management. A
parameter group represents a combination of specific values for the parameters that are passed to the
engine software during startup. These values determine how the engine processes on each node behave
at runtime. The parameter values on a specific parameter group apply to all nodes that are associated
with the group, regardless of which cluster they belong to.
To fine-tune your cluster's performance, you can modify some parameter values or change the cluster's
parameter group.
• You cannot modify or delete the default parameter groups. If you need custom parameter values, you
must create a custom parameter group.
• The parameter group family and the cluster you're assigning it to must be compatible. For example,
if your cluster is running Redis version 3.2.10, you can only use parameter groups, default or custom,
from the Redis3.2 family.
• If you change a cluster's parameter group, the values for any conditionally modifiable parameter must
be the same in both the current and new parameter groups.
• When you change a cluster's parameters, the change is applied to the cluster either immediately or,
with the exceptions noted following, after the cluster nodes are rebooted. This is true whether you
change the cluster's parameter group itself or a parameter value within the cluster's parameter group.
To determine when a particular parameter change is applied, see the Changes Take Effect column in
the tables for Redis-specific parameters (p. 441).
If you have a Redis (cluster mode disabled) cluster and make changes to the following parameters, you
must reboot the nodes in the cluster:
• activerehashing
• databases
1. Create a manual backup of your cluster. See Making manual backups (p. 315).
2. Delete the Redis (cluster mode enabled) cluster. See Deleting a cluster (p. 165).
3. Restore the cluster using the altered parameter group and backup to seed the new
cluster. See Restoring from a backup with optional cluster resizing (p. 334).
You can check if a parameter group is part of a global datastore by looking in these locations:
• On the ElastiCache console on the Parameter Groups page, the yes/no Global attribute
• The yes/no IsGlobal property of the CacheParameterGroup API operation
Global Default
The top-level root parameter group for all Amazon ElastiCache customers in the region.
Customer Default
A copy of the Global Default cache parameter group which is created for the customer's use.
Customer Owned
A copy of the Customer Default cache parameter group. A Customer Owned cache parameter group is
created whenever the customer creates a cache parameter group.
Not all parameter values can be modified. For more information, see Redis-specific
parameters (p. 441).
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. To see a list of all available parameter groups, in the left hand navigation pane choose Parameter
Groups.
3. To create a parameter group, choose Create Parameter Group.
The parameter group family, such as redis3.2, defines the actual parameters in your parameter group
and their initial values. The parameter group family must coincide with the cluster's engine and
version.
5. In the Name box, type in a unique name for this parameter group.
When creating a cluster or modifying a cluster's parameter group, you will choose the parameter
group by its name. Therefore, we recommend that the name be informative and somehow identify
the parameter group's family.
To terminate the process without creating the parameter group, choose Cancel.
8. When the parameter group is created, it will have the family's default values. To change the default
values you must modify the parameter group. For more information, see Modifying a parameter
group (p. 435).
• --cache-parameter-group-family — The engine and version family for the parameter group.
• --description — A user supplied description for the parameter group.
Example
The following example creates a parameter group named myRed28 using the redis2.8 family as the
template.
For Windows:
The output from this command should look something like this.
{
"CacheParameterGroup": {
"CacheParameterGroupName": "myRed28",
"CacheParameterGroupFamily": "redis2.8",
"Description": "My first parameter group"
}
}
When the parameter group is created, it will have the family's default values. To change the default
values you must modify the parameter group. For more information, see Modifying a parameter
group (p. 435).
Example
The following example creates a parameter group named myRed28 using the redis2.8 family as the
template.
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheParameterGroup
&CacheParameterGroupFamily=redis2.8
&CacheParameterGroupName=myRed28
&Description=My%20first%20parameter%20group
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=<credential>
The response from this action should look something like this.
<CreateCacheParameterGroupResponse xmlns="http://elasticache.amazonaws.com/
doc/2013-06-15/">
<CreateCacheParameterGroupResult>
<CacheParameterGroup>
<CacheParameterGroupName>myRed28</CacheParameterGroupName>
<CacheParameterGroupFamily>redis2.8</CacheParameterGroupFamily>
<Description>My first parameter group</Description>
</CacheParameterGroup>
</CreateCacheParameterGroupResult>
<ResponseMetadata>
<RequestId>d8465952-af48-11e0-8d36-859edca6f4b8</RequestId>
</ResponseMetadata>
</CreateCacheParameterGroupResponse>
When the parameter group is created, it will have the family's default values. To change the default
values you must modify the parameter group. For more information, see Modifying a parameter
group (p. 435).
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. To see a list of all available parameter groups, in the left hand navigation pane choose Parameter
Groups.
Example
The following sample code lists the parameter group myRed28.
For Windows:
The output of this command will look something like this, listing the name, family, and description for
the parameter group.
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myRed28",
"CacheParameterGroupFamily": "redis2.8",
"Description": "My first parameter group"
}
]
}
Example
The following sample code lists the parameter group myRed56 for parameter groups running on Redis
engine version 5.0.6 onwards. If the parameter group is part of a Replication across AWS Regions using
global datastores (p. 231), the IsGlobal property value returned in the output will be Yes.
For Windows:
The output of this command will look something like this, listing the name, family, isGlobal and
description for the parameter group.
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myRed56",
"CacheParameterGroupFamily": "redis5.0",
"Description": "My first parameter group",
"IsGlobal": "yes"
}
]
}
Example
The JSON output of this command will look something like this, listing the name, family, description
and, in the case of redis5.6 whether the parameter group is part of a global datastore (isGlobal), for each
parameter group.
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "custom-redis32",
"CacheParameterGroupFamily": "redis3.2",
"Description": "custom parameter group with reserved-memory > 0"
},
{
"CacheParameterGroupName": "default.memcached1.4",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "Default parameter group for memcached1.4"
},
{
"CacheParameterGroupName": "default.redis2.6",
"CacheParameterGroupFamily": "redis2.6",
"Description": "Default parameter group for redis2.6"
},
{
"CacheParameterGroupName": "default.redis2.8",
"CacheParameterGroupFamily": "redis2.8",
"Description": "Default parameter group for redis2.8"
},
{
"CacheParameterGroupName": "default.redis3.2",
"CacheParameterGroupFamily": "redis3.2",
"Description": "Default parameter group for redis3.2"
},
{
"CacheParameterGroupName": "default.redis3.2.cluster.on",
"CacheParameterGroupFamily": "redis3.2",
"Description": "Customized default parameter group for redis3.2 with cluster
mode on"
},
{
"CacheParameterGroupName": "default.redis5.6.cluster.on",
"CacheParameterGroupFamily": "redis5.0",
"Description": "Customized default parameter group for redis5.6 with cluster
mode on",
"isGlobal": "yes"
},
]
}
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&MaxRecords=10
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=<credential>
The response from this action will look something like this, listing the name, family, description and, in
the case of redis5.6 if the parameter group belongs to a global datastore (isGlobal), for each parameter
group.
<DescribeCacheParameterGroupsResponse xmlns="http://elasticache.amazonaws.com/
doc/2013-06-15/">
<DescribeCacheParameterGroupsResult>
<CacheParameterGroups>
<CacheParameterGroup>
<CacheParameterGroupName>myRedis28</CacheParameterGroupName>
<CacheParameterGroupFamily>redis2.8</CacheParameterGroupFamily>
<Description>My custom Redis 2.8 parameter group</Description>
</CacheParameterGroup>
<CacheParameterGroup>
<CacheParameterGroupName>myMem14</CacheParameterGroupName>
<CacheParameterGroupFamily>memcached1.4</CacheParameterGroupFamily>
<Description>My custom Memcached 1.4 parameter group</Description>
</CacheParameterGroup>
<CacheParameterGroup>
<CacheParameterGroupName>myRedis56</CacheParameterGroupName>
<CacheParameterGroupFamily>redis5.0</CacheParameterGroupFamily>
<Description>My custom redis 5.6 parameter group</Description>
<isGlobal>yes</isGlobal>
</CacheParameterGroup>
</CacheParameterGroups>
</DescribeCacheParameterGroupsResult>
<ResponseMetadata>
<RequestId>3540cc3d-af48-11e0-97f9-279771c4477e</RequestId>
</ResponseMetadata>
</DescribeCacheParameterGroupsResponse>
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=<credential>
The response from this action will look something like this, listing the name, family, and description.
<DescribeCacheParameterGroupsResponse xmlns="http://elasticache.amazonaws.com/
doc/2013-06-15/">
<DescribeCacheParameterGroupsResult>
<CacheParameterGroups>
<CacheParameterGroup>
<CacheParameterGroupName>myRed28</CacheParameterGroupName>
<CacheParameterGroupFamily>redis2.8</CacheParameterGroupFamily>
<Description>My custom Redis 2.8 parameter group</Description>
</CacheParameterGroup>
</CacheParameterGroups>
</DescribeCacheParameterGroupsResult>
<ResponseMetadata>
<RequestId>3540cc3d-af48-11e0-97f9-279771c4477e</RequestId>
</ResponseMetadata>
</DescribeCacheParameterGroupsResponse>
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myRed56
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=<credential>
The response from this action will look something like this, listing the name, family, description and
whether the parameter group is part of a global datastore (isGlobal).
<DescribeCacheParameterGroupsResponse xmlns="http://elasticache.amazonaws.com/
doc/2013-06-15/">
<DescribeCacheParameterGroupsResult>
<CacheParameterGroups>
<CacheParameterGroup>
<CacheParameterGroupName>myRed56</CacheParameterGroupName>
<CacheParameterGroupFamily>redis5.0</CacheParameterGroupFamily>
<Description>My custom Redis 5.6 parameter group</Description>
<isGlobal>yes</isGlobal>
</CacheParameterGroup>
</CacheParameterGroups>
</DescribeCacheParameterGroupsResult>
<ResponseMetadata>
<RequestId>3540cc3d-af48-11e0-97f9-279771c4477e</RequestId>
</ResponseMetadata>
</DescribeCacheParameterGroupsResponse>
To list a parameter group's parameters and their values using the ElastiCache console
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. To see a list of all available parameter groups, in the left hand navigation pane choose Parameter
Groups.
3. Choose the parameter group for which you want to list the parameters and values by choosing the
box to the left of the parameter group's name.
The parameters and their values will be listed at the bottom of the screen. Due to the number of
parameters, you may have to scroll up and down to find the parameter you're interested in.
Example
The following sample code list all the parameters and their values for the parameter group myRedis28.
For Windows:
Example
The following sample code list all the parameters for the parameter group myRed28.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameters
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=<credential>
The response from this action will look something like this. This response has been truncated.
<DescribeCacheParametersResponse xmlns="http://elasticache.amazonaws.com/doc/2013-06-15/">
<DescribeCacheParametersResult>
<CacheClusterClassSpecificParameters>
<CacheNodeTypeSpecificParameter>
<DataType>integer</DataType>
<Source>system</Source>
<IsModifiable>false</IsModifiable>
<Description>The maximum configurable amount of memory to use to store items, in
megabytes.</Description>
<CacheNodeTypeSpecificValues>
<CacheNodeTypeSpecificValue>
<Value>1000</Value>
<CacheClusterClass>cache.c1.medium</CacheClusterClass>
</CacheNodeTypeSpecificValue>
<CacheNodeTypeSpecificValue>
<Value>6000</Value>
<CacheClusterClass>cache.c1.xlarge</CacheClusterClass>
</CacheNodeTypeSpecificValue>
<CacheNodeTypeSpecificValue>
<Value>7100</Value>
<CacheClusterClass>cache.m1.large</CacheClusterClass>
</CacheNodeTypeSpecificValue>
<CacheNodeTypeSpecificValue>
<Value>1300</Value>
<CacheClusterClass>cache.m1.small</CacheClusterClass>
</CacheNodeTypeSpecificValue>
...output omitted...
</CacheClusterClassSpecificParameters>
</DescribeCacheParametersResult>
<ResponseMetadata>
<RequestId>6d355589-af49-11e0-97f9-279771c4477e</RequestId>
</ResponseMetadata>
</DescribeCacheParametersResponse>
You can modify some parameter values in a parameter group. These parameter values are applied to
clusters associated with the parameter group. For more information on when a parameter value change
is applied to a parameter group, see Redis-specific parameters (p. 441).
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. To see a list of all available parameter groups, in the left hand navigation pane choose Parameter
Groups.
3. Choose the parameter group you want to modify by choosing the box to the left of the parameter
group's name.
The parameter group's parameters will be listed at the bottom of the screen. You may need to page
through the list to see all the parameters.
4. To modify one or more parameters, choose Edit Parameters.
5. Choose Save Changes.
6. To find the name of the parameter you changed, see Redis-specific parameters (p. 441). If you have
a Redis (cluster mode disabled) cluster and make changes to the following parameters, you must
reboot the nodes in the cluster:
• activerehashing
• databases
• activerehashing
• databases
1. Create a manual backup of your cluster. See Making manual backups (p. 315).
2. Delete the Redis (cluster mode enabled) cluster. See Deleting a cluster (p. 165).
3. Restore the cluster using the altered parameter group and backup to seed the new
cluster. See Restoring from a backup with optional cluster resizing (p. 334).
Example
To find the name and permitted values of the parameter you want to change, see Redis-specific
parameters (p. 441)
The following sample code sets the value of two parameters, reserved-memory-percent and cluster-
enabled on the parameter group myredis32-on-30. We set reserved-memory-percent to 30 (30 percent)
and cluster-enabled to yes so that the parameter group can be used with Redis (cluster mode enabled)
clusters (replication groups).
For Windows:
{
"CacheParameterGroupName": "my-redis32-on-30"
}
To find the name of the parameter you changed, see Redis-specific parameters (p. 441).
If you have a Redis (cluster mode disabled) cluster and make changes to the following parameters, you
must reboot the nodes in the cluster:
• activerehashing
• databases
• activerehashing
• databases
1. Create a manual backup of your cluster. See Making manual backups (p. 315).
2. Delete the Redis (cluster mode enabled) cluster. See Deleting a cluster (p. 165).
3. Restore the cluster using the altered parameter group and backup to seed the new cluster.
See Restoring from a backup with optional cluster resizing (p. 334).
Example
To find the name and permitted values of the parameter you want to change, see Redis-specific
parameters (p. 441)
The following sample code sets the value of two parameters, reserved-memory-percent and cluster-
enabled on the parameter group myredis32-on-30. We set reserved-memory-percent to 30 (30 percent)
and cluster-enabled to yes so that the parameter group can be used with Redis (cluster mode enabled)
clusters (replication groups).
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheParameterGroup
&CacheParameterGroupName=myredis32-on-30
&ParameterNameValues.member.1.ParameterName=reserved-memory-percent
&ParameterNameValues.member.1.ParameterValue=30
&ParameterNameValues.member.2.ParameterName=cluster-enabled
&ParameterNameValues.member.2.ParameterValue=yes
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=<credential>
If you have a Redis (cluster mode disabled) cluster and make changes to the following parameters, you
must reboot the nodes in the cluster:
• activerehashing
• databases
• activerehashing
• databases
1. Create a manual backup of your cluster. See Making manual backups (p. 315).
2. Delete the Redis (cluster mode enabled) cluster. See Deleting a cluster (p. 165).
3. Restore the cluster using the altered parameter group and backup to seed the new cluster.
See Restoring from a backup with optional cluster resizing (p. 334).
You cannot delete a parameter group if it is associated with any clusters. Nor can you delete any of the
default parameter groups.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. To see a list of all available parameter groups, in the left hand navigation pane choose Parameter
Groups.
3. Choose the parameter groups you want to delete by choosing the box to the left of the parameter
group's name.
Example
For Windows:
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteCacheParameterGroup
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=<credential>
Redis-specific parameters
If you do not specify a parameter group for your Redis cluster, then a default parameter group
appropriate to your engine version will be used. You can't change the values of any parameters in the
default parameter group. However, you can create a custom parameter group and assign it to your
cluster at any time as long as the values of conditionally modifiable parameters are the same in both
parameter groups. For more information, see Creating a parameter group (p. 425).
Topics
• Redis 6.x parameter changes (p. 442)
• Redis 5.0.3 parameter changes (p. 444)
• Redis 5.0.0 parameter changes (p. 445)
• Redis 4.0.10 parameter changes (p. 448)
• Redis 3.2.10 parameter changes (p. 451)
• Redis 3.2.6 parameter changes (p. 451)
• Redis 3.2.4 parameter changes (p. 451)
• Redis 2.8.24 (enhanced) added parameters (p. 455)
• Redis 2.8.23 (enhanced) added parameters (p. 455)
• Redis 2.8.22 (enhanced) added parameters (p. 456)
• Redis 2.8.21 added parameters (p. 457)
• Redis 2.8.19 added parameters (p. 457)
• Redis 2.8.6 added parameters (p. 457)
• Redis 2.6.13 parameters (p. 459)
• Redis node-type specific parameters (p. 465)
Note
Because the newer Redis versions provide a better and more stable user experience, Redis
versions 5.0.0, 5.0.3, 5.0.4 and 5.0.5 as well as 2.6.13, 2.8.6, and 2.8.19 are deprecated when
using the ElastiCache console. We recommend against using these Redis versions. If you need to
use one of them, work with the AWS CLI or ElastiCache API.
For more information, see the following topics:
You can't use this action to You can't use this action to
create a replication group create a replication group
with cluster mode enabled. with cluster mode enabled.
Modify Cluster Using the AWS CLI (p. 150) Using the ElastiCache
API (p. 151)
You can't use this action to
create a replication group You can't use this action to
with cluster mode enabled. create a replication group
with cluster mode enabled.
Modify Replication Group Using the AWS CLI (p. 294) Using the ElastiCache
API (p. 295)
• default.redis6.x – Use this parameter group, or one derived from it, for Redis (cluster mode
disabled) clusters and replication groups.
• default.redis6.x.cluster.on – Use this parameter group, or one derived from it, for Redis
(cluster mode enabled) clusters and replication groups.
Note
In Redis engine version 6.2, when the r6gd node family was introduced for use with Data
tiering (p. 121), only noeviction, volatile-lru and allkeys-lru max-memory policies are supported
with r6gd node types.
For more information, see ElastiCache for Redis version 6.2 (enhanced) (p. 190) and ElastiCache for Redis
version 6.0 (enhanced) (p. 190).
acl-pubsub- Permitted values: Default pubsub channel permissions for ACL users
default resetchannels, allchannels deployed to this cluster.
(added in
6.2) Default: allchannels
Type: string
Modifiable: Yes
Modifiable: Yes
lazyfree- Default: no When the value is set to yes, the DEL command
lazy-user- acts the same as UNLINK.
del (added Type: string
in 6.0)
Modifiable: Yes
lua- Permitted values: yes/no Always enable Lua effect replication or not in Lua
replicate- scripts
commands Default: yes
Type: boolean
Modifiable: Yes
• default.redis5.0 – Use this parameter group, or one derived from it, for Redis (cluster mode
disabled) clusters and replication groups.
• default.redis5.0.cluster.on – Use this parameter group, or one derived from it, for Redis
(cluster mode enabled) clusters and replication groups.
For more information, see ElastiCache for Redis version 5.0.3 (enhanced) (p. 191).
• default.redis5.0 – Use this parameter group, or one derived from it, for Redis (cluster mode
disabled) clusters and replication groups.
• default.redis5.0.cluster.on – Use this parameter group, or one derived from it, for Redis
(cluster mode enabled) clusters and replication groups.
stream- Permitted values: 0+ The stream data structure is a radix tree of nodes
node-max- that encode multiple items inside. Use this
bytes Default: 4096 configuration to specify the maximum size of a
single node in radix tree in Bytes. If set to 0, the
Type: integer size of the tree node is unlimited.
Modifiable: Yes
stream- Permitted values: 0+ The stream data structure is a radix tree of nodes
node-max- that encode multiple items inside. Use this
entries Default: 100 configuration to specify the maximum number of
items a single node can contain before switching
Type: integer to a new node when appending new stream
entries. If set to 0, the number of items in the tree
Modifiable: Yes
node is unlimited
Type: integer
Modifiable: Yes
lua- Permitted values: yes/no Always enable Lua effect replication or not in Lua
replicate- scripts
commands Default: yes
Type: boolean
Modifiable: Yes
Redis has renamed several parameters in engine version 5.0 in response to community feedback. For
more information, see What's New in Redis 5?. The following table lists the new names and how they
map to previous versions.
Modifiable: No
client- Default: For values see For Redis read replicas: If a client's output buffer
output- Redis node-type specific reaches the specified number of bytes, the client
buffer- parameters (p. 465) will be disconnected.
limit-
replica- Type: integer
hard-limit
Modifiable: No
client- Default: For values see For Redis read replicas: If a client's output buffer
output- Redis node-type specific reaches the specified number of bytes, the client
buffer- parameters (p. 465) will be disconnected, but only if this condition
limit- persists for client-output-buffer-limit-
replica- Type: integer replica-soft-seconds.
soft-limit
Modifiable: No
Modifiable: No
Modifiable: Yes
Changes Take Effect: Immediately
• default.redis4.0 – Use this parameter group, or one derived from it, for Redis (cluster mode
disabled) clusters and replication groups.
• default.redis4.0.cluster.on – Use this parameter group, or one derived from it, for Redis
(cluster mode enabled) clusters and replication groups.
Type: boolean
Modifiable: Yes
Type: boolean
Modifiable: Yes
Modifiable: Yes
Type: boolean
Modifiable: No
LFU parameters
Modifiable: Yes
Type: integer
Modifiable: Yes
Default: no
Type: boolean
Modifiable: Yes
active-defrag-ignore- Permitted values: 10485760-104857600
Minimum amount of
bytes fragmentation waste to start
Default: 104857600 active defrag.
Type: integer
Modifiable: Yes
Modifiable: Yes
Modifiable: Yes
Type: integer
Modifiable: Yes
Type: integer
Modifiable: Yes
client-query-buffer-limit Permitted values: 1048576-1073741824
Max size of a single client query
buffer.
Default: 1073741824
Type: integer
Modifiable: Yes
proto-max-bulk-len Permitted values: 1048576-536870912
Max size of a single element
request.
Default: 536870912
Type: integer
Modifiable: Yes
Beginning with Redis 3.2.4 there are two default parameter groups.
• default.redis3.2 – When running Redis 3.2.4, specify this parameter group or one derived from
it, if you want to create a Redis (cluster mode disabled) replication group and still use the additional
features of Redis 3.2.4.
• default.redis3.2.cluster.on – Specify this parameter group or one derived from it, when you
want to create a Redis (cluster mode enabled) replication group.
Topics
• New parameters for Redis 3.2.4 (p. 452)
• Parameters changed in Redis 3.2.4 (enhanced) (p. 454)
[head]->node->node->...->node->[tail]
[head]->[next]->node->node->...->node-
>[prev]->[tail]
Modifiable: Yes
Changes Take Effect: Immediately
If the read-replica cluster is promoted to primary for any reason other than a Multi-AZ enabled
replication group failing over, the client will continue trying to write to endpoint A. Because endpoint
A is now the endpoint for a read-replica, these writes will fail. This is the behavior for Redis before
ElastiCache introducing close-on-replica-write and the behavior if you disable close-on-
replica-write.
With close-on-replica-write enabled, any time a client attempts to write to a read-replica, the
client connection to the cluster is closed. Your application logic should detect the disconnection, check
the DNS table, and reconnect to the primary endpoint, which now would be endpoint B.
As previously mentioned, with close-on-replica-write enabled, any time a client attempts to write
to a read-replica the client connection to the cluster is closed. Establishing a new connection to the
node takes time. Thus, disconnecting and reconnecting as a result of a write request to the replica also
affects the latency of read requests that are served through the same connection. This effect remains in
place until a new connection is established. If your application is especially read-heavy or very latency-
sensitive, you might keep your clients connected to avoid degrading read performance.
• Beginning with Redis version 2.8.22, repl-backlog-size applies to the primary cluster as
well as to replica clusters.
• Beginning with Redis version 2.8.22, the repl-timeout parameter is not supported. If it is
changed, ElastiCache will overwrite with the default (60s), as we do with appendonly.
• appendonly
• appendfsync
• repl-timeout
Redis 2.6.13 was the first version of Redis supported by ElastiCache. The following table shows the Redis
2.6.13 parameters that ElastiCache supports.
Default: yes
activerehashing Determines whether to enable Redis' active
rehashing feature. The main hash table is
Type: string (yes/no) rehashed ten times per second; each rehash
operation consumes 1 millisecond of CPU time.
Modifiable: Yes
This value is set when you create the parameter
Changes take place: At Creation group. When assigning a new parameter group to
a cluster, this value must be the same in both the
old and new parameter groups.
client- Default: For values see For Redis read replicas: If a client's output buffer
output- Redis node-type specific reaches the specified number of bytes, the client
buffer- parameters (p. 465) will be disconnected.
limit-
slave-hard- Type: integer
limit
Modifiable: No
client- Default: For values see For Redis read replicas: If a client's output buffer
output- Redis node-type specific reaches the specified number of bytes, the client
buffer- parameters (p. 465) will be disconnected, but only if this condition
limit- persists for client-output-buffer-limit-
slave-soft- Type: integer slave-soft-seconds.
limit
Modifiable: No
Changes Take Effect: Immediately
Changes Take Effect: Immediately
list-max- Default: 512 Determines the amount of memory used for lists.
ziplist- Lists with fewer than the specified number of
entries Type: integer entries are stored using a special encoding that
saves space.
Modifiable: Yes
Changes Take Effect: Immediately
Changes Take Effect: Immediately
lua-time- Default: 5000 The maximum execution time for a Lua script, in
limit milliseconds, before ElastiCache takes action to
Type: integer stop the script.
Modifiable: No If lua-time-limit is exceeded, all Redis
commands will return an error of the form ____-
BUSY. Since this state can cause interference with
many essential Redis operations, ElastiCache
will first issue a SCRIPT KILL command. If this
is unsuccessful, ElastiCache will forcibly restart
Redis.
Modifiable: No
Type: integer
Modifiable: No
Type: integer
Modifiable: No
Type: integer
Modifiable: No
Type: integer
Modifiable: No
Type: integer
Modifiable: No
Type: integer
Modifiable: No
maxmemory- Default: volatile-lru The eviction policy for keys when maximum
policy memory usage is reached.
Type: string
Valid values are: volatile-lru | allkeys-
Modifiable: Yes lru | volatile-random | allkeys-random
| volatile-ttl | noeviction
Changes Take Effect: Immediately
For more information, see Using Redis as an LRU
cache.
Modifiable: No
Changes Take Effect: Immediately
slowlog- Default: 128 The maximum length of the Redis Slow Log.
max-len
Type: integer
Modifiable: Yes
Changes Take Effect: Immediately
Changes Take Effect: Immediately
Changes Take Effect: Immediately
Note
If you do not specify a parameter group for your Redis 2.6.13 cluster, then a default parameter
group (default.redis2.6) will be used. You cannot change the values of any parameters in
the default parameter group; however, you can always create a custom parameter group and
assign it to your cluster at any time.
Note
All current generation instance types are created in an Amazon Virtual Private Cloud VPC by
default.
T1 instances do not support Multi-AZ.
T1 and T2 instances do not support Redis AOF.
Redis configuration variables appendonly and appendfsync are not supported on Redis
version 2.8.22 and later.
Security is a shared responsibility between AWS and you. The shared responsibility model describes this
as security of the cloud and security in the cloud:
• Security of the cloud – AWS is responsible for protecting the infrastructure that runs AWS services in
the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors
regularly test and verify the effectiveness of our security as part of the AWS compliance programs. To
learn about the compliance programs that apply to Amazon ElastiCache, see AWS Services in Scope by
Compliance Program.
• Security in the cloud – Your responsibility is determined by the AWS service that you use. You are also
responsible for other factors including the sensitivity of your data, your company’s requirements, and
applicable laws and regulations.
This documentation helps you understand how to apply the shared responsibility model when using
Amazon ElastiCache. The following topics show you how to configure Amazon ElastiCache to meet
your security and compliance objectives. You also learn how to use other AWS services that help you to
monitor and secure your Amazon ElastiCache resources.
Topics
• Data protection in Amazon ElastiCache (p. 469)
• Internetwork traffic privacy (p. 501)
• Identity and access management in Amazon ElastiCache (p. 538)
• Logging and monitoring in Elasticache (p. 577)
• Compliance validation for Amazon ElastiCache (p. 617)
• Resilience in Amazon ElastiCache (p. 621)
• Infrastructure security in AWS Elasticache (p. 624)
• Self-service updates in Amazon ElastiCache (p. 625)
• Troubleshooting (p. 634)
For data protection purposes, we recommend that you protect AWS account credentials and set up
individual user accounts with AWS Identity and Access Management (IAM). That way each user is given
only the permissions necessary to fulfill their job duties. We also recommend that you secure your data
in the following ways:
• Use advanced managed security services such as Amazon Macie, which assists in discovering and
securing personal data that is stored in Amazon S3.
We strongly recommend that you never put sensitive identifying information, such as your customers'
account numbers, into free-form fields such as a Name field. This includes when you work with
Elasticache or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter
into Elasticache or other services might get picked up for inclusion in diagnostic logs. When you provide
a URL to an external server, don't include credentials information in the URL to validate your request to
that server.
Topics
• Data security in Amazon ElastiCache (p. 470)
Amazon ElastiCache for Redis also provides optional encryption features for data on clusters running
Redis versions 3.2.6, 4.0.10 or later:
• In-transit encryption encrypts your data whenever it is moving from one place to another, such as
between nodes in your cluster or between your cluster and your application.
• At-rest encryption encrypts your on-disk data during sync and backup operations.
If you want to enable in-transit or at-rest encryption, you must meet the following conditions.
• Your cluster or replication group must be running Redis 3.2.6, 4.0.10 or later.
• Your cluster or replication group must be created in a VPC based on Amazon VPC.
• Optionally, you can also use AUTH and the AUTH token (password) needed to perform operations on
this cluster or replication group.
Topics
• ElastiCache for Redis in-transit encryption (TLS) (p. 471)
• At-Rest Encryption in ElastiCache for Redis (p. 483)
• Authenticating users with Role-Based Access Control (RBAC) (p. 490)
In-transit encryption is optional and can only be enabled on Redis replication groups when they
are created. You enable in-transit encryption on a replication group by setting the parameter
TransitEncryptionEnabled to true (CLI: --transit-encryption-enabled) when you create
the replication group. You can do this whether you are creating the replication group using the AWS
Management Console, the AWS CLI, or the ElastiCache API. If you enable in-transit encryption, you must
also provide a value for CacheSubnetGroup.
Important
The parameters TransitEncryptionEnabled (CLI: --transit-encryption-enabled)
are only available when using the CreateReplicationGroup (CLI: create-replication-
group) operation.
Topics
• In-transit encryption overview (p. 471)
• In-transit encryption conditions (p. 472)
• Enabling in-transit encryption (p. 472)
• Connecting to Amazon ElastiCache for Redis nodes enabled with in-transit encryption using redis-
cli (p. 475)
• See also (p. 478)
• Authenticating users with the Redis AUTH command (p. 478)
• Encrypted connections—both the server and client connections are Secure Socket Layer (SSL)
encrypted.
• Encrypted replication—data moving between a primary node and replica nodes is encrypted.
• Server authentication—clients can authenticate that they are connecting to the right server.
• Client authentication—using the Redis AUTH feature, the server can authenticate the clients.
• In-transit encryption is supported on replication groups running Redis versions 3.2.6, 4.0.10 and later.
• In-transit encryption is supported only for replication groups running in an Amazon VPC.
• In-transit encryption is only supported for replication groups running the following node types.
• R6g, R5, R4, R3
• M6g, M5, M4, M3
• T4g, T3, T2
Because of the processing required to encrypt and decrypt the data at the endpoints, implementing in-
transit encryption can reduce performance. Benchmark in-transit encryption compared to no encryption
on your own data to determine its impact on performance for your implementation.
Tip
Because creating new connections can be expensive, you can reduce the performance impact of
in-transit encryption by persisting your SSL connections.
You can only enable in-transit encryption when you create a Redis replication group. If you have an
existing replication group on which you want to enable in-transit encryption, do the following.
1. Create a manual backup of the replication group. For more information, see Making manual
backups (p. 315).
2. Create a new replication group by restoring from the backup setting the engine version to 3.2.6,
4.0.10 and later, and the parameter TransitEncryptionEnabled to true (CLI: --transit-
encryption-enabled). For more information, see Restoring from a backup with optional cluster
resizing (p. 334).
3. Update the endpoints in your application to the new replication group's endpoints. For more
information, see Finding connection endpoints (p. 175).
4. Delete the old replication group. For more information, see the following:
To enable in-transit encryption when creating a replication group using the AWS Management Console,
make the following selections:
To enable in-transit encryption when creating a Redis replication group using the AWS CLI, use the
parameter transit-encryption-enabled.
Use the AWS CLI operation create-replication-group and the following parameters to create a
Redis replication group with replicas that has in-transit encryption enabled:
Key parameters:
• --engine—Must be redis.
• --engine-version—Must be 3.2.6, 4.0.10 or later.
• --transit-encryption-enabled—Required. If you enable in-transit encryption you must also
provide a value for the --cache-subnet-group parameter.
• --num-cache-clusters—Must be at least 1. The maximum value for this parameter is six.
• Creating a Redis (Cluster Mode Disabled) replication group from scratch (AWS CLI) (p. 273)
• create-replication-group
Enabling in-transit encryption on a cluster for Redis (Cluster Mode Enabled) (CLI)
Use the AWS CLI operation create-replication-group and the following parameters to create a
Redis (cluster mode enabled) replication group that has in-transit encryption enabled:
Key parameters:
• --engine—Must be redis.
• --engine-version—Must be 3.2.6, 4.0.10 or later.
• Creating a Redis (Cluster Mode Enabled) replication group from scratch (AWS CLI) (p. 280)
• create-replication-group
Enabling in-transit encryption on a cluster for Redis (Cluster Mode Disabled) (API)
Use the ElastiCache API operation CreateReplicationGroup and the following parameters to create a
Redis (cluster mode disabled) replication group that has in-transit encryption enabled:
Key parameters
• Engine—Must be redis.
• EngineVersion—Must be 3.2.6, 4.0.10 or later.
• TransitEncryptionEnabled—Must set to true.
When TransitEncryptionEnabled is set to true, you must also provide a value for
CacheSubnetGroup.
• NumCacheClusters—Must be at least 1. The maximum value for this parameter is six.
• Creating a Redis (cluster mode disabled) replication group from scratch (ElastiCache API) (p. 276)
• CreateReplicationGroup
Enabling in-transit encryption on a cluster for Redis (Cluster Mode Enabled) (API)
Use the ElastiCache API operation CreateReplicationGroup and the following parameters to create a
Redis (cluster mode enabled) replication group that has in-transit encryption enabled:
Key parameters
• Engine—Must be redis.
• EngineVersion—Must be 3.2.6, 4.0.10 or later.
When TransitEncryptionEnabled is set to true, you must also provide a value for
CacheSubnetGroup.
• Use one of the following parameter sets to specify the configuration of the replication group's node
groups:
• NumNodeGroups—Specifies the number of shards (node groups) in this replication group. The
maximum value of this parameter is 500 but can be increased to a maximum of 250 by a service
limit increase request. For more information, see AWS service limits.
ReplicasPerNodeGroup—Specifies the number of replica nodes in each node group. The value
specified here is applied to all shards in this replication group. The maximum value of this parameter
is 5.
• NodeGroupConfiguration—Specifies the configuration of each shard independently.
• Creating a replication group in Redis (Cluster Mode Enabled) from scratch (ElastiCache API) (p. 285)
• CreateReplicationGroup
To access data from ElastiCache for Redis nodes enabled with in-transit encryption, you use clients
that work with Secure Socket Layer (SSL). You can also use redis-cli with TLS/SSL on Amazon linux and
Amazon Linux 2.
To use redis-cli to connect to a Redis cluster enabled with in-transit encryption on Amazon
Linux 2 or Amazon Linux
1. Download and compile the redis-cli utility. This utility is included in the Redis software distribution.
2. At the command prompt of your EC2 instance, type the following commands:
Amazon Linux 2
Amazon Linux
sudo yum install gcc jemalloc-devel openssl-devel tcl tcl-devel clang wget
wget http://download.redis.io/redis-stable.tar.gz
tar xvzf redis-stable.tar.gz
cd redis-stable
make redis-cli CC=clang BUILD_TLS=yes
sudo install -m 755 src/redis-cli /usr/local/bin/
On Amazon Linux, you may also need to run the following additional steps:
API Version 2015-02-02
475
Amazon ElastiCache for Redis User Guide
Data security in Amazon ElastiCache
3. After this, it is recommended that you run the optional make-test command.
4. At the command prompt of your EC2 instance, type the following command, substituting the
endpoint of your cluster and port for what is shown in this example.
For more information on finding the endpoint, see Find your Node Endpoints.
The following example connects to a cluster with encryption and authentication enabled:
To work around this, you can use the stunnel command to create an SSL tunnel to the redis nodes. You
then use redis-cli to connect to the tunnel to access data from encrypted Redis nodes.
To use redis-cli to connect to a Redis cluster enabled with in-transit encryption using stunnel
vi /etc/stunnel/redis-cli.conf
fips = no
setuid = root
setgid = root
pid = /var/run/stunnel.pid
debug = 7
delay = yes
options = NO_SSLv2
options = NO_SSLv3
[redis-cli]
client = yes
accept = 127.0.0.1:6379
connect = primary.ssltest.wif01h.use1.cache.amazonaws.com:6379
[redis-cli-replica]
client = yes
accept = 127.0.0.1:6380
connect = ssltest-02.ssltest.wif01h.use1.cache.amazonaws.com:6379
In this example, the config file has two connections, the redis-cli and the redis-cli-replica.
The parameters are set as follows:
• connect is set to the Redis server endpoint. For more information, see Finding connection
endpoints (p. 175).
3. Start stunnel.
4. Connect to the encrypted Redis node using the local endpoint of the tunnel.
• If no AUTH password was used during ElastiCache for Redis cluster creation, this example uses
the redis-cli to connect to the ElastiCache for Redis server using complete path for redis-cli, on
Amazon Linux:
If AUTH password was used during Redis cluster creation, this example uses redis-cli to connect to
the Redis server using complete path for redis-cli, on Amazon Linux:
OR
If no AUTH password was used during ElastiCache for Redis cluster creation, this example uses
the redis-cli to connect to the ElastiCache for Redis server using complete path for redis-cli, on
Amazon Linux:
If AUTH password was used during Redis cluster creation, this example uses redis-cli to connect to
the Redis server using complete path for redis-cli, on Amazon Linux:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
auth MySecretPassword
+OK
get foo
$3
bar
5. To stop and close the SSL tunnels, pkill the stunnel process.
See also
• At-Rest Encryption in ElastiCache for Redis (p. 483)
• Authenticating users with the Redis AUTH command (p. 478)
• Authenticating Users with Role-Based Access Control (RBAC)
• Amazon VPCs and ElastiCache security (p. 502)
• Identity and access management in Amazon ElastiCache (p. 538)
Topics
• Overview of AUTH in ElastiCache for Redis (p. 478)
• Applying authentication to an ElastiCache for Redis cluster (p. 478)
• Modifying the AUTH token on an existing ElastiCache for Redis cluster (p. 479)
In particular, be aware of these AUTH token, or password, constraints when using AUTH with ElastiCache
for Redis:
To set up a strong token, we recommend that you follow a strict password policy, such as requiring the
following:
• Tokens, or passwords, must include at least three of the following character types:
• Uppercase characters
• Lowercase characters
• Digits
• Nonalphanumeric characters (!, &, #, $, ^, <, >, -)
• Tokens, or passwords, must not contain a dictionary word or a slightly modified dictionary word.
• Tokens, or passwords, must not be the same as or similar to a recently used token.
The following AWS CLI operation creates a replication group with encryption in transit (TLS) enabled and
the AUTH token This-is-a-sample-token. Replace the subnet group sng-test with a subnet group
that exists.
Key parameters
For Windows:
To make it easier to update your authentication, you can modify the AUTH token used on an ElastiCache
for Redis cluster. You can make this modification if the engine version is 5.0.5 or higher and if ElastiCache
for Redis has encryption in transit enabled.
Modifying the auth token supports two strategies: ROTATE and SET. The ROTATE strategy adds an
additional AUTH token to the server while retaining the previous token. The SET strategy updates
the server to support just a single AUTH token. Make these modification calls with the --apply-
immediately parameter to apply changes immediately.
To update a Redis server with a new AUTH token, call the ModifyReplicationGroup API with the --
auth-token parameter as the new auth token and the --auth-token-update-strategy with the
value ROTATE. After the modification is complete, the cluster will support the previous AUTH token in
addition to the one specified in the auth-token parameter.
Note
If you do not configure the AUTH token before, then once the modification is complete, the
cluster will support no AUTH token in addition to the one specified in the auth-token parameter.
If this modification is performed on a server that already supports two AUTH tokens, the oldest AUTH
token will also be removed during this operation, allowing a server to support up to two most recent
AUTH tokens at a given time.
At this point, you can proceed by updating the client to use the latest AUTH token. After the clients are
updated, you can use the SET strategy for AUTH token rotation (explained in the following section) to
exclusively start using the new token.
The following AWS CLI operation modifies a replication group to rotate the AUTH token This-is-the-
rotated-token.
For Windows:
To update a Redis server with two AUTH tokens to support a single AUTH token, call the
ModifyReplicationGroup API operation. Call ModifyReplicationGroup with the --auth-token
parameter as the new AUTH token and the --auth-token-update-strategy parameter with the
value SET. The auth-token parameter must be the same value as the last AUTH token rotated. After
the modification is complete, the Redis server supports only the AUTH token specified in the auth-
token parameter.
The following AWS CLI operation modifies a replication group to set the AUTH token to This-is-the-
set-token.
For Windows:
--auth-token-update-strategy SET ^
--apply-immediately
To enable authentication on an existing Redis server, call the ModifyReplicationGroup API operation.
Call ModifyReplicationGroup with the --auth-token parameter as the new token and the --
auth-token-update-strategy with the value ROTATE.
After the modification is complete, the cluster supports the AUTH token specified in the auth-token
parameter in addition to supporting connecting without authentication. Enabling authentication is only
supported on Redis servers with encryption in transit (TLS) enabled.
If you are authenticating users with Redis Role-Based Access Control (RBAC) as described in
Authenticating users with role-based access control (RBAC) and want to migrate to Redis AUTH, use the
following procedures. You can migrate using either console or CLI.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the list in the upper-right corner, choose the AWS Region where the cluster that you want to
modify is located.
3. In the navigation pane, choose the engine running on the cluster that you want to modify.
For Windows:
--apply-immediately
For more information on working with AUTH, see AUTH token on the redis.io website.
ElastiCache for Redis at-rest encryption is an optional feature to increase data security by encrypting on-
disk data. When enabled on a replication group, it encrypts the following aspects:
Data stored on SSDs (solid-state drives) in data tiering enabled clusters is always encrypted by default.
However, when the cluster is backed up, the snapshot data is not automatically encrypted. Encryption
needs to be enabled on the snapshot. For more information, see Enabling At-Rest Encryption.
ElastiCache for Redis offers default (service managed) encryption at rest, as well as ability to use your
own symmetric customer managed AWS KMS keys in AWS Key Management Service (KMS).
Note
The default (service managed) encryption is the only option available in the GovCloud (US)
Regions.
At-rest encryption can be enabled on a replication group only when it is created. Because there is some
processing needed to encrypt and decrypt the data, enabling at-rest encryption can have a performance
impact during these operations. You should benchmark your data with and without at-rest encryption to
determine the performance impact for your use cases.
For information on encryption in transit, see ElastiCache for Redis in-transit encryption (TLS) (p. 471)
Topics
• At-Rest Encryption Conditions (p. 483)
• Using customer managed keys from AWS KMS (p. 484)
• Enabling At-Rest Encryption (p. 485)
• See Also (p. 489)
• At-rest encryption is supported on replication groups running Redis versions 3.2.6, 4.0.10 or later.
• At-rest encryption is supported only for replication groups running in an Amazon VPC.
• At-rest encryption is only supported for replication groups running the following node types.
• R6gd, R6g, R5, R4, R3
• M6g, M5, M4, M3
• T4g,T3, T2
• If a cluster is using a node type from the r6gd family, data stored on SSD is encrypted whether at-rest
encryption is enabled or not.
• The option to use customer managed key for encryption at rest is not available in AWS GovCloud (us-
gov-east-1 and us-gov-west-1) regions.
• If a cluster is using a node type from the r6gd family, data stored on SSD is encrypted with the chosen
customer managed AWS KMS key (or service-managed encryption in AWS GovCloud Regions).
Implementing at-rest encryption can reduce performance during backup and node sync operations.
Benchmark at-rest encryption compared to no encryption on your own data to determine its impact on
performance for your implementation.
To learn how to create AWS KMS root keys, see Creating Keys in the AWS Key Management Service
Developer Guide.
ElastiCache for Redis allows you to integrate with AWS KMS. For more information, see Using Grants
in the AWS Key Management Service Developer Guide. No customer action is needed to enable Amazon
ElastiCache integration with AWS KMS.
The kms:ViaService condition key limits use of an AWS KMS key (KMS key) to requests from specified
AWS services. To use kms:ViaService with ElastiCache, include both ViaService names in the condition
key value: elasticache.AWS_region.amazonaws.com and dax.AWS_region.amazonaws.com. For
more information, see kms:ViaService.
You can use AWS CloudTrail to track the requests that Amazon ElastiCache sends to AWS Key
Management Service on your behalf. All API calls to AWS Key Management Service related to customer
managed keys have corresponding CloudTrail logs. You can also see the grants that ElastiCache creates
by calling the ListGrants KMS API call.
Once a replication group is encrypted using customer managed key, all backups for the replication group
are encrypted as follows:
• Automatic daily backups are encrypted using the customer managed key associated with the cluster.
• Final backup created when replication group is deleted, is also encrypted using the customer managed
key associated with the replication group.
• Manually created backups are encrypted by default to use the KMS key associated with the replication
group. You may override this by choosing another customer managed key.
• Copying a backup defaults to using a customer managed key associated with the source backup. You
may override this by choosing another customer managed key.
Note
• Customer managed keys cannot be used when exporting backups to your selected Amazon
S3 bucket. However, all backups exported to Amazon S3 are encrypted using Server side
encryption. You may choose to copy the backup file to a new S3 object and encrypt using a
customer managed KMS key, copy the file to another S3 bucket that is set up with default
encryption using a KMS key or change an encryption option in the file itself.
• You can also use customer managed keys to encrypt manually-created backups for replication
groups that do not use customer managed keys for encryption. With this option, the backup
file stored in Amazon S3 is encrypted using a KMS key, even though the data is not encrypted
on the original replication group.
Restoring from a backup allows you to choose from available encryption options, similar to
encryption choices available when creating a new replication group.
• If you delete the key or disable the key and revoke grants for the key that you used to encrypt a
replication group, the replication group becomes irrecoverable. In other words, it cannot be modified
or recovered after a hardware failure. AWS KMS deletes root keys only after a waiting period of at least
seven days. After the key is deleted, you can use a different customer managed key to create a backup
for archival purposes.
• Automatic key rotation preserves the properties of your AWS KMS root keys, so the rotation has no
effect on your ability to access your ElastiCache data. Encrypted Amazon ElastiCache replication
groups don't support manual key rotation, which involves creating a new root key and updating any
references to the old key. To learn more, see Rotating AWS KMS keys in the AWS Key Management
Service Developer Guide.
• Encrypting an ElastiCache replication group using KMS key requires one grant per replication group.
This grant is used throughout the lifespan of the replication group. Additionally, one grant per backup
is used during backup creation. This grant is retired once the backup is created.
• For more information on AWS KMS grants and limits, see Limits in the AWS Key Management Service
Developer Guide.
You can enable at-rest encryption when you create an ElastiCache for Redis replication group. You can do
so using the AWS Management Console, the AWS CLI, or the ElastiCache API.
When creating a replication group, you can pick one of the following options:
To learn how to create AWS KMS root keys, see Create Keys in the AWS Key Management Service
Developer Guide
Contents
• Enabling At-Rest Encryption on an Existing Redis Cluster (p. 486)
• Enabling At-Rest Encryption Using the AWS Management Console (p. 486)
• Enabling At-Rest Encryption Using the AWS CLI (p. 486)
• Enabling At-Rest Encryption on a Redis (Cluster Mode Disabled) Cluster (CLI) (p. 486)
• Enabling At-Rest Encryption on a Cluster for Redis (Cluster Mode Enabled) (CLI) (p. 487)
• Enabling At-Rest Encryption Using the ElastiCache API (p. 488)
• Enabling At-Rest Encryption on a Redis (Cluster Mode Disabled) Cluster (API) (p. 488)
• Enabling At-Rest Encryption on a Cluster for Redis (Cluster Mode Enabled) (API) (p. 489)
You can only enable at-rest encryption when you create a Redis replication group. If you have an existing
replication group on which you want to enable at-rest encryption, do the following.
1. Create a manual backup of your existing replication group. For more information, see Making
manual backups (p. 315).
2. Create a new replication group by restoring from the backup. On the new replication group,
enable at-rest encryption. For more information, see Restoring from a backup with optional cluster
resizing (p. 334).
3. Update the endpoints in your application to point to the new replication group.
4. Delete the old replication group. For more information, see Deleting a cluster (p. 165) or Deleting a
replication group (p. 296).
To enable at-rest encryption when creating a replication group using the AWS Management Console,
make the following selections:
To enable at-rest encryption when creating a Redis cluster using the AWS CLI, use the --at-rest-
encryption-enabled parameter when creating a replication group.
The following operation creates the Redis (cluster mode disabled) replication group my-classic-rg
with three nodes (--num-cache-clusters), a primary and two read replicas. At-rest encryption is enabled
for this replication group (--at-rest-encryption-enabled).
The following parameters and their values are necessary to enable encryption on this replication group:
Key Parameters
• --engine—Must be redis.
• --engine-version—Must be 3.2.6, 4.0.10 or later.
• --at-rest-encryption-enabled—Required to enable at-rest encryption.
For Windows:
• Creating a Redis (Cluster Mode Disabled) replication group from scratch (AWS CLI) (p. 273)
• create-replication-group
Enabling At-Rest Encryption on a Cluster for Redis (Cluster Mode Enabled) (CLI)
The following operation creates the Redis (cluster mode enabled) replication group my-clustered-rg
with three node groups or shards (--num-node-groups). Each has three nodes, a primary and two read
replicas (--replicas-per-node-group). At-rest encryption is enabled for this replication group (--at-rest-
encryption-enabled).
The following parameters and their values are necessary to enable encryption on this replication group:
Key Parameters
• --engine—Must be redis.
• --engine-version—Must be 4.0.10 or later.
• --at-rest-encryption-enabled—Required to enable at-rest encryption.
• --cache-parameter-group—Must be default-redis4.0.cluster.on or one derived from it to
make this a cluster mode enabled replication group.
--engine redis \
--engine-version 4.0.10 \
--at-rest-encryption-enabled \
--cache-parameter-group default.redis4.0.cluster.on
For Windows:
• Creating a Redis (Cluster Mode Enabled) replication group from scratch (AWS CLI) (p. 280)
• create-replication-group
To enable at-rest encryption when creating a Redis replication group using the ElastiCache API, set the
parameter AtRestEncryptionEnabled to true with CreateReplicationGroup.
The following operation creates the Redis (cluster mode disabled) replication group my-classic-rg
with three nodes (NumCacheClusters), a primary and two read replicas. At-rest encryption is enabled for
this replication group (AtRestEncryptionEnabled=true).
The following parameters and their values are necessary to enable encryption on this replication group:
• Engine—Must be redis.
• EngineVersion—Must be 3.2.6, 4.0.10 or later.
• AtRestEncryptionEnabled—Required to be true to enable at-rest encryption.
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&AtRestEncryptionEnabled=true
&CacheNodeType=cache.m3.large
&CacheParameterGroup=default.redis4.0
&Engine=redis
&EngineVersion=4.0.10
&NumCacheClusters=3
&ReplicationGroupDescription=test%20group
&ReplicationGroupId=my-classic-rg
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
• Creating a Redis (cluster mode disabled) replication group from scratch (ElastiCache API) (p. 276)
• CreateReplicationGroup
Enabling At-Rest Encryption on a Cluster for Redis (Cluster Mode Enabled) (API)
The following operation creates the Redis (cluster mode enabled) replication group my-clustered-
rg with three node groups/shards (NumNodeGroups), each with three nodes, a primary and two
read replicas (ReplicasPerNodeGroup). At-rest encryption is enabled for this replication group
(AtRestEncryptionEnabled=true).
The following parameters and their values are necessary to enable encryption on this replication group:
• Engine—Must be redis.
• AtRestEncryptionEnabled—Required to be true to enable at-rest encryption.
• EngineVersion—Must be 3.2.6, 4.0.10 or later.
• CacheParameterGroup—Must be default-redis4.0.cluster.on, or one derived from it for this
to be a Redis (cluster mode enabled) cluster.
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&AtRestEncryptionEnabled=true
&CacheNodeType=cache.m3.large
&CacheParemeterGroup=default.redis4.0.cluster.on
&Engine=redis
&EngineVersion=4.0.10
&NumNodeGroups=3
&ReplicasPerNodeGroup=2
&ReplicationGroupDescription=test%20group
&ReplicationGroupId=my-clustered-rg
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=<credential>
• Creating a replication group in Redis (Cluster Mode Enabled) from scratch (ElastiCache API) (p. 285)
• CreateReplicationGroup
See Also
• Amazon VPCs and ElastiCache security (p. 502)
• Identity and access management in Amazon ElastiCache (p. 538)
Unlike Redis AUTH, where all authenticated clients have full replication group access if their token is
authenticated, RBAC enables you to control cluster access through user groups. These user groups are
designed as a way to organize access to replication groups.
With RBAC, you create users and assign them specific permissions by using an access string, as described
following. You assign the users to user groups aligned with a specific role (administrators, human
resources) that are then deployed to one or more ElastiCache for Redis replication groups. By doing this,
you can establish security boundaries between clients using the same Redis replication group or groups
and prevent clients from accessing each other’s data.
RBAC is designed to support the introduction of Redis ACL in Redis 6. When you use RBAC with your
ElastiCache for Redis cluster, there are some limitations:
• You can't specify passwords in an access string. You set passwords with CreateUser or ModifyUser calls.
• For user rights, you pass on and off as a part of the access string. If neither is specified in the access
string, the user is assigned off and doesn't have access rights to the replication group.
• You can't use forbidden and renamed commands. If you specify a forbidden or a renamed command,
an exception will be thrown. If you want to use access control lists (ACLs) for a renamed command,
specify the original name of the command, in other words the name of the command before it was
renamed.
• You can't use the reset command as a part of an access string. You specify passwords with API
parameters, and ElastiCache for Redis manages passwords. Thus, you can't use reset because it would
remove all passwords for a user.
• Redis 6 introduces the ACL LIST command. This command returns a list of users along with the ACL
rules applied to each user. ElastiCache for Redis supports the ACL LIST command, but does not
include support for password hashes as Redis does. With ElastiCache for Redis, you can use the
describe-users operation to get similar information, including the rules contained within the access
string. However, describe-users doesn't retrieve a user password.
Other read-only commands supported by ElastiCache for Redis include ACL WHOAMI, ACL USERS, and
ACL CAT. ElastiCache for Redis doesn't support any other write-based ACL commands.
• The following constraints apply:
Using RBAC with ElastiCache for Redis is described in more detail following.
Topics
• Specifying Permissions Using an Access String (p. 491)
• Applying RBAC to a Replication Group for ElastiCache for Redis (p. 491)
• Migrating from Redis AUTH to RBAC (p. 500)
• Migrating from RBAC to Redis AUTH (p. 501)
Access strings are defined as a list of space-delimited rules which are applied on the user. They define
which commands a user can execute and which keys a user can operate on. In order to execute a
command, a user must have access to the command being executed and all keys being accessed by the
command. Rules are applied from left to right cumulatively, and a simpler string may be used instead of
the one provided if there are redundancies in the string provided.
For information about the syntax of the ACL rules, see ACL.
In the following example, the access string represents an active user with access to all available keys and
commands.
on ~* +@all
The preceding settings are the least restrictive. You can modify these settings to make them more
secure.
In the following example, the access string represents a user with access restricted to read access on keys
that start with “app::” keyspace
You can refine these permissions further by listing commands the user has access to:
For information on assigning an access string to a user, see Creating Users and User Groups with the
Console and CLI (p. 492).
If you are migrating an existing workload to ElastiCache, you can retrieve the access string by calling ACL
LIST, excluding the user and any password hashes.
Topics
• Creating Users and User Groups with the Console and CLI (p. 492)
• Managing User Groups with the Console and CLI (p. 495)
• Assigning User Groups to Replication Groups (p. 498)
Creating Users and User Groups with the Console and CLI
The user information for RBAC users is a user ID, user name, and optionally a password and an access
string. The access string provides the permission level on keys and commands. The user ID is unique to
the user, and the user name is what is passed to the engine.
Make sure that the user permissions you provide make sense with the intended purpose of the user
group. For example, if you create a user group called Administrators, any user you add to that group
should have its access string set to full access to keys and commands. For users in an e-commerce user
group, you might set their access strings to read-only access.
ElastiCache automatically configures a default user with user ID and user name "default" and adds it
to all user groups. You can't modify or delete this user. This user is intended for compatibility with the
default behavior of previous Redis versions and has an access string that permits it to call all commands
and access all keys.
To add proper access control to a cluster, replace this default user with a new one that isn't enabled
or uses a strong password. To change the default user, create a new user with the user name set to
default. You can then swap it with the original default user.
The following procedures shows how to swap the original default user with another default user that
has a modified access string.
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. Choose Redis from the navigation pane.
3. Choose User Group Management.
4. For User Group ID, choose the ID that you want to modify. Make sure that you choose the link and
not the check box.
5. Choose Swap Default.
6. In the Swap Default window, for Default User choose the user that you want as the default user.
7. Choose Swap. When you do this, any existing connections to a replication group that the original
default user has are terminated.
1. Create a new user with the user name default by using the following commands.
For Windows:
2. Create a user group and add the user that you created previously.
For Windows:
3. Swap the new default user with the original default user.
For Windows:
When this modify operation is called, any existing connections to a replication group that the
original default user has are terminated.
When creating a user, you can set up to two passwords. When you modify a password, any existing
connections to replication groups are maintained.
In particular, be aware of these user password constraints when using RBAC for ElastiCache for Redis:
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the Amazon ElastiCache dashboard, choose User Management. The following options are
available:
• Create User – When creating a user, you enter a user ID, user name, password, and access string.
The access string sets the permission level for what keys and commands the user is allowed.
When creating a user, you can set up to two passwords. When you modify a password, any existing
connections to replication groups are maintained.
• Modify User – Enables you to update a user's password or change its access string.
• Delete User – The user account will be removed from any User Management Groups to which it
belongs.
Use the following procedures to manage users with the AWS CLI.
• Use the modify-user command to update a user's password or passwords or change a user's access
permissions.
When a user is modified, the user groups associated with the user are updated, along with any
replication groups associated with the user group. All existing connections are maintained. The
following are examples.
For Windows:
{
"UserId": "user-id-1",
"UserName": "user-name-1",
"Status": "modifying",
"Engine": "redis",
"AccessString": "off ~objects:* ~items:* ~public:* -@all",
"UserGroupIds": [
"new-group-1"
],
"Authentication": {
"Type": "no-password"
},
"ARN": "arn:aws:elasticache:us-east-1:493071037918:user:user-id-1"
}
Note
We don't recommend using the nopass option. If you do, we recommend setting the user's
permissions to read-only with access to a limited set of keys.
• Use the delete-user command to delete a user. The user account is deleted and removed from
any user groups to which it belongs. The following is an example.
For Windows:
{
"UserId": "user-id-2",
"UserName": "user-name-2",
"Status": "deleting",
"Engine": "redis",
"AccessString": "on ~keys* -@all +get",
"UserGroupIds": [
"new-group-1"
],
"Authentication": {
"Type": "password",
"PasswordCount": 1
},
"ARN": "arn:aws:elasticache:us-east-1:493071037918:user:user-id-2"
}
You can create user groups to organize and control access of users to one or more replication groups, as
shown following.
Use the following procedure to manage user groups using the console.
1. Sign in to the AWS Management Console and open the Amazon ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. On the Amazon ElastiCache dashboard, choose User Management.
• Create – When you create a user group, you add users and then assign the user groups to
replication groups. For example, you can create an Admin user group for users who have
administrative roles on a cluster.
Important
When you a create user group, you are required to include the default user.
• Add Users – Add users to the user group.
• Remove Users – Remove users from the user group. When users are removed from a user group,
any existing connections they have to a replication group are terminated.
• Delete – Use this to delete a user group. Note that the user group itself, not the users belonging to
the group, will be deleted.
Use the following procedures to manage user groups using the CLI.
To create a new user group and add a user by using the CLI
For Windows:
{
"UserGroupId": "new-group-1",
"Status": "creating",
"Engine": "redis",
"UserIds": [
"user-id-1",
"user-id-2"
],
"ReplicationGroups": [],
"ARN": "arn:aws:elasticache:us-east-1:493071037918:usergroup:new-group-1"
}
To modify a user group by adding new users or removing current members by using the CLI
For Windows:
{
"UserGroupId": "new-group-1",
"Status": "modifying",
"Engine": "redis",
"UserIds": [
"user-id-1",
"user-id-2"
],
"PendingChanges": {
"UserIdsToRemove": [
"user-id-2"
],
"UserIdsToAdd": [
"user-id-3"
]
},
"ReplicationGroups": [],
"ARN": "arn:aws:elasticache:us-east-1:493071037918:usergroup:new-group-1"
}
Note
Any open connections belonging to a user removed from a user group are ended by this
command.
• Use the delete-user-group command as shown following. The user group itself, not the users
belonging to the group, is deleted.
For Windows:
To see a list of user groups, you can call the describe-user-groups operation.
{
"UserGroups": [{
"UserGroupId": "test-group",
"Status": "creating",
"Engine": "redis",
"UserIds": [
"defaut", "test-user-1"
],
"ReplicationGroups": []
}]
}
After you have created a user group and added users, the final step in implementing RBAC is assigning
the user group to a replication group.
To add a user group to a replication using the AWS Management Console, do the following:
• For cluster mode disabled, see Creating a Redis (cluster mode disabled) cluster (Console) (p. 47)
• For cluster mode enabled, see Creating a Redis (cluster mode enabled) cluster (Console) (p. 132)
The following AWS CLI operation creates a replication group with encryption in transit (TLS) enabled and
the user-group-ids parameter with the value my-user-group-id. Replace the subnet group sng-test
with a subnet group that exists.
Key Parameters
For Windows:
{
"ReplicationGroup": {
"ReplicationGroupId": "new-replication-group",
"Description": "new-replication-group",
"Status": "creating",
"PendingModifiedValues": {},
"MemberClusters": [
"new-replication-group-001"
],
"AutomaticFailover": "disabled",
"SnapshotRetentionLimit": 0,
"SnapshotWindow": "10:30-11:30",
"ClusterEnabled": false,
"UserGroupIds": ["new-group-1"]
"CacheNodeType": "cache.m5.large",
"DataTiering": "disabled"
"TransitEncryptionEnabled": true,
"AtRestEncryptionEnabled": false
}
}
The following AWS CLI operation modifies a replication group with encryption in transit (TLS) enabled
and the user-group-ids parameter with the value my-user-group-id.
For Windows:
{
"ReplicationGroupId": "replication-group-1",
"PendingChanges": {
"UserGroups": {
"UserGroupIdsToRemove": ["new-group-1"],
"UserGroupIdsToAdd": ["new-group-2"]
}
}
.
.
.
"UserGroupIds": ["new-group-1"]
}
{
"ReplicationGroupId": "replication-group-1",
"PendingChanges": {
"UserGroups": {
"UserGroupIdsToRemove": ["new-group-1"],
"UserGroupIdsToAdd": ["new-group-2"]
}
}
.
.
.
"UserGroupIds": ["new-group-1"]
}
Note the PendingChanges in the response. Any modifications made to a replication group are updated
asynchronously. You can monitor this progress by viewing the events. For more information, see Viewing
ElastiCache events (p. 610).
Use the following procedure to migrate from Redis AUTH to RBAC using the console.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. From the list in the upper-right corner, choose the AWS Region where the cluster that you want to
modify is located.
3. In the navigation pane, choose the engine running on the cluster that you want to modify.
Use the following procedure to migrate from Redis AUTH to RBAC using the CLI.
For Windows:
• Amazon VPCs and ElastiCache security (p. 502) explains the type of security group you need for
your installation.
• Identity and access management in Amazon ElastiCache (p. 538) for granting and limiting actions
of users, groups, and roles.
The Amazon Virtual Private Cloud (Amazon VPC) service defines a virtual network that closely resembles
a traditional data center. When you configure your Amazon VPC you can select its IP address range,
create subnets, and configure route tables, network gateways, and security settings. You can also add
a cache cluster to the virtual network, and control access to the cache cluster by using Amazon VPC
security groups.
This section explains how to manually configure an ElastiCache cluster in an Amazon VPC. This
information is intended for users who want a deeper understanding of how ElastiCache and Amazon VPC
work together.
Topics
• Understanding ElastiCache and Amazon VPCs (p. 503)
• Access Patterns for Accessing an ElastiCache Cluster in an Amazon VPC (p. 507)
• Migrating an EC2-Classic cluster into a VPC (p. 513)
• Creating a Virtual Private Cloud (VPC) (p. 515)
• Creating a replication group in an Amazon VPC (p. 517)
• Connecting to a cache cluster running in an Amazon VPC (p. 518)
• If your AWS account supports only the EC2-VPC platform, ElastiCache always launches your cluster in
an Amazon VPC.
• If you're new to AWS, your clusters will be deployed into an Amazon VPC. A default VPC will be created
for you automatically.
• If you have a default VPC and don't specify a subnet when you launch a cluster, the cluster launches
into your default Amazon VPC.
For more information, see Detecting Your Supported Platforms and Whether You Have a Default VPC.
With Amazon Virtual Private Cloud, you can create a virtual network in the AWS cloud that closely
resembles a traditional data center. You can configure your Amazon VPC, including selecting its IP
address range, creating subnets, and configuring route tables, network gateways, and security settings.
The basic functionality of ElastiCache is the same in a virtual private cloud; ElastiCache manages
software upgrades, patching, failure detection and recovery whether your clusters are deployed inside or
outside an Amazon VPC.
ElastiCache cache nodes deployed outside an Amazon VPC are assigned an IP address to which the
endpoint/DNS name resolves. This provides connectivity from Amazon Elastic Compute Cloud (Amazon
EC2) instances. When you launch an ElastiCache cluster into an Amazon VPC private subnet, every cache
node is assigned a private IP address within that subnet.
The Amazon VPC is an isolated portion of the AWS Cloud that is assigned its own block of IP
addresses.
An Internet gateway connects your Amazon VPC directly to the Internet and provides access
to other AWS resources such as Amazon Simple Storage Service (Amazon S3) that are running
outside your Amazon VPC.
An Amazon VPC subnet is a segment of the IP address range of an Amazon VPC where you can
isolate AWS resources according to your security and operational needs.
A routing table in the Amazon VPC directs network traffic between the subnet and the Internet.
The Amazon VPC has an implied router, which is symbolized in this diagram by the circle with
the R.
An Amazon VPC security group controls inbound and outbound traffic for your ElastiCache
clusters and Amazon EC2 instances.
You can launch an ElastiCache cluster in the subnet. The cache nodes have private IP addresses
from the subnet's range of addresses.
You can also launch Amazon EC2 instances in the subnet. Each Amazon EC2 instance has a
private IP address from the subnet's range of addresses. The Amazon EC2 instance can connect
to any cache node in the same subnet.
For an Amazon EC2 instance in your Amazon VPC to be reachable from the Internet, you need
to assign a static, public address called an Elastic IP address to the instance.
Why use the Amazon VPC instead of EC2 classic with your ElastiCache
deployment?
Launching your instances into an Amazon VPC allows you to:
• Assign static private IP addresses to your instances that persist across starts and stops.
• Assign multiple IP addresses to your instances.
• Define network interfaces, and attach one or more network interfaces to your instances.
• Change security group membership for your instances while they're running.
• Control the outbound traffic from your instances (egress filtering) in addition to controlling the
inbound traffic to them (ingress filtering).
• Add an additional layer of access control to your instances in the form of network access control lists
(ACL).
• Run your instances on single-tenant hardware.
For a comparison of Amazon EC2 Classic, Default VPC, and Non-default VPC, see Differences Between
EC2-Classic and EC2-VPC.
The Amazon VPC must allow non-dedicated Amazon EC2 instances. You cannot use ElastiCache in an
Amazon VPC that is configured for dedicated instance tenancy.
Prerequisites
To create an ElastiCache cluster within an Amazon VPC, your Amazon VPC must meet the following
requirements:
• The Amazon VPC must allow nondedicated Amazon EC2 instances. You cannot use ElastiCache in an
Amazon VPC that is configured for dedicated instance tenancy.
• A cache subnet group must be defined for your Amazon VPC. ElastiCache uses that cache subnet group
to select a subnet and IP addresses within that subnet to associate with your cache nodes.
• A cache security group must be defined for your Amazon VPC, or you can use the default provided.
• CIDR blocks for each subnet must be large enough to provide spare IP addresses for ElastiCache to use
during maintenance activities.
Internet-bound traffic over the VPN and use local security policies and firewall to control egress. In that
case, you incur additional bandwidth charges when you access AWS resources over the Internet.
You can use Amazon VPC security groups to help secure the ElastiCache clusters and Amazon EC2
instances in your Amazon VPC. Security groups act like a firewall at the instance level, not the subnet
level.
Note
We strongly recommend that you use DNS names to connect to your cache nodes, as the
underlying IP address can change if you reboot the cache node.
Description Documentation
How to get started using Amazon VPC Getting started with Amazon VPC
How to use Amazon VPC through the AWS Amazon VPC User Guide
Management Console
Complete descriptions of all the Amazon VPC Amazon EC2 Command Line Reference (the
commands Amazon VPC commands are found in the Amazon
EC2 reference)
Complete descriptions of the Amazon VPC API Amazon EC2 API Reference (the Amazon VPC
operations, data types, and errors API operations are found in the Amazon EC2
reference)
Information for the network administrator who What is AWS Site-to-Site VPN?
needs to configure the gateway at your end of an
optional IPsec VPN connection
For more detailed information about Amazon Virtual Private Cloud, see Amazon Virtual Private Cloud.
Contents
• Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in the Same Amazon
VPC (p. 507)
• Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in Different Amazon
VPCs (p. 508)
• Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in Different
Amazon VPCs in the Same Region (p. 509)
• Using Transit Gateway (p. 510)
• Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in Different
Amazon VPCs in Different Regions (p. 510)
• Using Transit VPC (p. 510)
• Accessing an ElastiCache Cluster from an Application Running in a Customer's Data Center (p. 511)
• Accessing an ElastiCache Cluster from an Application Running in a Customer's Data Center
Using VPN Connectivity (p. 511)
• Accessing an ElastiCache Cluster from an Application Running in a Customer's Data Center
Using Direct Connect (p. 512)
Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in the
Same Amazon VPC
The most common use case is when an application deployed on an EC2 instance needs to connect to a
Cluster in the same VPC.
The simplest way to manage access between EC2 instances and clusters in the same VPC is to do the
following:
1. Create a VPC security group for your cluster. This security group can be used to restrict access to the
cluster instances. For example, you can create a custom rule for this security group that allows TCP
access using the port you assigned to the cluster when you created it and an IP address you will use
to access the cluster.
The default port for Redis clusters and replication groups is 6379.
2. Create a VPC security group for your EC2 instances (web and application servers). This security group
can, if needed, allow access to the EC2 instance from the Internet via the VPC's routing table. For
example, you can set rules on this security group to allow TCP access to the EC2 instance over port
22.
3. Create custom rules in the security group for your Cluster that allow connections from the security
group you created for your EC2 instances. This would allow any member of the security group to
access the clusters.
Note
If you are planning to use Local Zones, ensure that you have enabled them. When you create a
subnet group in that local zone, your VPC is extended to that Local Zone and your VPC will treat
the subnet as any subnet in any other Availability Zone. All relevant gateways and route tables
will be automatically adjusted.
To create a rule in a VPC security group that allows connections from another security group
1. Sign in to the AWS Management Console and open the Amazon VPC console at https://
console.aws.amazon.com/vpc.
2. In the navigation pane, choose Security Groups.
3. Select or create a security group that you will use for your Cluster instances. Under Inbound
Rules, select Edit Inbound Rules and then select Add Rule. This security group will allow access to
members of another security group.
4. From Type choose Custom TCP Rule.
a. For Port Range, specify the port you used when you created your cluster.
The default port for Redis clusters and replication groups is 6379.
b. In the Source box, start typing the ID of the security group. From the list select the security
group you will use for your Amazon EC2 instances.
5. Choose Save when you finish.
Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in
Different Amazon VPCs
When your Cluster is in a different VPC from the EC2 instance you are using to access it, there are several
ways to access the cluster. If the Cluster and EC2 instance are in different VPCs but in the same region,
you can use VPC peering. If the Cluster and the EC2 instance are in different regions, you can create VPN
connectivity between regions.
Topics
• Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in Different Amazon VPCs
in the Same Region (p. 509)
• Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in Different Amazon VPCs
in Different Regions (p. 510)
Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in Different Amazon
VPCs in the Same Region
The following diagram illustrates accessing a cluster by an Amazon EC2 instance in a different Amazon
VPC in the same region using an Amazon VPC peering connection.
Cluster accessed by an Amazon EC2 instance in a different Amazon VPC within the same Region - VPC
Peering Connection
A VPC peering connection is a networking connection between two VPCs that enables you to route traffic
between them using private IP addresses. Instances in either VPC can communicate with each other
as if they are within the same network. You can create a VPC peering connection between your own
Amazon VPCs, or with an Amazon VPC in another AWS account within a single region. To learn more
about Amazon VPC peering, see the VPC documentation.
1. Make sure that the two VPCs do not have an overlapping IP range or you will not be able to peer
them.
2. Peer the two VPCs. For more information, see Creating and Accepting an Amazon VPC Peering
Connection.
3. Update your routing table. For more information, see Updating Your Route Tables for a VPC Peering
Connection
Following is what the route tables look like for the example in the preceeding diagram. Note that
pcx-a894f1c1 is the peering connection.
4. Modify the Security Group of your ElastiCache cluster to allow inbound connection from the
Application security group in the peered VPC. For more information, see Reference Peer VPC Security
Groups.
Accessing a cluster over a peering connection will incur additional data transfer costs.
You can enable multicast on a transit gateway, and then create a transit gateway multicast domain that
allows multicast traffic to be sent from your multicast source to multicast group members over VPC
attachments that you associate with the domain.
You can also create a peering connection attachment between transit gateways in different AWS
Regions. This enables you to route traffic between the transit gateways' attachments across different
Regions.
Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in Different Amazon
VPCs in Different Regions
Once the Transit Amazon VPC is established, an application deployed in a “spoke” VPC in one region can
connect to an ElastiCache cluster in a “spoke” VPC within another region.
1. Deploy a Transit VPC Solution. For more information, see, AWS Transit Gateway.
2. Update the VPC routing tables in the App and Cache VPCs to route traffic through the VGW (Virtual
Private Gateway) and the VPN Appliance. In case of Dynamic Routing with Border Gateway Protocol
(BGP) your routes may be automatically propagated.
3. Modify the Security Group of your ElastiCache cluster to allow inbound connection from the
Application instances IP range. Note that you will not be able to reference the application server
Security Group in this scenario.
Accessing a cluster across regions will introduce networking latencies and additional cross-region data
transfer costs.
Topics
• Accessing an ElastiCache Cluster from an Application Running in a Customer's Data Center Using VPN
Connectivity (p. 511)
• Accessing an ElastiCache Cluster from an Application Running in a Customer's Data Center Using
Direct Connect (p. 512)
Accessing an ElastiCache Cluster from an Application Running in a Customer's Data Center Using
VPN Connectivity
The following diagram illustrates accessing an ElastiCache cluster from an application running in your
corporate network using VPN connections.
1. Establish VPN Connectivity by adding a hardware Virtual Private Gateway to your VPC. For more
information, see Adding a Hardware Virtual Private Gateway to Your VPC.
2. Update the VPC routing table for the subnet where your ElastiCache cluster is deployed to allow
traffic from your on-premises application server. In case of Dynamic Routing with BGP your routes
may be automatically propagated.
3. Modify the Security Group of your ElastiCache cluster to allow inbound connection from the on-
premises application servers.
Accessing a cluster over a VPN connection will introduce networking latencies and additional data
transfer costs.
Accessing an ElastiCache Cluster from an Application Running in a Customer's Data Center Using
Direct Connect
The following diagram illustrates accessing an ElastiCache cluster from an application running on your
corporate network using Direct Connect.
To access an ElastiCache cluster from an application running in your network using Direct
Connect
1. Establish Direct Connect connectivity. For more information, see, Getting Started with AWS Direct
Connect.
2. Modify the Security Group of your ElastiCache cluster to allow inbound connection from the on-
premises application servers.
Accessing a cluster over DX connection may introduce networking latencies and additional data transfer
charges.
1. You first need to create a Virtual Private Cloud (VPC). Follow the steps to create a VPC at Creating a
Virtual Private Cloud (VPC).
2. Once you have created the VPC, follow the steps to create a subnet group at Subnets and Subnet
Groups.
3. Your VPC comes with a default security group. You can choose to use it or you can create one by
following the steps at Security groups for your VPC in the Amazon VPC documentation.
4. In order to add your cluster to a VPC, you must first create a backup of it and then restore the
backup into the VPC. Go to the ElastiCache for Redis console and choose your cluster. Choose
Actions and then choose Backup. Enter a Backup Name and then choose Create Backup.
5. Once the backup is created, you add it to the VPC you created previously. Return to the ElastiCache
for Redis console and choose Backups. Choose the backup you created and then choose Restore.
6. In Cluster name, enter a name for your cluster.
7. In Choose a Subnet group, select the subnet group you created previously and then choose
Continue.
Once the restoration process is complete, your cluster will be available in the VPC.
Note
Previous generation node types might not be supported on the VPC platform. For a full list of
VPC supported node types, see Supported node types by AWS Region (p. 101).
1. Sign in to the AWS Management Console, and open the Amazon VPC console at https://
console.aws.amazon.com/vpc/.
2. Create a new Amazon VPC by using the Amazon Virtual Private Cloud wizard:
The public subnet will have one fewer available IP address, because the wizard creates an
Amazon EC2 NAT instance and an Elastic IP address (for which Amazon EC2 rates apply) for
outbound communication to the Internet from your private subnet.
Tip
Make a note of your two subnet identifiers, and which is public and private. You will
need this information later when you launch your cache clusters and add an Amazon EC2
instance to your Amazon VPC.
4. Create an Amazon VPC security group. You will use this group for your cache cluster and your
Amazon EC2 instance.
a. In the navigation pane of the Amazon VPC Management console, choose Security Groups.
b. Choose Create Security Group.
c. Type a name and a description for your security group in the corresponding boxes. In the VPC
box, choose the identifier for your Amazon VPC.
d. When the settings are as you want them, choose Yes, Create.
5. Define a network ingress rule for your security group. This rule will allow you to connect to your
Amazon EC2 instance using Secure Shell (SSH).
• Type: HTTP
• Source: 0.0.0.0/0
Now you are ready to create a cache subnet group and launch a cache cluster in your Amazon VPC.
To launch a Redis (cluster mode enabled) replication group, see Creating a Redis (Cluster Mode Enabled)
cluster (Console) (p. 280)
You have now launched a Redis replication group inside an Amazon VPC. For an example of one way to
connect to your new replication group running in the Amazon VPC, continue to Connecting to a cache
cluster running in an Amazon VPC (p. 518).
To create an Amazon EC2 instance in your Amazon VPC using the Amazon EC2 console
1. Sign in to the AWS Management Console and open the Amazon EC2 console at https://
console.aws.amazon.com/ec2/.
2. In the console, choose Launch Instance and follow these steps:
3. On the Choose an Amazon Machine Image (AMI) page, choose the 64-bit Amazon Linux AMI, and
then choose Select.
4. On the Choose an Instance Type page, choose 3. Configure Instance.
5. On the Configure Instance Details page, make the following selections:
When the settings are as you want them, choose 4. Add Storage.
6. On the Add Storage page, choose 5. Tag Instance.
7. On the Tag Instance page, type a name for your Amazon EC2 instance, and then choose 6.
Configure Security Group.
8. On the Configure Security Group page, choose Select an existing security group. For more
information on security groups, see Amazon EC2 security groups for Linux instances.
Choose the name of your Amazon VPC security group, and then choose Review and Launch.
9. On the Review Instance and Launch page, choose Launch.
10. In the Select an existing key pair or create a new key pair window, specify a key pair that you want
to use with this instance.
Note
For information about managing key pairs, see the Amazon EC2 Getting Started Guide.
11. When you are ready to launch your Amazon EC2 instance, choose Launch.
You can now assign an Elastic IP address to the Amazon EC2 instance that you just created. You need to
use this IP address to connect to the Amazon EC2 instance.
In the Private IP address box, select the box to obtain the private IP address and then choose
Associate.
You can now use SSH to connect to the Amazon EC2 instance using the Elastic IP address that you
created.
• Open a command window. At the command prompt, issue the following command, replacing
mykeypair.pem with the name of your key pair file and 54.207.55.251 with your Elastic IP address.
Important
Do not log out of your Amazon EC2 instance yet.
You are now ready to interact with your ElastiCache cluster. Before you can do that, if you haven't already
done so, you need to install the telnet utility.
To install telnet and interact with your cache cluster (AWS CLI)
1. Open a command window. At the command prompt, issue the following command. At the
confirmation prompt, type y.
...(output omitted)...
...(output omitted)...
Complete!
2. Use telnet to connect to your cache node endpoint over port 6379. Replace the hostname shown
below with the hostname of your cache node.
You are now connected to the cache engine and can issue commands. In this example, you add a
data item to the cache and then get it immediately afterward. Finally, you'll disconnect from the
cache node.
OK
get mykey
quit
You are now connected to the cache engine and can issue commands. In this example, you add a
data item to the cache and then get it immediately afterward. Finally, you'll disconnect from the
cache node.
OK
get mykey
get mykey
myvalue
quit
Important
To avoid incurring additional charges on your AWS account, be sure to delete any AWS resources
you no longer want after trying these examples.
Instances in your VPC don't need public IP addresses to communicate with Amazon ElastiCache API
endpoints. Your instances also don't need public IP addresses to use any of the available ElastiCache API
operations. Traffic between your VPC and Amazon ElastiCache doesn't leave the Amazon network. Each
interface endpoint is represented by one or more elastic network interfaces in your subnets. For more
information on elastic network interfaces, see Elastic network interfaces in the Amazon EC2 User Guide.
• For more information about VPC endpoints, see Interface VPC endpoints (AWS PrivateLink) in the
Amazon VPC User Guide.
• For more information about ElastiCache API operations, see ElastiCache API operations.
After you create an interface VPC endpoint, if you enable private DNS hostnames for the endpoint,
the default ElastiCache endpoint (https://elasticache.Region.amazonaws.com) resolves to your VPC
endpoint. If you do not enable private DNS hostnames, Amazon VPC provides a DNS endpoint name that
you can use in the following format:
VPC_Endpoint_ID.elasticache.Region.vpce.amazonaws.com
For more information, see Interface VPC Endpoints (AWS PrivateLink) in the Amazon VPC User Guide.
ElastiCache supports making calls to all of its API Actions inside your VPC.
Note
Private DNS hostnames can be enabled for only one VPC endpoint in the VPC. If you want to
create an additional VPC endpoint then private DNS hostname should be disabled for it.
VPC endpoint policies are supported for ElastiCache API endpoints. By default, full access to ElastiCache
API operations is allowed through the endpoint. For more information, see Controlling access to services
with VPC endpoints in the Amazon VPC User Guide.
After you create an interface VPC endpoint, you can enable private DNS hostnames for the endpoint.
When you do, the default Amazon ElastiCache endpoint (https://elasticache.Region.amazonaws.com)
resolves to your VPC endpoint. For the China (Beijing) and China (Ningxia) AWS Regions, you can make
API requests with the VPC endpoint by using elasticache.cn-north-1.amazonaws.com.cn for
Beijing and elasticache.cn-northwest-1.amazonaws.com.cn for Ningxia. For more information,
see Accessing a service through an interface endpoint in the Amazon VPC User Guide.
For more information, see Controlling access to services with VPC endpoints in the Amazon VPC User
Guide.
{
"Statement": [{
"Principal": "*",
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:ModifyCacheCluster",
"elasticache:CreateSnapshot"
],
"Resource": "*"
}]
}
Example VPC endpoint policy that denies all access from a specified AWS account
The following VPC endpoint policy denies AWS account 123456789012 all access to resources using the
endpoint. The policy allows all actions from other accounts.
{
"Statement": [{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "*",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
If you create a cluster in an Amazon VPC, you must specify a subnet group. ElastiCache uses that subnet
group to choose a subnet and IP addresses within that subnet to associate with your nodes.
This section covers how to create and leverage subnets and subnet groups to manage access to your
ElastiCache resources.
For more information about subnet group usage in an Amazon VPC environment, see Step 3: Authorize
access to the cluster (p. 52).
Topics
• Creating a subnet group (p. 525)
• Assigning a subnet group to a cluster or replication group (p. 528)
When you create a new subnet group, note the number of available IP addresses. If the subnet has very
few free IP addresses, you might be constrained as to how many more nodes you can add to the cluster.
To resolve this issue, you can assign one or more subnets to a subnet group so that you have a sufficient
number of IP addresses in your cluster's Availability Zone. After that, you can add more nodes to your
cluster.
The following procedures show you how to create a subnet group called mysubnetgroup (console), the
AWS CLI, and the ElastiCache API.
1. Sign in to the AWS Management Console, and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation list, choose Subnet Groups.
3. Choose Create Subnet Group.
4. In the Create Subnet Group wizard, do the following. When all the settings are as you want them,
choose Yes, Create.
Your new subnet group appears in the Subnet Groups list of the ElastiCache console. At the bottom of
the window you can choose the subnet group to see details, such as all of the subnets associated with
this group.
For Windows:
{
"CacheSubnetGroup": {
"VpcId": "vpc-37c3cd17",
"CacheSubnetGroupDescription": "Testing",
"Subnets": [
{
"SubnetIdentifier": "subnet-53df9c3a",
"SubnetAvailabilityZone": {
"Name": "us-west-2a"
}
}
],
"CacheSubnetGroupName": "mysubnetgroup"
}
}
• CacheSubnetGroupName=mysubnetgroup
• CacheSubnetGroupDescription==Testing
• SubnetIds.member.1=subnet-53df9c3a
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheSubnetGroup
&CacheSubnetGroupDescription=Testing
&CacheSubnetGroupName=mysubnetgroup
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&SubnetIds.member.1=subnet-53df9c3a
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Credential=<credential>
&X-Amz-Date=20141201T220302Z
&X-Amz-Expires=20141201T220302Z
&X-Amz-Signature=<signature>
&X-Amz-SignedHeaders=Host
• Standalone Redis cluster – To launch a single-node Redis cluster, see Creating a Redis (cluster mode
disabled) cluster (Console) (p. 47). In step 7.a (Advanced Redis Settings), choose a VPC subnet group.
• Redis (cluster mode disabled) replication group – To launch a Redis (cluster mode disabled)
replication group in a VPC, see Creating a Redis (Cluster Mode Disabled) replication group from
scratch (p. 273). In step 7.b (Advanced Redis Settings), choose a VPC subnet group.
• Redis (cluster mode enabled) replication group – Creating a Redis (Cluster Mode Enabled) cluster
(Console) (p. 280). In step 6.i (Advanced Redis Settings), choose a VPC subnet group.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Subnet Groups.
3. In the list of subnet groups, choose the one you want to modify.
4. In the lower portion of the ElastiCache console, make any changes to the description or the list of
subnet IDs for the subnet group. To save your changes, choose Save.
For Windows:
{
"CacheSubnetGroup": {
"VpcId": "vpc-73cd3c17",
"CacheSubnetGroupDescription": "New description",
"Subnets": [
{
"SubnetIdentifier": "subnet-42dcf93a",
"SubnetAvailabilityZone": {
"Name": "us-west-2a"
}
},
{
"SubnetIdentifier": "subnet-48fc12a9",
"SubnetAvailabilityZone": {
"Name": "us-west-2a"
}
}
],
"CacheSubnetGroupName": "mysubnetgroup"
}
}
• CacheSubnetGroupName=mysubnetgroup
• Any other parameters whose values you want to change. This example uses
CacheSubnetGroupDescription=New%20description to change the description of the subnet
group.
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheSubnetGroup
&CacheSubnetGroupDescription=New%20description
&CacheSubnetGroupName=mysubnetgroup
&SubnetIds.member.1=subnet-42df9c3a
&SubnetIds.member.2=subnet-48fc21a9
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Credential=<credential>
&X-Amz-Date=20141201T220302Z
&X-Amz-Expires=20141201T220302Z
&X-Amz-Signature=<signature>
&X-Amz-SignedHeaders=Host
Note
When you create a new subnet group, take note the number of available IP addresses. If the
subnet has very few free IP addresses, you might be constrained as to how many more nodes
you can add to the cluster. To resolve this issue, you can assign one or more subnets to a subnet
group so that you have a sufficient number of IP addresses in your cluster's Availability Zone.
After that, you can add more nodes to your cluster.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In the navigation pane, choose Subnet Groups.
3. In the list of subnet groups, choose the one you want to delete and then choose Delete.
4. When you are asked to confirm this operation, choose Yes, Delete.
• --cache-subnet-group-name mysubnetgroup
For Windows:
• CacheSubnetGroupName=mysubnetgroup
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteCacheSubnetGroup
&CacheSubnetGroupName=mysubnetgroup
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Credential=<credential>
&X-Amz-Date=20141201T220302Z
&X-Amz-Expires=20141201T220302Z
&X-Amz-Signature=<signature>
&X-Amz-SignedHeaders=Host
Amazon ElastiCache allows you to control access to your clusters using ElastiCache security groups. An
ElastiCache security group acts like a firewall, controlling network access to your cluster. By default,
network access is turned off to your clusters. If you want your applications to access your cluster, you
must explicitly enable access from hosts in specific Amazon EC2 security groups. Once ingress rules are
configured, the same rules apply to all clusters associated with that security group.
To allow network access to your cluster, create a security group and use the
AuthorizeCacheSecurityGroupIngress API operation (CLI: authorize-cache-security-
group-ingress) to authorize the desired Amazon EC2 security group (which in turn specifies the
Amazon EC2 instances allowed). The security group can be associated with your cluster at the time of
creation, or using the ModifyCacheCluster API operation (CLI: modify-cache-cluster).
Important
Access control based on IP range is currently not enabled at the individual cluster level. All
clients to a cluster must be within the EC2 network, and authorized via security groups as
described previously.
For more information about using ElastiCache with Amazon VPCs, see Amazon VPCs and ElastiCache
security (p. 502).
Note that Amazon EC2 instances running in an Amazon VPC can't connect to ElastiCache clusters in EC2-
Classic.
Topics
• Creating a security group (p. 533)
• Listing available security groups (p. 535)
• Authorizing network access to an amazon EC2 security group (p. 537)
The following procedures show you how to create a new security group.
Example: mysecuritygroup
• --description – A description for this security group.
For Windows:
Example: mysecuritygroup
• Description – A URL encoded description for this security group.
Example: My%20security%20group
Example
https://elasticache.us-west-2.amazonaws.com /
?Action=CreateCacheSecurityGroup
&CacheSecurityGroupName=mysecuritygroup
&Description=My%20security%20group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20150202T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20150202T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
You can list which security groups have been created for your AWS account.
The following procedures show you how to list the available security groups for your AWS account.
JSON output from this command will look something like this.
{
"Marker": "Marker",
"CacheSecurityGroups": [
{
"OwnerId": "OwnerId",
"CacheSecurityGroupName": "CacheSecurityGroupName",
"Description": "Description",
"EC2SecurityGroups": [
{
"Status": "Status",
"EC2SecurityGroupName": "EC2SecurityGroupName",
"EC2SecurityGroupOwnerId": "EC2SecurityGroupOwnerId"
}
]
}
]
}
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheSecurityGroups
&MaxRecords=100
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20150202T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20150202T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
If you want to access your cluster from an Amazon EC2 instance, you must grant access to the Amazon
EC2 security group that the EC2 instance belongs to. The following procedures show you how to grant
access to an Amazon EC2 Security Group.
Important
• Authorizing an Amazon EC2 security group only grants access to your clusters from all EC2
instances belonging to the Amazon EC2 security group.
• It takes approximately one minute for changes to access permissions to take effect.
• --cache-security-group-name – the name of the security group you are granting Amazon EC2
access to.
• --ec2-security-group-name – the name of the Amazon EC2 security group that the Amazon EC2
instance belongs to.
• --ec2-security-group-owner-id – the id of the owner of the Amazon EC2 security group.
Example
For Linux, macOS, or Unix:
For Windows:
{
"CacheSecurityGroup": {
"OwnerId": "OwnerId",
"CacheSecurityGroupName": "CacheSecurityGroupName",
"Description": "Description",
"EC2SecurityGroups": [
{
"Status": "available",
"EC2SecurityGroupName": "EC2SecurityGroupName",
"EC2SecurityGroupOwnerId": "EC2SecurityGroupOwnerId"
}
]
}
}
• CacheSecurityGroupName – the name of the security group you are granting Amazon EC2 access to.
• EC2SecurityGroupName – the name of the Amazon EC2 security group that the Amazon EC2
instance belongs to.
• EC2SecurityGroupOwnerId – the id of the owner of the Amazon EC2 security group.
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=AuthorizeCacheSecurityGroupIngress
&EC2SecurityGroupOwnerId=987654321021
&EC2SecurityGroupName=myec2group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20150202T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20150202T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
Authentication
You can access AWS as any of the following types of identities:
• AWS account root user – When you first create an AWS account, you begin with a single sign-in
identity that has complete access to all AWS services and resources in the account. This identity is
called the AWS account root user and is accessed by signing in with the email address and password
that you used to create the account. We strongly recommend that you do not use the root user for
your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the
root user only to create your first IAM user. Then securely lock away the root user credentials and use
them to perform only a few account and service management tasks.
• IAM user – An IAM user is an identity within your AWS account that has specific custom permissions
(for example, permissions to create a cluster in ElastiCache). You can use an IAM user name and
password to sign in to secure AWS webpages like the AWS Management Console, AWS Discussion
Forums, or the AWS Support Center.
In addition to a user name and password, you can also generate access keys for each user. You can
use these keys when you access AWS services programmatically, either through one of the several
SDKs or by using the AWS Command Line Interface (CLI). The SDK and CLI tools use the access keys
to cryptographically sign your request. If you don’t use AWS tools, you must sign the request yourself.
ElastiCache supports Signature Version 4, a protocol for authenticating inbound API requests. For more
information about authenticating requests, see Signature Version 4 signing process in the AWS General
Reference.
• IAM role – An IAM role is an IAM identity that you can create in your account that has specific
permissions. An IAM role is similar to an IAM user in that it is an AWS identity with permissions policies
that determine what the identity can and cannot do in AWS. However, instead of being uniquely
associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role
does not have standard long-term credentials such as a password or access keys associated with it.
Instead, when you assume a role, it provides you with temporary security credentials for your role
session. IAM roles with temporary credentials are useful in the following situations:
• Federated user access – Instead of creating an IAM user, you can use existing identities from AWS
Directory Service, your enterprise user directory, or a web identity provider. These are known as
federated users. AWS assigns a role to a federated user when access is requested through an identity
provider. For more information about federated users, see Federated users and roles in the IAM User
Guide.
• AWS service access – A service role is an IAM role that a service assumes to perform actions on your
behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more
information, see Creating a role to delegate permissions to an AWS service in the IAM User Guide.
• Applications running on Amazon EC2 – You can use an IAM role to manage temporary credentials
for applications that are running on an EC2 instance and making AWS CLI or AWS API requests. This
is preferable to storing access keys within the EC2 instance. To assign an AWS role to an EC2 instance
and make it available to all of its applications, you create an instance profile that is attached to
the instance. An instance profile contains the role and enables programs that are running on the
EC2 instance to get temporary credentials. For more information, see Using an IAM role to grant
permissions to applications running on Amazon EC2 instances in the IAM User Guide.
Access control
You can have valid credentials to authenticate your requests, but unless you have permissions you cannot
create or access Amazon ElastiCache resources. For example, you must have permissions to create an
ElastiCache cache cluster.
The following sections describe how to manage permissions for Amazon ElastiCache. We recommend
that you read the overview first.
When granting permissions, you decide who is getting the permissions. You also decide the resources
they get permissions for and the specific actions that you want to allow on those resources.
Topics
• Amazon ElastiCache resources and operations (p. 541)
• Understanding resource ownership (p. 542)
• Managing access to resources (p. 542)
• Using identity-based policies (IAM policies) for Amazon ElastiCache (p. 545)
• Resource-level permissions (p. 549)
• Using condition keys (p. 550)
• Using Service-Linked Roles for Amazon ElastiCache (p. 566)
• ElastiCache API permissions: Actions, resources, and conditions reference (p. 572)
These resources have unique Amazon Resource Names (ARNs) associated with them as shown following.
Note
For resource-level permissions to be effective, the resource name on the ARN string should be
lower case.
Cluster arn:aws:elasticache:us-
east-2:123456789012:cluster:my-cluster
Snapshot arn:aws:elasticache:us-
east-2:123456789012:snapshot:my-snapshot
User arn:aws:elasticache:us-
east-2:123456789012:user:my-user
ElastiCache provides a set of operations to work with ElastiCache resources. For a list of available
operations, see Amazon ElastiCache Actions.
• Suppose that you use the root account credentials of your AWS account to create a cache cluster. In
this case, your AWS account is the owner of the resource. In ElastiCache, the resource is the cache
cluster.
• Suppose that you create an IAM user in your AWS account and grant permissions to create a cache
cluster to that user. In this case, the user can create a cache cluster. However, your AWS account, to
which the user belongs, owns the cache cluster resource.
• Suppose that you create an IAM role in your AWS account with permissions to create a cache cluster. In
this case, anyone who can assume the role can create a cache cluster. Your AWS account, to which the
role belongs, owns the cache cluster resource.
Policies attached to an IAM identity are referred to as identity-based policies (IAM policies). Policies
attached to a resource are referred to as resource-based policies.
Topics
• Identity-based policies (IAM policies) (p. 543)
• Specifying policy elements: Actions, effects, resources, and principals (p. 543)
• Specifying conditions in a policy (p. 544)
• Attach a permissions policy to a user or a group in your account – An account administrator can
use a permissions policy that is associated with a particular user to grant permissions. In this case,
the permissions are for that user to create an ElastiCache resource, such as a cache cluster, parameter
group, or security group.
• Attach a permissions policy to a role (grant cross-account permissions) – You can attach an
identity-based permissions policy to an IAM role to grant cross-account permissions. For example,
the administrator in Account A can create a role to grant cross-account permissions to another AWS
account (for example, Account B) or an AWS service as follows:
1. Account A administrator creates an IAM role and attaches a permissions policy to the role that
grants permissions on resources in Account A.
2. Account A administrator attaches a trust policy to the role identifying Account B as the principal
who can assume the role.
3. Account B administrator can then delegate permissions to assume the role to any users in Account
B. Doing this allows users in Account B to create or access resources in Account A. In some cases, you
might want to grant an AWS service permissions to assume the role. To support this approach, the
principal in the trust policy can also be an AWS service principal.
For more information about using IAM to delegate permissions, see Access Management in the IAM
User Guide.
The following is an example policy that allows a user to perform the DescribeCacheClusters action
for your AWS account. ElastiCache also supports identifying specific resources using the resource ARNs
for API actions. (This approach is also referred to as resource-level permissions).
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DescribeCacheClusters",
"Effect": "Allow",
"Action": [
"elasticache:DescribeCacheClusters"],
"Resource": resource-arn
}
]
}
For more information about using identity-based policies with ElastiCache, see Using identity-based
policies (IAM policies) for Amazon ElastiCache (p. 545). For more information about users, groups, roles,
and permissions, see Identities (Users, Groups, and Roles in the IAM User Guide.
ElastiCache defines a set of actions that you can specify in a policy. For example, for the ElastiCache
snapshot resource, the following actions are defined: CreateCacheCluster, DeleteCacheCluster,
and DescribeCacheCluster. Performing an API operation can require permissions for more than one
action.
• Resource – In a policy, you use an Amazon Resource Name (ARN) to identify the resource to which the
policy applies. For more information, see Amazon ElastiCache resources and operations (p. 541).
• Action – You use action keywords to identify resource operations that you want to allow or deny. For
example, depending on the specified Effect, the elasticache:CreateCacheCluster permission
allows or denies the user permissions to perform the Amazon ElastiCache CreateCacheCluster
operation.
• Effect – You specify the effect when the user requests the specific action—this can be either allow
or deny. If you don't explicitly grant access to (allow) a resource, access is implicitly denied. You can
also explicitly deny access to a resource. For example, you might do this to make sure that a user can't
access a resource, even if a different policy grants access.
• Principal – In identity-based policies (IAM policies), the user that the policy is attached to is the
implicit principal. For resource-based policies, you specify the user, account, service, or other entity
that you want to receive permissions (applies to resource-based policies only).
To learn more about IAM policy syntax and descriptions, see AWS IAM Policy Reference in the IAM User
Guide.
For a table showing all of the Amazon ElastiCache API actions, see ElastiCache API permissions: Actions,
resources, and conditions reference (p. 572).
To express conditions, you use predefined condition keys. To use ElastiCache-specific condition keys, see
Using condition keys (p. 550). There are AWS-wide condition keys that you can use as appropriate. For a
complete list of AWS-wide keys, see Available Keys for Conditions in the IAM User Guide.
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowClusterPermissions",
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup",
"elasticache:DescribeCacheClusters",
"elasticache:ModifyCacheCluster",
"elasticache:RebootCacheCluster"],
"Resource": "*"
},
{
"Sid": "AllowUserToPassRole",
"Effect": "Allow",
"Action": [ "iam:PassRole" ],
"Resource": "arn:aws:iam::123456789012:role/EC2-roles-for-cluster"
}
]
}
• The first statement grants permissions for the Amazon ElastiCache actions
(elasticache:CreateCacheCluster, elasticache:DescribeCacheClusters,
elasticache:ModifyCacheCluster, and elasticache:RebootCacheCluster) on any cache
cluster owned by the account.
• The second statement grants permissions for the IAM action (iam:PassRole) on the IAM role name
specified at the end of the Resource value.
The policy doesn't specify the Principal element because in an identity-based policy you don't specify
the principal who gets the permission. When you attach policy to a user, the user is the implicit principal.
When you attach a permissions policy to an IAM role, the principal identified in the role's trust policy gets
the permissions.
For a table showing all of the Amazon ElastiCache API actions and the resources that they apply to, see
ElastiCache API permissions: Actions, resources, and conditions reference (p. 572).
To use the Amazon ElastiCache console, first grant permissions for additional actions as shown in the
following permissions policy.
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "MinPermsForECConsole",
"Effect": "Allow",
"Action": [
"elasticache:Describe*",
"elasticache:List*",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeVpcs",
"ec2:DescribeAccountAttributes",
"ec2:DescribeSecurityGroups",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"s3:ListAllMyBuckets",
"sns:ListTopics",
"sns:ListSubscriptions" ],
"Resource": "*"
}
]
}
The ElastiCache console needs these additional permissions for the following reasons:
• Permissions for the ElastiCache actions enable the console to display ElastiCache resources in the
account.
• The console needs permissions for the ec2 actions to query Amazon EC2 so it can display Availability
Zones, VPCs, security groups, and account attributes.
• The permissions for cloudwatch actions enable the console to retrieve Amazon CloudWatch metrics
and alarms, and display them in the console.
• The permissions for sns actions enable the console to retrieve Amazon Simple Notification Service
(Amazon SNS) topics and subscriptions, and display them in the console.
The following AWS managed policies, which you can attach to users in your account, are specific to
ElastiCache:
Note
You can review these permissions policies by signing in to the IAM console and searching for
specific policies there.
You can also create your own custom IAM policies to allow permissions for Amazon ElastiCache API
actions. You can attach these custom policies to the IAM users or groups that require those permissions.
When combined with the minimum permissions needed to use the Amazon ElastiCache console, the
example policies in this section grant additional permissions. The examples are also relevant to the AWS
SDKs and the AWS CLI. For more information about what permissions are needed to use the ElastiCache
console, see Permissions required to use the Amazon ElastiCache console (p. 546).
For instructions on setting up IAM users and groups, see Creating Your First IAM User and Administrators
Group in the IAM User Guide.
Important
Always test your IAM policies thoroughly before using them in production. Some ElastiCache
actions that appear simple can require other actions to support them when you are using the
ElastiCache console. For example, elasticache:CreateCacheCluster grants permissions to
create ElastiCache cache clusters. However, to perform this operation, the ElastiCache console
uses a number of Describe and List actions to populate console lists.
Examples
• Example 1: Allow a user to create and manage security groups (p. 547)
• Example 2: Allow a user read-only access to ElastiCache resources (p. 547)
• Example 3: Allow a user to perform common ElastiCache system administrator tasks (p. 548)
• Example 4: Allow a user to access all ElastiCache API actions (p. 548)
• Example 5: Allow a user to call IAM CreateServiceLinkedRole API (p. 548)
{
"Version": "2012-10-17",
"Statement":[{
"Sid": "SecGrpAllows",
"Effect":"Allow",
"Action":[
"elasticache:CreateCacheSecurityGroup",
"elasticache:DeleteCacheSecurityGroup",
"elasticache:DescribeCacheSecurityGroup",
"elasticache:AuthorizeCacheSecurityGroupIngress",
"elasticache:RevokeCacheSecurityGroupIngress"],
"Resource":"*"
}
]
}
"Version": "2012-10-17",
"Statement":[{
"Sid": "ECUnrestricted",
"Effect":"Allow",
"Action": [
"elasticache:Describe*",
"elasticache:List*"],
"Resource":"*"
}
]
}
Common system administrator tasks include modifying cache clusters, parameters, and parameter
groups. A system administrator may also want to get information about the ElastiCache events. The
following policy grants a user permissions to perform ElastiCache actions for these common system
administrator tasks. Typically, you attach this type of permissions policy to the system administrators
group.
{
"Version": "2012-10-17",
"Statement":[{
"Sid": "ECAllowSpecific",
"Effect":"Allow",
"Action":[
"elasticache:ModifyCacheCluster",
"elasticache:RebootCacheCluster",
"elasticache:DescribeCacheClusters",
"elasticache:DescribeEvents",
"elasticache:ModifyCacheParameterGroup",
"elasticache:DescribeCacheParameterGroups",
"elasticache:DescribeCacheParameters",
"elasticache:ResetCacheParameterGroup",
"elasticache:DescribeEngineDefaultParameters"],
"Resource":"*"
}
]
}
The following policy allows a user to access all ElastiCache actions. We recommend that you grant this
type of permissions policy only to an administrator user.
{
"Version": "2012-10-17",
"Statement":[{
"Sid": "ECAllowSpecific",
"Effect":"Allow",
"Action":[
"elasticache:*" ],
"Resource":"*"
}
]
}
The following policy allows user to call the IAM CreateServiceLinkedRole API. We recommend that
you grant this type of permissions policy to the user who invokes mutative ElastiCache operations.
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"CreateSLRAllows",
"Effect":"Allow",
"Action":[
"iam:CreateServiceLinkedRole"
],
"Resource":"*",
"Condition":{
"StringLike":{
"iam:AWSServiceName":"elasticache.amazonaws.com"
}
}
}
]
}
Resource-level permissions
You can restrict the scope of permissions by specifying resources in an IAM policy. Many Elasticache API
actions support a resource type that varies depending on the behavior of the action. Every IAM policy
statement grants permission to an action that's performed on a resource. When the action doesn't act on
a named resource, or when you grant permission to perform the action on all resources, the value of the
resource in the policy is a wildcard (*). For many API actions, you can restrict the resources that a user can
modify by specifying the Amazon Resource Name (ARN) of a resource, or an ARN pattern that matches
multiple resources. To restrict permissions by resource, specify the resource by ARN.
Examples
• Example 1: Allow a user full access to specific ElastiCache resource types (p. 550)
• Example 2: Deny a user access to a replication group. (p. 550)
{
"Sid": "Example1",
"Effect": "Allow",
"Action": "elasticache:*",
"Resource": [
"arn:aws:elasticache:us-east-1:account-id:subnetgroup:*",
"arn:aws:elasticache:us-east-1:account-id:securitygroup:*",
"arn:aws:elasticache:us-east-1:account-id:replicationgroup:*"
]
}
{
"Sid": "Example2",
"Effect": "Deny",
"Action": "elasticache:*",
"Resource": [
"arn:aws:elasticache:us-east-1:account-id:replicationgroup:name"
]
}
To apply a condition, you add the condition information to the IAM policy statement. In the
following example, you specify the condition that any cache cluster created will be of node type
cache.r5.large.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster"
],
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"StringEquals": {
"elasticache:CacheNodeType": [
"cache.r5.large"
]
}
}
}
]
}
The following table shows the service-specific condition keys that apply to ElastiCache and the actions
that use them.
Key
Description
Datatype Used by Affected resource type (* If
name marked with an asterisk, only
this resource will be affected if
present in the request.)
Filters
elasticache:CacheNodeType
String CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the CreateCacheCluster Cluster,
cacheNodeType ReplicationGroup*
parameter
ModifyReplicationGroup ReplicationGroup
present
in ModifyCacheClusters Cluster
the
request. ModifyGlobalReplicationGroup
GlobalReplicationGroup
This
key
can
be
used
to
restrict
which
cache
node
types
can
be
used
on
cluster
creation
or
scaling
operations.
Key
Description
Datatype Used by Affected resource type (* If
name marked with an asterisk, only
this resource will be affected if
present in the request.)
Filters
elasticache:NumNodeGroups
Number CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the ModifyReplicationGroupShardConfiguration
ReplicationGroup
NumNodeGroups
IncreaseNodeGroupsInGlobalReplicationGroup
GlobalReplicationGroup
or
NodeGroupCount DecreaseNodeGroupsInGlobalReplicationGroup
GlobalReplicationGroup
parameter
specified
in
the
request.
This
key
can
be
used
to
restrict
the
number
of
node
groups
(shards)
clusters
can
have
after
creation
or
scaling
operations.
Filters
elasticache:ReplicasPerNodeGroup
Number CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the CreateCacheCluster Cluster
number
IncreaseReplicaCount ReplicationGroup
of
replicas DecreaseReplicaCount ReplicationGroup
per
node
group
(shards)
specified
in
creations
or
scaling
requests.
Key
Description
Datatype Used by Affected resource type (* If
name marked with an asterisk, only
this resource will be affected if
present in the request.)
Filters
elasticache:EngineVersion
String CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the CreateCacheCluster Cluster,
engineVersion ReplicationGroup*
parameter
ModifyReplicationGroup ReplicationGroup
present
in ModifyCacheClusters Cluster
creation
or ModifyGlobalReplicationGroup
GlobalReplicationGroup
cluster
modification
requests.
Filters
elasticache:EngineType
String CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the CreateCacheCluster Cluster,
engine ReplicationGroup*
type
present
in
creation
requests.
For
replication
group
creations,
default
engine
"redis"
is
used
as
key
if
parameter
is
not
present.
Key
Description
Datatype Used by Affected resource type (* If
name marked with an asterisk, only
this resource will be affected if
present in the request.)
Filters
elasticache:AutomaticFailoverEnabled
Bool CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the ModifyReplicationGroup ReplicationGroup
AutomaticFailoverEnabled
ModifyGlobalReplicationGroup
GlobalReplicationGroup
parameter
present
in
the
request
or
default
false
value
if
parameter
is
not
present.
Filters
elasticache:AtRestEncryptionEnabled
Bool CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the
AtRestEncryptionEnabled
parameter
present
in
the
request
or
default
false
value
if
parameter
is
not
present.
Key
Description
Datatype Used by Affected resource type (* If
name marked with an asterisk, only
this resource will be affected if
present in the request.)
Filters
elasticache:TransitEncryptionEnabled
Bool CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the
TransitEncryptionEnabled
parameter
present
in
the
request
or
default
false
value
if
parameter
is
not
present.
Filters
elasticache:MultiAZEnabled
Bool CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the CreateCacheCluster Cluster,
AZMode ReplicationGroup*
parameter,
ModifyReplicationGroup ReplicationGroup
MultiAZEnabled
parameter ModifyCacheClusters Cluster
or
the ModifyGlobalReplicationGroup
GlobalReplicationGroup
number
of
availability
zones
that
the
cluster
or
replication
group
can
be
placed.
Key
Description
Datatype Used by Affected resource type (* If
name marked with an asterisk, only
this resource will be affected if
present in the request.)
Filters
elasticache:ClusterModeEnabled
Bool CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the
clustermode
parameter
present
in
the
request.
Default
value
for
single-
node
group
(shard)
creations
is
false.
Filters
elasticache:AuthTokenEnabled
Bool CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the CreateCacheCluster Cluster,
presence ReplicationGroup*
of
ModifyReplicationGroup ReplicationGroup
non
empty ModifyCacheClusters Cluster
AuthToken
parameter ModifyGlobalReplicationGroup
GlobalReplicationGroup
in
the
request.
Filters
elasticache:SnapshotRetentionLimit
Number CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the CreateCacheCluster Cluster,
SnapshotRetentionLimit ReplicationGroup*
parameter
ModifyReplicationGroup ReplicationGroup
in
the ModifyCacheClusters Cluster
request.
ModifyGlobalReplicationGroup
GlobalReplicationGroup
Key
Description
Datatype Used by Affected resource type (* If
name marked with an asterisk, only
this resource will be affected if
present in the request.)
Filters
elasticache:KmsKeyId
String CreateSnapshot Snapshot
access
by CopySnapshot Snapshot
the
CreateReplicationGroup ReplicationGroup,
KmsKeyId
GlobalReplicationGroup*
parameter
in
the
request.
Filters
elasticache:CacheParameterGroupName
String CreateReplicationGroup ReplicationGroup,
access GlobalReplicationGroup*
by
the CreateCacheCluster Cluster,
the ReplicationGroup*
CacheParameterGroupName
ModifyReplicationGroup ReplicationGroup
parameter
in ModifyCacheClusters Cluster
the
request. CreateCacheParameterGroup ParameterGroup
ModifyCacheParameterGroup ParameterGroup
DeleteCacheParameterGroup ParameterGroup
ResetCacheParameterGroup ParameterGroup
For more information on using policy condition operators, see ElastiCache API permissions: Actions,
resources, and conditions reference (p. 572).
1. elasticache:CacheNodeType: Specify which NodeType(s) a user can create. Using the provided
conditions, the customer can specify a single or a range value for a node type.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster"
],
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"StringEquals": {
"elasticache:CacheNodeType": [
"cache.t2.micro",
"cache.t2.medium"
]
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"NumericLessThanEquals": {
"elasticache:NumNodeGroups": "20"
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"NumericGreaterThanEquals": {
"elasticache:ReplicasPerNodeGroup": "5"
},
"NumericLessThanEquals": {
"elasticache:ReplicasPerNodeGroup": "10"
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster"
],
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"StringEquals": {
"elasticache:EngineVersion": "5.0.6"
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster"
],
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"StringEquals": {
"elasticache:EngineType": "redis"
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"Bool": {
"elasticache:AtRestEncryptionEnabled": "true"
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"Bool": {
"elasticache:TransitEncryptionEnabled": "false"
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"Bool": {
"elasticache:AutomaticFailoverEnabled": "true"
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Deny",
"Action": [
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"Bool": {
"elasticache:MultiAZEnabled": "false"
}
}
}
]
}
10.elasticache:ClusterModeEnabled: Specify that replication groups can only be created with cluster
mode enabled.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
"Effect": "Allow",
"Action": [
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"Bool": {
"elasticache:ClusterModeEnabled": "true"
}
}
}
]
}
11.elasticache:AuthTokenEnabled: Specify that replication groups can only be created with AUTH
token enabled.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"Bool": {
"elasticache:AuthTokenEnabled": "true"
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"NumericGreaterThanEquals": {
"elasticache:SnapshotRetentionLimit": "30"
}
}
}
]
}
13.elasticache:KmsKeyId: Specify usage of customer managed AWS KMS keys. This key would
complement the At-Rest Encryption one.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"StringEquals": {
"elasticache:KmsKeyId": "my-key"
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"StringEquals": {
"elasticache:CacheParameterGroupName": "my-org-param-group"
}
}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:CreateReplicationGroup"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster"
],
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"StringEqualsIfExists": {
"elasticache:CacheNodeType": [
"cache.r5.large",
"cache.r6g.4xlarge"
]
},
"StringEquals": {
"aws:RequestTag/Project": "XYZ"
}
}
}
]
}
Note
When creating polices to enforce tags and other condition keys together, the
conditional IfExists may be required on condition key elements due to the extra
elasticache:AddTagsToResource policy requirements for creation requests with the --
tags parameter.
A service-linked role makes setting up Amazon ElastiCache easier because you don’t have to manually
add the necessary permissions. The roles already exist within your AWS account but are linked to Amazon
ElastiCache use cases and have predefined permissions. Only Amazon ElastiCache can assume these
roles, and only these roles can use the predefined permissions policy. You can delete the roles only after
first deleting their related resources. This protects your Amazon ElastiCache resources because you can't
inadvertently remove necessary permissions to access the resources.
For information about other services that support service-linked roles, see AWS Services That Work with
IAM and look for the services that have Yes in the Service-Linked Role column. Choose a Yes with a link
to view the service-linked role documentation for that service.
Contents
• Service-Linked Role Permissions for Amazon ElastiCache (p. 566)
• Creating a Service-Linked Role (IAM) (p. 568)
• Creating a Service-Linked Role (IAM Console) (p. 568)
• Creating a Service-Linked Role (IAM CLI) (p. 568)
• Creating a Service-Linked Role (IAM API) (p. 568)
• Editing the Description of a Service-Linked Role for Amazon ElastiCache (p. 568)
• Editing a Service-Linked Role Description (IAM Console) (p. 568)
• Editing a Service-Linked Role Description (IAM CLI) (p. 569)
• Editing a Service-Linked Role Description (IAM API) (p. 569)
• Deleting a Service-Linked Role for Amazon ElastiCache (p. 570)
• Cleaning Up a Service-Linked Role (p. 570)
• Deleting a Service-Linked Role (IAM Console) (p. 570)
• Deleting a Service-Linked Role (IAM CLI) (p. 571)
• Deleting a Service-Linked Role (IAM API) (p. 571)
Permission policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateNetworkInterface",
"ec2:CreateSecurityGroup",
"ec2:DeleteNetworkInterface",
"ec2:DeleteSecurityGroup",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:RevokeSecurityGroupIngress",
"cloudwatch:PutMetricData",
"outposts:GetOutpost",
"outposts:GetOutpostInstanceTypes",
"outposts:ListOutposts",
"outposts:ListSites",
"application-autoscaling:DeregisterScalableTarget",
"application-autoscaling:DescribeScalableTargets"
],
"Resource": "*"
}
]
}
Add the following policy statement to the permissions for that IAM entity:
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/elasticache.amazonaws.com/
AWSServiceRoleForElastiCache*",
"Condition": {"StringLike": {"iam:AWSServiceName": "elasticache.amazonaws.com"}}
}
Add the following policy statement to the permissions for that IAM entity:
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/elasticache.amazonaws.com/
AWSServiceRoleForElastiCache*",
"Condition": {"StringLike": {"iam:AWSServiceName": "elasticache.amazonaws.com"}}
}
Alternatively, you can use an AWS managed policy to provide full access to Amazon ElastiCache.
1. Sign in to the AWS Management Console and open the IAM console at https://
console.aws.amazon.com/iam/.
2. In the navigation pane of the IAM console, choose Roles. Then choose Create new role.
3. Under Select type of trusted entity choose AWS Service.
4. Under Or select a service to view its use cases, choose ElastiCache.
5. Choose Next: Permissions.
6. Under Policy name, note that the ElastiCacheServiceRolePolicy is required for this role.
Choose Next:Tags.
7. Note that tags are not supported for Service-Linked roles. Choose Next:Review.
8. (Optional) For Role description, edit the description for the new service-linked role.
9. Review the role and then choose Create role.
You can use IAM operations from the AWS Command Line Interface to create a service-linked role. This
role can include the trust policy and inline policies that the service needs to assume the role.
You can use the IAM API to create a service-linked role. This role can contain the trust policy and inline
policies that the service needs to assume the role.
Use the CreateServiceLinkedRole API call. In the request, specify a service name of
elasticache.amazonaws.com.
You can use the IAM console to edit a service-linked role description.
You can use IAM operations from the AWS Command Line Interface to edit a service-linked role
description.
1. (Optional) To view the current description for a role, use the AWS CLI for IAM operation get-role.
Example
Use the role name, not the ARN, to refer to roles with the CLI operations. For example, if a role has
the following ARN: arn:aws:iam::123456789012:role/myrole, refer to the role as myrole.
2. To update a service-linked role's description, use the AWS CLI for IAM operation update-role-
description.
For Windows:
You can use the IAM API to edit a service-linked role description.
1. (Optional) To view the current description for a role, use the IAM API operation GetRole.
Example
https://iam.amazonaws.com/
?Action=GetRole
&RoleName=AWSServiceRoleForElastiCache
&Version=2010-05-08
&AUTHPARAMS
Example
https://iam.amazonaws.com/
?Action=UpdateRoleDescription
&RoleName=AWSServiceRoleForElastiCache
&Version=2010-05-08
&Description="New description"
Amazon ElastiCache does not delete the service-linked role for you.
Before you can use IAM to delete a service-linked role, first confirm that the role has no resources
(clusters or replication groups) associated with it.
To check whether the service-linked role has an active session in the IAM console
1. Sign in to the AWS Management Console and open the IAM console at https://
console.aws.amazon.com/iam/.
2. In the navigation pane of the IAM console, choose Roles. Then choose the name (not the check box)
of the AWSServiceRoleForElastiCache role.
3. On the Summary page for the selected role, choose the Access Advisor tab.
4. On the Access Advisor tab, review recent activity for the service-linked role.
1. Sign in to the AWS Management Console and open the IAM console at https://
console.aws.amazon.com/iam/.
2. In the navigation pane of the IAM console, choose Roles. Then select the check box next to the role
name that you want to delete, not the name or row itself.
3. For Role actions at the top of the page, choose Delete role.
4. In the confirmation dialog box, review the service last accessed data, which shows when each of the
selected roles last accessed an AWS service. This helps you to confirm whether the role is currently
active. If you want to proceed, choose Yes, Delete to submit the service-linked role for deletion.
5. Watch the IAM console notifications to monitor the progress of the service-linked role deletion.
Because the IAM service-linked role deletion is asynchronous, after you submit the role for deletion,
the deletion task can succeed or fail. If the task fails, you can choose View details or View Resources
from the notifications to learn why the deletion failed.
You can use IAM operations from the AWS Command Line Interface to delete a service-linked role.
1. If you don't know the name of the service-linked role that you want to delete, enter the following
command. This command lists the roles and their Amazon Resource Names (ARNs) in your account.
Use the role name, not the ARN, to refer to roles with the CLI operations. For example, if a role has
the ARN arn:aws:iam::123456789012:role/myrole, you refer to the role as myrole.
2. Because a service-linked role cannot be deleted if it is being used or has associated resources, you
must submit a deletion request. That request can be denied if these conditions are not met. You
must capture the deletion-task-id from the response to check the status of the deletion task.
Enter the following to submit a service-linked role deletion request.
The status of the deletion task can be NOT_STARTED, IN_PROGRESS, SUCCEEDED, or FAILED. If the
deletion fails, the call returns the reason that it failed so that you can troubleshoot.
1. To submit a deletion request for a service-linked roll, call DeleteServiceLinkedRole. In the request,
specify a role name.
Because a service-linked role cannot be deleted if it is being used or has associated resources, you
must submit a deletion request. That request can be denied if these conditions are not met. You
must capture the DeletionTaskId from the response to check the status of the deletion task.
2. To check the status of the deletion, call GetServiceLinkedRoleDeletionStatus. In the request, specify
the DeletionTaskId.
The status of the deletion task can be NOT_STARTED, IN_PROGRESS, SUCCEEDED, or FAILED. If the
deletion fails, the call returns the reason that it failed so that you can troubleshoot.
You can use condition keys in your ElastiCache policies to express conditions. To see a list of ElastiCache-
specific condition keys, along with the actions and resource types to which they apply, see Using
condition keys (p. 550). For a complete list of AWS-wide keys, see Available Keys for Conditions in the
IAM User Guide.
Note
To specify an action, use the elasticache: prefix followed by the API operation name (for
example, elasticache:DescribeCacheClusters).
AddTagsToResource
Action: elasticache:AddTagsToResource
Resource: *
AuthorizeCacheSecurityGroupIngress
Action: elasticache:AuthorizeCacheSecurityGroupIngress
Resource: *
BatchApplyUpdateAction
Action: elasticache:BatchApplyUpdateAction
Resource: arn:aws:elasticache:us-east-1:account-id:replicationgroup:*
BatchStopUpdateAction
Action: elasticache:BatchStopUpdateAction
Resource: arn:aws:elasticache:us-east-1:account-id:replicationgroup:*
CompleteMigration
Action: elasticache:CompleteMigration
Resource: *
CopySnapshot
Action: elasticache:CopySnapshot
Resource: *
CreateCacheCluster
Actions: elasticache:CreateCacheCluster
s3:GetObject
Note
If you use the SnapshotArns parameter, each member of the SnapshotArns list requires
its own s3:GetObject permission with the s3 ARN as its resource.
Resource: *
arn:aws:s3:::my_bucket/snapshot1.rdb
Where my_bucket/snapshot1 is an S3 bucket and snapshot that you want to create the cache
cluster from.
CreateCacheParameterGroup
Action: elasticache:CreateCacheParameterGroup
Resource: *
CreateCacheSecurityGroup
Action: elasticache:CreateCacheSecurityGroup
Resource: *
CreateCacheSubnetGroup
Action: elasticache:CreateCacheSubnetGroup
Resource: *
CreateGlobalReplicationGroup
Action: elasticache:CreateGlobalReplicationGroup
Resource: *
CreateReplicationGroup
Action: elasticache:CreateReplicationGroup
s3:GetObject
Note
If you use the SnapshotArns parameter, each member of the SnapshotArns list requires
its own s3:GetObject permission with the s3 ARN as its resource.
Resource: *
arn:aws:s3:::my_bucket/snapshot1.rdb
Where my_bucket/snapshot1 is an S3 bucket and snapshot that you want to create the cache
cluster from.
CreateSnapshot
Action: elasticache:CreateSnapshot
Resource: *
DecreaseNodeGroupsInGlobalReplicationGroup
Action: elasticache:DecreaseNodeGroupsInGlobalReplicationGroup
Resource: *
DecreaseReplicaCount
Action: elasticache:DecreaseReplicaCount
Resource: *
DeleteCacheCluster
Action: elasticache:DeleteCacheCluster
Resource: *
DeleteCacheParameterGroup
Action: elasticache:DeleteCacheParameterGroup
Resource: *
DeleteCacheSecurityGroup
Action: elasticache:DeleteCacheSecurityGroup
Resource: *
DeleteCacheSubnetGroup
Action: elasticache:DeleteCacheSubnetGroup
Resource: *
DeleteGlobalReplicationGroup
Action: elasticache:DeleteGlobalReplicationGroup
Resource: *
DeleteReplicationGroup
Action: elasticache:DeleteReplicationGroup
Resource: *
DeleteSnapshot
Action: elasticache:DeleteSnapshot
Resource: *
DescribeCacheClusters
Action: elasticache:DescribeCacheClusters
Resource: *
DescribeCacheEngineVersions
Actions: elasticache:DescribeCacheEngineVersions
Resource: *
DescribeCacheParameterGroups
Action: elasticache:DescribeCacheParameterGroups
Resource: *
DescribeCacheParameters
Action: elasticache:DescribeCacheParameters
Resource: *
DescribeCacheSecurityGroups
Action: elasticache:DescribeCacheSecurityGroups
Resource: *
DescribeCacheSubnetGroups
Action: elasticache:DescribeCacheSubnetGroups
Resource: *
DescribeEngineDefaultParameters
Action: elasticache:DescribeEngineDefaultParameters
Resource: *
DescribeEvents
Action: elasticache:DescribeEvents
Resource: *
DescribeGlobalReplicationGroups
Action: elasticache:DescribeGlobalReplicationGroups
Resource: *
DescribeReplicationGroups
Action: elasticache:DescribeReplicationGroups
Resource: *
DescribeReservedCacheNodes
Action: elasticache:DescribeReservedCacheNodes
Resource: *
DescribeReservedCacheNodesOfferings
Action: elasticache:DescribeReservedCacheNodesOfferings
Resource: *
DescribeSnapshots
Action: elasticache:DescribeSnapshots
Resource: *
DescribeUpdateActions
Action: elasticache:DescribeUpdateActions
Resource: *
DisassociateGlobalReplicationGroup
Action: elasticache:DisassociateGlobalReplicationGroup
Resource: *
FailoverGlobalReplicationGroup
Action: elasticache:FailoverGlobalReplicationGroup
Resource: *
IncreaseNodeGroupsInGlobalReplicationGroup
Action: elasticache:IncreaseNodeGroupsInGlobalReplicationGroup
Resource: *
IncreaseReplicaCount
Action: elasticache:IncreaseReplicaCount
Resource: *
ListAllowedNodeTypeModifications
Action: elasticache:ListAllowedNodeTypeModifications
Resource: *
ListTagsForResource
Action: elasticache:ListTagsForResource
Resource: *
ModifyCacheCluster
Action: elasticache:ModifyCacheCluster
Resource: *
ModifyCacheParameterGroup
Action: elasticache:ModifyCacheParameterGroup
Resource: *
ModifyCacheSubnetGroup
Action: elasticache:ModifyCacheSubnetGroup
Resource: *
ModifyGlobalReplicationGroup
Action: elasticache:ModifyGlobalReplicationGroup
Resource: *
ModifyReplicationGroup
Action: elasticache:ModifyReplicationGroup
Resource: *
PurchaseReservedCacheNodesOffering
Action: elasticache:PurchaseReservedCacheNodesOffering
Resource: *
RebootCacheCluster
Action: elasticache:RebootCacheCluster
Resource: *
RemoveTagsFromResource
Action: elasticache:RemoveTagsFromResource
Resource: *
ResetCacheParameterGroup
Action: elasticache:ResetCacheParameterGroup
Resource: *
RevokeCacheSecurityGroupIngress
Action: elasticache:RevokeCacheSecurityGroupIngress
Resource: *
StartMigration
Action: elasticache:StartMigration
Resource: *
TestFailover
Action: elasticache:TestFailover
Resource: *
Amazon CloudWatch provides metrics for monitoring your cache performance. In addition, cost
allocation tags help you monitor and manage costs.
Topics
• Log delivery (p. 578)
• Monitoring use with CloudWatch Metrics (p. 587)
• Logging Amazon ElastiCache API calls with AWS CloudTrail (p. 603)
• Monitoring ElastiCache events (p. 606)
Log delivery
Note
Redis Slow Log is supported for Redis cache clusters and replication groups using engine version
6.0 onward.
Redis Engine Log is supported for Redis cache clusters and replication groups using engine
version 6.2 onward.
Log delivery lets you stream Redis SLOWLOG or Redis Engine Log to one of two destinations:
You enable and configure log delivery when you create or modify a cluster using ElastiCache APIs. Each
log entry will be delivered to the specified destination in one of two formats: JSON or TEXT.
A fixed number of Slow log entries are retrieved from the Redis engine periodically. Depending on the
value specified for engine parameter slowlog-max-len, additional slow log entries might not be
delivered to the destination.
You can choose to change the delivery configurations or disable log delivery at any time using the AWS
console or one of the modify APIs, either modify-cache-cluster or modify-replication-group.
You must set the apply-immediately parameter for all log delivery modifications.
Note
Amazon CloudWatch Logs charges apply when log delivery is enabled, even when logs are
delivered directly to Amazon Kinesis Data Firehose. For more information, see Vended Logs
section in Amazon CloudWatch Pricing.
• Role – Role of the node from where the log is emitted. It can be one of the following: “M” for Primary
and “S” for replica.
• Message – Redis Engine log message.
• logs:CreateLogDelivery
• logs:UpdateLogDelivery
• logs:DeleteLogDelivery
• logs:GetLogDelivery
• logs:ListLogDeliveries
For more information, see Overview of access management: Permissions and policies.
{
"CacheClusterId": "logslowxxxxmsxj",
"CacheNodeId": "0001",
"Id": 296,
"Timestamp": 1605631822,
"Duration (us)": 0,
"Command": "GET ... (1 more arguments)",
"ClientAddress": "192.168.12.104:55452",
"ClientName": "logslowxxxxmsxj##"
}
Engine log
Engine log supports both JSON and TEXT
{
"CacheClusterId": "xxxxxxxxxzy-engine-log-test",
"CacheNodeId": "0001",
"LogLevel": "VERBOSE",
"Role": "M",
"Time": "12 Nov 2020 01:28:57.994 UTC",
"Message": "Replica is waiting for next BGSAVE before synchronizing with the primary.
Check back later"
Topics
• Amazon CloudWatch Logs (p. 580)
• Amazon Kinesis Data Firehose (p. 581)
You must have the following permissions settings to configure ElastiCache for Redis to send logs to a
CloudWatch Logs log group:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries"
],
"Resource": [
"*"
],
"Effect": "Allow",
"Sid": "ElastiCacheLogging"
},
{
"Sid": "ElastiCacheLoggingCWL",
"Action": [
"logs:PutResourcePolicy",
"logs:DescribeResourcePolicies",
"logs:DescribeLogGroups"
],
"Resource": [
"*"
],
"Effect": "Allow"
}
]
}
You must have the following permissions to configure ElastiCache for Redis to send logs to an Amazon
Kinesis Data Firehose delivery stream.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries"
],
"Resource": [
"*"
],
"Effect": "Allow",
"Sid": "ElastiCacheLogging"
},
{
"Sid": "ElastiCacheLoggingFHSLR",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Sid": "ElastiCacheLoggingFH",
"Action": [
"firehose:TagDeliveryStream"
],
"Resource": "Amazon Kinesis Data Firehose delivery stream ARN",
"Effect": "Allow"
}
]
}
1. Under Advanced Redis settings, choose Logs and then check either Slow logs or Engine logs.
2. Under Log format, choose either Text or JSON.
3. Under Destination Type, choose either CloudWatch Logs or Kinesis Firehose.
4. Under Log destination, choose either Create new and enter either your Amazon S3 bucket name,
CloudWatchLogs log group name or your Kinesis Data Firehose stream name, or choose Select
existing and then choose either your CloudWatch Logs group name or your Kinesis Data Firehose
stream name,
You can choose to either enable/disable log delivery or change either the destination type, format or
destination:
"LogGroup":"my-log-group"
}
},
"LogFormat":"json"
}'
For Windows:
"LogGroup":"my-log-group"
}
},
"LogFormat":"json"
}'
For Windows:
For Windows:
Engine Log
For Windows:
}
},
"LogFormat":"json"
}'
For Windows:
For Windows:
"LogType":"engine-log",
"LogFormat":"json"
}'
For Windows:
ElastiCache provides both host-level metrics (for example, CPU usage) and metrics that are specific to
the cache engine software (for example, cache gets and cache misses). These metrics are measured and
published for each Cache node in 60-second intervals.
Important
You should consider setting CloudWatch alarms on certain key metrics, so that you will be
notified if your cache cluster's performance starts to degrade. For more information, see Which
Metrics Should I Monitor? (p. 597) in this guide.
Topics
• Host-Level Metrics (p. 587)
• Metrics for Redis (p. 589)
• Which Metrics Should I Monitor? (p. 597)
• Choosing Metric Statistics and Periods (p. 600)
• Monitoring CloudWatch Cluster and Node Metrics (p. 600)
Host-Level Metrics
The AWS/ElastiCache namespace includes the following host-level metrics for individual cache nodes.
See Also
CPUCreditUsage The number of CPU credits spent by the instance Credits (vCPU-
for CPU utilization. One CPU credit equals minutes)
one vCPU running at 100% utilization for one
minute or an equivalent combination of vCPUs,
utilization, and time (for example, one vCPU
running at 50% utilization for two minutes or
two vCPUs running at 25% utilization for two
minutes).
NetworkBytesIn The number of bytes the host has read from the Bytes
network.
With the exception of ReplicationLag and EngineCPUUtilization, these metrics are derived from
the Redis info command. Each metric is calculated at the cache node level.
See Also
BytesReadFromDisk The total number of bytes read from disk per Bytes
minute. Supported only for clusters using Data
tiering (p. 121).
Evictions The number of keys that have been evicted due Count
to the maxmemory limit. This is derived from the
evicted_keys statistic at Redis INFO.
NumItemsReadFromDisk The total number of items retrieved from disk per Count
minute. Supported only for clusters using Data
tiering (p. 121).
EngineCPUUtilization availability
AWS Regions listed following are available on all supported node types.
Region Region name
Region Region name
eu-west-3 EU (Paris)
The following are aggregations of certain kinds of commands, derived from info commandstats.
The commandstats section provides statistics based on the command type, including the number
of calls, the total CPU time consumed by these commands, and the average CPU consumed
per command execution. For each command type, the following line is added: cmdstat_XXX:
calls=XXX,usec=XXX,usec_per_call=XXX.
The latency metrics listed following are calculated using commandstats statistic from Redis INFO. They
are calculated in the following way: delta(usec)/delta(calls). delta is calculated as the diff
within one minute. Latency is defined as CPU time taken by ElastiCache to process the command. Note
that for clusters using data tiering, the time taken to fetch items from SSD is not included in these
measurements.
For a full list of available commands, see redis commands in the Redis documentation.
Metrics to Monitor
• CPUUtilization (p. 597)
• EngineCPUUtilization (p. 597)
• SwapUsage (p. 598)
• Evictions (p. 598)
• CurrConnections (p. 598)
• Memory (p. 598)
• Network (p. 598)
• Latency (p. 598)
• Replication (p. 598)
CPUUtilization
This is a host-level metric reported as a percentage. For more information, see Host-Level
Metrics (p. 587).
For smaller node types with 2vCPUs or less, use the CPUUtilization metric to monitor your
workload.
Generally speaking, we suggest you set your threshold at 90% of your available CPU. Because Redis
is single-threaded, the actual threshold value should be calculated as a fraction of the node's total
capacity. For example, suppose you are using a node type that has two cores. In this case, the threshold
for CPUUtilization would be 90/2, or 45%.
You will need to determine your own threshold, based on the number of cores in the cache node that
you are using. If you exceed this threshold, and your main workload is from read requests, scale your
cache cluster out by adding read replicas. If the main workload is from write requests, depending on your
cluster configuration, we recommend that you:
• Redis (cluster mode disabled) clusters: scale up by using a larger cache instance type.
• Redis (cluster mode enabled) clusters: add more shards to distribute the write workload across more
primary nodes.
Tip
Instead of using the Host-Level metric CPUUtilization, Redis users might be able to use
the Redis metric EngineCPUUtilization, which reports the percentage of usage on the
Redis engine core. To see if this metric is available on your nodes and for more information, see
Metrics for Redis.
For larger node types with 4vCPUs or more, you may want to use the EngineCPUUtilization metric,
which reports the percentage of usage on the Redis engine core. To see if this metric is available on your
nodes and for more information, see Metrics for Redis.
EngineCPUUtilization
For larger node types with 4vCPUs or more, you may want to use the EngineCPUUtilization metric,
which reports the percentage of usage on the Redis engine core. To see if this metric is available on your
nodes and for more information, see Metrics for Redis.
For more information, see the CPUs section at Monitoring best practices with Amazon ElastiCache for
Redis using Amazon CloudWatch.
SwapUsage
This is a host-level metric reported in bytes. For more information, see Host-Level Metrics (p. 587).
This metric should not exceed 300 MB. If it does, see the following topics:
• Ensuring that you have enough memory to create a Redis snapshot (p. 221)
• Managing Reserved Memory (p. 223)
Evictions
This is a cache engine metric. We recommend that you determine your own alarm threshold for this
metric based on your application needs.
CurrConnections
This is a cache engine metric. We recommend that you determine your own alarm threshold for this
metric based on your application needs.
An increasing number of CurrConnections might indicate a problem with your application; you will need
to investigate the application behavior to address this issue.
For more information, see the Connections section at Monitoring best practices with Amazon
ElastiCache for Redis using Amazon CloudWatch.
Memory
Memory is a core aspect of Redis. Understanding the memory utilization of your cluster is necessary to
avoid data loss and accommodate future growth of your dataset. Statistics about the memory utilization
of a node are available in the memory section of the Redis INFO command.
For more information, see the Memory section at Monitoring best practices with Amazon ElastiCache for
Redis using Amazon CloudWatch.
Network
One of the determining factors for the network bandwidth capacity of your cluster is the node type you
have selected. For more information about the network capacity of your node, see Amazon ElastiCache
pricing.
For more information, see the Network section at Monitoring best practices with Amazon ElastiCache for
Redis using Amazon CloudWatch.
Latency
You can measure a command’s latency with a set of CloudWatch metrics that provide aggregated
latencies per data structure. These latency metrics are calculated using the commandstats statistic from
the Redis INFO command.
For more information, see the Latency section at Monitoring best practices with Amazon ElastiCache for
Redis using Amazon CloudWatch.
Replication
The volume of data being replicated is visible via the ReplicationBytes metric. Although this metric
is representative of the write load on the replication group, it doesnt provide insights into replication
health. For this purpose, you can use the ReplicationLag metric.
For more information, see the Replication section at Monitoring best practices with Amazon ElastiCache
for Redis using Amazon CloudWatch.
All ElastiCache samples are published for a 60 second duration for each individual cache node. For any
60 second period, a cache node metric will only contain a single sample.
For further information on how to retrieve metrics for your cache nodes, see Monitoring CloudWatch
Cluster and Node Metrics (p. 600).
The following procedures show you how to use CloudWatch to gather storage space statistics for an
cache cluster for the past hour.
Note
The StartTime and EndTime values supplied in the examples below are for illustrative
purposes. You must substitute appropriate start and end time values for your cache nodes.
For information on ElastiCache limits, see AWS Service Limits for ElastiCache.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. Select the cache nodes you want to view metrics for.
Note
Selecting more than 20 nodes disables viewing metrics on the console.
a. On the Cache Clusters page of the AWS Management Console, click the name of one or more
cache clusters.
A list of available CloudWatch Metrics appears at the bottom of the console window.
d. Click on the CPU Utilization metric.
The CloudWatch console will open, displaying your selected metrics. You can use the Statistic
and Period drop-down list boxes and Time Range tab to change the metrics being displayed.
Monitoring CloudWatch Cluster and Node Metrics using the CloudWatch CLI
To gather CPU utilization statistics for a cache cluster
For Windows:
Monitoring CloudWatch Cluster and Node Metrics using the CloudWatch API
To gather CPU utilization statistics for a cache cluster
• Call the CloudWatch API GetMetricStatistics with the following parameters (note that the start
and end times are shown as examples only; you will need to substitute your own appropriate start
and end times):
• Statistics.member.1=Average
• Namespace=AWS/ElastiCache
• StartTime=2013-07-05T00:00:00
• EndTime=2013-07-06T00:00:00
• Period=60
• MeasureName=CPUUtilization
• Dimensions=CacheClusterId=mycachecluster,CacheNodeId=0002
Example
http://monitoring.amazonaws.com/
?Action=GetMetricStatistics
&SignatureVersion=4
&Version=2014-12-01
&StartTime=2018-07-05T00:00:00
&EndTime=2018-07-06T23:59:00
&Period=3600
&Statistics.member.1=Average
&Dimensions.member.1="CacheClusterId=mycachecluster"
&Dimensions.member.2="CacheNodeId=0002"
&Namespace=&AWS;/ElastiCache
&MeasureName=CPUUtilization
&Timestamp=2018-07-07T17%3A48%3A21.746Z
&AWS;AccessKeyId=<&AWS; Access Key ID>
&Signature=<Signature>
To learn more about CloudTrail, see the AWS CloudTrail User Guide.
For an ongoing record of events in your AWS account, including events for Amazon ElastiCache, create a
trail. A trail enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create
a trail in the console, the trail applies to all regions. The trail logs events from all regions in the AWS
partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can
configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs.
For more information, see the following:
All Amazon ElastiCache actions are logged by CloudTrail and are documented in the ElastiCache
API Reference. For example, calls to the CreateCacheCluster, DescribeCacheCluster and
ModifyCacheCluster actions generate entries in the CloudTrail log files.
Every event or log entry contains information about who generated the request. The identity
information helps you determine the following:
• Whether the request was made with root or IAM user credentials.
• Whether the request was made with temporary security credentials for a role or federated user.
• Whether the request was made by another AWS service.
parameters, and so on. CloudTrail log files are not an ordered stack trace of the public API calls, so they
do not appear in any specific order.
The following example shows a CloudTrail log entry that demonstrates the CreateCacheCluster
action.
{
"eventVersion":"1.01",
"userIdentity":{
"type":"IAMUser",
"principalId":"EXAMPLEEXAMPLEEXAMPLE",
"arn":"arn:aws:iam::123456789012:user/elasticache-allow",
"accountId":"123456789012",
"accessKeyId":"AKIAIOSFODNN7EXAMPLE",
"userName":"elasticache-allow"
},
"eventTime":"2014-12-01T22:00:35Z",
"eventSource":"elasticache.amazonaws.com",
"eventName":"CreateCacheCluster",
"awsRegion":"us-west-2",
"sourceIPAddress":"192.0.2.01",
"userAgent":"AWS CLI/ElastiCache 1.10 API 2014-12-01",
"requestParameters":{
"numCacheNodes":2,
"cacheClusterId":"test-memcached",
"engine":"memcached",
"aZMode":"cross-az",
"cacheNodeType":"cache.m1.small",
},
"responseElements":{
"engine":"memcached",
"clientDownloadLandingPage":"https://console.aws.amazon.com/elasticache/
home#client-download:",
"cacheParameterGroup":{
"cacheParameterGroupName":"default.memcached1.4",
"cacheNodeIdsToReboot":{
},
"parameterApplyStatus":"in-sync"
},
"preferredAvailabilityZone":"Multiple",
"numCacheNodes":2,
"cacheNodeType":"cache.m1.small",
"cacheClusterStatus":"creating",
"autoMinorVersionUpgrade":true,
"preferredMaintenanceWindow":"thu:05:00-thu:06:00",
"cacheClusterId":"test-memcached",
"engineVersion":"1.4.14",
"cacheSecurityGroups":[
{
"status":"active",
"cacheSecurityGroupName":"default"
}
],
"pendingModifiedValues":{
}
},
"requestID":"104f30b3-3548-11e4-b7b8-6d79ffe84edd",
"eventID":"92762127-7a68-42ce-8787-927d2174cde1"
}
The following example shows a CloudTrail log entry that demonstrates the DescribeCacheCluster
action. Note that for all Amazon ElastiCache Describe calls (Describe*), the ResponseElements
section is removed and appears as null.
{
"eventVersion":"1.01",
"userIdentity":{
"type":"IAMUser",
"principalId":"EXAMPLEEXAMPLEEXAMPLE",
"arn":"arn:aws:iam::123456789012:user/elasticache-allow",
"accountId":"123456789012",
"accessKeyId":"AKIAIOSFODNN7EXAMPLE",
"userName":"elasticache-allow"
},
"eventTime":"2014-12-01T22:01:00Z",
"eventSource":"elasticache.amazonaws.com",
"eventName":"DescribeCacheClusters",
"awsRegion":"us-west-2",
"sourceIPAddress":"192.0.2.01",
"userAgent":"AWS CLI/ElastiCache 1.10 API 2014-12-01",
"requestParameters":{
"showCacheNodeInfo":false,
"maxRecords":100
},
"responseElements":null,
"requestID":"1f0b5031-3548-11e4-9376-c1d979ba565a",
"eventID":"a58572a8-e81b-4100-8e00-1797ed19d172"
}
The following example shows a CloudTrail log entry that records a ModifyCacheCluster action.
{
"eventVersion":"1.01",
"userIdentity":{
"type":"IAMUser",
"principalId":"EXAMPLEEXAMPLEEXAMPLE",
"arn":"arn:aws:iam::123456789012:user/elasticache-allow",
"accountId":"123456789012",
"accessKeyId":"AKIAIOSFODNN7EXAMPLE",
"userName":"elasticache-allow"
},
"eventTime":"2014-12-01T22:32:21Z",
"eventSource":"elasticache.amazonaws.com",
"eventName":"ModifyCacheCluster",
"awsRegion":"us-west-2",
"sourceIPAddress":"192.0.2.01",
"userAgent":"AWS CLI/ElastiCache 1.10 API 2014-12-01",
"requestParameters":{
"applyImmediately":true,
"numCacheNodes":3,
"cacheClusterId":"test-memcached"
},
"responseElements":{
"engine":"memcached",
"clientDownloadLandingPage":"https://console.aws.amazon.com/elasticache/
home#client-download:",
"cacheParameterGroup":{
"cacheParameterGroupName":"default.memcached1.4",
"cacheNodeIdsToReboot":{
},
"parameterApplyStatus":"in-sync"
},
"cacheClusterCreateTime":"Dec 1, 2014 10:16:06 PM",
"preferredAvailabilityZone":"Multiple",
"numCacheNodes":2,
"cacheNodeType":"cache.m1.small",
"cacheClusterStatus":"modifying",
"autoMinorVersionUpgrade":true,
"preferredMaintenanceWindow":"thu:05:00-thu:06:00",
"cacheClusterId":"test-memcached",
"engineVersion":"1.4.14",
"cacheSecurityGroups":[
{
"status":"active",
"cacheSecurityGroupName":"default"
}
],
"configurationEndpoint":{
"address":"test-memcached.example.cfg.use1prod.cache.amazonaws.com",
"port":11211
},
"pendingModifiedValues":{
"numCacheNodes":3
}
},
"requestID":"807f4bc3-354c-11e4-9376-c1d979ba565a",
"eventID":"e9163565-376f-4223-96e9-9f50528da645"
}
Topics
• Managing ElastiCache Amazon SNS notifications (p. 606)
• Viewing ElastiCache events (p. 610)
• Event Notifications and Amazon SNS (p. 613)
The following procedure shows you how to add an Amazon SNS topic for a cluster. To add an Amazon
SNS topic for a replication group, in step 2, instead of choosing a cluster, choose a replication group then
follow the same remaining steps.
Note
This process can also be used to modify the Amazon SNS topic.
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. In Clusters, choose the cluster for which you want to add or modify an Amazon SNS topic ARN.
3. Choose Modify.
4. In Modify Cluster under Topic for SNS Notification, choose the SNS topic you want to add, or
choose Manual ARN input and type the ARN of the Amazon SNS topic.
5. Choose Modify.
To add or modify an Amazon SNS topic for a cluster, use the AWS CLI command modify-cache-
cluster.
The following code example adds an Amazon SNS topic arn to my-cluster.
For Windows:
To add or modify an Amazon SNS topic for a cluster, call the ModifyCacheCluster action with the
following parameters:
• CacheClusterId=my-cluster
• TopicArn=arn%3Aaws%3Asns%3Aus-
west-2%3A565419523791%3AElastiCacheNotifications
Example
https://elasticache.amazon.com/
?Action=ModifyCacheCluster
&ApplyImmediately=false
&CacheClusterId=my-cluster
&NotificationTopicArn=arn%3Aaws%3Asns%3Aus-
west-2%3A565419523791%3AElastiCacheNotifications
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. To see a list of your clusters running Redis, in the navigation pane choose Redis.
3. Choose the box to the left of the cluster you want to modify notification for.
4. Choose Modify.
5. In Modify Cluster under Topic for SNS Notification, choose Disable Notifications.
6. Choose Modify.
To disable Amazon SNS notifications, use the command modify-cache-cluster with the following
parameters:
For Windows:
To disable Amazon SNS notifications, call the ModifyCacheCluster action with the following
parameters:
• CacheClusterId=my-cluster
• NotificationTopicStatus=inactive
Example
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheCluster
&ApplyImmediately=false
&CacheClusterId=my-cluster
&NotificationTopicStatus=inactive
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=<credential>
&X-Amz-Signature=<signature>
The following procedures show you how to view all ElastiCache events for the past 24 hours (1440
minutes).
1. Sign in to the AWS Management Console and open the ElastiCache console at https://
console.aws.amazon.com/elasticache/.
2. To see a list of all available events, in the navigation pane, choose Events.
On the Events screen each row of the list represents one event and displays the event source, the
event type (cache-cluster, cache-parameter-group, cache-security-group, or cache-subnet-group),
the GMT time of the event, and a description of the event.
Using the Filter you can specify whether you want to see all events, or just events of a specific type
in the event list.
The following code lists all events for the past 24 hours (1440 minutes).
The output from the describe-events command looks something like this.
"SourceIdentifier": "my-mem-cluster",
"SourceType": "cache-cluster",
"Message": "Added cache node 0003 in availability zone us-west-2a",
"Date": "2020-06-09T02:01:21.706Z"
},
{
"SourceIdentifier": "my-mem-cluster",
"SourceType": "cache-cluster",
"Message": "Increasing number of requested nodes",
"Date": "2020-06-09T01:58:34.178Z"
},
{
"SourceIdentifier": "mycluster-0003-004",
"SourceType": "cache-cluster",
"Message": "Added cache node 0001 in availability zone us-west-2c",
"Date": "2020-06-09T01:51:14.120Z"
},
{
"SourceIdentifier": "mycluster-0003-004",
"SourceType": "cache-cluster",
"Message": "This cache cluster does not support persistence (ex: 'appendonly').
Please use a different instance type to enable persistence.",
"Date": "2020-06-09T01:51:14.095Z"
},
{
"SourceIdentifier": "mycluster-0003-004",
"SourceType": "cache-cluster",
"Message": "Cache cluster created",
"Date": "2020-06-09T01:51:14.094Z"
},
{
"SourceIdentifier": "mycluster-0001-005",
"SourceType": "cache-cluster",
"Message": "Added cache node 0001 in availability zone us-west-2b",
"Date": "2020-06-09T01:42:55.603Z"
},
{
"SourceIdentifier": "mycluster-0001-005",
"SourceType": "cache-cluster",
"Message": "This cache cluster does not support persistence (ex: 'appendonly').
Please use a different instance type to enable persistence.",
"Date": "2020-06-09T01:42:55.576Z"
},
{
"SourceIdentifier": "mycluster-0001-005",
"SourceType": "cache-cluster",
"Message": "Cache cluster created",
"Date": "2020-06-09T01:42:55.574Z"
},
{
"SourceIdentifier": "mycluster-0001-004",
"SourceType": "cache-cluster",
"Message": "Added cache node 0001 in availability zone us-west-2b",
"Date": "2020-06-09T01:28:40.798Z"
},
{
"SourceIdentifier": "mycluster-0001-004",
"SourceType": "cache-cluster",
"Message": "This cache cluster does not support persistence (ex: 'appendonly').
Please use a different instance type to enable persistence.",
"Date": "2020-06-09T01:28:40.775Z"
},
{
"SourceIdentifier": "mycluster-0001-004",
"SourceType": "cache-cluster",
"Message": "Cache cluster created",
"Date": "2020-06-09T01:28:40.773Z"
}
]
}
For more information, such as available parameters and permitted parameter values, see describe-
events.
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeEvents
&MaxRecords=40
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cache-cluster
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=<credential>
The following code lists the cache-cluster events for the past 24 hours (1440 minutes).
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeEvents
&Duration=1440
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cache-cluster
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=<credential>
<DescribeEventsResponse xmlns="http://elasticache.amazonaws.com/doc/2015-02-02/">
<DescribeEventsResult>
<Events>
<Event>
<Message>Cache cluster created</Message>
<SourceType>cache-cluster</SourceType>
<Date>2015-02-02T18:22:18.202Z</Date>
<SourceIdentifier>mem01</SourceIdentifier>
</Event>
(...output omitted...)
</Events>
</DescribeEventsResult>
<ResponseMetadata>
<RequestId>e21c81b4-b9cd-11e3-8a16-7978bb24ffdf</RequestId>
</ResponseMetadata>
</DescribeEventsResponse>
For more information, such as available parameters and permitted parameter values, see
DescribeEvents.
Notifications are published to a specified Amazon SNS topic. The following are requirements for
notifications:
ElastiCache Events
The following ElastiCache events trigger Amazon SNS notifications. For information on event details, see
Viewing ElastiCache events (p. 610).
ElastiCache:AddCacheNodeFailed ElastiCache:AddCacheNodeFailed
A cache
: node could not be
due to insufficient free IP cluster-name added because there are not
addresses enough available IP addresses.
ElastiCache:CacheClusterScalingComplete
CacheClusterScalingCompleteScaling
: for cache-cluster
cluster-name completed successfully.
ElastiCache:CacheClusterScalingFailed
ElastiCache:CacheClusterScalingFailed
Scale-up
: operation on cache-
cluster-name cluster failed.
ElastiCache:CacheNodesRebooted ElastiCache:CacheNodesRebooted
One or: more cache nodes has
cluster-name been rebooted.
ElastiCache:FailoverComplete Failover
ElastiCache:FailoverComplete : over to a replica node
(Redis only) mycluster was successful.
ElastiCache:ReplicationGroupScalingFailed
"Failed applying Scale-up operation on
modification to cache replication group failed.
node type to %s."
ElastiCache:ServiceUpdateAvailableForNode
"Service update is A self-service update is available
available for cache node for the node.
%s."
ElastiCache:SnapshotComplete A cache
ElastiCache:SnapshotComplete : snapshot has completed
(Redis only) cluster-name successfully.
Related topics
• Viewing ElastiCache events (p. 610)
To learn whether Elasticache or other AWS services are in scope of specific compliance programs, see
AWS Services in Scope by Compliance Program. For general information, see AWS Compliance Programs.
You can download third-party audit reports using AWS Artifact. For more information, see Downloading
Reports in AWS Artifact.
Your compliance responsibility when using AWS services is determined by the sensitivity of your data,
your company's compliance objectives, and applicable laws and regulations. AWS provides the following
resources to help with compliance:
• Security and Compliance Quick Start Guides – These deployment guides discuss architectural
considerations and provide steps for deploying baseline environments on AWS that are security and
compliance focused.
• Architecting for HIPAA Security and Compliance Whitepaper – This whitepaper describes how
companies can use AWS to create HIPAA-eligible applications.
Note
Not all AWS services are HIPAA eligible. For more information, see the HIPAA Eligible Services
Reference.
• AWS Compliance Resources – This collection of workbooks and guides might apply to your industry
and location.
• Evaluating Resources with Rules in the AWS Config Developer Guide – The AWS Config service assesses
how well your resource configurations comply with internal practices, industry guidelines, and
regulations.
• AWS Security Hub – This AWS service provides a comprehensive view of your security state within AWS
that helps you check your compliance with security industry standards and best practices.
• AWS Audit Manager – This AWS service helps you continuously audit your AWS usage to simplify how
you manage risk and compliance with regulations and industry standards.
You can use Amazon ElastiCache for Redis to build HIPAA-compliant applications. To help do this, you
can enable at-rest encryption, in-transit encryption, and Redis AUTH when you create a Redis cluster
using ElastiCache for Redis versions 3.2.6, 4.0.10, or later. You can store healthcare-related information,
including protected health information (PHI), under an executed Business Associate Agreement (BAA)
with AWS. AWS Services in Scope have been fully assessed by a third-party auditor and result in a
certification, attestation of compliance, or Authority to Operate (ATO). For more information, see the
following topics:
Topics
• ElastiCache for Redis compliance (p. 618)
Topics
• Self-service security updates for compliance (p. 618)
• ElastiCache for Redis FedRAMP compliance (p. 618)
• HIPAA eligibility (p. 619)
• ElastiCache for Redis PCI DSS compliance (p. 620)
• Create and seed a new compliant cluster (p. 621)
• More information (p. 621)
Security updates are released by using the Service Updates feature. They are specified by the Update
Type field of value security update. The Service Update has corresponding Severity and Recommended
Apply by Date fields. In order to maintain compliance of your Redis clusters, you must apply the
available updates by the Recommended Apply by Date. The field SLA Met reflects your Redis cluster’s
compliance status.
Note
If you do not apply the Service Update by the recommended date or when the Service Update
expires, ElastiCache will not take any action to apply the update on your behalf.
You are notified of the Service Updates applicable to your Redis clusters by an announcement
on the Redis console, email, Amazon SNS, CloudWatch events ((AWS Health Service).
For more information on Self-Service Maintenance see Self-service updates in Amazon
ElastiCache (p. 625).
CloudWatch events and AWS Health Dashboard are not supported in the following regions:
• us-gov-west-1
• us-gov-east-1
• cn-north-1
• cn-northwest-1
You can request access to the AWS FedRAMP Security Packages through the FedRAMP PMO or your AWS
Sales Account Manager or, they can be downloaded through AWS Artifact at AWS Artifact.
Requirements
To enable FedRAMP support on your ElastiCache for Redis cluster, your cluster and nodes within the
cluster must satisfy the following requirements.
• Engine version requirements – Your cluster must be running ElastiCache for Redis 3.2.6, 4.0.10 and
later for both cluster mode enabled and disabled to qualify for FedRAMP compliance.
• Starting with ElastiCache for Redis versions 3.2.6, 4.0.10 and later for both cluster mode enabled
and disabled, you can also enable additional data security features such as:
• ElastiCache for Redis in-transit encryption (TLS) (p. 471)
• At-Rest Encryption in ElastiCache for Redis (p. 483)
• Authenticating users with the Redis AUTH command (p. 478)
• Node type requirements – Your cluster must be running a current-generation node type — M4, M5,
M6g, T2, T3, T4g, R4, R5 or R6g. For more information, see the following:
• Supported node types (p. 99)
• Choosing your node size (p. 127)
• FIPS Endpoints requirements – Your ElastiCache for Redis clusters can be created using the FIPS
endpoints available in the following regions:.
HIPAA eligibility
The AWS HIPAA Compliance program includes Amazon ElastiCache for Redis as a HIPAA eligible service.
To use ElastiCache for Redis in compliance with HIPAA, you need to set up a Business Associate
Agreement (BAA) with AWS. In addition, your cluster and the nodes within your cluster must satisfy the
requirements for engine version, node type, and data security listed following.
Requirements
To enable HIPAA support on your ElastiCache for Redis cluster, your cluster and nodes within the cluster
must satisfy the following requirements.
• Engine version requirements – Your cluster must be running one of the following ElastiCache for
Redis versions to qualify for HIPAA eligibility.
• ElastiCache for Redis version 6.0 (enhanced) (p. 190) or higher.
• ElastiCache for Redis version 5.0.0 (enhanced) (p. 192) or higher.
• ElastiCache for Redis version 4.0.10 (enhanced) (p. 193)
• ElastiCache for Redis version 3.2.6 (enhanced) (p. 194)
• Node type requirements – Your cluster must be running a current-generation node type— M4, M5,
M6g, T2, T3, T4g, R4, R5, R6g or R6gd. For more information, see the following:
• Supported node types (p. 99)
• Choosing your node size (p. 127)
• Data security requirements – Your cluster must enable in-transit encryption, at-rest encryption, and
Redis AUTH. For more information, see the following:
• ElastiCache for Redis in-transit encryption (TLS) (p. 471)
• At-Rest Encryption in ElastiCache for Redis (p. 483)
• Authenticating users with the Redis AUTH command (p. 478)
• Security Updates Requirement – You must update your Redis cluster with the latest Service Updates
of type security by the Recommended Apply by Date. You can update the cluster in real-time and
on-demand to ensure no impact to your business. For more information, see Self-service updates in
Amazon ElastiCache (p. 625)
By implementing these requirements, ElastiCache for Redis can be used to store, process, and access
Protected Health Information (PHI) in compliance with HIPAA.
For general information about AWS Cloud and HIPAA eligibility, see the following:
• HIPAA Compliance
• Architecting for HIPAA Security and Compliance on Amazon Web Services
• Security Updates Requirement – You must regularly update your Redis cluster by the Recommended
Apply by Date. You can update the cluster in real-time and on-demand to ensure no impact to your
business. For more information, see Self-service updates in Amazon ElastiCache (p. 625).
Requirements
To enable PCI DSS support on your ElastiCache for Redis cluster, your cluster and nodes within the
cluster must satisfy the following requirements.
• Engine version requirements – Your cluster must be running ElastiCache for Redis 3.2.6, 4.0.10 and
later for both cluster mode enabled and disabled.
• Node type requirements – Your cluster must be running a current-generation node type— M4, M5,
M6g, T2, T3, T4g, R4, R5, R6g or R6gd. For more information, see the following:
• Supported node types (p. 99)
• Choosing your node size (p. 127)
• Security Updates Requirement – You must regularly update your Redis cluster by the Recommended
Apply by Date. You can update the cluster in real-time and on-demand to ensure no impact to your
business. For more information, see Self-service updates in Amazon ElastiCache (p. 625).
API Version 2015-02-02
620
Amazon ElastiCache for Redis User Guide
Resilience
ElastiCache for Redis also offers Data Security Controls to further secure the cluster to store, process, and
transmit sensitive financial data like Customer Cardholder Data (CHD) when using the service.
More information
For general information about AWS Cloud compliance, see the following:
For more information about AWS Regions and Availability Zones, see AWS Global Infrastructure.
In addition to the AWS global infrastructure, Amazon ElastiCache offers several features to help support
your data resiliency and backup needs.
Topics
• Mitigating Failures (p. 622)
Mitigating Failures
When planning your Amazon ElastiCache implementation, you should plan so that failures have a
minimal impact upon your application and data. The topics in this section cover approaches you can take
to protect your application and data from failures.
Topics
• Mitigating Failures when Running Redis (p. 622)
• Recommendations (p. 624)
Topics
• Mitigating Failures: Redis Append Only Files (AOF) (p. 622)
• Mitigating Failures: Redis Replication Groups (p. 623)
When AOF is enabled for Redis, whenever data is written to your Redis cluster, a corresponding
transaction record is written to a Redis append only file (AOF). If your Redis process restarts, ElastiCache
creates a replacement cluster and provisions it. You can then run the AOF against the cluster to
repopulate it with data.
Some of the shortcomings of using Redis AOF to mitigate cluster failures are the following:
• It is time-consuming.
Creating and provisioning a cluster can take several minutes. Depending on the size of the AOF,
running it against the cluster adds even more time when your application can't access your cluster for
data. This forces your application to hit the database directly.
• The AOF can get big.
Because every write to your cluster is written to a transaction record, AOFs can become very large,
larger than the .rdb file for the dataset in question. Because ElastiCache relies on the local instance
store, which is limited in size, enabling AOF can cause out-of-disk-space issues. You can avoid out-of-
disk-space issues by using a replication group with Multi-AZ enabled.
• Using AOF can't protect you from all failure scenarios.
For example, if a node fails due to a hardware fault in an underlying physical server, ElastiCache will
provision a new node on a different server. In this case, the AOF is not available and can't be used to
recover the data.
For more information, see Append only files (AOF) in ElastiCache for Redis (p. 345).
A Redis replication group is comprised of a single primary node which your application can both read
from and write to, and from 1 to 5 read-only replica nodes. Whenever data is written to the primary
node it is also asynchronously updated on the read replica nodes.
During this time your application can continue reading and writing using the other nodes.
Redis Multi-AZ
You can enable Multi-AZ on your Redis replication groups. Whether you enable Multi-AZ or not, a failed
primary will be detected and replaced automatically. How this takes place varies whether or not Multi-AZ
is or is not enabled.
Failing over to a replica node is generally faster than creating and provisioning a new primary node.
This means your application can resume writing to your primary node sooner than if Multi-AZ were not
enabled.
For more information, see Minimizing downtime in ElastiCache for Redis with Multi-AZ (p. 253).
During steps 1 through 4 of this process, your application can't write to the primary node. However, your
application can continue reading from your replica nodes.
For added protection, we recommend that you launch the nodes in your replication group in different
Availability Zones (AZs). If you do this, an AZ failure will only impact the nodes in that AZ and not the
others.
For more information, see High availability using replication groups (p. 246).
No matter how many nodes you have, if they are all located in the same Availability Zone, a catastrophic
failure of that AZ results in your losing all your cache data. However, if you locate your nodes in multiple
AZs, a failure of any AZ results in your losing only the nodes in that AZ.
Any time you lose a node you can experience a performance degradation since read operations are now
shared by fewer nodes. This performance degradation will continue until the nodes are replaced. Because
your data is not partitioned across Redis nodes, you risk some data loss only when the primary node is
lost.
For information on specifying the Availability Zones for Redis nodes, see Creating a Redis (cluster mode
disabled) cluster (Console) (p. 47).
For more information on regions and Availability Zones, see Choosing regions and availability
zones (p. 87).
Recommendations
There are two types of failures you need to plan for, individual node failures and broad Availability Zone
failures. The best failure mitigation plan will address both kinds of failures.
When running Redis, we recommend that you enable Multi-AZ on your replication group so that
ElastiCache will automatically fail over to a replica if the primary node fails.
Other precautions
If you're running Redis, then in addition to the above, we recommend that you schedule regular backups
of your cluster. Backups (snapshots) create a .rdb file you can use to restore your cluster in case of failure
or corruption. For more information, see Backup and restore for ElastiCache for Redis (p. 310).
You use AWS published API calls to access Elasticache through the network. Clients must support
Transport Layer Security (TLS) 1.0 or later. We recommend TLS 1.2 or later. Clients must also support
cipher suites with perfect forward secrecy (PFS) such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve
Ephemeral Diffie-Hellman (ECDHE). Most modern systems such as Java 7 and later support these modes.
Additionally, requests must be signed by using an access key ID and a secret access key that is associated
with an IAM principal. Or you can use the AWS Security Token Service (AWS STS) to generate temporary
security credentials to sign requests.
With self-service updates, you control when and which updates are applied. You can also monitor the
progress of these updates to your selected Redis clusters in real time.
Depending on the type of service update, you can choose to stop an update to remaining nodes and
clusters. You can select a group of clusters (including the ones that were partially updated) to apply the
service updates anytime until the service update expires.
You control when to apply an update, regardless of the recommendation. At a minimum, we strongly
recommend that you apply any updates of type security to ensure that your Redis clusters are always
up-to-date with current security patches. It is also recommended to apply updates of type engine to
ensure that your clusters run the latest ElastiCache patch for a given engine version as well as the latest
Redis OSS versions released by ElastiCache.
To view the up-to-date status of all your Redis clusters, you can choose Service Update Status. This view
also shows the clusters for which the update is not applicable. In addition, you might find updates that
you applied to Redis clusters exceed their estimated update time. In this case, you can stop them and
reapply them at a time that better suits your business needs.
Topics
• Applying the self-service updates (p. 625)
• Stopping the self-service updates (p. 631)
For more information about reviewing your ElastiCache fleet and applying any service-specific updates
to applicable Redis clusters, see Applying the service updates using the console for Redis (p. 626).
When a new service update is available for one or more of your Redis clusters, you can use the
ElastiCache console, API, or AWS CLI to apply the update. The following sections explain the options that
you can use to apply updates.
Topics
• Applying the service updates using the console for Redis (p. 626)
• Applying the service updates using the service updates list (p. 629)
Choose this to view Update Status for individual Redis clusters, and then choose Apply, View, or Stop
for the service updates. If a service update is available, the console displays a banner at the top of the
Redis page, as shown following.
If you choose Apply Now, you can choose to apply the service update to all or a subset of the applicable
clusters in this workflow, as shown following.
Note
If you choose Dismiss, the console stops displaying the banner for that console session.
However, the banner reappears the next time that you refresh your session.
On the Apply Updates Now page, you can use these options:
• Auto-Update after Due Date: If this attribute is yes, after the Recommended apply by Date has
passed, ElastiCache schedules clusters yet to be updated in the appropriate maintenance window.
Updates are applied along with other applicable updates. You can continue to apply the updates until
the update expiration date.
If this attribute is no and you don't apply the self-service update before it expires, ElastiCache doesn't
automatically apply the service update for you. If your cluster is part of one or more ElastiCache-
supported compliance programs and isn't updated, it remains out of compliance until the next
cumulative update becomes available.
• The Nodes Updated ratio value for your Redis cluster and the Estimated Update Time value help
you plan your maintenance schedule. If service updates exceed the estimated time constraints for
your business flows, you can stop updates and reapply them at a later date. For more information, see
Stopping the self-service updates (p. 631).
• If you choose to apply the service updates to any or all available Redis clusters, choose Confirm. If you
choose this, you then view the Service Updates page, where you can monitor the status of your service
update.
• If you choose Cancel, you can explore further options, as explained following.
On the ElastiCache dashboard, you can check Update Status for each of your Redis clusters, as shown
following.
If you stop an in-progress update on a Redis cluster, some nodes might be updated while others are
not. The stopping process doesn't roll back any changes to already updated nodes. You can reapply
the update to those nodes that still have an available status at your convenience if the update doesn't
have an Expired status.
• complete: The update has been successfully applied.
• up to date: The cluster doesn't have any outstanding active service updates and your cluster
is compliant. For more information about compliance, see Self-service security updates for
compliance (p. 618).
To view the list of individual service updates and their status, along with other information, choose the
Service Updates List tab.
Important
We strongly recommend that you apply updates of type security as soon as you can. Doing this
helps ensure that your Redis clusters are always up-to-date with the latest security patches and
are compliant. For more information, see Self-service security updates for compliance (p. 618).
To view the list of individual service updates in relation to the applicable Redis clusters, choose the
Service Update Status tab.
In the Service Updates Status list, you can view the following:
• Service Update Status: The status of the update, which is one of the following:
• available: The update is available for requisite Redis clusters.
• complete: The update has been applied and all Redis clusters are compliant.
• canceled: The update has been canceled and is no longer necessary.
• expired: The update is no longer available to apply.
• Service Update SLA Met: This reflects whether your cluster is compliant.
• yes: All available updates have been applied to this cluster and available nodes by the apply-by date.
• no: If no, at least one node in the replication group has not been updated by the recommended
apply-by date. This typically happens when a service update is applied and then stopped.
Note
If you stop the progress of a service update on a cluster, any nodes that are already updated
have a complete status. Any nodes that have an In Progress or Stopping status revert to a
Stopped status, and the Service Update SLA Met status changes to no.
• N/A: The replication group was created after the recommended apply-by date.
• Cluster Status Modified Date: The latest date that the update status was changed for a cluster.
Note
The Show Previous Updates check box, if selected, displays a list of previous updates that are
no longer available.
• To retrieve a description of the service updates that are available, run the following command:
your cluster runs the same Redis engine version across all nodes. Service update description will
describe the type of Redis engine version update. It can also be found in the PHD, SNS or Email
notifications.
The Stopping operation immediately interrupts all updates to those clusters and any nodes that are yet
to be updated. It continues to completion any nodes that have an in progress status. However, it ceases
updates to other nodes in the same cluster that have an update available status and reverts them to a
Stopping status.
When the Stopping workflow is complete, the nodes that have a Stopping status change to a Stopped
status. Depending on the workflow of the update, some clusters won't have any nodes updated. Other
clusters might include some nodes that are updated and others that still have an update available
status.
You can return later to finish the update process as your business flows permit. In this case, choose
the applicable clusters that you want to complete updates on, and then choose Apply Now. For more
information, see Applying the service updates using the console for Redis (p. 626).
• After a service update has progressed on a selected Redis cluster, the ElastiCache console displays the
View/Stop Update tab at the top of the Redis dashboard.
• When you stop the update, choose the Redis cluster and examine the status. It reverts to a Stopping
status, as shown following, and eventually a Stopped status.
Troubleshooting
The following items must be verified while troubleshooting persistent connectivity issues with
ElastiCache:
Topics
• Security groups (p. 634)
• Network ACLs (p. 634)
• Route tables (p. 636)
• DNS resolution (p. 636)
• Identifying issues with server-side diagnostics (p. 636)
• Network connectivity validation (p. 640)
• Network-related limits (p. 641)
• CPU Usage (p. 642)
• Connections being terminated from the server side (p. 644)
• Client-side troubleshooting for Amazon EC2 instances (p. 645)
• Dissecting the time taken to complete a single request (p. 645)
Security groups
Security Groups are virtual firewalls protecting your ElastiCache client (EC2 instance, AWS Lambda
function, Amazon ECS container, etc.) and ElastiCache cluster. Security groups are stateful, meaning
that after the incoming or outgoing traffic is allowed, the responses for that traffic will be automatically
authorized in the context of that specific security group.
The stateful feature requires the security group to keep track of all authorized connections, and there
is a limit for tracked connections. If the limit is reached, new connections will fail. Please refer to the
troubleshooting section for help on how to identify if the limits has been hit on the client or Elasticache
side.
You can have a single security groups assigned at the same time to the client and ElastiCache cluster, or
individual security groups for each.
For both cases, you need to allow the TCP outbound traffic on the ElastiCache port from the source and
the inbound traffic on the same port to ElastiCache. The default port is 11211 for Memcached and 6379
for Redis. By default, security groups allow all outbound traffic. In this case, only the inbound rule in the
target security group is required.
For more information, see Access patterns for accessing an ElastiCache cluster in an Amazon VPC.
Network ACLs
Network Access Control Lists (ACLs) are stateless rules. The traffic must be allowed in both directions
(Inbound and Outbound) to succeed. Network ACLs are assigned to subnets, not specific resources. It is
possible to have the same ACL assigned to ElastiCache and the client resource, especially if they are in
the same subnet.
By default, network ACLs allow all trafic. However, it is possible to customize them to deny or allow
traffic. Additionally, the evaluation of ACL rules is sequential, meaning that the rule with the lowest
number matching the traffic will allow or deny it. The minimum configuration to allow the Redis traffic
is:
• Inbound Rules:
• Rule number: preferably lower than any deny rule;
• Type: Custom TCP Rule;
• Protocol: TCP
• Port Range: 1024-65535
• Source: 0.0.0.0/0 (or create individial rules for the ElastiCache cluster subnets)
• Allow/Deny: Allow
• Outbound Rules:
• Rule number: preferably lower than any deny rule;
• Type: Custom TCP Rule;
• Protocol: TCP
• Port Range: 6379
• Source: 0.0.0.0/0 (or the ElastiCache cluster subnets. Keep in mind that using specific IPs may create
issues in case of failover or scaling the cluster)
• Allow/Deny: Allow
• Inbound Rules:
• Rule number: preferably lower than any deny rule;
• Type: Custom TCP Rule;
• Protocol: TCP
• Port Range: 6379
• Source: 0.0.0.0/0 (or create individial rules for the ElastiCache cluster subnets)
• Allow/Deny: Allow
• Outbound Rules:
• Rule number: preferably lower than any deny rule;
• Type: Custom TCP Rule;
• Protocol: TCP
• Port Range: 1024-65535
• Source: 0.0.0.0/0 (or the ElastiCache cluster subnets. Keep in mind that using specific IPs may create
issues in case of failover or scaling the cluster)
• Allow/Deny: Allow
Route tables
Similarly to Network ACLs, each subnet can have different route tables. If clients and the ElastiCache
cluster are in different subnets, make sure that their route tables allow them to reach each other.
More complex environments, involving multiple VPCs, dynamic routing, or network firewalls, may
become difficult to troubleshoot. See Network connectivity validation (p. 640) to confirm that your
network settings are appropriate.
DNS resolution
ElastiCache provides the service endpoints based on DNS names. The endpoints available are
Configuration, Primary, Reader, and Node endpoints. For more information, see Finding Connection
Endpoints.
In case of failover or cluster modification, the address associated to the endpoint name may change and
will be automatically updated.
Custom DNS settings (i.e., not using the VPC DNS service) may not be aware of the ElastiCache-provided
DNS names. Make sure that your system can successfully resolve the ElastiCache endpoints using system
tools like dig (as shown following) or nslookup.
You can also force the name resolution through the VPC DNS service:
• CPU usage: Redis is a multi-threaded application. However, execution of each command happens
in a single (main) thread. For this reason, ElastiCache provides the metrics CPUUtilization and
EngineCPUUtilization. EngineCPUUtilization provides the CPU utilization dedicated to the
Redis process, and CPUUtilization the usage across all vCPUs. Nodes with more than one vCPU
usually have different values for CPUUtilization and EngineCPUUtilization, the second being
commonly higher. High EngineCPUUtilization can be caused by an elevated number of requests
or complex operations that take a significant amount of CPU time to complete. You can identify both
with the following:
• Elevated number of requests: Check for increases on other metrics matching the
EngineCPUUtilization pattern. Useful metrics are:
• CacheHits and CacheMisses: the number of successful requests or requests that didn’t find a
valid item in the cache. If the ratio of misses compared to hits is high, the application is wasting
time and resources with unfruitful requests.
• SetTypeCmds and GetTypeCmds: These metrics correlated with EngineCPUUtilization
can help to understand if the load is significantly higher for write requests, measured by
SetTypeCmds, or reads, measured by GetTypeCmds. If the load is predominantly reads, using
multiple read-replicas can balance the requests across multiple nodes and spare the primary for
writes. In cluster mode-disabled clusters, the use of read-replicas can be done by creating an
additional connection configuration in the application using the ElastiCache reader endpoint. For
more information, see Finding Connection Endpoints. The read operations must be submitted to
this additional connection. Write operations will be done through the regular primary endpoint.
In cluster mode-enabled, it is advisable to use a library that supports read replicas natively. With
the right flags, the library will be able to automatically discover the cluster topology, the replica
nodes, enable the read operations through the READONLY Redis command, and submit the read
requests to the replicas.
• Elevated number of connections:
• CurrConnections and NewConnections: CurrConnection is the number of established
connections at the moment of the datapoint collection, while NewConnections shows how many
connections were created in the period.
Creating and handling connections implies significant CPU overhead. Additionally, the TCP three-
way handshake required to create new connections will negatively affect the overall response
times.
An ElastiCache node with thousands of NewConnections per minute indicates that a connection
is created and used by just a few commands, which is not optimal. Keeping connections
established and reusing them for new operations is a best practice. This is possible when the client
application supports and properly implements connection pooling or persistent connections. With
connection pooling, the number of currConnections does not have big variations, and the
NewConnections should be as low as possible. Redis provides optimal performance with small
number of currConnections. Keeping currConnection in the order of tens or hundreds minimizes
the usage of resources to support individual connections like client buffers and CPU cycles to serve
the connection.
• Network throughput:
• Determine the bandwidth: ElastiCache nodes have network bandwidth proportional to the
node size. Since applications have different characteristics, the results can vary according to the
workload. As examples, applications with high rate of small requests tend to affect more the CPU
usage than the network throughput while bigger keys will cause higher network utilization. For
that reason, it is advisable to test the nodes with the actual workload for a better understanding
of the limits.
Simulating the load from the application would provide more accurate results. However,
benchmark tools can give a good idea of the limits.
• For cases where the requests are predominantly reads, using replicas for read operations will
alleviate the load on the primary node. If the use-case is predominantly writes, the use of many
replicas will amplify the network usage. For every byte written to the primary node, N bytes
will be sent to the replicas,being N the number of replicas. The best practice for write intensive
workloads are using ElastiCache for Redis with cluster mode-enabled so the writes can be
balanced across multiple shards, or scale-up to a node type with more network capabilities.
• The CloudWatchmetrics NetworkBytesIn and NetworkBytesOut provide the amount of data
coming into or leaving the node, respectively. ReplicationBytes is the traffic dedicated to data
replication.
A notorious example is the KEYS command. It sweeps the entire keyspace searching for a given
pattern and blocks the execution of other commands during its execution. Redis uses the “Big O”
notation to describe its commands complexity.
Keys command has O(N) time complexity, N being the number of keys in the database. Therefore,
the larger the number of keys, the slower the command will be. KEYS can cause trouble in different
ways: If no search pattern is used, the command will return all key names available. In databases
with thousand or million of items, a huge output will be created and flood the network buffers.
If a search pattern is used, only the keys matching the pattern will return to the client. However, the
engine still sweeps the entire keyspace searching for it, and the time to complete the command will
be the same.
An alternative for KEYS is the SCAN command. It iterates over the keyspace and limits the iterations
in a specific number of items, avoiding prolonged blocks on the engine.
Scan has the COUNT parameter, used to set the size of the iteration blocks. The default value is 10
(10 items per iteration).
Depending on the number of items in the database, small COUNT values blocks will require more
iterations to complete a full scan, and bigger values will keep the engine busy for longer at each
iteration. While small count values will make SCAN slower on big databases, larger values can cause
the same issues mentioned for KEYS.
As an example, running the SCAN command with count value as 10 will requires 100,000 repetitions
on a database with 1 million keys. If the average network round-trip time is 0.5 milliseconds,
approximately 50,000 milliseconds (50 seconds) will be spent transferring requests.
On the other hand, if the count value were 100,0000, a single iteration would be required and only
0.5 ms would be spent transferring it. However, the engine would be entirely blocked for other
operations until the command finishes sweeping all the keyspace.
Besides KEYS, several other commands are potentially harmful if not used correctly. To see a list of
all commands and their respective time complexity, go to https://redis.io/commands.
network latency inherent to multiple individual SET or GET commands. However, an extensive list
of parameters will affect CPU usage.
While CPU utilization alone is not the cause for connectivity issues, spending too much time to
process a single or few commands over multiple keys may cause failure of other requests and
increase overall CPU utilization.
The number of keys and their size will affect the command complexity and consequently
completion time.
Other examples of commands that can act upon multiple keys: HMGET, HMSET, MSETNX, PFCOUNT,
PFMERGE, SDIFF, SDIFFSTORE, SINTER, SINTERSTORE, SUNION, SUNIONSTORE, TOUCH, ZDIFF,
ZDIFFSTORE, ZINTER or ZINTERSTORE.
• Commands acting upon multiple data types: Redis also provides commands that act upon
one or multiple keys, regardless of their data type. ElastiCache for Redis provides the metric
KeyBasedCmds to monitor such commands. This metric sums the execution of the following
commands in the selected period:
• O(N) complexity:
• KEYS
• O(1)
• EXISTS
• OBJECT
• PTTL
• RANDOMKEY
• TTL
• TYPE
• EXPIRE
• EXPIREAT
• MOVE
• PERSIST
• PEXPIRE
• PEXPIREAT
• UNLINK (O(N) to reclaim memory. However the memory-reclaiming task happens in a
separated thread and does not block the engine
• Different complexity times depending on the data type:
• DEL
• DUMP
• RENAME is considered a command with O(1) complexity, but executes DEL internally. The
execution time will vary depending on the size of the renamed key.
• RENAMENX
• RESTORE
• SORT
• Big hashes: Hash is a data type that allows a single key with multiple key-value sub-items.
Each hash can store 4.294.967.295 items and operations on big hashes can become expensive.
Similarly to KEYS, hashes have the HKEYS command with O(N) time complexity, N being the
number of items in the hash. HSCAN must be preferred over HKEYS to avoid long running
commands. HDEL, HGETALL, HMGET, HMSET and HVALS are commands that should be used with
caution on big hashes.
API Version
• Other big data-structures: Besides 2015-02-02
hashes, other data structures can be CPU intensive. Sets, Lists,
Sorted Sets, and Hyperloglogs can also639
take significant time to be manipulated depending on
Amazon ElastiCache for Redis User Guide
Network connectivity validation
their size and commands used. For more information on those commands, see https://redis.io/
commands.
Reachability Analyzer will test the network connectivity and confirm if all the requirements and
permissions are satisfied. For the tests below you will need the ENI ID (Elastic Network Interface
Identification) of one of the ElastiCache nodes available in your VPC. You can find it by doing the
following:
1. Go to https://console.aws.amazon.com/ec2/v2/home?#NIC:
2. Filter the interface list by your Elasticache cluster name or the IP address got from the DNS
validations previously.
3. Write down or otherwise save the ENI ID. If multiple interfaces are shown, review the description to
confirm that they belong to the right ElastiCache cluster and choose one of them.
4. Proceed to the next step.
5. Create an analyze path at https://console.aws.amazon.com/vpc/home?#ReachabilityAnalyzer and
choose the following options:
• Source Type: Choose instance if your ElastiCache client runs on an Amazon EC2 instance or
Network Interface if it uses another service, such as AWS Fargate Amazon ECS with awsvpc
network, AWS Lambda, etc), and the respective resource ID (EC2 instance or ENI ID);
• Destination Type: Choose Network Interface and select the Elasticache ENI from the list.
• Destination port: specify 6379 for ElastiCache for Redis or 11211 for ElastiCache for Memcached.
Those are the ports defined with the default configuration and this example assumes that they are
not changed.
• Protocol: TCP
Create the analyze path and wait a few moments for the result. If the status is unreachable, open the
analysis details and review the Analysis explorer for details where the requests were blocked.
To validate the TCP connectivity on the ElastiCache service port: On Amazon Linux, Nping is available
in the package nmap and can test the TCP connectivity on the ElastiCache port, as well as providing the
network round-trip time to establish the connection. Use this to validate the network connectivity and
the current latency to the ElastiCache cluster, as shown following:
By default, nping sends 5 probes with a delay of 1 second between them. You can use the option “-c” to
increase the number of probes and “--delay“ to change the time to send a new test.
If the tests with nping fail and the VPC Reachability Analyzer tests passed, ask your system administrator
to review possible Host-based firewall rules, asymmetric routing rules, or any other possible restriction
on the operating system level.
On the ElastiCache console, check if Encryption in-transit is enabled in your ElastiCache cluster details.
If in-transit encryption is enabled, confirm if the TLS session can be established with the following
command:
An extensive output is expected if the connection and TLS negotiation are successful. Check the return
code available in the last line, the value must be 0 (ok). If openssl returns something different, check
the reason for the error at https://www.openssl.org/docs/man1.0.2/man1/verify.html#DIAGNOSTICS.
If all the infrastructure and operating system tests passed but your application is still unable to connect
to ElastiCache, check if the application configurations are compliant with the ElastiCache settings.
Common mistakes are:
• Your application does not support ElastiCache cluster mode, and ElastiCache has cluster-mode
enabled;
• Your application does not support TLS/SSL, and ElastiCache has in-transit encryption enabled;
• Application supports TLS/SSL but does not have the right configuration flags or trusted certification
authorities;
Network-related limits
• Maximum number of connections: There are hard limits for simultaneous connections. Each
ElastiCache node allows up to 65,000 simultaneous connections across all clients. This limit can
be monitored through the CurrConnections metrics on CloudWatch. However, clients also have
their limits for outbound connections.On Linux, check the allowed ephemeral port range with the
command:
# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999
In the previous example, 28231 connections will be allowed from the same source, to the same
destination IP (ElastiCache node) and port. The following command shows how many connections exist
for a specific Elasticache node (IP 1.2.3.4):
ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' |
wc -l
If the number is too high, your system may become overloaded trying to process the connection
requests. It is advisable to consider implementing techniques like connection pooling or persistent
connections to better handle the connections. Whenever possible, configure the connection pool to
limit the maximum number of connections to a few hundred. Also, back-off logic to handle time-outs
or other connection exceptions would are advisable to avoid connection churn in case of issues.
• Network traffic limits: Check the following CloudWatch metrics for Redis to identify possible network
limits being hit on the ElastiCache node:
• NetworkBandwidthInAllowanceExceeded / NetworkBandwidthOutAllowanceExceeded:
Network packets shaped because the throughput exceeded the aggregated bandwidth limit.
It is important to note that every byte written to the primary node will be replicated to N replicas, N
being the number of replicas. Clusters with small node types, multiple replicas, and intensive write
requests may not be able to cope with the replication backlog. For such cases, it's a best practice to
scale-up (change node type), scale-out (add shards in cluster-mode enabled clusters), reduce the
number of replicas, or minimize the number of writes.
• NetworkConntrackAllowanceExceeded: Packets shaped because the maximum number of
connections tracked across all security groups assigned to the node has been exceeded. New
connections will likely fail during this period.
• NetworkPackets PerSecondAllowanceExceeded: Maximum number of packets per second
exceeded. Workloads based on a high rate of very small requests may hit this limit before the
maximum bandwidth.
The metrics above are the ideal way to confirm nodes hitting their network limits. However, limits are
also identifiable by plateaus on network metrics.
If the plateaus are observed for extended periods, they will be likely followed by replication lag,
increase on bytes Used for cache, drop on freeable memory, high swap and CPU usage. Amazon EC2
instances also have network limits that can tracked through ENA driver metrics. Linux instances with
enhanced networking support and ENA drivers 2.2.10 or newer can review the limit counters with the
command:
CPU Usage
The CPU usage metric is the starting point of investigation, and the following items can help to narrow
down possible issues on the ElastiCache side:
• Redis SlowLogs: The ElastiCache default configuration retains the last 128 commands that took over
10 milliseconds to complete. The history of slow commands is kept during the engine runtime and
will be lost in case of failure or restart. If the list reaches 128 entries, old events will be removed to
open room for new ones. The size of the list of slow events and the execution time considered slow can
by modified via the parameters slowlog-max-len and slowlog-log-slower-than in a custom
parameter group. The slowlogs list can be retrieved by running SLOWLOG GET 128 on the engine, 128
being the last 128 slow commands reported. Each entry has the following fields:
The event above happened on December 26, at 19:26:07 UTC, took 4.8 seconds (4.823ms) to complete
and was caused by the KEYS command requested from the client 1.2.3.4.
$ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020
With Python:
PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime : 12/26/2020 7:26:07 PM
UtcDateTime
: 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date : 12/26/2020 12:00:00 AM
Day : 26
DayOfWeek
: Saturday
DayOfYear : 361
Hour : 19
Millisecond : 0
Minute : 26
Month
: 12
Offset : 00:00:00Ticks : 637446075670000000
UtcTicks
: 637446075670000000
TimeOfDay : 19:26:07
Year : 2020
Many slow commands in a short period of time (same minute or less) is a reason for concern. Review
the nature of commands and how they can be optimized (see previous examples). If commands with
O(1) time complexity are frequently reported, check the other factors for high CPU usage mentioned
before.
• Latency metrics: ElastiCache for Redis provides CloudWatch metrics to monitor the average latency for
different classes of commands. The datapoint is calculated by dividing the total number of executions
of commands in the category by the total execution time in the period. It is important to understand
that latency metric results are an aggregate of multiple commands. A single command can cause
unexpected results, like timeouts, without significant impact on the metrics. For such cases, the
slowlog events would be a more accurate source of information. The following list contains the latency
metrics available and the respective commands that affect them.
• EvalBasedCmdsLatency: related to Lua Script commands, eval, evalsha;
• GeoSpatialBasedCmdsLatency: geodist, geohash, geopos, georadius, georadiusbymember,
geoadd;
• GetTypeCmdsLatency: Read commands, regardless of data type;
• HashBasedCmdsLatency: hexists, hget, hgetall, hkeys, hlen, hmget, hvals, hstrlen, hdel,
hincrby, hincrbyfloat, hmset, hset, hsetnx;
• HyperLogLogBasedCmdsLatency: pfselftest, pfcount, pfdebug, pfadd, pfmerge;
• KeyBasedCmdsLatency: Commands that can act upon different data types: dump, exists, keys,
object, pttl, randomkey, ttl, type, del, expire, expireat, move, persist, pexpire,
pexpireat, rename, renamenx, restoreK, sort, unlink;
• ListBasedCmdsLatency: lindex, llen, lrange, blpop, brpop, brpoplpush, linsert, lpop, lpush, lpushx,
lrem, lset, ltrim, rpop, rpoplpush, rpush, rpushx;
• PubSubBasedCmdsLatency: psubscribe, publish, pubsub, punsubscribe, subscribe, unsubscribe;
• SetBasedCmdsLatency: scard, sdiff, sinter, sismember, smembers, srandmember, sunion,
sadd, sdiffstore, sinterstore, smove, spop, srem, sunionstore;
• SetTypeCmdsLatency: Write commands, regardless of data-type;
• SortedSetBasedCmdsLatency: zcard, zcount, zrange, zrangebyscore, zrank, zrevrange,
zrevrangebyscore, zrevrank, zscore, zrangebylex, zrevrangebylex, zlexcount,
zadd. zincrby, zinterstore, zrem, zremrangebyrank, zremrangebyscore, zunionstore,
zremrangebylex, zpopmax, zpopmin, bzpopmin, bzpopmax;
Starting with Elasticache Redis 2.8.22, AWS introduced a forkless backup and replication method.
The new method may delay writes in order to prevent failures. Both methods can cause periods
of higher CPU utilization, lead to higher response times and consequently lead to client timeouts
during their execution. Always check if the client failures happen during the backup window or the
SaveInProgress metric was 1 in the period. It is advisable to schedule the backup window for
periods of low utilization to minimize the possibility of issues with clients or backup failures.
• Bugs in the client application may cause connections to be forgotten and kept established with an
idle state. This is called "connection leak“ and the consequence is a steady increase on the number
of established connections observed on the CurrConnections metric. This behavior can result in
saturation on the client or ElastiCache side. When an immediate fix is not possible from the client side,
some administrators set a ”timeout“ value in their ElastiCache parameter group. The timeout is the
time in seconds allowed for idle connections to persist. If the client doesn’t submit any request in the
period, the Redis engine will terminate the connection as soon as the connection reaches the timeout
value. Small timeout values may result in unnecessary disconnections and clients will need handle
them properly and reconnect, causing delays.
• The memory used to store keys is shared with client buffers. Slow clients with big requests or
responses may demand a significant amount of memory to handle its buffers. The default ElastiCache
for Redis configurations does not restrict the size of regular client output buffers. If the maxmemory
limit is hit, the engine will try to evict items to fulfill the buffer usage. In extreme low memory
conditions, ElastiCache for Redis might choose to disconnect clients that consume large client output
buffers in order to free memory and retain the cluster’s health.
It is possible to limit the size of client buffers with custom configurations and clients hitting the limit
will be disconnected. However, clients should be able to handle unexpected disconnections. The
parameters to handle buffers size for regular clients are the following:
• client-query-buffer-limit: Maximum size of a single input request;
• client-output-buffer-limit-normal-soft-limit: Soft limit for client connections. The connection will be
terminated if stays above the soft limit for more than the time in seconds defined on client-output-
buffer-limit-normal-soft-seconds or if it hits the hard limit;
• client-output-buffer-limit-normal-soft-seconds: Time allowed for the connections exceeding the
client-output-buffer-limit-normal-soft-limit;
• client-output-buffer-limit-normal-hard-limit: A connection hitting this limit will be immediatelly
terminated.
API Version 2015-02-02
644
Amazon ElastiCache for Redis User Guide
Client-side troubleshooting for Amazon EC2 instances
Besides the regular client buffers, the following options control the buffer for replica nodes and Pub/
Sub (Publish/Subscribe) clients:
• client-output-buffer-limit-replica-hard-limit;
• client-output-buffer-limit-replica-soft-seconds;
• client-output-buffer-limit-replica-hard-limit;
• client-output-buffer-limit-pubsub-soft-limit;
• client-output-buffer-limit-pubsub-soft-seconds;
• client-output-buffer-limit-pubsub-hard-limit;
• CPU:
• EC2 instance CPU usage: Make sure the CPU hasn’t been saturated or near to 100 percent. Historical
analysis can be done via CloudWatch, however keep in mind that data points granularity is either 1
minute (with detailed monitoring enabled) or 5 minutes;
• If using burstable EC2 instances, make sure that their CPU credit balance hasn’t been depleted. This
information is available on the CPUCreditBalance CloudWatch metric.
• Short periods of high CPU usage can cause timeouts without reflecting on 100 percent utilization on
CloudWatch. Such cases require real-time monitoring with operating-system tools like top, ps and
mpstat.
• Network
• Check if the Network throughput is under acceptable values according to the instance capabilities.
For more information, see Amazon EC2 Instance Types
• On instances with the ena Enhanced Network driver, check the ena statistics for timeouts or
exceeded limits. The following statistics are useful to confirm network limits saturation:
• bw_in_allowance_exceeded / bw_out_allowance_exceeded: number of packets shaped
due to excessive inbound or outbound throughput;
• conntrack_allowance_exceeded: number of packets dropped due to security groups
connection tracking limits. New connections will fail when this limit is saturated;
• linklocal_allowance_exceeded: number of packets dropped due to excessive requests to
instance meta-data, NTP via VPC DNS. The limit is 1024 packets per second for all the services;
• pps_allowance_exceeded: number of packets dropped due to excessive packets per second
ratio. The PPS limit can be hit when the network traffic consists on thousands or millions of very
small requests per second. ElastiCache traffic can be optimized to make better use of network
packets via pipelines or commands that do multiple operations at once like MGET instead of GET.
From the output above we can confirm that the TCP three-way handshake was completed in 222
microseconds (918091 - 917869) and the ping command was submitted and returned in 173
microseconds (918295 - 918122).
It took 438 microseconds (918307 - 917869) from requesting to closing the connection. Those results
would confirm that network and engine response times are good and the investigation can focus on
other components.
• On the operating system: Strace can help identifying time gaps on the OS level. The analysis of
actual applications would be way more extensive and specialized application profilers or debuggers are
advisable. The following example just shows if the base operating system components are working as
expected, otherwise further investigation may be required. Using the same Redis PING command with
strace we get:
1609430221.709084
(+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
(+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK,
IPPROTO_IP) = 3
1609430221.717419
(+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"...,
2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28-
>16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3,
"\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")},
[28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0,
[128]) = -1 ENOTSOCK
(Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128-
>0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
(+ 0.003569) +++ exited with 0 +++
In the example above, the command took a little more than 54 milliseconds to complete (752110 -
697712 = 54398 microseconds).
A significant amount of time, approximately 20ms, was taken to instantiate nc and do the name
resolution (from 697712 to 717890), after that, 2ms were required to create the TCP socket (745659
to 747858), and 0.4 ms (747858 to 748330) to submit and receive the response for the request.
To view the quotas for ElastiCache, open the Service Quotas console. In the navigation pane, choose
AWS services and select ElastiCache.
To request a quota increase, see Requesting a Quota Increase in the Service Quotas User Guide. If the
quota is not yet available in Service Quotas, use the limit increase form.
Resource Default
Reference
The topics in this section cover working with the Amazon ElastiCache API and the ElastiCache section of
the AWS CLI. Also included in this section are common error messages and service notifications.
Topics
• Using the query API (p. 649)
• Available libraries (p. 651)
• Troubleshooting applications (p. 652)
Each Query request must include some common parameters to handle authentication and selection of
an action.
Some operations take lists of parameters. These lists are specified using the param.n notation. Values of
n are integers starting from 1.
The following are the basic steps used to authenticate requests to AWS. This assumes you are registered
with AWS and have an Access Key ID and Secret Access Key.
4. AWS uses the Access Key ID to look up the Secret Access Key.
5. AWS generates a signature from the request data and the Secret Access Key using the same
algorithm used to calculate the signature in the request.
6. If the signatures match, the request is considered to be authentic. If the comparison fails, the
request is discarded, and AWS returns an error response.
Note
If a request contains a Timestamp parameter, the signature calculated for the request expires
15 minutes after its value.
If a request contains an Expires parameter, the signature expires at the time specified by the
Expires parameter.
1. Create the canonicalized query string that you need later in this procedure:
a. Sort the UTF-8 query string components by parameter name with natural byte ordering.
The parameters can come from the GET URI or from the POST body (when Content-Type is
application/x-www-form-urlencoded).
b. URL encode the parameter name and values according to the following rules:
i. Do not URL encode any of the unreserved characters that RFC 3986 defines. These
unreserved characters are A-Z, a-z, 0-9, hyphen ( - ), underscore ( _ ), period ( . ), and tilde
( ~ ).
ii. Percent encode all other characters with %XY, where X and Y are hex characters 0-9 and
uppercase A-F.
iii. Percent encode extended UTF-8 characters in the form %XY%ZA....
iv. Percent encode the space character as %20 (and not +, as common encoding schemes do).
c. Separate the encoded parameter names from their encoded values with the equals sign ( = )
(ASCII character 61), even if the parameter value is empty.
d. Separate the name-value pairs with an ampersand ( & ) (ASCII code 38).
2. Create the string to sign according to the following pseudo-grammar (the "\n" represents an ASCII
newline).
The HTTPRequestURI component is the HTTP absolute path component of the URI up to, but not
including, the query string. If the HTTPRequestURI is empty, use a forward slash ( / ).
3. Calculate an RFC 2104-compliant HMAC with the string you just created, your Secret Access Key as
the key, and SHA256 or SHA1 as the hash algorithm.
For example, the following is a sample request (linebreaks added for clarity).
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterIdentifier=myCacheCluster
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-12-01
For the preceding query string, you would calculate the HMAC signature over the following string.
GET\n
elasticache.amazonaws.com\n
Action=DescribeCacheClusters
&CacheClusterIdentifier=myCacheCluster
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE%2F20140523%2Fus-west-2%2Felasticache%2Faws4_request
&X-Amz-Date=20141201T223649Z
&X-Amz-SignedHeaders=content-type%3Bhost%3Buser-agent%3Bx-amz-content-sha256%3Bx-amz-
date
content-type:
host:elasticache.us-west-2.amazonaws.com
user-agent:CacheServicesAPICommand_Client
x-amz-content-sha256:
x-amz-date:
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterIdentifier=myCacheCluster
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20141201/us-west-2/elasticache/aws4_request
&X-Amz-Date=20141201T223649Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=2877960fced9040b41b4feaca835fd5cfeb9264f768e6a0236c9143f915ffa56
For detailed information on the signing process and calculating the request signature, see the topic
Signature Version 4 Signing Process and its subtopics.
Available libraries
AWS provides software development kits (SDKs) for software developers who prefer to build applications
using language-specific APIs instead of the Query API. These SDKs provide basic functions (not included
in the APIs), such as request authentication, request retries, and error handling so that it is easier to get
started. SDKs and additional resources are available for the following programming languages:
• Java
• Windows and .NET
• PHP
• Python
• Ruby
For information about other languages, see Sample Code & Libraries.
Troubleshooting applications
ElastiCache provides specific and descriptive errors to help you troubleshoot problems while interacting
with the ElastiCache API.
Retrieving errors
Typically, you want your application to check whether a request generated an error before you spend any
time processing results. The easiest way to find out if an error occurred is to look for an Error node in
the response from the ElastiCache API.
XPath syntax provides a simple way to search for the presence of an Error node, as well as an easy way
to retrieve the error code and message. The following code snippet uses Perl and the XML::XPath module
to determine if an error occurred during a request. If an error occurred, the code prints the first error
code and message in the response.
use XML::XPath;
my $xp = XML::XPath->new(xml =>$response);
if ( $xp->find("//Error") )
{print "There was an error processing your request:\n", " Error code: ",
$xp->findvalue("//Error[1]/Code"), "\n", " ",
$xp->findvalue("//Error[1]/Message"), "\n\n"; }
Troubleshooting tips
We recommend the following processes to diagnose and resolve problems with the ElastiCache API.
To do this, simply open a browser window and submit a query request to the ElastiCache service (such
as https://elasticache.amazonaws.com). A MissingAuthenticationTokenException or 500 Internal
Server Error confirms that the service is available and responding to requests.
• Check the structure of your request.
Each ElastiCache operation has a reference page in the ElastiCache API Reference. Double-check that
you are using parameters correctly. To give you ideas regarding what might be wrong, look at the
sample requests or user scenarios to see if those examples are doing similar operations.
• Check the forum.
ElastiCache has a discussion forum where you can search for solutions to problems others have
experienced along the way. To view the forum, see
https://forums.aws.amazon.com/ .
Follow the instructions in this topic only if you are going to the AWS CLI for ElastiCache.
Important
The Amazon ElastiCache Command Line Interface (CLI) does not support any ElastiCache
improvements after API version 2014-09-30. To use newer ElastiCache functionality from the
command line, use the AWS Command Line Interface.
Topics
• Prerequisites (p. 653)
• Getting the command line tools (p. 654)
• Setting up the tools (p. 654)
• Providing credentials for the tools (p. 655)
• Environmental variables (p. 655)
Prerequisites
This document assumes that you can work in a Linux/UNIX or Windows environment. The Amazon
ElastiCache command line tools also work on Mac OS X, which is a UNIX-based environment; however, no
specific Mac OS X instructions are included in this guide.
As a convention, all command line text is prefixed with a generic PROMPT> command line prompt.
The actual command line prompt on your machine is likely to be different. We also use $ to indicate
a Linux/UNIX specific command and C:\> for a Windows specific command. The example output
resulting from the command is shown immediately thereafter without any prefix.
$ export JAVA_HOME=<PATH>
2. Confirm the path setting by running $JAVA_HOME/bin/java -version and checking the output.
$ $JAVA_HOME/bin/java -version
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) Client VM (build 19.0-b09, mixed mode, sharing)
• Open a command line window and enter one of the following commands to set the
AWS_ELASTICACHE_HOME environment variable.
$ export &AWS;_ELASTICACHE_HOME=<path-to-tools>
To make the tools easier to use, we recommend that you add the tools' BIN directory to your system
PATH. The rest of this guide assumes that the BIN directory is in your system path.
• Enter the following commands to add the tools' BIN directory to your system PATH.
$ export PATH=$PATH:$&AWS;_ELASTICACHE_HOME/bin
Note
The Windows environment variables are reset when you close the command window. You might
want to set them permanently. Consult the documentation for your version of Windows for
more information.
Note
Paths that contain a space must be wrapped in double quotes, for example:
"C:\Program Files\Java"
Important
On UNIX, limit permissions to the owner of the credential file:
With the credentials file setup, you'll need to set the AWS_CREDENTIAL_FILE environment variable so
that the ElastiCache tools can find your information.
• On Linux and UNIX, update the variable using the following command:
2. Check that your setup works properly, run the following command:
elasticache --help
You should see the usage page for all ElastiCache commands.
Environmental variables
Environment variables can be useful for scripting, configuring defaults or temporarily overriding them.
In addition to the AWS_CREDENTIAL_FILE environment variable, most API tools included with the
ElastiCache Command Line Interface support the following variables:
The following examples show how to set the environmental variable EC2_REGION to configure the
region used by the API tools:
Linux, OS X, or Unix
$ export EC2_REGION=us-west-1
Windows
$ set EC2_REGION=us-west-1
Error Message: Cluster node quota exceeded. Each cluster can have at most %n nodes in this region.
Cause: You attempted to create or modify a cluster with the result that the cluster would have more
than %n nodes.
Solution: Change your request so that the cluster does not have more than %n nodes. Or, if you
need more than %n nodes, make your request using the Amazon ElastiCache Node request form.
For more information, see Amazon ElastiCache Limits in Amazon Web Services General Reference.
Error Messages: Customer node quota exceeded. You can have at most %n nodes in this region Or, You
have already reached your quota of %s nodes in this region.
Cause: You attempted to create or modify a cluster with the result that your account would have
more than %n nodes across all clusters in this region.
Solution: Change your request so that the total nodes in the region across all clusters for this
account does not exceed %n. Or, if you need more than %n nodes, make your request using the
Amazon ElastiCache Node request form.
For more information, see Amazon ElastiCache Limits in Amazon Web Services General Reference.
Error Messages: The maximum number of manual snapshots for this cluster taken within 24 hours has
been reached or The maximum number of manual snapshots for this node taken within 24 hours has
been reached its quota of %n
Cause: You attempted to take a manual snapshot of a cluster when you have already taken the
maximum number of manual snapshots allowed in a 24-hour period.
Solution: Wait 24 hours to attempt another manual snapshot of the cluster. Or, if you need to take a
manual snapshot now, take the snapshot of another node that has the same data, such as a different
node in a cluster.
Error Messages: InsufficientCacheClusterCapacity
Cause: AWS does not currently have enough available On-Demand capacity to service your request.
Solution:
• Wait a few minutes and then submit your request again; capacity can shift frequently.
• Submit a new request with a reduced number of nodes or shards (node groups). For example,
if you're making a single request to launch 15 nodes, try making 3 requests of 5 nodes, or 15
requests for 1 node instead.
• If you're launching a cluster, submit a new request without specifying an Availability Zone.
• If you're launching a cluster, submit a new request using a different node type (which you can scale
up at a later stage). For more information, see Scaling ElastiCache for Redis clusters (p. 345).
Notifications
This topic covers ElastiCache notifications that you might be interested in. A notification is a situation
or event that, in most cases, is temporary, lasting only until a solution is found and implemented.
Notifications generally have a start date and a resolution date, after which the notification is no longer
relevant. Any one notification might or might not be relevant to you. We recommend an implementation
guideline that, if followed, improves the performance of your cluster.
The following table describes important changes in each release of the ElastiCache for Redis User Guide
after March 2018. For notification about updates to this documentation, you can subscribe to the RSS
feed.
ElastiCache now supports AWS PrivateLink allows you January 24, 2022
PrivateLink (p. 658) to privately access ElastiCache
API operations without an
internet gateway, NAT device,
VPN connection, or AWS
Direct Connect connection.
For more information, see
Amazon ElastiCache API and
interface VPC endpoints (AWS
PrivateLink) for Redis or Amazon
ElastiCache API and interface
VPC endpoints (AWS PrivateLink)
for Memcached.
ElastiCache for Redis now Amazon ElastiCache for Redis November 23, 2021
supports Redis 6.2 and Data introduces the next version of
Tiering (p. 658) the Redis engine supported by
Amazon ElastiCache. ElastiCache
for Redis 6.2 includes
performance improvements
for TLS-enabled clusters using
x86 node types with 8 vCPUs
or more or Graviton2 node
types with 4 vCPUs or more.
ElastiCache for Redis also
introduces data tiering. You can
use data tiering as a lower-cost
way to scale your clusters to
up to hundreds of terabytes of
capacity. For more information,
see ElastiCache for Redis version
6.2 (enhanced) and Data tiering.
Support for Auto ElastiCache for Redis now August 19, 2021
Scaling (p. 658) supports Auto Scaling.
ElastiCache for Redis auto
scaling is the ability to increase
or decrease the desired shards
Support for delivery of Redis ElastiCache now lets you stream April 22, 2021
Slow logs (p. 658) Redis SLOWLOG to one of
two destinations: Amazon
Kinesis Data Firehose or Amazon
CloudWatch Logs. For more
information, see Log delivery.
ElastiCache is now available on AWS Outposts bring native AWS October 8, 2020
AWS Outposts (p. 658) services, infrastructure, and
operating models to virtually
any data center, co-location
space, or on-premises facility.
You can deploy ElastiCache on
Outposts to set up, operate, and
use cache on-premises, just as
you would in the cloud. For more
information, see Using Outposts
for Redis or Using Outposts for
Memcached.
ElastiCache now supports Redis Amazon ElastiCache for Redis October 7, 2020
6 (p. 658) introduces the next version of
the Redis engine supported by
Amazon ElastiCache. This version
includes authenticating users
with role-based access control,
versionless support, client-
side caching, and significant
operational improvements.
For more information, see
ElastiCache for Redis Version 6.0
(Enhanced).
ElastiCache now supports Local A Local Zone is an extension September 25, 2020
Zones (p. 658) of an AWS Region that is
geographically close to your
users. You can extend any virtual
private cloud (VPC) from a
parent AWS Region into Local
Zones by creating a new subnet
and assigning it to a Local Zone.
For more information, see Using
Local Zones.
ElastiCache for Redis now The Redis Cluster mode makes August 13, 2020
supports scaling your Redis configurations possible that you
Cluster environment up to 500 can use to partition your data
nodes or 500 shards (p. 658) across multiple shards and offers
better scalability, performance,
and availability. This feature is
available on Amazon ElastiCache
for Redis version 5.0.6 onwards
in all AWS Regions and for all
existing and new ElastiCache
for Redis Cluster environments.
For more information, see Redis
Nodes and Shards.
ElastiCache now You can now restrict the scope August 12, 2020
supports resource-level of a user's permissions by
permissions (p. 658) specifying ElastiCache resources
in an AWS Identity and Access
Management (IAM) policy. For
more information, see Resource-
level permissions.
ElastiCache for Redis adds ElastiCache for Redis now June 10, 2020
additional Amazon CloudWatch supports new CloudWatch
metrics (p. 658) metrics, including PubSubCmds
and HyperLogLogBasedCmds.
For a full list, see Metrics for
Redis.
ElastiCache for Redis now The Global Datastore for Redis March 16, 2020
supports Global Datastore for feature offers fully managed,
Redis (p. 658) fast, reliable, and secure
replication across AWS Regions.
Using this feature, you can
create cross-Region read replica
clusters for ElastiCache for Redis
to enable low-latency reads
and disaster recovery across
AWS Regions. You can create,
modify, and describe a global
datastore. You can also add or
remove AWS Regions from your
global datastore and promote an
AWS Region as primary within
a global datastore. For more
information, see Replication
Across AWS Regions Using
Global Datastore.
ElastiCache for Redis now For more information, see December 18, 2019
supports Redis version 5.0.6 ElastiCache for Redis Version
(p. 658) 5.0.6 (Enhanced).
Amazon ElastiCache now You can now launch the next November 12, 2019
supports T3-Standard cache generation general-purpose
nodes (p. 658) burstable T3-Standard cache
nodes in Amazon ElastiCache.
Amazon EC2’s T3-Standard
instances provide a baseline
level of CPU performance with
the ability to burst CPU usage
at any time until the accrued
credits are exhausted. For more
information, see Supported
Node Types.
Amazon ElastiCache now ElastiCache for Redis 5.0.5 October 30, 2019
supports modifying the AUTH now enables you to modify
token on an existing ElastiCache authentication tokens by setting
for Redis server (p. 658) and rotating new tokens. You
can now modify active tokens
while they're in use. You can
also add brand-new tokens
to existing clusters enabled
with encryption in transit that
were previously set up without
authentication tokens. This is
a two-step process by which
you can set and rotate the
token without interrupting
client requests. This feature
is currently not supported on
AWS CloudFormation. For more
information, see Authenticating
Users with the Redis AUTH
Command.
Amazon ElastiCache now You can now use Online October 28, 2019
supports online data migration Migration to migrate your
from Redis on Amazon EC2 data from self-hosted
(p. 658) Redis on Amazon EC2 to
Amazon ElastiCache. For
more information, see Online
Migration to ElastiCache.
ElastiCache for Redis now This update includes online September 23, 2019
supports Redis version 5.0.5 configuration changes for
(p. 658) ElastiCache for Redis of
autofailover clusters during all
planned operations. For more
information, see ElastiCache for
Redis Version 5.0.5 (Enhanced).
ElastiCache for Redis introduces You can now scale up or scale August 20, 2019
online vertical scaling for Redis down your sharded Redis Cluster
Cluster mode. (p. 658) on demand. ElastiCache for
Redis resizes your cluster by
changing the node type, while
the cluster continues to stay
online and serve incoming
requests. For more information,
see Online Vertical Scaling by
Modifying Node Type.
ElastiCache for Redis now allows This feature allows you June 13, 2019
users to use a single reader to direct all read traffic to
endpoint for your Amazon your ElastiCache for Redis
ElastiCache for Redis cluster. cluster through a single,
(p. 658) cluster-level endpoint to take
advantage of load balancing
and higher availability. For
more information, see Finding
connection endpoints.
ElastiCache for Redis now allows With this feature, you can June 4, 2019
users to apply service updates choose to apply available
on their own schedule (p. 658) service updates at a time of your
choosing and not just during
maintenance windows. This will
minimize service interruptions,
particularly during peak business
flows, and help ensure you
remain compliant if your cluster
is in ElastiCache-supported
compliance programs. For more
information, see Self-Service
Updates in Amazon ElastiCache
and Self-Service Security
Updates for Compliance.
ElastiCache for Redis now This also includes improved May 15, 2019
supports Redis version 5.0.4, Hyperloglog error handling and
including engine stability other enhancements. For more
guarantee in special conditions. information, see Redis 5.0.4
(p. 658) release notes.
ElastiCache for Redis now This includes bug fixes to February 28, 2019
supports Redis version 5.0.3 and improve sorted set edge cases,
ability to rename commands. accurate memory usage.
(p. 658) For more information, see
Redis 5.0.3 release notes.
It also includes support for
renaming commands. For more
information, see ElastiCache for
Redis Version 5.0.3 (Enhanced).
ElastiCache Standard Reserved Reserved Instances give you the January 18, 2019
Instance offerings: Partial flexibility to reserve an Amazon
Upfront, All Upfront and No ElastiCache instance for a one-
Upfront. (p. 658) or three-year term based on an
instance type and AWS Region.
For more information, see
Managing Costs with Reserved
Nodes.
ElastiCache for Redis support The node or shard limit can November 19, 2018
for up to 250 nodes per Redis be increased to a maximum of
cluster 250 per ElastiCache for Redis
cluster. For more information,
see Shards.
ElastiCache for Redis support ElastiCache for Redis introduces November 19, 2018
for autofailover and backup and support for autofailover,
restore on all T2 nodes (p. 658) creating snapshots, and backup
and restore on all T2 nodes.
For more information, see
ElastiCache for Redis Backup and
Restore and Snapshot.
Support for ElastiCache for Redis ElastiCache for Redis now November 9, 2018
5.0.0 supports Redis 5.0.0, including
Redis streams. For more
information, see ElastiCache for
Redis Version 5.0.0 (Enhanced).
It has also added a new metric,
StreamBasedCmds, which
reports the sum of all of the
commands that act upon one
or more streams data type. For
more information, see Metrics
for Redis.
ElastiCache for Redis support for ElastiCache for Redis now October 23, 2018
M5 and R5 nodes supports M5 and R5 nodes,
general-purpose and memory-
optimized instance types based
on the AWS Nitro System.
For more information, see
Supported Node Types.
Support for dynamically ElastiCache for Redis has September 17, 2018
changing the number of read added support for adding and
replicas removing read replicas from
any cluster with no cluster
downtime. For more information
about these and other changes
in this release, see Changing
the Number of Replicas in the
ElastiCache for Redis User Guide.
See also DecreaseReplicaCount
and IncreaseReplicaCount in the
ElastiCache API Reference.
Redis (cluster mode enabled) Amazon ElastiCache for Redis August 20, 2018
engine upgrades has added support for upgrading
Redis (cluster mode enabled)
engine versions. For more
information, see Upgrading
Engine Versions.
PCI DSS compliance certification ElastiCache for Redis is now July 5, 2018
certified for PCI DSS compliance.
For more information, see
ElastiCache for Redis PCI DSS
Compliance.
Support for ElastiCache for Redis ElastiCache for Redis now June 14, 2018
4.0.10 supports Redis 4.0.10, including
both encryption and online
cluster resizing in a single
version. For more information,
see ElastiCache for Redis Version
4.0.10 (Enhanced).
User Guide restructure (p. 658) The single ElastiCache User April 20, 2018
Guide is now restructured so
that there are separate user
guides for Redis (ElastiCache
for Redis User Guide) and
for Memcached (ElastiCache
for Memcached User Guide).
The documentation structure
in the AWS CLI Command
Reference: elasticache section
and the Amazon ElastiCache API
Reference remain unchanged.
The following table describes the important changes to the ElastiCache for Redis User Guide before
March 2018.
Support for Asia ElastiCache added support for the Asia Pacific February 12, 2018
Pacific (Osaka- (Osaka-local) Region. The Asia Pacific (Osaka) Region
local) Region. currently supports a single Availability Zone and is
by invitation only. For more information, see the
following:
Support for EU ElastiCache added support for the EU (Paris) Region. December 18, 2017
(Paris). For more information, see the following:
Support for China Amazon ElastiCache added support for China December 11, 2017
(Ningxia) Region (Ningxia) Region. For more information, see the
following:
Support for This release of ElastiCache added support for Service December 7, 2017
Service Linked Linked Roles (SLR). For more information, see the
Roles following:
Support for R4 This release of ElastiCache added support R4 node November 20, 2017
node types types in all AWS Regions supported by ElastiCache.
You can purchase R4 node types as On-Demand or as
Reserved Cache Nodes. For more information, see the
following:
ElastiCache for Amazon ElastiCache for Redis adds support for November 9, 2017
Redis 3.2.10 and ElastiCache for Redis 3.2.10. ElastiCache for Redis
HIPAA eligibility ElastiCache for Redis version 3.2.6 is now certified for November 2, 2017
HIPAA eligibility when encryption is enabled on your
cluster. For more information, see the following:
ElastiCache ElastiCache adds support for ElastiCache for Redis October 25, 2017
for Redis 3.2.6 3.2.6, which includes two encryption features:
and support for
encryption • In-transit encryption encrypts your data whenever
it is in transit, such as between nodes in a cluster or
between a cluster and your application.
• At-rest encryption encrypts your on-disk data
during sync and backup operations.
Support for ElastiCache adds support for testing Automatic April 4, 2017
testing Automatic Failover on Redis clusters that support replication. For
Failover more information, see the following:
Enhanced Redis ElastiCache adds enhanced Redis backup and March 15, 2017
restore restore with cluster resizing. This feature supports
restoring a backup to a cluster with a different
number of shards than the cluster used to create
the backup. (For the API and CLI, this feature can
restore a different number of node groups rather
than a different number of shards.) This update also
supports different Redis slot configurations. For
more information, see Restoring from a backup with
optional cluster resizing (p. 334).
New Redis ElastiCache adds a new Redis parameter, reserved- March 15, 2017
memory memory-percent, which makes managing your
management reserved memory easier. This parameter is available
parameter on all versions of ElastiCache for Redis. For more
information, see the following:
Support for EU ElastiCache adds support for EU (London) Region. December 13, 2016
West (London) Only node types T2 and M4 are currently supported.
Region For more information, see the following:
Support for ElastiCache adds support for the Canada (Montreal) December 8, 2016
Canada (Montreal) Region. Only node type M4 and T2 are currently
Region supported in this AWS Region. For more information,
see the following:
Support for M4 ElastiCache adds support for R3 and M4 node types in November 1, 2016
and R3 node types South America (São Paulo) Region and M4 node types
in China (Beijing) Region. For more information, see
the following:
US East 2 (Ohio) ElastiCache adds support for the US East (Ohio) October 17, 2016
Region support Region (us-east-2) with M4, T2, and R3 node types.
For more information, see the following:
Support for Redis ElastiCache adds support for Redis Cluster October 12, 2016
Cluster (enhanced). Customers using Redis Cluster, can
partition their data across up to 15 shards (node
groups). Each shard supports replication with up to
5 read replicas per shard. Redis Cluster automatic
failover times are about one fourth as long as those
of earlier versions.
M4 node type ElastiCache adds support for the M4 family of node August 3, 2016
support types in most AWS Regions supported by ElastiCache.
You can purchase M4 node types as On-Demand or as
Reserved Cache Nodes. For more information, see the
following:
Mumbai Region ElastiCache adds support for the Asia Pacific June 27, 2016
support (Mumbai) Region. For more information, see the
following:
Snapshot export ElastiCache adds the ability to export a Redis May 26, 2016
snapshot so you can access it from outside
ElastiCache. For more information, see the following:
Node type scale ElastiCache adds the ability to scale up your Redis March 24, 2016
up node type. For more information, see Scaling
ElastiCache for Redis clusters (p. 345).
Easy engine ElastiCache adds the ability to easily upgrade your March 22, 2016
upgrade Redis cache engine. For more information, see
Upgrading engine versions (p. 198).
Support for R3 ElastiCache adds support for R3 node types in the March 16, 2016
node types China (Beijing) Region and South America (São Paulo)
Region. For more information, see Supported node
types (p. 99).
Support for Redis ElastiCache adds support for Redis version 2.8.24 January 20, 2016
2.8.24 with improvements added since Redis 2.8.23.
Improvements include bug fixes and support for
logging bad memory access addresses. For more
information, see the following:
Support for Asia ElastiCache adds support for the Asia Pacific (Seoul) January 6, 2016
Pacific (Seoul) (ap-northeast-2) Region with t2, m3, and r3 node
Region types.
Amazon Because the newer Redis versions provide a better December 15, 2015
ElastiCache and more stable user experience, Redis versions
console change. 2.6.13, 2.8.6, and 2.8.19 are no longer listed in the
ElastiCache Management Console. For other options
and more information, see Supported ElastiCache for
Redis versions (p. 189).
Support for Redis ElastiCache adds support for Redis version 2.8.23 November 13, 2015
2.8.23. with improvements added since Redis 2.8.22.
Improvements include bug fixes and support
for the new parameter close-on-slave-
write which, if enabled, disconnects clients who
attempt to write to a read-only replica. For more
information, see ElastiCache for Redis version 2.8.23
(enhanced) (p. 196).
Support for Redis ElastiCache adds support for Redis version 2.8.22 September 28, 2015
2.8.22. with ElastiCache added enhancements and
improvements since version 2.8.21. Improvements
include:
Support for Redis ElastiCache adds support for Redis version 2.8.21 July 29, 2015
2.8.21 and Redis improvements since version 2.8.19. This
Redis release includes several bug fixes. For more
information, see Redis 2.8 release notes.
New topic: Added new topic on how to access ElastiCache July 9, 2015
Accessing resources from outside AWS. For more information,
ElastiCache from see Accessing ElastiCache resources from outside
outside AWS AWS (p. 171).
Support for Redis ElastiCache adds support for Redis version 2.8.19 and March 11, 2015
v. 2.8.19. Redis improvements since version 2.8.6. This support
includes support for:
Support for cost ElastiCache adds support for cost allocation tags. February 9, 2015
allocation tags For more information, see Monitoring costs with cost
allocation tags (p. 210).
Support for AWS ElastiCache adds support for the AWS GovCloud (US- January 29, 2015
GovCloud (US- West) (us-gov-west-1) Region.
West) Region
Support for ElastiCache adds support for the Europe (Frankfurt) January 19, 2015
Europe (Frankfurt) (eu-central-1) Region.
Region
Multi-AZ support ElastiCache adds support for Multi-AZ from the October 24, 2014
for Redis primary node to a read replica in a Redis replication
replication groups group. ElastiCache monitors the health of the
replication group. If the primary fails, ElastiCache
automatically promotes a replica to primary, then
replaces the replica. For more information, see
Minimizing downtime in ElastiCache for Redis with
Multi-AZ (p. 253).
AWS CloudTrail ElastiCache adds support for using AWS CloudTrail September 15, 2014
logging of API to log all ElastiCache API calls. For more information,
calls supported see Logging Amazon ElastiCache API calls with AWS
CloudTrail (p. 603).
New instance sizes ElastiCache adds support for additional General September 11, 2014
supported Purpose (T2) instances. For more information, see
Configuring engine parameters using parameter
groups (p. 423).
New instance sizes ElastiCache adds support for additional General July 1, 2014
supported Purpose (M3) instances and Memory Optimized (R3)
instances. For more information, see Configuring
engine parameters using parameter groups (p. 423).
Backup and In this release, ElastiCache allows customers to create April 24, 2014
restore for Redis snapshots of their Redis clusters, and create new
clusters clusters using these snapshots. A backup is a copy
of the cluster at a specific moment in time, and
consists of cluster metadata and all of the data in the
Redis cache. Backups are stored in Amazon S3, and
customers can restore the data from a snapshot into
a new cluster at any time. For more information, see
Backup and restore for ElastiCache for Redis (p. 310).
Redis 2.8.6 ElastiCache supports Redis 2.8.6, in addition to Redis March 13, 2014
2.6.13. With Redis 2.8.6, customers can improve the
resiliency and fault tolerance of read replicas, with
support for partial resynchronization, and a user-
defined minimum number of read replicas that must
be available at all times. Redis 2.8.6 also offers full
support for publish-and-subscribe, where clients can
be notified of events that occur on the server.
Redis cache engine ElastiCache offers Redis cache engine software, in September 3, 2013
addition to Memcached. Customers who currently
use Redis can "seed" a new ElastiCache Redis cache
cluster with their existing data from a Redis snapshot
file, easing migration to a managed ElastiCache
environment.
Support for In this release, ElastiCache is fully integrated with January 8, 2013
default Amazon Amazon Virtual Private Cloud (VPC). For new
Virtual Private customers, cache clusters are created in an Amazon
Cloud (VPC) VPC by default. For more information, see Amazon
VPCs and ElastiCache security (p. 502).
Support for In this release, ElastiCache clusters can be launched in December 20, 2012
Amazon Virtual Amazon Virtual Private Cloud (VPC). By default, new
Private Cloud customers' cache clusters are created in an Amazon
(VPC) VPC automatically; existing customers can migrate to
Amazon VPC at their own pace. For more information,
see Amazon VPCs and ElastiCache security (p. 502).
New cache node This release provides four additional cache node November 13, 2012
types types.
Reserved cache This release adds support for reserved cache nodes. April 5, 2012
nodes
New guide This is the first release of Amazon ElastiCache User August 22, 2011
Guide.
AWS glossary
For the latest AWS terminology, see the AWS glossary in the AWS General Reference.