ElastiCache Serverless for Valkeyとは？料金の計算・上限値と作成手順【Valkey 9対応】

Amazon ElastiCache Serverless for Valkeyは、ノードの種類や台数を決めずにValkeyのキャッシュを使えるElastiCacheのデプロイ方式です。課金は「保存しているデータ量（GB時）」と「処理したリクエスト量（ECPU）」の2軸で、Valkeyは他エンジンより単価が約33%安く、最小課金容量も100MBまで下がります。一方で、本記事の試算条件では、数GBのデータを常時保存する場合はノードベースのほうが低料金になります。実際の比較には、必要な処理性能とピーク負荷も含めてください。この記事では、東京リージョンの実単価を使った月額試算、Serverlessだけに掛かる上限と制約、CLIでの作成とアプリからの接続、Redis OSSからの移行までを、AWS公式ドキュメントに沿って整理します。

まとめ：ElastiCache Serverless for Valkeyの要点

• 料金は東京リージョンでデータ保存 $0.101/GB時、リクエストは 100万ECPUあたり$0.0027。最小課金は100MBで、月額の下限は約$7.4です。
• 費用の大半はデータ保存で決まります。本記事の単価では1GBの保存料金は730時間で約$73.7です。毎秒500リクエストを1リクエストあたり1ECPUとし、比較先のノードで必要な性能を満たせる場合、掲載例ではレプリカ付きのノードベースが安くなります。
• Serverlessは常にクラスターモード有効・TLS必須です。クラスター対応のクライアントで接続し、複数キーを扱うコマンドはハッシュタグで同じスロットにそろえます。
• キースペース通知、CLIENT LIST、FUNCTION、Global Datastore、データ階層化、Valkey 9.0の耐久性（durability）はServerlessでは使えません。
• Valkey 9.0以降では、VPCを使わずIAM認証とTLS 1.3で接続する公開エンドポイントを選べます。
• 使用量の上限（cache usage limits）で費用に天井を付けられますが、事前スケーリング用の最小値を設定すると、使っていなくてもその分が課金されます。

以下、仕組みとバージョン、料金、制約、作成と接続、移行、監視の順に根拠を示します。

ElastiCache Serverless for Valkeyの仕組みと選べるバージョン

プロキシ経由の単一エンドポイントとクラスターモード固定

Serverlessのキャッシュを作ると、アプリケーションには1つのDNSエンドポイントが渡されます。接続はネットワークロードバランサー配下のプロキシ層が受け、裏側のシャード構成が変わってもクライアントはトポロジーを再取得する必要がありません。ElastiCacheはCPU・メモリ・ネットワークの使用率を監視し、どれかが逼迫するとシャードを追加してデータを再配置します。

エンジンは常にクラスターモード有効（cluster-enabled yes）で動き、全16,384スロットが「1つの仮想ノード」の持ち物としてクライアントに見えます。データは複数のアベイラビリティーゾーンへ非同期で複製され、可用性のSLAは99.99%です。保管時と通信時の暗号化は常に有効で、無効化はできません。マイナーバージョンとパッチは自動で適用され、メジャーバージョンだけは通知を受けて利用者が上げる方式です。

Valkey 7.2から9.1までのバージョンと主な追加点

Serverlessが対応するのはValkey 7.2以降、Redis OSS 7.1、Memcached 1.6.22以降です。ElastiCacheのエンジンバージョン一覧には、Valkeyについて次の版が載っています。

Serverlessでは保存量も課金対象です。利用中のエンジンにメモリ効率改善が適用され、課金対象の保存量が最小課金容量を上回る範囲で減れば、保存料金も下がります。9.0で入ったdurability（Multi-AZのトランザクションログ）はノードベース専用で、Serverlessでは選べません。2026年6月のValkey 9.1の告知は「ノードベースのクラスター向け」で、Serverlessに9.1が入っているかは作成したキャッシュのFullEngineVersionで確かめる必要があります。新規に作るならメジャーバージョン9を指定してください。

