MNTSQ Techブログ

「MNTSQ（モンテスキュー）」のTechブログです。

トップ > AIと一緒に取り組むAWSコストのコントロール〜施策棚卸しから実施まで〜

AIと一緒に取り組むAWSコストのコントロール〜施策棚卸しから実施まで〜

MNTSQ Tech Blog TOP > 記事一覧 > AIと一緒に取り組むAWSコストのコントロール〜施策棚卸しから実施まで〜

藤原です。

パブリッククラウドのコストコントロール、どこから手を付けていますか？

本エントリでは、2026年上期に取り組んだAWSコストコントロール施策を題材に、AIを壁打ち相手として使いながら、施策の棚卸し → 想定削減効果の見積もり → 優先度づけ → 実施判断を進めた事例を解説します。AIと人間の役割分担について、ひとつの例として捉えてもらえるとありがたいです。

コスト削減の進め方とAI

コスト削減の打ち手そのものは、実はそれほど目新しいものではありません。教科書的な施策は山ほどあります。

とくに難しかったり大変なのは施策の実行ではなく、その前段階です。進め方をざっと大枠で分けると

  1. 棚卸し
    • 自分たちの環境で効きそうな施策を漏れなく洗い出す
  2. 見積もり
    • それぞれが「いくら効くのか」を、自分たちの請求データに基づいて試算する
  3. 優先度づけ
    • 効果も工数もリスクもバラバラな施策を、どの順で並べるか
  4. 判断
    • 「やる/やらない/保留」を、コミットメントのリスクや事業の文脈を踏まえて決める
  5. 実施
    • やることが確定した施策を実行

これら5ステップに分解できます。とくに 2 の試算と 3 の優先度づけは、Cost Explorerの数字を引っ張り、インスタンス単価を調べ、各種割引やサイズフレキシビリティなどを加味してと、多くの作業が必要になります。これらが確実に時間を溶かしてくれます。これらの作業ををAIに任せことができると検討の速度を大幅に高められます。

進め方の全体像

最初に親Issueを立て、そこにぶら下げる形で施策を棚卸し・試算・優先度づけしていきました。進め方は大きく5ステップで、AIに任せられるのは Step 1〜3、最後の Step 4 の判断は人間が握る、Step 5は人間でもAIでも必要に応じて進めるという分担です。

Step 1: 棚卸し（AIにブレストさせる）

起点にしたのは、ここ数ヶ月のAWS Billing and Cost Managementの情報をAIに調査させること でした。Cost Explorer や Cost and Usage Report のサービス別・アカウント別・月次の推移をAIに読ませ、「どのサービスがコスト増の主因になっているか」「直近で異常な伸びをしている費目はどれか」をまず特定させます。人間が請求画面をあちこち開いて差分を追う作業を、ここでごっそり肩代わりさせられます。

その内訳を踏まえて「効きそうなコスト削減施策を、効果見込みの仮説とあわせて出して」と棚卸しさせると、RI/SP・停止・ログ・アーキ移行といった定番に加え、自分では見落としていた切り口（Config記録頻度、MetricStream転送料、ECR PublicからのNAT通信）まで出てきます(図1)。

図1. AIと壁打ちして作成した施策と記載削減額の例

結果として、このStep 1の成果物として、こうした施策候補のリストが得られました。

  • OpenSearch の緊急調査と最適化（RI購入 + Right Sizing）
  • EC2/ECS の Compute Savings Plans 導入
  • RDS の Reserved Instances 導入
  • Enterprise Support プランの評価
  • ECS ARM64(AArch64) 移行
  • 非本番環境の夜間・休日停止
  • CloudWatch コスト最適化
  • AWS Config ルールの棚卸し
  • ElastiCache の Reserved Nodes 導入
  • NAT Gateway のデータ処理料金最適化
  • EBS ボリュームサイズの適正化

ここで出てくる削減効果はあくまで「仮説」です。粒度を揃えるための叩き台と割り切ります。なお、AIが施策ごとに積み上げてくる想定削減効果の合計は、こちらの感覚値よりもずっと大きな数字になっていました。後述するとおり、この数字はそのままは実現しません。

