1. はじめに
2024年12月、筆者は Aurora Serverless v2 の ゼロスケール の動作を確認してみた という記事を書きました。0 ACU まで落ちた状態から接続したとき、再開（resume）に何秒かかるのか、を実測した内容です。
前回の実測値をざっくりまとめると、次のようになります。
| 状態 | 再開時間（前回実測、2024-12 時点） |
|---|---|
| 通常の一時停止（5 分放置）・最大 ACU 2 以上 | 約 10〜15 秒 |
| 通常の一時停止（5 分放置）・最大 ACU 2 未満 | 約 15〜20 秒 |
| Deeper Sleep（24 時間以上放置） | 約 75 秒 |
そんな中、2026年4月20日に AWS Database Blog で Aurora Serverless: Faster performance, enhanced scaling, and still scales down to zero という記事が公開され、Aurora Serverless v2 Platform Version 4（以下 PV4）が発表されました。目を引くのは次の数値です（いずれも Platform Version 3 比）。
- NOPM(New Orders Per Minute) で 27〜34% 性能向上
- 0.5 ACU → 256 ACU へのスケールアップが 40 分から 22 分に短縮（約 45% 高速化）
- Sysbench 書き込みワークロードの完了時間が 73 分 → 49 分へ短縮（約 32.9% 短縮）
ブログ本文には、スケーリングアルゴリズムの改良について次の一文があります。
Now with platform version 4, Aurora is further enhancing the scaling algorithm by taking additional metrics as signals for scaling decisions.
ここで気になったのは、ブログで示されている数値はいずれも「稼働中の」スケーリング性能やワークロード完了時間の話であって、ゼロスケール状態からの再開時間（コールドスタート）に効くかどうかは明言されていない 点です。実際、ブログ本文を通して再開時間の改善に関する記述は見当たりませんでした。
一方でスケーリングアルゴリズムの改良が謳われている以上、0 ACU からの起動にも何らかの影響が出ている可能性はあります。そこで 前回 2024 年末時点の実測値と、2026 年 4 月時点の PV4 実測値を並べて比較してみた というのが本記事の主旨です。
Platform Version (PV) について
Aurora Serverless v2 には、バックグラウンドでリリースされる「プラットフォームバージョン」という概念があります。エンジンバージョン（例: PostgreSQL 16.x）とは別に、Serverless v2 の内部アーキテクチャ（スケーリングアルゴリズムや ACU 管理など）の世代を表します。PV2 / PV3 / PV4 の関係は 2. Platform Versionのおさらい で整理します。
今回の検証ゴール
| # | 検証項目 |
|---|---|
| 1 | PV4 で通常の一時停止からの再開時間は前回（10〜20 秒）と変わったか |
| 2 | PV4 で長期休眠からの再開時間は前回（約 75 秒）と変わったか |
| 3 | AWS Database Blog が謳う性能改善はコールドスタート（0 ACU からの起動）にも波及しているか |
検証環境と具体的な測定条件は 3.検証環境 で整理します。
結論（先出し）
- 通常の pause からの再開時間（PV4）: 約 12〜14 秒。最大 ACU=1 の構成では前回比 約 25〜30% 短縮、max=2 以上は前回レンジ内に収まり 12 秒前後が下限フロア
- Deeper Sleepからの再開時間（PV4）: 約 73 秒（前回 PV2: 約 75 秒）。実質変化なし
- AWS Database Blog が謳う性能改善はスケールアップ速度やワークロード処理能力の話であり、コールドスタートへの波及は限定的
- アプリ側の接続タイムアウト設計は前回推奨値（通常 pause: 30 秒以上、Deeper Sleep: 120 秒以上）が引き続き有効
2. Platform Version のおさらい
本題の検証に入る前に、Platform Version（以下 PV）の位置づけを簡単に整理します。
| PV | リリース時期 | 概要 |
|---|---|---|
| PV2 | Aurora Serverless v2 GA 以降の従来版 | 前回（2024-12）検証時はこの世代 |
| PV3 | 2025 年 8 月発表 | 性能向上版 |
| PV4 | 2026 年 4 月 20 日発表 | スケーリングアルゴリズム改良版。本記事の対象 |
Aurora Serverless v2 は新規クラスタを最新 PV で起動するルールがあり、ユーザー側から PV を指定する手段はありません。2026 年 4 月時点で新規クラスタを立てれば、東京リージョンにロールアウト済みであれば自動的に PV4 になります。本記事ではこの性質を利用し、前回（PV2 相当）の実測値と、今回の PV4 実測値の 2 点で比較 します。PV3 のみの実機データは取得できないため、PV3 の位置づけは AWS Database Blog の記述に委ねます。
3. 検証環境
今回は 1 クラスタの最大 ACU をマネジメントコンソールから段階的に 1 → 2 → 4 → 8 に変更しながら測定 しました。
| 項目 | 値 |
|---|---|
| クラスタ | Aurora PostgreSQL 17.7（db.serverless） |
| 最小 ACU / 最大 ACU | 0 / 1・2・4・8（順次変更） |
| 非アクティブ時の一時停止 | 5 分 |
| Platform Version | PV4 |
| リージョン | ap-northeast-1（東京） |
CLIでも確認できます。
-----------------------------------------------------------------------------------------
| DescribeDBClusters |
+--------------+--------------------+------------------+--------------------------------+
| DBCluster | DBEngine | DBEngineVersion | ServerlessV2PlatformVersion |
+--------------+--------------------+------------------+--------------------------------+
| sv2-pv4-max8| aurora-postgresql | 17.7 | 4 |
+--------------+--------------------+------------------+--------------------------------+
時刻計測は、クライアント側の date で取った時刻と、psql 経由で DB 側が返す clock_timestamp() の差分を「再開時間」として記録する方式で、前回記事と同じ手法を踏襲しています。各構成で 5 回ずつ計測し、Deeper Sleep（24 時間以上のゼロスケール継続）からの再開は最大 ACU=8 設定で 1 回のみ取得しています。
計測の間隔を 12 分にした理由
Aurora Serverless v2 の自動一時停止は「0 ACU の状態が 5 分継続したら一時停止」という条件で、接続を切断した瞬間に 0 ACU に落ちるわけではなく、ACU が下がりきるまでに数分のラグがあります。
実際、初回検証は 6 分間隔で 10 回計測したのですが、奇数回は約 13 秒で再開、偶数回は 50ms 前後で応答（一時停止に到達していない） という綺麗な交互パターンが出ました。これを避けるため、計測の間隔を 12 分に拡大しています。
4. 検証① 通常の一時停止からの再開時間
5 分の非アクティブで自動的に一時停止した状態から、psql で接続して clock_timestamp() を取得するまでの時間を測りました。
4.1. 実行イメージと無効サンプルの扱い
最大 ACU=8 構成での実行ログ抜粋です（iteration N は N 回目の計測、elapsed は経過時間ミリ秒）。
[2026-04-27T05:03:41+0000] preflight: SELECT 1 ...
[2026-04-27T05:03:41+0000] preflight OK
[2026-04-27T05:03:41+0000] iteration 1/5: sleeping 720s to ensure pause state...
[2026-04-27T05:15:41+0000] iteration 1: psql start (t0=1777266941967)
[2026-04-27T05:15:42+0000] iteration 1: OK elapsed=52ms db_ts=2026-04-27 05:15:42.016523+00
[2026-04-27T05:15:42+0000] iteration 2/5: sleeping 720s to ensure pause state...
[2026-04-27T05:27:42+0000] iteration 2: psql start (t0=1777267662028)
[2026-04-27T05:27:54+0000] iteration 2: OK elapsed=12232ms db_ts=2026-04-27 05:27:54.256878+00
（中略）
[2026-04-27T06:04:30+0000] iteration 5: OK elapsed=11837ms db_ts=2026-04-27 06:04:30.339561+00
[2026-04-27T06:04:30+0000] done.
1 回目の elapsed=52ms は、最大 ACU を 8 に変更した直後の事前接続でクラスタが活性化したまま 12 分の待機に入ったため、一時停止に到達せずに「起動中の通常応答」を測ってしまったものです。最大 ACU 変更を伴う構成切り替え直後の 1 回目は、各構成で同じ理由で除外対象になりました（最大 ACU=2 のみ 3 回目も同じく境界の揺らぎで瞬時応答になっています）。
集計時には経過時間 1000ms 未満のサンプルを「一時停止に到達しなかったもの」として機械的に除外しています。
# src/summarize.py で集計
python3 summarize.py --min-ms 1000 ../results/resume-pv4-max*-pause-*.csv
4.2. PV4 の計測結果
各構成の有効サンプル数と統計値です（単位: 秒）。
| 構成 | サンプル数 | 中央値 | 最小 | 最大 | 平均 | 標準偏差 |
|---|---|---|---|---|---|---|
| ACU 0 ～ 1(max1) | 5 | 13.7 | 12.4 | 14.1 | 13.5 | 0.68 |
| ACU 0 ～ 2(max2) | 3 | 12.2 | 12.0 | 13.0 | 12.4 | 0.52 |
| ACU 0 ～ 4(max4) | 4 | 12.3 | 11.6 | 12.6 | 12.2 | 0.43 |
| ACU 0 ～ 8(max8) | 4 | 12.0 | 11.7 | 12.5 | 12.1 | 0.39 |
サンプル数は 3〜5 件と少なめですが、各構成で標準偏差が 0.4〜0.7 秒に収まっており、中央値の比較には十分な安定性があります。
4.3. 前回（PV2 / 2024-12）との比較
前回記事の実測レンジと並べると次のようになります。
| 構成 | PV2（2024-12, 前回記事） | PV4（2026-04, 今回） | 差分の見え方 |
|---|---|---|---|
| 最大 ACU 2 未満（max=1） | 約 15〜20 秒 | 中央値 13.7 秒（12.4〜14.1） | 約 25〜30% 短縮 |
| 最大 ACU 2 以上（max=2/4/8） | 約 10〜15 秒 | 中央値 12.0〜12.3 秒（11.6〜13.0） | ほぼ同等（前回レンジの中位） |
読み取れること
- 最大 ACU=1 の構成では短縮が見られます。前回 15〜20 秒のレンジに対して、今回 13.7 秒中央値ですので、おおよそ 1/4 程度の改善幅です
- 最大 ACU が 2 以上の構成では前回値とほぼ同水準 で、改善は観測できませんでした
- 今回 PV4 では max=2 / max=4 / max=8 の中央値が 12.0〜12.3 秒の 0.3 秒以内 に収まっています。最大 ACU を増やしても再開時間はそれ以上下がらず、「再開時間の下限は 12 秒前後」 ですね
考察（AWS Database Blog の主張との関係、アプリケーションのタイムアウト設計への示唆）は 7.考察 で扱います。
5. 検証② Deeper Sleepからの再開時間
5.1. Deeper Sleep とは
Aurora Serverless v2 では、5 分間の非アクティブで通常の「一時停止（pause）」に移行しますが、ゼロスケール状態がさらに長時間継続すると、内部的に「Deeper Sleep」と呼ばれるより深い休眠状態に遷移します。この状態では通常の pause よりも再開（resume）に時間がかかります。
コンソールのイベントログで Deeper Sleep 状態への遷移が記録されていたことを確認しています。
今回は、max=8 構成での最終接続（2026-04-27 15:04:30）から次の接続（2026-04-29 09:08:55）まで 約 42 時間のゼロスケール継続後に計測しました。前回（2024-12）の条件（24 時間以上）を満たしています。
5.2. PV4 の計測結果
計測スクリプトの実行ログです（PAUSE_SECONDS=0：事前スリープなしで即接続）。
[2026-04-29T00:08:55+0000] preflight: SELECT 1 ...
[2026-04-29T00:10:08+0000] preflight OK
[2026-04-29T00:10:08+0000] iteration 1/1: PAUSE_SECONDS=0, skipping sleep (deeper sleep 想定で即計測)
[2026-04-29T00:10:08+0000] iteration 1: psql start (t0=1777421408404)
[2026-04-29T00:10:08+0000] iteration 1: OK elapsed=337ms db_ts=2026-04-29 00:10:08.737449+00
スクリプト冒頭の preflight（SELECT 1 による疎通確認）が 73 秒かかっています。この時点で Deeper Sleep からの resume が完了しており、iteration 1 本体は 337 ms（起動済みの DB へのただの接続）です。
| 計測ポイント | 所要時間 |
|---|---|
| preflight（= Deeper Sleep からの実質的な再開時間） | 73 秒 |
| iteration 1（再開済み状態での接続） | 337 ms |
5.3. 前回（PV2 / 2024-12）との比較
| 状態 | PV2（2024-12） | PV4（2026-04） | 変化 |
|---|---|---|---|
| 長期休眠（24 時間以上） | 約 75 秒 | 73 秒（1 回計測） | ほぼ同水準 |
サンプルが 1 回のみのため断定はできませんが、前回の約 75 秒に対して今回は 73 秒と誤差の範囲内です。PV4 においても Deeper Sleep からの再開時間は変わっていないと考えられます。
6. 検証結果まとめ
6.1. 通常の一時停止（pause）からの再開時間
| 構成 | PV2（2024-12） | PV4（2026-04） | 差分 |
|---|---|---|---|
| max=1 | 約 15〜20 秒 | 中央値 13.7 秒（12.4〜14.1） | 約 25〜30% 短縮 |
| max=2 | 約 10〜15 秒 | 中央値 12.2 秒（12.0〜13.0） | 前回レンジの中位 |
| max=4 | 約 10〜15 秒 | 中央値 12.3 秒（11.6〜12.6） | 前回レンジの中位 |
| max=8 | 約 10〜15 秒 | 中央値 12.0 秒（11.7〜12.5） | 前回レンジの中位 |
6.2. 長期休眠（Deeper Sleep）からの再開時間
| 状態 | PV2（2024-12） | PV4（2026-04） | 変化 |
|---|---|---|---|
| 長期休眠（約 42 時間非アクティブ） | 約 75 秒 | 73 秒（1 回計測） | ほぼ同水準 |
6.3. 主な発見
- PV4 では最大 ACU=1 の構成でのみ再開時間の短縮（約 25〜30%）が確認できた（誤差かもしれない）
- 最大 ACU が 2 以上の構成では PV2 時代と同水準（12〜13 秒）
- PV4 で ACU = 2 / 4 / 8 の中央値は 12.0〜12.3 秒と僅差。「12 秒前後が再開時間の下限フロア」 と見られる
- Deeper Sleep からの再開時間（約 73 秒）は PV4 でも改善なし
- スケーリング性能改善はコールドスタートへの波及は限定的
7. 考察
7.1. AWS Database Blog の主張との関係
AWS Database Blog（2026-04-20）が示す PV4 の性能改善数値は、いずれも 「稼働中インスタンスのスケールアップ速度」や「高負荷ワークロードの処理能力」 に関するものです。今回実測した 「ゼロスケール（0 ACU）から起動するまでの時間」 とは性質が異なります。
コールドスタートの律速ステップは、スケーリングアルゴリズムの改良よりも深いレイヤー（ストレージの再マウント、PostgreSQL プロセスの起動など）にあると考えられます。そのため PV のバージョンアップがコールドスタート時間に大きく影響しないのは自然なことと言えます。
前回（2024-12）の実測値は「2〜3 回確認」のレンジ値です。今回との差異が改善なのか誤差なのかを厳密に言い切るには、同一条件での反復測定が必要です。あくまで 「大きな変化はなさそう」 という読み方に留めてください。
7.2. アプリケーション側のタイムアウト設計への示唆
Aurora Serverless v2 をゼロスケールで運用する場合のタイムアウト推奨値は、PV4 でも前回から変わりません。
| シナリオ | 想定される再開時間 | 推奨する接続タイムアウト |
|---|---|---|
| 通常の pause（5〜10 分非アクティブ） | 12〜14 秒 | 20 秒以上 |
| Deeper Sleep（数時間〜日単位の非アクティブ） | 約 73〜75 秒 | 120 秒以上 |
Deeper Sleep に遷移すると 1 分以上応答がない期間が発生します。再開待ちを許容できないワークロードでは、定期的なウォームアップ接続（例: CloudWatch Events + Lambda で数時間おきに SELECT 1 を実行）を組み合わせて Deeper Sleep への遷移を防ぐ運用が有効です。
7.3. PV アップグレードの価値判断
PV4 は「稼働中の性能向上」が主眼であり、再開時間（コールドスタート）を期待してアップグレードを評価するのは適切ではありません。新規クラスタは自動的に最新 PV になるため、今後 PV4 で新たにゼロスケール運用を始める場合も、再開時間の設計値は本記事の実測値（通常 pause: 12〜14 秒、Deeper Sleep: 約 73 秒）を基準にしてください。
8. まとめ
Aurora Serverless v2 Platform Version 4（PV4）の再開時間を 2026 年 4 月に実測し、前回（2024 年 12 月、PV2 相当）と比較しました。
| 状態 | PV2（2024-12） | PV4（2026-04） |
|---|---|---|
| 通常 pause・max=1 | 約 15〜20 秒 | 中央値 13.7 秒 |
| 通常 pause・max=2 以上 | 約 10〜15 秒 | 中央値 12.0〜12.3 秒 |
| Deeper Sleep | 約 75 秒 | 73 秒（1 回計測） |
まとめると：
- PV4 でも再開時間の大きな短縮はなく、通常 pause は 12〜14 秒前後、Deeper Sleep は 約 75 秒が設計値として引き続き有効
- AWS Database Blog の性能数値（NOPM 向上・スケールアップ高速化）はコールドスタートとは別の話
- アプリ側の接続タイムアウトは 通常 pause: 20 秒以上、Deeper Sleep: 120 秒以上を推奨
- 前回（2024-12）と今回（2026-04）を並べると、再開時間はほぼ不変という時系列が見えてくる