「AWS予算超過」の戦慄　“金曜朝のアラート”で冷や汗をかかない技術

AWSの年次イベント「re:Invent 2025」で、コスト最適化をテーマにしたセッションが開催された。開発者が即実践できる削減手法や自動化戦略とは。

公開 2026年01月15日 16時00分

[TechTargetジャパン]

印刷する

　「金曜の朝、今週は順調だと思っていたら、AWSの予算が超過しているというアラートが自分と上司に届いた。慌てて調査すると“異常はない”と表示された」――悪夢をこう切り出したのは、AWSのステフ・グーチ氏（シニアオプティマイゼーションアーキテクトアドボケート）だ。

　グーチ氏は2025年12月、Betsson Groupのケネス・アタード氏（エンタープライズアーキテクト）とともに、今すぐ実践できるAWSのコスト最適化、AIを使った最適化の高速化、無駄を生まない仕組み作りの3点を解説した。同社は、24の国と地域でアミューズメントサービスを展開する企業だ。この内容は、米ラスベガスで開催されたAWS（Amazon Web Services）の年次イベント「AWS re:Invent 2025」のセッション「Optimize AWS Costs: Developer Tools and Techniques」で共有されたものだ。

AWSのコスト最適化は「削る」→「自動化」→「防ぐ」の3段階で進める

併せて読みたいお薦め記事

AWSのコスト関連記事

　登壇者の2人は、以下のサービスや手法を使ったコスト最適化について共有した。

「AWS CloudTrail」

　AWS CloudTrail（以下、CloudTrail）は、AWSアカウント内での設定変更履歴や、管理イベントの記録を提供するログ監視サービスだ。「Trail」（証跡）は、ログの収集単位を指す。CloudTrailには無料プランが用意されているが、以下に注意が必要だ。

2つ目以降のTrailを作成、運用するごとに料金が発生する。
CloudTrailのイベントをSQLクエリで高速で分析できるツール「CloudTrail Lake」も有料だ。CloudTrail Lakeを、どのログを収集しているか整理しないまま使っていた場合、同一のログを何重にも保存して課金される恐れがある。

対策は？

組織に存在するAWSアカウントにひも付くCloudTrailの数とCloudTrail Lakeの使用実態を棚卸しする。
不要なCloudTrailを各アカウントから削除する。
アカウント管理サービス「AWS Organizations」の管理アカウントで作成し、組織内全アカウントのイベントを一元記録するOrganization Trailに統合する。

「Amazon Elastic Block Store」

　AWSのブロックストレージサービスAmazon Elastic Block Store（以下、Amazon EBS）は、同社の仮想マシンサービス「Amazon Elastic Compute Cloud」（EC2）のインスタンス1台に1対1で接続して使う。Amazon EBSのボリューム（ストレージの論理的な保存領域）がEC2のインスタンスと接続していなくても、存在するだけで課金される。

対策は？

EC2のインスタンスと接続していない（未アタッチ）状態のAmazon EBSを洗い出す。
重要なデータが格納されている場合、スナップショット（ファイルやストレージのある時点の状態を記録したもの）を取得する。
それ以外は削除する。これにより、「保険として残していたAmazon EBS」が課金され続けないようにできる。

不要なネットワーク

　この目的は、通信経路を作り過ぎていないか確認することにある。

ロードバランサー

　AWSのロードバランサー（負荷分散装置）「Elastic Load Balancing」（ELB）は、「スキーム設定」で、インターネットからアクセス可能であることを意味する「Internet-facing」という設定を選択できる。インターネットからアクセス可能な、“PublicなELB”には、時間当たりの基本料金などの利用料だけでなく、「IPv4」アドレスの利用料も発生する。つまり、PublicなELBを立てることと、パブリックIPv4アドレス利用料の二重課金構造になる。

ネットワークアドレス変換（NAT）ゲートウェイ

　NATゲートウェイは、仮想ネットワーク内部での通信が可能なサブネット（IPアドレスの範囲）である「プライベートサブネット」と、インターネットの間に制限付きの一方向接続を構築する。このゲートウェイの問題は、起動中に毎時課金されることだ。

「AWS Transit Gateway」

　AWS Transit Gateway（以下、TGW）は、AWS内の論理的な隔離ネットワーク「Amazon Virtual Private Cloud」（Amazon VPC）と、オンプレミスのネットワークを接続するハブとなるサービスだ。「実験的に構築したTGWを本番移行し忘れたままにした」「複数のTGWを作成し、経路が重複した」といった場合も、利用時間で料金が発生する。

対策は？

使われていないロードバランサー
役目を終えたNATゲートウェイ
不要なTransitGW

を一括棚卸し、削除する。

Right-sizing

　「性能に対してインスタンスが大きすぎないか？」と疑問を持つことが出発点になる。例えば、

CPUの使用率は5％なのに、m6i.4xlarge
メモリも全然使っていない

といった場面だ。

　m6i.4xlargeは、EC2の汎用インスタンス（M6iファミリー）の「4xlargeサイズ」で、第3世代インテルXeonスケーラブルプロセッサを搭載した高性能サーバだ。m6i.4xlargeは以下のスペックを備える。

仮想CPU（vCPU）
- 16コア（32スレッド）
メモリ
- 64GB

　m6i.4xlargeは大容量インスタンスであるにもかかわらず、CPUの使用率が平均5％という状態は、実使用率が極端に低い状態を指す。この状態はRight-sizing（適切なサイズ設定）を実施し、コストを削減できる可能性がある。

対策は？

「AWS Compute Optimizer」
- AWSの各クラウドサービスのコスト削減を支援するツール
「Cost Optimization Hub」
- AWSのコスト最適化ツール

を使用する。

過剰なサイズになっているEC2を小さくする。

Graviton

　サーバプロセッサを「Intelのままで放置していないか？」と立ち止まって考えるのがポイントだ。例えば、x86系プロセッサを搭載したサーバ（x86サーバ）を使い続けているのであれば、Armが設計した64bitのプロセッサアーキテクチャ「ARM64」を基盤とするサーバプロセッサ「Graviton」に変えるだけで以下のメリットを享受できるという。