SAP-C02-139 · セクション 16 / タスク 3.5

Underutilized / Overutilized Resourceを特定する

Underutilized / Overutilized / Idle Resource / Unused Resource / Utilization / Rightsizing / AWS Compute Optimizer / AWS Trusted Advisor / Waste

コストベースラインを作成したら、次は、

どのリソースを
後続のコスト改善候補として
詳しく調べるべきか

を特定します。

このページでは、適正サイジングの一般原則やAWS推奨事項の使い方を最初から説明し直しません。

既存環境について得られた、

利用状況

AWS Compute Optimizerの検出結果

AWS Trusted Advisorの検出結果

業務上の必要性

を組み合わせ、

低利用

過剰利用

アイドル

未使用

適正サイジング候補

停止 / 削除候補

追加確認

へ分類します。

ゴール

AWSの検出結果だけで変更を決定するのではなく、

AWSの検出結果
+
現在の利用状況
+
業務上の必要性

から、

このリソースは
どの種類の最適化候補か

を判断できるようにします。

最終的な出力は、

リソース
↓
分類
↓
候補
↓
根拠

を持つ最適化候補一覧です。

1. コストベースラインからリソース単位へ進む

前段では、

現在コスト

サービス別コスト

使用量

コスト推移

を比較可能な基準として整理しました。

ここでは、その中から実際のリソースを確認します。

例えば、

Amazon EC2
月40万円

という情報だけでは、

40万円のうち
どこに改善余地があるか

は分かりません。

そこで、

EC2-A
EC2-B
EC2-C
...

というリソース単位まで落とし込みます。

2. 最適化候補を4つの利用状態で整理する

候補を整理するときは、まず次の状態を区別します。

状態	このページでの分類
必要だが現在能力に余裕がある	低利用
必要だが現在能力が不足している	過剰利用
存在・稼働しているが実質的な利用がほとんどない	アイドル
現在利用されておらず、業務上も不要と確認できる	未使用

ここで重要なのは、

低利用
=
削除候補

ではなく、

低利用
↓
適正サイジング候補

未使用
↓
停止 / 削除候補

のように、候補の種類を分けることです。

3. Compute Optimizerの検出結果を分類へ変換する

AWS Compute Optimizerでは、EC2インスタンスについて、

Over-provisioned

Under-provisioned

などの検出結果を確認できます。

名称だけを見ると誤解しやすいため、候補一覧へ登録するときは意味を正しく対応付けます。

4. Over-provisionedは低利用側の候補

Compute Optimizerの、

Over-provisioned

は、現在のリソース仕様の一部を縮小しても、ワークロードの性能要件を満たせると判断された状態です。

したがって、

Over-provisioned
↓
利用量が多すぎる

とは読みません。

候補一覧では、

現在も必要
+
Over-provisioned
↓
低利用側
↓
適正サイジング候補

として整理します。

5. Under-provisionedは能力不足側の候補

反対に、

Under-provisioned

は、CPU、メモリ、ネットワークなどの現在能力の少なくとも一部が、ワークロードの性能要件を満たしていない状態です。

したがって、

Under-provisioned
↓
利用量が少ない

ではありません。

候補一覧では、

現在も必要
+
Under-provisioned
↓
能力不足側
↓
適正サイジング候補

として整理します。

6. 利用率だけで削除候補にしない

例えば、

CPU使用率
非常に低い

という情報があっても、それだけでは、

不要

とは判断できません。

確認するのは、

現在も何らかの役割があるか

です。

必要なリソースなら、

低利用

として適正サイジング候補になる可能性があります。

7. Idle / Unattached / Unusedを候補分類へ利用する

現在のAWS Compute Optimizerには、アイドルリソースに関する推奨があり、検出結果として、

Idle

Unattached

Unused

などがあります。

これらも最終アクションではなく、

どの種類の候補として
確認を進めるか

を決める入力として使います。

8. Idleは必要性確認へ進める

例えば、

EC2
↓
Idle

であっても、

DR待機用途

月末処理

緊急時専用

などの役割が残っている可能性があります。

したがって、

Idle
↓
即削除

とはしません。

候補一覧では、

アイドル
+
業務上の必要性を確認

として扱います。

9. Unattached / Unusedも業務上の必要性と組み合わせる

例えばAmazon EBSボリュームが、

Unattached

と検出されていても、

将来再接続する予定

移行作業で一時保管中

復旧用途で保持

などの可能性があります。

一方、

Unattached
+
所有者確認
+
今後も不要

まで確認できれば、

未使用
↓
削除候補

として整理できます。

10. 「アイドル」と「無駄」を分ける

アイドルは、

利用状況

を表します。

無駄なコストと判断するには、

利用がほとんどない

+
現在の業務要件上も不要

という確認が必要です。

つまり、

Idle
=
利用状態

不要
=
業務上の判断

を分けます。

11. AWS Trusted Advisorも候補発見の入力として使う

AWS Trusted Advisorのコスト最適化関連チェックからも、コスト改善候補となるリソースを確認できます。

このページではTrusted Advisorの各チェック内容を再講義せず、

Trusted Advisorで
候補が検出された
↓
現在の利用状況と
業務上の必要性を確認
↓
候補一覧へ分類

という使い方に限定します。

Trusted Advisorで検出されたこと自体を、

削除確定

とは扱いません。

12. Trusted Advisorの表示件数を改善機会の総数とみなさない

現在のAWS Trusted Advisorの一部のコスト最適化チェックでは、AWS Cost Optimization Hubから得られる推奨事項について、

リソースごとに
上位の推奨アクション

が表示されます。

例えば、あるEC2インスタンスについてTrusted Advisorに、

