5月3日。aws-nuke を使用して検証環境の大掃除をしてみる。

記事タイトルとURLをコピーする

こんにちは。
技術課の山本です。

本記事の背景

5月3日は憲法記念日です。
語呂合わせ的には ゴミ(53)の日でもあります。
ということですので、私自身が検証に利用している AWS アカウントの大掃除をすることにしました。
サーバーワークスに入社してから数年、会社が提供してくれている私の検証用 AWS アカウントには、様々な細かい消し忘れリソースがあります。
最近は、継続的に月あたり 数百円 〜 2000 円の利用料が発生していました。
余分なコンピューティングリソースを起動していると、料金もかかりますし、電気も使いますから地球環境にも良くないです。
余分なリソースの放置はセキュリティリスクにもなりますし、気持ちがモヤっとします。

aws-nuke とは

aws-nuke を使用すると、AWS アカウント内の様々なリソースをガッと削除することができます。
英語の "nuke" は 「核」という意味で、名前はちょっと物騒ですね。
AWS 公式のツールではないため、利用は自己責任です。
自身の検証環境の大掃除であるため、このツールを使用します。

事前準備として、AWS アカウントのエイリアス設定と、AWS の認証情報の基本設定 (~/.aws/credential、~/.aws/cronfig ファイルに設定するもの) が必要です。 ちなみに検証環境の削除に使う想定のツールであるため、アカウントエイリアスに "prod" を含んでいる時には、削除が動きません。

前提

筆者の環境は、Macbook です。そのため、brew で aws-nuke をインストールしています。
brew 以外の方法では、docker がメジャーなようです。
また、Linux 用のバイナリもあるようです。
詳細は、以下を参照ください。

GitHub - rebuy-de/aws-nuke: Nuke a whole AWS account and delete all its resources.

試しに東京リージョンの S3 バケットを消してみる

例としまして、東京リージョンにある S3 バケットを削除するための設定ファイルを示します。

regions:
- ap-northeast-1

account-blocklist:
- "999999999999"

accounts:
  "123456789012": {} #自身の検証用 AWS アカウントの ID を指定。

resource-types:
    targets:
    - S3Bucket

東京リージョンには "test-yamamoto-1" という S3 バケットが1つだけあります。

中には、スクリーンショットを1枚格納しています。

aws-nuke を実行してみると、アカウントエイリアスの入力を求められます。
その後に削除対象のリソースをリストアップしてくれます。
実行して見たところ、東京リージョン内にある1つの S3 バケットと、その中にあるスクリーンショットのファイルをリストアップしてくれました。

 aws-nuke -c config-sample.yml

実際に削除するには、"--no-dry-run" オプションを指定します。
実際の削除時にもう一回、アカウントエイリアスの入力を求められます。

 aws-nuke -c config-sample.yml --no-dry-run

S3 バケットと中のスクリーンショット1枚を削除したため、"2 finished" になっています。
AWS マネジメントコンソールを見ると、バケットが消えていました。

私の検証用 AWS アカウントにある、様々な細かい消し忘れリソースを削除する。

私の検証用 AWS アカウントには、様々なサービスの消し忘れリソースがあります。
そのため、まずは対象を全て洗い出してみます。

まず、設定ファイルの" resource-types: "に記述可能な削除対象サービスは、"resource-types" オプションを使用して確認できます。

aws-nuke resource-types > types.yml

400 近い結果があったため、内容は割愛します。

# 結果
ACMCertificate
ACMPCACertificateAuthority
ACMPCACertificateAuthorityState
AMGWorkspace
AMPWorkspace
APIGatewayAPIKey
・・・割愛・・・

上記の 400 近いリソースを全て記述するのが大変な場合は、除外するリソースを記述することもできます。
以下は、"resource-types:" に" excludes: " (除外)を指定して "S3Bucket"以外を全て削除する設定ファイルの例になります。

regions:
- ap-northeast-1

account-blocklist:
- "999999999999"