Step 2: 想定削減効果の試算（AIに請求データを食わせて計算させる）

棚卸しした施策を1つずつ、AIに実データに基づいた試算をさせていきます。ここがAIの一番の効かせどころです。

ここで効いたのが、AWSのPricing APIをAIに調査させること 1です。RIやSavings Plansの試算では、オンデマンド単価・RI単価・支払い方式ごとの割引率といった「正確な料金」が欠かせません。これを記憶やうろ覚えで埋めると試算ごと崩れますが、Pricing APIを叩いて対象インスタンスタイプ・リージョンの単価を取得させることで、実際の料金表に基づいた試算ができます(図2)。

図2. 削減効果を試算した例

たとえばOpenSearch RIでは、Pricing APIで取得した単価をもとに、対象ノードのインスタンスタイプ・台数・期間・支払い方式を踏まえ、オンデマンド時とRI適用時の月額を突き合わせて試算させています。r7g/c7g系の3年 No Upfront RIなら割引率は約48%、といった具合に、施策ごとの削減率が定量的に見えてきます。

Compute Savings PlansやRDS RIでは、Cost Explorerの推奨値（ルックバック期間・推奨カバレッジ・想定稼働率）まで読み込ませて、1年/3年 × No Upfront/All Upfront のマトリクスで比較させました。RDSのサイズフレキシビリティ（db.r8g.2xlarge を db.r8g.large × 4 換算でカバーする）のような細かい仕様も、ちゃんと計算に織り込んでくれます。

ただしここで重要なのが、「稼働の前提」まで含めて試算させること です。RIやSavings Plansは購入後、対象が停止していても課金され続けます。非本番環境で夜間・休日は停止する運用がある場合に、フル稼働を前提にカバレッジを設計すると、停止している時間帯のぶんだけコミットがムダになります。「この環境は平日日中だけ稼働、夜間・休日は停止」という運用実態を前提に置いて見積もらせると、どこまでをRI/SPで踏み込んでよく、どこからは停止やオンデマンドに任せるべきか の境界が定量的に見えてきます。常時稼働の本番系は厚めにコミットし、停止運用のある非本番系はコミットを薄く（あるいは停止施策に寄せる）といった、環境ごとのメリハリのある設計につなげられます。

裏を返せば、稼働状況の前提をどこまでインプットできるかが、そのまま試算の質を決めます。各環境の稼働時間・停止スケジュール・将来の構成変更の見込みといった前提を具体的に与えられるほど、コミットメントの過剰購入リスクを抑える「リスクコントロール」につながり、同時に実際に得られるコスト削減効果の算定精度も上がります。逆に前提が曖昧なまま試算させると、実態と乖離するリスクが大きくなります。AIに任せる部分だからこそ、インプットする情報の質と量がアウトプットの信頼性を左右する という点への理解が重要です。

Step 3: 効果 × 工数 × リスクで優先度づけ

試算が揃ったら、各施策を 「削減効果」「工数」「リスク」 の3軸で並べます。これもAIに整理させると一覧になります。 次に挙げているのはElastiCacheでのコスト削減案の例です。

優先 施策 想定削減 工数 リスク
★★★ Reserved Nodes 購入 中 低（購入のみ） 低
★★☆ production ノードダウングレード 小 中（要メトリクス確認） 中
★☆☆ 非本番ダウングレード 小 低 低

基本方針はシンプルで、「効果が大きく・工数が低く・リスクが低い」ものから着手します。RI/SP購入や設定変更だけで効く施策（OpenSearch RI、Config棚卸し）は即実施、メトリクス確認やデータ移行が要る施策は後回しといった整理になります。

Step 4: 実施判断（ここは人間がやる）

そして最後、「やる/やらない/保留」の判断は人間が握ります。 ここはAIに丸投げできないというのが今回はっきりした境界です。具体の判断結果の事例は以降で解説します。

