AWSコストを見直すためにやったこと

概要

AWS のコスト見直しを実施する機会がありました。
備忘録的に、やった手順を記録に残します。

前提

• スクラム開発
• 開発と本番で、別々のAWSアカウントを運用

方針

まずは、開発環境からコスト見直しを図る。

観点は、以下の二つ。

• 断捨離
  • 不要、未使用のサービスを削除していく
• コスト最適化
  • 過剰なスペックのマシンリソースを、適したスペックに下げる
  • リザーブドインスタンス、セービングプランの使用を検討する

開発環境で適用したコストカット策のうち、本番環境でも適用できそうなものは適用する。

やったこと

開発環境

1. AWS Billing のページを確認しつつ、コストの高いサービスを特定する
   • 何$ 以上を高コストと扱うかはプロジェクトの規模次第
   • 自分は$20以上を高コスト（≒改善の余地あり）と判断
2. 特定したサービス毎に、以下表の項目を埋めていく

カラム名	概説	備考
No	行番号	複数人で議論する時、番号呼びで認識合わせできて便利
サービス名	コストを見直す対象となるAWSサービス名	要約できるとﾖｼ
コスト	料金
原因	高コストとなってしまっている原因
解決手段	原因を何とかするための解決手段	複数あれば、複数書く。
対応	解決手段毎に、対応方針（即時対応/要調査/後日対応/対応しない）を決める	別途バックログを作成して対応する規模が、要調査や後日対応になるイメージ。 即対応できそうなものは、さっさとやってしまう。
本番環境へ適用するか	本コストカット策を、本番環境にも適用するか否か	低コストサービスへの移行
対応状況	対応状況（未対応/対応中/対応済み）を書く

例）

No	サービス名	コスト	原因	解決手段	対応	本番環境へ適用するか	対応状況
1	Amazon Elastic Container Service APN1-Fargate-GB-Hours 維持コスト。	USD xs.xx	非営業日以外も稼働している	営業時間中のみ、稼働させる	即時	不要	対応済み

3. 表に従って対応する
   • 即時対応可能な策は、すぐに対応する
   • 調査が必要なものは、さっと調査して結論を出す
     • 調査に時間を要する可能性がある場合、調査バックログを切り出すのもあり
   • 対応に時間を要する解決手段は、別途対応バックログを切り出して対応する

本番環境

上記まとめた表に従って、本番環境に適用するコストカット策を実施していく。

以上。

所感

いざやってみると、維持コストに相当する料金が大部分だった。
EventBridgeなどで容易に有効/無効を切り替えることが出来るサービスは、さっさと切り替えてしまった。
一方で、無効にできず、削除するしかないリソースも存在した（自分が遭遇したのは、ALB、NAT Gateway 、 VPCエンドポイント）。
これらの維持コストをカットしようとすると、ネットワーク最適化や 「有効/無効」の要領で 「作成/削除」を実装する必要がある。
この辺りは、実装にかかるコストと、実装によって浮く料金のトレードオフかな、と感じた。

解決手段について、一度表にしてしまうと、後は表を埋めるだけとなり、かなり心持が楽になった。
複数人で議論する場合も、表のように情報がまとまっていると、議論の土台（または共通認識）として機能するため議論を進めやすい。

解決手段を実施した場合の削減見込みみたいな情報も載せると、「対応」の値を含めて優先順位を決めやすそう。