Amazon MemoryDBとは？ElastiCacheとの違い・東京リージョンの料金と2026年の選び方

Amazon MemoryDBは、インメモリの速度と複数アベイラビリティーゾーン（AZ）にまたがる永続性を1つのサービスで両立させた、AWSのフルマネージドデータベースです。ValkeyとRedis OSSに互換性があり、既存のクライアントやデータ構造をそのまま持ち込めます。ただし2026年にAmazon ElastiCacheが同じ方式の耐久性へ対応し、AWS公式の推奨は書き換わりました。この記事では東京リージョンの実単価とAWSの現行ドキュメントをもとに、MemoryDBの仕組み・料金・接続手順・制約と、新規に選ぶべき条件を整理します。

まとめ

MemoryDBは、書き込みをMulti-AZトランザクションログへ永続化してから応答する、耐久性つきのインメモリデータベースです。読み取りはマイクロ秒、書き込みは1桁ミリ秒です。エンジンはValkeyとRedis OSSから選べ、Valkeyにするとノード時間料金が一律30%下がり、データ書き込み料金も月10TBまで無料になります。東京リージョンのdb.r7g.largeは、Redis OSSで1時間0.371ドル、Valkeyで0.2597ドルです。

2026年6月、ElastiCache for Valkey 9.0が同じMulti-AZトランザクションログによる耐久性を獲得し、10月27日には既存クラスターでも耐久性を後から切り替えられるようになりました。AWSはElastiCache開発者ガイドで、単一リージョンの耐久ワークロードには耐久性を有効にしたElastiCacheを、複数リージョンのアクティブ・アクティブにはMemoryDBを、と案内しています。

判断はこうなります。複数リージョンで同時に書き込みたいならMemoryDBです。耐久性に加えてSSDへのデータ階層化が要る場合も、MemoryDBにしか組めません。SLA対象外のt4gで足りる月150ドル以下の小さな耐久構成なら、MemoryDBのほうが安く収まります。それ以外の単一リージョンの用途は、ElastiCacheの耐久性オプションを第一候補にします。

Amazon MemoryDBの仕組みと「for Redis」からの改称

Multi-AZトランザクションログと読み書きのレイテンシ

MemoryDBの中核はMulti-AZトランザクションログです。AWSの開発者ガイドは、全データをメモリに置くことで「microsecond read and single-digit millisecond write latency」を実現し、同時に複数AZのトランザクションログへ永続化すると説明しています。書き込みは複数AZへの記録を待ってから応答が返るため1桁ミリ秒になり、読み取りはメモリ上で完結するのでマイクロ秒です。

公式の説明でも、遅くなるのは永続化を待つ書き込みで、読み取りはメモリから返ります。アプリケーション全体の応答時間は負荷や通信条件にも左右されますが、差が効いてくるのは1リクエストで何度も書き込む処理や、書き込みの応答時間がそのまま利用者の待ち時間になる処理です。Multi-AZ構成の可用性SLAは、2023年1月31日の告知で99.99%に引き上げられています。

クラスター・シャード・ノードの構成と課金されるノード数

MemoryDBのデータはクラスター単位で管理され、クラスターは複数のシャードに分割されます。構成要素の説明によると、各シャードは読み書きを受けるプライマリノード1台と、読み取り専用のレプリカノード最大5台で構成され、プライマリ障害時はレプリカが昇格します。MemoryDBは常にクラスターモードで動くため、クライアントもクラスター対応の接続方式を使います。

料金はノード単位でかかるので、課金台数は「シャード数×（1＋シャードあたりのレプリカ数）」です。CLIの既定値はシャード1・レプリカ1なので、何も指定しなければ2台分の料金が発生します。2シャードでレプリカを2台ずつ置けば6台分です。データ量でシャード数が、可用性と読み取り負荷でレプリカ数が決まると考えると見積もりが早くなります。

改称とValkey・Redis OSSの両対応

