前提
- 金銭的なコスト削減のために、運用コストが上昇したら元も子もないので注意!!!
全体
- EC2 から、ECS(Fargate)、lambdaへの移行を検討中ならば、Compute Savings Plansを使用する
- そもそも使っていないインスタンスを停止する
EC2
- 性能が過剰ならば、より低スペックのインスタンスに変更する
- インスタンスタイプが古いのであれば、最新にする(最新のほうが安い
- 可能であれば、CPUを Graviton に変更する
- 24H稼働が不要であれば、夜間休日は停止する(検証環境や営業時間しか使わないサービスなど)
- 停止しても問題なければ、スポットインスタンスに変更する
- 1年以上使用するのであれば、リザーブドインスタンスやSavings Plansを契約する
- バッチ処理などは、ECS(fargate)やlambdaへの移行を検討する
- → そもそもEC2は運用コストが高い場合が多い
- オートスケーリンググループを使って、低負荷時はマシンを停止する
ECS(fargate)
- 性能が過剰ならば、メモリやCPUを減らす
- 可能であれば、CPUを Graviton に変更する
- 24H稼働が不要であれば、夜間休日は停止する(検証環境や営業時間しか使わないサービスなど)
- 停止しても問題なければ、Fargate Spotに変更する
- 稼働する量が決まっているならば、Savings Plansを契約する
- 処理頻度が低いのであれば、lambdaに移行する
RDS(Aurora)
- 性能が過剰ならば、インスタンスタイプを下げる
- CPUを Graviton に変更する
- 低頻度アクセスや社内利用であれば、Aurora Serverlessへ移行する
- 1年以上使用するのであれば、リザーブドインスタンスやSavings Plansを契約する
- 不要ならばバックアップ保持期間を短くする
- IOが多いならば、Aurora I/O 最適化を検討する
lambda
- メモリ使用量が過剰ならば減らす → Lambda Power Tuning
- 可能であれば、CPUを Graviton に変更する
- 実行可否をlambda内で処理しているのならば、イベントフィルタリングを使ってlambdaを実行させないようにする
- 実行頻度が高いのであれば、ECS(fargate)に移行したほうが安いかも
S3
- 不要なのに保存しているオブジェクトを廃棄する
- もしくは、数ヶ月経過後はアーカイブする
- 消えても大きく問題がないオブジェクトは、シングルAZに変更する
- アクセス頻度が低いオブジェクトは、低頻度アクセスやアーカイブに変更する
- S3Intelligent-Tieringを使って自動的にコスト最適化を行う
