LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

固定インスタンスのDBコストが無駄になりやすいケース：負荷変動・検証環境・断続利用

Aurora Serverless v2への移行でDBコストを最適化するとは、固定インスタンスでは避けられないアイドル時間のコンピュート課金を、ACU（Aurora Capacity Unit）自動スケールと自動一時停止によって削減し、使用量に応じた課金に切り替えていく取り組みを指します。

固定インスタンス（例：db.r6g.large 等のプロビジョンドクラスター）は、設定したインスタンスタイプの料金が稼働時間に応じて発生します。負荷がゼロに近い夜間・休日も課金が継続するため、利用時間が偏っているシステムでは支払いに対する実質的なコンピュート利用率が低くなりやすいです。

特にコスト上の無駄が生じやすいのは、次の3つのケースです。

• 負荷が時間帯・曜日で大きく変動するシステム：日中のアクセス集中と夜間の閑散期でリソース需要が数倍以上開くと、ピーク対応サイズのまま低負荷時間帯も課金が発生します。
• 開発・検証・ステージング環境：平日の業務時間のみ使用するケースが多く、週末・夜間は接続がほぼゼロになります。固定インスタンスでは月内の実際の稼働率が低くても課金額は変わりません。
• 社内ツール・バックオフィス系アプリ：営業時間内のみ利用され、夜間は無人になるシステムです。常時起動が前提の構成では、アイドル時間のコストが積み重なります。

これらのケースでは、Aurora Serverless v2への移行によってコンピュート課金を使用実態に近づけられる可能性があります。ただし、移行の効果はワークロードの特性に依存するため、まず現状の利用パターン分析が出発点になります。

Aurora Serverless v2の仕組み：ACU自動スケール・ゼロキャパシティ・上限256 ACU

Aurora Serverless v2（ACU自動スケール）とは、Amazon Auroraのコンピュートリソースを需要に応じてACU（Aurora Capacity Unit）単位で自動的に増減させるサーバーレス構成オプションです^*1。固定インスタンスタイプを事前に選択する必要がなく、秒単位で容量が調整されます。

ACU（Aurora Capacity Unit）の仕組み

ACUはAurora Serverless v2のコンピュートリソースを表す単位で、1 ACUはおおよそ2 GiBのメモリとそれに対応するCPU・ネットワーク帯域から構成されます^*1。クラスターの最小ACUと上限ACUを設定すると、Auroraが実際の接続数やクエリ負荷に応じてACUを動的に調整します。

上限はクラスターあたり256 ACUまで設定できます^*1。通常のWebアプリケーションや中規模のOLTPワークロードではこの上限に達するケースは少ないですが、大量の同時接続や重いバッチ処理が集中する構成では設計時に確認が必要です。

ゼロキャパシティ（自動一時停止）と再開

AWS公式によると、2024年にAurora Serverless v2はゼロキャパシティ（0 ACU）対応を追加しました^*2。接続が一定時間ない場合にクラスターが自動的に一時停止し、コンピュート課金が発生しなくなります（ストレージ課金は継続）。アイドル判定の時間は300秒（5分）〜86400秒（24時間）の範囲で設定できます^*1。

次に接続要求が来ると Aurora Serverless v2 が自動で再開します。再開にかかる時間は十数秒程度が目安ですが、構成によって変動します^*1。再開遅延が許容できないケース（リアルタイムAPIの初回レスポンス要件が厳格な場合など）では、ゼロキャパシティを有効にするかどうかを慎重に判断する必要があります。

対応エンジンバージョンの要件

ゼロキャパシティを利用するにはAurora側のエンジンバージョンが必要です。AWS公式によると、Aurora PostgreSQL 13.15以降・14.12以降・15.7以降・16.3以降、Aurora MySQL 3.08以降などが対応しています^*1。詳細な要件は定期的に更新されるため、実際の構成検討時はAWS公式ドキュメントの最新情報をご確認ください。

移行・最適化の考え方：適性ワークロード・ACU設計・Savings Plans活用

Aurora Serverless v2に適性のあるワークロード

Aurora Serverless v2が費用対効果を発揮しやすいのは、コンピュートリソース需要が「断続的」または「変動幅が大きい」ワークロードです。具体的には以下のような特徴を持つシステムが候補になります。