2021年の提供開始時のサービス名は「Amazon MemoryDB for Redis」でした。2024年10月8日にValkeyエンジンのサポートが始まり、現在の公式名称は「Amazon MemoryDB」です。検索で「amazon memorydb for redis」と入力しても指すサービスは同じで、Redis OSSエンジンも引き続き選べます。ValkeyはRedis OSSのライセンス変更を受けてLinux Foundationのもとで開発されている後継実装で、エンジン間の違いはValkeyとは？Redisとの違い・Streamsの使い方と導入手順【Valkey 9.1】で詳しく扱っています。

ElastiCacheとの違いと2026年時点の選び分け

AWS公式ガイダンスの転換

従来の境界は、ElastiCacheが既存データベースの前段に置くキャッシュ、MemoryDBが耐久性を持つプライマリデータベース、という分担でした。MemoryDB開発者ガイドの関連サービスのページは今もこの説明のままです。

一方、ElastiCache開発者ガイドの同名ページは「You should consider using MemoryDB if your workload requires multi-Region active-active replication with conflict-free data types (CRDTs). For single-Region durable workloads, consider using ElastiCache with durability enabled.」と書き換わっています。両ページの記述は一致しておらず、新しいのはElastiCache側です。MemoryDB側だけを読んで「耐久性が必要だからMemoryDB」と決めると、2026年時点では割高な選択になりえます。

背景にあるのが、2026年6月2日に発表されたElastiCache for Valkeyの耐久性です。同期書き込みは少なくとも2つのAZへ記録してから応答し、データ損失ゼロを狙う代わりに書き込みが1桁ミリ秒になります。非同期書き込みはマイクロ秒を保つ代わりに、障害時に最大10秒分の書き込みを失う可能性があります。非同期では10秒を超えて永続化できない状態が続くと、プライマリが新しい書き込みを拒否します。

6月の時点では耐久性を有効にできるのはクラスター作成時だけでしたが、2026年10月27日の告知で、既存クラスターを作り直さずに同期・非同期・無効を切り替えられるようになりました。切り替えの条件はValkey 9.0以降、Multi-AZとシャードあたり1台以上のレプリカ、転送時のTLS、クラスターモード有効の4つで、ServerlessとGlobal Datastoreは対象外です。変更はほかの修正と同時に出せず、ノード置換に伴って短いフェイルオーバーが起きます。対応インスタンスはR8g・R7g・R6g・M8g・M7g・M6g・C8gn・C7gnで、T系は使えず、データ階層化とも併用できません。ElastiCache側の構成と料金体系はAmazon ElastiCacheとは？対応エンジン・Serverlessとノードベースの違いと料金・採用判断を実装者目線で解説にまとめています。

東京リージョンの実単価で見る耐久性の上乗せ分

2026年11月1日にAWSの料金のPrice List APIから取得した東京リージョンの単価を、同クラスのノードで並べます。いずれも1ノード1時間あたりのオンデマンド料金です。

同期耐久性のElastiCacheとMemoryDBの差は1時間0.0114ドル、率にして約4.6%です。非同期なら耐久性の追加料金はかかりません。r7g.large以上のサイズでは、かつてMemoryDBが背負っていた「耐久性のためのプレミアム」はほぼ消えています。

MemoryDBを選ぶ場面と選ばない場面

単価が並んだ今、決め手は機能の差です。MemoryDBを選ぶ理由が残るのは次の3つの場面です。

• 複数リージョンで同時に読み書きしたい（後述のマルチリージョンクラスターはMemoryDBだけの機能です）
• 耐久性とSSDへのデータ階層化を両立したい（ElastiCacheの耐久性はデータ階層化と併用できません）
• 小さな耐久構成を安く持ちたい（MemoryDBはdb.t4gでも耐久性込みで動きますが、ElastiCacheの耐久性はT系に対応しません）

