「AWS予算超過」の戦慄 “金曜朝のアラート”で冷や汗をかかない技術：re:Invent 2025で語られた「自動化」と「予防」の鉄則

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

[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のコスト関連記事

• 年3万ドルを“ドブ捨て”課金　AWS Lambdaのコストを1円でも下げる方法は
• 「完璧な設計」なのに3000万円溶けた　AWSの失敗事例から学ぶ3つの教訓

　登壇者の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」に変えるだけで以下のメリットを享受できるという。

• 価格の安さ
• 性能

対策は？

• EC2
• リレーショナルデータベース管理システム（RDBMS）の「Amazon Relational Database Service」（Amazon RDS）
• 「AWS Lambda」（サーバレスコンピューティングツール）

を以下のインスタンスタイプに置き換える。

• m6g
  • Graviton、Graviton 2を採用したインスタンスタイプ
• c7g
  • Graviton3を採用したインスタンスタイプ
• t4g
  • Graviton 2を採用したインスタンスタイプ

Amazon S3／EBSストレージ

• 何年も前のログ
• 二度と見ない検証データ

があった場合、「捨てられるデータを捨てているか？」という考え方を持つことが肝要だ。そこで、

• 不要な「Amazon Simple Storage Service」（Amazon S3）のデータを削除する。
• 必要だが低頻度なデータは「Amazon S3 Glacier」やAmazon S3の自動階層化機能「Intelligent-Tiering」へ移行する。

　登壇者の2人は他にもさまざまなコスト最適化手法を紹介している。