運用管理

AWS Compute Optimizer

機械学習で CloudWatch メトリクスを分析し、EC2・EBS・Lambda・ECS のリソースサイズを最適化する推奨を提示するサービス

約 2 分で読めます

概要

AWS Compute Optimizer は、CloudWatch から収集した CPU 使用率・メモリ使用率・ネットワーク I/O などのメトリクスを機械学習モデルで分析し、EC2 インスタンス・EBS ボリューム・Lambda 関数・ECS タスクに対するライトサイジング推奨を提示するサービスです。過剰にプロビジョニングされたリソースを検出してコスト削減の機会を示すだけでなく、リソース不足によるパフォーマンス低下のリスクも警告します。さらに Savings Plans や Reserved Instances の購入推奨も提供し、オンデマンド料金からの割引率を具体的な金額で試算できます。

ML モデルが過去のメトリクスから最適解を導く仕組み

Compute Optimizer の推奨精度を支えているのは、CloudWatch メトリクスの時系列データを入力とする機械学習モデルです。デフォルトでは過去 14 日間のメトリクスを分析しますが、Enhanced Infrastructure Metrics を有効にすると最大 93 日間のデータを参照でき、月末のバッチ処理や四半期決算時のスパイクといった長期的な負荷パターンも考慮した推奨が得られます。EC2 インスタンスの場合、CPU 使用率だけでなくメモリ使用率 (CloudWatch Agent 経由)、ディスク I/O、ネットワーク帯域を総合的に評価し、同等以上のパフォーマンスを維持しつつコストが低いインスタンスタイプを提案します。たとえば m5.xlarge で CPU 使用率が常時 15% 以下なら m5.large へのダウンサイズを推奨し、年間の削減額を具体的に表示します。推奨には Over-provisioned (過剰)、Under-provisioned (不足)、Optimized (最適) の 3 段階のラベルが付与されるため、対処の優先順位を直感的に判断できます。

Lambda と ECS のライトサイジングで見落としがちなポイント

Compute Optimizer は EC2 だけでなく Lambda 関数のメモリ設定と ECS on Fargate のタスクサイズにも推奨を出します。Lambda の場合、メモリを増やすと比例して CPU パワーも割り当てられるため、メモリ使用量が少なくても CPU バウンドな処理ではメモリ増加がレイテンシ改善とコスト削減の両方に効く場合があります。Compute Optimizer はこの特性を踏まえ、実行時間とメモリ使用量の両面から最適なメモリサイズを提案します。ECS タスクについては、Fargate で設定した vCPU とメモリの組み合わせに対して、実際の使用率が低ければ小さいタスクサイズへの変更を推奨します。Azure にも同様のリソース最適化機能として Azure Advisor のコスト推奨がありますが、Compute Optimizer のように ML モデルで長期間のメトリクスを分析する仕組みは Azure Advisor にはなく、閾値ベースの単純な判定にとどまります。クラウドコスト管理の書籍 (Amazon) では、ライトサイジングの判断基準が体系的に整理されています。

Savings Plans 推奨と組織全体への展開

Compute Optimizer は個々のリソースのサイジングだけでなく、Savings Plans の購入推奨も提供します。過去の使用パターンから 1 年または 3 年のコミットメント期間ごとに最適な Savings Plans の金額を試算し、オンデマンド料金と比較した削減率を表示します。Organizations と連携すれば、管理アカウントから組織内の全メンバーアカウントの推奨を一括で確認でき、アカウントごとに個別にオプトインする手間が省けます。実務上の注意点として、Compute Optimizer の推奨はあくまで過去のメトリクスに基づく予測であり、将来のワークロード変更 (新機能リリースによるトラフィック増加、サービス廃止によるリソース削減など) は考慮されません。推奨を適用する前に、直近のロードマップや計画中のアーキテクチャ変更を確認し、推奨が妥当かどうかをチームで判断するプロセスを設けることが重要です。また、推奨の適用後は CloudWatch ダッシュボードでパフォーマンスメトリクスを 1-2 週間モニタリングし、問題がないことを確認してから次のリソースに着手する段階的なアプローチが安全です。

共有するXB!

関連する用語

AWS Cost ExplorerAmazon EC2AWS LambdaAmazon ECSAmazon EBS

関連するサービス

AWS Cost ExplorerAmazon EC2AWS LambdaAmazon CloudWatch

関連する記事

AWS の料金モデルはなぜ複雑なのか - 従量課金の裏にある経済学とゲーム理論オンデマンド、リザーブドインスタンス、スポットインスタンスという 3 層の料金構造を、航空業界のイールドマネジメントや需要予測の経済学から読み解き、料金の複雑さの合理的な理由を解説します。Auto Scaling はなぜスケールアウトは速く、スケールインは慎重なのか - 非対称な判断ロジックの設計意図EC2 Auto Scaling がスケールアウトを即座に実行する一方でスケールインに冷却期間を設ける非対称な設計の理由、フラッピング防止の仕組み、ターゲット追跡スケーリングの内部ロジックを解説します。AWS Auto Scaling で実現する需要追従型インフラ - スケーリングポリシーの設計と最適化ターゲット追跡・予測・スケジュールドの 3 種類のポリシーを使い分け、混合インスタンスポリシーでスポットを活用したコスト最適化を実現する手法を紹介します。re:Invent の発表から読む AWS の 3 年後 - サービスのライフサイクルと廃止の法則CodeCommit の新規受付停止、SimpleDB の事実上の終了など、AWS サービスにも寿命があるという事実を直視し、サービスのライフサイクル分析と「消えないサービス」を見極める技術選定の視点を提供します。AWS サービス名の由来と命名規則 - なぜ S3 は S が 3 つなのかS3、EC2、Lambda、Aurora など主要サービスの名前の由来を掘り下げ、AWS の命名規則に潜むパターン、命名の失敗例、リブランディングの歴史を雑学的に解説します。

内容が近い用語・記事

コンピュートリソース最適化 - AWS Compute Optimizer による適正サイジングAWS Compute Optimizer を使ったリソースの適正サイジングを解説。EC2 ・ Lambda ・ EBS ・ ECS on Fargate の推奨事項、コスト削減効果の試算、導入手順を紹介します。AWS Compute Optimizer で実現するリソース最適化 - インスタンスのライトサイジングCloudWatch メトリクスを ML で分析し、EC2・Lambda・EBS・ECS Fargate のリソースサイズを最適化する推奨を生成する。Graviton 移行推奨と拡張メトリクスによる精度向上の活用法を解説します。AWS Compute OptimizerML でリソースの使用状況を分析し、最適なインスタンスタイプやサイズを推奨するサービスAWS コスト管理ツール群 - Cost Explorer・Budgets・Compute Optimizer のネイティブ統合AWS は Cost Explorer、Budgets、Compute Optimizer、Trusted Advisor といったコスト管理ツールをネイティブに統合しています。Azure Cost Management や GCP の課金管理と比較し、AWS のコスト可視化と最適化の優位性を分析します。AWS Savings Plans で最大 72% のコスト削減 - Compute と EC2 Instance プランの使い分けCompute プランと EC2 Instance プランの使い分けで最大 72% のコスト削減を実現する。Cost Explorer の推奨機能と利用率・カバレッジの監視を紹介します。