3つ目は単価に表れます。東京でレプリカ1台の2ノード構成を730時間動かすと、MemoryDBのdb.t4g.small（Valkey）は約75.63ドル、db.t4g.mediumでも約150.23ドルです。ElastiCacheで耐久性を使える最小級のcache.m6g.largeは、同期耐久で約263.24ドル、非同期でも約223.09ドルかかります。データが選択したノードの使用可能メモリに収まり、CPU負荷もバースト型ノードに適していれば、MemoryDBのt4gは低コストな候補です。ただしMemoryDBのSLAは、バースト可能な汎用インスタンスのノードに起因する停止を適用対象から外しています。99.99%の保証を前提にする本番ではr系を選び、t4gは消えると困るが停止はある程度許容できるデータに使います。

逆に、耐久性が不要な単一リージョンのセッションストアやキャッシュ、Valkey 8系以降の機能を使いたい場合、書き込みにマイクロ秒の応答が必須の場合は、MemoryDBを新規に選ぶ理由がありません。セッションデータの保存先の選び方はセッション管理とは？セッションIDの発行から失効までの実装と保存先選定を解説で整理しています。

エンジンバージョンの開き

MemoryDBのエンジンバージョン一覧に載っているのは、6.2、7.0、7.1、7.2.6、そして2024年12月1日リリースの7.3までです（2026年11月1日確認）。Valkey 8系・9系の記載はありません。対するElastiCacheはValkey 9.1まで進み、8.2でベクトル検索、9.0で全文検索と耐久性が加わっています。7.3から約2年、MemoryDBのエンジンが7.x系に留まっている点は、新規採用で見落とせません。対応版は追加されうるので、着手前に一覧で確認してください。

料金体系と東京リージョンの月額試算

Valkeyエンジンで一律30%下がるノード時間料金

MemoryDBの課金軸は、ノードの稼働時間・データ書き込み量・スナップショット保存量の3つで、マルチリージョン構成ではリージョン間の送信データ転送料金が加わり、東京リージョンからの送信は1GBあたり0.09ドルです。支配的なのはノード時間です。東京リージョンの1時間あたりのオンデマンド単価は次のとおりです。

どのサイズでも差はきっちり30.0%で、r6g世代とr7g世代は同額です。新規に作るならr7gを選びます。r6gdはデータ階層化用のノードで、データ階層化の説明によると、メモリが埋まるとアクセスの少ない値をSSDへ移し、SSD上のデータの読み取りには500バイトの値で約450マイクロ秒が上乗せされます。定常的に触るデータが全体の20%以下なら候補になります。

データ書き込みとスナップショットの課金

見落とされやすいのがデータ書き込み料金です。Redis OSSエンジンでは東京リージョンで1GBあたり0.200ドルが一律にかかり、Valkeyエンジンでは月10TBまで無料、超過分が1GBあたり0.04ドルです。月に3TB書き込む構成なら、Redis OSSでは約600ドルが加算されるのに対しValkeyでは0ドルになり、ノード時間の30%より大きく効きます。スナップショットは、リージョン内のMemoryDBクラスター総ストレージ容量の100%まで追加の保存料金がかかりません。この無料枠を超えた分は、東京では1GB月あたり0.023ドルで、両エンジン同額です。

リザーブドノードの割引率とValkeyへの適用

1年以上動かす前提なら、リザーブドノードで単価を下げられます。期間は1年か3年、支払いは前払いなし・一部前払い・全額前払いの3方式です。東京のPrice List APIにある db.r7g.large（Redis OSS）の価格を、前払い分を期間の時間数で割って実効単価に直すと次のようになります。

Price List上のリザーブドノードはRedis OSSの行しかなく、Valkey専用の商品はありません。代わりにRedis OSSのリザーブドノードがValkeyのノードにも充当されます。AWSの例では、db.r7g.4xlargeのRedis OSSは32ユニット、同じサイズのValkeyは22.4ユニットとして数えるため、Redis OSS 1台分の予約でValkeyを約1.43台分まかなえます。予約は同じファミリー内でサイズをまたいで使えますが、db.t4gにはリザーブドノードがありません。

レプリカ付き小規模構成と本番構成の月額試算

