ある企業が、Amazon RDS for MySQL インスタンス(db.m5.4xlarge)を本番環境で運用しているが、AWS Compute Optimizer の分析によると CPU 使用率が常に 10〜20% 程度で過剰プロビジョニングの状態と判定された。コストを削減しながら将来の需要増加にも柔軟に対応できる最も適切な変更はどれか。
- A. RDS インスタンスを Amazon Aurora Serverless v2 に移行して ACU の自動スケールで需要に応じたコストに変更する。
- B. RDS の Multi-AZ を無効化してコストを 50% 削減する。
- C. RDS インスタンスを最も小さいインスタンスタイプ(db.t3.micro)に変更する。
- D. RDS インスタンスタイプを db.m5.xlarge(1/4 のサイズ)に変更し、AWS Compute Optimizer の推奨に従って CPU クレジットベースのバースト可能なインスタンスタイプを検討する。将来の需要増加時はインスタンスタイプを再変更する。
解答と解説を見る
正解: A
Aurora Serverless v2 は ACU(Aurora Capacity Unit)を秒単位でスケールイン・スケールアウトし、実際の使用量に応じたコストのみが発生する。現在の 10〜20% 使用率では固定インスタンスコストの大部分が無駄になっているが、Aurora Serverless v2 にすると低負荷時には最小 ACU(例: 0.5 ACU)で稼働し、将来の需要増加時は自動的にスケールアップする。柔軟な対応と最適なコストの両方を実現できる。選択肢Cの db.t3.micro は開発/テスト向けの小型インスタンスで、本番環境の信頼性と性能要件を満たさない可能性が高い。選択肢Dの db.m5.xlarge への変更はコスト削減になるが、固定サイズのままであり将来の需要増加に対して手動でのサイズ変更が必要。Aurora Serverless v2 の自動スケールほど柔軟ではない。選択肢BのMulti-AZ 無効化は本番環境での高可用性を失うリスクが非常に高く、コスト削減目的での無効化は推奨されない。
📚 関連サービスの解説: Amazon RDS ・ Amazon Aurora