Deploying Redis on AWS

This content was generated with the assistance of AI and should be verified against the official Redis documentation before being relied on in production.

This section’s bibliography lists the reference material consulted while preparing these pages.

This page covers deploying and consuming Redis on AWS as of 2026-09-25, as distinct from the local docker run redis:8 development setup used elsewhere in this section — see Getting Started for that. Three AWS-adjacent options exist for production traffic: Redis Cloud on AWS (Redis’s own managed service, billed through AWS Marketplace), Amazon ElastiCache (AWS’s own managed cache, now built primarily around the Valkey fork), and Amazon MemoryDB (AWS’s durable in-memory database). Because engine versions, support dates, and feature availability all shift over time, the specific dates and version numbers below should be reverified against the dated AWS/Redis pages linked throughout before being relied on for a deployment decision. For the Azure equivalent see Deploying Redis on Azure, and for the broader Azure platform view see Redis and Partner Databases on Azure. For the broader AWS platform view of caching and the other in-memory and graph databases, see Caching, Graph and Partner Databases.

Redis Cloud on AWS

Redis Cloud is Redis’s own fully managed service, covered generically (subscriptions, tiers, networking, Terraform) in Redis Software, Redis Cloud, Kubernetes & Valkey; this section covers only what is specific to running it on AWS rather than repeating that material.

  • Marketplace listing — Redis Cloud can be provisioned and billed directly through AWS Marketplace, so its usage rolls into a customer’s existing AWS invoice and consolidated billing/cost-allocation tooling instead of a separate Redis invoice. See Redis Cloud on AWS.

  • Pro, in-your-own-region deployment — a Redis Cloud Pro subscription on AWS provisions dedicated infrastructure inside a chosen AWS region, rather than the shared infrastructure Essentials databases run on, so latency-sensitive workloads can co-locate the database with the application’s own AWS resources. See Redis Cloud subscriptions.

  • VPC peering and PrivateLink — a Redis Cloud Pro database reaches an application’s VPC either through VPC peering (a direct bilateral route between the two VPCs, simple to set up but requiring non-overlapping CIDR ranges) or AWS PrivateLink (a unidirectional endpoint into the Redis Cloud VPC that avoids exposing the whole subnet and works across accounts and overlapping CIDR ranges). PrivateLink is generally the better default where it’s supported, with VPC peering remaining the simpler choice for a single non-overlapping VPC. See Connect to AWS PrivateLink and Enable VPC peering.

  • Active-Active (CRDB) geo-distribution — a Redis Cloud Pro subscription can run an Active-Active database (a CRDT-backed database, or CRDB) across multiple AWS regions, each region accepting local writes at local latency with conflicting updates converging automatically, the same mechanism Redis Software, Redis Cloud, Kubernetes & Valkey describes for Redis Software. On AWS this gives a globally distributed application a local Redis endpoint per region without the application implementing its own cross-region write-conflict resolution. See Create an Active-Active database.

$ redisctl cloud subscription create --provider AWS --region us-east-1 \
    --deployment-type active-active --name orders-global

This derives from Redis Cloud on AWS.

Amazon ElastiCache