• 開発・テスト・ステージング環境：業務時間外はほぼ接続がなく、ゼロキャパシティとの相性が高いです。
• バッチ処理専用DB：定時実行後に長時間アイドルになる構成で、実行時間だけ課金される利点があります。
• アクセスが時間帯に偏るWebアプリ：日中ピーク・深夜閑散のパターンが明確な場合、ACU自動調整でピーク追従と低負荷時の節約を両立できます。
• 社内ツール・管理画面：営業時間内のみ使用するシステムで、夜間・休日の課金を抑えられます。

一方、常時高負荷・ミリ秒単位のレスポンス要件がある本番OLTPや、常時大量接続を維持するシステムは、プロビジョンドクラスターとの比較検討が必要です。

最小ACUと上限ACUの設計

最小ACUを低く設定するほどアイドル時のコンピュート課金は抑えられますが、急激な負荷増加への対応速度に影響することがあります。一方、上限ACUを高く設定するとピーク対応力は上がりますが、課金の上限も上がります。現状のCPU使用率・接続数・レスポンスタイムの実績値を分析し、適切なレンジを設定することが重要です。

チューニングの基本的なアプローチは、まず余裕を持った最小/上限ACUで稼働させ、CloudWatch（AWSのモニタリングサービス）でACU推移を観測した後に最小値を下げていく段階的な絞り込みです。一度の設定で最適化が完了するケースは少なく、観測→調整のサイクルが必要です。

Database Savings Plansの活用

AWS公式によると、Database Savings Plans（2025年に発表）はAurora Serverless v2も対象で、1年コミットで約35%の割引が見込める場合があります^*3。条件・割引率はAWSの定めにより変動するため、最新情報はAWSコスト管理コンソールのSavings Plans画面でご確認ください。

Savings PlansはACU使用量の一定部分をコミットして割引を受ける仕組みです。常時稼働している読み取りレプリカや、最小ACUを一定水準に設定しているクラスターでは、コミット量の見積もりが立てやすくなります。ゼロキャパシティ（自動一時停止）を多用するケースでは、コミット量の算出を慎重に行う必要があります。

移行の進め方：現状分析→適性判断→ACU設定→検証→本番→モニタリング

ステップ1：現状の利用状況を可視化する

移行検討の出発点は、現行DBの利用パターン分析です。CloudWatchメトリクスから過去数週間〜1か月分のCPU使用率・DBConnection数・期間あたりのアクティブ時間帯を取得します。アイドル時間の割合・ピーク時と閑散時のリソース需要差が分かると、Aurora Serverless v2の適性判断に必要な材料が揃います。

この段階で「ほぼ常時高負荷でアイドルがほとんどない」ことが判明した場合は、Aurora Serverless v2への移行よりも Savings Plans やリザーブドインスタンスとの組み合わせを先に検討する方が合理的です。

ステップ2：適性判断とエンジンバージョン確認

利用パターン分析の結果をもとに、Aurora Serverless v2の適性を判断します。ゼロキャパシティを活用したい場合は、現行エンジンバージョンが要件を満たしているかを確認します。

Aurora PostgreSQL 13.15以降・14.12以降・15.7以降・16.3以降、Aurora MySQL 3.08以降が対応していますが^*1、要件は更新されることがあるためAWS公式ドキュメントを参照してください。バージョンが要件を下回る場合はアップグレードが先行作業になります。

ステップ3：最小ACU・上限ACU・アイドル時間の設定値を決める

現状分析で得た接続数・CPU使用率の実績値から、最小ACUと上限ACUの初期値を仮設定します。最小ACUを0（ゼロキャパシティ有効）に設定する場合は、再開遅延（十数秒程度が目安）を受け入れられるシステムかどうかの要件確認が必要です。

アイドル判定時間（300秒〜86400秒）は、利用パターンに合わせて設定します。業務時間のみ利用の社内ツールであれば短め（例：600〜1800秒）でもよく、夜間バッチ間隔が長いケースでは長め（例：3600秒以上）にする設計も考えられます。

ステップ4：検証環境で動作確認と負荷テストを行う

本番切り替えの前に、検証環境でAurora Serverless v2の挙動を確認します。再開遅延・ACU推移・コネクションプーリング（RDS Proxyの要否）などを検証し、アプリケーション側に接続タイムアウト設定の調整が必要かを確認します。

負荷テストでピーク時のACU消費量を計測しておくと、上限ACUの適正化に役立ちます。テスト中に上限ACUに達していないか・最小ACUが低すぎてスケールアップに時間がかかっていないかを CloudWatch で観測します。