公式の料金ページの計算例は米国リージョンの単価なので、東京の単価で730時間（1か月）を計算し直しました。Valkeyエンジンで書き込みは月10TB以内とし、スナップショットとデータ転送は含めていません。

中規模本番はシャードごとにレプリカを2台置き、AZ障害時もレプリカが1台残る構成です。小規模本番をRedis OSSエンジンで組むと、ノード時間だけで約541.66ドルになり、書き込み料金も別にかかります。既存のRedis OSSクラスターを運用しているなら、エンジンの切り替えを優先して検討する価値があります。

クラスター作成と接続の手順

ACLユーザーとTLS有効クラスターの作成

MemoryDBのクラスター作成ではACLの指定が必須です。全アカウントに用意されている「open-access」ACLはパスワードなしで全コマンドを許すので、本番では使いません。ACLの説明どおり、TLSを無効にしたクラスターはopen-accessしか選べないため、TLSは有効のままにします。パスワードは16〜128文字の印字可能文字で、カンマ・二重引用符・スラッシュ・@は使えません。

aws memorydb create-user \
  --user-name app-user \
  --access-string "on ~app:* &* +@all -@dangerous" \
  --authentication-mode Type=password,Passwords=AppUserPassw0rd-2026

aws memorydb create-acl \
  --acl-name app-acl \
  --user-names app-user

aws memorydb create-cluster \
  --cluster-name my-memorydb \
  --node-type db.r7g.large \
  --engine valkey \
  --engine-version 7.3 \
  --acl-name app-acl \
  --tls-enabled \
  --num-shards 1 \
  --num-replicas-per-shard 1 \
  --subnet-group-name my-subnet-group

アクセス文字列の ~app:* は操作できるキーを「app:」で始まるものに限り、-@dangerous はFLUSHALLなどの管理系コマンドを外します。保管時の暗号化はMemoryDBでは常に有効です。データ階層化を使う場合はr6gd系ノードを選んで --data-tiering を付けます。

PythonクラスタークライアントのTLS接続

接続先はクラスターエンドポイント（clustercfg. で始まるホスト名）です。Pythonでは、valkey-pyをインストールし、MEMORYDB_ENDPOINT・MEMORYDB_USER・MEMORYDB_PASSWORDを環境変数に設定してから、以下のコードを実行します。実行環境からクラスターのVPCへ到達できることと、セキュリティグループで実行元からTCP 6379への接続を許可していることが前提です。

import os
from valkey.cluster import ValkeyCluster

client = ValkeyCluster(
    host=os.environ["MEMORYDB_ENDPOINT"],  # clustercfg.my-memorydb.xxxxxx.memorydb.ap-northeast-1.amazonaws.com
    port=6379,
    username=os.environ["MEMORYDB_USER"],
    password=os.environ["MEMORYDB_PASSWORD"],
    ssl=True,
    decode_responses=True,
)

client.set("app:session:u123", "logged-in", ex=1800)
print(client.get("app:session:u123"), client.ttl("app:session:u123"))

このコードは、Valkey 9.1.2をTLS・クラスターモード・同じアクセス文字列のACLで起動したローカル環境に、valkey-py 6.1.1で接続して確認しました（自己署名証明書のため ssl_ca_certs を追加）。出力は「logged-in 1800」で、「app:」以外のキーへの書き込みは NoPermissionError、FLUSHALLは NOPERM で拒否されました。コマンドラインから確かめるなら valkey-cli -c --tls -h <エンドポイント> -p 6379 --user app-user --pass <パスワード> で同じ接続ができます。

IAM認証を使う場合の制約

パスワードの代わりにIAMで認証することもできます。ただしIAM認証の制約として、エンジン7.0以降が必要で、認証トークンの有効期限は15分、IAMで認証した接続は12時間で自動的に切断されます。接続を延ばすには新しいトークンでAUTHかHELLOを送り直す必要があり、MULTI／EXECの中では使えません。長時間つなぎっぱなしのワーカーでは、資格情報プロバイダーに対応したクライアントを選んでください。

Redis OSSからValkeyへのエンジン切り替え