ElastiCache is AWS’s own managed cache/database service. Since Redis Ltd.'s March 2024 relicensing (covered in Redis Software, Redis Cloud, Kubernetes & Valkey), AWS has invested primarily in Valkey, the BSD-licensed community fork, rather than tracking Redis’s newer license tiers.

  • Valkey vs. legacy Redis OSS support — ElastiCache’s Redis OSS engine is frozen at 7.1: AWS has not shipped and does not plan to ship a newer Redis OSS engine version on ElastiCache, and Valkey (starting at 7.2) is the recommended engine for any new deployment. ElastiCache Redis OSS versions 4 and 5 moved out of standard support on January 31, 2026; from February 1, 2026 onward, caches still on those versions are automatically enrolled in a paid Extended Support tier that continues critical security updates and bug fixes until the tier ends on January 31, 2029. Applications not yet ready to move engines should budget for that Extended Support cost or an upgrade path onto Valkey; new workloads should default to Valkey rather than Redis OSS from the start. See ElastiCache engine versions and ElastiCache Extended Support.

  • Serverless vs. node-based clusters — ElastiCache Serverless provisions no nodes to size: it scales compute and storage automatically with load, runs Valkey, Redis OSS, or Memcached in cluster mode, requires TLS-capable clients, and is always deployed Multi-AZ. A node-based cluster instead has an explicit node type and shard/replica topology chosen up front, giving predictable, reservable capacity at the cost of manual sizing and scaling decisions. See Choosing between deployment options.

  • Cluster mode enabled vs. disabled — on a node-based cluster, cluster mode enabled shards data across multiple node groups (the same partitioning model Replication, Sentinel & Cluster covers for self-managed Redis Cluster), while cluster mode disabled keeps a single shard with up to five read replicas. ElastiCache Serverless is always effectively cluster-mode, with the sharding hidden from the operator. See How ElastiCache works.

  • Multi-AZ — a node-based cluster can enable Multi-AZ with automatic failover, promoting a replica in a different availability zone when the primary node fails, without the application managing failover itself; ElastiCache Serverless is Multi-AZ unconditionally. See How ElastiCache works.

  • Global Datastore — cross-region replication for node-based Valkey or Redis OSS clusters, creating read-only replica clusters in other AWS regions for low-latency cross-region reads and disaster recovery. Global Datastore is available for node-based clusters only — it does not extend to ElastiCache Serverless as of this writing, which should be reverified before relying on it. See Replication across AWS Regions using global datastores.

  • IAM authentication — an ElastiCache user can be configured to authenticate with an IAM-signed token instead of a static password, so access to the cache is governed by the same IAM policies (and short-lived credentials) as the rest of an AWS account rather than a long-lived secret an application must rotate itself. See IAM authentication.

  • Valkey modules in place of Redis Stack — this section’s other pages document Redis Open Source 8.10’s built-in Query Engine, JSON, and vector search (see Query Engine: Search & Aggregations, JSON, and Vector Search: Query Engine & Vector Sets), which Redis 8 folded into its tri-licensed core rather than shipping as separate Redis Stack modules. ElastiCache for Valkey instead ships these as official, separately versioned Valkey modules — valkey-json (RedisJSON-API-compatible JSON support) and valkey-search (vector and full-text search) — rather than a single bundled engine release, so module availability and command coverage should be checked per Valkey engine version rather than assumed to match Redis 8’s built-in behavior exactly. See Getting started with JSON for Valkey and Redis OSS and Get started with Amazon ElastiCache for Valkey.

$ aws elasticache create-serverless-cache \
    --serverless-cache-name orders-cache \
    --engine valkey \
    --major-engine-version 8

This derives from Choosing between deployment options.

Amazon MemoryDB

MemoryDB is AWS’s durable, Multi-AZ in-memory database rather than a cache: every write is persisted to a distributed, Multi-AZ transactional log before being acknowledged, so a node failure recovers from that log with no data loss, and MemoryDB can serve as an application’s primary database rather than sitting in front of one. It’s Valkey- and Redis OSS-compatible at the protocol level, the same way ElastiCache is. ElastiCache is by default a cache that may be rebuilt from a system of record on a miss. Since June 2026, ElastiCache for Valkey 9.0 can optionally keep a Multi-AZ transactional log as well (see Durability in ElastiCache), which narrows the gap. MemoryDB is durable by design, on every write, for workloads that need Redis’s data structures and latency profile with durability guaranteed by AWS rather than by the application’s own persistence strategy. See Amazon MemoryDB FAQs, and Caching, Graph and Partner Databases for how to choose between ElastiCache with durability and MemoryDB.

Choosing between them

Redis Cloud on AWS Amazon ElastiCache Amazon MemoryDB

Durability

Configurable persistence (RDB/AOF), operated by Redis

Cache-oriented by default; node-based clusters support RDB/AOF, Serverless does not expose it as a tunable. Valkey 9.0 adds optional durability (Multi-AZ transactional log, synchronous or asynchronous writes)

Durable by design — every write goes to a Multi-AZ transactional log before acknowledgment

Modules / Query Engine

Full Redis 8 feature set (Query Engine, JSON, vector search, Active-Active) as Redis ships it

Valkey engine: valkey-json/valkey-search modules, versioned separately from core; Redis OSS engine frozen at 7.1, no Redis 8 features

Valkey- or Redis-OSS-compatible core data structures; module/search feature parity trails ElastiCache and Redis Cloud

Operational model

Fully managed by Redis; customer chooses region/networking, Redis operates the cluster

Fully managed by AWS; customer chooses serverless or node-based, engine, and topology

Fully managed by AWS; customer chooses node type and shards, AWS manages the transactional log

Typical use case

Workloads wanting Redis 8’s full feature set and Active-Active multi-region writes, billed through AWS

General-purpose caching, session storage, leaderboards — AWS-native operations and billing preferred over Redis 8-specific features

A primary data store needing Redis-style structures and latency with strong durability, replacing a separate cache-plus-database pair

Spring Boot configuration

The same RedisConnectionFactory/Lettuce wiring used elsewhere in this section (see Clients & Client-Side Caching) applies to all three AWS options; what differs is the endpoint, TLS requirement, and authentication:

  • TLS endpoint — ElastiCache Serverless and MemoryDB require TLS; node-based ElastiCache clusters and Redis Cloud databases support it as a configurable option that should be enabled for any production deployment.

  • Cluster configuration endpoint — a cluster-mode-enabled ElastiCache cluster, ElastiCache Serverless cache, or MemoryDB cluster exposes one configuration endpoint that resolves to the current topology, rather than a fixed node address, so the client discovers shards/replicas through that single endpoint instead of a hand-maintained node list.

  • IAM auth token as the client password — when IAM authentication is enabled, the short-lived signed token generated for the cache’s resource ARN is passed as the Lettuce/Jedis password field on each connection, in place of a static AUTH password; the application is responsible for regenerating that token before it expires and re-authenticating with it.

  • ReadFrom.REPLICA_PREFERRED — routes read commands to a replica when one is available and healthy, falling back to the primary otherwise, spreading read load across the replicas a Multi-AZ or cluster-mode topology already provisions.

package com.example.bookshop.config;

import io.lettuce.core.ReadFrom;
import io.lettuce.core.RedisURI;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisStaticMasterReplicaConfiguration;
import org.springframework.data.redis.connection.lettuce.LettuceClientConfiguration;
import org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory;

@Configuration
public class ElastiCacheConfig {

    @Bean
    public LettuceConnectionFactory redisConnectionFactory(
            @org.springframework.beans.factory.annotation.Value("${elasticache.configuration-endpoint}")
            String configurationEndpoint,
            @org.springframework.beans.factory.annotation.Value("${elasticache.iam-auth-token}")
            String iamAuthToken) {
        RedisStaticMasterReplicaConfiguration configuration =
                new RedisStaticMasterReplicaConfiguration(configurationEndpoint, 6379);
        configuration.setPassword(iamAuthToken);
        LettuceClientConfiguration clientConfiguration = LettuceClientConfiguration.builder()
                .useSsl()
                .readFrom(ReadFrom.REPLICA_PREFERRED)
                .build();
        return new LettuceConnectionFactory(configuration, clientConfiguration);
    }
}

elasticache.iam-auth-token is generated ahead of time (and refreshed periodically) from the cache’s ARN using the AWS SDK’s IAM auth token generator; that generation step is outside Spring’s own configuration surface. This derives from ElastiCache IAM authentication.

Provisioning a Redis Cloud subscription on AWS with the official rediscloud Terraform provider:

resource "rediscloud_subscription" "orders" {
  name           = "orders-cache"
  payment_method = "marketplace"

  cloud_provider {
    provider = "AWS"
    region {
      region                       = "us-east-1"
      networking_deployment_cidr   = "10.0.0.0/24"
    }
  }

  creation_plan {
    memory_limit_in_gb           = 4
    throughput_measurement_by    = "operations-per-second"
    throughput_measurement_value = 25000
    modules                      = ["RedisJSON", "RediSearch"]
  }
}

resource "rediscloud_subscription_database" "orders_db" {
  subscription_id = rediscloud_subscription.orders.id
  name             = "orders"
  memory_limit_in_gb = 4
  data_persistence   = "aof-every-1-second"
}

This derives from Redis Cloud Terraform provider.

Provisioning an ElastiCache Serverless cache for Valkey with the aws_elasticache_serverless_cache resource:

resource "aws_elasticache_serverless_cache" "orders" {
  engine = "valkey"
  name   = "orders-cache"

  cache_usage_limits {
    data_storage {
      maximum = 10
      unit    = "GB"
    }
    ecpu_per_second {
      maximum = 5000
    }
  }

  daily_snapshot_time     = "03:00"
  snapshot_retention_limit = 7
  security_group_ids       = [aws_security_group.orders_cache.id]
  subnet_ids                = aws_subnet.private[*].id
}

This derives from Choosing between deployment options.

Which AWS option

flowchart TD A[Need durability as a primary\ndata store, not just a cache?] -->|Yes| B[Amazon MemoryDB] A -->|No| C{Need Redis 8's Query\nEngine, JSON, vector search,\nor Active-Active?} C -->|Yes, full feature set\nand multi-region writes| D[Redis Cloud on AWS] C -->|Yes, search/JSON is\nenough, AWS-native ops| E[ElastiCache for Valkey\nwith valkey-search/valkey-json] C -->|No, plain cache| F{Operational preference?} F -->|Autoscaling,\nno capacity planning| G[ElastiCache Serverless] F -->|Fixed, reservable\ncapacity and topology| H[ElastiCache node-based\ncluster mode enabled/disabled]

Related pages

References