Amazon Aurora Serverless v2はゼロキャパシティへのスケーリングをサポートし、データベース接続をベースとした一定期間の非アクティブ後にデータベースが自動的に一時停止するようになると発表した。Auroraのオンデマンド自動スケーリング設定にゼロキャパシティへのスケーリング機能がないことは長年にわたって論争の的となっていた。
AWSのシニアデータベーススペシャリスト・ソリューションアーキテクト Jason Pedreza氏とAWSのプロダクトマネージャーAnum Jang Sher氏は説明する：
自動一時停止・再開機能は、厳格なサービスレベル目標を持たないアプリケーションのコスト管理に役立ちます。約15秒の再開時間を許容できるワークロードの場合、次のようなケース：開発やテストに使われるクラスター、データベースがレジュームする間のコールドスタートが許容されるアプリケーション、でこの機能を利用できます。
4年前のre:Inventでプレビュー版として発表され2023年春から一般利用が可能になったAurora Serverless v2は当初、最小容量0.5ACUを必要としていた。1ACUは約2GiBのメモリとそれに対応するCPUおよびネットワークリソースに相当する。
典型的な再開時間が約15秒かつ接続要求はデータベースインスタンス再開が完了した後に確立されるため、クラウドプロバイダーはクライアントのタイムアウト設定（JDBCドライバーのconnectTimeoutや sslResponseTimeoutなど）をこの時間を超えるように構成することを推奨している。「Pre:Invent」の発表を振り返り、Ampt共同設立者でサーバーレス・ニュースレター Off-by-none の執筆者 Jeremy Daly氏は こうコメントしている：
おそらく最も大きな発表のひとつは Amazon Aurora Serverless v2がゼロキャパシティへのスケーリングをサポートしたことでしょう。これはv1では利用可能で開発環境には最適な選択肢でしたが、v2が発表されると選択肢ではなくなっていました。まだ15秒のコールドスタートがありますが、非常に予測可能なトラフィックパターンがない限り、これを本番環境で有効にすることはお勧めしません。
今年初頭にAWSはAurora Serverless v1の廃止を発表した。コミュニティからの主な不満は、AWS上のマネージド・リレーショナル・データベースに"scale to zero "オプションがないことだった。
SecondsUntilAutoPauseプロパティはデータベースインスタンスが一時停止する前にオープンな接続がない状態でどれぐらいの時間待つ必要があるか、最小値5分（デフォルト）、最大値1日の間で決定する。AWSは、Aurora Serverless v2インスタンスが再開する時、その初期容量は一時停止する前よりも小さくなる可能性があると警告している。また、Aurora Serverless v2と廃止されたAurora Serverless v1では、自動一時停止動作に顕著な違いがある。さらに、RDSプロキシやクラスター内のデータベースインスタンスへのオープンな接続を維持するプロキシを使用している場合などの特定のシナリオではACUゼロへのスケーリングができない。
ドキュメントによるとデータベース一時停止中に新しい接続が要求された場合、自動的に再開し、アプリケーションの需要に合わせてスケーリングされる。自動一時停止機能が有効な場合でもクラスターの手動停止と起動は可能だが、 一時停止中のインスタンスは再起動時に自動的に再開される。Yan Cui氏が「ついにその名に恥じないものになった！」と書く一方で、 Duckbill Groupのチーフ・クラウド・エコノミスト Corey Quinn氏はコメントしている：
何年もそれに抵抗し、自社の歴史を修正しようと試みて失敗した後、Amazonはサーバーレスが実際には「ゼロにスケールする」という意味だと認識するようになった。
AWSは、Aurora Serverless v2の自動一時停止機能について、いくつかのアプリケーション設計上の注意点を強調している。接続ロジックを実装する際には、初回の接続試行がエラーを返した場合に接続をリトライすることを推奨している。加えて、アプリケーションはデータベースへのオープン接続を持ったクライアントセッションやプログラミングツールを放置することを避けるべきである。
ゼロキャパシティへのスケール機能は、現在Aurora PostgreSQLバージョン13.15+、14.12+、15.7+、16.3+、およびAurora MySQLバージョン3.08+でサポートされている。