Node-Based Clusters

While ElastiCache Serverless abstracts infrastructure decisions behind a managed proxy layer, many workloads demand explicit control over shard count, replica count, and node types to meet specific performance, cost, or compliance requirements. The node-based (provisioned) cluster model is the alternative where engineering teams make these decisions directly, shaping the cluster topology to match their workload characteristics.

At the center of every node-based Valkey or Redis OSS deployment in ElastiCache sits a replication group.The top-level logical resource that represents an entire Valkey or Redis OSS cluster in ElastiCache, containing all shards, primaries, and replicas as a single manageable unit. This lesson walks through the building blocks that compose a replication group, including shards (node groups), primary and replica nodes, endpoints, cluster mode disabled vs. enabled, parameter groups, and maintenance behavior. By the end, you will be able to describe how a node-based cluster is shaped, how clients connect to it, and how configuration and maintenance decisions affect operational predictability.

Replication groups, shards, and replicas

A replication group is the top-level resource you create when provisioning a Valkey or Redis OSS cluster in ElastiCache. Inside a replication group, data is organized into one or more shards.Also called node groups, shards are partitions within a replication group where each shard owns a distinct subset of the keyspace and operates independently for write and replication purposes. Each shard contains exactly one primary node that accepts all write operations and zero to five replica nodes that asynchronously replicate data from the primary and serve read traffic.

A common misconception is that adding replicas increases write throughput. Replicas improve read scaling and availability, but the number of shards determines write and data-partitioning capacity. Each shard owns a subset of the keyspace, and the primary in each shard is the sole writer for that partition. When a write command arrives, it is processed by the shard's primary and then propagated asynchronously to its ...