You can use Amazon ElastiCache to implement an in-memory storage layer between your application code and your database using the Memcached or Redis engines. Adding an in-memory storage layer can often lead to dramatic speed improvements for database accesses.
Regardless of which engine you choose, ElastiCache makes it easy to deploy, operate, and scale a cloud-based in-memory storage layer.
Backup and Restore
Today we are making ElastiCache for Redis even more powerful with the addition of backup and restore functionality. You can now create a snapshot of your entire Redis cluster as it exists at a specific point in time. You can schedule automatic, recurring daily snapshots and you can initiate a manual snapshot at any time.
The snapshots are stored in Amazon S3 with high durability, and can be used for warm starts, backups, and archiving. Restoring a cache snapshot creates a new ElastiCache for Redis cluster and populates it with the data from the snapshot. You can even create multiple ElastiCache for Redis clusters from a single snapshot. This can be handy for performance-sensitive applications that work best when running from a warm (well-populated) cache.
Let's take a tour of the new Backup and Restore functions in the AWS Management Console. You can establish a recurring backup schedule when you create a new Cache cluster or you can schedule backups for an existing cluster. You can choose the desired retention period (1 to 35 days), and you can also set the daily time range for automatic backups:
You can also create a snapshot manually, like this:
You can see your automatic and manual snapshots:
And you can restore a snapshot to create a new cluster:
Backup and Restore Notes
This new feature is now available in all AWS Regions where ElastiCache is currently available. You can create a snapshot from any ElastiCache instance type, with the exception of the t1.micro.
ElastiCache provides storage space for one snapshot free of charge for each active ElastiCache for Redis cluster. Storage for additional snapshots is priced at $0.085 / GB per month.
For better performance, we recommend taking snapshots on a read replica instead of on the master cache node. The snapshot process uses the Redis BGSAVE operation and is subject to its strengths and limitations. To be more specific, this operation causes the Redis process to fork into parent and child processes. The parent process continues to handle requests while the child process writes the snapshot to disk. The forking process can increase memory pressure within the cache node, leading to swapping and reduced performance. Moving this work to a read replica will minimize any possible impact on the performance of your application.