組織内のIPv4アドレス(EIP)を自動通知してコスト削減する

こんにちは、西山です。

Japan AWS Ambassadors Advent Calendar 2024の3日目の記事です。

 

今年の頭にAWSのパブリックIPv4アドレスが有料化されましたね。

起動中のEC2に関連付けられているIPv4アドレスが有料化されると通知があってAWS業界大騒ぎ、組織内のIPv4アドレスを棚卸しし不要なものを削除したかと思いますが、半年以上たちそんな事件はどこへやら、いつの間にかまたIPアドレスが乱立していないでしょうか?

 

ギークフィードでもパブリックIPv4アドレスの棚卸しを行い、社内アナウンスを行いました。

毎月AWS利用料のチェックを行っていますが、アカウント単位で見るためなかなかIPアドレスには目が届きません。

有料化に伴ってIPAM(Amazon VPC IP Address Manager )が一部無料で利用できるようになりましたが、見に行くこと自体を忘れてしまいます。。

 

1つあたりのIPv4アドレスは$3.6/月ですが、みんながポコポコ使うと塵も積もってなかなかの金額になってしまいます。

とはいえパブリックIPv4アドレスの利用を禁止したいわけでもありません。

検証、本番環境以外はローカルで開発するといった開発プロセスでもないため、まずは無駄遣いをなくそうということでEIPに絞ってコスト最適化を行うことにしました。

EIPのアカウントごとの利用数、とくに関連付けられていないEIPを発見してコスト最適化することを目標にしたいと思います。

そしてそれを月一でSlackに通知して使っていなさそうなアカウントのEIPを定期的に削減していきます。

 

前提

 

今回の仕組みはAWS Organizationsを利用していることを前提としたものとなります。

正確にはAWS Configアグリゲーターを利用して、複数アカウントに対して横断でConfigでクエリできることを前提としています。

 

方針

 

以下の方針で作っていきます。

 

  • 組織内のEIPをアカウントごとに個数をリスト化する
  • アカウント名も出す(アカウントIDだけだとわからないから)
  • リソースに関連付けられていないEIPをリスト化する
  • ChatbotからSlackへ通知できるようにする
  • Step Functionsを使う(勉強のため)

 

構成

 

  1. EventBridgeからStep Functionsを定期実行
  2. ステートマシン内でConfigでリソースをクエリ
  3. Lambdaで結果を整形し、SNSトピックへパブリッシュ
  4. SNSからChatbot経由でSlackへメッセージ送信

 

 

Step Functionsステートマシンのワークフローは以下になります。

Step Functionsのデータ入出力、とくにJSONの扱いに苦労し、何度もドキュメントのinputPath, outputPath, resultPathとにらめっこしました。

 

  1. アカウントごとのEIP数を取得
  2. 1の結果リストに対して以下をMap分散実行
    1. StringをJSON parse
    2. アカウントIDからアカウント名を取得
    3. 1の結果とアカウント名を複合
  3. 2の結果を保管するpathを変更
  4. 関連付けられていないEIPリストを取得
  5. データをLambdaからSNSへパブリッシュ

 

 

コード

 

今回作成したコードは以下で公開しています。

https://github.com/ippei2480/automate-notification-for-eip

 

コードの利用方法

パラメーターの設定

 

parameters-example.tsをparameters.tsという名前にコピーします。

appParameter内の各パラメーターを以下を参照して設定します。

 

key value
account アカウントID
region リージョン
scheduleCronString 定期実行するためのcron定義
configurationAggregatorName 組織全体を検索可能なConfigのアグリゲーター名

 

デプロイ

 

cdkアプリケーションなので、

$ cdk deploy

でデプロイ可能です。

 

Chatbotの設定

 

AWS Chatbotを手動で設定します。

デプロイリソースの中にSNSトピックがあるため、そのトピックをChatbotと関連付けます。

 

 

動作確認

 

Step Functionsステートマシンを手動で実行、もしくはEventBridgeのスケジュールで実行されると、以下のような通知がSlackに投稿されます。

 

アカウントごとのEIP数は、アカウントID、EIP数、アカウント名を。

関連付けられていないEIPリストでは、アカウントID、リージョン、EIPのIPを通知します。

これを月イチで通知すれば少しでも無駄なコスト削減ができますね。

 

 

おわりに

 

今回は組織内のEIPアドレスリストをSlackに自動通知させることで、定期的な棚卸しを楽にすることができました。

この情報を元に不要と思われるEIPを削除しコスト削減をすることが可能です。

 

また、Step Functionsの勉強にもなりました。どちらかというとこちらのほうが価値があったかもしれません。

自分や社内のだれかが楽になる仕組みを今後も作りつつ勉強できればと思います。

 

最後に、メンバーにコスト意識を持ってもらうためには継続的な啓蒙が重要かと思います。

一方的なダメ出しをするのではなく、無駄をなくすためにどうすればよいかもセットで啓蒙することを心がけています。

例えば、今回のEIPのケースで開発用EC2へアタッチしsshアクセスを行っているのであれば、AWS CLIとSSM Session Managerを教えてあげることで、EIPがなくて再起動のたびにEC2のパブリックアドレスが変わっても、instanceIdでよりセキュアにインスタンスにアクセスできることを伝えるなどです。

全国の悩めるCCoEに届けば幸いです。今後も一緒にコスト最適化をしていきましょう。

この記事が気に入ったら
いいね ! しよう

Twitter で

【採用情報】一緒に働く仲間を募集しています

採用情報
ページトップへ