ElastiCache Serverless for Valkeyの料金と月額の試算

データ保存（GB時）とECPUの課金単位

データ保存量は1分間に複数回サンプリングされ、1時間ごとの平均がGB時として課金されます。ECPU（ElastiCache Processing Unit）はvCPU時間と転送量をまとめた単位で、単純なGET・SETは転送1KBごとに1ECPUです。3.2KBを書き込むSETは3.2ECPU、SETの3倍のvCPU時間を使うHMGETは3ECPUと、vCPU時間と転送量の大きいほうで数えます。AWS Price List APIで取得した東京リージョン（ap-northeast-1）の単価は次のとおりです。

単価はPrice List APIの2026-09-14公開版です。料金ページにある「月額$6から」はバージニア北部（us-east-1、保存$0.084/GB時）の値で、東京では100MB×$0.101×730時間＝約$7.4が下限になります。

東京リージョン単価での月額試算

平均保存量と平均リクエスト数から、単純なGET・SETを前提に保存料金とECPU料金を概算するスクリプトです。CPU処理が支配的なコマンド、事前スケーリングの最小値、バックアップ、別途発生する転送料金、税金は計算に含めていません。1リクエストあたりの転送量が1KBを超えると、その分ECPUが増えます。

# 東京リージョン（ap-northeast-1）の単価。Price List API 版 20260914063714 で取得
STORAGE_PER_GB_HOUR = 0.101   # Valkey データ保存 USD/GB-時
ECPU_PER_MILLION = 0.0027     # Valkey 100万ECPUあたり USD
MIN_GB = 0.1                  # Valkey の最小課金容量 100MB
HOURS = 730                   # 1か月の時間数

def monthly(avg_gb, avg_req_per_sec, kb_per_req=1.0):
    gb = max(avg_gb, MIN_GB)
    ecpu = avg_req_per_sec * HOURS * 3600 * max(kb_per_req, 1.0)
    return gb * STORAGE_PER_GB_HOUR * HOURS, ecpu / 1e6 * ECPU_PER_MILLION

for gb, rps, kb in [(0.05, 10, 1), (1, 500, 1), (2, 2000, 1), (2, 2000, 4), (10, 5000, 1)]:
    s, e = monthly(gb, rps, kb)
    print(f"{gb:>5}GB {rps:>5}req/s {kb}KB -> 保存 ${s:8.2f} + ECPU ${e:7.2f} = ${s+e:8.2f}/月")

Python 3で実行した結果です。

 0.05GB    10req/s 1KB -> 保存 $    7.37 + ECPU $   0.07 = $    7.44/月
    1GB   500req/s 1KB -> 保存 $   73.73 + ECPU $   3.55 = $   77.28/月
    2GB  2000req/s 1KB -> 保存 $  147.46 + ECPU $  14.19 = $  161.65/月
    2GB  2000req/s 4KB -> 保存 $  147.46 + ECPU $  56.76 = $  204.22/月
   10GB  5000req/s 1KB -> 保存 $  737.30 + ECPU $   35.48 = $  772.78/月

毎秒2,000リクエストでもECPUは月$14程度で、請求の9割以上がデータ保存です。値が4KBに膨らむとECPUは4倍になりますが、それでも保存料金を超えません。Serverlessの費用を下げる手段は、まずTTLを付けて保存量を減らすことです。

ノードベースとの損益分岐

同じ東京単価で、データ量ごとにServerlessとノードベース（プライマリ＋レプリカ1台のMulti-AZ構成）を比べます。ノードは、既定のreserved-memory-percent（25%）を差し引いて収まる最小のタイプを選び、Serverless側には毎秒500リクエスト分のECPU（月$3.55）を加えています。

