目次
1. 結論
EC2 Auto Scalingは、「システムの無駄を削ぎ落とし、実力を最大限に引き出すマネージャー」です。 – 高性能: 負荷に応じて「水平スケーリング」することで、ユーザーを待たせない応答性能を維持します。 – コスト最適化: 不要な時はインスタンスを消し、さらに「スポットインスタンス」を混ぜることで、支払いを最小限に抑えます。
2. 各ドメインでの役割
高性能アーキテクチャの設計
- 動的スケーリング: CPU使用率やリクエスト数に基づき、リアルタイムで計算リソースを追加。スパイク負荷でもパフォーマンスを落とさない。
- 予測スケーリング: 機械学習でトラフィックを予測。アクセスが増える「前」に台数を増やしておくことで、起動待ちの遅延を無くす。
コスト最適化アーキテクチャの設計
- 最小限の台数管理: 需要がない時にインスタンスを自動で終了させ、無駄なオンデマンド料金を発生させない。
- 混合インスタンスポリシー: 「オンデマンド」と「スポット」を組み合わせて配置。ベース分はオンデマンド/RIで固め、変動分を格安のスポットで補うことで、コストを劇的に下げる。
- キャパシティ最適化: 多様なインスタンスタイプを混ぜて使うことで、スポットの中断リスクを抑えつつ安く運用する。
3. キーワードでの判断
| 問題文のキーワード | 疑うべきサービス/機能 | 判断理由 |
|---|---|---|
| 「予測できない負荷に対して応答時間を維持」 | 動的スケーリング | リアルタイムな拡張が必要 |
| 「最小限のコストで可用性を維持」 | 混合インスタンス (スポット併用) | 安価なリソースの活用 |
| 「決まった時間にアクセスが増える」 | スケジュールスケーリング | 事前のリソース確保 |
4. ひっかけポイント
- スケーリングの「速さ」: EC2の起動には数分かかるため、超短時間のスパイクには間に合わない（その場合は余裕を持った最小台数や予測スケーリングが必要）。
- 垂直スケーリング: インスタンスタイプを大きくするのは手動。Auto Scalingはあくまで「台数（水平）」の調整。
5. 覚え方
- 「アコーディオンのようなインフラ」。
- 曲の盛り上がり（負荷）に合わせて大きく広がり、静かなシーンでは小さくたたむ。さらに安い材料（スポット）を混ぜてコストも抑えるイメージ。
6. 関連サービス
| サービス名 | 関連する理由 |
|---|---|
| Spot Instances | Auto Scalingと組み合わせてコストを最大90%削るための相棒。 |
| AWS Compute Optimizer | ASG内のインスタンスタイプが最適（安くて高性能）かを診断してくれる。 |
| AWS Budgets | スケーリングによるコスト増を監視し、予算を超えないようにアラートを出す。 |
7. Obsidian管理メモ
- 復習ポイント: 「混合インスタンスポリシー（スポット活用）」と「予測スケーリング」は試験で非常に好まれる正解パターン。
- 関連ノート: EC2フリートとスケーリング戦略
8. HTMLファイル名
aws-auto-scaling-performance-and-cost.html
