ある企業が AWS のインフラコストを削減するため、コスト最適化プロジェクトを開始しました。AWS Cost Explorer のレコメンデーションを確認すると、本番環境の EC2 インスタンスの 40% が過去 3 か月間で CPU 使用率の平均が 5% 以下であることが分かりました。また、未使用の EBS ボリューム（デタッチ済み）が 200 以上あります。組織のコンプライアンス要件として、本番リソースの削除前に 2 段階の承認が必要です。最もコスト効率よく安全にリソースを最適化するには、どのプロセスが適切ですか？
- A. すぐに低使用率の EC2 インスタンスを停止し、デタッチされた EBS ボリュームを削除する
- B. 全 EC2 インスタンスを Spot インスタンスに変更してコストを削減し、EBS ボリュームはライフサイクルポリシーで自動スナップショット後に削除する
- C. AWS Compute Optimizer の推奨事項をエクスポートし、低使用率 EC2 インスタンスの詳細な使用状況レポートを作成する。承認ワークフロー（ServiceNow や JIRA など変更管理システム）に変更申請を提出し、2 段階の承認後に AWS Systems Manager Automation でインスタンスタイプのダウンサイジングまたは停止を実行する。未使用 EBS ボリュームは AWS Config ルールとリメディエーションで検出・スナップショット作成後に削除する
- D. Reserved Instance への切り替えで低使用率インスタンスのコストを削減し、EBS ボリュームは現状維持する
解答と解説を見る
正解: C
Compute Optimizer のエクスポートで詳細なデータをチームと共有し、変更管理システムとの統合で 2 段階承認を実現します。承認後の Systems Manager Automation で安全にダウンサイジングを実行し、Config リメディエーションで EBS ボリュームを自動的にスナップショット後に削除することで、データ保護と運用コンプライアンスを両立できます。 A: 承認なしの即時削除は 2 段階承認のコンプライアンス要件に反し、本番システムに影響を与えるリスクがあります。 D: Reserved Instance への切り替えはコスト削減に有効ですが、実際に低使用率のインスタンスへの投資はコスト最適化の観点では非効率です。ダウンサイジングの方が長期的に効果的です。 B: 本番インスタンスを Spot に変更することは、Spot の中断リスクにより本番システムの安定性を損なう可能性があり、一般的に本番ワークロードには推奨されません。
📚 関連サービスの解説: Amazon EC2 ・ AWS Systems Manager