Cost要件からArchitectureを選択する

ゴール

最終的に、

AWS料金が一番安い

だけで選ぶのではなく、

料金モデル

適正サイジング

ストレージ階層化

マネージドサービス

データ転送

運用コスト

変更コスト

将来使用量

を1つのモデルへまとめ、

要件を満たす候補の中から
最も費用対効果の高いアーキテクチャ

を選択できることがゴールです。

1. 最初にコスト以外の必須要件で候補を絞る

コスト最適化は、

最安のアーキテクチャを探す

ことではありません。

まず、

パフォーマンス
可用性
セキュリティ
コンプライアンス
RTO / RPO
データ所在地要件
運用要件

などの必須条件を満たす候補だけを残します。

つまり、

要件
↓
アーキテクチャ 候補
↓
コスト比較

です。

例えば、

Single-AZ

が最も安くても、Multi-AZが必須なら比較候補には入りません。

2. 「要件を満たす最低コスト」を探す

アーキテクチャ選択では、

最低コスト

ではなく、

必須要件を満たす範囲での最低コスト

を考えます。

例えば、

この場合、

Aが最安

でも、コスト面のアーキテクチャ選択の比較対象は、

B
vs
C

です。

3. 比較条件を揃える

アーキテクチャ候補を比較するときは、

同じビジネス需要
同じ性能目標
同じ可用性要件
同じデータ量
同じトラフィック
同じ比較期間

を使用します。

例えば、

候補A
現在の過剰プロビジョニング

vs

候補B
完全に適正サイジング済み

では公平な比較になりません。

各候補を、

合理的に最適化された将来状態

へ揃えて比較します。

4. 各候補を個別に最適化してから比較する

候補Aと候補Bについて、

適正サイジング
料金モデル
ストレージ階層化
データ転送 経路
運用モデル

をそれぞれ最適化します。

重要なのは、

候補Aには最適化を適用
候補Bには未最適化状態

としないことです。

アーキテクチャ比較は、

最適化済み 候補 A
vs
最適化済み 候補 B

で行います。

5. 料金モデルはアーキテクチャの安定部分へ適用する

料金モデル自体の選び方は既習です。

ここでは、既習の料金モデルを、

各アーキテクチャで
将来も残ると見込める使用量

へ適用した状態で比較します。

つまり、

候補 A
↓
最適化済み 料金

候補 B
↓
最適化済み 料金

としてから総コストへ組み込みます。

6. 適正サイジングはすべての候補へ行う

アーキテクチャ Aが、

EC2中心

で、アーキテクチャ Bが、

マネージド / サーバーレス中心

だとしても、どちらも必要容量に合わせます。

つまり、

コンピューティング
ストレージ
データベース キャパシティ
スループット
プロビジョンドキャパシティ

について、

必要な需要
vs
設定済み キャパシティ

を揃えます。

適正サイジングされていない候補を比較に残すと、アーキテクチャそのものではなく、

単なる過剰プロビジョニング

を比較してしまいます。

7. ストレージ階層化を保存期間とアクセスパターンへ反映する

保存データについては、既習の、

アクセス頻度
取り出し要件
保持期間
オブジェクトサイズ

を使って、候補ごとに適切なストレージ階層化を適用します。

ここでも、

候補 A
すべて高頻度アクセス用ストレージ

候補 B
ライフサイクル最適化済み

という比較はしません。

同じデータ要件なら、

両候補で
合理的なストレージ戦略

を使います。

8. データ転送はアーキテクチャによって変わる

同じ処理を実現するアーキテクチャでも、

AZ配置

NAT Gateway経路

VPC Endpoint

CloudFront

リージョン配置

によってネットワークコストは変わります。

そのため、

データ量が同じ
=
データ転送コストも同じ

ではありません。

各候補について、

送信元
↓
経路
↓
送信先

を作り、既習のデータ転送モデルを反映します。

9. 既習のマネージドサービス コストモデルを候補へ適用する

マネージドサービスとセルフマネージドを、

AWS直接費用
+
残存運用コスト

で比較する考え方は既習です。

ここでは、この判断を再説明するのではなく、

候補 A
↓
既習の運用コストモデルを適用

候補 B
↓
既習の運用コストモデルを適用

した結果を、アーキテクチャ全体の総コストへ組み込みます。

重要なのは、

片方はAWS請求額
もう片方は運用費込み

のようにコスト境界を変えないことです。

10. コスト境界をすべての候補で揃える

候補によって、

AWS請求へ直接出るコスト

中央プラットフォームチームが負担するコスト

アプリケーションチームが負担するコスト

マネージドサービス料金

の見え方が異なる場合があります。

しかしアーキテクチャ比較では、

どの部署の請求に見えるか

ではなく、

組織として
そのアーキテクチャを運用するために
何が必要か

を同じ境界で比較します。

例えば、

候補 A
AWS請求は低い
中央運用チームの工数が多い

候補 B
AWS請求は高い
中央運用チームの工数が少ない

なら、中央チームの工数をAだけコスト境界の外へ出してはいけません。

比較では、

同じ対象範囲
+
同じ期間
+
同じコスト境界

へ揃えます。

11. 一時的な変更コストも比較期間へ入れる

アーキテクチャ変更には、

移行
開発
テスト
データ転送
切り替え
トレーニング

などの一時費用が発生する場合があります。

例えば、

候補 B
移行コスト
12,000 USD

で、12か月比較なら、概念上、

12,000 / 12
=
1,000 USD / 月相当

として比較できます。

36か月比較なら、

12,000 / 36
≈
333 USD / 月相当

です。

つまり、

比較期間

によってアーキテクチャの優劣が変わる可能性があります。

12. 総コストモデルを作る

アーキテクチャ候補ごとに、概念的には、

総コスト
=
コンピューティング
+
データベース
+
ストレージ
+
データ転送
+
マネージドサービス料金
+
運用工数
+
変更 / 移行コスト

を比較します。

必要に応じて、

ライセンス
サポート
バックアップ
オブザーバビリティ
セキュリティ サービス

なども追加します。

重要なのは、

候補ごとに
同じコスト境界

を使うことです。

13. コスト要因を特定する

総コストを作った後は、

どの項目が
アーキテクチャの差を作っているか

を確認します。

例えば、

候補 A

コンピューティング          20%
ストレージ           8%
データ転送    12%
データベース         25%
運用       35%

なら、主要コスト要因は、

運用
データベース

です。

一方、

候補 B

コンピューティング          35%
ストレージ          10%
データ転送     5%
データベース         40%
運用       10%

なら、別のコスト要因になります。

これにより、

何を最適化すれば
選択結果へ最も影響するか

が分かります。

14. 平均値だけでアーキテクチャを決めない

例えば、

平均トラフィック
月5 TB

だけでは、将来、

2 TB
5 TB
20 TB

のどこへ動くか分からない場合があります。

そこで、

低
想定
高

など複数シナリオで比較します。

例えば、

なら、

低ではA
想定 / 高ではB

です。

アーキテクチャ選択では、

現在値だけ

ではなく、

将来使用量の範囲

も判断材料になります。

15. 損益分岐点を確認する

2つの候補の優劣が変わる境界を確認します。

例えば、

候補 A
固定費が低い
従量費が高い

候補 B
固定費が高い
従量費が低い

なら、トラフィックが増えるとBが有利になる可能性があります。

概念的には、

A 総コスト
=
B 総コスト

となる、

トラフィック
ストレージ
使用量 時間
運用時間

を求めます。

これが、

損益分岐点

です。

16. コミットメントリスクをアーキテクチャ選択へ含める

料金モデル自体の選び方は既習です。

ここで追加するのは、

アーキテクチャの寿命

と、

コミットメント期間

の関係です。

例えば、

12か月以内に
プラットフォーム変更の可能性が高い

↓

現在アーキテクチャへ
3年コミットメント

なら、アーキテクチャ変更後に、

未使用コミットメント

が残るリスクがあります。

そのため、

各候補の最適化済み コスト
+
アーキテクチャ変更リスク
+
未使用コミットメントリスク

を最終比較へ入れます。

17. サービス選択はアーキテクチャ全体のコスト構造として評価する

候補によって、

セルフマネージド
マネージドサービス
サーバーレス

などの構成要素が異なる場合があります。

ここでは個々のサービスの料金特性を再講義せず、既習のコストモデルを適用した結果を、

直接コスト
運用コスト
データ転送
ストレージ
変更コスト
将来使用量

と同じ総コスト境界へ入れます。

したがって、

特定のサービスカテゴリだから除外

ではなく、

要件適合済みのアーキテクチャ 候補として
他のコスト要因と一緒に評価

します。

18. コスト要件には「上限」以外もある

コスト要件は、

月10,000 USD以下

だけではありません。

例えば、

初期投資を抑える

変動費中心にする

長期安定利用を割引する

人員を増やさず運用する

トラフィック増加へ追従する

予測可能な支出にする

などもコスト要件です。

そのため、

最安

だけでなく、

コスト構造

もアーキテクチャ選択へ入れます。

19. 簡略化したアーキテクチャ比較例

次の2つのアーキテクチャが、どちらもパフォーマンス・可用性・セキュリティ要件を満たすとします。