この表の条件では、1GB以上のすべての例でノードベースが安く、9GBでは2倍以上の差になります。ただし、メモリ容量だけで選んだ構成の比較で、同等の処理性能を確かめた結果ではありません。特にT4gはCPUクレジットで動くバースト型なので、継続負荷では性能を確認してください。逆に、データが数百MBで収まる、夜間や週末はほぼ空になる、トラフィックの山が読めない、といった条件ではServerlessが有利です。ノードベースは予約ノードを買えばさらに下がるため、定常負荷ではこの差が広がります。ElastiCache全体の課金要素とデプロイ方式の選び方は、Amazon ElastiCacheの対応エンジン・Serverlessとノードベースの違いと料金を整理した記事で扱っています。

ElastiCache Serverless for Valkeyの上限値と使えない機能

変更できない設定値とキャッシュあたりの上限

Serverlessではパラメータグループを使わず、エンジン設定は一切変更できません。設計に影響する固定値と上限は、AWSの設定値と上限のページによると次のとおりです。

見落としやすいのはスロット単位の上限です。キャッシュ全体では毎秒1,500万ECPUまで伸びても、1つのキー（＝1スロット）に集中するアクセスは毎秒3万ECPUで頭打ちになります。ランキングのキー1本に全ユーザーの読み書きが集まる設計は、Serverlessでも水平分散の恩恵を受けられません。また、追い出しポリシーがvolatile-lru固定のため、TTLの無いキーは上限に達しても消されず、書き込みがOOMエラーになります。キャッシュ用途のキーにはTTLを必ず付けてください。

Serverlessで使えないコマンドと機能

ノードベースでは使えるのに、Serverlessでは使えないものがあります。サポート対象コマンドの一覧から、移行や設計の前に確認しておくべき項目を挙げます。

• キースペース通知（notify-keyspace-eventsは空で固定）。キーの期限切れをイベントで受け取る設計は組めません。
• KEYSとPSUBSCRIBE（パターン購読）。キーの列挙はSCAN、Pub/Subはチャネル名を明示したSUBSCRIBEに置き換えます。
• 調査系のMONITOR・SLOWLOG・MEMORY USAGE・OBJECT・LATENCYと、CLIENT LIST・CLIENT TRACKINGなどのCLIENT系の多く。
• FUNCTION・FCALL（Valkey Functions）、WAIT、SWAPDB。LuaのEVALは使えます。
• Global Datastore（リージョン間レプリケーション）、データ階層化、durability。

FLUSHALLとFLUSHDBは、仮想ノードの裏にある全シャードへ1回の呼び出しで作用します（削除範囲はFLUSHALLが全データベース、FLUSHDBが選択中のデータベース）。このため、トランザクション（MULTI）の中には入れられません。耐久性が必要なら、ElastiCacheのノードベース（Valkey 9.0以降のdurability）か、Amazon MemoryDBとElastiCacheの違いと2026年の選び方を解説した記事で比較している選択肢を検討してください。

ElastiCache Serverless for Valkeyの作成手順

AWS CLIによるVPC内キャッシュの作成

必須の引数はキャッシュ名とエンジンだけで、他は既定値で作成できます。本番では、配置するサブネット、セキュリティグループ、使用量の上限、自動スナップショットを明示しておくのが安全です。

aws elasticache create-serverless-cache \
  --serverless-cache-name app-cache \
  --engine valkey \
  --major-engine-version 9 \
  --subnet-ids subnet-0aaa1111 subnet-0bbb2222 \
  --security-group-ids sg-0ccc3333 \
  --cache-usage-limits 'DataStorage={Maximum=5,Unit=GB},ECPUPerSecond={Maximum=100000}' \
  --snapshot-retention-limit 7 \
  --daily-snapshot-time 18:00

