ElastiCache to Redis Cloud

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.

1. 1.Open the Amazon S3 console.
2. 2.Create a new S3 bucket to store Elasticache backups.
3. 3.Choose Permissions.
4. 4.Under Access control list (ACL), choose Edit.
5. 5.Click Add grantee, and then enter the following Elasticache canonical ID (this allows the Elasticache service to write backups to this S3 bucket):

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:

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.

1. 1.Open the ElastiCache console.
2. 2.From the navigation pane, choose Redis OSS caches.
3. 3.Select your Redis database
4. 4.In the Actions dropdown button, select Backup.
5. 5.Input a name for your backup and click Create Backup.
6. 6.In the navigation pane, under Resources, choose Backups.
7. 7.From the list of backups, select your backup.
8. 8.From the Actions dropdown menu, choose Export.
9. 9.In Target S3 location dropdown list, select the S3 bucket that you created.
10. 10.Click Export.
11. 11.Locate your backup RDB file in S3 and edit the permissions.
12. 12.In the Permissions tab click Edit
13. 13.For Authenticated users group (anyone with an AWS account), under Object check Read.

1. 1.In the Redis Cloud console, select the target database from the database list.
2. 2.Select Import.
3. 3.Enter the details for the RDB file:
4. 4.Source type - Select AWS S3.
5. 5.Source path - Enter the S3 URI for the RDB file from the previous step: s3://bucketname/[path/]filename.rdb
6. 6.For sharded databases with multiple RDB files, select Add source to add another RDB file.
7. 7.Select Import.
8. 8.Validate your migration and redirect your application’s traffic to the new Redis Cloud endpoint.

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.

1. 1.Open the ElastiCache console and select Parameter groups.
2. 2.Click Create parameter group.
3. 3.Name your parameter group, give it a description, and select the Redis version under Family.
4. 4.Click Create.
5. 5.From the Parameter groups page, click on the parameter group you just created, click Edit parameter values.
6. 6.Type in keyspace in Find parameters to filter for the notify-keyspace-events parameter.
7. 7.For Value, enter KEA.
8. 8.If your ElastiCache has cluster mode enabled, you will also need to modify the cluster-enabled parameter.
9. 9.Click Save changes.

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. 1.Open the ElastiCache console and select your Redis OSS cache.
2. 2.From the Actions dropdown button, select Set up compute connection.
3. 3.Create a new EC2 instance or select an existing one in the same VPC.
4. 4.Ubuntu is preferred, additional steps might be required if using Amazon Linux.
5. 5.Click Setup, this will create a new ENI and security groups to allow your instance access to ElastiCache.

1. Use Instance Connect or SSH to connect to the new EC2 instance:

2. Install the redis-cli tool:

3. Verify the connectivity with the ElastiCache instance, replace ELASTICACHE_ENDPOINT with your ElastiCache endpoint. Remove the --tls option if TLS is not enabled.

4. Install Java, we recommended using OpenJDK 21 or later:

5. Install RIOT. Download the desired release. Then, unzip the package and make sure the RIOT binaries are in place, as shown here:

6. You can check the version of RIOT by running the command below:

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

1. 1.Log into the Redis Cloud console.
2. 2.Click on your migration target and take note of the: public endpoint, username, and password
3. 3.Back in your EC2 instance run the command below:

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:

• •Redis Input/Output Tools (RIOT)
• •RIOT Live Replication