Before migrating to Redis Cloud, you should evaluate the migration and consider the best option. Read this guide to determine which migration strategy is right for you.
540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353
6. For Objects, select List and Write.
7. For Bucket ACL, select Read and Write.
8. Click Save changes.
9. Add the following JSON to the Bucket policy. Replace UNIQUE-BUCKET-NAME with the name of your bucket:
{
"Version": "2012-10-17",
"Id": "MyBucketPolicy",
"Statement": [
{
"Sid": "RedisCloudBackupsAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::168085023892:root"
},
"Action": [
"s3:PutObject",
"s3:getObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::UNIQUE-BUCKET-NAME/*"
}
]
}
10. Disable “block all public access” at the account level and at the bucket level.
11. While still in the Permissions tab, edit Block public access (bucket settings).
12. Uncheck Block all public access.
13. Disable “block all public access” at the account level.
14. In the S3 navigation pane, click on Block Public Access settings for this account.
15. Uncheck Block all public access.
AWS does not allow direct access to ElastiCache instances. Your ElastiCache instance must be accessed from an EC2 instance with proper permissions. The following guide assumes that your ElastiCache instance is reachable from the internet via an EC2 instance.
Note: Live data migration is not supported by ElastiCache serverless.
By default, ElastiCache has keyspace notifications disabled. This feature is required for RIOT live mode. You will need to create a custom parameter group in order to modify configuration values for your ElastiCache. If your ElastiCache already has a custom parameter group, you can skip to step 5 to edit the notify-keyspace-events parameter.
10. In the left navigation pane, click on Redis OSS caches and select your ElastiCache instance.
11. Click Modify, under Parameter groups select your new parameter group.
12. Click Preview changes, then click Modify to confirm changes.
1. Use Instance Connect or SSH to connect to the new EC2 instance:
ssh -i “public key” AWS_EC2_INSTANCE
2. Install the redis-cli tool:
sudo apt update && sudo apt install -y redis-tools
3. Verify the connectivity with the ElastiCache instance, replace ELASTICACHE_ENDPOINT with your ElastiCache endpoint. Remove the --tls option if TLS is not enabled.
redis-cli --tls -h ELASTICACHE_ENDPOINT -p 6379
4. Install Java, we recommended using OpenJDK 21 or later:
sudo apt install -y openjdk-21-jdk
5. Install RIOT. Download the desired release. Then, unzip the package and make sure the RIOT binaries are in place, as shown here:
wget https://github.com/redis/riot/releases/download/v4.2.3/riot-4.2.3.tar && tar -xvf riot-4.2.3.tar && cd riot-4.2.3/bin/
6. You can check the version of RIOT by running the command below:
./riot --version
------------------------------------------------------------
riot 4.2.3
------------------------------------------------------------
Build time: 2025-02-16 18:35:57Z
Revision: d7a319522e4e72a2b5277e5a15bd715d557dedb6
JVM: 21.0.6 (Ubuntu 21.0.6+7-Ubuntu-124.04.1)
------------------------------------------------------------
Once Java and RIOT are installed, you are all set to begin the migration process which replicates data directly from the source (ElastiCache) to the target (Redis Cloud).
sudo ./riot replicate rediss://ELASTICACHE_ENDPOINT:port redis://username:password@REDIS_CLOUD_ENDPOINT:port --mode live
4. If you are migrating from an ElastiCache cluster, you must include the --source-cluster option
5. If you are migrating to a Redis Cloud cluster, you must include the --target-cluster option.
6. If TLS is not enabled in your ElastiCache cluster, replace rediss:// with redis://
7. Validate your migration and redirect your application’s traffic to the new Redis Cloud endpoint.
Note:
The live replication mechanism does not guarantee data consistency. Redis sends keyspace notifications over pub/sub which does not provide guaranteed delivery. It is possible that RIOT can miss some notifications in case of network failures for example.
Also, depending on the type, size, and rate of change of data structures on the source it is possible that RIOT cannot keep up with the change stream. For example if a big set is repeatedly updated, RIOT will need to read the whole set on each update and transfer it over to the target database. With a big-enough set, RIOT could fall behind and the internal queue could fill up leading up to updates being dropped.
For those potentially problematic migrations it is recommended to perform some preliminary sizing using Redis statistics and bigkeys/memkeys in tandem with --mem-limit. If you need assistance please contact your Redis account team.
For more information, see: