Azure SQL Database Serverlessの料金が高い原因と対策｜見積もりと請求がズレる仕組みを解説

Azure SQL Databaseを「開発」「汎用（General Purpose）– サーバーレス（Serverless）」で最安にしたつもりでも、請求が1日あたり数ドル〜数十ドルに跳ね上がることがあります。多くの場合、原因はServerlessの課金ロジック（Online中の下限課金）と、想定外の定期接続・機能設定です。見積もりと請求のズレを埋める確認ポイントと、すぐできる対策を具体的に解説します。

月額見積もりと請求額がズレる一番の理由

Azure SQL Database（単一データベース）のServerlessは、ざっくり言うと「使った分だけ課金」ですが、ここでいう“使った分”はクエリを投げた時間だけではありません。ポイントは、データベースがOnline（稼働）状態にいる時間には、実負荷が小さくても最小vCore/最小メモリ相当の下限が発生しうる、という点です。

そしてポータル作成画面に出る「月額見積もり」は、Serverlessの稼働時間（Onlineの時間）やvCoreの伸び方が環境によって変わるため、どうしても“理想条件”寄りの数字になりがちです。結果として、「月5ドルくらい」→「実際は1日20ドル」のようなギャップが起こります。

課金要素	いつ発生するか	見積もりとズレやすい理由
コンピュート（vCore秒）	DBがOnlineの間、秒単位で発生（下限あり）	「どれだけOnlineになるか」が運用次第で激変する
ストレージ	常時発生（Pausedでも発生）	「停止＝無料」ではない
バックアップ/保持系	保持期間や冗長化で増減	設定次第でストレージ課金が増える／Auto-pauseが使えない場合がある
周辺サービス（監査ログ等）	Log Analytics等に送ると別課金	SQL本体より周辺で膨らむケースがある

Serverlessの課金ロジックを押さえる

Microsoftの説明では、Serverlessはワークロードに合わせて自動スケールし、コンピュートを秒単位で課金します。さらに（General Purposeでは）アイドル時に自動一時停止（Auto-pause）して、停止中はコンピュートがゼロになり、ストレージだけ課金という設計です。

ただし、ここで重要なのが次の2点です。

• Onlineの間は「最低でもこのくらいは課金される」という下限がある
• Auto-pauseに入るまでの“待ち時間（Auto-pause delay）”もOnline扱いなので、その間は下限分が積み上がる

コンピュートは「CPU」と「メモリ」の大きい方が基準になる

Serverlessのコンピュート課金は単純な「vCore × 時間」ではなく、秒ごとにCPU使用量とメモリ使用量を見て、より大きい方（正規化後）で課金量が決まります。さらに、CPU/メモリが最小値を下回る場合でも最小vCore・最小メモリ相当の“プロビジョン分”が課金対象になります。

つまり、体感として「何もしてない」はずでも、Onlineの間は最小vCore/最小メモリの“アイドリング代”が発生し続けます。

Auto-pauseが成立する条件

「Auto-pauseを有効にしたのに止まらない」というときは、まず条件を疑うのが近道です。Auto-pauseは、Auto-pause delayの間ずっと次の条件を満たしたときに初めて発動します。

• セッション数が0（接続が残っていない）
• ユーザーのワークロードによるCPUが0

さらに、特定の機能を使っているとAuto-pauseそのものが使えない（= Online固定になる）ことがあります。たとえば、Geo-replication、長期バックアップ保持（LTR）、SQL Data Syncの同期DB、DNSエイリアス、Elastic JobsのジョブDBなどが該当します。

加えて、サービス更新の都合で一時的にAuto-pauseが抑止されることもあり得ます。

Auto-pause delayは「短くできるほど節約に効く」

昔の解説では「最短1時間」が前提になっているものも多いのですが、現在はAuto-pause delayの最小値が15分まで下がり、より早くPausedに入れて節約しやすくなっています。開発・検証環境では、この変更が効きます。

「ちょっと触っただけ」で一日中課金される典型パターン

Serverlessの落とし穴は、DBが「自動停止できる状態」に入るまでに、想像以上に条件が厳しいことです。たとえば次のような挙動が起こります。

• 開発者がSSMS/Azure Data Studioを開きっぱなし（Object Explorerが接続を維持）
• アプリのヘルスチェックが数分〜数十分おきに接続
• バッチやFunctionが「空振りでも接続だけ」している
• 監視・セキュリティ系が定期的にDBへアクセス

これらがあると、Auto-pause delayのカウントがリセットされ、DBはほぼ常時Onlineになりがちです。Onlineである以上、最小vCore/最小メモリ分の下限が秒課金で積み上がります。