AWS CLI 1.44.87に通し、リクエストの組み立てまでを確認したところ、CacheUsageLimits.DataStorage.Maximum=5・Unit=GB・ECPUPerSecond.Maximum=100000として送信されました（実際のキャッシュは作成していません）。自動スナップショットは1日1回で、保持期間は最大35日（0で無効）です。--daily-snapshot-timeはUTCで、18:00は日本時間の午前3時です。作成後はaws elasticache describe-serverless-caches --serverless-cache-name app-cacheでステータスがavailableになるのを待ち、表示されたエンドポイントに接続します。コンソールでは「Valkey caches」から「Create Valkey cache」を選び、名前を入れて既定設定のまま作成すれば1分程度で使えるようになります。

セキュリティグループでは、アプリ側からポート6379（読み書き）と6380（読み取り専用）へのインバウンドを許可します。

公開エンドポイント（Valkey 9.0以降）の条件

Valkey 9.0以降のServerlessでは、接続タイプに「Public」を選ぶと、VPCを経由せずインターネットから接続できるエンドポイントが発行されます。CLIでは--connection-type publicと--user-group-id default.iam-user-groupを付け、エンドポイントはxxx.public.serverless.<リージョン>.cache.amazonaws.comの形になります。

条件は、ユーザーグループの全ユーザーがIAM認証であることと、TLS 1.3での接続です。パスワード認証のユーザーは混在させられません。作成権限はIAMの条件キーelasticache:ConnectionTypeで制限できるため、組織で公開エンドポイントを禁止したい場合はこの条件キーでポリシーを書きます。VPC内のLambdaやECSから使うなら、従来どおりVPC接続を選ぶほうが経路を絞れます。

アプリからの接続とクラスターモードの注意点

valkey-cliでのTLS接続と読み取りポート6380

Amazon Linux 2023ではValkeyパッケージに含まれるvalkey-cliがTLSに対応しています。Serverlessは常にクラスターモードなので-cを付けて接続します。

valkey-cli -c -h app-cache-xxxxxx.serverless.apne1.cache.amazonaws.com -p 6379 --tls

同じホスト名でポート6380も公開されており、接続後にREADONLYを送るとレプリカから結果整合性の読み取りができます。スロットあたりの上限が毎秒3万から9万ECPUに広がり、読み取りのレイテンシも下がります。書き込み直後の値を読む必要がある処理は6379、多少古くてもよい参照系は6380と、接続先を分けるのが定石です。

Pythonからの接続とCROSSSLOTエラー

クラスターモードに対応していないクライアント（単一ノード用のValkey()やRedis()）では、スロットのリダイレクトを処理できません。valkey-py（Python）ならValkeyClusterを使い、ssl=Trueを指定します。実行前にpip install valkeyでインストールし、環境変数VALKEY_HOSTに作成したキャッシュのエンドポイントを設定します。以下はユーザーグループを設定していないVPC接続の例で、公開エンドポイントやユーザーグループを使うキャッシュでは認証情報の追加が必要です。

import os
from valkey.cluster import ValkeyCluster
from valkey.exceptions import ValkeyClusterException

HOST = os.environ.get("VALKEY_HOST", "localhost")
PORT = int(os.environ.get("VALKEY_PORT", "6379"))

client = ValkeyCluster(
    host=HOST,
    port=PORT,
    ssl=True,
    ssl_ca_certs=os.environ.get("VALKEY_CA"),  # ローカル検証の自己署名証明書用。ElastiCacheでは未設定でよい
    decode_responses=True,
)

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

client.set("{cart:u123}:items", "3", ex=1800)
client.set("{cart:u123}:total", "4980", ex=1800)
print("MGET(同じハッシュタグ):", client.mget("{cart:u123}:items", "{cart:u123}:total"))

try:
    client.execute_command("MGET", "a:1", "b:2")
except ValkeyClusterException as e:
    print("MGET(別スロット):", e)

Serverlessの接続条件の一部を再現したローカル構成（TLS有効・全スロットを1ノードに割り当てたValkey 9.1.2のクラスター）を手元に立て、valkey-py 6.1.1で実行した結果です。

