Cost・Performance・Business要件から最適化戦略を選択する

1. コスト最適化は最安化ではない

一番安い構成がビジネス要件を満たさないなら、その構成は最適化候補ではありません。

安い
↓
採用

ではない

要件を満たす？
↓ はい
トレードオフを比較
↓
コスト効率の高い候補を採用

例えば、コストを下げるための変更でレイテンシーSLOや処理期限を破るなら、その変更はアーキテクチャ判断として成立しません。

2. 必須制約と最適化の観点を分ける

最初に、候補を即座に除外する必須制約と、残った候補を比較する最適化の観点を分けます。

コストが安くても必須制約を破る候補を、比較表に残し続けてはいけません。

3. コスト可視性は判断根拠

最適化対象はコスト額だけで決めず、コスト / 使用量 / 所有責任 / 使用率 / ワークロードパターンを根拠として使います。

高コスト
+
高使用率
+
ビジネス重要
→ すぐ無駄とは判断しない

中程度のコスト
+
極端に低い使用率
+
ビジネス要件も低い
→ 最適化候補として優先評価

高コスト ≠ 無駄です。コストドライバーを特定した後、なぜそのコストが必要なのかまで確認します。

4. 最適化手段を分離する

コスト最適化には複数の手段があります。これらを一つの問題として混ぜず、それぞれの責任を分離します。

例えば既知の過剰プロビジョニングがあるなら、その大きすぎるリソースの使用量をそのまま長期コミットメントへ固定するのではなく、必要な使用規模と継続ベースラインを分けて評価します。

5. 判断順序は論理モデルであり必須の実行順ではない

理解しやすい判断モデルとして、次の順序を使います。

コスト可視性
↓
リソース規模を評価
↓
使用量パターンを評価
↓
購入選択肢を評価

ただし、これは「適正サイズ化が完全に終わるまで料金モデルを検討してはいけない」というAWS上の制約ではありません。重要なのは、既知の無駄や将来変更を無視したコミットメントを避け、継続的に再評価することです。

6. パフォーマンス要件を候補選択のガードレールにする

リソースの変更は、平均値だけでなくピーク・ワークロードサイクル・パフォーマンス要件を満たすかで判断します。

候補 A
コスト: 最安
ピーク時にSLO違反
→ 除外

候補 B
コスト: Aより高い
ピーク時もSLO達成
→ 比較対象に残す

パフォーマンスを壊す縮小は、コストが下がっても採用できません。

7. 安定使用量でも将来変更が大きいなら柔軟性を比較する

使用量が安定していることと、設定が固定されることは同じではありません。

安定ベースライン
+
ファミリー / リージョン / コンピューティングモデル変更の可能性
        ↓
高い柔軟性を持つコミットメント候補を評価

割引だけが目的ならSavings Plansを優先評価し、特定AZのキャパシティ確保などRI固有の要件がある場合にはゾーン単位のRI等も候補にします。

8. 不確実性には柔軟性自体の値がある

新規サービス、短期移行、需要が読めないワークロードでは、長期割引を最大化することより変更余地を残すことがビジネス値になる場合があります。

需要不明
アーキテクチャ変更の可能性
開始期限が近い
        ↓
柔軟な構成で開始
        ↓
実使用量を観測
        ↓
最適化を更新

オンデマンド単価が高いという理由だけで、不確実な使用量へ無理にコミットメントする必要はありません。

9. 安定ベースラインと不確実なピークを分ける

継続性が高いベースラインと、一時的・不確実なピークを同じ料金モデルへ固定する必要はありません。

使用量
│              不確実なピーク
│          ┌────────────┐
│    ┌─────┘            └─────
│────┴────────────────────────
│      安定ベースライン
└──────────────────────────── 時間

ベースラインにはコミットメント割引を評価し、変動分には柔軟性を残すという混在戦略が候補になります。

10. ワークロードをコンポーネントへ分解して混在戦略を使う

一つのアプリケーションに一つの料金モデルだけを使う必要はありません。コンポーネントごとの使用量パターンと中断許容度で分けます。

本番アプリケーション
├─ 安定ベースライン
│   └─ コミットメント 割引を評価
├─ 不確実なバースト
│   └─ オンデマンドを評価
└─ 再試行可能な非同期ワーカー
    └─ スポットを評価

