ある企業が AWS 上で Amazon EKS クラスターを運用しており、Kubernetes ノードのコスト最適化を検討しています。現在は固定サイズのノードグループ（m5.xlarge、常時 20 台）で稼働していますが、夜間と週末は Pod 数が平常時の 20% 程度に減少します。ピーク時には 20 台では不足することもあります。コストを最小化しながら、ピーク時のキャパシティも自動的に確保できる最も適切な構成はどれですか？
- A. 夜間と週末に EventBridge スケジュールで Lambda を実行してノードグループのサイズを手動で変更する
- B. EKS から ECS Fargate に移行し、Pod のリソース要件に応じた従量課金に変更する
- C. Kubernetes Cluster Autoscaler を設定し、Pod の需要に応じて EKS ノードグループを自動スケール（スケールアウト/スケールイン）する。オンデマンドインスタンスとスポットインスタンスを混在させたマネージドノードグループ（または Karpenter）を設定し、夜間・週末には不要なノードを自動削除してコストを削減する
- D. ノードグループのサイズを固定で 30 台に増やし、ピーク時に備える
解答と解説を見る
正解: C
Cluster Autoscaler（またはより新しい Karpenter）は Kubernetes の Pod スケジューリングに基づいて自動的にノードを追加・削除します。スポットインスタンスとオンデマンドの混在（Spot Fleet / Managed Node Group）により、夜間・週末の削減コストを最大化できます。Karpenter はノードプロビジョニングの最適化（最小コストのインスタンスタイプ選択）も自動化します。 D: 固定 30 台への増加は常時コストが増大し、コスト最小化の要件に反します。夜間・週末の余剰キャパシティに対してもコストが発生します。 B: ECS への移行は大きなアーキテクチャ変更で、EKS の既存投資（Kubernetes マニフェスト、ツール）が無駄になります。コスト最適化のためだけにプラットフォーム移行することは過剰です。 A: 手動によるスケジュールスケーリングは、実際の負荷パターンの変動に対応できず、ピーク時の突発的な負荷増加に対応できません。
📚 関連サービスの解説: Amazon EKS