症状	よくある原因	対処の方向性
何もしてないのに毎日課金	Auto-pauseに入れていない（定期接続 / セッション残り）	Activity logでResume要因を特定、接続元を止める
夜間もコンピュート課金が止まらない	Auto-pause delayが長い / 最小vCoreが大きい	Auto-pause delay短縮、最小vCoreを下げる
Auto-pauseが有効なはずなのにPausedにならない	Geo-replication / LTRなどでAuto-pause非対応	機能を見直す（開発環境なら無効化）

「1日20ドル」を簡易計算で現実に落とす

Serverlessの請求は、ざっくり次の式で概算できます。

概算コンピュート費 ＝ vCore単価（$/vCore/秒） × 課金対象vCore秒（vCore seconds）

課金対象vCore秒は、Azure Monitorのメトリックapp_cpu_billed（vCore seconds）で把握できます（その期間に「請求対象になったvCore秒」が出ます）。これにリージョンの単価を掛けると、コンピュート料金の芯が見えます。

Microsoft Learnのシナリオ例では、単価を$0.000145/vCore/秒としたとき、特定の条件で24時間あたり約$7.31になる計算が示されています。これは「実際に少し触っただけ」でも、Auto-pause delay中の下限課金が効いてくることを示す良い例です。

もしDBがほぼ24時間Onlineで、課金対象が平均1vCore相当になっているなら、86,400（秒/日）× 単価で日額が出ます。最小vCoreが2相当になれば単純に倍に近づくため、「数十ドル/日」は十分あり得ます。

Hyperscaleに変えたのに高いまま…の落とし穴

「Hyperscaleにしたら見積もりが数セント/月になったのに、実際は毎日課金される」という話は、設定の勘違いで起きやすいです。特に重要なのが次の事実です。

現時点では、ServerlessのAuto-pause/Auto-resumeはGeneral Purposeでのみサポートされており、HyperscaleではAuto-pauseがサポートされません（= Auto-pause delayの設定自体がGPにしか効かない）。つまり、Hyperscale Serverlessを選ぶと、停止してコンピュートがゼロになる前提が崩れます。

また、Hyperscaleは構成次第で「レプリカ分のコンピュート」が増えます。たとえば、ゾーン冗長を有効にすると少なくともHAレプリカが必要になり、価格はプライマリ/セカンダリ（HAやnamed replica）双方に適用されます。

さらにHyperscaleはストレージが実割り当てで動的に増え、バックアップ保持（PITR）のコストはDBサイズや変更率、保持期間に依存します。

Hyperscaleでコストが増えやすい要素	何が起きるか	開発検証での現実的な判断
Auto-pause前提の運用	そもそもAuto-pauseが効かず、下限課金が続く	Auto-pauseが必要ならGP Serverlessを優先
ゾーン冗長（HAレプリカ）	レプリカ分のコンピュートが増える	検証用途なら不要なことが多い
保持/冗長化を厚くする	バックアップ/保存コストが増える	開発は最小限の保持にする

「何が起動させているのか」を特定する実践手順

手順：まずはCost Managementで“何に課金されているか”を分解

• Cost Managementの分析で、対象リソース（SQL Database）を絞り込む
• グループ化（Group by）をメーター（Meter）や課金項目にして、コンピュート主体なのか、ストレージ主体なのかを見極める
• 「SQLは安いのに高い」場合は、Log Analyticsなど周辺課金が混ざっていないかも確認する

手順：DBが本当にPausedになっているか確認

Serverless（Auto-pause有効）では、DBの状態はOnline / Pausing / Paused / Resumingのように遷移します。ポータルの概要画面で状態が確認でき、さらにActivity logでPause/Resumeの履歴も追えます。

CLIで状態だけサッと見たい場合は、次のような確認もできます。

az sql db show --resource-group <RG> --server <SERVER> --name <DBNAME> --query status -o tsv

手順：Activity logで「誰がResumeしたか」を見る

「自分は触っていないのに起動している」問題の核心は、Resumeのトリガーです。最近、Azure MonitorのActivity logにAuto-resumeの原因を特定できるテレメトリが追加され、Resume Databasesの成功イベントでCallerプロパティに原因が出るようになりました。これにより、推測ではなくログで犯人を確定できます。

Auto-resumeの例として、ログイン（接続）だけでなく、脆弱性評価、データマスキングなどのセキュリティ設定変更、サービス更新などがトリガーになり得ることも示されています。

手順：セッション（接続）を洗い出す

