第 12 章 コストを最適化したアーキテクチャの設計（20%）
コンピューティングのコスト
この章で学ぶこと
- AWS の購入オプション（スポットインスタンス、リザーブドインスタンス、Savings Plans）
- 分散コンピューティングの戦略（エッジ処理）
- ハイブリッドのコンピューティングオプション（Outposts、Snowball Edge）
- インスタンスのタイプ・ファミリー・サイズ（メモリ最適化、コンピューティング最適化、仮想化）
- コンピューティング使用率の最適化（コンテナ、サーバーレス、マイクロサービス）
この章に出てくる用語（1 件）
- スポットインスタンス
- AWS の余っている容量を、安く借りる仕組み。 最大で 9 割ほど安くなるが、容量が必要になったら 2 分前の通知で止められる。止まって困らない処理に限って使う。複数のインスタンスタイプ・複数の AZ を候補にしておくと、中断されにくくなる。
12-1 買い方は 4 つ
同じインスタンスでも、買い方を変えるだけで値段が変わる。判断の軸は「どれだけ約束できるか」と「中断されても平気か」だ。
| 買い方 | 約束すること | 安さ | 向く場面 |
|---|---|---|---|
| オンデマンド | 何も約束しない | 基準 | 読めない負荷・短期・検証 |
| Savings Plans | 1 年か 3 年、一定額を使うと約束 | 大きく下がる | 使い続けるのは確実だが、何を使うかは変わるかもしれない |
| リザーブドインスタンス | 1 年か 3 年、特定の条件で使うと約束 | 大きく下がる | 構成が固定された本番（容量の予約もできる） |
| スポットインスタンス | 空きがあるときだけ借りる | 最も安い（最大 9 割引） | 中断されても平気な処理 |
Savings Plans とリザーブドインスタンスは似ているが、縛りの形が違う。
| Savings Plans | リザーブドインスタンス | |
|---|---|---|
| 約束の単位 | 1 時間あたりの金額 | インスタンスの条件（タイプ・リージョンなど） |
| 柔軟さ | Compute タイプならリージョンもファミリーも自由。Fargate・Lambda にも効く | 標準 RI は変更できない／コンバーティブル RI は交換できる |
| 容量の予約 | できない | ゾーン指定の RI ならできる |
試験では
「容量を確実に確保したい」はリザーブドインスタンス（ゾーン指定）かオンデマンドキャパシティ予約。Savings Plans は割引だけで容量は押さえない。ここを取り違えた選択肢が出る。
補足
Compute Savings Plans は Fargate と Lambda にも効く。「コンテナやサーバーレスに寄せたが、割引も効かせたい」という要件で出てくる。EC2 Instance Savings Plans は対象が EC2 に限られるぶん割引率が高い。
12-2 スポットインスタンス
| 使える | 使えない |
|---|---|
| バッチ処理・データ処理（やり直せる） | データベース（止まると壊れる） |
| CI / CD のビルド | 状態を持つサーバー（セッションが消える） |
| 機械学習の学習（チェックポイントを取る） | 常に一定の台数が要る本番の中核 |
| ステートレスな Web の一部（ASG で混ぜる） | ライセンスで固定が必要なもの |
補足
ASG ではオンデマンドとスポットを混ぜられる。「最低 N 台はオンデマンド、増える分はスポット」と書けば、安くしつつ、中断されても最低限は残る。コストと可用性を両立させたい設問での定番の答え。
12-3 専有が要るとき
| Dedicated Host | Dedicated Instance | |
|---|---|---|
| 何を専有するか | 物理サーバーそのもの | ハードウェアは専有だが、物理サーバーは意識しない |
| ソケット・コアが見えるか | 見える | 見えない |
| 向く場面 | ソケット単位・コア単位のライセンス持ち込み（BYOL） | 他社と同居したくないだけのとき |
| 費用 | 最も高い | 高い |
試験では
「既存の Windows / Oracle のライセンスを持ち込みたい」は Dedicated Host。ライセンスが物理コア数で数えられるため、物理サーバーが見えないと持ち込めない。
12-4 大きさを合わせる
買い方の次に効くのが適正化（right sizing）だ。多くの環境では、使われていない余裕に払っている。
- 測る ―― CloudWatch の指標と AWS Compute Optimizer で使用率を見る。
- 落とす ―― 使用率が低いインスタンスを 1 段小さくする。
- 世代を上げる ―― 新しい世代のほうが安くて速いことが多い。
- Graviton（ARM）を検討する ―― 同等の性能でより安いことが多い。対応していないソフトもあるので、動作確認は要る。
試験では
「コストを下げたいが性能は落としたくない」には、新しい世代への移行と Graviton がよく効く。単純に小さくする選択肢だけでなく、この方向も見る。
12-5 動いている時間を減らす
| 手 | 効く場面 | 注意 |
|---|---|---|
| 夜間・休日に止める（スケジュール） | 開発・検証環境 | ASG のスケジュールか Instance Scheduler で自動化 |
| ハイバネート | 起動に時間がかかるが使う時間は短い | メモリを EBS に保存するので EBS 料金は続く |
| サーバーレスに寄せる | 使用量に大きな波がある | 待っている時間に課金されない |
| Auto Scaling で下限を下げる | 夜間のアクセスが少ない | 最小台数を見直す |
補足
EC2 を停止しても EBS の課金は続く。「止めたのに請求が減らない」という設問の定番で、完全に止めたいなら削除（スナップショットを取ってから）になる。
12-6 オンプレに置くという選択
| 選択肢 | コストの観点での意味 |
|---|---|
| AWS Outposts | データを出せない要件を満たしつつ AWS の運用に寄せる。安くはならない |
| AWS Snowball Edge | 現地で処理して、結果だけ送る。転送料と時間を減らす |
| エッジでの処理 | 送るデータ量そのものを減らす（IoT など） |
12-7 選び方をまとめる
| 問題文に出る語 | 答えの方向 |
|---|---|
| 1 年以上使い続けるのは確実 | Savings Plans |
| 構成が固定・容量も確保したい | リザーブドインスタンス（ゾーン指定） |
| Fargate や Lambda にも割引を効かせたい | Compute Savings Plans |
| 中断されても平気なバッチ | スポットインスタンス |
| 安くしたいが最低限は残したい | ASG でオンデマンドとスポットを混ぜる |
| Windows / Oracle のライセンスを持ち込む | Dedicated Host |
| 使用率が低いインスタンスがある | Compute Optimizer で適正化・世代を上げる |
| 性能を落とさず安く | 新しい世代／Graviton |
| 開発環境の費用を下げたい | 夜間・休日に止める（スケジュール） |
| 使用量に大きな波がある | サーバーレス（Lambda・Fargate）へ |
| 止めたのに請求が減らない | EBS ボリュームが残っている |
シナリオ演習
演習 12-1
夜間に 6 時間かかる集計バッチを毎日動かしている。途中で止まってもやり直せる。費用を最小にしたい。
補足
答え：スポットインスタンス（または AWS Batch とスポットの組み合わせ）で動かす。
「止まってもやり直せる」がスポットを指している。リザーブドや Savings Plans は常時稼働する部分に効くもので、1 日 6 時間のバッチには向かない。
演習 12-2
本番の Web サーバーは 24 時間稼働で、今後 3 年は使い続けることが決まっている。ただし将来インスタンスファミリーを変える可能性がある。
補足
答え：Compute Savings Plans を 3 年で購入する。
標準リザーブドインスタンスはファミリーを固定するので、変える可能性があるという条件に合わない。Compute Savings Plans ならファミリーもリージョンも変えられる。
この章のまとめ
- 最も安い購入オプション
- スポットの中断前に出る通知
- Savings Plans が約束するもの
- リザーブドインスタンスが約束するもの
- Savings Plans で容量を確保できるか
- 容量を確保できる買い方
この端末にだけ保存されます（登録不要）