RightsizingとOptimization Visibility

1. 適正サイズ化は単なる縮小ではない

適正サイズ化はリソースを「小さくすること」ではなく、ワークロード要件に対して適切なキャパシティへ合わせることです。

アイドル / 未使用リソースの停止や削除は、適正サイズ化とは分けて考えます。

2. 平均値だけでなくワークロードサイクルを見る

CPU平均が低いからといって、すぐに縮小してはいけません。適正サイズ化では利用率の時間変化とビジネス要件を合わせて評価します。

平均使用率
        ↓
ピーク / 定期 急増
        ↓
月次 サイクル / 季節性
        ↓
パフォーマンス要件
        ↓
キャパシティ判断

見る対象にはCPU、メモリ、ネットワーク、ストレージ、IOPS、スループットなどがあります。重要なのは、短い期間だけでは見えないピークや周期性を含むワークロードサイクルを観測することです。

3. AWS Compute Optimizerは利用状況から推奨事項を作る

AWS Compute Optimizerはリソース設定と過去の使用率を分析し、検出結果や最適化の推奨事項を提示します。

リソース設定
+
過去使用率
        ↓
検出結果
+
推奨事項
+
予測使用率

EC2だけを対象とするサービスではなく、複数のリソースタイプを分析します。ただし、リソースタイプによって適正サイズ化推奨事項、アイドル推奨事項など推奨事項の種類は異なります。

4. 推奨事項がないことと最適化済みは同じではない

例えばEC2インスタンスで推奨事項が表示されていない場合でも、即座に「最適化済み（最適化済み）」と判断してはいけません。

推奨事項なし
        ↓
最適化済み ?
        ↓
必ずしもはいではない
        ↓
メトリクス履歴不足 / 分析条件未達なども確認

最適化ツールの出力を読むときは、分析対象期間と必要メトリクスが揃っているかを確認します。

5. EC2メモリを評価するにはOS側メトリクスが必要

EC2の標準CloudWatch メトリクスだけでは、OS内部のメモリ利用率を直接取得しません。Compute Optimizerでメモリを考慮したEC2の適正サイズ化を行う場合は、CloudWatchエージェントなどでメモリ メトリクスを収集します。

EC2標準メトリクス
→ CPU / ネットワークなど

メモリを判断したい
→ CloudWatchエージェント等でOS メトリクスを収集
→ Compute Optimizerが分析

CPUだけで縮小するとメモリ ボトルネックを見落とす可能性があるため、ワークロードがメモリ 機密ならメモリ メトリクスの有無が判断 要因になります。

6. 参照期間はワークロードサイクルを含む長さを選ぶ

Compute Optimizerでは分析期間を拡張できる選択肢がありますが、SAP-C02で重要なのは数値の丸暗記ではなく、観測期間がワークロードサイクルを含んでいるかです。

短い参照期間
→ 月末処理や周期ピークを見逃す可能性

ワークロードサイクルを含む参照期間
→ 通常 / ピークの両方を評価しやすい

月次バッチや季節的トラフィックがあるなら、それを観測できない短期間のメトリクスだけで適正サイズ化しないようにします。

7. 予測使用率は将来予測ではない

Compute Optimizerの予測使用率は、将来のワークロード需要を予測する値ではありません。

過去の分析期間
        ↓
推奨 リソースを
その期間に使っていたと仮定
        ↓
予測使用率

つまり推奨事項を採用した場合の過去期間に対する仮想的な使用率です。今後の製品開始、成長、季節的イベントなどの将来要件は別途アーキテクチャ要件として評価します。

8. 推奨事項はアーキテクチャ判断の入力

推奨事項がコスト削減効果を示していても、そのまま本番へ適用するのではなくパフォーマンスリスクやビジネス要件と比較します。

推奨事項
    ↓
削減効果
    +
パフォーマンス余裕
    +
ピーク / 成長
    +
ビジネス重要度
    ↓
アーキテクチャ判断

EC2の適正サイズ化では、ワークロードのリスク許容度に応じてCPU / メモリの余裕など推奨事項設定を調整できます。開発とミッションクリティカル 本番で同じ安全余裕を使う必要はありません。