稼働中のRedis OSSクラスターをValkeyへ切り替えるには update-cluster を使います。更新中も読み取りは続けられ、書き込みが止まるのはフェイルオーバーの数秒間です。エンジン版はダウングレードできないので、検証環境で先に確かめてから本番に当てます。

aws memorydb update-cluster \
  --cluster-name my-memorydb \
  --engine valkey \
  --engine-version 7.2

ベクトル検索の対応範囲と実運用での制約

索引アルゴリズムとフィールド型

ベクトル検索はMemoryDB 7.1以降で使えます。索引はHASHキーまたはJSONキーの上に作り、HSET や JSON.SET でキーを更新すると索引が背景で追随します。フィールド型はNUMERIC・TAG・TEXT・VECTORの4種類です。TEXTはURLや文書本文など、検索結果に添えて返す値を持たせる用途と説明されています。ベクトル検索のアルゴリズムは厳密解のFLATと近似のHNSWです。HNSWの M は最大512、EF_CONSTRUCTION と EF_RUNTIME は最大4096で、作成後に変えられるのは EF_RUNTIME だけです。ベクトル型はFLOAT32のみ、距離はL2・IP・COSINE、次元数の上限は32768です。

有効化はクラスター作成時にパラメータグループ default.memorydb-redis7.search を指定して行います。

aws memorydb create-cluster \
  --cluster-name my-vector-cluster \
  --node-type db.r7g.large \
  --acl-name app-acl \
  --engine redis \
  --engine-version 7.1 \
  --num-shards 1 \
  --parameter-group-name default.memorydb-redis7.search

クラスターがavailableになったら、そのクラスターエンドポイントへTLSとapp-userで接続します。以下はシェルではなく、接続後のvalkey-cliの対話プロンプトで実行するコマンドです。索引の接頭辞はACLで許可したキーの範囲（ここでは「app:」）に収めます。MemoryDBは索引単位でアクセスを判定し、接頭辞に含まれうる全キーへの権限が無いユーザーはその索引を使えないためです。

FT.CREATE hash_idx1 ON HASH PREFIX 1 app:hash: SCHEMA vec AS VEC VECTOR HNSW 6 DIM 2 TYPE FLOAT32 DISTANCE_METRIC L2
FT.SEARCH hash_idx1 "*=>[KNN 100 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2

近似最近傍探索の仕組みと他製品との比較はベクトルDBとは？仕組み・インデックス構造・製品比較とpgvectorで動かす手順【2026年版】で扱っています。

ベクトル検索のシャード・ノード・再起動時の制約

RAGの基盤に使えそうに見えても、機能と上限のページにある制約のほうが先に効きます。

• 単一シャードに限られ水平スケールできず、伸ばせるのは垂直方向とレプリカだけ
• 既存クラスターでは有効化できず、無効なクラスターのスナップショットから新規作成する
• 対応ノードタイプはR6g・R7g・T4gのみ
• 再起動時は索引を背景で作り直し、完了前の検索は拒否されることがある（プライマリとレプリカで完了が揃わない）

単一シャード制約は、データ量が読めない段階でMemoryDBをベクトルストアに据えにくくします。AWSが示す試算例では、1536次元で1000万ベクトルに104.9GBが必要で、db.r7g.4xlargeが推奨されています。この規模を先に見積もってから採用してください。

MemoryDBだけが持つマルチリージョン構成

MemoryDBを選ぶ最大の理由は、2024年12月1日リリースの7.3で始まったマルチリージョンクラスターです。複数リージョンでアクティブ・アクティブに読み書きでき、可用性は最大99.999%、書き込みの競合はCRDT（競合フリー複製データ型）で解決されます。対応リージョンは東京・ソウル・シンガポール・シドニー・ムンバイ・バージニア北部・オハイオ・オレゴン・北カリフォルニア・アイルランド・フランクフルト・ロンドンの12です。

マルチリージョン構成のノード要件と機能制限

