ホーム パフォーマンス改善戦略

Compute Optimizer と Trusted Advisor によるパフォーマンス改善

リソース使用率に基づくサイズ適正化提案とTrusted Advisorのパフォーマンス系チェック項目の活用を解説します。

最終更新: 2026-07-28 カテゴリ: パフォーマンス改善戦略

既存システムのパフォーマンス改善は、勘や経験則ではなく、実際の使用率データに基づいて 継続的に行うべきです。本記事では2つの代表的な分析ツールを解説します。

SAA レベル:基礎概念

Compute Optimizerの基本(コスト最適化記事の復習)

  • CPU・メモリ使用率等のCloudWatchメトリクスを機械学習で分析し、EC2・EBS・Lambda・Auto Scalingグループの適正なサイズを推奨する
  • オーバープロビジョニング(コスト観点)だけでなく、**アンダープロビジョニング(パフォーマンス観点)**の検出にも使われる

SAA 試験のポイント

Compute Optimizerは、1-5のコスト最適化の文脈だけでなく、パフォーマンス問題(CPU使用率が恒常的に高く、レイテンシが悪化している)の解決策としても使われる、両面の価値を持つツールであるという理解がSAAで問われます。

Trusted Advisorの基本カテゴリ

カテゴリ内容
コスト最適化アイドルリソース、購入オプションの見直し
パフォーマンスサービスクォータへの近接、過負荷リソースの検出
セキュリティ公開されたS3バケット、緩すぎるセキュリティグループ等
耐障害性マルチAZ未設定、バックアップ未設定等
サービスクォータ各種上限への近接状況

SAP レベル:高度な設計シナリオ

パフォーマンスチェック項目の活用

SAP 試験のポイント

Trusted Advisorのパフォーマンスカテゴリでは、EBSボリュームのIOPS使用率が高すぎる、Auto Scalingグループが最大キャパシティに近づいている、といった将来のボトルネックの予兆を検出します。SAPレベルでは、これらの指摘を放置せず、サービスクォータの引き上げ申請を事前に行う(本番障害が起きてから緊急申請するのではなく)という予防的な運用が問われます。

Trusted Advisor(パフォーマンスチェック) │ 「Auto Scalingグループが最大キャパシティの90%に到達」を検出 事前対応: 最大キャパシティの引き上げ、またはサービスクォータの緩和申請 (放置した場合)本番トラフィック急増時にスケールできず障害発生

Compute Optimizerによる継続的なパフォーマンスチューニング

SAP 試験のポイント

「一度サイジングして終わり」ではなく、SAPレベルではアプリケーションの成長やトラフィックパターンの変化に応じて、Compute Optimizerの推奨事項を定期的(例: 月次)にレビューする継続的なチューニングサイクルを運用に組み込むことが求められます。特に、新機能リリース後にアクセスパターンが変化した際は、旧来のサイジングが最適でなくなっている可能性が高い点に注意が必要です。

設計上の落とし穴

「Trusted Advisorのチェック結果をダッシュボードで確認するだけ」という受動的な運用は、SAPレベルでは不十分です。Trusted AdvisorのAPIやEventBridge連携を使い、重要度の高い指摘事項を自動的にチケット管理システムに起票する、または自動修復Lambdaをトリガーする、能動的な運用への統合が問われます。

Enterpriseサポートプランでの追加機能

  • Business/Enterpriseサポートプランでは、Trusted Advisorの全チェック項目にアクセスでき、Organizations全体でのチェック結果の集約・API経由でのプログラム的な取得も可能になる
  • 大規模組織では、これを自社のダッシュボードやアラート基盤に統合し、独自の運用フローに組み込むことが一般的

まとめ

  • SAA: Compute Optimizerがコストとパフォーマンス両面の適正化提案を行うこと、Trusted Advisorの主要カテゴリを理解する。
  • SAP: パフォーマンスチェック項目を用いた予防的なクォータ管理、継続的なチューニングサイクルの運用設計ができる。

次は キャッシュ層追加・DB読み取りレプリカ活用を見ていきましょう。