What Is Amazon ElastiCache? Redis and Memcached on AWS Explained

Amazon ElastiCache is AWS's managed in-memory cache: you pick an engine, a sizing model and a network placement, and AWS runs the nodes, patching and failover. Backends use it for hot reads, sessions, rate limits and counters that should not hit Postgres on every request.

Creating a cluster in the console is quick, and the decisions that stick are the engine (Valkey, Redis OSS or Memcached), node-based versus serverless, Multi-AZ, and the fact that most setups are VPC-only, so local development needs its own Redis. This guide covers those choices and how Encore (infrastructure from code) provisions ElastiCache from a cache declared in code. For a wider comparison of managed Redis providers, see managed Redis in 2026.

Amazon ElastiCache at a glance

How ElastiCache works

You create either a node-based cluster or an ElastiCache Serverless cache. Node-based clusters let you choose node type, shard count, replica count and placement across Availability Zones. ElastiCache Serverless creates a highly available cache quickly, scales memory and compute for you, and exposes a single endpoint so you do not size nodes by hand.

Clients connect with ordinary Redis or Memcached libraries. For Redis-compatible engines that means commands such as GET, SET, INCR and data structures such as hashes and sorted sets. Cluster mode shards keys across nodes when a single primary is not enough. Encryption in transit (TLS), encryption at rest and Redis ACLs are available on supported engine versions.

Engines: Valkey, Redis OSS and Memcached

Valkey is the Linux Foundation fork of Redis 7.2.4, created after Redis changed its license. It stays BSD-licensed and protocol-compatible, and AWS puts it first in current ElastiCache docs.

Redis OSS is the Redis-compatible engine line ElastiCache continues to offer for teams that standardize on Redis client behaviour and versions AWS supports.

Memcached is a multithreaded key-value cache. It has no Redis data structures, no built-in replication in the Redis sense, and a simpler operational model. Pick it when the workload is plain cache get/set and you already use Memcached clients.

For most new backend caches on AWS, Valkey or Redis OSS is the default. Memcached fits teams that already depend on it.

Node-based vs Serverless

Node-based Multi-AZ deployments keep a primary and replicas in different Availability Zones and fail over automatically when the primary fails. You still choose capacity so the working set fits in memory. Serverless removes that capacity planning and still targets high availability; check current engine version support when you need a specific Redis feature.

Networking and Multi-AZ

Node-based clusters and VPC serverless caches sit in subnet groups inside your VPC. Security groups control which compute security groups may open port 6379 (or the Memcached port). There is no public endpoint on classic node-based setups, which keeps latency low from ECS or EKS and means a laptop cannot reach production without a tunnel or a separate local Redis.

Multi-AZ replication is the usual production setting for Redis-compatible caches that must survive an AZ loss. Snapshots cover warmer recovery; they do not replace designing for cache misses after a flush or failover.

Amazon MemoryDB is a related AWS service with a Multi-AZ transaction log for durable Redis-compatible primary data. Prefer ElastiCache when the workload is a cache in front of a database; prefer MemoryDB when Redis structures are the system of record.

What a hand-built setup involves

A typical ElastiCache setup for a backend has a subnet group across private subnets, a security group peering the service SG, a parameter group for maxmemory-policy, TLS and AUTH, IAM or secrets for the password, Terraform or CloudFormation for each environment, and a local Redis container because the cluster is not reachable from a developer laptop. Every new service that needs its own cache repeats that wiring.

How Encore provisions ElastiCache

Encore combines an open source infrastructure SDK for TypeScript and Go with a platform that provisions and deploys into your own AWS or GCP account. A cache declared in code becomes ElastiCache on AWS, starting on cache.m6g.large with Multi-AZ replication and Redis ACLs, or Memorystore for Redis in a high-availability setup on GCP, as documented in the AWS infrastructure docs and GCP infrastructure docs.

Set up the app

A per-user rate limiter with typed keys and a 10-second window:

// limits/encore.service.ts
import { Service } from "encore.dev/service";
export default new Service("limits");

The keyspace types both the key fields and the integer value, so two call sites cannot disagree on the shape under requests/:userId:

// limits/limits.ts
import { api, APIError } from "encore.dev/api";
import { CacheCluster, IntKeyspace, expireIn } from "encore.dev/storage/cache";

// ElastiCache on AWS, Memorystore on GCP, an in-memory implementation locally.
const cluster = new CacheCluster("rate-limit", { evictionPolicy: "allkeys-lru" });

const requestsPerUser = new IntKeyspace<{ userId: string }>(cluster, {
  keyPattern: "requests/:userId",
  defaultExpiry: expireIn(10 * 1000),
});

export const ping = api(
  { expose: true, method: "GET", path: "/ping/:userId" },
  async ({ userId }: { userId: string }): Promise<{ count: number }> => {
    const count = await requestsPerUser.increment({ userId }, 1);
    if (count > 10) {
      throw APIError.resourceExhausted("rate limit exceeded");
    }
    return { count };
  },
);

encore run uses a local, in-memory Redis implementation, so you can exercise the limiter on a laptop. It keeps only a small number of keys and purges them at random past that limit, so treat local counts as approximate. Keyspaces are covered in the TypeScript caching docs and the Go caching docs. Encore manages cache credentials, so no Redis URL or password is committed or shared. Connecting AWS is covered in deploying to your own cloud.

An AI coding agent adding a cache writes a keyspace declaration and tests it locally, and the ElastiCache cluster behind it arrives with the next deploy.

Best fit: TypeScript and Go teams on AWS who want a managed cache in their own VPC, declared in the code that reads and writes it.

Good to know

• Set maxmemory-policy to match the use: allkeys-lru suits disposable cache entries; counters you cannot lose should not be evicted.
• Plan for cache misses after failover or a flush; the database or upstream API remains the source of truth for cached data.
• Keep rate-limit and session keys on a trusted identity, not a client-supplied header that any caller can rotate.

Related guides

• Managed Redis in 2026
• Add caching to a TypeScript API
• Add Redis to a Go API
• Add a Redis cache on AWS with an AI agent
• What is Amazon RDS?