クラウドコスト削減 診断点検表 · 2026

総額だけを見ても何が上がったのかは見えません。先月と今月の請求をアカウントとサービス単位で並べ、増加分の大きい順に行を並べます。たいていは上位の三、四行が増加分の大半を作ります。その行をさらに資源単位まで下りて、どの資源がいつから増えたかを見ます。増え始めた日付がリリースやマーケティング施策、新機能の公開と重なるかを確認すると原因の候補が絞られます。持ち主が空欄の項目は別に数えます。タグがなくどのチームのものか分からない資源は誰も減らそうと言い出さないため、翌月も同じ場所に残ります。この最初の表がなければ、以降の点検はすべて勘で進むことになります。

一か月分だけを見ると、季節やイベントで上がった分と構造で上がった分が混ざります。少なくとも三、四か月を同じ形式で並べ、階段のように一度上がって維持されている項目と、毎月少しずつ上がる項目を分けて印を付けます。前者はたいてい特定の変更が原因で、後者は積み上がる資源が原因です。原因を絞るときはリリース履歴とインフラ変更記録を同じカレンダーに重ねます。

請求額が上がったという事実だけでは、問題かどうかの判断は付きません。事業が二倍になって請求が1.5倍なら、その月は良い月です。そこで総額の横に、事業単位で割った値を一つ置きます。注文1件あたりの費用、アクティブユーザー1人あたりの費用、リクエスト100万件あたりの費用のうち、自社サービスを最もよく説明する一つを選び、毎月同じ方法で数えます。この値が維持または低下していれば、総額が上がっても説明が立ちます。この値が上がれば、使用量とは関係なく何かがずれています。報告の場で必要になる一文もここから出ます。分母は財務がすでに使っている指標に合わせるほうが良いです。インフラだけの新しい指標を作ると、その値は翌四半期には誰も見なくなります。

最初に見るのは、開発環境と検証環境が夜間と週末に立ち上がったままかどうかです。業務時間だけ使う環境を止める施策は戻しやすく、本番サービスに触れません。次が大きさです。ピーク使用率が低いまま数週間を過ごしたインスタンス、古い世代に残っているインスタンス、オートスケーリングの最小台数が必要より高く設定されたグループを一覧にします。縮小の判断は平均ではなくピークで行います。平均だけを見て縮めると、月末やバッチの時間帯で問題が起きます。ロードバランサーの背後にトラフィックの来ない対象が付いていないか、停止したインスタンスにディスクだけが残って課金され続けていないかも同じ場で確認します。確保したまま何にも紐づいていない固定IPや、使われていないロードバランサー、名前だけ残る旧デプロイ環境もここで引っかかります。

代表的な項目は、接続されていないボリューム、削除したサーバーが残したスナップショット、期限のないまま積み上がるバックアップ、ライフサイクルルールのないオブジェクトストレージです。スナップショットは一つずつが小さく目に付きませんが、世代が積み上がると元より大きくなります。保持期間を決めて自動で消えるようにするほうが、毎月手で消すより確実です。ログもストレージです。どのログを何日置くのか、監査要件が求める期間はどれだけかを確認し、残りは安価な階層へ下ろすか削除します。消す前に、何のために残したのかを担当者に一度尋ねます。災害復旧用に残したものを費用としてだけ見て消せば、その値は事故のときに請求されます。オブジェクトストレージは保存量よりリクエスト数や階層移動で値が付く場合があるため、請求項目を細目まで展開して見ます。

転送料金は資源一覧に行として並ばないため、原因を見つけにくい項目です。インターネットへ出るトラフィック、アベイラビリティゾーンやリージョンをまたぐ内部通信、NATゲートウェイを通る要求を分けて見ます。データベースとアプリケーションが別のゾーンにあれば、ありふれた照会の一つ一つが転送料金を作ります。画像や静的ファイルがオリジンサーバーから直接出ているなら、前段にキャッシュを置くだけで出ていく量が減ります。キャッシュをすでに使っていても、適中率が低ければ料金は二重に付きます。ログとバックアップを別リージョンへ複製している場合は、その複製が規制要件なのか慣行なのかを確認します。

