1. はじめに
2026 年 9 月 30 日、Aurora Serverless のスケーリングがさらに大きな単位になったという発表がありました1。現在の容量に、1 秒以内で最大 16 ACU（Aurora Capacity Unit）を追加できるという内容です。プラットフォームバージョン 3 と 4 では、設定を変えなくても有効になっています。
筆者は 8 月に、ひとつ前の発表（1 秒以内に最大 12 ACU）を計測した記事を書きました2。以下、この記事を「前回の記事」と呼びます。前回の記事では、0 ACU から再開した直後に負荷をかけても、容量が 2.0 ACU のまましばらく変わらないことを確認しています。2.0 ACU のままだった時間は、条件を変えた 33 回で 58〜201 秒（約 1〜3.4 分）でした。スケールアップが始まってからは速かったので、時間がかかっていたのは「スケールアップが始まるまで」でした。
今回の発表文にも、想定する使い方としてアイドルと突発的なアクセスを繰り返すワークロードが書かれています1。そこで、16 ACU になった今、再開直後にスケールアップが始まるまでの時間がどうなったかを前回の記事と同じ条件で測り直しました。発表文には「現在の容量に追加する」と書かれています。この書き方に合わせて、1 秒で増える量が開始時の容量によって変わるかも確かめます。
1.1. 結論（先出し）
検証は 2 つです。検証（1）では、一時停止中のクラスタに接続して pgbench で負荷をかけ、再開直後にスケールアップが始まるまでの時間を測りました。負荷は 8 接続と 128 接続の 2 種類で、計 8 回です。検証（2）では、負荷をかけずに最小 ACU の設定を引き上げました。開始時の容量を変えて、最初の 1 秒で容量が何 ACU 増えるかを測っています。
- 検証（1）で再開直後に負荷をかけると、8 回とも、スケールアップが始まるまでしばらく容量が 2.0 ACU のままだった。8 接続では 48〜50 秒（前回の記事は 58〜59 秒）だった。128 接続では 77〜82 秒が 3 回、173〜184 秒が 2 回で、前回の記事の 58〜201 秒の範囲に収まる
- 検証（1）でスケールアップが始まってからは速く、128 接続の 5 回とも 8〜10 秒で 16 ACU を超えた。接続が返るまでの 18〜24 秒も前回の記事と同じ範囲である
- 検証（2）で最小 ACU を引き上げると、発表の「1 秒で最大 16 ACU」を確認できた。0.5 ACU から引き上げると 3 回とも 1〜2 秒で 16.5 ACU になった。ただし最初の 1 秒の増加量は +6.5〜+16.0 ACU でばらつき、開始時の容量が大きいほど大きく増える傾向は見えなかった
- 検証（2）の追加として、一時停止中に最小 ACU を引き上げても、再開後 43〜45 秒は 2.0 ACU のままだった
発表の改善は「スケールアップが始まったあとの 1 回の増え方」であり、再開直後にスケールアップが始まるまでの時間は変わっていません。ゼロスケール（アイドル時に 0 ACU まで下げて一時停止する使い方）で再開直後の突発的なアクセスに応答性が必要なら、負荷で容量が上がるのを待っていては間に合いません。必要な容量は最小 ACU で前もって確保しておく必要があります。常に備えるなら最小 ACU を 0 以外にして一時停止させない（前回の記事の結論のまま）、ピークの時刻が決まっているなら 3〜5 分前に最小 ACU を引き上げておく（再開に約 1 分、そこから 34 ACU までに約 3.5 分）、のどちらかです。
1.2. 検証ゴール
| # | 確かめること | 確認できれば OK の条件 |
|---|---|---|
| 1 | 0 ACU から再開した直後に負荷をかけたとき、容量が 2.0 ACU から変わらない時間がまだあるか | 前回の記事と同じ条件（128 接続・8 接続）でスケールアップが始まるまでの秒数を複数回取り、前回の記事の分布と並べて示せる |
| 2 | 1 秒で増える容量が、開始時の容量によって変わるか | 開始時の容量を 0.5・8・34 ACU にして最小 ACU を引き上げ、最初の 1 秒の増加量の大きさを比べられる |
2. 検証環境
前回の記事と比べられるよう、構成はできるだけ揃えました。
| 項目 | 前回の記事（2026 年 8 月） | 今回 |
|---|---|---|
| クラスタ | Aurora PostgreSQL 17.7（db.serverless）1 台 |
Aurora PostgreSQL 17.7（db.serverless）1 台 |
| プラットフォームバージョン | 4 | 4 |
| リージョン | ap-northeast-1 | ap-northeast-1 |
| 最小 ACU / 上限 ACU | 0 / 64（上限 8・16 での比較も） | 0 / 64（検証（2）のみ最小を変更） |
| 一時停止までの時間 | 300 秒 | 300 秒 |
| 負荷をかける EC2 | c6i.4xlarge（16 vCPU）、クラスタと同じ AZ | c6i.4xlarge（16 vCPU）、クラスタと同じ AZ |
| 負荷 | pgbench の読み取り専用モード（-S）、8〜256 接続 |
pgbench 17.11 の読み取り専用モード（-S）、128 接続と 8 接続 |
| データ | scale factor 20（一部の比較で scale factor 2000） | scale factor 20（200 万行 / 307 MB） |
図 1: 構成図
EC2 からクラスタへの SELECT 1 の往復は平均 0.533 ミリ秒でした（200 回）。計測中の EC2 の CPU 使用率は最大 14.0% で、負荷をかける側の CPU には余裕があります。
容量は CloudWatch の ServerlessDatabaseCapacity を、get-metric-data に Period: 1 を指定して 1 秒ごとに取得しています。期間が 60 秒未満のデータポイントは 3 時間しか取得できないので3、試行のたびに直後に取得しました。あわせて pgbench 側のスループットを TPS（1 秒あたりのトランザクション数）として 5 秒間隔で記録しました。容量の変化と同じ時刻に TPS が変わることを毎回確かめています。
3. 発表内容と公式ドキュメントの現状
発表文は次のとおりです1。
adding up to 16 ACUs to its current capacity within a second
「現在の容量に、1 秒以内で最大 16 ACU を追加する」という意味です。到達する水準ではなく、今の容量に足す量として書かれています。前回の記事では、容量が 4.5 ACU の状態で最小 ACU を引き上げたときの値を書きました2。1 秒で 16.5 ACU になり、増加量は +12 ACU でした。今回の発表は、この「足す量」が 16 まで増えたという書き方です。
一方で、2026 年 10 月 1 日時点の公式ドキュメントには、12 ACU も 16 ACU も書かれていません。スケーリングの説明は以前のままで、英語版も同じ記述です4。
スケーリングは 0.5 ACU という小さい増分で行われます。現在の容量が大きいほど、スケーリングの増分が大きくなり、そのため、スケーリングがより高速になります。
検証（2）では、この説明と発表文の「最大 16 ACU」がどう両立するのかを、開始時の容量を変えて確かめます。
4. 検証（1）再開直後にスケールアップが始まるまでの時間
手順は前回の記事と同じです。一時停止（0 ACU）に入ったことを確認してからさらに 300 秒待ち、接続します。接続が返った 2 秒後から pgbench で 300 秒間負荷をかけます。時刻の起点は前回の記事と同じく「接続が返った時刻」です。2.0 ACU を最後に確認した時刻までを「スケールアップが始まるまでの時間」として扱います。
①〜⑥は 8 接続と 128 接続を交互に、⑦・⑧は 128 接続を続けて、計 8 回測りました。回ごとの値は 4.1 章（8 接続）と 4.2 章（128 接続）の表に分けて載せます。
接続を試みてから 2.0 ACU になるまでは 0.8〜1.8 秒で、接続が返るまでは 18.3〜23.9 秒でした。どちらも前回の記事（約 1 秒、12〜25 秒）と同じ範囲です。
接続は 8 回とも再試行なしで返っていますが、そのうち 5 回は 20 秒を超えました。公式ドキュメントには、再開には通常約 15 秒かかるため、クライアントの接続タイムアウトを 15 秒より長くするよう書かれています5。前々回の記事と前回の記事では、目安を 20 秒以上としていました62。今回の値では、20 秒の接続タイムアウトだと 8 回中 5 回が失敗します。今回の計測の範囲では、30 秒程度を目安にするほうが安全です。
4.1. 8 接続
| # | 接続数 | 接続が返るまで | スケールアップが始まるまで | 2.0 ACU のあいだの TPS（中央値） | 最後の 60 秒の TPS（中央値） |
|---|---|---|---|---|---|
| ① | 8 | 21.3 秒 | 48.6 秒 | 3,116 | 13,765 |
| ③ | 8 | 21.0 秒 | 49.8 秒 | 3,939 | 13,432 |
| ⑤ | 8 | 18.5 秒 | 48.3 秒 | 4,358 | 14,239 |
8 接続の 3 回は 48.3〜49.8 秒で、ほぼ同じ値でした。前回の記事の 8 接続（58 / 59 / 59 秒）より約 10 秒短い値です。2.0 ACU のあいだの TPS は 3,116〜4,358、最後の 60 秒は 13,432〜14,239 でした。前回の記事（2.0 ACU のあいだ 3,300〜4,500、上昇後 約 14,500）と同じ水準です。
4.2. 128 接続
| # | 接続数 | 接続が返るまで | スケールアップが始まるまで | 2.0 ACU のあいだの TPS（中央値） | 最後の 60 秒の TPS（中央値） |
|---|---|---|---|---|---|
| ② | 128 | 23.9 秒 | 81.8 秒 | 6,523 | 87,913 |
| ④ | 128 | 23.1 秒 | 78.2 秒 | 6,381 | 95,873 |
| ⑥ | 128 | 22.4 秒 | 77.4 秒 | 6,870 | 90,930 |
| ⑦ | 128 | 18.3 秒 | 183.6 秒 | 12,273 | 71,698 |
| ⑧ | 128 | 19.9 秒 | 173.5 秒 | 11,618 | 71,844 |
128 接続の 5 回は、2 つのグループに分かれました。77〜82 秒の 3 回と、173〜184 秒の 2 回です。図 2 に、それぞれのグループから 1 回ずつ（②と⑦）を並べます。
図 2: 128 接続の 2 回（②・⑦）の容量と TPS。横軸は接続が返ってからの経過秒。灰色の丸は前後とつながらない 1〜3 秒だけの値（折れ線に含めない。4.4 章）
どちらの回も、スケールアップが始まってからは速く、8〜10 秒で 16 ACU を超えています（5 回とも同じ）。スケールアップが始まるまでの長さと、そのあいだの TPS が違います。長かった回は、同じ 2.0 ACU の表示のまま 1.7〜1.9 倍の TPS（約 12,000）を処理していました。
回ごとに、一時停止に入る直前の容量を並べました。
| # | 直前の試行 | 一時停止に入る直前の容量 | スケールアップが始まるまで |
|---|---|---|---|
| ② | 8 接続 | 2.5 ACU | 81.8 秒 |
| ④ | 8 接続 | 5.0 ACU | 78.2 秒 |
| ⑥ | 8 接続 | 3.0 ACU | 77.4 秒 |
| ⑦ | 128 接続 | 20.0 ACU | 183.6 秒 |
| ⑧ | 128 接続 | 21.0 ACU | 173.5 秒 |
直前に 128 接続の負荷をかけ、約 20 ACU のまま一時停止に入った 2 回だけが長くなっています。前回の記事でも、長かった 7 回はいずれも 5〜20 分前に負荷をかけたあとでした2。108 秒だった 2 回は、その日の最初の計測です。直前に負荷をかけた回ほど長い、という点は前回の記事と同じです。
ただし、8 接続では直前の負荷による差が出ていません。③と⑤は、直前の 128 接続のあと 28.0 ACU・36.5 ACU から一時停止に入りました。それでも 48〜50 秒で、他の回と変わりませんでした。また、長かった⑦・⑧はこの日の最後の 2 回でもあり、「直前の負荷」と「何回目か」を切り分けられていません。一時停止に入る直前の状態が、再開後にスケールアップが始まるまでの時間に関係している可能性があります（要追加検証）。
4.3. 前回の記事との比較
前回の記事と今回の値を並べると、図 3 のようになります。
図 3: スケールアップが始まるまでの時間（接続が返ってから）。前回の記事は 2026 年 8 月、今回は 2026 年 10 月 1 日の計測
| 条件 | 前回の記事 | 今回 |
|---|---|---|
| 8 接続 | 58 / 59 / 59 秒 | 48.3 / 48.6 / 49.8 秒 |
| 128 接続 | 108 / 108 / 163 / 164 / 167 / 178 / 約 183 / 約 184 / 約 194 秒（9 回、中央値 167 秒） | 77.4 / 78.2 / 81.8 / 173.5 / 183.6 秒（5 回） |
計測した日もクラスタも違うので、1 回ずつの値を比べる意味は薄いと考えています。分布として見ると、8 接続は 3 回とも前回の記事より約 10 秒短くなりました。128 接続は、前回の記事の最小（108 秒）を下回る回が 3 回出ました。一方で、前回の記事の範囲（163〜約 194 秒）と重なる回も 2 回あります。
4.4. 図 2 の灰色の点（メトリクスの外れ値）
スケールアップが始まった直後に、容量が 1〜3 秒だけ 3〜4 ACU に下がって見える箇所があります。②では 89 秒目の 1 秒が 3.0 ACU で、その前後は 10.5 ACU と 18.5 ACU です。⑦では 199〜201 秒目の 3 秒間が 4.0 ACU で、その前後は 16〜18 ACU でした。⑧でも 185〜186 秒目の 2 秒間が 3.5 ACU です。128 接続の 5 回すべてに、スケールアップが始まってから数十秒のあいだに 3〜4 ACU に下がって見える値が 1 か所以上あります。その 1〜3 秒を含む 5 秒間の TPS は下がっていません（⑦は 195〜200 秒が 56,881、200〜205 秒が 55,860）。前回の記事では、前後とつながらない 1 秒だけの値をメトリクスの外れ値として折れ線に含めませんでした2。今回は 2〜3 秒続く値もあるので、前後より 5 ACU 以上低い 3 秒までの落ち込みを同じ扱いにして、図 2 では灰色の点で示しています。容量が実際に下がったのではなく、メトリクスの値の側の揺れと考えられます。
5. 検証（2）開始時の容量と 1 秒の増加量
5.1. 方法
負荷はかけず、最小 ACU の設定を引き上げて、容量が 1 秒で何 ACU 増えるかを見ます。前回の記事 5.5 章と同じやり方です2。以下、設定を変更したあと最初に大きく増えた 1 秒の増加量を「最初の 1 秒の増加量」と呼びます（変更直後の 1 秒が +0.5 ACU で次の 1 秒に大きく増えた場合は、大きく増えたほうの 1 秒）。
開始時の容量を揃えるため、1 サイクルを次の順で行いました。
- 最小 ACU 0 のまま、アイドルで 0.5 ACU まで下がるのを待つ
- 最小 ACU を 34 に引き上げる（開始 0.5 ACU からの増加を見る）
- 容量が 34 で安定したら、最小 ACU を 64 に引き上げる（開始 34 ACU からの増加を見る）
- 90 秒観測したら、最小 ACU を 0 に戻す。クラスタの状態が
availableに戻るのを待つので、実際に戻せたのは 2〜4 分後
このサイクルは 3 回です。当初は、一時停止と再開で毎回 2.0 ACU に戻す手順を考えていました。計測の途中から一時停止に入らなくなったため、上の手順に切り替えています（6.5 章）。
結果を見たあと、開始時の容量を 8 ACU にした計測も 2 回追加しました。最小 ACU を 8 に引き上げ、8 ACU で安定してから最小 40 に引き上げます。最小 40 にしたのは、+16 ACU を超えて増えても見分けられるよう、+32 ACU の幅をとるためです。追加の 2 回ではクラスタが一時停止に入っていたので、最小 8 への変更でクラスタが再開しています。
5.2. 結果
| サイクル | 変化まで（0.5 → 最小 34） | 最初の 1 秒の増加量（0.5 → 最小 34） | 変化まで（34 → 最小 64） | 最初の 1 秒の増加量（34 → 最小 64） |
|---|---|---|---|---|
| 1 | 8.9 秒 | 0.5 → 16.5（+16.0） | 12.5 秒 | 34.0 → 43.5（+9.5） |
| 2 | 6.3 秒 | 0.5 → 16.5（+16.0） | 5.7 秒 | 34.0 → 42.0（+8.0） |
| 3 | 13.9 秒 | 1.0 → 16.5（+15.5。その前の 1 秒は 0.5 → 1.0） | 15.3 秒 | 34.0 → 43.5（+9.5） |
変化までの時間は、最小 ACU を変更してからの秒数です。
図 4: 最小 ACU を引き上げたときの容量。左は 0.5 ACU から最小 34 へ、右は 34 ACU から最小 64 へ。点線は設定した最小 ACU
0.5 ACU からは 3 回とも、変更から 6〜15 秒後に 16.5 ACU まで増えています。2 回は 1 秒で +16.0 ACU、もう 1 回は +0.5 ACU の 1 秒後に +15.5 ACU でした。発表文の「1 秒以内に最大 16 ACU を追加」とほぼ同じ量です。一方、34 ACU からの最初の 1 秒の増加量は +8.0〜+9.5 ACU でした。
追加した開始 8 ACU の 2 回は次のとおりです。
| 追加 | 一時停止中 → 最小 8 | 変化まで（8.0 → 最小 40） | 最初の 1 秒の増加量（8.0 → 最小 40） |
|---|---|---|---|
| 1 | 7.9 秒で 2.0 ACU、そのあと 45 秒は 2.0 のまま、72 秒で 8.0 | 5.1 秒 | 8.0 → 23.0（+15.0） |
| 2 | 13.7 秒で 2.0 ACU、そのあと 43 秒は 2.0 のまま、67 秒で 8.0 | 9.1 秒 | 8.0 → 14.5（+6.5） |
図 5: 一時停止中に最小 ACU を 8 に引き上げた 2 回の容量。横軸は最小 ACU を 8 に変更してからの経過秒。点線は最小 ACU を 40 に変更した時刻
開始 8 ACU からの最初の 1 秒の増加量は、+15.0 ACU と +6.5 ACU で大きく違いました。開始時の容量を 0.5・8・34 ACU にした 8 回を並べると、最初の 1 秒の増加量は +6.5〜+16.0 ACU の範囲でばらついています。
5.3. 最初の 1 秒のあとの上がり方
最初の 1 秒のあとは、0.5 ACU ずつのゆっくりした一定の上がり方に変わります。16.5 ACU から 34 ACU までは 1 分に約 5 ACU のペースで、最小 34 ACU に届いたのは変更から 211〜220 秒後でした。34 ACU から最小 64 への引き上げでは、最初の 1 秒のあと 1 分に約 8 ACU のペースで上がります。観測した約 150 秒のあいだには 64 に届いていません（61〜61.5 ACU まで）。最小 ACU を 34 に上げても、最初の 1 秒で届くのは 16.5 ACU までで、残りの 17.5 ACU には約 3.5 分かかります。
6. 考察
6.1. 検証（1）再開直後にスケールアップが始まるまでの時間は変わらなかった
スケールアップが始まるまでの 2.0 ACU のままの時間は、8 接続・128 接続のどちらでも 8 回すべてにありました（4 章）。発表文には再開直後についての記述がありません1。今回の改善は「スケールアップが始まったあとの 1 回の増え方」の話だと考えられます。
スケールアップが始まるまでの時間に関係しそうな記述として、公式ドキュメントには「現在の容量が必要容量より極端に小さくない場合、スケールアップする規模と速度を最も効果的に見積もることができます」と書かれています7。8 接続では必要な容量が小さく（今回の 8 接続では最大 8.0〜9.0 ACU）、128 接続よりスケールアップが始まるまでが短くなりました。8 接続のほうが短かったことは、この説明に沿っていると考えられます。ただし、128 接続で 2 つのグループに分かれたこと（4.2 章）までは、この記述からは説明できません。
スケールアップが始まってからは速く、128 接続の 5 回とも 16 ACU を超えるまでは数秒でした（4.2 章）。ただし負荷をかけた場合は 1 秒ごとの増分を取っていないので、「最大 16 ACU」の確認には検証（2）の値だけを使います（6.2 章）。
6.2. 検証（2）「1 秒で最大 16 ACU」は最小 ACU の引き上げで確認できた
最小 ACU を 0.5 ACU から引き上げたときは、1 秒で +15.5〜+16.0 ACU 増えました（5.2 章）。発表文の「1 秒以内に最大 16 ACU」は、最小 ACU の引き上げで確認できました。
0.5 ACU からは 3 回とも最初の 1 秒で届いた先がちょうど 16.5 ACU で、前回の記事でも 4.5 ACU から 16.5 ACU になっていました2。そこで「16.5 ACU という水準まで上がる」のかを確かめるために、開始 8 ACU を追加しました。しかし 23.0 ACU まで上がった回があり、水準で止まるわけではありませんでした。検証（2）の 8 回で +16.0 ACU を超えた回は無く、発表文の「最大 16 ACU」は毎回 16 増えるという意味ではないと考えられます。何が最初の 1 秒の増加量の大きさを決めているのかは、今回の回数では分かりません。
6.3. 検証（2）最初の 1 秒の増加量は開始時の容量では決まらなかった
最初の 1 秒の増加量は、開始 0.5 ACU からは +15.5〜+16.0 ACU、開始 8 ACU からは +6.5・+15.0 ACU、開始 34 ACU からは +8.0〜+9.5 ACU でした。ドキュメントには「現在の容量が大きいほど増分が大きい」と書かれています4。最小 ACU を引き上げたときの最初の 1 秒の増加量には、開始時の容量が大きいほど大きくなる傾向は見えませんでした。最も大きかったのは開始 0.5 ACU の回です。
一方、最初の 1 秒のあとのゆっくりした上がり方は、34 ACU に向かう区間が 1 分に約 5 ACU、64 ACU に向かう区間が 1 分に約 8 ACU でした。容量が大きいほうが速くなっています（5.3 章）。最初の 1 秒のあとの上がり方は、今回の 2 区間ではドキュメントの「現在の容量が大きいほど増分が大きい」という説明と合っています。最初の 1 秒の増加量とそのあとの上がり方は、別の決まり方をしていると考えられます。
6.4. 2 つの検証から見るゼロスケール運用への示唆
前回の記事では、再開直後に容量が必要なら、負荷で上がるのを待つより最小 ACU を先に引き上げるほうが確実だと書きました2。今回も同じ結果でした。公式ドキュメントにも、非常に大きな容量にすばやくスケールアップする必要があるときは、スケーリングレートの要件を満たす値に最小容量を設定することを検討するよう書かれています7。一時停止していない 0.5 ACU の状態から最小 ACU を引き上げれば、変更から 6〜15 秒で 16.5 ACU までは上がります。一方で負荷に任せると、128 接続では 77〜184 秒は 2.0 ACU のままでした。
ただし、16.5 ACU を超える分は 1 秒ごとの増え方がゆるやかで、34 ACU に届くまで約 3.5 分かかりました（5.3 章）。大きな容量が必要な時刻が分かっているなら、3〜5 分前から引き上げておく必要があります。一時停止中からなら、再開の約 1 分がこの 3〜5 分に足されます（5.2 章）。
一時停止中に最小 ACU を引き上げた場合の動きにも注意が必要です。一時停止中に最小 ACU を 8 に引き上げた 2 回は、変更でクラスタが再開して 2.0 ACU になったあと、しばらく 2.0 ACU のままでした（5.2 章）。負荷をかけたときの再開直後と同じ動きが、最小 ACU を引き上げた場合にも出ていると考えられます。一時停止しているクラスタで前もって容量を用意するなら、再開から約 1 分を見込む必要があります。
なお、応答性が必要なら最小 ACU を 0 以外にする、という前回の記事の結論は変わりません。最小 ACU を 0 以外にすると一時停止しなくなり、アイドル時間の料金がかかる5という条件も同じです。
6.5. 最小 ACU を前もって引き上げるときの注意点
6.4 章の「最小 ACU を前もって引き上げる」手順を作るなら、検証（2）で最小 ACU の変更を繰り返す中で確認した次の挙動も知っておく必要があります。
最小 ACU を変更すると、変更後 4〜5 分はクラスタの状態が modifying のままになります。容量が新しい最小値に届いたあとも、しばらくは状態が変わりません。最小 34 への変更のあと約 5 分、最小 64 への変更のあと約 4 分、状態が available に戻りませんでした。状態が戻るまでに次の変更を送ると InvalidDBClusterStateFault で拒否されます。最小 ACU を元に戻す変更も、同じく拒否の対象です。スクリプトで連続して変更する場合は、変更の前に状態が available になるのを待つ必要があります。
負荷のあとで最小 ACU を下げても、容量はすぐには下がりません（図 6）。当初の手順で、負荷の直後に開始容量 2 ACU を作ろうとしたときのことです。128 接続の負荷の直後に最小 ACU を 2 にしたところ、約 2 分は 26.5 ACU のままでした。そこから 10.5 ACU へ下がり、さらに約 4 分 10.5 ACU 前後にとどまりました。3.0 ACU まで下がったのは変更から約 6.4 分後です。最小 64 から最小 0 に戻したときは、64.0 ACU から 1.0 ACU 以下が 1 分続く状態になるまでに約 16 分かかりました。
図 6: 最小 ACU を下げたあとの容量。左は 128 接続の負荷の直後に最小 ACU を 2 にしたとき、右は最小 ACU を 64 から 0 に戻したとき。横軸は最小 ACU を変更してからの経過秒
接続が無くても一時停止に入らないことがあります。一時停止に入らない理由はインスタンスのログに出ます。12:21 に最小 ACU を 0 に戻してから、クラスタは接続が 0 本のまま 54 分以上、一時停止に入りませんでした。容量は 12:30 に 0.5 ACU まで下がり、そのまま 0.5 ACU にとどまっています。インスタンスのログ instance/instance.log には、10 分ごとに次の行が出ていました。
2026-10-01T03:30:58,789 [INFO] Auto-pause blockers registered since 2026-10-01T03:20:58.195Z: database activity before auto-pause timeout, continuous backup lag, service or customer maintenance action
時刻は UTC で、日本時間では 12:30 です。一時停止しなかった理由として、停止までの猶予中のデータベースの動き、継続バックアップの遅れ、サービスまたは利用者による保守の操作、の 3 つが記録されています。
一時停止しなかった理由がこのログに記録されることは、公式ドキュメントにも書かれています5。同じページには、管理操作で再開したあとは少なくとも 20 分は一時停止しないという記述もあります5。「service or customer maintenance action」を含む行は 9 行ありました。クラスタを作った直後の 1 行を除く 8 行は、どれも最小 ACU を変更してから 20 分以内の記録です。ただし、同じ行は 14:06〜14:15 の変更のあとには出ておらず、変更のたびに必ず出るわけではありませんでした。ログは 10 分ごとにまとめて出るので、時刻は 10 分の単位でしか分かりません。最小 ACU の変更に、この 20 分の規定が当てはまった可能性があります。「continuous backup lag」と「database activity before auto-pause timeout」は、接続が 0 本の時間帯にも出続けていました。この 2 つの理由が何によるものかは、今回は調べていません。
このクラスタはその後、14:26 には一時停止に入っていました。最小 ACU を引き上げてから 0 に戻しても、すぐには一時停止しない場合があります。料金の面では、戻したあとしばらくは 0.5 ACU 以上の課金が続くと見込んでおく必要があります。
7. まとめ
「1 秒で最大 16 ACU を追加」という増え方は、最小 ACU を引き上げたときに確認できました。一時停止していない 0.5 ACU の状態から引き上げると、6〜15 秒後に 16.5 ACU まで増えています。再開直後に負荷をかけた場合も、スケールアップが始まってから 16 ACU を超えるまでは 8〜10 秒でした。
一方で、再開直後に容量が 2.0 ACU から変わらない時間は、8 回すべてにありました。8 接続では 48〜50 秒で、前回の記事より約 10 秒短くなっています。128 接続では 77〜82 秒の回と 173〜184 秒の回に分かれました。長い回はどちらも、直前に 128 接続の負荷をかけた回でした。ただし、この日の最後の 2 回でもあり、何が長くしたのかは切り分けられていません。ゼロスケールで再開直後に突発的なアクセスを受ける使い方では、2.0 ACU のままの時間を前提に設計する必要があります。応答性が必要なら最小 ACU を 0 以外にする、という前回の記事の結論は変わりません。
再開直後の突発的なピークに必要な容量は、負荷で上がるのを待っても間に合いません。必要な容量は前もって確保しておく必要があります。常に備えるなら最小 ACU を 0 以外にして一時停止させない、時刻が決まっているなら 3〜5 分前に最小 ACU を引き上げる、のどちらかです。ただし最初の 1 秒の増加量は +6.5〜+16.0 ACU でばらつき、その先は 1 分に約 5〜8 ACU のペースでした。一時停止中に引き上げた場合は、再開後 43〜45 秒は 2.0 ACU のままです。
なお前回の記事では、この 2.0 ACU のままの時間がメトリクスの見え方によるものでないことを、DB 内部の shared_buffers とスループットでも確かめました2。今回は DB 内部の観測はしておらず、スループット（pgbench）の変化が容量の変化と同じ時刻に起きることだけを確かめています。
参考
-
Amazon Aurora serverless now scales faster to support agentic AI and other bursty workloads（AWS What's New。2026 年 9 月 30 日掲載。日本語版のページも 2026 年 10 月 1 日時点では英語の本文） ↩ ↩2 ↩3 ↩4
-
Aurora Serverless の「1 秒で 12 ACU」を、設定変更と実負荷の 2通りで計測する（前回の記事。4.1 章の分布と偏り、5.5 章の最小 ACU の引き上げ、5.7 章の DB 内部での裏取り） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
Amazon CloudWatch の概念（CloudWatch ユーザーガイド。「メトリクスの保持」節。「期間が 60 秒未満のデータポイントは、3 時間使用できます」） ↩
-
Aurora serverless の仕組み（Aurora ユーザーガイド。「Aurora serverless でのスケーリング」節。英語版 How Aurora serverless works の Scaling 節も同じ記述） ↩ ↩2
-
Aurora serverless の自動一時停止と再開によるゼロ ACU へのスケーリング（Aurora ユーザーガイド。「自動一時停止した Aurora serverless インスタンスの再開」「Aurora serverless が自動一時停止しない状況」「自動一時停止中の Aurora serverless クラスターのメンテナンスとアップグレードの仕組み」節） ↩ ↩2 ↩3 ↩4
-
Aurora Serverless v2 のゼロスケール再開時間を Platform Version 4 で再計測してみた（前々回の記事。接続が返るまでの時間） ↩
-
Aurora serverless でのパフォーマンスとスケーリング（Aurora ユーザーガイド。「クラスターに Aurora serverless の最小容量設定を選択する」節） ↩ ↩2