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 はインメモリ層として使います。キャッシュ、セッション状態、レート制限、リーダーボード、pub/sub など、マイクロ秒の読み取りが耐久性の保証より重要な用途です。DynamoDB を高速化するためにキャッシュを追加するのであれば、本当の判断は ElastiCache か DynamoDB 独自のキャッシュである DAX か、という比較になります。その比較は下にあります。

DynamoDB vs ElastiCache の概要

特性	DynamoDB	ElastiCache
役割	耐久性のある記録システム	マネージドなインメモリデータストアまたはキャッシュ
エンジン	1つのマネージドエンジン（DynamoDB 自体）	Valkey、Memcached、Redis OSS
データモデル	NoSQL のキーバリューおよびドキュメント。最大 400 KB の型付きアイテム	エンジン依存 — Valkey/Redis OSS では文字列、ハッシュ、リスト、セット、ソート済みセット、ストリーム。Memcached ではプレーンなキーバリュー
耐久性	すべての書き込みをディスクに永続化し、複数のアベイラビリティーゾーンにレプリケート	デフォルトはインメモリ。ノードベースの Valkey クラスターでは分散型 Multi-AZ トランザクションログで耐久性を有効化可能
整合性	デフォルトは結果整合性。リクエストごとに強い整合性のある読み取りが可能	プライマリノード上では自ノードのキーに対して強い整合性。レプリカ読み取りは遅延しうる
アクセス	ネイティブ API（`GetItem`、`Query`、`Scan`、…）に加え PartiQL	キャッシュ endpoint 越しのエンジンコマンド。キーをまたぐクエリ言語はなし
キャパシティモデル	ディスク上のストレージ。データ量に応じてスケール	プロビジョンしたメモリに制約 — サーバーレスなら AWS がスケールし、ノードベースのクラスターは自分でサイズを決める
運用モデル	サーバーレス。プロビジョンもパッチも不要	サーバーレスキャッシュまたはノードベースのクラスター。AWS がプロビジョン、モニタリング、ノード交換、パッチを管理
典型的な用途	存続しなければならないレコード	cache-aside 層、セッションストア、レート制限、キューと pub/sub

DynamoDB が適している場合

データが存続しなければならない。 DynamoDB はすべての書き込みをデフォルトで永続化しレプリケートします。ElastiCache キャッシュはインメモリが第一であり、耐久性はノードベースの Valkey クラスターで有効化するもので、デフォルトの姿勢ではありません。
ワーキングセットがメモリを超える。 DynamoDB のコストはストレージに連動します。ElastiCache のキャパシティは、プロビジョンした RAM、またはサーバーレスキャッシュがスケールするメモリに制約されます。
強い整合性のある読み取りが必要。 DynamoDB はリクエストごとに提供します。データベースの前段のキャッシュは、構造上、それに対して結果整合性になります。
AWS のコントロールプレーンが欲しい。 ポイントインタイムリカバリ、バックアップ、Streams、IAM、Lambda トリガーは DynamoDB テーブルの設定です。

ElastiCache が適している場合

マイクロ秒の読み取りが必要。 RAM 上のデータは、背後のデータベースが何であれ、耐久性ストレージより速く応答します。
豊富なインメモリデータ構造が必要。 ソート済みセット、カウンター、ストリーム、pub/sub は Valkey と Redis OSS では第一級であり、耐久性ストアでモデリングするのは手間です。
データが本当に一時的である。 セッション、レート制限ウィンドウ、再計算可能な結果はキャッシュのライフサイクルに合います。
DynamoDB 以外もキャッシュする。 ElastiCache は RDS、Aurora、API、検索インデックスなど何の前段にも置けます。DAX が加速するのは DynamoDB だけです。

併用する

本番で一般的な形は両方です。DynamoDB が耐久性のあるレコードを保持し、インメモリ層がホットな読み取りを吸収します。ElastiCache は、自分でコードを書く汎用の cache-aside 層としてこれを行います — アプリケーションがキャッシュを確認し、ミス時に DynamoDB にフォールバックし、キャッシュを埋めます。DynamoDB には cache-aside コードなしで同じことをする独自の代替である DAX もあります。

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 では、無効化を含む cache-aside ロジックを自分で書き所有します。

DAX が向かない4つの文書化された理由。 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 は事実上使えず、Valkey、Redis OSS、Memcached の任意のクライアントから到達できる ElastiCache が実用的な選択です。この1行がレイテンシベンチマークよりも先に問いを決めることが多く、見落としやすいです。

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 であるアイテムは問題ありません。タイムスタンプ、セッション ID、テナント ID をトップレベルの属性名として使うアイテム — クエリ可能にするためにマップをアイテム上にフラット化したときに現れる形 — は、DAX のメタデータを永遠に増やします。アイテムがキャッシュから追い出されても、キャッシュはその領域を回収しません。

緩和策は設定ではなくモデリングです。識別子は属性の値に置き、可変キーはマップ内に1段ネストします。制限は明示的にそこには適用されません。ElastiCache に同等の制約はありません。アイテムスキーマを追跡しないからです。

耐久性はもはや明確な境界線ではない。 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 はその下の DynamoDB テーブルを閲覧、編集、クエリするためのネイティブなデスクトップクライアントです。macOS、Windows、Linux で動作します。標準の AWS 認証情報チェーンを読み取るため、移行するものは何もありません。グリッドは USER#123 のような複合キーをデコードし、TTL 属性をマークするため、キャッシュがテーブルに対して保持することを求められるアイテム形状 — およびトップレベルの属性名 — を把握しやすくなります。

キャッシュ投入コードに必要なキー条件とフィルターを組み立てるには、無料の DynamoDB Expression Builder が、インストール不要で貼り付け可能な SDK、CLI、PartiQL の出力を生成します。DynoTable はクローズドソースの商用アプリです。このページはその機能を説明するものであり、どのように構築されているかを説明するものではありません。

よくある質問

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 トランザクションログに永続化するため、すべてのキャッシュノードが失敗してもデータが存続します。キャッシュが揮発性かどうかは、選んだエンジンとクラスタータイプ次第です。

参考資料

Last verified 2026-08-02 against the official AWS ElastiCache User Guide and DynamoDB Developer Guide. Valkey, Redis OSS and Memcached are trademarks of their respective owners; referenced here for identification only.