前提条件と制限は厳しめです。ノードはR7gのxlarge以上が必須で、db.r7g.largeでは組めません。エンジンはValkey 7.3以降、束ねられるのは最大5リージョンです。データ型はString・Hash・Set・Sorted Setに限られ、TTLは使えず、APPENDなどの読み取り後に書き換えるコマンドも非対応です。ベクトル検索とデータ階層化も併用できません。トランザクションの原子性は1つのリージョン内だけで保証されます。

運用面では、単一エンドポイントも自動フェイルオーバーもない点に注意が必要です。リージョン障害時はアプリケーション側でトラフィックを手動で切り替え、AWSはRPO/RTOのSLAを示していません。分断の検知には MultiRegionClusterReplicationLag メトリクスの監視が案内されています。スループットはノードあたり読み取り1.3GB/s、シャードあたりのグローバル集約書き込みが約50MB/sです。AWS上のRedis互換サービス全体の選び方はAWSでRedisを使う方法：ElastiCache・MemoryDB・EC2の選び分けと接続手順で比べています。MemoryDBとElastiCacheのどちらで組むか、移行を含めて相談したい場合はAWSを中心としたインフラ構築の支援も行っています。

よくある質問

MemoryDBとElastiCacheの違いは何ですか？

もともとはMemoryDBが耐久性を持つプライマリデータベース、ElastiCacheがキャッシュという住み分けでした。2026年にElastiCache for Valkey 9.0が同じ方式の耐久性に対応したため、現在のAWSの案内は「複数リージョンのアクティブ・アクティブならMemoryDB、単一リージョンの耐久ワークロードは耐久性を有効にしたElastiCache」です。T系ノードでの小さな耐久構成と、耐久性つきのデータ階層化はMemoryDBでしか組めません。

MemoryDBの料金はいくらですか？

東京リージョンのオンデマンドで、db.r7g.largeがValkeyエンジンで1時間0.2597ドル、Redis OSSエンジンで0.371ドルです。これにデータ書き込み料金（Valkeyは月10TBまで無料、Redis OSSは1GBあたり0.200ドル）とスナップショット保存料金が加わります。レプリカ1台の2ノード構成なら月約379ドル、db.t4g.smallなら月約76ドルが目安です。単価は改定されるため、最終的には公式の料金ページで確認してください。

「Amazon MemoryDB for Redis」は今も使えますか？

同じサービスで、現在の名称は「Amazon MemoryDB」です。名称の変更とValkey対応は別々の更新で、Valkeyエンジンは2024年10月から選べるようになりました。Redis OSSエンジンも引き続き選べるので機能は失われていませんが、ドキュメントやコンソールの表記は新名称になっています。

既存のRedisクライアントはそのまま使えますか？

使えます。ただしMemoryDBは常にクラスターモードで、TLSとACLのユーザー認証を使うのが基本なので、クラスター対応のクライアントでTLSとユーザー名・パスワードを指定します。Valkey 7.2にはRedis OSS 7.1からの挙動変更があり、PUBLISHの応答順序やブロック中コマンドの解除時のエラーコードが変わっています。

MemoryDBはValkeyに対応していますか？

対応しています。2024年10月からValkeyエンジンを選べるようになり、公式のエンジン一覧ではValkey 7.2.6と7.3が最新です（2026年11月1日時点）。Valkeyを選ぶとノード時間が30%安くなり、データ書き込みも月10TBまで無料になります。マルチリージョンクラスターはValkey 7.3以降でしか組めません。

関連記事

• Amazon ElastiCacheとは？対応エンジン・Serverlessとノードベースの違いと料金・採用判断を実装者目線で解説
• ElastiCache Serverless for Valkeyとは？料金の試算・上限値・認証と接続手順【2026年10月】
• Valkeyとは？Redisとの違い・Streamsの使い方と導入手順【Valkey 9.1】
• AWSでRedisを使う方法：ElastiCache・MemoryDB・EC2の選び分けと接続手順
• ベクトルDBとは？仕組み・インデックス構造・製品比較とpgvectorで動かす手順【2026年版】