GET: logged-in TTL: 1800
MGET(同じハッシュタグ): ['3', '4980']
MGET(別スロット): MGET - all keys must map to the same key slot

Serverlessはスロットを1つの仮想ノードにまとめて見せますが、クラスターモードの制約はそのまま残ります。a:1（スロット8311）とb:2（スロット2372）のように別スロットのキーを1コマンドで扱うと、クライアント側で止まるか、サーバーからCROSSSLOT Keys in request don't hash to the same slotが返ります。同じユーザーのカートやセッションのように一緒に読み書きするキーは、{cart:u123}のようなハッシュタグで同じスロットにそろえます。ログイン状態をキャッシュに置く設計の全体像は、セッション管理の実装と保存先選定を解説した記事にまとめています。

Redis OSSのサーバーレスキャッシュからValkeyへの移行

Redis OSSで作ったServerlessキャッシュは、エンジンとメジャーバージョンを指定し直すだけでValkeyに切り替えられます。エンドポイントのDNS名は変わらず、アプリケーションの接続設定もそのままです（AWSのアップグレード手順）。

aws elasticache modify-serverless-cache \
  --serverless-cache-name my-cache \
  --engine valkey \
  --major-engine-version 9

CLIはv1なら1.35.2以上、v2なら2.18.2以上が必要です。Redis OSS 5.0.6以降からの移行は、フェイルオーバーの数秒を除いて読み書きを続けられます。

注意したいのは戻し方です。ElastiCacheが用意しているロールバックはValkey 7.2からRedis OSS 7.1への1通りだけで、Valkey 8以降へ上げたキャッシュをRedis OSSへ戻す経路はありません。いきなり9へ上げず、まず7.2で動作を確かめてから上げると、問題が出たときにRedis OSSへ戻す余地が残ります。ロールバックするキャッシュに紐づくユーザーとユーザーグループは、エンジン種別がREDISである必要があります。ValkeyとRedisのライセンスやコマンド差分そのものは、ValkeyとRedisの違いを解説した記事で詳しく扱っています。

上限設定・事前スケーリングと監視するメトリクス

Serverlessの使用量上限と課金対象の制御

--cache-usage-limitsのMaximumを設定すると、データ量とECPU/秒がその値を超えなくなります。データ量が上限に達すると、TTL付きのキーがLRUで追い出され、追い出せるキーが無ければ書き込みがOOMエラーになります。ECPU/秒が上限を超えると、リクエストがスロットリングされます。AWSは、上限を設定したらBytesUsedForCacheとElastiCacheProcessingUnitsに上限の75%相当のCloudWatchアラームを設定することを推奨しています。ECPUは期間内の合計値なので、1秒あたりの上限と比較する場合は、Sumを集計期間の秒数で割ってください。

事前スケーリングの最小値と未使用時の課金

同じ引数のMinimumは事前スケーリング（プレウォーミング）用です。空のキャッシュが最初に受けられるのは毎秒3万ECPU（READONLY併用で9万）で、そこから倍々で拡張していくため、ゲームのリリースやセール開始のように一気にアクセスが来る場面では、事前に最小値を引き上げておきます。設定の反映には最大60分かかります。

ただし、最小値を設定すると、実際の使用量が下回っていてもその値で課金されます。東京の単価で毎秒10万ECPUを最小にすると、1時間あたり$0.972、1か月置きっぱなしにすると約$710です。イベントが終わったらMinimum=0に戻してください。最小値の引き下げは即時に反映されます。

監視するCloudWatchメトリクス

Serverlessはノード単位ではなくキャッシュ単位のメトリクスを出します。運用で最初に見るのは次の4つです。

