はじめに
こんにちは。SCSKのふくちーぬです。
今回は、AWS Resource Groupsのライフサイクルイベントを使用して、リソースに一意に付与している共通タグの変更検知をしてみます。
AWS Resource Groupsは、AWSクラウド上のリソースをカスタムグループにまとめるためのサービスです。AWS上で散らばったリソースの整理整頓をすることができます。
例として、EC2・セキュリティグループ等の複数リソースがある場合、それらを一つのグループにまとめておくことができます。これによって、関連するAWSリソースを見つけたり、一括で管理したりするのが容易になります。
環境準備
今回は、セキュリティグループとS3を作成します。作成時に、グループとしてまとめるために一意の共通タグも付与しておきます。
タグをつけ忘れた際には、リソース作成後付与することもできますし、Tag Editorを使用して一括で付与することもできます。
| タグキー | タグ値 |
| RgName | test-system |
Resource Groupの作成
グループの作成
今回は共通タグでリソースをグループ化します。”グループリソースをプレビュー”を押下します。
先ほど作成したセキュリティグループとS3が選択されています。
グループ名を入力します。今回は、”test-group”としています。
“グループを作成”を押下します。
グループが作成されました。
グループリソース内のリンクを押下すると、それぞれのマネジメントコンソールに飛ぶことができて便利ですね。
ライフサイクルイベントの有効
通知の設定
Event Bridgeを作成する前に、ターゲットとなる(=通知先となる)SNSトピックの作成をしておきます。
SNSトピックの作成
Event Bridgeの設定
Resource Groupsのライフサイクルイベントについても、CloudTrail等のイベントの構文と記述方法は同様となります。
イベントルール内のイベントパターンの構文に迷ったら、AWSドキュメントのサンプルを参考にしてください。
イベントルールの作成
“membership-change”を”remove”に設定することで、リソースグループから外れた場合に通知ができるようになります。
検証
今回は、以下の4種類のパターンで検証を行います。
①共通タグを削除した場合
セキュリティグループの共通タグを削除してみます。
登録したメールアドレスに以下の通知がきます。
意訳すると、「EC2のセキュリティグループがリソースグループのメンバーから削除されました」という意味になります。
またResource Groupsのマネジメントコンソール上でもリソースグループ内から外されていることが分かります。もちろん共通タグを削除しただけなので、セキュリティグループ自体は存在しているので安心ください。
②共通タグを変更した場合
セキュリティグループの共通タグを付与し直してください。
次に共通タグを変更してみます。ここでは、”test-system-change”に変更しました。
登録したメールアドレスに以下の通知がきます。
内容は先ほどと同様となります。
つまり、共通タグの名前を変更した場合にも”リソースグループから外れた”と判断されることになります。
③リソースを削除した場合
セキュリティグループの共通タグを修正してください。
では、このセキュリティグループ自体を削除してください。
登録したメールアドレスに以下の通知がきます。
ここまでくると分かっている方も多いと思いますが、上記2パターンと同様の内容ですね。
つまり、リソース自体を削除した場合にも”リソースグループから外れた”と判断されることになります。
④リソースを追加した場合
最後にリソースを追加してみます。同様の方法でセキュリティグループを作成してください。
今度は、メール通知が来ないですね。
現在は”membership-change”を”remove”としているためですね。もしリソースグループに新しいリソースが追加された際にも検知したい場合は、以下のように”membership-change”に”add”を追加すれば問題ありません。
{
"source": ["aws.resource-groups"],
"detail": {
"resources": {
"membership-change": ["add","remove"]
},
"group": {
"arn": ["arn:aws:resource-groups:ap-northeast-1:<AWSアカウントID>:group/test-group"]
}
}
}
まとめ
検証の内容をまとめます。
特に③において、リソースの削除検知としても利用できないことはないです。しかし、あくまでResource Groupsの判断基準は「共通タグに変更があったかどうか」で「実際にリソースが存在しているかどうか」まで面倒は見てくれません。
CloudTrailの証跡にて該当リソースの削除APIが実行されたかどうかも併せて判断するのがよいと思われます。
| 検証 | 検知の挙動 | 備考 |
| ①共通タグを変更した場合 | リソースグループから外されたと検知される | 実際のリソースは存在する |
| ②共通タグを削除した場合 | 実際のリソースは存在する | |
| ③リソースを削除した場合 | 実際のリソースは存在しない
※リソースの削除をしても検知されるが、削除の確証として使用したい場合にはマネコンでの存在確認/CloudTrailの証跡も併用するのがよい |
|
| ④リソースを追加した場合 | 検知されない | “membershup-change”に”add”を追加することで検知可能となる |
最後に
いかがだったでしょうか。Resource Groupsのライフサイクルイベントを使用して一通りの挙動を確認しました。
プロジェクトで各種AWSリソースを指定の共通タグで付与するといったケースが一般的にあります。初期構築時には一意の共通タグを付与したものの、共通タグの変更/リソースの削除・追加オペレーションが発生することは大いに発生します。そんな時に、共通タグの管理方法の一つして導入の検討をしていただければと思います。
本記事が皆様のお役にたてば幸いです。
ではサウナラ～🔥