【AWS】AWS検証環境の掃除を優しく効率的にやってみた

» AWS » 技術
ホワイトバード先輩 ホワイトバード先輩

 こんにちは、ホワイトバードです。 

年度末ということもあり、AWS検証環境のクリーンアップを行うことにしました。その結果の奮闘記を簡単にまとめたいと思います。


AWSの検証環境、どうなっていたの？

まず、ネクストモードのAWS検証環境の現状がどうなっていたかをまとめたいと思います。設立から5年たち、AWS検証も多数行われてきた結果、残ってしまっていたリソースで毎月それなりの課金が発生していました。検証で利用中のものは大いに使えばよいと思いますが、これでは限られた資源を減らしていることになります。

工夫してできていたこと

AWSのご相談を受ける会社の手前、工夫してやれていることもありました。例えば、下記のようなものです。

  • EC2やRDSの夜間休日の自動停止
  • NATゲートウェイやパブリックIPv4アドレスは都度関連付ける
  • 検証終了後の検証リソースの削除
  • OktaによるSSOを徹底し、IAMユーザーの利用停止
  • 月の利用状況をサービスごとに可視化し、チームのSlackに投稿するようにしてエンジニアに利用状況を意識づける

残ってしまったもの

検証環境は検証を目的にしているため、検証が終了したらリソースを削除するのが基本ルールです。しかしながら、そのルールがなされていてもこのようなものが残ってしまっていることがありました。

  • ハンズオンで作成したログ類がS3やCloudWatch Logsに残っており、「失効しない」設定になっている
  • 不要なEBSやRDSのスナップショットの削除漏れ
  • ネクストモードで普段あまり利用しないリージョンの削除漏れ

これらも含めて実際に削除を行っていきました。

AWS環境の既存クリーンアップツール

AWS環境をクリーンアップする既存のツールにはAWS Nukeというツールがあります。こちらのツールは対象のリージョンやアカウントを指定することで一括削除が可能となりますが、一方で検証中など特定のタグが付いたリソースを対象外にしたい場合はサービスごとに指定する必要があったり、サービス間の連携が必要なリソースでタグ付けできないリソースがあるとそれを削除してしまうなどの問題があります。

クリーンアップツールをお手製で

検証環境のため、万が一誤って削除してもワークロードに影響を及ぼすことはありません。しかし、検証が最初からやり直しになるなど業務遅延の影響はあるため、削除は慎重に行っていく必要があります。一方で、手動での削除は現実的ではありません。したがって、今回は専用の削除スクリプトをAIを使いながら作成することにしました。

設計方針

設計にあたっては、下記を意識して行うようにしました。

  • 期間や対象のタグはパラメータで実行が可能なこと
  • 削除対象のリージョンとリソースの一覧を出力可能なこと
  • 除外タグが指定されたリソースと依存関係があるリソースを抽出すること
    • EC2にタグがつけられていたら、EC2に紐づくVPCやサブネット、セキュリティグループ、ELBなど
    • API GatewayとLambdaとDynamoDB
    • CloudFrontとS3
    • CloudFormationに付いていたら、CloudFormationのスタックの出力
  • セキュリティ系・ガバナンス系サービスはそもそも除外する
    • IAM系
    • Security Hub
    • GuardDuty
    • AWS Config
    • AWS CloudTrailとログバケット
    • Inspector
    • Systems Manager
    • Macie
    • Organizations系
  • その他、個別に除外したいサービスはパラメータで除外できるようにすること
    ※Route 53のホストゾーンや電話番号紐づいたAmazon Connectインスタンスのように、一度削除すると復旧が難しいもの

そして、削除ステップはこのように行うようにしました。

  1. 課金が発生しているリージョンの取得
  2. リージョンごとにリソースIDの一覧を取得
    CloudWatch Logsについては、数が多いため失効期間が設定されていないロググループのみを抽出
  3. リソースのうち、除外タグが作成されているものをピックアップ
  4. 除外タグの付いたリソースと依存関係のあるリソースのピックアップ
  5. Step2,3,4をマージして、削除リストを作成
  6. ドライランを実行し、削除リストのリソースが削除可能か調べる
  7. 本番削除

実装&実行

実装については、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活用についてもご相談ください！

ダウンロードする