マネージドのデータベース、検索、キュー、キャッシュは立ち上げておくだけで値が付きます。開発用に作ったクラスターがプロジェクト終了後も回り続けている例は多く見られます。マルチAZ構成やリードレプリカが開発環境にまでそのまま複製されていないかを見ます。商用ソフトウェアのライセンスがインスタンス時間に乗って課金される構成なら、ライセンスの値がインスタンス料金を上回る場合もあります。クラウド請求の外に出ていく値も同じ表に載せます。監視、ログ収集、通知、デプロイツールの購読料が使用量に追随する構造なら、インフラを減らしても総額が変わらないことがあります。

同じ点検を翌四半期に繰り返さないために、値が自然に分かれる形を作っておきます。アカウントとプロジェクトを環境別に分ければ開発環境の値が本番に混ざらず、チーム別に分ければ請求書がそのまま配賦表になります。タグは項目を増やすより、三、四個を強制するほうが守られます。所有チーム、環境、サービス、終了予定日があれば、たいていの問いに答えが出ます。タグのない資源は作成できないようにし、すでに付いていない資源は担当者が見つかるまで一覧に残します。終了予定日の欄があると、試験用に立てた資源が半年後も回っている事態が減ります。この整理が終われば、翌月の請求書は原因を探す文書ではなく確認する文書になります。

契約購入と予約購入は割引率が大きいため、最初に手を付けたくなります。順序を逆にすると、無駄まで一緒に固定されます。今の大きさが適正かを確認する前に1年や3年を約束すれば、減らす機会がその期間ずっと塞がれます。前の点検を終えて残った使用量のうち、事業がどう転んでも使い続ける底の帯だけを契約で覆い、その上はオンデマンドに残します。期間を決めるときは、組織再編やサービス終了、大規模な移行計画がその期間に入っていないかをカレンダーで先に見ます。契約を途中で譲渡・変更できるか、アカウントを分けても割引が追随するかも契約前に確認します。

一覧ができたら、削減額ではなくリスクで並べ替えます。止めて入れ直せばよいもの、戻すのにリリースが必要なもの、戻せないものの三つに分けます。最初の束はその週に終わらせ、最後の束は担当者の確認と作業枠を取って進めます。項目ごとに戻す条件と責任者を併記します。何をなぜ止めたのかが残っていなければ、数か月後の障害調査で原因を探すのに時間がかかります。整理したアカウントは放置すれば元へ戻ります。新規作成の資源にタグを強制するルール、予算のしきい値を超えたときにまず担当チームへ通知する順序、コストレビューを定例会議に載せる日程まで同じ点検表に入れます。終わった項目は消さず、いつ何をしたかを残します。翌四半期に同じ資源が再び一覧に上がっても、判断を繰り返さずに済みます。

自分たちで見る人がいなければ診断を委託します。提案を比べるときは削減額より課金構造を先に見ます。削減額の一部を受け取る成果連動型は施策を速く進めますが、契約購入のように長く固定される項目を勧める側へ傾きやすくなります。クラウド使用料を再販する構造なら、使用量が減れば相手の売上も減る点を計算に入れます。何が残るかも契約前に決めます。報告書一部ではなく、タグのルールと予算アラート、施策一覧と戻す条件が自社アカウントに残ってはじめて、翌四半期に同じ診断を買い直さずに済みます。ワークロードを知らないまま使用率だけで切った一覧は、締め処理やバッチ日程で事故を作ります。各資源がどの業務周期のために存在するのかを担当者に尋ねる手順が提案に入っているかを確認します。最初の契約を短く区切る方法もあります。診断とリスクの低い施策までを一度任せ、そこで残った文書と実際に下がった項目を見て次の範囲を決めれば、判断の根拠が提案書ではなく結果になります。