DynamoDB vs ElastiCache
DynamoDB 與 Amazon ElastiCache 都把資料存放在 AWS 上，也都常被稱作很快，但它們回答的是不同的問題。DynamoDB 是全受管、無伺服器的記錄資料庫：寫入會持久化到磁碟，並橫跨可用區複寫。ElastiCache 用 AWS 自己的話說，是 "a web service that makes it easy to set up, manage, and scale a distributed in-memory data store or cache environment in the cloud." 對大多數系統而言，有用的比較不是 DynamoDB 或 ElastiCache — 而是哪一種快取（如果有的話）該放在 DynamoDB 前方。
你該用 DynamoDB 還是 ElastiCache？
把 DynamoDB 用於你負擔不起遺失的資料：以鍵在任何規模下讀寫的耐久項目。把 ElastiCache 用於記憶體內層 — 快取、session 狀態、速率限制、排行榜、pub/sub — 在微秒級讀取比耐久性保證更重要的地方。若你加入快取是為了加速 DynamoDB，真正的抉擇是 ElastiCache 對上 DAX（DynamoDB 自家的快取）；該比較見下文。
DynamoDB vs ElastiCache 一覽
| 特性 | DynamoDB | ElastiCache |
|---|---|---|
| 角色 | 耐久的記錄資料庫 | 受管的記憶體內資料儲存或快取 |
| 引擎 | 單一受管引擎（DynamoDB 本身） | Valkey、Memcached 與 Redis OSS |
| 資料模型 | NoSQL 鍵值與文件；型別化項目最大 400 KB | 依引擎而定 — Valkey/Redis OSS 上的 string、hash、list、set、sorted set 與 stream；Memcached 上為單純鍵值 |
| 耐久性 | 每次寫入都持久化至磁碟，並橫跨可用區複寫 | 預設為記憶體內；節點式 Valkey 叢集可透過分散式 Multi-AZ 交易式日誌啟用耐久性 |
| 一致性 | 預設最終一致；可依請求取得強一致讀取 | 主節點對其自有鍵為強一致；replica 讀取可能落後 |
| 存取 | 原生 API（GetItem、Query、Scan、…）加上 PartiQL | 透過快取 endpoint 的引擎指令；無跨鍵查詢語言 |
| 容量模型 | 磁碟上的儲存；隨資料量擴充 | 受佈建記憶體所限 — 無伺服器快取由 AWS 代為擴充，節點式叢集則自行調整大小 |
| 維運模式 | 無伺服器；無需佈建或修補 | 無伺服器快取或節點式叢集；AWS 管理佈建、監控、節點替換與修補 |
| 典型用途 | 必須存活的記錄 | cache-aside 層、session 儲存、速率限制、佇列與 pub/sub |
何時 DynamoDB 是較佳選擇
- 資料必須存活。 DynamoDB 預設會持久化並複寫每一次寫入。ElastiCache 快取是記憶體優先；耐久性要在節點式 Valkey 叢集上啟用，而非預設姿態。
- 你的工作集大於記憶體。 DynamoDB 成本隨儲存而變。ElastiCache 容量受你佈建的 RAM 或無伺服器快取擴充到的記憶體所限。
- 你需要強一致讀取。 DynamoDB 可依請求提供。放在資料庫前方的快取，本質上與資料庫是最終一致的。
- 你想要 AWS 控制平面。 point-in-time recovery、備份、Streams、IAM 與 Lambda 觸發，在 DynamoDB 資料表上都是組態問題。
何時 ElastiCache 是較佳選擇
- 你需要微秒級讀取。 RAM 中的資料，無論後方是什麼資料庫，都比耐久儲存回應更快。
- 你需要豐富的記憶體內資料結構。 sorted set、計數器、stream 與 pub/sub 在 Valkey 與 Redis OSS 上是一等公民，在耐久儲存中建模則是額外工作。
- 資料確實是暫時性的。 session、速率限制時窗與可重新計算的結果，都契合快取的生命週期。
- 你快取的不只是 DynamoDB。 ElastiCache 可放在任何東西前方 — RDS、Aurora、API、搜尋索引。DAX 只加速 DynamoDB。
搭配使用
常見的正式環境形狀是兩者並用：DynamoDB 保存耐久記錄，記憶體內層吸收熱門讀取。ElastiCache 以通用的 cache-aside 層做到這點，程式由你撰寫 — 應用程式先查快取，未命中再回退到 DynamoDB，並在未命中時填入快取。DynamoDB 也提供自家替代方案 DAX，無需 cache-aside 程式碼即可做到類似效果。
DynamoDB 前方該選 ElastiCache 還是 DAX
這是多數團隊真正在做決策的地方，而 AWS 文件比行銷頁面說得更清楚。
DAX 可直接套用；ElastiCache 要改程式。 DAX "API-compatible with DynamoDB. Therefore, it requires only minimal functional changes to use with an existing application." 它把最終一致讀取 "by an order of magnitude from single-digit milliseconds to microseconds" 地縮短延遲。使用 ElastiCache 時，快取旁路邏輯（含失效處理）由你撰寫並擁有。
四個文件記載的理由，說明 DAX 可能不適合。 AWS 列出 DAX 不 理想的案例，每一項都對應真實工作負載：
- 強一致讀取。 DAX 提供的是最終一致資料。若讀取路徑需要
ConsistentRead，DAX 就不是選項。 - 寫入密集的工作負載。 "High volume of writes lead to increased replication across DAX nodes in a cluster," 提高資源使用與可用性風險。
- 重複讀取率低。 "DAX performs best when cache hit rates exceed 90%." 低於此，未命中會消耗資源卻買不到多少延遲改善。
- 語言支援。 "DAX supports applications written in Go, Java, Node.js, Python, and .NET, using AWS-provided clients." 若你的服務是 Rust、Ruby、PHP 或 Elixir，DAX 實質上對你關閉，而 ElastiCache — 可透過任何 Valkey、Redis OSS 或 Memcached 用戶端連線 — 才是實務選擇。這一行比任何延遲基準測試更常決定問題，而且很容易被忽略。
DAX 也 "only available for the EC2-VPC platform."
建模前值得知道的 DAX 陷阱。 AWS 記載了一項限制，會與常見的 DynamoDB 建模習慣相撞：
DAX clusters maintain metadata about the attribute names of items they store. That metadata is maintained indefinitely (even after the item has expired or been evicted from the cache). Applications that use an unbounded number of attribute names can, over time, cause memory exhaustion in the DAX cluster. This limitation applies only to top-level attribute names, not nested attribute names.
請對照人們如何建構稀疏或異質項目來讀這段。值 是時間戳記與 UUID 的項目沒問題。把時間戳記、session ID 或租戶 ID 當成頂層屬性名稱 的項目 — 這種把 map 攤平到項目上以維持可查詢性的形狀 — 會讓 DAX 的中繼資料永久成長。項目從快取逐出後，快取也不會回收這塊空間。
緩解方式是建模，而非組態：把識別碼放在屬性 值 中，並把可變鍵再巢狀一層放在 map 內，而限制明確指出該處不適用。ElastiCache 沒有對等限制，因為它根本不追蹤你的項目 schema。
耐久性已不再是乾淨的分界線。 熟悉的那句「ElastiCache 無法耐久」已過時。AWS 記載 "for node-based Valkey clusters, you can enable durability to persist your data in a distributed Multi-AZ transactional log," 且 "with durability enabled, your data is protected even if all cache nodes fail." 這並未讓 ElastiCache 成為記錄系統 — 但代表「快取重啟就全沒了」在未先確認引擎與叢集類型前，不能當論點。
使用 DynamoDB
無論你在前方放哪種快取，DynoTable 都是原生桌面用戶端，可在 macOS、Windows 與 Linux 上瀏覽、編輯與查詢底下的 DynamoDB 資料表。它讀取你標準的 AWS 憑證鏈，因此無需遷移。它的格線會解碼像 USER#123 這類複合鍵，並標記 TTL 屬性，讓你容易看出哪些項目形狀 — 以及哪些頂層屬性名稱 — 會被前方的快取要求持有。
若要建立快取填充程式所需的鍵條件與 filter，免費的 DynamoDB Expression Builder 會產生可直接貼上的 SDK、CLI 與 PartiQL 輸出，無需安裝。DynoTable 是一款閉源的商業應用程式；本頁描述它做什麼，而非它如何建構。
FAQ
ElastiCache 能取代 DynamoDB 嗎？
作為記錄系統不行。ElastiCache 是記憶體內儲存；即使在節點式 Valkey 叢集上啟用耐久性，它仍是設計成快取層，而非資料真正存放的資料庫。DynamoDB 預設會把每一次寫入持久化並橫跨可用區複寫。
對 DynamoDB 而言，DAX 還是 ElastiCache 比較好？
若你的應用程式以 Go、Java、Node.js、Python 或 .NET 撰寫、讀取為最終一致，且快取命中率會超過 90% — DAX 與 API 相容，幾乎不用改程式。若你需要其他語言、需要快取 DynamoDB 以外的資料，或想要 DAX 未提供的記憶體內資料結構，則選 ElastiCache。
ElastiCache 在節點重啟時會遺失資料嗎？
預設為記憶體內，請當成揮發性。AWS 現已記載節點式 Valkey 叢集的可選耐久性，持久化到分散式 Multi-AZ 交易式日誌，即使所有快取節點失效資料仍可存活。你的快取是否揮發，取決於你選擇的引擎與叢集類型。
相關內容
- 學習何時使用 DynamoDB，以及 DynamoDB TTL 如何讓快取性質的項目過期。
- 從一般角度比較 DynamoDB 與 Redis 的儲存與快取問題。
- 以single-table design為耐久存取模式建模。
- 下載 DynoTable 以瀏覽、查詢與編輯你的 DynamoDB 資料表。
參考資料
- What is Amazon ElastiCache?
- In-memory acceleration with DynamoDB Accelerator (DAX)
- What is Amazon DynamoDB?
- DynamoDB read consistency
最後驗證於 2026-08-02，比對官方 AWS ElastiCache User Guide 與 DynamoDB Developer Guide。Valkey、Redis OSS 與 Memcached 是其各自擁有者的商標；此處引用僅供識別之用。