推奨アクション
1件

だけ表示されていても、

そのリソースには
改善機会が1種類しかない

とまでは判断しません。

候補一覧では、

Trusted Advisorで
表示された上位アクション
↓
候補として記録

し、さらに詳細な判断が必要なら、関連する詳細な推奨事項を確認します。

このページで重要なのは、

Trusted Advisorに
何件表示されたか

ではなく、

対象リソースを
どの改善候補として
分類するか

です。

13. AWSの検出結果と分類を分ける

例えば、

AWSの検出結果	業務上の状況	分類
Over-provisioned	現在も必要	低利用 / 適正サイジング候補
Under-provisioned	現在も必要	能力不足 / 適正サイジング候補
Idle	DR待機用途あり	アイドル / 維持または追加確認
Unattached	今後も不要	未使用 / 削除候補
Trusted Advisorの推奨アクション	対象リソースを確認	表示された改善候補として記録

このように、

AWSの検出結果

と、

最適化候補としての分類

を同じものとして扱いません。

14. 適正サイジング候補と削除候補を区別する

候補一覧では、

現在も必要
+
能力が利用状況と合っていない
↓
適正サイジング候補

と、

現在利用されていない
+
業務上も不要
↓
停止 / 削除候補

を分けます。

具体的な変更先や変更方法は、後続の改善判断へ残します。

15. 最適化候補一覧へ残す情報

例えば、次のように整理します。

リソース	利用状況	AWSの検出結果	必要性	候補
EC2-A	継続的に低利用	Over-provisioned	必要	適正サイジング
EC2-B	ほぼ利用なし	Idle	DR待機用途	維持 / 追加確認
EBS-C	未接続	Unattached	不要確認済み	削除候補
EC2-D	能力不足	Under-provisioned	必要	適正サイジング
EC2-E	―	Trusted Advisorの推奨	要確認	表示された改善候補を記録

重要なのは、

どのAWSサービスが
推奨したか

だけではありません。

なぜその分類にしたか

を残します。

16. 判断フロー

コストベースライン
↓
リソース単位で確認
↓
AWSの検出結果あり？
↓
現在も業務上必要？
│
├─ いいえ
│   ↓
│   未使用候補
│   ↓
│   停止 / 削除候補
│
└─ はい
    ↓
    利用状況は？
    │
    ├─ 能力に余裕
    │   ↓
    │   低利用
    │   ↓
    │   適正サイジング候補
    │
    ├─ 能力不足
    │   ↓
    │   過剰利用
    │   ↓
    │   適正サイジング候補
    │
    └─ ほぼ利用なし
        ↓
        アイドル
        ↓
        待機用途などを確認
        ↓
        維持 / 追加確認 / 停止候補
↓
Trusted Advisor等の
表示結果も候補として整理
↓
根拠付きの候補一覧へ登録

17. 混同ポイント

誤った判断	このページでの判断
`Over-provisioned` = 過剰利用	現在能力が過剰なので低利用側
`Under-provisioned` = 低利用	現在能力不足なので過剰利用側
CPUが低ければ未使用	現在も必要か確認する
`Idle`なら必ず削除	待機用途などの必要性を確認する
`Unattached`なら無条件で削除	業務上も不要か確認する
AWSの検出結果 = 最終アクション	候補分類の入力として使う
Trusted Advisorに1件表示 = 改善機会も1種類だけ	上位アクションの表示であり、必要なら詳細を確認する
高利用率 = 無駄	能力不足の可能性も確認する

18. SAP-C02での判断フロー

既存環境の
コストベースラインあり
↓
リソース単位へ分解
↓
利用状況を確認
↓
Compute Optimizer /
Trusted Advisorの
検出結果を確認
↓
業務上の必要性を確認
↓
分類
├─ 低利用
├─ 過剰利用
├─ アイドル
├─ 未使用
└─ 追加確認
↓
候補
├─ 適正サイジング
├─ 維持
├─ 停止
├─ 削除
└─ 追加調査
↓
後続の改善判断へ

19. このページで扱わないこと

ここでは、

具体的な新しい
インスタンスタイプの選択

適正サイジングの
具体的な変更手順

Spot Instancesへの移行

Auto Scaling設定変更

Reserved Instances

Savings Plans

購入コミットメント

ネットワーク / データ転送コスト改善

ストレージ階層化

コスト配分タグ設計

削除操作そのもの

最終的なコスト改善施策の選択

は扱いません。

このページで完成させるのは、

利用状況
+
AWSの検出結果
+
業務上の必要性
↓
最適化候補として分類

することです。

まとめ

AWS Compute OptimizerやAWS Trusted Advisorの結果は、

そのまま実施する変更命令

ではありません。

既存リソースについて、

現在も必要か

実際にどう利用されているか

AWSは何を検出したか

を合わせて確認します。

そのうえで、

必要だが能力に余裕
→ 低利用
→ 適正サイジング候補

必要だが能力不足
→ 過剰利用
→ 適正サイジング候補

ほぼ利用なし
→ アイドル
→ 必要性を追加確認

現在利用なし
+
業務上も不要
→ 未使用
→ 停止 / 削除候補

へ分類します。

Trusted Advisorに表示される推奨アクションも候補として記録しますが、表示件数だけから改善機会の総数を決めません。

最終的に、

根拠付きの最適化候補一覧

を後続の改善判断へ渡します。

主要AWS公式資料

AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 3.5
AWS Compute Optimizer — Viewing EC2 instance recommendations
AWS Compute Optimizer — Viewing idle resource recommendations
AWS Trusted Advisor — コスト最適化チェック

理解確認

このページの内容を4問で確認します。

理解確認4問へ →