なお、施策によっては Step 2 の時点で判断がほぼ片付くものもあります。稼働の前提情報や現状の構成・設定をインプットして試算させる過程で、「これはすでに実施済みだった」と判明する施策が出てくる からです。実際、非本番環境の夜間・休日停止はすでに運用に入っていましたし、AWS Config の記録頻度見直しもすでに対応済みでした。前提情報を丁寧に与えるほど、こうした「やらなくてよい施策」が早い段階でふるい落とされ、人間が本当に判断すべき施策に集中できます。

実際にどう決着したかを区分ごとに並べます。

即実施、または実施済みだったもの

効果が大きくリスクが小さく、さらに工数もかからないものについては即実施しました。 また、Step 1の時点で上がっていたもののうちすでに実施済みのものもありました。

提案施策 判断
OpenSearch RI（3年 No Upfront） 本番系の安定稼働ノードなので3年RIで即購入
RDS RI（r8g系・1年 No Upfront） r8g系は3年RIが存在しないため1年一択
AWS Config ルール棚卸し VPC関連リソースの記録頻度を CONTINUOUS→DAILY に。すでに対応済みだった
非本番環境の夜間・休日停止 調べたらすでに停止済みだった

ここで挙げたものはいずれもすでに高い効果を上げていたもの、実施することで高い効果がほぼ得られるものです。 とくに本番環境のOpenSearchのRI購入は効果として大きいものでした。

試算して実施したもの

次に効果が大きく、リスクも大きいが、工数はかからないものです。 リスクとしてはミスコミットが起きる可能性が高いものです。 具体的には以下に挙げているEC2/ECS絡みの1施策でした。

提案施策 判断
Compute SP（ECS関連・カバレッジは控えめに設定） AWS推奨より低め・1年・No Upfrontを選択

この施策がリスクとして大きくなっている理由はシンプルに一定自動スケールアウト・インの仕組みを導入しているからです。 システムの利用状況に応じてスケールアウト・インをさせる構造となっているため全体の需給を確実に予測することは難しくなっています。

ここで効いた人間としての判断は以下の通りです。

  • AWS推奨の単価をそのまま採用しない。前述のとおりスケールアウト・インで需給の予測が難しく、コミットしすぎるとスケールイン時に使い切れずムダになります。そこでミスコミットを避けるため、AWS推奨よりも低めのコミット単価に寄せました。コミットを薄くすればカバーしきれないオンデマンド分は残りますが、確実に使い切れる範囲に絞ることを優先した判断です。
  • コミットは「後から増やす方向」に倒す。Savings Plans は後からコミットメントを積み増すことはできても、いったん買ったコミットを途中で減らすことは困難です。減らせない以上、最初から攻めると過剰コミットがそのまま固定費になってしまいます。そこでまずは低めのコミットから入り、しばらく稼働傾向（スケールの実績や需給の振れ幅）を観察したうえで、足りないぶんを段階的に積み増していく方針としました。
  • 3年ではなく1年を選ぶ。割引率だけ見れば3年のコミットが最大になります。今後のアーキテクチャ変更などを見据えると3年コミットはリスクとして大きいと判断して1年にしています。将来的には3年へ切り替える前提です。

追加調査の上実施したもの

案としては出てきたが、具体の詳細の対応内容として、追加の調査（具体対象とすべきものはなにか、除外が必要なものは何か、どう実装すべきか）が必要なものについては追加調査の上実施しました。 次に挙げる施策がその対象となりました。

提案施策 具体の施策内容
CloudWatch コスト最適化 非本番MetricStream停止・ログ保持期間設定・Container Insights無効化など6施策を特定。Datadog でカバーできる範囲を調査の上で判断
ECS ARM64(AArch64) 移行 Fargateが約20%安。サービス単位で順次移行
NAT Gateway 最適化 この時点ではコストの原因特定まで届かず、具体の施策は詳細を調査の上で検討