accounts:
  "123456789012": {} #自身の検証用 AWS アカウントの ID を指定。

resource-types:
  excludes: #削除しないリソース(除外対象)を記述
  - S3Bucket

私の場合、検証環境で動かしているようなアプリケーションはないため、設定ファイルは以下のようになりました。

regions:
- ap-northeast-1
- us-east-1
- global

account-blocklist:
- "999999999999"

accounts:
  "123456789012": {} #自身の検証用 AWS アカウントの ID を指定。

resource-types:
  excludes:
  - IAMGroup
  - IAMGroupPolicy
  - IAMGroupPolicyAttachment
  - IAMInstanceProfile
  - IAMInstanceProfileRole
  - IAMOpenIDConnectProvider
  - IAMPolicy
  - IAMRole
  - IAMRolePolicy
  - IAMRolePolicyAttachment
  - IAMSAMLProvider
  - IAMServerCertificate
  - IAMServiceSpecificCredential
  - IAMSigningCertificate
  - IAMUser
  - IAMUserAccessKey
  - IAMUserGroupAttachment
  - IAMUserPolicy
  - IAMUserPolicyAttachment
  - IAMUserSSHPublicKey
  - IAMVirtualMFADevice
  - CloudFormationStack
  - Route53HostedZone
  - S3AccessPoint
  - S3Bucket
  - S3MultipartUpload
  - S3Object

私の検証環境用の設定ファイルに関する背景

リソースの存在するリージョンとしては、

  • 東京 ( ap-northeast-1 )
  • バージニア北部( us-east-1 )
  • グローバル ( global )

の想定です。

  1. IAM を消すと aws-nuke の実行が止まってしまうことや、場合によっては AWS にログインができなくなったり、社内ツールの利用にも影響が出そうなため、丸っと対象外にしました。後ほど自身で精査することにしました。
  2. CloudFormation スタックには、 IAM ロールを作成しているものがあったため、後ほど自身で精査することにしました。
  3. Route53 には購入しているドメインがあるため、対象外としました。( 動かしているサービスはないため ACM は対象になりました。 )
  4. S3 バケットについては、最初は対象外にしていませんでした。実際に削除した時に、オブジェクト数が 200 万近くあり、aws-nuke の実行が2時間経っても終わらなかったため、対象外にしました。

aws-nuke 実行後に実施したこと

  1. aws-nuke でリストアップのみを実施して、オブジェクト数が多い S3 バケットを把握しました。S3 バケットの「空にする」ボタンを押すと、1000 ファイルずつ消してくれます。1000 ファイルあたり 3秒程度かかっていました。あるバケットには 135万ファイルほどあり、全部で2時間くらいかかりました。CloudTrail の過去ログでした。ライフサイクルポリシーの設定を忘れていたようです。AWS WAF のログも 20万ファイルほどありました。サービス期間やリクエスト数が多いと、AWS WAF のログは相当な量になりそうです。
  2. 削除から2日後に、Cost Explorer を確認し、削除後のコストが下がっていることを確認しました。削除後もコストがかかっているものがあり、確認したところ削除対象外のリージョンにリソースがありました。CloudWatch Logs で、us-west-2 にログを出しているものがあったり、us-east-2 にWAF があったりと、長年忘れ去られてきたリソースを発見しました。東京リージョンでリリースしていないサービスを試した時のものなどでした。
  3. 誤って CloudTrail の証跡設定を消してしまったため、復旧予定です。

感想

私のように、「AWSアカウントに無駄なリソースがたくさんあるものの、利用サービスが多いため、リストアップして削除するのに時間がかかる」というシーンでは、ありがたいツールでした。
リストアップするだけで、「どのサービスに何のリソースがあるのか」をテキストで把握でき、とても助かりました。

余談

珍しく怪我をしてしまい、山に登りに行けないので、少し前の写真を眺めています。

山本 哲也 (記事一覧)

カスタマーサクセス部のエンジニア(一応)

好きなサービス:ECS、ALB

趣味:トレラン、登山(たまに)