Skip to main content



We use Redis as the cache database for our ASM.

The main reasons why we chose it over other alternatives are:

  1. It supports clustering, allowing to distribute data accross nodes, granting horizontal autoscaling capabilities.
  2. It complies with several certifications from ISO and CSA. Many of these certifications are focused on granting that the entity follows best practices regarding secure cloud-based environments and information security.
  3. It can exist within the same VPC as AWS-hosted applications like our ASM.
  4. As it exists within the same VPC as our ASM, cached data only has to travel within the local network, increasing overrall application performance.
  5. It supports complex data types, which considerably simplifies mapping data from applications to it.
  6. It supports local deployments, allowing us to run Redis on local machines. This is especially useful for ephemeral environments.
  7. It can be fully managed as code using Terraform.
  8. It supports a wide range of cache node sizes, which come preconfigured and are very easy to set.
  9. It supports VPC security groups, allowing to specify networking inbound and outbound rules for IP addresses, ports and other security groups.
  10. It quickly adds support to the newest Redis versions.
  11. Redis cluster performance can be monitored via CloudWatch.


  1. AWS DynamoDB Accelerator (DAX): It is a cache that sits between DynamoDB and the application, allowing to cache data without having to maintain an extra layer of complexity in your application. It does not support local deployments, its query cache is not granular, generating inconsistencies when data changes via granular operations, it has a poorly maintained client.
  2. AWS DynamoDB (No cache): We are considering removing the entire extra layer of complexity that cache brings with it and only using DynamoDB, as it already provides very good performance. This could considerably simplify our ASM architecture by slightly reducing its performance.


We use Redis for:

  1. Retrieving cached data from our ASM.
  2. Managing our ASM sessions.


  1. You can access the Redis console after authenticating on AWS.
  2. Any changes to Redis infrastructure must be done via Merge Requests by modifying its Terraform module.
  3. To learn how to test and apply infrastructure via Terraform, visit the Terraform Guidelines.
  4. Please adhere to our current design when modifying the Redis logic, that way we can keep a consistent architecture.
  5. When working on our ASM, sometimes you will need to invalidate Redis cache, you can do this by using the invalidateCache mutation. Please visit our API Documentation section for more information.