Aurora Serverless v2の使い方｜ACUの決め方と0への自動停止

Aurora Serverless v2 は、Aurora の DB インスタンスの大きさ（CPU とメモリ）を、負荷に合わせて自動で増減させる仕組みです。 大きさの単位は ACU（Aurora Capacity Unit、約 2 GiB のメモリと、それに見合う CPU・ネットワーク）で、クラスターに「最小 ACU」と「最大 ACU」を決めます。最小を 0 にすると、接続が無い時間が続いたときにインスタンスが自動で一時停止し、その間のインスタンス料金が 0 になります。 次の接続で再開し、ドキュメントでは再開に約 15 秒（24 時間を超えて止まっていると 30 秒以上）かかるとされています。

# 最小 0 ACU（10 分接続が無ければ一時停止）〜 最大 8 ACU のクラスター
aws rds create-db-cluster --db-cluster-identifier app-db \
  --engine aurora-postgresql --engine-version 16.6 \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=8,SecondsUntilAutoPause=600 \
  --master-username postgres --manage-master-user-password \
  --db-subnet-group-name app-db-subnets --vpc-security-group-ids sg-0123456789abcdef0

# インスタンスクラスを db.serverless にしてライターを作る
aws rds create-db-instance --db-instance-identifier app-db-writer \
  --db-cluster-identifier app-db --engine aurora-postgresql --db-instance-class db.serverless

確認環境：AWS CLI 1.46.1・boto3 1.43.112（Linux）。AWS には接続せず、moto 5.2.4 のサーバーモードで create-db-cluster（--serverless-v2-scaling-configuration）・create-db-instance --db-instance-class db.serverless・modify-db-cluster の形を確かめました。接続の再試行は、PostgreSQL 16.15 と psycopg 3.3.6 を使い、「一時停止中の DB に接続すると再開まで待たされる」動きを 15 秒待たせる中継で模して動かしています。ACU・自動一時停止・再開の時間・料金は AWS のドキュメントと料金ページに基づいています（確認日 2026年10月13日）。

ACU とは：最小と最大の意味

ドキュメントでは「範囲は、エンジンの版とプラットフォームの版のうち低い方で決まる」とされています。プラットフォームの版 1 は 0〜128、版 2〜4 は 0〜256 です。エンジンを上げても最大が 128 のままなら、プラットフォームの版を確かめます。

最小 ACU の決め方

ドキュメントでは「最小は 0.5 にしたくなるが、よく使うデータの量に見合う大きさを選ぶ」と書かれています。プロビジョンドから移すなら、今のインスタンスのメモリを 2 GiB で割った値が最初の目安です（db.r6g.large の 16 GiB なら 8 ACU）。

最大 ACU の決め方と max_connections

最大 ACU は、負荷の上限であると同時に、max_connections（同時接続の上限）を決めます。 最大を変えたあとは、max_connections に反映させるために再起動が要ります（静的パラメータのため）。

PostgreSQL で最小を 0 か 0.5 にすると、max_connections は最大 2,000 で頭打ちになります。最大を 1〜4 にした小さなクラスターでは、MySQL で 90〜135 しか接続できません。 Lambda などから多く接続するなら、最大を上げるか、接続をまとめる仕組みを使います。PostgreSQL の接続数の見方は、関連記事「PostgreSQL接続数の確認｜pg_stat_activityの見方と対処」で扱っています。MySQL の接続数の上限に達したときは、関連記事「MySQL Too many connectionsの原因と直し方」で扱っています。

0 ACU への自動一時停止

止まる条件と止まらない原因

最小を 0 にし、ユーザーの接続が1つも無い状態が SecondsUntilAutoPause 秒続くと、インスタンスが一時停止します。 Aurora が健全性の確認に使う管理用の接続は数えません。

止まらない原因の一覧です（ドキュメント）。

ライターと、昇格の優先度（プロモーションティア）が 0・1 のリーダーは、同時に止まり、同時に再開します。 リーダーを独立して止めたいなら、優先度を 2〜15 にします。

ブログなどでは、Aurora MySQL の binlog_format を有効にしていたため止まらなかった例も報告されています。バイナリログのレプリケーションを使わないなら、クラスターパラメータグループで無効にしておきます。

再開のきっかけと時間

pg_cron や MySQL のイベントスケジューラーは、止まったインスタンスを起こしません。 夜間バッチを DB の中のスケジューラーで動かしているなら、外から接続して起こすか、最小を 0 にしません。外から決まった時刻に処理を動かす方法は、関連記事「EventBridge Schedulerの使い方｜cron・rate・1回実行」で扱っています。

止まっているかを確かめる

# 3 分間の最小値。0 なら一時停止していた時間がある
aws cloudwatch get-metric-statistics --namespace AWS/RDS \
  --metric-name ServerlessDatabaseCapacity \
  --dimensions Name=DBInstanceIdentifier,Value=app-db-writer \
  --start-time "$(date -u -d '3 minutes ago' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 60 --statistics Minimum --output text