ステップ5：本番切り替えとモニタリング

検証が完了したら本番クラスターをAurora Serverless v2に移行します。新規クラスター作成後にスナップショットからリストアする方法と、Blue/Greenデプロイメントを用いた方法があります。ダウンタイム許容・切り戻し方針は事前に決めておくことが重要です。

本番稼働後は数週間単位でACU推移・コスト変化を観測します。最小ACUを段階的に下げながら、レスポンスタイムへの影響がないかを確認する継続改善サイクルを設けると、コスト最適化の精度が高まります。

外注の使いどころ：適性診断・移行設計・チューニングの委託判断軸

内製で対応する際に必要なスキルと工数の目安

Aurora Serverless v2への移行を内製で行うには、少なくともAWS RDS/Auroraの運用知識・CloudWatchによるメトリクス分析・データ移行設計・アプリケーション接続設定の変更に対応できるエンジニアが必要です。加えて、ゼロキャパシティやACU設定の仕様理解・RDS Proxyの設計・本番切り替え時のロールバック計画まで含めると、DBとインフラ両方の知見が求められます。

現状分析から本番切り替えまでの工程を1〜2名体制で進めた場合、調査・設計・検証・本番移行・初期モニタリングを合わせて数週間〜数か月の期間を要するケースがあります（システム規模・既存構成の複雑さによって変動します）。DB移行の経験が社内にない場合、設定ミスによる本番障害や移行後の性能劣化リスクが高まります。

外注が有効なシーン

次のいずれかに当てはまる場合は、外注による支援を検討する価値があります。

• 適性診断の客観的判断が必要なとき：現行DBがAurora Serverless v2に向いているかどうかを、CloudWatchデータの分析と費用シミュレーションをセットで判断してほしいケースです。
• 移行設計・RDS Proxy設計まで任せたいとき：コネクションプーリング要否・Blue/Greenデプロイメントの設計・切り戻し手順まで含めた移行設計を依頼したい場合です。
• 本番切り替え後のチューニングを継続委託したいとき：最小ACUの絞り込みや Database Savings Plans の適用タイミングなど、移行後の継続的なコスト最適化を支援してほしい場合です。
• 社内にAurora移行の知見がないとき：初めてAuroraを扱うチームや、DB専任エンジニアが不在の情シス環境では、移行失敗による本番障害リスクを外注で低減できます。

委託範囲の切り方と契約形態

外注の範囲は「現状分析・適性診断のみ」から「本番移行・初期チューニングまで一括」まで段階的に設定できます。まず適性診断を成果物付きの請負で依頼し、結果に応じて移行設計以降を追加委託する進め方が、費用リスクを抑えつつ専門知見を活用しやすい構成です。

継続的なACUチューニングやモニタリング支援が必要な場合は、準委任契約（技術者が業務を遂行し成果を問わない形態）が適しています。契約前にスコープ・成果物・対応範囲を文書で明確にすることが、後工程でのトラブル回避につながります。

まとめ：Aurora Serverless v2移行でコスト最適化する3つの判断軸

本稿では、固定インスタンスのDBコストが無駄になりやすいケースから始まり、Aurora Serverless v2の仕組み・移行の進め方・外注の使いどころまでを整理しました。要点を3つに集約すると次の通りです。

第一に、Aurora Serverless v2への移行が費用対効果を発揮するのは「断続的・変動の大きいワークロード」です。常時高負荷のシステムや再開遅延を許容できない用途では、移行前に適性をしっかり見極める必要があります。第二に、ゼロキャパシティ・最小ACU設定・Database Savings Plansの3つを組み合わせることで、コスト削減の余地を広げられますが、それぞれ対応エンジンバージョン・再開遅延・コミット量の見積もりという固有の留意点があります。第三に、現状分析から本番切り替え・継続チューニングまでの工程は、Aurora移行の経験があるエンジニアに委託することでリスクと工数の両方を抑えられます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「Using Amazon Aurora Serverless v2」（Aurora User Guide、2024年）
2. *2　出典：Amazon Web Services「Amazon Aurora Serverless v2 supports scaling to zero capacity」（AWS What’s New、2024年）
3. *3　出典：Amazon Web Services「AWS Savings Plans Pricing」（AWS公式、2025年）

Tweet