CloudWatch のコスト最適化では、単純にログ保持期間やメトリクスを削るのではなく、「それは Datadog 側でカバーできているか」を調査してから判断 しました。MNTSQ では o11y 基盤として Datadog を主に利用しており、メトリクス・ログ・トレースは原則 Datadog に集約する方針です。だからこそ、CloudWatch 側で何を削っても監視・調査に支障が出ないか——たとえば非本番環境の MetricStream を止めても Datadog 側の監視で足りるか、Container Insights を無効化しても必要なコンテナメトリクスが Datadog で取れているか、保持期間を縮めるロググループが Datadog に転送済みか、またはS3にアーカイブ済みかなどをひとつずつ確認した上で、削ってよいものだけを対象に絞りました。「CloudWatch のコスト」と「実際に必要な可観測性」は別物で、Datadog でカバーできている部分は CloudWatch 側を遠慮なく削れる、という切り分けがここでの肝でした。

ARM64移行では、削減効果そのものより 「x86（amd64）から ARM64(aarch64) へ移行する際のブロッカーが具体的に何か」の洗い出し に重きを置きました。具体的には、

  • aarch64 向けのコンテナイメージが提供されているか（マルチアーキ対応イメージか、ベースイメージに arm64 タグがあるか）
  • アーキ依存のネイティブバイナリ・商用ライブラリがないか（例: Aspose のような x86 依存の商用ライブラリ、特定アーキ向けにビルドされた拡張モジュール）
  • CI/ビルドパイプラインが aarch64 ビルドに対応しているか（クロスビルドやマルチアーキビルドの整備が必要か）

といった観点を施策化の前に調査しています。こうして「すぐ倒せるもの」「依存を解消してから倒すもの」「現状は倒せないもの」を切り分けたうえで、サービス単位で順次移行する形にしました。一律に倒さず、ブロッカーを見極めて移行可否を判断する のはやはり人間の仕事です。ここでは、幸いにもほとんどのものをaarch64へ移行することができました。

そして NAT Gateway のデータ処理料金最適化は、今回のなかでもとくに「分析から対策まで」の流れが綺麗に決まった取り組みでした。VPC Flow Logs を Athena で集計し、通信先を Route53 Resolver のクエリログと突き合わせて「どの宛先がデータ処理料金を押し上げているのか」を地道に特定。その結果、最大の要因が ECR Public からの image pull（CloudFront 経由）であることを突き止め、ECR Pull Through Cache の導入という具体的な対策につなげています。この調査と対策の詳細は、担当メンバーが別エントリにまとめてくれているので、ぜひそちらを読んでください。

tech.mntsq.co.jp

「コストが高い」という入口から、Flow Logs の分析で真因にたどり着き、回避策まで落とし込む——という一連の流れは、コスト最適化のお手本のような進め方になっていると思います。

見送り・保留にしたもの(人の判断が必要な部分)

AIが「やれば効く」と試算した施策でも、見送ったものがあります。 次のようなものです。

提案施策 見送り・保留の理由
Enterprise Support → Business TAM・Trusted AdvisorなどEnterprise固有の価値を踏まえ、初めから削減対象外とみていた。単体の損得だけでは測れない。
ElastiCache RI Redis→Valkey移行を予定。移行後にノードのサイズ見直しがあること。コスト削減効果も小さいことから保留。
EBS ボリューム縮小 EBSは縮小不可でデータ移行が必要。手間とリスクに対し効果が小さく コストパフォーマンスが悪い。新規構築時に適正サイズを当てる方針へ

Enterprise Support の解約は、AIの試算上は当初想定で最大級の削減効果が出る施策でした。ただ、これは最初から削減の対象外とみていたものです。TAMの伴走やインフライベント管理など、Enterprise Supportで得ている価値は請求書の削減額には現れません。サポートのランクを落とした結果として障害対応や運用の質が下がれば、コスト削減以上のものを失いかねません。だからこそ、削減額の大小にかかわらず検討対象から外していました。これは請求書の数字をいくら睨んでも出てこない、契約と事業の文脈に基づく判断 です。

EBSも同じで、一定の削減ポテンシャルはあるものの「縮小不可・要データ移行」というEBSの仕様上、費用対効果が見合わない。AIの試算は「やれば効く額」を出してくれますが、「やる価値があるか」は別問題 だということです。

