こんにちは、ホワイトバードです。
年度末ということもあり、AWS検証環境のクリーンアップを行うことにしました。その結果の奮闘記を簡単にまとめたいと思います。
まず、ネクストモードのAWS検証環境の現状がどうなっていたかをまとめたいと思います。設立から5年たち、AWS検証も多数行われてきた結果、残ってしまっていたリソースで毎月それなりの課金が発生していました。検証で利用中のものは大いに使えばよいと思いますが、これでは限られた資源を減らしていることになります。
AWSのご相談を受ける会社の手前、工夫してやれていることもありました。例えば、下記のようなものです。
検証環境は検証を目的にしているため、検証が終了したらリソースを削除するのが基本ルールです。しかしながら、そのルールがなされていてもこのようなものが残ってしまっていることがありました。
これらも含めて実際に削除を行っていきました。
AWS環境をクリーンアップする既存のツールにはAWS Nukeというツールがあります。こちらのツールは対象のリージョンやアカウントを指定することで一括削除が可能となりますが、一方で検証中など特定のタグが付いたリソースを対象外にしたい場合はサービスごとに指定する必要があったり、サービス間の連携が必要なリソースでタグ付けできないリソースがあるとそれを削除してしまうなどの問題があります。
検証環境のため、万が一誤って削除してもワークロードに影響を及ぼすことはありません。しかし、検証が最初からやり直しになるなど業務遅延の影響はあるため、削除は慎重に行っていく必要があります。一方で、手動での削除は現実的ではありません。したがって、今回は専用の削除スクリプトをAIを使いながら作成することにしました。
設計にあたっては、下記を意識して行うようにしました。
そして、削除ステップはこのように行うようにしました。
実装については、Kiroを使ってスクリプトを作成しました。AWS Knowledge MCP ServerとSPECモードで作成し、ほかの業務の合間に完成させました。
検証環境とはいえ、業務で使用している環境であり、実際にどのリソースが現在進行形で使用中なのかを私一人では調査しきれません。
まずはStep 5まで実施し、削除リストを作成の上チーム内へ周知を行い、除外タグの設定を行ってもらいました。
削除前日にもStep 5まで実施し、改めて確認のうえ、当日はチームで確認しながら実行していきました。
そして、気になる効果ですが執筆日時点では月の途中となりますが、やはりCloudWatch LogsとS3といったデータが多く残されていたため、2/3程度になる見込みで進んでいます。
しかしながら、日常業務で使っていたSlack通知用のLambdaが削除されていたことに気づきました・・・すみません。ということもあるので、削除は慎重に行っていくことをお勧めします。
え？ツールを公開しないのかって？自分たちの使っているリソース一覧を取得しながらやったほうがいいと思いますので、あえて非公開にしておきます。削除ツールなので、ツールの実行結果は自身で責任が取れるよう、レビューの上で実施されることをお勧めします。
ネクストモードのカルチャーの記事にある「限られた資源で働き方の常識を超えよう」 から、A penny saved is a penny earned. 節約した1セントは、稼いだ1セントと同じ価値があります。にもあるように、地味ながらこうしたコスト削減の取り組みは定期的に実施していければと思います。
ネクストモードではAWS環境のご利用のご相談も承っております。SaaS活用と合わせたAWS活用についてもご相談ください！