ElastiCache 最大的成本驱动因素很容易被忽视：您永远无法将节点的全部内存用作可用的键空间。根据 AWS 的官方文档，默认情况下有 25% 的内存被预留用于备份和复制等操作，这部分内存是不可用的。因此，客户实际可用的容量要小于实例规格所标示的数值。
这一点至关重要，因为您支付的正是内存的费用。如果您根据规格而非可用键空间来规划容量，那么您将面临选择：要么淘汰更多数据，要么处理内存不足错误，要么通过增加分片、副本或迁移到更大节点来推高您的 ElastiCache 账单。我们设计的 Redis Enterprise 则确保您能获得所需的数据集大小，而无需管理节点级的开销。
本文将通过具体的节点示例来解释 Redis 与 ElastiCache 的成本差异，分析开销和扩展如何影响总拥有成本（TCO），并探讨 ElastiCache 转向 Valkey 对长期成本和创新的影响。
您在 ElastiCache 上究竟能获得多少键空间？
无论是 Valkey 还是 Redis OSS，AWS 都要求至少有 25% 的预留内存。在小型节点（30%）和微型节点（50%）上，该预留比例更高。对于自动分层节点，建议的预留比例也是 50%。结果就是：可用键空间最多只占所列节点内存的 75%，而在某些节点上仅为 50%。
以下示例来自 AWS 定价页面：
| 实例类型 | 内存 | 预留 | 可用键空间 |
|---|---|---|---|
| cache.t4g.micro* | 0.5 GiB | 50% | 0.25 GiB |
| cache.t4g.small | 1.37 GiB | 30% | 0.96 GiB |
| cache.t4g.medium | 3.09 GiB | 25% | 2.32 GiB |
| cache.m7g.xlarge | 12.93 GiB | 25% | 9.69 GiB |
| cache.r6gd.4xlarge | 504 GiB | 50% | 252 GiB |
- 可突发的 t-class 节点还设有基准 CPU 和网络限制，其突发性能是尽力而为的，并可能产生额外费用。
复制要求与高可用性（HA）
高可用性需要副本，但不同平台所需的副本数量不同。
- ElastiCache：ElastiCache 允许单个副本，但最佳实践要求“跨可用区设置两个或更多副本”。这使得为高可用性数据集预配的内存和节点成本增加了三倍。
- Redis Cloud：我们通过两个副本来满足我们的高可用性服务等级协议（SLA）（一个主副本，一个从副本）。这将容量需求降低至两倍，同时也减少了操作的复杂性。
结合 ElastiCache 所需的内存开销，您就能开始看到资源效率低下的程度。对于一个 100 GB 的高可用性数据集：
- ElastiCache 容量规划 = 100 GB × 4/3 开销 × 3 个副本 ≈需预配 400 GB
- Redis Cloud 容量规划 = 100 GB × 2 个副本 =需预配 200 GB
这种复制上的差异加剧了内存开销的差距，是导致 ElastiCache 总拥有成本（TCO）更高的主要驱动因素。
为什么这会推高实际成本
依据标称内存和最低高可用性要求来规划容量会导致资源预配不足。您后续需要添加分片、副本或更大的节点，这不仅增加了开销，也带来了额外的工作。我们在两个方面最能看到其影响：
- 纵向扩展：从小型节点迁移到大型节点需要一个维护窗口和/或停机时间。客户端变更和数据重新平衡增加了工作量和风险。
- 横向扩展：添加更多分片也会增加成本，并且在实例负载较高时可能导致维护窗口或停机。
环境级经济性 vs 标价
只有在考虑到开销和高可用性副本后，比较才是公平的。但更应着眼于整个部署，而非单个节点。在一个为吞吐量和高可用性而设计的 250 GB 数据集示例中，一旦计入 25% 的预留内存和额外的副本，基于 r7g.xlarge 或 m7g.8xlarge 的 ElastiCache 会显得昂贵得多，而我们 Redis 则直接交付目标大小的数据集。
多租户特性加剧了这种效应。Redis 可以在共享的集群基础设施上放置多个小型数据库。这提高了小型节点的效率，降低了整体总拥有成本，并为那些在 ElastiCache 中可能存在性能问题的小型数据集提供了一致的性能。
预留节点与灵活性
预留节点可以降低 ElastiCache 的小时费率，但折扣与特定的节点系列和区域绑定。AWS 在 2024 年 10 月增加了同一系列内的规格灵活性，这有所帮助，但您在合约期内仍受限于该系列和区域。我们在 Redis 采取了不同的方法。我们的折扣适用于一个积分池，不会强迫您选择特定的节点类型、区域或内存大小。
Redis vs. ElastiCache 成本：Redis 如何降低您的成本与风险
- 我们销售的是可用数据集，而非标称内存。您无需计算预留、副本或持久化开销。
- 多租户。将多个数据库整合到共享的底层基础设施中，以避免内存和 CPU 资源未被充分利用。
- 可替代额外系统的功能集。Redis 查询引擎和 Redis 数据集成是 Redis Cloud 独有的两项功能，可减少对其他服务的使用和数据迁移。
Valkey 因素
ElastiCache 现在运行在 Valkey 之上，并且 AWS 增加了一项 Valkey 专属折扣以鼓励采用。与 Redis Cloud 相比，这降低了小时定价上的表面差距，使得两种服务的成本看起来更接近。然而，这需要与上文讨论的内存开销和功能限制进行权衡。更大的担忧可能是，以更低价格提供 Valkey 并不能解决所有问题：
- Valkey 的发展路线与 Redis 不同，且缺乏我们的路线图和创新能力。
- ElastiCache for Valkey 缺少能够削减运营成本的功能，包括 Redis 数据集成、Redis 查询引擎和 Redis Flex。
- 当 Redis 独有的功能变得至关重要时，绑定在 Valkey 上的客户将面临未来迁移工作的风险。
因此，尽管折扣改变了标价，但一旦考虑到缺失的功能、扩展的复杂性和技术锁定，潜在的总拥有成本差距可能依然存在。
ElastiCache 的标称价格并未反映您的实际所得。25% 的预留内存、为高强度写入预留的 headroom、推荐的副本数量以及节点限制，都将一个简单的预估变成了一张更大的账单。我们则让您专注于可用数据集，高效地整合小型工作负载，并省去了重新分片和迁移的工作。