# 一時停止・再開のイベント（RDS-EVENT-0370〜0374）
aws rds describe-events --source-type db-instance --source-identifier app-db-writer --duration 1440

接続コード：再開を待てるタイムアウトと再試行

ドキュメントでは、タイムアウトを再開の時間より長くし、失敗した接続を 3 回ほど再試行すること、ただし認証エラーは再試行しないことが勧められています。

import os, time, random
import psycopg

def connect_with_retry(dsn: str, *, connect_timeout=30, attempts=3):
    """自動一時停止からの再開（ふつう約 15 秒、長く止まると 30 秒以上）を待てる接続"""
    for i in range(1, attempts + 1):
        started = time.monotonic()
        try:
            conn = psycopg.connect(dsn, connect_timeout=connect_timeout)
            print(f"attempt {i}: connected in {time.monotonic() - started:.1f}s")
            return conn
        except psycopg.OperationalError as e:
            msg = str(e).strip().splitlines()[-1]
            print(f"attempt {i}: {type(e).__name__} after {time.monotonic() - started:.1f}s: {msg}")
            if "password authentication failed" in msg or i == attempts:
                raise                                   # 認証エラーは再試行しない
            time.sleep(min(2 ** i, 10) + random.random())

if __name__ == "__main__":
    dsn = os.environ["DSN"]   # host=app-db.cluster-xxxx.ap-northeast-1.rds.amazonaws.com dbname=app user=app ...
    ct = int(os.environ.get("CT", "30"))
    with connect_with_retry(dsn, connect_timeout=ct) as conn:
        print(conn.execute("select 1").fetchone())

PostgreSQL の前に「しばらく接続が無いと、次の接続を 15 秒待たせてから通す」中継を置いて動かした結果です（Aurora の再開を模したもので、実際の再開時間ではありません）。

== CT=30（タイムアウト 30 秒）
attempt 1: connected in 15.1s
(1,)
== CT=5（タイムアウト 5 秒）
attempt 1: ConnectionTimeout after 5.0s: connection timeout expired
attempt 2: ConnectionTimeout after 5.0s: connection timeout expired
attempt 3: connected in 0.0s
(1,)

タイムアウトが短くても、再試行の間に再開が終われば接続できました。ただし、再開の時間が「タイムアウト × 回数＋待ち時間」を超えると失敗します。Lambda や API の前段のタイムアウト（API Gateway の統合タイムアウトの既定 29 秒など）に収まるかも合わせて決めます。

接続プールは、使っていない接続を閉じる設定にします。 プールが最小数の接続を持ち続けると、ユーザーの接続があるとみなされ、一時停止しません。

プロビジョンドとの比較

同じ大きさで一日中動かすなら、プロビジョンドの方が安くなります。 料金ページの米国東部の単価（Aurora Standard）で比べると、次のとおりです。

平均の ACU が約 2.4 を下回るならサーバーレス、上回るならプロビジョンドが安い、という計算です（ストレージ・I/O は同じ）。db.r6i.large の単価は料金ページのグローバルデータベースの例の値です。

費用の計算例

料金ページの米国東部の単価です（東京リージョンの単価は料金ページ・料金計算ツールで確かめます）。

最小 0.5 で何もしなくても、ACU だけで月 40 USD を超えます。 開発環境を 0 ACU にすると、使わない時間のこの分がかかりません。ストレージ・バックアップ・I/O は止まっていてもかかります。費用の確認は、関連記事「AWSの料金を確認する方法｜Cost Explorer・CLI・予算アラート」で扱っています。

CLI での作成・変更

クラスターとライター

aws rds create-db-subnet-group --db-subnet-group-name app-db-subnets \
  --db-subnet-group-description "app db" --subnet-ids subnet-0aaa1111 subnet-0bbb2222

aws rds create-db-cluster --db-cluster-identifier app-db \
  --engine aurora-postgresql --engine-version 16.6 \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=8,SecondsUntilAutoPause=600 \
  --master-username postgres --manage-master-user-password \
  --db-subnet-group-name app-db-subnets --vpc-security-group-ids sg-0123456789abcdef0 \
  --storage-encrypted

aws rds create-db-instance --db-instance-identifier app-db-writer \
  --db-cluster-identifier app-db --engine aurora-postgresql --db-instance-class db.serverless

aws rds wait db-instance-available --db-instance-identifier app-db-writer

moto で作ると、create-db-cluster の応答に次の値が入りました。