アーキテクチャ選択では、ワークロード全体ではなくコンポーネント単位の要件を見ることでコストとリスクを両立できます。

11. キャパシティ確保と割引要件を分離する

特定可用性ゾーンでEC2キャパシティを確保する必要がある場合、コスト割引だけを比較しても要件を満たせません。

割引 要件
→ 料金モデル

キャパシティ 保証 要件
→ ゾーン単位のRI / キャパシティ予約など

必要なら、キャパシティ確保と適用可能な割引を別レイヤーとして組み合わせます。Savings Plans単体をキャパシティ予約として扱ってはいけません。

12. 料金割引と実行時品質を混同しない

料金モデルを変更しても、それだけでCPU性能、レイテンシー、マルチAZ、フェイルオーバー能力が向上するわけではありません。

料金モデルはアーキテクチャ要件を置き換えません。

13. ビジネスタイムラインも制約として扱う

コストを完全に最適化してから開始することが、常にビジネス全体で最適とは限りません。

3週間後に開始必須
+
需要不明
+
アーキテクチャ変更の可能性
        ↓
開始を遅らせて完全予測
ではなく
柔軟に開始して証跡を蓄積
        ↓
最適化を更新

市場投入速度とコストにはトレードオフがあります。ビジネスタイムラインを必須制約として扱う場合もあります。

14. 候補比較は制約通過後に行う

候補を比較するときは、まず必須制約を満たしているかを確認し、その後にトレードオフを比較します。

「コストスコアが最も低い候補」ではなく、すべての必須制約を満たした候補の中で最も合理的なトレードオフを選びます。

15. シナリオで統合判断する

シナリオ A：新規サービス

開始期限あり
需要予測不可
中断不可
アーキテクチャ変更の可能性あり
        ↓
柔軟に開始
↓
コスト / 使用量を観測
↓
リソース規模とコミットメントを更新

シナリオ B：安定した本番ベースライン

24時間稼働
ベースライン安定
パフォーマンス要件明確
将来のファミリー / リージョン変更あり
        ↓
パフォーマンスを守るリソース規模
+
柔軟なコミットメント候補
を比較

シナリオ C：再試行可能なバッチ

並列ジョブ
再試行可能
期限に余裕
        ↓
適正サイズ化された リソース
+
スポットを含む候補を比較

シナリオ D：特定AZキャパシティが必須

特定AZキャパシティ必須
+
安定使用量
        ↓
キャパシティ 保証を必須制約化
↓
制約を満たす候補だけでコスト比較

16. 障害モード

17. SAP-C02判断フロー

ビジネス要件を抽出
          ↓
必須制約を固定
          ↓
コスト / 使用量 / 使用率証跡
          ↓
候補を作る
          ↓
制約違反を除外
          ↓
残った候補について
コスト / パフォーマンス / 可用性 /
柔軟性 / 中断 / キャパシティ /
ビジネスタイムラインを比較
          ↓
アーキテクチャ選択
          ↓
理由を説明
          ↓
実績データで継続的に再評価

まとめ

• コスト最適化は最安化ではなく、ビジネス要件を満たす中でコスト効率の高いアーキテクチャを選ぶことです。
• 必須制約に違反する候補は、コスト比較の前に除外します。
• コスト可視性は最適化判断の根拠であり、高コストだけで無駄とは判断しません。
• 適正サイズ化はリソース使用規模、購入選択肢は使用量の購入方法を判断する別手段です。
• 安定ベースライン、不確実なピーク、中断可能なコンポーネントを分けると混在戦略を設計できます。
• 料金割引、実行時パフォーマンス、可用性、キャパシティ確保は別要件です。
• ビジネスタイムラインや将来変更もアーキテクチャ選択の制約 / トレードオフに含めます。
• 最終的には、選んだ候補だけでなく「なぜ他を除外したか」まで説明できる状態を目指します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• AWS Well-Architected Framework — コスト最適化 柱
• 最適な料金モデルの選択
• 料金モデルの分析とレビュー
• AWS コスト管理 / AWS Compute Optimizer
• AWS Savings Plans / Amazon EC2 購入オプション