候補 A

直接コンピュート費用
2,200 USD

ストレージ
900 USD

データ転送
500 USD

データベース / インフラストラクチャ
1,600 USD

運用工数
2,400 USD

移行コスト
12か月換算
500 USD

合計：

8,100 USD / 月相当

候補 B

直接コンピュート費用
2,700 USD

ストレージ
750 USD

データ転送
350 USD

マネージドデータベース / サービス
2,300 USD

運用工数
700 USD

移行コスト
12か月換算
800 USD

合計：

7,600 USD / 月相当

候補 Aは、

直接AWS料金

だけなら低く見えます。

しかし、

運用コスト
+
移行コスト

まで同じ期間へ揃えると、候補 Bの総コストが低くなります。

これは料金表ではなく、判断方法を示す簡略例です。

20. 感度分析で選択結果を確認する

候補 Bを選ぶ前に、

トラフィック +100%

ストレージ +50%

運用 -30%

コンピューティング 需要 -40%

など、主要コスト要因を変化させます。

もし、

少し条件が変わるだけで
候補 AとBが逆転する

なら、選択は不確実性に敏感です。

一方、

複数シナリオで
候補 Bが一貫して低コスト

なら、選択の確度は上がります。

21. 見かけ上の削減を除外する

コスト最適化案では、

見かけ上の削減

を除外します。

例えば、

可用性を下げたから安くなった

必要キャパシティを削ったから安くなった

運用作業をコスト 0として扱った

移行コストを除外した

比較期間を変えた

場合は、アーキテクチャ自体のコスト効率を比較できていません。

正しい削減は、

同じ必要な成果

を維持したうえで生じる削減です。

22. アーキテクチャ決定を記録する

最終決定では、

選んだアーキテクチャ

だけを記録するのではなく、

要件

使用量 前提

比較期間

料金前提

コスト要因

運用前提

損益分岐点

選択理由

も残します。

なぜなら、

トラフィック
AWS料金
ビジネス要件
使用パターン

が変われば、最適解も変わる可能性があるためです。

23. 選択後は制御ループへ接続する

アーキテクチャ選択は、

決定
↓
終了

ではありません。

選択時に置いた、

トラフィック
使用量
コスト
運用時間
増加

という仮定を、実運用の、

コスト
使用量
予算
予測

と比較します。

つまり、

アーキテクチャ選択
↓
運用
↓
測定
↓
再評価

までをコスト最適化として扱います。

24. 代表的なアンチパターン

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

ビジネス / 技術要件
        ↓

必須要件を満たす
アーキテクチャ候補を残す
        ↓

同じ需要
同じSLA
同じ比較期間へ揃える
        ↓

各候補を個別に最適化
        ↓
適正サイジング
料金モデル
ストレージ階層化
データ転送
運用モデル

        ↓

同じコスト境界へ揃える
        ↓

AWS直接費用を計算
        ↓

運用コストを追加
        ↓

移行 / 変更コストを追加
        ↓

総コストを比較
        ↓

主要コスト要因を特定
        ↓

低 / 想定 / 高
シナリオで再計算
        ↓

損益分岐点
コミットメントリスク
将来の増加を確認
        ↓

要件を満たす候補の中から
コスト効率の高いアーキテクチャを選択
        ↓

前提 / 担当者を記録
        ↓

実際のコスト / 使用量から
継続的に再評価

まとめ

コスト要件からアーキテクチャを選択するときは、

個別サービスの単価

だけでは判断しません。

まず、

要件を満たす候補

だけを残します。

次に各候補へ、

料金モデル
適正サイジング
ストレージ階層化
データ転送最適化
運用コストモデル

を公平に適用します。

さらに、

AWS直接費用
+
運用コスト
+
変更コスト

を同じ期間・同じコスト境界で比較します。

その後、

将来使用量
感度
損益分岐点
コミットメントリスク

を確認します。

最終的には、

必要な成果を満たしながら
組織 総コストを
最も効率化できるアーキテクチャ

を選択します。

そして選択時の仮定を、

実コスト
実使用量

で継続的に検証します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 2.6
• AWS Well-Architected Framework — COST 5: Evaluate cost when selecting services
• COST05-BP02 — Analyze all components of the workload
• COST05-BP03 — Perform a thorough analysis of each component
• COST05-BP05 — Select components to optimize cost in line with organization priorities
• COST05-BP06 — Perform cost analysis for different usage over time
• COST 6 — Select the correct resource type, size, and number
• COST06-BP01 — Perform cost modeling
• COST06-BP02 — Select resource type, size, and number based on data
• AWS Well-Architected Cost Optimization Pillar — Cost effective resources