9. AWS Trusted Advisorは環境全体のベストプラクティス可視性

AWS Trusted AdvisorはAWS環境を横断し、複数のベストプラクティスカテゴリで確認を行います。

主な責任は幅広いベストプラクティス可視性です。一方、一部のAWS Trusted AdvisorのチェックではCompute Optimizerの推奨事項が表示されるため、両者を完全に独立したデータソースとして考える必要はありません。

10. Compute OptimizerとAWS Trusted Advisorを使い分ける

「最適化だからどちらでも同じ」ではなく、必要な可視性の粒度で選びます。

11. S3 Storage LensはS3ストレージ全体を可視化する

S3 Storage LensはS3ストレージ全体の使用量 / アクティビティ / コスト最適化可視性を提供します。Organizationsと組み合わせることで、組織、アカウント、リージョン、バケット、ストレージ クラスなどの単位で傾向を確認できます。

組織
  ↓
アカウント
  ↓
リージョン
  ↓
バケット
  ↓
ストレージ クラス / プレフィックス等

非現行バージョン、未完了のマルチパートアップロード、ストレージ量、ライフサイクルルールの適用範囲などを使い、S3固有の最適化候補を見つけます。

12. S3 Storage Lensは日次推移を見るサービス

S3 Storage Lensのメトリクスは日次で更新されます。したがって、リクエスト障害を秒・分単位で検知するようなリアルタイム運用監視ではなく、S3全体の推移や最適化可視性に向いています。

日次の全体可視性
→ S3 Storage Lens

リアルタイム インシデント監視
→ 別の運用上の監視要件

13. S3 Storage Lensの高度なメトリクスはより深い分析に使う

無料メトリクスでも基本的なストレージ / コスト最適化メトリクスを利用できます。高度なメトリクス階層では、より高度なメトリクスカテゴリ、CloudWatchへの発行、より長い履歴などを利用できます。

プレフィックス集約やコンテキストに応じた推奨事項はダッシュボードの高度な機能として利用できますが、デフォルトメトリクスのレポートにも上位プレフィックスや推奨事項関連機能があるため、「プレフィックスという単語だけで高度なメトリクス」と機械的に判断しないことが重要です。

14. 障害モード

15. SAP-C02判断フロー

要件
↓
何を最適化するか
├─ コンピューティングリソースのサイズ / アイドル
│   → Compute Optimizer
├─ AWS環境全体のベストプラクティス
│   → AWS Trusted Advisor
└─ S3ストレージ全体のストレージ最適化
    → S3 Storage Lens
↓
使用率 / メトリクスの取得範囲は十分か
↓
ワークロードサイクル / ピークを含むか
↓
推奨事項の前提を確認
↓
パフォーマンス / リスク / 将来要件を評価
↓
適正サイズ化またはアイドルリソース対応
↓
効果を再計測

まとめ

• 適正サイズ化は縮小だけでなく、拡大や維持も含むキャパシティ適正化です。
• アイドル / 未使用リソースの停止 / 削除は適正サイズ化とは分けて評価します。
• Compute Optimizerは複数リソースタイプを扱い、リソースごとに適正サイズ化 / アイドルなど推奨事項タイプが異なります。
• EC2メモリを判断する場合はCloudWatchエージェントなどでOS側メトリクスを収集します。
• 参照期間はワークロードサイクルを含むように選びます。
• 予測使用率は将来予測ではありません。
• AWS Trusted Advisorは幅広いベストプラクティス可視性、Compute Optimizerはリソース利用状況に基づく最適化の推奨事項が中心です。
• S3 Storage LensはS3ストレージ全体の日次推移 / 最適化可視性を提供します。
• 推奨事項はアーキテクチャ判断の入力であり、ビジネス要件とリスクを評価して採用します。

主要AWS公式資料

• AWS Compute Optimizer ユーザーガイド
• AWS Trusted Advisor ユーザーガイド / 確認 リファレンス
• Amazon S3 Storage Lens ユーザーガイド
• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド