AWSコスト削減のよくある質問｜中小企業が見直す設定と手順

「AWSの請求額が毎月じわじわ増えているが、どこから手を付ければいいか分からない」という相談を、AI検証や設備監視システムを運用する企業からよくいただきます。本記事では、中小企業の現場で実際に多いAWSコスト削減の疑問をQ&A形式で整理し、無駄な設定の見つけ方と削減の具体的な手順を解説します。

AI PoCや外観検査システム、センサーデータの収集基盤など、製造業の現場でもAWSを使う場面は確実に増えています。一方で「最初の見積もりより毎月の請求が高い」「何に使われているのか誰も把握していない」という状態も珍しくありません。 この記事では、設備保全・品質管理・情シスの担当者の方から実際によく受ける質問をもとに、専任のクラウド担当がいない会社でも実行できる見直しの手順をまとめます。

Q1. まず、毎月のAWS費用はどこで確認すればいいですか？

結論から言うと、最初に見るべきは請求書のPDFではなく、AWSマネジメントコンソールの「Cost Explorer」です。請求書は合計金額しか分かりませんが、Cost Explorerならサービス別・リージョン別・日別の費用をグラフで確認でき、「どのサービスが」「いつから」増えたのかを特定できます。 最初に確認する切り口は3つで十分です。第一に「サービス別の月次推移」で、EC2・S3・RDSなど上位5サービスを把握します。第二に「日別の推移」で、特定の日から急増していないかを見ます。第三に「リージョン別」で、使った覚えのないリージョンに課金が発生していないかを確認します。検証時に東京以外のリージョンで作ったリソースが放置されているケースは、実際の見直しで非常によく見つかります。 このとき、リソースに「プロジェクト名」や「環境（本番/検証）」のタグが付いていないと内訳の分析が進みません。現時点でタグ運用がなくても、見直しをきっかけに主要リソースだけでもタグを付けておくと、次回以降の確認が格段に楽になります。

Q2. 中小企業のAWSで「無駄な費用」が出やすいのはどこですか？

経験上、最も多いのは「止め忘れ・消し忘れ」です。具体的には次の5つを最初に疑ってください。

1. 検証用に立てたまま放置されたEC2インスタンス（特にGPUインスタンス）
2. インスタンス削除後も残っているEBSボリュームとスナップショット
3. 使っていないElastic IP（アタッチされていないものは課金対象）
4. 常時稼働しているNAT Gateway（1台あたり月5,000円前後＋データ処理料）
5. 保持期間が無期限のCloudWatch Logs

AIや設備監視の用途では、EC2（特にGPU）とS3のストレージが費用の大半を占めるのが典型的なパターンです。私たちがAI検証環境のコストを分析すると、おおむね次のような構成比になることが多く、上位2〜3項目を見直すだけで全体の半分以上に手を付けられます。

逆に言えば、細かいサービスを一つずつ精査する前に、費用の大きい順に上から見ていくのが鉄則です。月数百円のサービスの最適化に時間をかけるのは割に合いません。

Q3. AWSコスト削減は、何から手を付けるのが正解ですか？

手順はシンプルで、「消す → 止める → 縮める → 割引を使う」の順番です。この順番を守ることが、中小企業がAWSコスト削減で失敗しないための最大のポイントです。

1. 消す：使っていないリソース（放置インスタンス、孤立EBS、古いスナップショット、未使用Elastic IP）を削除する
2. 止める：検証環境や開発環境を夜間・休日に自動停止する
3. 縮める：CPU使用率が常に10%以下のインスタンスを小さいタイプに変更する（ライトサイジング）
4. 割引を使う：残った常時稼働分にSavings Plansなどの割引を適用する

よくある失敗は、この順番を逆にして、無駄なリソースが残ったまま1年契約の割引を結んでしまうことです。不要なものに割引を適用しても、不要な支出が少し安くなるだけです。まず1〜3を1〜2週間かけて実施し、月額が落ち着いてから割引の検討に進んでください。 判断基準の目安として、「直近30日間CPU使用率が5%未満かつネットワークI/Oがほぼゼロ」のインスタンスは停止候補、「最終アタッチから90日以上経過」のEBSやスナップショットは削除候補、と機械的にリストアップすると判断が早く進みます。

Q4. AI PoCで使うGPUインスタンスの費用を抑えるコツはありますか？

結論は「学習・検証用のGPUは、使う時間だけ起動する」です。GPUインスタンスは単価が高く、例えばg4dn.xlargeを東京リージョンで24時間稼働させると月8万円近くになりますが、外観検査モデルの学習や精度検証で実際にGPUを使っているのは平日日中の一部だけ、というケースがほとんどです。

