ElastiCache Redis パッチ適用時のダウンタイムは本当に発生するのか
ElastiCache Redis のパッチ（service update）適用時にどの程度のダウンタイムが発生するのか、公式ドキュメントと実測結果をまとめる。
結論
Redis 5.0.6 以降 + Multi-AZ + レプリカありの構成では、計画されたパッチ適用時に書き込み中断は発生しない。これは公式ドキュメントに明記されている。
公式ドキュメントの記載
Minimizing downtime in ElastiCache by using Multi-AZ より:
For Valkey and Redis OSS cluster mode disabled clusters with Multi-AZ enabled that run on the 5.0.6 or later engine, the planned node replacements complete while the cluster serves incoming write requests.
計画されたノード置換（パッチ適用含む）では、クラスタが書き込みリクエストを処理し続けたまま完了する。
よくある誤解
同じドキュメントに以下の記載がある:
This process usually takes just a few seconds until you can write to the cluster again.
この「数秒」は障害によるフェイルオーバー（予期しないプライマリノード障害）の話であり、計画されたパッチ適用の話ではない。混同しやすいので注意。
バージョン別まとめ
| シナリオ | バージョン | 公式の挙動 |
|---|---|---|
| 計画メンテナンス（パッチ適用） | 5.0.6 以降 + Multi-AZ | 書き込み継続（中断なし） |
| 計画メンテナンス（パッチ適用） | 4.0.10 以前 + Multi-AZ | DNS 更新に伴い数秒の中断の可能性 |
| 障害フェイルオーバー | 全バージョン + Multi-AZ | 数秒（a few seconds） |
| スタンドアロン（レプリカなし） | 全バージョン | ノード再起動中はサービス不可 |
実測結果
環境
- Redis 7.0.7 / cache.t4g.micro
- レプリカ1台（Multi-AZ + Auto Failover）
- 未適用パッチ6件を累積適用
監視結果（1秒間隔、約25分間）
| 種別 | 件数 | NG |
|---|---|---|
| HTTP ping | 1,510 | 0 |
| Redis ping | 1,511 | 0 |
フェイルオーバーは発生した
Redis ping の接続先 IP と AWS API のロール変化から、フェイルオーバー自体は発生していることが確認できた。
14:25:19 @ [OK] Ping succeeded @ IP: 10.0.0.192 ← primary 14:25:20 @ [OK] Ping succeeded @ IP: 10.0.1.198 ← replica に切り替わり AWS API ステータスも available → modifying → available と遷移し、ロールが入れ替わった。
しかし、DNS エンドポイント経由の接続ではエラー0件。1秒間隔の監視で検知できないほど高速に切り替わっている。
standalone 環境でも同様
別環境（standalone・レプリカなし）でも同じパッチを適用したが、こちらもダウンタイムなしだった。公式ドキュメントではスタンドアロンは「サービス不可」とされているが、実際にはホットパッチ方式で再起動なしに適用された可能性がある。