"Endpoint": "app-db.cluster-dreumrh3ab80.ap-northeast-1.rds.amazonaws.com",
"ReaderEndpoint": "app-db.cluster-ro-dreumrh3ab80.ap-northeast-1.rds.amazonaws.com",
"Port": 5432,
"ServerlessV2ScalingConfiguration": {
    "MinCapacity": 0.0,
    "MaxCapacity": 8.0,
    "SecondsUntilAutoPause": 600
},
"MasterUserSecret": {
    "SecretArn": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:rds!cluster-086fb91d-...",
    "SecretStatus": "creating",

マスターパスワードの取り出し方は、関連記事「AWS Secrets Managerの使い方 CLI・boto3取得早見表」で扱っています。

範囲を変える・0 をやめる

# 自動一時停止を有効にする（1 時間）
aws rds modify-db-cluster --db-cluster-identifier app-db \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=16,SecondsUntilAutoPause=3600

# 0 をやめる（最小を 0 より大きくすると SecondsUntilAutoPause は消える）
aws rds modify-db-cluster --db-cluster-identifier app-db \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16 --apply-immediately

# 最大を変えたら、max_connections を反映させるために再起動
aws rds reboot-db-instance --db-instance-identifier app-db-writer

moto で通ったが、AWS では断られる値

moto はスケーリングの範囲を調べないので、値はドキュメントの範囲で決めます。クラスター・インスタンスの起動・停止・スナップショットの CLI は、関連記事「AWS CLIでRDSを操作｜起動・停止・スナップショット・接続先取得」で扱っています。

接続の注意

Lambda からの接続を RDS Proxy でまとめる方法は、関連記事「RDS Proxyの使い方｜LambdaからDB接続を安定させる設定」で扱っています。

よくある質問

Q. 0 ACU にしたのに止まりません。 A. まず pg_stat_activity（MySQL なら SHOW PROCESSLIST）で、自分の接続以外が残っていないかを見ます。接続プール、BI ツール、監視、ヘルスチェック、RDS Proxy、バイナリログのレプリケーションがよくある原因です。止まらない原因の表を順に確かめます。

Q. 既存のクラスターを 0 ACU にできますか。 A. エンジンが 0 ACU に対応した版（PostgreSQL 16.3・15.7・14.12・13.15 以上、MySQL 3.08.0 以上）なら、modify-db-cluster で MinCapacity=0 にできます。それより前の版なら、先にアップグレードします。

Q. Aurora Serverless v1 とは何が違いますか。 A. v2 は通常の Aurora クラスターのインスタンスクラス（db.serverless）として動き、リードレプリカ・マルチ AZ・プロビジョンドとの混在などが使えます。0 への一時停止も v2 で使えるようになりました（2024年11月の発表）。

Q. 再開中の接続はエラーになりますか。 A. ドキュメントでは、止まったインスタンスに接続すると自動で再開して接続を受け付けるとされています。タイムアウトが再開の時間より短いと、クライアント側でタイムアウトになります。

まとめ

• ACU は約 2 GiB のメモリと CPU。最小・最大の範囲で自動に増減し、秒単位で課金
• 最小は「よく使うデータがメモリに乗る大きさ」、開発は 0。最大は負荷と max_connections で決める
• 0 ACU は MySQL 3.08.0・PostgreSQL 16.3 などから。SecondsUntilAutoPause は 300〜86,400 秒
• 止まらない原因は 開いたままの接続・RDS Proxy・レプリケーション・グローバルデータベース
• 再開は約 15 秒（24 時間超で 30 秒以上）。接続タイムアウト 30 秒以上＋再試行、認証エラーは再試行しない
• 一日中同じ負荷ならプロビジョンドが安い（米国東部の単価で平均 約 2.4 ACU が分かれ目）

参考・出典

確認日はいずれも 2026年10月13日です。

• Amazon Aurora User Guide「Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2」：https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html
• Amazon Aurora User Guide「How Aurora Serverless v2 works」：https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html
• Amazon Aurora User Guide「Performance and scaling for Aurora Serverless v2」（最小・最大 ACU と max_connections）：https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html
• AWS CLI Command Reference「rds create-db-cluster」：https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html
• Amazon Aurora の料金：https://aws.amazon.com/rds/aurora/pricing/
• AWS What's New「Amazon Aurora Serverless v2 supports scaling to zero capacity」（2024年11月）：https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-aurora-serverless-v2-scaling-zero-capacity
• AWS Database Blog「Introducing scaling to 0 capacity with Amazon Aurora Serverless v2」：https://aws.amazon.com/blogs/database/introducing-scaling-to-0-capacity-with-amazon-aurora-serverless-v2/
• クラスメソッド「Amazon Aurora Serverless v2が最小キャパシティ0に対応し、自動停止・再開が可能になりました」：https://dev.classmethod.jp/articles/amazon-aurora-serverless-v2-supports-acu0-pause-resume/
• Zenn（team_delta）Aurora Serverless v2 が 0 ACU にならなかった事例（binlog_format）：https://zenn.dev/team_delta/articles/dd1372fa046af7

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。