具体的な対策は3段階あります。第一に、EventBridgeとLambda（またはInstance Scheduler）で平日9時〜19時だけ起動するスケジュール運用にする。これだけで費用は4分の1程度になります。第二に、中断されても再開できる学習ジョブならスポットインスタンスを使い、さらに最大7割程度の割引を狙う。第三に、PoC段階ではモデル学習をバッチジョブ化し、ジョブ終了時にインスタンスを自動終了させる仕組みにしておくことです。 もう一つ見落とされがちなのが、推論用に常時起動しているエンドポイントです。PoCのデモ用に立てたSageMakerエンドポイントやGPU付きの推論サーバーが、デモ終了後も数カ月動き続けていた、という事例は実際にあります。また、現場での常時推論が前提なら、クラウドに画像を送り続けるよりエッジ側で推論してクラウドには結果と異常画像だけ送る構成の方が、推論費用と転送費用の両方を抑えられることも多く、構成レベルでの比較検討をおすすめします。

Q5. センサーデータや検査画像の保存費用（S3）はどう見直せばいいですか？

結論は「ライフサイクルルールを1本設定する」ことです。S3の標準ストレージは1GBあたり月約3.6円ですが、設備のセンサー時系列データや検査画像は数TB単位になりやすく、全量を標準クラスに置き続けると保存費用だけで月数万円規模になります。 実務的な目安として、直近30日はすぐ参照するので標準クラス、30日を過ぎたらS3 Standard-IA（約半額）、90日〜180日を過ぎたらGlacier系（10分の1以下）へ自動移行するルールが出発点になります。異常検知モデルの再学習で過去データを使う場合も、「直近3〜6カ月分がすぐ読めれば十分で、それ以前は取り出しに数時間かかっても問題ない」ことがほとんどです。 あわせて確認したいのが、不完全なマルチパートアップロードの残骸と、バージョニング有効時の旧バージョンです。どちらも画面上は見えにくいのに課金され続けるため、ライフサイクルルールで「7日経過した不完全アップロードを削除」「旧バージョンを90日で削除」を設定しておくと安心です。アクセスパターンが読めない場合は、自動で最適なクラスに移動するIntelligent-Tieringを使う判断もあります。

Q6. Savings Plansやリザーブドインスタンスは中小企業でも使うべきですか？

結論は「常時稼働が確定しているリソースには使うべき、ただしQ3の手順を終えてから」です。1年契約・前払いなしのCompute Savings Plansでもオンデマンド比で2〜3割程度安くなり、設定の手間に対する効果は大きい施策です。 判断基準は明確で、「この先1年間、ほぼ確実に動き続けるか」です。本番の監視ダッシュボード用サーバー、社内AIチャットの常時稼働基盤、RDSのような止められないデータベースは対象になります。一方、PoC用のGPUインスタンスのように利用が数カ月で終わる可能性があるもの、インスタンスタイプを変える可能性が高いものは対象外です。 迷う場合は、直近3カ月の最低利用量（夜間も含めて常に動いている分）だけをカバーする控えめなコミットから始めてください。使い切れないコミットは逆に無駄になるため、「確実な分だけ契約し、半年後に見直して積み増す」運用が中小企業には現実的です。

Q7. 一度削減しても、また増えてしまいます。維持するにはどうすればいいですか？

結論は「仕組みで気づけるようにする」ことです。人の注意力に頼った運用は必ず元に戻ります。最低限、次の3つを設定してください。

1. AWS Budgetsで月額予算を設定し、実績80%到達と予測超過の時点でメール通知する
2. Cost Anomaly Detection（無料）を有効にして、急な費用増を自動検知する
3. 検証環境の自動停止スケジュールを標準化し、「夜間は止まっているのが普通」の状態にする

加えて、月1回15分でよいので「先月のサービス別上位5項目と前月差分を見る会」を定例化することをおすすめします。差分だけ見れば時間はかかりませんし、「先月からEC2が2万円増えた理由を答えられる人がいる」状態を保つこと自体が最大の抑止力になります。 新しくリソースを作るときに「プロジェクトタグ」と「停止予定日」をセットで決めるルールにしておくと、PoC終了後の消し忘れもほぼ防げます。費用管理は特別な技術ではなく、こうした小さな運用ルールの積み重ねです。

まとめ：費用の見直しは「金額」ではなく「説明できるか」で判断する

今回の質問に共通するのは、「請求額が高いこと」そのものではなく、「何にいくら使っているか説明できないこと」が本当の問題だという点です。AI検証のためのGPUに月5万円かかっていても、それが精度検証に必要な稼働なら正当な投資です。逆に、誰も使っていない検証サーバーの月1万円は、金額が小さくても純粋な無駄です。 だからこそ、見直しの最初の一歩はCost Explorerで内訳を可視化し、「消す → 止める → 縮める → 割引を使う」の順で淡々と進めることに尽きます。そして削減後は、予算アラートと月次の差分確認で元に戻らない仕組みを作る。この流れ自体は、AI PoCでも設備監視でも社内チャット基盤でも変わりません。 これからAIの検証をクラウドで始める段階の方は、最初からタグ付け・自動停止・ライフサイクルルールを組み込んだ構成にしておくと、後からの見直しコストが大幅に減ります。費用管理を「後始末」ではなく「設計の一部」として扱うことが、小さなチームでクラウドを使いこなす一番の近道です。