Azure クラウドコスト最適化ガイド — .NET ワークロードのコストを下げる

Azure 上で .NET ワークロードを運用していると、利用が拡大するにつれてコストが想定を上回り、どこに無駄があるのか把握しづらくなる。クラウドのコストは「見える化」「適切なサイジング」「使った分だけ払う仕組みへの移行」「割引プランの活用」「アプリケーション側の効率化」という複数のレイヤーで最適化でき、それぞれが相乗的に効く。本記事では Microsoft Cost Management による可視化から、SKU / リージョン選定、オートスケール、サーバーレス、予約とスポット、ストレージ階層、不要リソースの棚卸し、.NET 側の効率化までを整理し、最後に継続運用としての FinOps の考え方を示す。より広い文脈は.NET モダナイゼーション完全ガイドを参照してほしい。

コストを可視化する

最適化の第一歩は現状把握である。何にいくらかかっているかを分解できなければ、削減対象を特定できない。Azure では Microsoft Cost Management がこの役割を担う。

Cost Management の Cost analysis では、サービス別・リソースグループ別・リージョン別・タグ別にコストを集計し、日次や月次の推移を確認できる。まず着手すべきは一貫したタグ付けである。環境（本番 / ステージング / 開発）、プロジェクト、部門、コストセンターといったタグをリソースに付与しておくと、コストをビジネス単位で按分でき、責任の所在が明確になる。Azure Policy を使えばタグの付与を強制したり、リソース作成時に自動継承させたりできる。

可視化と並行して予算とアラートを設定する。Cost Management の Budgets では月次や四半期の予算しきい値を定義し、実績が 80%、100%、予測が 100% を超えた時点でメール通知やアクショングループ経由の自動処理を発火できる。予算超過を月末に気づくのではなく、その途中で検知できる体制が重要になる。

# 予算を CLI で作成する例
az consumption budget create \
  --budget-name prod-monthly \
  --amount 5000 \
  --category Cost \
  --time-grain Monthly \
  --start-date 2026-07-01 \
  --end-date 2027-07-01

Azure コスト最適化の主なレバー — オートスケール・サーバーレス・予約・適正化を組み合わせてコストを下げる。

適切な SKU とリージョンを選ぶ

過剰なサイジングは最も見つけやすい無駄である。CPU 使用率やメモリ使用率が常時低いインスタンスは、より小さい SKU へ落とせる余地がある。Azure Advisor はこうした過剰プロビジョニングを検出し、ダウンサイズやシャットダウンの推奨を提示する。仮想マシンであれば新しい世代の SKU ほど同一価格あたりの性能が高いことが多く、世代更新自体が実質的なコスト削減になる。

リージョン選定も価格に直結する。同じサービスでもリージョンごとに単価が異なり、加えてリージョンをまたぐ下り方向のデータ転送には課金が発生する。レイテンシ要件とデータ所在の制約を満たしつつ、通信するリソース同士は同一リージョン・同一可用性ゾーンにまとめると、転送コストとレイテンシの双方を抑えられる。

オートスケールで需要に追従する

負荷は時間帯や曜日で変動する。ピークに合わせて固定した容量を張り続けると、閑散時間帯の分がそのまま無駄になる。オートスケールは需要に応じてインスタンス数を増減させ、この無駄を削る。

App Service では CPU 使用率やキュー長などのメトリクスに基づくスケールアウト・スケールインルールを定義できる。Container Apps は HTTP 同時リクエスト数や KEDA ベースのイベント量でスケールし、AKS では Cluster Autoscaler がノード数を、Horizontal Pod Autoscaler が Pod 数を調整する。いずれも最小・最大インスタンス数とスケール条件を適切に設定することが肝心で、最小値を過大にするとオートスケールの効果が薄れ、最大値を過小にすると性能が頭打ちになる。

サーバーレスと消費ベースへ寄せる

常時起動が不要なワークロードは、使った分だけ課金される消費ベースのモデルに移すとコスト効率が大きく改善する。

Azure Functions の従量課金プランでは、関数の実行回数と実行時間・メモリ消費に対してのみ課金され、待機中のコストが発生しない。イベント駆動やバッチ、断続的な API といったワークロードに向く。実装上の勘所はAzure Functions サーバーレス開発のベストプラクティスにまとめている。

Container Apps はゼロスケールに対応しており、リクエストがない間はレプリカ数を 0 まで縮小してコンピュートコストを発生させない。最小レプリカを 0 に設定するとコールドスタートが伴うため、レイテンシ要件と相談して最小レプリカ数を決める。常時のトラフィックがない内部 API や管理系サービスでは、ゼロスケールの恩恵が特に大きい。

予約とスポットで単価を下げる