取組結果: ピーク時比で20%以上のコスト削減を実現

最終的に、ここまでの取組を通じてAWSコストがもっとも高かった時期と比べて、20%以上のコスト削減を実現できました。

当初AIが施策ごとに積み上げてきた想定削減効果の合計は、これよりもかなり大きな数字でした。 「そんなわけないだろ」と思いながらも、稼働の前提や現状の構成といった追加情報をコンテキストとして渡していくことで、最終的にはかなり高い精度で削減効果を見積もれるようになりました。 そして実際に実行に移した結果が、このピーク時比 20%以上 という削減を達成できました。

これらのアクションは、見積もりから実行まで3月から4月にかけておおよそ1ヶ月程度で実施しました。 これだけの削減を短期間で実現できたのは、AIを使った見積もり支援だけでなく、その後の施策推進のために迅速に対応してくれたSREチームのメンバーのおかげです。

今後の取り組み見込み

ここまでで実施済みのコスト管理施策について、弊社を担当してもらっているTAMの方からもレビューいただきました。 短期間で大きな削減を実施できており、インフラ観点では打つべき手立てについてはひととおり打てている旨をお墨付きいただきました。

今後元々予定していた大きな構成の変更が佳境を迎えており、それが完了すればさらにかなりのコスト削減が実現できそうです。 さらに、今後の施策としては、

  1. RIの積み増し
    • 追加でさらに購入しても問題なさそうなものについてRIを購入する
  2. Savings Planの積み増し
    • Compute Savings Planの積み増しだけでなく、OpenSearchのデータノードも狙ったDatabase Savings Planのコミット

などを検討しています。

なお、この2つ目のうち、Database Savings PlanでOpenSearch のデータノードも対象にできることは、われわれも把握できておらず、担当いただいているAWS TAM2の方からのアドバイスではじめて知った選択肢です。AIに棚卸しさせても出てこず、OpenSearch はRI前提で進めていたところに、TAMの方から教わって今後の打ち手に加わったものです。「AIでも拾いきれない最新動向や、自社の構成に踏み込んだ最適な打ち手」を埋めてくれるTAMのような高度専門人材の価値は、AIで足元を固めたからこそあらためて実感できました。

まとめ AIの使いどころと、人間が握るべき判断

最後に、今回の事例から得た「コストコントロールにおけるAIとの役割分担」について振り返ってみます。

  • AIが圧倒的に速い領域（積極的に任せる）

    • 施策候補の棚卸し・ブレスト（見落としを拾う）
    • 請求データ・単価・割引を踏まえた削減効果の試算
    • 効果 × 工数 × リスクの一覧化

  • 人間が握るべき判断（任せてはいけない）

    • コミットメント期間のリスク（変動の激しい構成に3年RIを当てないなど）
    • 契約・サポート品質の文脈（Enterprise Supportのように削減額だけでは測れない価値を考慮するなど）
    • 費用対効果の閾値（EBS縮小のように「効くがやる手間が多く価値が薄い」施策への線引き）

とくに効果 × 工数 × リスクの観点からのGo/Stopの最終判断は人間が担います。 そこに取り組むだけの価値があるのかについて、具体的な数字ではあらわせない部分があるからです。 AIで棚卸しと試算を高速に回しつつ、追加のコンテキストなどを人間がAIに提供して見積もりを精緻化、人間がAIの出力した情報をもとにGo/Stopを判断する。 この分担が、今回うまく噛み合いました。

本事例が、コスト削減に取り組む際の参考になれば幸いです。

  1. AWSのPricing MCPサーバーを使ってもよいかもしれません。参考↩
  2. TAMとはTechnical Account Managerのことです。AWSのエンタープライズサポートを契約すると顧客ごとに担当としてTAMがアサインされ、さまざまな観点からの支援を提供してもらえます。2026/6時点の情報なので最新の情報や詳細については、AWS エンタープライズサポートのページを参照してください。↩
記事一覧へ