--- title: "Amazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説" url: "https://www.issoh.co.jp/tech/details/4586/" published: 2024-12-20 updated: 2026-08-11 categories: ["データベース"] publisher: "株式会社一創" --- # Amazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説 Amazon Aurora Serverless v2は、負荷に応じてデータベースの計算能力を自動で増減させるAuroraの構成オプションです。リレーショナルではなくドキュメント指向のマネージドデータベースを検討する場合は、[Amazon DocumentDBとは何かを解説した記事](https://www.issoh.co.jp/tech/details/15445/)もあわせて確認してください。容量はACU（Aurora Capacity Unit）という単位で0.5刻みに調整され、2024年11月からは最小0 ACU、つまり無アクセス時に計算コストをゼロまで落とす「スケールトゥゼロ」に対応しました。旧構成のAurora Serverless v1は2025年に提供を終了しており、これから採用・移行を検討するならv2が前提になります。本記事はACUと料金の仕組み、v1からの移行、対応エンジンバージョン、作成手順、そしてv2が向く場面と避けるべき場面までを、公式の一次情報にもとづいて整理します。リレーショナルではなくワイドカラム型のマネージドDBを探す場合は、[Amazon Keyspacesとは何かを解説した記事](https://www.issoh.co.jp/tech/details/15449/)が別方向の選択肢になります。 ## まとめ：Aurora Serverless v2の要点 - 容量はACU単位で自動スケール。**1 ACU ≈ 2 GiBメモリ**、**0.5 ACU刻み**、上限は**256 ACU（約512 GiB）**。 - 最小0 ACU（スケールトゥゼロ）に対応。無トラフィックが続くと自動一時停止し、次の接続で**約15秒**で再開する。 - 課金は割り当てACUの**秒単位**。一時停止中も**ストレージ課金は継続**する（計算だけ止まる）。 - Aurora Serverless v1は提供終了。新規作成は不可で、既存クラスターはv2へ自動アップグレードされる。 - アクセスが変動・断続する用途に向く。常時高負荷ならプロビジョンド構成のほうが安いことがある。 以下でACUの考え方から料金、移行、向き不向きまで順に見ていきます。 ## Aurora Serverless v2の仕組みとACU（キャパシティの考え方） Aurora Serverless v2は、CPUとメモリのセットをACUという抽象単位でまとめ、稼働中の負荷に合わせて割り当て量を自動で変えます。インスタンスクラスを固定するプロビジョンド構成と違い、需要が上がれば容量を足し、下がれば削るため、キャパシティ設計を「最小ACU」と「最大ACU」の範囲指定だけに単純化できます。 ### ACUの基本と0.5刻みスケール（1 ACU=2 GiB） 1 ACUはおよそ2 GiBのメモリと、それに対応するCPU・ネットワーク能力の組です。スケールは0.5 ACU単位で細かく動くため、2 ACUから4 ACUへ一気に飛ぶのではなく、2.5・3.0・3.5と負荷に追随してなめらかに増減します。これにより、急なアクセス増でも段階的に容量を追加でき、過剰割り当てによる無駄を抑えられます。 ### 最小0 ACUへのスケール（自動一時停止と再開） 最小容量に0 ACUを指定すると、一定時間アクセスが無いときにデータベースが自動で一時停止します。停止までの無トラフィック待機時間は300秒（5分）から86,400秒（24時間）の範囲で設定でき、停止中は計算コストが発生しません。次にアプリケーションが接続すると約15秒で再開します。この15秒程度の再開遅延（コールドスタート）を許容できるかが、0 ACU採用の分かれ目です。開発・検証環境やアクセスが夜間に途絶えるサービスでは大きな節約になりますが、レイテンシに厳しい本番APIでは最小を0.5 ACU以上にして常時起動を保つ判断もあります。計算容量を完全に停止して数百ミリ秒で復帰させる方式と見比べたい場合は、[サーバーレスPostgresのNeonにおける停止設定と課金](https://www.issoh.co.jp/tech/details/16444/)もあわせて確認すると判断しやすくなります。 ### 最大256 ACUまでのスケール範囲の決め方 最大容量は256 ACU（約512 GiBメモリ相当）まで指定できます。最小と最大の幅を広げるほど自動スケールの余地は増えますが、最小ACUを高く設定するとアイドル時も常にその分課金される点に注意が必要です。実務では、平常時のメモリ使用量から最小ACUを見積もり、ピーク時のバッファとして最大ACUに余裕を持たせるのが基本になります。最小ACUが低すぎるとスケールアップが間に合わずスロットリングの原因になるため、ワークロードのメモリ下限を下回らない値を選びます。 ## Aurora Serverless v1との違いとv1提供終了への対応 「Serverless」という名前は同じでも、v1とv2は内部アーキテクチャが別物です。これから使うならv2一択で、v1は移行の対象として理解しておけば十分です。 ### v1とv2の主な違い | 観点 | Serverless v1 | Serverless v2 | | --------------- | -------------- | ---------------------- | | スケール単位 | 倍々（2→4→8…）で不連続 | 0.5 ACU刻みで連続的 | | スケール速度 | 数十秒〜分単位で断続 | 秒単位で即応 | | 0容量への停止 | 対応（休止あり） | 対応（最小0 ACU・GA 2024-11） | | マルチAZ / リードレプリカ | 非対応 | 対応 | | 提供状況 | 提供終了 | 現行 | v1は容量を倍々でしか変えられず、スケール中に短い中断が起きることもありました。v2は0.5 ACU刻みで即座に追随し、マルチAZ配置やリードレプリカ、Data APIといったプロビジョンド構成と同等の機能を使えます。可用性と応答性のどちらもv2が上回るため、機能面での比較検討はほぼ不要です。 ### v1の提供終了スケジュールと自動アップグレード Aurora Serverless v1はすでに提供を終了しています。2025年1月8日以降はマネジメントコンソール・CLIとも新規のv1クラスターやインスタンスを作成できません。さらに2025年4月7日以降、稼働中のv1クラスターは次回のメンテナンスウィンドウでAurora Serverless v2へ自動的にアップグレードされます。v1を運用中であれば、自動アップグレードを待つ前に検証環境で互換性（対応エンジンバージョン・接続まわり・最小/最大ACUの設定値）を確認しておくと、想定外の挙動を避けられます。 ## Aurora Serverless v2の料金とコスト最適化 Serverless v2のコストは「割り当てられたACU量 × 稼働時間」で決まります。使った分だけ払えるのが利点ですが、設定次第では固定インスタンスより高くつくため、課金の内訳（ACU秒課金とストレージ別枠）を先に押さえておきます。 ### ACU課金の仕組み（秒単位・ストレージは別枠） 計算料金は、その時点で割り当てられているACUに対して秒単位で発生します。単価はリージョンで異なり、たとえば米国東部（バージニア北部）ではおおむね1 ACUあたり時間0.12 USD、東京リージョンはこれより高めです（正確な単価はAWSの料金ページで確認してください）。計算料金とは別に、保存しているデータ量に応じたストレージ料金とI/O料金がかかります。0 ACUで一時停止していてもストレージ料金は止まらないため、コスト試算で見落としやすい部分です。 ### 最小ACUが生む「フロアコスト」と0 ACUの節約効果 最小ACUを0.5に設定すると、アイドル時でも常に0.5 ACU分の計算料金が発生し続けます。これが月額の下限（フロアコスト）になります。アクセスが途切れる時間帯が長いワークロードでは、最小を0 ACUにしてスケールトゥゼロを効かせると、この下限を実質ゼロまで削れます。一方、24時間トラフィックが絶えない本番システムでは0 ACUの恩恵はほとんど無く、むしろ頻繁な一時停止・再開がユーザー体験を損なうため、最小ACUを実負荷に合わせて上げるほうが合理的です。 ### 最小・最大ACUの実測ベース設定（環境別の切り分け） 過剰な最大ACUは、想定外の負荷スパイクで高額請求につながります。まずは一定期間プロビジョンド構成やモニタリングで平常時とピーク時のメモリ使用量を把握し、最小・最大ACUを実測値の範囲に収めるのが基本です。開発・ステージング環境は最小0 ACU＋短い一時停止待機時間、本番はコールドスタートを避ける最小ACUと、環境ごとに設定を分けると無駄を減らせます。 ## 対応データベースエンジンと必要バージョン Serverless v2はAurora MySQL互換・Aurora PostgreSQL互換の両方で使えますが、機能ごとに必要な最小エンジンバージョンが異なります。とくにスケールトゥゼロは比較的新しいバージョンが前提です。 ### Aurora MySQL / PostgreSQLの対応バージョン Serverless v2はAurora MySQL（MySQL 8.0互換）とAurora PostgreSQLの近年のメジャーバージョンで利用できます。採用時は、使いたいエンジンバージョンがServerless v2に対応しているかをAWS公式の対応表で確認します。Aurora MySQLのバージョン選定やサポート期限については、[Aurora MySQL 8.4の全体像と移行を検討する読者が押さえる前提](/tech/details/12354/)もあわせて参照すると、エンジン側の前提を押さえられます。 ### 0 ACU（スケールトゥゼロ）に必要な最小バージョン 最小0 ACUを使うには、対応バージョンが限られます。Aurora MySQLは3.08.0以上、Aurora PostgreSQLは13.15・14.12・15.7・16.3以上が必要です。これらより古いバージョンでは最小容量は0.5 ACUが下限になり、スケールトゥゼロは選べません。0 ACUによる節約を前提に設計する場合は、まずエンジンバージョンがこの条件を満たしているかを最初に確認してください。 ## Aurora Serverless v2の始め方（クラスター作成の手順） Serverless v2は独立したサービスではなく、Auroraクラスター内のインスタンスのキャパシティタイプとして選びます。作成の流れはプロビジョンドAuroraとほぼ同じで、キャパシティ設定だけがACU範囲の指定に変わります。 ### 事前準備（VPC・サブネットグループ・セキュリティグループ） Auroraはプライベートネットワーク内に配置するのが基本です。事前に、2つ以上のアベイラビリティゾーンにまたがるサブネットを含むDBサブネットグループ、データベースへのアクセス元を絞るセキュリティグループ（例：アプリケーションサーバーのセキュリティグループからの3306番/5432番のみ許可）を用意します。マルチAZ構成を組む場合は、複数AZにサブネットが存在することが前提になります。 ### Serverless v2インスタンスの作成とキャパシティ設定 RDSコンソールでAuroraクラスターを作成する際、エンジンにAurora（MySQLまたはPostgreSQL）を選び、対応バージョンを指定します。インスタンス設定で「Serverless v2」を選ぶと、固定のインスタンスクラスではなく最小ACUと最大ACUを入力する形式に変わります。ここで最小に0を指定すればスケールトゥゼロが有効になり、あわせて一時停止までの待機時間を設定します。作成後は、アプリケーション側の接続がRDS Proxyやコネクションプールを介しているかも確認します。急な同時接続の増加はスケールと相性が悪いため、接続の集約が有効です。接続プールの考え方は[RDS Proxyとは？対応エンジン・料金・接続プールの仕組みと導入手順を解説](/tech/details/6798/)で詳しく扱っています。 ## Aurora Serverless v2を選ぶべきケースと避けるべきケース Serverless v2は万能ではありません。自動スケールと従量課金が効く場面でこそ価値が出ます。逆に、負荷が読めていて一定なら、あえてServerlessにする必要はありません。ここは実装前に必ず判断すべき論点です。 ### 変動・スパイク負荷で効くケース アクセスが時間帯やイベントで大きく変動するワークロードは、Serverless v2の最も得意な領域です。日中だけ使う社内システム、キャンペーンで瞬間的にアクセスが跳ねるサービス、テナントごとに利用時間が異なるSaaSなどは、需要に合わせて容量を上下させることで、ピークに合わせた固定インスタンスを常時抱える無駄を省けます。開発・検証環境も、最小0 ACUで夜間・休日のコストをほぼゼロにできます。 ### 常時高負荷・コスト逆転で不利なケース 24時間ほぼ一定の高負荷が続くワークロードでは、Serverless v2はプロビジョンド構成より割高になりがちです。同一メモリ量あたりの単価はプロビジョンド構成より高めのため（正確な比較はAWSの料金ページで確認）、常にフルにACUを使い続ける状態では、リザーブドインスタンスなどで固定契約したほうが安くなります。「サーバーレスだから常に安い」という前提で採用すると、負荷が平坦なシステムではコストが逆転します。レイテンシに極めて厳しく、コールドスタートの15秒すら許容できない本番APIも、最小0 ACUは避け、最小ACUを底上げする設計が必要です。 ### 大量同時接続とRDS Proxyの併用 Lambdaのような多数の実行環境から同時に接続が押し寄せる構成では、接続数がスケールの追随を上回り、接続枯渇やスロットリングを招くことがあります。この場合はRDS Proxyで接続をプールし、データベースへの実接続数を抑えるのが定石です。分散SQLで水平スケールとサーバーレスを両立したい場合は、Aurora Serverless v2とは設計思想の異なる選択肢として[Amazon Aurora DSQLの概要と基本概念についての説明](/tech/details/4487/)も比較対象になります。 ## よくある質問 ### Aurora Serverless v1とv2、どちらを使うべきですか？ v2です。v1は2025年に提供を終了し、新規作成はできません。既存のv1クラスターも順次v2へ自動アップグレードされるため、新規採用・移行検討はv2を前提にしてください。 ### 最小0 ACUにすれば完全に無料になりますか？ いいえ。一時停止中は計算料金が止まりますが、保存データに対するストレージ料金は継続して発生します。計算コストをゼロにできても、データベースの維持費が完全に無料になるわけではありません。 ### 一時停止からの再開（コールドスタート）はどれくらいかかりますか？ 0 ACUで一時停止した状態から次の接続で再開するまで、およそ15秒です。この遅延を許容できない用途では、最小ACUを0.5以上にして常時起動を保つ設計にします。 ### Aurora Serverless v2はMySQL 8.0に対応していますか？ 対応しています。Aurora MySQL互換（MySQL 8.0互換）で利用できます。ただしスケールトゥゼロ（最小0 ACU）にはAurora MySQL 3.08.0以上が必要です。使いたいバージョンがv2と機能に対応しているかは公式の対応表で確認してください。 ### スケールは瞬時に行われますか？ 0.5 ACU刻みで秒単位に追随します。ただし急激な同時接続の増加には追いつかないことがあるため、接続の集約（RDS Proxy等）や、余裕を持たせた最小ACUの設定で、スケール遅延によるスロットリングを避けます。 ## 関連記事 - [Aurora MySQL 8.4の全体像と移行を検討する読者が押さえる前提](/tech/details/12354/) - [RDS Proxyとは？対応エンジン・料金・接続プールの仕組みと導入手順を解説](/tech/details/6798/) - [Amazon Aurora DSQLの概要と基本概念についての説明](/tech/details/4487/) --- 出典: [Amazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説]()（株式会社一創）