Cost分析結果から改善施策を選択する

ここまでのコスト分析によって、

Unused Resource

過剰なCapacity

安定して残る使用量

中断可能な処理

高額なData Transfer

コスト帰属不足

異常支出の検出遅延

など、具体的な問題が見えてきます。

次に必要なのは、それぞれの技術をもう一度学ぶことではありません。

確認済みの分析結果
↓
原因に対応する改善候補
↓
不要な候補を除外
↓
ワークロード要件を確認
↓
削減効果・実装条件を比較
↓
Improvement Selection

という最終的な改善施策の選択です。

ゴール

何が問題？
↓
その問題へ直接作用する施策は？
↓
複数の問題がある？
↓
必要十分な改善セットを作る
↓
要件を満たす？
↓
実装可能？
↓
Improvement Selection

と判断できることがゴールです。

1. 既習の改善軸を「選択条件」として使う

重要なのは、AWS機能から使い道を探すのではなく、確認済みの問題から対応する施策を選ぶことです。

2. まず「どの問題が確認されているか」を固定する

Unused Resource 12万円
過剰なEC2 Capacity 18万円
Rightsizing後にも残る安定した必要使用量 40万円

なら、Unusedは除去、過剰CapacityはRightsizing、安定して残る使用量はPricing Model候補と分けます。単にEC2総額だけから1つの施策を選びません。

3. 1つの環境に複数の改善施策が必要な場合がある

過剰な本番EC2 → Rightsizing
Rightsizing後にも残る安定したベース使用量 → Pricing Model
別の中断可能なバッチ → Spot

それぞれが異なる確認済みの問題へ対応しているなら、必要な改善セットとして組み合わせます。

4. 根拠のない改善施策を追加しない

「安いからSpot」「割引があるからCommitment」「EC2だからRightsizing」のような選び方はしません。その施策を必要とする分析結果が実際に存在するかを確認します。

5. 既知のWasteを将来の必要使用量として扱わない

現在70万円
├─ Unused 12万円
├─ 過剰Capacity 18万円
└─ 改善後にも必要な安定使用量 40万円

既に不要・過剰と判明している利用を、将来も必要なベース使用量として扱わず、改善後にも残る必要使用量でPricing Modelを評価します。

6. ワークロード要件によって候補を除外する

性能要件
可用性要件
中断許容度
将来の利用見込み
Commitmentリスク
変更可能時間
再起動可否
ロールバック可能性

削減できるだけでなく、要件を満たし実装可能かまで確認します。

7. 直接的なコスト改善と管理改善を区別する

Unused Resource、Rightsizing、Pricing Model、Spot、Data Transfer改善は利用や構成へ直接作用します。一方、TaggingとAlertingはコスト帰属不足や検出遅延といった管理上の問題へ対応します。

8. Data Transferが主要因なら、その原因へ作用する施策を選ぶ

主要Cost DriverがInter-AZ Data Transferで、コンピューティングサイズとPricing Modelに大きな問題がないなら、Data Transferを生むTraffic Flow / Architectureを改善対象にします。

9. TaggingとAlertingは別のGapへ対応する

コスト帰属不足 → Tagging
検出遅延 → Alerting

異なるGapには異なる施策を対応させます。

10. 必要十分な改善セットを作る

Unused → 除去
過剰Capacity → Rightsizing
安定して残る使用量 → Pricing Model
Data Transfer → Traffic Flow / Architecture改善

確認された問題を取りこぼさず、根拠のない施策を含まない改善セットを作ります。

11. 改善候補は削減額だけで決めない

推定削減額だけでなく、実装労力、変更リスク、再起動要否、ロールバック可否、ワークロード要件も合わせて確認します。

12. Cost Optimization Hubは改善候補の比較材料にできる

Cost Optimization Hubでは複数のコスト最適化推奨事項を集約でき、推定月間削減額、推奨Action、実装労力、再起動要否、ロールバック可能性などを比較材料にできます。ただし推奨事項を無条件で採用せず、実ワークロード要件と変更条件を合わせて判断します。

13. 優先度は「Cost Impact × 適用可能性 × 実装条件」で比較する

大きな削減余地があっても要件上適用できなければ候補にはできません。削減効果、適用可能性、実装条件を合わせて比較します。

14. Improvement Selectionの流れ

Cost Baseline / 詳細分析
↓
確認済みCost Driver・Gap
↓
対応する改善候補
↓
不要な候補を除外
↓
複数Gapなら必要な改善セットを作る
↓
性能 / 可用性 / 中断許容度
将来利用 / Commitment
実装労力 / 変更リスクを確認
↓
改善候補を比較
↓
Improvement Selection

15. 改善後は効果を確認する

施策を適用した後は、想定していたCost Driverが実際に減少したかを確認します。ここでは選択した施策が分析結果に対して有効だったかを確認する補足として扱います。

混同ポイント

SAP-C02での判断

何が確認された？
↓
Unused？ 過剰Capacity？ 安定使用量？ 中断可能？ Data Transfer？ 配賦不足？ 検出不足？
↓
対応する改善候補は？
↓
複数Gapがある？
↓
必要十分な改善セットは？
↓
要件を満たす？
↓
削減効果と実装条件は妥当？
↓
Improvement Selection

決定打は、確認された問題へ直接作用する施策だけを組み合わせ、ワークロード要件と実装条件を満たす最終案を選ぶことです。

まとめ

確認済みCost Driver / Gap
↓
対応する改善候補
↓
必要十分な改善セット
↓
要件・制約確認
↓
削減効果・実装条件比較
↓
Improvement Selection

分析結果に根拠がある施策だけを選び、複数の問題があれば必要な改善セットを作ります。最後に削減効果、ワークロード要件、実装条件を確認して最終決定します。