AWS 上のごく小規模な Redis のマネージドインスタンスが必要な局面で、費用と aws-cdk での取り回しを鑑みて ElastiCache Serverless を導入しました。
アプリケーションエンジニアの 
id:astj です。
ごく小規模なウェブサービスにおける（セッション情報などの）揮発性データストアとして Amazon ElastiCache の Redis を使っている箇所があるのですが、しばらく保守が行き渡っていなかったところ標準サポート期間が終了し、 AWS による延長サポートに切り替わってしまっていました。
延長サポートされていることで一定のセキュリティが担保されているのはありがたいですが、延長サポートぶんの追加料金（2年間は元料金に+80%）が加算されて費用的には不利なため、少なくとも標準サポートの提供されるところまで更新して、延長サポート加算前程度の水準の費用までは抑えておきたいところです。
この要件を解決するために必要なアクションの第一の候補は勿論 ElastiCache の Redis バージョンを更新して標準サポートされるバージョンに切り替えることでしょう。Redis OSS でなく Valkey に切り替えることと合わせれば、同インスタンスタイプのままコスト削減も達成可能です。
今回のサービスの利用箇所は東京リージョンの t3.small ですので、 Valkey に切り替えれば1日あたり$1.25ほどだったのが$1ほどになります。 これで更新すれば終了、めでたしめでたしですね。
CloudFormation における ElastiCache の扱いについて
というところなのですが、このプロジェクトでは aws-cdk を介して CloudFormation でインフラリソースを管理しています。元々、CloudFormation では元々スタック外での変更（ドリフト）が起きたときにスタック側で整合性を取るところに扱いの難しさがあり、2019年にリリースされた CloudFormation Resource Import の登場により、一度テンプレートからリソースを切り離した後に再度インポートし直すことで整合性を取る方法が確立され、これのおかげで以前と比べれば融通を利かせる余地は広くなってきました。*1
という背景があるのですが、この CloudFormation の import には制限があり、CloudFormation で利用可能な AWS リソースであっても import できる物とできない物があり、 ElastiCache においては2026年2月現在では肝心要の AWS::ElastiCache::CacheCluster や ReplicationGroup がこれに対応していません。
今回のサービスでは問題になったことはありませんが、他サービスにおいてこの制約で扱いづらい思いをした経験もあり、 CloudFormation ベースのインフラ管理プロジェクトで ElastiCache を扱い続けるのには少し悩ましいところがある、と考えていました。
ElastiCache Serverless という選択肢
ここで ElastiCache Serverless に目を向けます。ElastiCache Serverless の Redis OSS / Valkey は、おおまかには「内部でよしなにオートスケールする Redis Cluster」と理解して良いでしょう。よしなにオートスケールすることが一番の魅力ですが、Valkey の場合はそれに加えて最低利用料金がかなり低廉であるという特徴があります。ElastiCache Serverless の費用は保持データ量に応じた費用とECPU(おおざっぱには読み書きリクエスト数)に応じた費用から構成されますが、Valkey の場合は前者のデータ量に応じた料金の最低値が100MB相当であり、 Redis OSS や Memcached における1GB相当よりもかなり安く付きます。 それぞれ東京リージョンの Valkey で比較すると、インスタンスベースの最小サイズとなる t4g.micro は $0.02/時ですが、Serverless においてはデータ量課金の最低料金100MB分が $0.01/時（と、これに加えてECPUに応じた費用）となります。そのため、データ量がごく少なく、またトラフィックも十分少ない環境においては、t4g.micro と比べても半額程度で運用できる期待が持てます。
また、 CloudFormation サポートにおいても元来の非 Serverless クラスタより扱いが進んでいます。具体的には AWS::ElastiCache::ServerlessCache は CloudFormation の Resource import に対応している。このことから、将来的に運用でカバーしたい事態が発生してもその後 CloudFormation 管理下に戻しやすいことで好感を持ちました。
ちなみに、肝心の aws-cdk において、 ElastiCache Serverlss は 2026/2/24 現在は cdk 本体ではなく alpha 版扱いのモジュールから L2 コンストラクタが提供されています。
要求する品質水準によってはこれを採用基準に満たないと捉えることもありますが、今回のサービスの期待水準的には許容可能と考えました。というのは、内部的にはカスタムリソースを利用せず素直な CloudFormation で構成されており、また前述のように Resource Import に対応した ServerlssCache リソースで構築されていることから、仮に将来 cdk モジュールに非互換な変更が入った場合でもドリフト復旧と同じ要領で CloudFormation 管理下に戻しやすいと期待できるでしょう。
以上の観点から、今回は ElastiCache Serverless に移行するようにしました。
性能評価（をしない）
ここで補足しておきたいのは、おそらく ElastiCache Serverless を導入するなら本来検討したいであろう、耐障害性やスケール性、またスケールした際の経済性については評価していないというポイントです。 いわゆる本番サービスとして提供する場合はこれらの観点からの精査が必要ですが、今回は本番サービス級の品質を要求しない局面であったことからこれらの精査は行っていません。また、耐障害性についても、元々冗長化していない Redis ノード1台で運用していた水準ですので、それよりは良いでしょう、ということでヨシとしています。
RedisのTLS接続
ということで移行します。今回の場合はRedis内のデータは揮発性の情報しか含まれていないので、新たにクラスタを建てて、アプリからの接続をそちらに向けて完成です。特に cdk におけるリソース構築上も見所がなかったので省略します。
……というので終わりにしたかったのですが、 ElastiCache Serverless においては一点重要な特徴があります。Redis / Valkey のプロトコルにおいては TLS を設定することができますが、 ElastiCache Serverless においてはこの TLS 接続が必須となり、外すことができません。
そして、redis-cli や（少なくとも自分が確認した範囲での）各種クライアントライブラリにおいて、 TLS 接続は透過的には行えず、なんらかのオプションパラメータを渡す必要があります。即ち、「アプリからの接続をそちら（ElastiCache Serverless）に向ける」という段階では、単純なエンドポイント URL の切り替えの他に TLS 接続を有効化する必要があります。
redis-cli においては --tls オプションがこれに該当します。手元で検証した限りでは、オプションをつけ忘れると明示的なエラーにはならず接続できずタイムアウトする挙動を示したため、知らずにいると原因に気付きづらいのが悩ましいところかなと思います。
redis-cli --tls -h YOUR_CLUSTER_IDENTIFIER.serverless.apne1.cache.amazonaws.com
Redis に TLS サポートが入ったのは2020年5月の v6.0 です。古いバージョンのまま塩漬け運用しているとこれを満たさないこともあるかもしれません。
ちなみに、今回の Perl 製サービスにおいて利用している Redis::Fast における TLS(SSL) サポートは2024年リリースの 0.37 から利用できます。
my $redis = eval { Redis::Fast->new( server => "$redis_host:6379", ... ssl => $ENV{REDIS_TLS}, ); };
結果・まとめ
ここまで情報を小出しにしてきましたが、最終的には 「Perl 製のプロダクトの小さいマネージド Redisとして、最小構成で安く運用でき、 cdk / CloudFormation での扱いの良い Amazon ElastiCache Serverless を選定しました」というようになりました。
今のところ費用面は期待通り低減されており、また性能面でも元々の少ないリクエスト数の範囲で問題なく動いており、本件の期待は無事満たしています。
個人的にはより要求の高い条件下でも利用できればと思っていますが、それはまたどこかの機会で検討したいと思っています。
*1:そもそも CloudFormation 内の操作で全てを完結できればこのことで困らないのですが、稼働中のリソースの状態を更新する際に CloudFormation で直接リソースを更新する場合に発生するダウンタイムを、手動の中間状態を挟んで更新することで回避するようなことはインフラ運用で時たま存在したり、また緊急対応として直接 aws-cli やマネージメントコンソール画面からリソースを書き換えることも時にはあるでしょう。。
