Choosing your node size
The node size you select for your cluster impacts costs, performance, and fault tolerance.
Choosing your Memcached node size
Memcached clusters contain one or more nodes with the cluster's data partitioned across the nodes. Because of this, the memory needs of the cluster and the memory of a node are related, but not the same. You can attain your needed cluster memory capacity by having a few large nodes or several smaller nodes. Further, as your needs change, you can add nodes to or remove nodes from the cluster and thus pay only for what you need.
The total memory capacity of your cluster is calculated by multiplying the number of nodes in the cluster by the RAM capacity of each node after deducting system overhead. The capacity of each node is based on the node type.
cluster_capacity = number_of_nodes * (node_capacity - system_overhead)The number of nodes in the cluster is a key factor in the availability of your cluster running Memcached. The failure of a single node can have an impact on the availability of your application and the load on your backend database. In such a case, ElastiCache provisions a replacement for a failed node and it gets repopulated. To reduce this availability impact, spread your memory and compute capacity over more nodes with smaller capacity, rather than using fewer high-capacity nodes.
In a scenario where you want to have 35 GB of cache memory, you can set up any of the following configurations:
-
11
cache.t2.mediumnodes with 3.22 GB of memory and 2 threads each = 35.42 GB and 22 threads. -
6
cache.m4.largenodes with 6.42 GB of memory and 2 threads each = 38.52 GB and 12 threads. -
3
cache.r4.largenodes with 12.3 GB of memory and 2 threads each = 36.90 GB and 6 threads. -
3
cache.m4.xlargenodes with 14.28 GB of memory and 4 threads each = 42.84 GB and 12 threads.
Comparing node options | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Node type | Memory (in GiB) | Cores | Hourly cost * | Nodes needed | Total memory (in GiB) | Total cores | Monthly cost † | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.t2.medium | 3.22 | 2 | $ 0.068 | 11 | 35.42 | 22 | $ 538.56 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.m4.large | 6.42 | 2 | $ 0.156 | 6 | 38.52 | 12 | $ 673.92 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.m4.xlarge | 14.28 | 4 | $ 0.311 | 3 | 42.84 | 12 | $ 671.76 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.m5.xlarge | 12.93 | 4 | $ 0.311 | 3 | 38.81 | 12 | $ 671.76 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.m6g.large | 6.85 | 2 | $ 0.147 | 6 | 41.1 | 12 | $ 635 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.r4.large | 12.3 | 2 | $ 0.228 | 3 | 36.9 | 6 | $ 492.48 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.r5.large | 13.07 | 2 | $ 0.216 | 3 | 39.22 | 6 | $ 466.56 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| cache.r6g.large | 13.07 | 2 | $ 0.205 | 3 | 42.12 | 6 | $ 442 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| * Hourly cost per node as of October 8, 2020. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| † Monthly cost at 100% usage for 30 days (720 hours). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
These options each provide similar memory capacity but different computational
capacity and cost. To compare the costs of your specific options, see Amazon ElastiCache Pricing
For clusters running Memcached, some of the available memory on each node is used for connection overhead. For more information, see Memcached connection overhead
Using multiple nodes requires spreading the keys across them. Each node has its own endpoint. For easy endpoint management, you can use the ElastiCache the Auto Discovery feature, which enables client programs to automatically identify all of the nodes in a cluster. For more information, see Automatically identify nodes in your cluster.
In some cases, you might be unsure how much capacity you need. If so, for testing we
recommend starting with one cache.m5.large node. Then monitor the memory
usage, CPU utilization, and cache hit rate with the ElastiCache metrics that are published to
Amazon CloudWatch. For more information on CloudWatch metrics for ElastiCache, see Monitoring use with CloudWatch metrics. For production and larger
workloads, the R5 nodes provide the best performance and RAM cost value.
If your cluster doesn't have the hit rate that you want, you can easily add more nodes to increase the total available memory in your cluster.
If your cluster is bound by CPU but has sufficient hit rate, set up a new cluster with a node type that provides more compute power.