「キャッシュ用のRedisをAWSに移行したいが、ElastiCacheとMemoryDBのどちらにすればよいか分からない」——こう相談されることが増えている。2021年にAmazon MemoryDB for Redisが登場して以来、AWS上のRedisサービスは事実上2択になったが、両者の違いを正確に把握しているエンジニアはまだ少ない。
ElastiCacheはキャッシュ専用に最適化されたサービスで、データの永続化は二次的な機能だ。一方のMemoryDBは、Redisをプライマリデータベースとして使えるよう、耐久性の設計から根本的に作り直されている。目的が違うのだから、料金が高くても正解になる用途がある。
この記事では、Amazon MemoryDB for Redisの仕組みとElastiCacheとの違いを整理し、料金体系・パフォーマンス特性・ユースケース別の選定基準を解説する。「なんとなくElastiCacheで済ませていた」という判断を見直すきっかけになれば幸いだ。
インメモリDBとキャッシュ層の設計が変わってきた背景
オンプレ環境では、Redisはほぼ「揮発性のキャッシュ」として使うのが常識だった。RDBのクエリ結果やセッション情報をメモリに乗せてレスポンスを高速化する。データが消えても、下位のRDBから再構築できれば問題ない——そういう位置づけだ。
ところが、マイクロサービス化が進む中でRedisへの期待が変わってきた。セッション管理・リーダーボード・リアルタイム在庫・フィーチャーフラグの状態保持など、「消えてはまずいデータ」をRedisで扱うケースが増えている。AWSが2021年11月にMemoryDBをGAリリースしたのも、この需要に応えるためだ。
キャッシュの前提で設計されたElastiCacheを無理にプライマリDBとして使うと、フェイルオーバー時のデータロスで障害が起きやすい。MemoryDBは最初からそのギャップを埋めるために設計されたサービスだ。
Amazon MemoryDB for Redisとは
Amazon MemoryDB for Redisは、Redis互換のインメモリデータベースサービスだ。最大の特徴は、すべての書き込みをマルチAZトランザクションログに永続化した後でクライアントに「書き込み完了」を返す点にある。
この設計により、ノード障害やAZ障害が発生してもデータを失わない（ゼロデータロス）。ElastiCacheがRDBのキャッシュ層として「あったら速い」という役割だとすると、MemoryDBは「なければシステムが止まる」プライマリDBの役割を担える。
主な特徴
・Redis互換API: Redis 6.2以降の主要コマンドをそのまま使える。既存のRedisクライアントライブラリ（ioredis、Jedis等）は変更不要
・マルチAZトランザクションログ: 書き込みを複数AZにまたがるログに同期記録してから応答する。これがゼロデータロスの核心
・ゼロデータロスフェイルオーバー: プライマリノード障害時にレプリカが昇格してもデータの欠損がない
・読み取りスケールアウト: 読み取り専用レプリカを追加することで、読み取りスループットを水平拡張できる
・マネージドスナップショット＋PITR: 日次自動スナップショットとポイントインタイムリカバリ（最大35日）を標準サポート
・ACLによるアクセス制御: コマンド・キープレフィックス単位でユーザーの操作権限を絞れる
ElastiCache for Redisとの違い
同じ「AWS上のRedis」でも、設計思想が根本的に異なる。以下の比較表で整理しよう。
| 項目 | Amazon MemoryDB for Redis | ElastiCache for Redis |
|---|---|---|
| 主な用途 | プライマリデータベース（消えてはまずいデータ） | キャッシュ層（消えても再構築できるデータ） |
| データ耐久性 | ゼロデータロス（マルチAZトランザクションログに同期書き込み） | AOF/RDB設定でオプション保存（非同期。フェイルオーバー時にわずかなデータロスあり） |
| 書き込みレイテンシ | 数ミリ秒（トランザクションログへの同期書き込みが必要なため） | マイクロ秒オーダー（メモリ書き込みのみ） |
| フェイルオーバー時間 | 数十秒以内（データロスなし） | 1分前後（AOF有効時でもわずかなロス可能性あり） |
| Redis互換バージョン | Redis 6.2以降（2026年9月時点） | Redis 5.x～7.x（バージョン選択幅が広い） |
| 料金モデル | ノード料金 + I/Oリクエスト料金 + スナップショット保存料金 | ノード料金のみ（I/O課金なし） |
| ポイントインタイムリカバリ | 標準サポート（最大35日） | 手動スナップショットのみ（PITR非対応） |
| 主なユースケース | セッション管理・在庫管理・リーダーボード・フィーチャーフラグ | DBクエリキャッシュ・静的コンテンツキャッシュ・一時データ |
ポイントは「書き込みレイテンシ vs 耐久性」のトレードオフだ。ElastiCacheはメモリへの書き込みのみで即座に返答するため、マイクロ秒レベルのレイテンシを実現できる。MemoryDBは複数AZへのトランザクションログ書き込みが完了してから返答するため、書き込みはミリ秒オーダーになる。
「数ミリ秒で許容できるか、マイクロ秒が必要か」——この問いが最初の選定基準になる。
ElastiCacheの基本設計についてはAmazon ElastiCache入門記事で詳しく解説している。MemoryDBとの差分を確認する前に、ElastiCacheのアーキテクチャを先に押さえておくと理解が深まる。
Amazon MemoryDB for Redisの料金体系
MemoryDBの料金は3つの要素で構成される（東京リージョン・ap-northeast-1、2026年9月時点の概算。正確な金額はAWS公式料金ページで確認すること）。
1. ノード料金（vCPU＋メモリ）
| ノードタイプ | vCPU | メモリ | On-Demand（時間料金） |
|---|---|---|---|
| db.t4g.small | 2 | 約1.4 GB | 約$0.032/時間 |
| db.r6g.large | 2 | 約13 GB | 約$0.248/時間 |
| db.r6g.xlarge | 4 | 約26 GB | 約$0.496/時間 |
| db.r6g.2xlarge | 8 | 約53 GB | 約$0.992/時間 |
2. I/Oリクエスト料金
MemoryDB特有の課金項目がI/Oリクエスト料金だ。SET・HSET・LPUSH等の書き込みコマンド1回ごとにカウントされる（GET等の読み取り専用コマンドは対象外）。東京リージョンでは100万リクエストあたり約$0.20が目安だ。
書き込みが頻繁なワークロードでは、このI/O課金がコストに大きく影響する。月間10億回の書き込みがあれば、I/O料金だけで約$200加算される計算になる。
3. スナップショットストレージ料金
自動スナップショットのS3保存料金として、GB/月あたり約$0.023が課金される。無料枠として「プライマリノードのメモリ容量分」が含まれるため、小規模な構成では実質無料になるケースも多い。
ElastiCache for Redisとのコスト比較（目安）
同等スペック（r6g.large、シングルノード）で月額コストを比べると、概算で以下のようになる。
| サービス | ノード料金/月 | I/O料金（月10億書き込みの場合） | 合計目安 |
|---|---|---|---|
| MemoryDB for Redis（db.r6g.large） | 約$179 | 約$200 | 約$379～ |
| ElastiCache for Redis（cache.r6g.large） | 約$120 | なし | 約$120 |
書き込みが多いほどMemoryDBのコスト負担は増える。一方で、データロスによる障害対応コストやビジネス影響（売上損失・ユーザー補償・開発工数）と比較したとき、MemoryDBへの追加投資が合理的なケースは多い。「保険として払うコスト」と捉えると判断しやすい。
どちらを選ぶべきか——ユースケース別の判断基準
ElastiCache for Redisを選ぶケース
・RDBやDynamoDBの前段キャッシュ: データが消えても下位DBから再取得できるなら耐久性は不要。コストを抑えてパフォーマンスを優先できる
・マイクロ秒レベルの書き込みが必要: ゲームのリアルタイム処理など、書き込みもマイクロ秒を要求される場合
・軽微なロスが許容できるセッションデータ: ユーザーがログインし直せる許容度があれば問題ない
・コスト優先の検証・開発環境: 本番相当の耐久性が不要なフェーズ
・古いRedisバージョンが必要なケース: ElastiCacheはバージョン選択幅が広く、5.x系など古いバージョンに対応できる
MemoryDB for Redisを選ぶケース
・リアルタイム在庫管理: 在庫数のデクリメントが消えると二重販売につながる場合。データロスが即ビジネス損失になる
・ゲームのリーダーボード・ポイント管理: スコアやポイントの欠損はユーザー信頼に直結する
・セッション＆認証状態の完全な保持: セキュリティトークンが突然消えることで多数ユーザーが強制ログアウトするような設計
・フィーチャーフラグの状態管理: A/Bテストやカナリアリリースのフラグがリセットされると、意図しない機能公開が起きる
・RedisをプライマリDBとして完結させたい: マイクロサービスで「Redisのみ」のシンプルなスタックにしたい場合
判断の分岐点を一言でまとめると「データが消えたとき、ビジネスへの影響が許容できるか」だ。許容できるならElastiCache、できないならMemoryDB——この軸で考えると迷いにくい。
運用設計のポイント
1. マルチAZ構成とフェイルオーバー設計
MemoryDBはクラスター単位でシャーディングとレプリカを設定する。本番環境では最低1つ以上のレプリカノードをプライマリとは別AZに配置するのが基本だ。
フェイルオーバー時、MemoryDBはトランザクションログから最後の書き込みを再適用してからレプリカを昇格させる。プライマリが突然クラッシュした直後のデータも失われない。ElastiCacheのAOFオプションとの最大の違いはここで、AOFは非同期書き込みのため「直前の数秒分」を失うリスクがある。
2. スナップショットとポイントインタイムリカバリ
MemoryDBは自動スナップショット（最大35日保持）とPITRを標準サポートする。誤操作やアプリケーションバグによる大量データ削除への備えとして有効だ。
注意点として、スナップショットからの復元は新しいクラスターとして起動される。本番クラスターに直接上書き復元はできないため、移行切り替えの手順を事前に確認しておくこと。
3. セキュリティ設定（VPC内配置とTLS）
MemoryDBは必ずVPCの内側に配置する。インターネット向けの公開エンドポイントは存在しない（ElastiCacheも同様）。アプリケーション側との通信はTLSを有効化することを強く推奨する。
アクセス制御はACL（アクセスコントロールリスト）で管理できる。「読み取り専用ユーザー」と「書き込み可能ユーザー」を分離すれば、最小権限の原則をRedis層でも実現できる。ElastiCacheの認証はデフォルト設定が甘いケースが多いが、MemoryDBではACLが前提の設計になっているため、セキュリティ面でも扱いやすい。
4. 監視指標の設計
MemoryDBはAmazon CloudWatchにメトリクスを自動送信する。運用上、特に注目しておきたい指標は以下の通りだ。
・DatabaseMemoryUsagePercentage: メモリ使用率。80%を超えたらスケールアップを検討する
・CurrConnections: 接続数。アプリ側のコネクションプール設定と突合して上限に余裕があるか確認する
・ReplicationLag: プライマリとレプリカ間のレプリケーション遅延。急増時はレプリカのスケールアップを検討
・EngineCPUUtilization: Redisエンジン固有のCPU使用率。CPUUtilizationとは別メトリクスで、こちらを見る
・IsPrimary: フェイルオーバーが発生していないかを確認するための基本指標
ElastiCacheからMemoryDBへの移行を検討するとき
すでにElastiCacheでRedisを運用している場合、MemoryDBへの移行を検討すべき主なトリガーは以下のようなものだ。
・フェイルオーバー後のデータ不整合が複数回発生し、ビジネス上の問題になった
・データロス修正の開発工数やユーザー補償コストが無視できなくなった
・RedisをプライマリDBとして使うアーキテクチャへのリファクタリングを計画している
移行の手間という面では、既存のElastiCacheクライアントコードは接続先エンドポイントを変更するだけでMemoryDBに接続できる。Redis互換APIを維持しているため、コマンドレベルの書き直しは原則不要だ。
ただし、ElastiCache固有の機能（Global Datastoreによるクロスリージョンレプリケーション等）を使っている場合は、代替設計を事前に検討する必要がある。また、ElastiCacheで使っていたパラメータグループの設定がそのままMemoryDBに引き継げない項目もあるため、設定の棚卸しを必ず行うこと。
よくある疑問と注意点
Q. MemoryDBは「インメモリDB」なのに、なぜストレージ料金がかかるのか？
データ自体はメモリ上に置かれる。ただし、耐久性を保証するためにトランザクションログをAmazon S3互換の分散ストレージに書き込んでいる。このストレージの使用料がI/Oリクエスト料金およびスナップショット料金として発生する。メモリ＋ストレージの2層構成で耐久性とスピードを両立している、と理解するとよい。
Q. ElastiCache for Redis 7.xのAOF設定で十分ではないか？
AOFは非同期書き込みのため、プライマリノードがクラッシュした瞬間の「数秒分のデータ」を失うリスクがある。また、AOFのfsync設定（appendfsync always）をtrulyにすると書き込みレイテンシが大幅に悪化する。MemoryDBのマルチAZトランザクションログは、この問題を「レイテンシの悪化を最小限に抑えつつゼロロスを実現する」アーキテクチャで解決している。
Q. Redisのバージョンが上がったときの追従はどうなるか？
MemoryDBのバージョンアップはAWSが管理するマネージドアップデートで提供される。メジャーバージョンアップには互換性の確認が必要だが、マイナーバージョンのセキュリティパッチは自動適用設定にできる。ElastiCacheと同様の運用感で扱える。
本記事のまとめ
| 判断軸 | MemoryDB for Redis | ElastiCache for Redis |
|---|---|---|
| データロスの許容度 | ゼロロス必須 | 多少のロスは許容できる |
| 書き込みレイテンシの要件 | 数ミリ秒で許容 | マイクロ秒が必要 |
| Redisの役割 | プライマリDB | キャッシュ層 |
| コスト感 | ElastiCacheより高い（I/O課金あり） | 相対的に安価 |
| PITR・ACL | 標準サポート | 非対応（スナップショットのみ） |
| 移行コスト | エンドポイント変更のみで接続可能 | （起点） |
Amazon MemoryDB for Redisは、ElastiCacheの上位互換ではなく「用途が異なるサービス」だ。キャッシュはElastiCache、プライマリDBはMemoryDB——この使い分けを基本に、データが消えたときのビジネス影響を軸に選ぶとよい。
インメモリの速度とRDB級の耐久性を両立したいシステムであれば、MemoryDBは非常に強力な選択肢になる。まずは開発環境でdb.t4g.smallを立ち上げ、既存のRedisクライアントコードをエンドポイント変更だけで接続できるか試してみることをすすめる。
PR
キャッシュ・データストア・メッセージングなど、AWSサービスを組み合わせた設計パターンを体系的に解説。MemoryDBを含むインメモリ設計の判断根拠を深めたいエンジニアにすすめる一冊。