Auto-pauseの成立条件に「セッション数=0」がある以上、接続が残っていれば止まりません。Online状態のときに、まずは“誰がつないでいるか”を可視化します。

SELECT
  session_id,
  host_name,
  program_name,
  login_name,
  status,
  login_time,
  last_request_start_time,
  last_request_end_time
FROM sys.dm_exec_sessions
WHERE session_id <> @@SPID
ORDER BY last_request_end_time DESC;

確認後は、接続ツール側（SSMS/Azure Data Studio等）を含めて必ず切断してください。診断のための接続が残っているだけで、Auto-pauseを阻害します。

開発・検証用途でコストを抑える現実的な選択肢

最優先：Azure SQL DatabaseのFree offer（無料枠）を使う

開発検証の“想定外請求”を避けたいなら、まずは無料枠の適用可否を確認するのが堅実です。Azure SQL Databaseには、サブスクリプションあたり最大10個のGeneral Purpose DBで、毎月100,000 vCore secondsと32GBのデータストレージ、さらにバックアップも一定量が無料になるオファーがあります（更新のない“期限なし”設計）。

無料上限に達したときの動作も選べます。

• 上限到達後は翌月まで自動停止（課金事故を起こしにくい）
• 上限超過分は課金して継続（うっかりで課金されやすい）

なお、無料枠のドキュメントでも「SSMSなどのツール接続を開きっぱなしにすると、Auto-pauseが効かずクレジットを消費する」点が明確に注意されています。

Serverlessを使うなら設定はここを詰める

Free offerが使えない／別環境でServerlessを使う場合は、次の3点が“節約のレバー”です。

• 最小vCore：Online中の下限課金に直結
• 最大vCore：スパイク時の上限（予防線）
• Auto-pause delay：短いほど、Idleの下限課金を減らせる

特にAuto-pause delayは、現在は最小15分まで下げられるため、開発検証では短めに振る価値が高いです。

項目	開発検証での推奨の考え方	注意点
最小vCore	可能な範囲で最小（下限課金を下げる）	Online中はCPU/メモリの大きい方で課金されるので、思ったより下限が上がる場合がある
最大vCore	検証に必要な範囲で小さく（暴走対策）	重いクエリを投げたときに遅くなる可能性
Auto-pause delay	可能なら短く（15分〜）	再開（Resuming）の待ちが発生しやすいので、CI等はタイムアウトを調整

常時アクセスがあるなら、Serverlessをやめた方が安くなることがある

Serverlessは「間欠的・予測しにくい利用で、アイドル時間が長い」場合に向き、逆に「規則的・平均利用が高い」場合はプロビジョンドが向く、という整理が公式にも示されています（課金粒度もServerlessは秒、プロビジョンドは時間）。

たとえば、ヘルスチェックや監視で数分おきに接続があるなら、ServerlessはほぼOnline固定になりやすく、下限課金が積み上がります。こうした場合は、最小構成のプロビジョンドや、複数DBをまとめるならエラスティックプールを検討した方が、運用もコストも安定します。

使わない期間が長いなら「削除して退避」が一番確実

SQL DatabaseはVMのように“電源オフ”してゼロ円、とはいきません。ServerlessでPausedになってもストレージは課金されます。長期間使わない検証DBは、BACPAC等で退避していったん削除する方が、費用事故を根絶できます。

予算・アラートで「気づく仕組み」を先に作る

最後に、運用で効くのは“早期検知”です。

• Cost Managementの予算（Budget）とアラートで、日次/週次の増加を検知
• Serverlessなら、Azure Monitorでapp_cpu_billedなどのメトリック監視（課金対象vCore秒の監視）
• Free offer利用時は、無料残量（Free amount remaining）にアラートを作る（10%を切ったら通知など）

まとめ

• Serverlessの料金は「コンピュート（秒課金）＋ストレージ」の合算で、Online中は下限課金が発生し得るため、少しの定期接続で日額が膨らむ。
• Auto-pauseはセッション=0かつCPU=0など条件があり、Geo-replicationやLTRなどの設定によってはAuto-pauseが使えない。
• Auto-pause delayは短いほど節約に効き、現在は最小15分まで下げられる。
• Hyperscale Serverlessは現時点でAuto-pause非対応なので、「止まってゼロ円」を期待すると外れる。
• Activity logでResumeの原因（Caller）を特定できるようになり、“誰が起動させたか”をログで確定できる。
• 開発検証は、まずFree offer（無料枠）を検討し、上限到達時の動作（自動停止/継続課金）も必ず確認する。