# Amazon ElastiCache Node

> ElastiCache bills by the node-hour, and a node is exactly what this page covers: one cache instance within a cluster, metered at its instance type's rate for every hour it exists. ZopNight discovers nodes alongside their parent cluster on the 6-hour cycle, attributes cost per node, and feeds node metrics into cluster rightsizing.

Source: https://zop.dev/integrations/aws/elasticache-node
Updated: 2026-08-19

---

An ElastiCache node is an individual cache instance within a cluster, and the unit ElastiCache actually bills by the hour. Node-level visibility shows exactly which shards and replicas drive a cluster's cost.

## The hour-by-hour unit of cache spend

Whatever the cluster topology (a single Memcached node, a Redis primary with replicas, a sharded cluster-mode deployment), the invoice is node-hours: each node bills its instance type's hourly rate for as long as it exists. Cluster design choices are therefore multiplication factors. Two replicas per shard triples the node count; six shards at three nodes each is eighteen meters running. Reserved-node pricing discounts committed usage, and data tiering on the r6gd family shifts the storage/memory economics, but nothing changes the basic arithmetic: topology times instance size times hours.

## Node-level attribution, cluster-level fixes

ZopNight discovers nodes automatically alongside their parent cluster on the 6-hour cycle, attributing cost per node and feeding node-level metrics into cluster rightsizing recommendations. The split exists because the two levels answer different questions: node data shows which shards and replicas the money actually goes to and whether load is balanced across them; the actionable change, whether fewer replicas, a smaller instance class, or fewer shards, is a cluster-level operation, and ZopNight applies its recommendations there rather than to individual nodes.

## Topology habits that multiply node-hours

Replica counts copied from production into every environment are the standard leak: a dev cache with two replicas per shard pays high-availability rates to protect data that regenerates on a miss. Memory headroom compounds it: clusters sized at a fraction of memory utilization, where one instance class down would halve the node rate. And hot-key skew wastes capacity horizontally: five shards idling while one works means the cluster is paying for parallelism the key distribution never uses.

## Reading node economics in the console

The ElastiCache console shows each cluster's node list with instance types and per-node CloudWatch links; memory usage, engine CPU, and cache-hit metrics per node reveal skew and headroom. Multiplying visible node count by instance rate makes any cluster's monthly floor a one-line calculation.