サーバーレス DB は「停止中コストゼロ」が前提だが、監視クエリや接続プールが DB を起こし続けると provisioned（常時起動）より高くつく。課金の主役は保存容量ではなく**起きている時間（計算 vCore）**であり、稼働率が上がるにつれてコストが逆転する構造を持つ。Azure SQL Serverless と Amazon Aurora Serverless v2 の課金構造、稼働率 48% のクロスオーバー試算、keep-alive の正体と監査手順を整理する。

課金の主役は「起きている時間」

Azure SQL Database Serverless の課金は vCore 秒（per-second billing）単位で動く。DB が起きている間は vCore単価 × 使用vCore数 が積み上がり、停止中は計算コストがゼロになる。ストレージは起動・停止にかかわらず消費分だけ課金が続くが、実際の PoC 請求を分解すると計算 vCore が約 8 割、ストレージが約 1 割だった。節約効果の大半は「起きている時間を削る」ことで生まれる。

Amazon Aurora Serverless v2 も同じ構造で、$0.12/ACU-hour 課金・停止中は計算コストゼロ。2024 年 11 月からは最小 ACU を 0 に設定できるゼロスケール対応になり、完全停止によるコストゼロが可能になった。

Azure Cosmos DB は別モデル。 消費した RU（Request Unit: データ操作の処理量の単位）の実量に対して課金される（$0.25 / 100 万 RU）ため、接続がなければ RU 消費ゼロ = 請求ゼロとなる。自動一時停止の設定自体が不要で、以降で説明する keep-alive（DB を起こし続ける動作）の問題は Cosmos DB には直接当てはまらない。主軸は Azure SQL Serverless と Aurora Serverless v2 の話になる。

出典：Microsoft SQL Docs（MicrosoftDocs/sql-docs, 2026-07-14 取得） / Microsoft Learn - Azure Cosmos DB Serverless（2025）

自動一時停止のパラメータ：最小待機時間が閾値になる

パラメータAzure SQL ServerlessAurora Serverless v2
デフォルト待機時間60 分—
最小待機時間15 分5 分（300 秒）
最大待機時間10,080 分（7 日）86,400 秒（24 時間）
再起動時間（目安）—約 15 秒（24 時間超の深スリープ後は 30 秒以上の可能性）

出典：Microsoft SQL Docs（2026-07-14 取得）/ AWS Documentation（2024-11-20）

Azure SQL は「最後のアクセスから 15 分以内に次のアクセスが来ると一時停止できない」構造だ。15 分より短い間隔で定期的なアクセスが続くと、DB は事実上ずっと起きている状態になる。Aurora v2 は最小 5 分と短く、5 分以内の間隔でアクセスが来る環境では最小設定でも停止できない。

DB を起こし続けているのはこの 4 パターン

意図せず DB を稼働させ続ける主因は、以下 4 つに集約される。

  1. 監視 ping — Azure Monitor / CloudWatch の死活監視クエリ。「5 分ごとに SELECT 1」がそのまま keep-alive になる
  2. 日次ジョブ・スケジュールバッチ — 深夜の軽微なクリーンアップや集計処理
  3. 接続プール（Connection Pool）の維持 — Prisma / Entity Framework などの ORM（オブジェクト関係マッパー：DB 操作をコードで抽象化するライブラリ）がアイドル接続を保持し続ける
  4. オーケストレーターのヘルスチェック — Azure Logic Apps / AWS Step Functions が状態確認のために定期接続する

監視 ping は既存設定をそのまま流用することが多く、見落とされやすい。Azure SQL の最小待機 15 分より短い間隔（例：5 分ごと）で ping が飛ぶ設定になっていると、DB は一度も止まらない。

稼働率 48% でコストが逆転する（試算値）

Azure SQL の場合、サーバーレス単価は provisioned 単価の約 2 倍になる（東米リージョン・二次ソース引用の参考値）。

シナリオ（4 vCore・East US 試算）月額
Provisioned 常時稼働約 $736
Serverless 稼働率 100%約 $1,524
Serverless 稼働率 50%約 $762

ブレークイーブン稼働率 = Provisioned 時間コスト ÷ Serverless 時間コスト = $1.009 ÷ $2.087 ≈ 48%

稼働率が 48% を超えると provisioned の方が安くなる計算になる。この数値は Usage.ai / nOps の公開単価をもとにした試算値であり、公式ドキュメントに明示されたクロスオーバーラインではない。設定・リージョン・割引契約で変わるため、自分の構成での計算は公式 Azure Pricing（https://azure.microsoft.com/pricing/details/sql-database/single/）を参照する。

コールドスタートへの対処：keep-alive より構成変更を選ぶ

「コールドスタートのレイテンシが許容できないから keep-alive を入れた」という設計は、コスト的に割高になりやすい。Aurora v2 の再起動時間は通常 約 15 秒（24 時間超の深スリープ後は 30 秒以上の可能性あり）。この遅延がユーザー向けリクエストに直接影響するなら、keep-alive で回避し続けるより provisioned への移行の方が構造がシンプルになる。

keep-alive でコールドスタートを回避する設計は、稼働率が高まるにつれて provisioned 相当のコストをサーバーレスの割高単価で払い続ける結果になる。「コールドスタートが許容できない = keep-alive を入れる」ではなく、「コールドスタートが許容できない = provisioned に移行する」が判断の分岐点になる。

keep-alive 監査チェックリスト

「何が DB を起こしているか」を棚卸しする前に、まず発火源を 4 カテゴリで確認する。

監視設定

  • 監視 ping の間隔を確認する（Azure SQL は 15 分超・Aurora v2 は 5 分超で keep-alive が回避できる下限ライン）
  • 死活監視クエリをアプリ側ヘルスエンドポイントに切り替えられないか検討する

ジョブ・バッチ

  • スケジュールジョブの発火間隔を一覧化する
  • 深夜バッチが本当に DB への直接接続を必要とする処理かを確認する（ファイル処理やキュー処理であれば DB 不要な場合がある）

接続プール（ORM 設定）

  • アイドル接続タイムアウト設定を確認する
  • 接続プールの最小接続数がゼロになっているかを確認する（0 でないと常時接続が維持される）

オーケストレーター

  • Logic Apps / Step Functions のヘルスチェック定義を確認する
  • DB への直接 SELECT をアプリ側エンドポイントに振り替えられないかを検討する

サーバーレスを選ぶ条件、provisioned に移行する条件

状況判断
稼働率が低い（目安 50% 未満）かつコールドスタート許容サーバーレスのまま
稼働率が高い（目安 50% 超）または常時稼働provisioned に移行
コールドスタートが許容できないprovisioned に移行
マルチリージョン書き込みが必要（Cosmos DB）Serverless は単一リージョン制限あり・Provisioned を検討

判断の起点は稼働率の計測。Azure Monitor または CloudWatch のメトリクスで「過去 1 週間に DB が起きていた時間の割合」を確認するだけで、上の表に当てはめる根拠が手に入る。

まとめ

「サーバーレスは安い」は稼働率が低い場合にのみ成立する条件付きの命題だ。keep-alive の発火源を特定し、稼働率を計測すれば、provisioned と比較した判断が数字で出る。

次の一歩

  1. Azure Monitor または CloudWatch で「過去 7 日間の DB 稼働時間」を確認する
  2. 上記チェックリストで監視 ping・接続プール設定を棚卸しする
  3. 自分の構成の単価を公式 Pricing ページで当てて、稼働率 × 単価のクロスオーバーを計算する（Azure SQL：https://azure.microsoft.com/pricing/details/sql-database/single/）

関連記事