クラウド費用が膨らむ理由と最適化の進め方｜AWS・Google Cloudに共通する考え方
AWSやGoogle Cloudなどのクラウドは、必要なときに必要な分だけ使える反面、使い方を管理しないと費用が少しずつ膨らんでいきます。導入当初は月数万円だった請求が、サービスの成長や担当者の入れ替わりを経て、気づいたときには数倍になっていたというケースは珍しくありません。
クラウド費用が膨らむ理由は、特定のサービスの単価が高いことよりも、「使っていないリソースが動き続けている」「必要以上の性能で動かしている」「誰が何のために作ったのか分からないリソースが残っている」といった、管理の問題であることがほとんどです。この点は、AWSでもGoogle Cloudでも変わりません。
そのため、クラウド費用の最適化は、一度の削減作業で終わるものではなく、費用を見える化し、原因を特定し、削減策を選び、再発を防ぐルールを作るという流れで進める必要があります。割引の購入などの手段は、その流れの中で使いどころを判断するものです。
この記事では、クラウド費用が膨らむ理由、費用の見える化の方法、すぐ効く削減策と設計で効く削減策、割引購入とスポットの使い分け、最適化を続けるための体制とルールを、AWSとGoogle Cloudに共通する考え方として解説します。
クラウド費用が膨らむ理由
クラウドの費用が想定より増える理由は、大きく次の4つに分けられます。どれか1つではなく、複数が重なっていることがほとんどです。
| 理由 | 具体的な状態 |
|---|---|
| 使っていないリソースが残っている | 検証用に作ったサーバー、停止したまま残っているディスク、使われていない固定IPアドレス、古いスナップショットやバックアップ |
| 性能が必要以上に大きい | 開始時に余裕を持って選んだサーバーのサイズが、そのまま見直されていない。CPUやメモリの使用率が常に低い |
| 常時稼働させる必要のないものが動いている | 夜間や休日も使わない開発環境、検証環境が24時間動いている |
| 設計に起因する費用 | データ転送が多い構成、ログの全量保存、全件を毎回処理するバッチ、データウェアハウスへの非効率なクエリ |
前の3つは「管理」の問題で、見つけさえすれば比較的すぐに直せます。4つ目の「設計」の問題は、アプリケーションやデータの処理方法に手を入れる必要があるため時間はかかりますが、費用の大部分を占めている場合は、ここを直さない限り根本的には下がりません。
また、クラウドの料金体系は従量課金が基本で、請求書は月末にまとめて届きます。日々の利用状況を見ていなければ、費用の増加に気づくのは翌月の請求時になり、原因の調査も後手に回ります。費用が膨らむ背景には、こうした「気づくまでの時間差」もあります。
まず費用を見える化する
削減策を考える前に、どこにいくらかかっているのかを把握します。AWSであればCost Explorer、Google CloudであればCloud Billingのレポートを使うと、サービス別、プロジェクトやアカウント別、期間別に費用を確認できます。最初に見るべきなのは次の点です。
- 費用の大きいサービスの上位5つと、それぞれの前月比
- 費用が急に増えた日と、その日に何があったか（リリース、データ移行、設定変更など）
- 本番環境と開発・検証環境の費用の比率
- 誰が管理しているのか分からないリソースの有無
この段階で効いてくるのが、リソースへのタグ（AWS）やラベル（Google Cloud）の付与です。「環境（本番・検証）」「システム名」「担当部署」などのタグを付けておけば、費用をシステム別、部署別に分けて見られるようになり、「この費用は誰の判断で減らせるのか」が明確になります。タグが付いていないリソースが多い場合は、まずタグ付けのルールを決め、新しく作るリソースから徹底することから始めます。
あわせて、予算と通知を設定しておきます。Google Cloudの公式ドキュメントでは、予算を作成すると実績の50%、90%、100%に達したときの通知がはじめから設定されると説明されています。ただし、通知のみの予算設定では利用や課金は自動で止まりません。AWSのBudgetsも同様に、まずは通知の仕組みとして使い、通知を受けたら誰が確認するのかまで決めておくことが重要です。
費用を事業の数字と並べて見る
クラウドの費用は、事業が伸びれば増えるのが自然です。そのため、請求額が前月より増えたことだけを見て「高くなった」と判断すると、必要な投資まで削ってしまうおそれがあります。判断の基準にしたいのは、利用者1人あたり、注文1件あたり、処理したデータ1件あたりといった、事業の量に対する費用の割合です。
たとえば、利用者が2倍になって費用も2倍になったのであれば、仕組みとしては健全です。利用者がほとんど増えていないのに費用だけが増えているなら、どこかに無駄や設計上の問題があると考えられます。月次の費用確認の場で、請求額と一緒に事業の主要な数字を並べておくと、削るべき費用と必要な費用を区別しやすくなります。
参考：予算と予算アラートの作成、編集、削除／Google Cloud
すぐ効く削減策と、設計で効く削減策
削減策は、作業の手間と効果の出方によって分けて考えると、優先順位を決めやすくなります。
| 区分 | 主な削減策 | 手間と注意点 |
|---|---|---|
| すぐ効く | 使っていないサーバー、ディスク、スナップショット、固定IPアドレスの削除 | 手間は小さい。削除前に本当に不要か、担当者とバックアップの要否を確認する |
| すぐ効く | 開発・検証環境の夜間・休日停止 | スケジュールで自動停止・起動を設定する。業務時間外に使う人がいないか事前に確認する |
| 少し手間がかかる | サーバーやデータベースのサイズの見直し（ライトサイジング） | CPUやメモリの使用率を一定期間確認してから縮小する。繁忙期の負荷も考慮する |
| 少し手間がかかる | ストレージの保存期間の設定と、低頻度アクセス向けのストレージクラスへの移行 | 取り出し時に料金がかかるクラスもあるため、アクセス頻度を確認してから移す |
| 設計で効く | データ転送の経路の見直し、バッチの差分処理化、データウェアハウスのクエリとテーブル設計の改善 | アプリケーションやデータ処理の改修が必要。効果が大きい場合が多い |
| 設計で効く | サーバーレスやマネージドサービスへの移行 | 利用量が少なく波があるシステムでは安くなりやすい。常時高負荷のシステムでは逆に高くなることもある |
判断の基準として、費用の上位がサーバーやデータベースの「稼働時間」に関わるものであれば、停止とサイズの見直しが先です。上位がデータウェアハウスのクエリ料金やデータ転送料金であれば、リソースを止めても効果は小さく、処理の設計を見直す必要があります。見える化の段階で、どちらのタイプの費用が大きいのかを見極めておくことが、遠回りを避けるコツです。
当社が関わった不動産販売業者向けの物件データ収集基盤では、データの持ち方とクエリの見直し、機械学習による事前の絞り込みによって、データ処理コストを80%削減しつつ、抽出できる物件数を2倍にしました。設計で効く削減策は手間がかかる分、機能を落とさずに費用を下げられる可能性があります。
割引購入とスポットの使い分け
一定量の利用を長期間続けることが確実なら、利用量を約束する代わりに単価が下がる割引の仕組みを使えます。また、中断されても問題のない処理であれば、余剰の計算資源を安く使える仕組みもあります。2026年10月時点で各社の公式ページに記載されている割引の上限は次のとおりです。いずれも「最大」の値で、実際の割引率は対象の種類や期間、リージョンによって変わり、今後改定される可能性もあります。
| 仕組み | 概要 | 公式ページ記載の割引の上限 |
|---|---|---|
| AWS Compute Savings Plans | 1年または3年、1時間あたりの利用金額を約束する。インスタンスの種類やリージョンの変更に柔軟 | 最大66% |
| AWS EC2 Instance Savings Plans | 1年または3年、特定のインスタンスファミリーとリージョンで利用金額を約束する | 最大72% |
| AWS EC2スポットインスタンス | 余剰の容量を利用する。中断される可能性がある | オンデマンド料金から最大90% |
| Google Cloudのリソースベースの確約利用割引 | 1年または3年、vCPUやメモリなどの量を約束する | メモリ最適化マシンで最大70%、その他のマシンで最大55% |
| Google Cloud Spot VM | 余剰の容量を利用する。プリエンプト（中断）される可能性がある | 多くのマシンタイプなどで最大91% |
割引購入が向いているのは、本番環境のように常時稼働し、今後1年以上は同じ程度の量を使い続けることが見込めるリソースです。反対に、サイズの見直しやサーバーレスへの移行を検討している段階で長期の約束をすると、削減の余地を自ら狭めてしまいます。順番としては、不要なリソースの削除とサイズの見直しを先に済ませ、残った「確実に使い続ける量」に対して割引を購入するのが基本です。
スポットが向いているのは、途中で止まっても再実行すればよいバッチ処理、データの変換処理、機械学習の学習処理、負荷試験などです。顧客が直接使う本番のWebサーバーや、処理の途中で止まると不整合が起きるデータベースには向きません。スポットを使う場合は、中断されたときに処理を再開できる設計になっているかを先に確認します。
割引を購入する前に確認したいこと
長期の割引は、約束した金額や量を使わなかった場合でも支払いが発生します。購入を判断する前に、次の点を確認しておくと失敗を避けられます。
- 過去数か月の利用量のうち、最も少ない月でも使っている量はどれくらいか
- 今後1年以内に、システムの廃止、統合、別のクラウドへの移行の予定がないか
- サイズの見直しやサーバーレスへの移行で、利用量が大きく減る見込みがないか
- 1年と3年のどちらの期間なら、事業の見通しと無理なく合うか
利用量の最も少ない月の水準を目安に、まず一部だけを購入し、様子を見ながら追加していく進め方であれば、使い切れないリスクを抑えられます。事業の見通しが立たない段階では、割引率の高さより柔軟さを優先し、期間の短いものや適用範囲の広いものを選ぶほうが安全です。
参考：Compute Savings Plans／Amazon Web Services
最適化を続けるための体制とルール
一度削減しても、管理の仕組みがなければ費用は再び膨らみます。最適化を続けるために決めておきたいのは、次のようなルールです。
- リソースを作るときは、環境、システム名、担当者のタグを必ず付ける
- 検証用のリソースには終了予定日を決め、期限を過ぎたものは確認のうえ削除する
- 月に一度、費用の上位サービスと前月比を確認する場を設ける
- 予算の通知を受けたときの確認者と、確認する項目を決めておく
- 新しいシステムを作るときは、設計の段階で月額費用の見込みを出す
社内に専任の担当者がいない場合は、すべてを自社で抱え込まず、月次の費用確認だけは自社で行い、原因の調査や設計の見直しは開発会社や技術パートナーに依頼するという分担も現実的です。その場合も、タグのルールと予算通知の設定は自社で持っておくと、外部に任せた部分の費用の妥当性を判断できます。
開発会社に新しいシステムの構築を依頼するときは、見積もりに開発費だけでなく、想定する利用量にもとづいたクラウドの月額費用の見込みを含めてもらうよう依頼してください。構築費が安くても、運用費が高くなる設計では総額で見て割高になることがあります。
まとめ
クラウド費用が膨らむ主な理由は、使っていないリソースの放置、必要以上の性能、常時稼働の必要がない環境の稼働、そして設計に起因する処理の多さです。AWSでもGoogle Cloudでも、費用を見える化し、上位の費用が稼働時間に関わるものか、処理の設計に関わるものかを見極めてから手を打つという流れは共通です。
割引購入は、不要なリソースの削除とサイズの見直しを終え、確実に使い続ける量が見えてから使います。スポットは中断されても再実行できる処理に限って使います。明日からできることとしては、Cost ExplorerやCloud Billingのレポートで費用の上位5サービスと前月比を確認し、あわせて予算通知が設定されているか、通知の宛先が今の担当者になっているかを確認してください。それだけでも、次に費用が増えたときに原因へたどり着くまでの時間を大きく縮められます。