• ThrottledCmds：拡張が追いつかずスロットリングされたリクエスト数。0以外が続くなら事前スケーリングかホットキーの分散を検討します。
• ElastiCacheProcessingUnits：消費したECPU。ECPU料金の見積もりの実測値です。
• BytesUsedForCache：保存量。請求の大半を占めるので、TTL設計の効果はここで確かめます。
• CacheHitRate：cache_hits / (cache_hits + cache_misses)。低いなら、キャッシュに載せる対象かTTLの長さを見直します。

不正アクセスの検知にはAuthenticationFailures・CommandAuthorizationFailures・KeyAuthorizationFailuresにアラームを設定します。重要なイベントはSNSではなくAmazon EventBridgeに送られます。

ElastiCache Serverless for Valkeyを選ばないほうがよい場面

Serverlessは「容量計画をしなくてよい」ことに価値があり、どの条件でも安いわけではありません。ここまでの制約を判断材料にまとめると、次のどれかに当てはまる時点でノードベースのElastiCacheか別サービスを選ぶべきです。

• 常時1GB以上を保存し、必要な処理性能を満たすノード構成との比較でServerlessの料金が高くなる定常負荷
• 主データストアとして使い、障害時のデータ消失を許容できない
• キースペース通知、KEYS、パターン購読、CLIENT TRACKINGに依存した既存コードがある
• 複数リージョンへの複製が要る
• 特定のキーに毎秒3万ECPUを超える読み書きが集中する

反対に、開発・検証環境、データが数百MBに収まるセッションストア、トラフィックの山が予測できない新規サービスでは、Serverlessの手軽さが費用差を上回ります。AWS以外も含めて従量課金のキャッシュを探しているなら、リクエスト課金のUpstashの料金と無料枠を解説した記事も比較材料になります。

よくある質問

ElastiCache Serverless for Valkeyの最低料金はいくらですか？

最小課金容量が100MBなので、東京リージョンでは保存料金だけで月約$7.4（0.1GB×$0.101×730時間）が下限です。これにリクエスト量に応じたECPU料金が加わります。料金ページの「月額$6から」はバージニア北部の単価で計算した値です。

ElastiCache Serverlessで使えるValkeyのバージョンはどれですか？

ServerlessはValkey 7.2以降に対応し、作成時はメジャーバージョンを指定し、省略すると利用できる最新版になります。ElastiCacheの一覧ではValkeyの最新が9.1ですが、9.1の告知はノードベース向けです。公開エンドポイントなどServerless向けの新機能は9.0以降が前提です。マイナーとパッチは自動で更新され、メジャーバージョンだけを利用者が上げます。

Redis OSSからValkeyに移行するとアプリの変更は必要ですか？

エンドポイントのDNS名は変わらず、Redis OSS 7.2までのコマンドはそのまま動くため、多くの場合アプリの変更は不要です。ただし、ロールバックできるのはValkey 7.2からRedis OSS 7.1だけなので、8以降へ上げる前に動作確認を済ませてください。

Serverlessとノードベースはどちらが安いですか？

保存量、ECPU消費量、必要なノード構成で決まります。本記事の毎秒500リクエスト・1リクエストあたり1ECPUという条件では、1GBの例でレプリカ付きのノードベースが安くなります。データが小さい、または利用が時間帯で大きく偏るならServerlessが有利です。

ElastiCacheの読み方は何ですか？

「エラスティキャッシュ」と読みます。伸縮自在を意味するelasticとcacheを組み合わせた名前で、Serverless for Valkeyはその中のサーバーレス型デプロイ方式です。

関連記事

• Amazon ElastiCacheとは？対応エンジン・Serverlessとノードベースの違いと料金・採用判断を実装者目線で解説
• Valkeyとは？Redisとの違い・Streamsの使い方と導入手順【Valkey 9.1】
• Amazon MemoryDBとは？ElastiCacheとの違い・料金と2026年の選び方を実装者目線で解説
• Upstashとは？サーバーレスRedisの料金・無料枠と使い方【2026年9月】
• セッション管理とは？セッションIDの発行から失効までの実装と保存先選定を解説