負荷を平準化できないベースライン容量には、消費ベースよりも割引プランのほうが有利になる。使用量が安定して予測できる分は、あらかじめコミットして単価を下げる。

Reserved Instances は 1 年または 3 年の利用をコミットする代わりに従量課金より大幅な割引を得る仕組みで、特定の VM シリーズやリージョンに紐づく。Savings Plans はコンピュート支出額を時間あたりでコミットするより柔軟な選択肢で、対象サービス間で割引を適用でき、サービス構成が変化しやすい環境に向く。まず Cost Management や Advisor の推奨で安定稼働している分を把握し、その範囲に予約や Savings Plans を当てるのが定石である。

一方、中断を許容できるワークロードにはスポット（Spot）が有効になる。余剰キャパシティを大幅な割引で利用できるが、Azure 側の都合で退避される可能性がある。バッチ処理、CI ビルド、ステートレスでリトライ可能な処理、AKS のスポットノードプールなどが適用先になる。

ストレージを階層化し保持を管理する

ストレージは放置すると単調に増え続けるコスト要因である。Azure Blob Storage はアクセス頻度に応じて Hot / Cool / Cold / Archive の階層を持ち、下位の階層ほど保管単価が安い。アクセス頻度の低いデータを下位階層へ移すだけで保管コストを削減できる。

ライフサイクル管理ポリシーを使えば、最終アクセスや最終更新からの経過日数に基づいて階層移動や削除を自動化できる。例えば 30 日でアクセスがなければ Cool、90 日で Archive、一定期間後に削除、といったルールを定義しておくと、運用の手間なく保持ポリシーを徹底できる。加えて、不要になった古いスナップショットやマネージドディスクのバックアップ、過剰な冗長性（不要な GRS など）の見直しも効く。

不要リソースを棚卸しする

クラウドでは検証や一時利用で作ったリソースが残存し、静かに課金を続けることが多い。定期的な棚卸しで、こうした「オーファンリソース」を特定して削除する。

典型的な対象は、どの VM にも接続されていないアンアタッチのマネージドディスク、割り当て先のない Public IP、空のアプリケーションゲートウェイやロードバランサ、停止したままの検証環境、使われていない古いスナップショットである。停止しても課金が続くリソース（割り当て解除していない VM など）にも注意が要る。Azure Resource Graph を使うと、こうした条件に合致するリソースを横断的にクエリできる。

# アンアタッチのマネージドディスクを一覧する
az graph query -q "Resources
  | where type == 'microsoft.compute/disks'
  | where properties.diskState == 'Unattached'
  | project name, resourceGroup, location"

.NET 側で効率化する

インフラだけでなくアプリケーション自体の効率も、必要なインスタンス数を通じてコストに跳ね返る。1 インスタンスあたりの処理密度を高めれば、同じ負荷をより少ない台数でさばける。

.NET 10 の Native AOT は事前コンパイルによりランタイムの JIT を不要にし、起動時間を短縮しメモリフットプリントを縮小する。省メモリ化はコンテナ 1 台あたりに載せられるインスタンス密度を高め、結果として必要なノード数を減らす。起動が速いことはゼロスケールやオートスケール時のコールドスタントを短くし、消費ベースモデルとの相性もよい。適用の可否や制約は.NET 10 Native AOT で高速起動を実現する実践ガイドで確認してほしい。

// Native AOT を有効化するプロジェクト設定
// <PropertyGroup>
//   <PublishAot>true</PublishAot>
//   <InvariantGlobalization>true</InvariantGlobalization>
// </PropertyGroup>

AOT 以外にも、非同期処理による接続の効率利用、適切なキャッシュによる下流呼び出しの削減、不要なアロケーションの抑制といった一般的な .NET の最適化が、コンピュートとデータ転送の双方でコストに寄与する。

FinOps として継続運用する

コスト最適化は一度きりの作業ではなく、継続的な運用プラクティスとして定着させる必要がある。FinOps はエンジニアリング、財務、事業部門が連携し、可視化・最適化・運用のサイクルを回す考え方である。

実務としては、月次でコストレビューを行い、タグ別・チーム別の支出を可視化して各チームに自分たちのコストを認識させる。予約カバレッジや利用率、オートスケールの効き、オーファンリソースの発生状況を定期的に点検し、Advisor の推奨をバックログに取り込む。新規リソースの作成時にはコスト影響をレビューし、タグ付けと予算を最初から設計に組み込む。こうした運用を回すことで、コストは削減して終わりではなく、常に適正水準に保たれる。移行そのものの設計はオンプレ .NET アプリの Azure 移行完全ガイドを参照してほしい。

エンハンスド株式会社では、クラウドのコスト最適化を含むアーキテクチャ改善を支援しています。