1. はじめに
2026 年 8 月 5 日、Aurora Serverless のスケーリングが改善されたという発表がありました1。初回のスケールアップで 1 秒以内に最大 12 ACU（Aurora Capacity Unit）まで到達し、そこから 256 ACU まで伸びる、という内容です。プラットフォームバージョン 3 と 4 では設定変更なしで有効になっています。
発表文が想定ワークロードとして挙げているのは、バーストと長いアイドルを繰り返す使い方です。つまり最小 ACU を 0 にして一時停止させる、いわゆるゼロスケール運用をしている読者が主な対象になります。
筆者は 4 月にゼロスケールからの再開時間を計測した記事を書きました2。そのときの結論は「プラットフォームバージョン 4 の改善は稼働中のスケーリングの話で、0 ACU からの起動時間は変わらない」でした。今回の発表は、起動ではなくスケールアップ側の改善です。そこで、0 ACU から再開した直後に実際の負荷をかけたら容量がどう変化するのかを計測しました。
なお発表文には、一時停止からの再開についての記載はありません。「スケールアップが速い」と「起動が速い」は別の話なので、この 2つを分けて計測します。
1.1. 結論（先出し）
- 0 ACU から再開すると、約 1 秒で 2.0 ACU になる。ただし接続が返るのは要求から 12〜25 秒後
- 負荷をかけ続けても、容量はしばらく 2.0 ACU のまま変わらない。負荷・データ量・上限を変えた 34回すべてで発生し、実測できた 33回では上がり始めまで 58〜201 秒（約 1〜3.4 分）。必要な容量が大きい条件ほど長く、同じ条件の 9回でも 108〜約194 秒（中央値 167 秒）とばらつく
- 容量が上がり始めてからは速く、上限 16 以上の構成では 8 秒以内に 12 ACU を超えた
- 最小 ACU を 1 から 30 へ引き上げた場合は、変更の適用に 13 秒、そのあとの 1 秒で 4.5 ACU から 16.5 ACU へ増えた
「1 秒で 12 ACU」という増え方は、このクラスタでも確認できました。ただしそれが出たのは、最小 ACU の設定を引き上げたときと、負荷をかけて約 1〜3.4 分待ったあとです。少なくとも今回の構成では、再開直後のバーストに対する応答性の改善は確認できませんでした。なおこの停滞は CloudWatch のメトリクスだけでなく、DB 内部のメモリ設定と実スループットでも同じ時刻まで続くことを確認しています（5.7 章）。
1.2. 検証ゴール
| # | 確かめること | 確認できれば OK の条件 |
|---|---|---|
| 1 | 0 ACU から再開した直後に負荷をかけたとき、容量がどう変化するか | 1 秒粒度の容量推移を複数回取得し、分布として示せる |
| 2 | 容量が上がり始めるまでの時間が、何に依存しているか | 負荷の大きさ・上限 ACU・データサイズ・負荷の有無・最小 ACU の変更、それぞれを変えて比べられる |
2. 検証環境
| 項目 | 内容 |
|---|---|
| クラスタ | Aurora PostgreSQL 17.7（db.serverless） |
| プラットフォームバージョン | 4（ServerlessV2PlatformVersion） |
| リージョン | ap-northeast-1 |
| 最小 ACU / 上限 ACU | 0 / 8・16・64（5.5 章の計測のみ最小を 1 → 30 に変更） |
| 非アクティブ一時停止 | 300 秒 |
| 負荷生成クライアント | EC2 c6i.4xlarge（16 vCPU）、クラスタと同一 VPC・同一 AZ |
| 負荷 | pgbench の読み取り専用モード（-S）。標準条件は 128 接続、比較で 8〜256 接続 |
| データセット | pgbench の scale factor 20（200 万行 / 307 MB）。5.3 章の比較のみ scale factor 2000（約 30 GB） |
エンジンバージョンを 17.7 にしたのは、前回記事と同じにして比べられる形にするためです。プラットフォームバージョンはエンジンバージョンとは別に管理されるため、17.7 のままでもプラットフォームバージョン 4 が割り当てられていました。
負荷をかける EC2 はクラスタと同じ VPC・同じ AZ に置きました。同一 VPC の外から接続していたときは、単純な SELECT の平均レイテンシが 11.3 ミリ秒ありました。このレイテンシで頭打ちになり、接続数を上げても Aurora 側に十分な負荷をかけられなかったためです。VPC 内に移したあとは 0.6 ミリ秒になりました。計測中の EC2 の CPU 使用率は最大でも 18.8% で、負荷をかける側は飽和していません。
容量は ServerlessDatabaseCapacity を 1 秒粒度で取得しています。get-metric-data に Period: 1 を指定すると 1 秒間隔で連続して取れます（get-metric-statistics は同じ 1 秒を指定しても最大 9 秒の欠落が出ました）。あわせて pgbench 側のスループット（5 秒間隔）も記録し、容量の変化と時刻が一致するかを毎回突き合わせています。この 2 系統目の記録は、容量データに欠落が出た回を補うためにも使います（4.1 章）。
3. 発表内容と、公式ドキュメントの現状
発表文には「1 秒以内に最大 12 ACU に到達する」とあります1。一方で、2026 年 8 月 7 日時点の公式ドキュメント（英語版）は、まだ以前の説明のままです。
スケーリングの説明ページには、増分は 0.5 ACU 単位から始まり、現在の容量が大きいほど増分も大きくなる、と書かれています3。一時停止と再開のページには、再開時は比較的小さい容量から始まってそこから上げていく、とあり、例として 2.0 ACU から再開する CloudWatch の出力が載っています4。
つまり「1 秒で 12 ACU」に対応する記述は、まだドキュメントに反映されていません。実測で補えるのはこの部分です。
4. 検証① 再開直後に負荷をかけると何が起きるか
一時停止（0 ACU）に入ったことを確認してから接続します。時刻の起点は「接続を要求した瞬間」、つまりアプリケーションが接続しに行った時点です。接続が返ったら pgbench で 128本の接続を張り、負荷をかけ続けます。
まず 1回分の推移です。上限 64 ACU の構成です。
| 経過秒 | ACU | 起きたこと |
|---|---|---|
| 0 | 0.0 | 接続を要求（このとき一時停止中） |
| 1 | 2.0 | 容量が 0 から 2.0 へ |
| 17 | 2.0 | 接続が返る |
| 18 | 2.0 | 128本の接続が張られ、負荷が始まる |
| 125 | 10.0 | 容量が上がり始める |
| 130 | 14.0 | |
| 317 | 26.5 |
一時停止からの再開そのものは速く、接続を要求してから約 1 秒で 0 から 2.0 ACU に上がっています。ただし接続が返るのはそこからさらに 16 秒後で、要求から数えると 17 秒かかりました。容量が 2.0 になるタイミングと、接続が使えるようになるタイミングは別です。
負荷が始まるのは接続が返ってから約 1 秒後です。pgbench が 128本の接続を張るのにその程度かかります。
そして負荷をかけ続けても、容量は 124 秒目まで 2.0 のまま変わりません。125 秒目に 1 秒で 10.0 へ上がりました。接続が返ってから数えると 108 秒後です。その後は上下しながら伸びていきます。
なお 1 秒粒度で見ると、値は小刻みに上下します。容量は毎秒計測され、0.5 ACU 刻みで増減すると説明されている3ので、この程度の上下は実際の挙動と考えられます。
一方で、前後とつながらない値が 1 サンプルだけ現れることもありました（この回では 2か所、いずれも 3.5）。前後が 13〜15 ACU なので差は 10 前後あり、0.5 刻みという説明と合いません。スケールダウンにはバッファキャッシュのデータが追い出されるといったコストがある3ため、1 秒で下げて 1 秒で戻す動作とも考えにくい値です。これはメトリクスの外れ値として扱い、図では折れ線から外して灰色の点で示しています。
以降、この待ち時間を「接続が返ってから容量が上がり始めるまでの時間」として計測します。接続が返るまでの時間は試行ごとに 12〜25 秒とばらつくので、そこを含めずに現象だけを切り出すためです。上の例では 108 秒になります。
pgbench 側のスループットとレイテンシも同じ時刻で変わります。2.0 ACU のあいだは毎秒 6,300〜9,400 トランザクション、レイテンシは 13〜20 ミリ秒でした。容量が上がった直後は毎秒 40,628 トランザクション、レイテンシ 3.1 ミリ秒です。同じ負荷のまま、毎秒トランザクション数が 4〜6倍になりました。128本の接続が 13〜20 ミリ秒待たされており、処理を待っている接続があった状態です。
4.1. 容量が上がり始めるまでの時間の分布
同じ条件（上限 64 ACU・128 接続・307 MB）で 9回計測しました。
このうち 3回は、容量メトリクスの取得が途中で欠けて、上がり始めの瞬間を直接は記録できていません。ただし欠け始めるまでは 1 秒刻みのデータが残っており、その時点まで 2.0 ACU が続いていたことは分かります。さらに 2 章のとおり pgbench 側のスループットを並行記録しているので、スループットが数倍に急増した時刻から、上がり始めの時刻を絞り込めます。両方が取れている 19回で突き合わせると、スループットの急増はいずれも容量が上がり始めてから 13 秒以内に現れていました（記録が 5 秒間隔のため、そのぶん遅れて見えます）。復元した 3回は、容量データが 2.0 のまま途切れた時刻と、スループットが急増した区間の終端との間に絞り込み、「約」を付けて示します。
9回の値は 108 / 108 / 163 / 164 / 167 / 178 / 約183 / 約184 / 約194 秒でした。中央値は 167 秒、幅は 108〜約194 秒です。同じ条件で繰り返しても 1.5倍を超える開きがあり、特定の秒数を前提にはできません。
内訳には偏りが 1つ見えます。108 秒だった 2回は、いずれもその日の一連の計測の 1回目で、直前の 1 時間に負荷をかける計測をしていませんでした。163 秒以上の 7回は、いずれも 5〜20 分前に負荷をかける計測を終えたあとでした。また、同じ時刻に別々のクラスタで計測した 3回（163 / 167 / 178 秒）は互いに近い値でした。ただし後日の追加計測（5.7 章）では、半日以上間を空けた 1回目でも 160 秒で、この偏りはあてはまりませんでした。関係があるのかどうかは、この回数では判断できません。
データセットや接続数を変えた分も含めると、実測できた 33回で 58〜201 秒の範囲に散らばります（短い側は 8 接続の軽負荷です。5.1 章）。いずれにしても、再開直後の約 1〜3.4 分は容量が 2.0 ACU から変わらない、という点は 34回すべてで再現しました。
5. 検証② 容量が変わらない原因を切り分ける
「1 秒で 12 ACU 上げる」という機能が関係しているのか、それとも別の要因なのかを、条件を 1つずつ変えて確かめます。
5.1. 負荷の大きさを変える
公式ドキュメントには、現在の容量が必要な容量より大幅に低いと、上げ幅と上げる速さをうまく見積もれない、という記述があります5。再開直後の 2.0 ACU はこの条件に該当するので、必要な容量が大きいほど待ち時間が長くなるのかを確かめます。
まず各負荷が必要とする容量を測りました。容量が上がりきった状態のクラスタに同じ負荷をかけ続け、安定した値を必要容量の目安とします。なお、容量がすでに上がった状態から負荷を強めた回では、4 章のような 2.0 ACU のまま待つ時間なしに容量が上がっています。
| 接続数 | 安定後の ACU（必要容量の目安） |
|---|---|
| 8 | 約 5.5〜6（再開計測内の上がったあとの安定値） |
| 16 | 約 9 |
| 64 | 約 31 |
| 128 | 約 50 |
| 256 | 64（上限に到達） |
128 接続の負荷は 50 ACU 前後を必要とします。再開直後はそれを 2.0 ACU で受けており、必要な容量の 1/25 のまま約 2〜3 分が経過することになります。
そのうえで、接続数だけを変えて待ち時間を測りました。クラスタの上限はすべて 64 ACU、データセットも同じです。
| 必要容量の目安 | 接続数 | 容量が上がり始めるまでの時間（秒） |
|---|---|---|
| 約 5.5〜6 ACU | 8 | 58 / 59 / 59 |
| 約 9 ACU | 16 | 85 / 87 / 92 |
| 約 31 ACU | 64 | 83 / 85 / 108 |
| 約 50 ACU | 128 | 108〜約194（9回・中央値 167。4.1 章） |
| 64 ACU | 256 | 160 / 約184 / 201（ほかに 1回、178 秒まで 2.0 ACU のまま計測終了） |
需要が 2.0 ACU に近い側ほど、待ちは短くなりました。8 接続（約 5.5〜6 ACU）は 58〜59 秒で、3回がほぼ同じ値です。接続数 16・64 の側は 83〜108 秒、128・256 の側は 108〜201 秒（4.1 章の 2回の 108 秒を除くと 160 秒以上）でした。必要な容量が大きいほど待ち時間が長いという傾向は、軽負荷側まで含めて一貫しています。ただし 16 接続と 64 接続はほぼ同じ幅で範囲の重なりもあり、比例のようなきれいな関係ではありません。
念のため、負荷をかける側が足りなかった可能性も確かめました。停滞している間はどの接続数でも 2.0 ACU なので、そのときの毎秒トランザクション数を比べます。
| 接続数 | 停滞中の毎秒トランザクション数 |
|---|---|
| 16 | 8,700〜9,500 |
| 64 | 7,700〜8,700 |
| 128 | 6,300〜11,800 |
| 256 | 8,900〜10,500 |
接続数を 16倍にしてもほとんど増えません。2.0 ACU 側が処理の上限になっているということで、どの接続数でも負荷は足りていました。DatabaseConnections でも、停滞中に 128本（256 接続の回は 256本）の接続が張られたままだったことを確認しています。8 接続の停滞中は毎秒 3,300〜4,500 トランザクションで、容量が上がったあとは毎秒約 14,500 と 3倍以上になりました。この軽負荷でも、停滞中は 2.0 ACU 側が処理の上限になっています。
なお、接続数 16・64・256 の各 3回は、同じ構成のクラスタ 3つへ同時に負荷をかけたものです（256 接続の 201 秒の回だけは単独の計測です）。8 接続の 3回は 1 クラスタずつ単独の計測です。停滞中の毎秒トランザクション数が、単独で計測した回と同じ範囲にあることを確認しており、負荷を生成する側の競合で結果は変わっていません。
5.2. 上限 ACU を変える
次に、接続数を 128 に固定したまま上限 ACU を変えます。上限は必要な容量を頭打ちにするので、5.1 章の関係が正しければ、上限が低い構成ほど待ち時間は短くなるはずです。また上限を 12 未満にすると、そもそも 12 ACU には到達できません。
| 上限 ACU | 容量が上がり始めるまでの時間（秒） | 到達最大 ACU |
|---|---|---|
| 8 | 94 / 96 / 118 | 8.0 |
| 16 | 96 / 123 / 125 | 16.0 |
| 64 | 108〜約194（9回・中央値 167） | 18.0〜27.0 |
待ち時間そのものは、上限 8 の構成でも発生します。長さは上限 8・16（94〜125 秒）が上限 64（中央値 167 秒）より短く、上限で必要容量を低く頭打ちにすると待ちも短くなる、という 5.1 章と同じ傾向です。
停滞中の DB 側 CPU 使用率にも、上限別の差が出ています。サーバーレスの CPUUtilization は「最大容量時に使える CPU に対する割合」と定義されています6。同じ 2.0 ACU の停滞中でも、この値（1 分平均）は上限 8 の構成で 47〜60%、上限 16 で 28〜30%、上限 64 で 5〜6% でした。CPU の消費はどの構成でも 2.0 ACU 相当の割り当てを超えており、容量が上がった直後には上限 8・16 とも 100% に達してそのまま続いています。需要が上限を超えていたことは、DB 側の指標でも確認できます。
上限 64 の到達最大が必要容量の約 50 に届いていないのは、負荷開始から 300 秒で計測を打ち切っているためです。上がり始めが 108〜約194 秒なので、残りの時間では 18〜27 ACU までしか伸びません。約 50 という必要容量は、容量が上がりきるまで負荷をかけ続けたときの安定値です（5.1 章）。
5.3. データサイズを変える
再開直後の 2.0 ACU ではメモリが約 4 GiB しかなく、データがバッファキャッシュに載らないためにストレージ読み取り待ちになっているのではないか、という仮説を立てました。スケーリングの判断には CPU・メモリ・ネットワークの使用状況が使われる3ので、ストレージ待ちで CPU 使用率が上がらなければ、容量が増えないことも説明できます。
そこで約 30 GB のデータセットと 307 MB のデータセットで比べました。後者は 2.0 ACU のメモリに収まるサイズです。
| データセット | 容量が上がり始めるまでの時間（秒） |
|---|---|
| 約 30 GB（5回・書き込みを含む負荷も使用） | 109〜176 |
| 307 MB（9回・4.1 章の同一条件） | 108〜約194 |
307 MB でも同じ待ち時間が出ました。両者の範囲は重なっており、データサイズでは説明が付きません。
5.4. 負荷をかけない
再開させるだけで、こちらからは負荷をかけなかった場合です。上限 16 ACU で 3回試しました。接続が返るまでは 13〜23 秒で、負荷をかけた場合と変わりません。
| 回 | 容量が上がり始めるまでの時間 | 到達最大 ACU |
|---|---|---|
| 1 | 36 秒 | 3.5 |
| 2 | 87 秒 | 5.0 |
| 3 | 82 秒 | 3.5 |
負荷をかけていないのに 2.0 ACU から上がります。公式ドキュメントには、負荷が無くても容量が最小まで下がらないことがあると書かれており、理由としてバックグラウンド処理（purge など）やクラスタ管理そのものに使う CPU とメモリが挙げられています7。アイドル時でも CPU とメモリを使う処理があり、同じ処理が再開直後の 2.0 ACU からの上昇にもつながっていると考えられます。
同じ上限 16 ACU で、負荷をかけた場合と並べます。
| 条件 | 容量が上がり始めるまでの時間 | 到達最大 ACU |
|---|---|---|
| 負荷なし | 36 / 82 / 87 秒 | 3.5〜5.0 |
| 負荷あり（128 接続） | 96 / 123 / 125 秒 | 16.0（上限） |
負荷をかけた 3回が、かけない 3回より早く上がり始めることはありませんでした。負荷で変わるのは「どこまで上がるか」であって、上がり始めはむしろ遅くなっています。必要な容量が大きいほど待ちが長いという 5.1 章の傾向とも合います（負荷なしの必要容量は 3.5〜5.0 ACU 相当です）。
5.5. 最小 ACU の設定を引き上げる
ここまでは実際に負荷をかけてきました。今度は同じクラスタで、最小 ACU の設定を 30 へ引き上げます。負荷はかけません。
事前に最小 ACU を 1 にして 3 分待ちましたが、容量は 4.5 ACU までしか下がりませんでした。5.4 章と同じ理由7で、最小 ACU を 1 に設定しても実際の容量が 1.0 になるわけではありません。変更を適用した時点の容量は 4.5 ACU です。
| 経過秒 | ACU | 変更前からの増加（ACU） | 起きたこと |
|---|---|---|---|
| 0 | 4.5 | （基準） | 最小 ACU を 30 へ変更 |
| 13 | 4.5 | +0.0 | まだ変化なし |
| 14 | 16.5 | +12.0 | 1 秒で 12.0 増える |
| 62 | 20.0 | +15.5 | |
| 181 | 30.0 | +25.5 | 設定した最小の 30 に到達 |
変更の適用そのものに 13 秒かかっている点は、あわせて見込んでおく必要があります。
この結果はほかの方の検証とも一致します8。同記事では最小 ACU を 1 から 30 に変えて 1 秒で 13.5 ACU に到達し、30 ACU 到達まで 3 分 45 秒という値でした。計測している操作が同じなので、同じ挙動を見ていると考えられます。
発表文の書き方と、2つの計測の値を並べます。発表文は「最大 12 ACU に到達する」という書き方ですが、2つの計測はどちらも 12 前後の増加になっています。
| 計測 | 変更前 | 1 秒後 | 差（ACU） |
|---|---|---|---|
| 本記事 | 4.5 ACU | 16.5 ACU | +12.0 |
| 前掲の検証8 | 1.0 ACU | 13.5 ACU | +12.5 |
12 という水準まで上がるのであれば、4.5 からでも 1.0 からでも 12.0 で止まるはずです。実際には両方とも 12 を超えたところまで上がっており、水準ではなく増加量が 12 前後、という読み方のほうが観測に合います。
5.6. 4 章の計測と並べる
4 章の「負荷をかけた場合」と 5.5 章の「設定を変更した場合」は、同じクラスタ・同じプラットフォームバージョンでの計測です。この 2つを同じ軸に重ねます。青が 4 章、オレンジが 5.5 章です。
オレンジは 14 秒目に垂直に立ち上がり、青は 125 秒目に 2.0 から 10.0 へ上がるまで横ばいです。同じクラスタでも、操作の違いで推移がこのように変わります。
この対比があるので、「この環境にはまだ新機能が適用されていないから上がらない」という説明は当てはまりません。新機能はこのクラスタで有効で、負荷をかけて上げる場合に、容量が上がり始めるまでの待ちが最も長くなります。
5.7. 計測の見え方によるものでないことを確かめる
最後に、この停滞が CloudWatch メトリクスの遅延や欠落による見かけではないことを、追加の 1回で確かめました。条件は 4.1 章と同じ（上限 64 ACU・128 接続・307 MB）で、容量に関わる指標を 3 系統同時に記録します。
- CloudWatch の
ServerlessDatabaseCapacity（1 秒粒度） - pgbench のスループット（5 秒間隔）
- DB 内部の
shared_buffers。Aurora Serverless は現在の容量に応じてこの値を動的に調整する9ため、接続の中から毎秒参照すれば、CloudWatch を経由せずに容量の変化を観測できる
| 系統 | 2.0 ACU 相当のままだった時間（接続が返ってから） | 変化のようす |
|---|---|---|
ServerlessDatabaseCapacity |
160 秒 | 160 秒目に 2.0 から上昇を開始 |
| pgbench スループット | 約 165 秒（毎秒 7,000〜12,800 トランザクション） | 165 秒のビンで毎秒 27,035 へ急増 |
shared_buffers |
234 秒（2.0 ACU 相当の約 2.9 GiB のまま） | 234 秒目に約 20 GiB へ拡大 |
容量メトリクスより早く変化した指標はありません。停滞中は実際のスループットも DB 内部のメモリ割り当ても 2.0 ACU 相当のままで、停滞が計測の見え方の問題ではないことを確認できました。スループットの急増が 5 秒遅れて見えるのは記録間隔によるものです。shared_buffers への反映は容量メトリクスより約 70 秒あとで、メモリ設定は容量に遅れて追従する指標のようです。
この回の停滞は 160 秒で、4.1 章の分布（108〜約194 秒）の範囲内でした。なお一時停止からの再開時には PostgreSQL のプロセスが起動し直っており（pg_postmaster_start_time が接続成功とほぼ同時刻）、その後のスケールアップでは再起動は起きていません。
6. 考察
時間がかかっているのは、スケールアップの動作そのものではなく、上げ始めるまでです。上がり始めてからは、上限 16 以上のどの回も 8 秒以内に 12 ACU を超えました。最速の回は 1 秒で 2.0 から 14.5 ACU に上がっています。最小 ACU を引き上げた場合も、適用後の 1 秒で 12.0 増えています。1 秒で 12 ACU を引き上げる仕組みそのものは、このクラスタで機能していると考えられます。
その仕組みが動作し始めるまでの待ち時間については、公式ドキュメントに次の記述があります。
Aurora serverless DB instances can most effectively estimate how much and how fast to scale up when the current capacity isn't drastically lower than the required capacity.5
現在の容量が必要な容量より大幅に低いと、上げ幅と上げる速さをうまく見積もれない、という説明です。再開直後の 2.0 ACU はこの条件に当てはまり、5.1 章の「必要な容量が大きいほど待ちが長く、需要が 2.0 ACU に近い 8 接続では 1 分弱まで短くなる」という結果とも矛盾しません。ただし同じ条件でも 108〜約194 秒とばらつくこと、境目がどこにあるのか分からないことから、内部の動作までは断定できません。
上限別の差（5.2 章）については、もう 1つ向きの合う公式の記述があります。Aurora は CPUUtilization（最大容量に対する割合）を監視し、その割合を継続的に高く使うとスケールアップする、と説明されています6。同じ 2.0 ACU の停滞でも、この割合は上限 8 では 47〜60%、上限 64 では 5〜6% と大きく違い、割合が高い構成ほど早く上がり始めていました。ただし同じ上限 64 の中で接続数によって差が出たことは、この記述だけでは説明できません。
5.5 章の 2つの計測が「水準への到達」ではなく「12 前後の増加」だったことも、設計を考えるうえで意味を持ちます。増加量だとすると、開始容量が低いほど 1 秒後に到達する水準も低くなります。最小 ACU をいくつにするかが、立ち上がりの速さを実質的に決めることになると考えられます。
なお、この待ち時間が今回の発表で生まれたものなのかは分かりません。筆者が前回・前々回に計測したのは接続が返るまでの時間だけで、容量の推移は記録していませんでした。以前から同じ挙動だった可能性もあります。本記事で言えるのは、プラットフォームバージョン 4 の現時点でこうなっている、という点までです。
6.1. ゼロスケール運用への影響
発表文が想定ワークロードに挙げているのは、バーストと長いアイドルを繰り返す使い方です。今回の計測はまさにその形で、結果として応答性の改善は確認できませんでした。
容量が 2.0 ACU になること自体は約 1 秒です。ただし接続が返るまでに 12〜25 秒かかり、そのあとの約 1〜3.4 分は 2.0 ACU 相当の性能しか出ません。しかもその長さは同じ条件でも 108〜約194 秒とばらつき、事前に予測できません。最初のリクエストが返るまでの時間だけでなく、しばらくスループットが出ないことと、その長さを予測できないことの両方を設計に見込む必要があります。
6.2. 負荷による自動スケールを待たず、容量を先に指定する
5.4 章のとおり、負荷をかけても容量が早く上がり始めることはありませんでした。一方 5.5 章では、最小 ACU を引き上げた場合に、適用後の 1 秒で 12 ACU 増えています。再開直後に容量が必要なら、負荷をかけて上がるのを待つより、容量を指定するほうが確実です。
具体的には 2つあります。
- 最小 ACU を 0 でなく一定以上にしておく。2.0 ACU からの立ち上がりがそもそも発生しない
- バーストの時刻が分かっているなら、その前に最小 ACU を引き上げておく。ただし設定変更の適用自体に 13 秒かかった（5.5 章）
スケーリングの速度は現在の容量に依存し、容量が大きいほど増分も大きくなると説明されています35。素早い立ち上がりが必要なら最小容量を上げる、という方向はドキュメントにも示されています。
ただし最小 ACU を 0 以外にすると一時停止しなくなるため4、アイドル時間の料金が発生します。応答性と費用のどちらを優先するかの判断になります。本記事では料金の計測はしていないので、金額の比較には踏み込みません。
6.3. 同じ挙動を報告している例
この「容量がしばらく変わらず、あるとき短時間で大きく上がる」という挙動は、今回の発表とは関係なく以前から観測されているようです。
2022 年の DeNA の検証記事10では「ACU 無反応期間」という言葉が使われています。sysbench を実行して 1〜3 秒で CPU 使用率が 95% を超えているのに ACU は変わらず、平均 11.25 秒たってから 1 秒で 5〜7 ACU 上がり、そのあとは十数秒に 1 ACU 程度のゆるやかな上昇になる、という内容です。
データ量と関係が見えなかったという観察は、本記事の 5.3 章と同じです。別のエンジン（Aurora MySQL）・別の負荷ツールで同じ結論に到達しています。一方、同検証では最大 ACU とも関係が見えなかったとしており、上限 ACU で差が出た本記事の 5.2 章とは観察が分かれています。また、背景負荷がある状態では無反応期間が平均 1.4 秒まで短くなるという報告も、本記事で容量が上がりきった状態のクラスタでは待ち時間なしに容量が上がったこと（5.1 章の必要容量の計測）とも合います。
ただし長さは大きく違います（平均 11.25 秒に対して、本記事は 58〜201 秒）。DeNA の検証は自動一時停止が登場する前のもので、最小 ACU も 4 以上です。0 ACU からの再開ではないので、この差がゼロスケール特有のものなのか、エンジンや年代の違いなのかは切り分けられません。
7. まとめ
「1 秒で 12 ACU」という増え方は、実際にこのクラスタでも確認できました。最小 ACU を引き上げたときは、変更の適用に 13 秒かかったあと、1 秒で 12.0 ACU 増えています。負荷をかけた場合も、上限 16 以上の構成では、上がり始めてから 8 秒以内に 12 ACU を超えました。
一方で、0 ACU から再開して負荷をかけた場合は、容量が上がり始めるまで 58〜201 秒かかりました（実測できた 33回。ほかに 178 秒まで変わらないまま計測が終わった回が 1回）。同じ条件の 9回に絞っても 108〜約194 秒で、中央値は 167 秒です。上限 ACU を 8 まで下げても、データセットを 307 MB まで小さくしても発生します。必要な容量が大きい条件ほど長くなり、需要が 2.0 ACU に近い 8 接続では 1 分弱でしたが、同じ条件でのばらつきも大きく、何秒待つかは事前に予測できません。この停滞は DB 内部の shared_buffers と実スループットでも同じ時刻まで確認できています（5.7 章）。
ゼロスケールで、再開直後にバーストを受ける使い方をしている場合、今回の計測の範囲では、この機能による応答性の改善は確認できませんでした。応答性が必要なら最小 ACU を 0 以外にする、という従来の判断は変わりません。
なお、負荷をかけない再開では接続完了まで 13〜23 秒かかりました（5.4 章）。3回の中央値は 18 秒で、前回記事で示した中央値 12.0〜13.7 秒より遅い値ですが、回数が少なくクラスタも別なので、変化があったとは言えません。前回記事で示した接続タイムアウトの目安（通常の一時停止で 20 秒以上）は、そのまま据え置いてよいと考えています。
参考
-
Amazon Aurora Serverless now scales instantly to 12 ACUs（2026 年 8 月 5 日） ↩ ↩2
-
Aurora Serverless v2 のゼロスケール再開時間を Platform Version 4 で再計測してみた ↩
-
How Aurora serverless works。Aurora serverless scaling の節。 ↩ ↩2 ↩3 ↩4 ↩5
-
Scaling to Zero ACUs with automatic pause and resume for Aurora serverless。Application design considerations の節。 ↩ ↩2
-
Performance and scaling for Aurora serverless。Choosing the minimum Aurora serverless capacity setting for a cluster の節。 ↩ ↩2 ↩3
-
Performance and scaling for Aurora serverless。Important Amazon CloudWatch metrics for Aurora serverless の節。 ↩ ↩2
-
Performance and scaling for Aurora serverless。Troubleshooting Aurora serverless capacity issues の節。 ↩ ↩2
-
Performance and scaling for Aurora serverless。Parameters that Aurora adjusts as Aurora serverless scales up and down の節。 ↩