設計

reqired-tags のときと同様、自作 Lambda Function にすることにしました。
但し2つのアカウントにそれぞれ別個の Lambda function となります。次のようなものです

定時起動 Lambda function "Generator" で専用S3 bucket （以下 Bucket1）に report を書き出し

Organizations Master Account に展開

report の書き出しをトリガーに通知用 Lambda Function "Transmitter" を起動

Compliance Account に展開
Bucket1 からデータを読み出し整形、 Slack へ配信

これだと2つの別々の Accounts に分散させてしまうことになってしまいますが、せっかく専用の Compliance Account を用意しているわけですから、関連する処理は極力 Compliance Account に寄せたいと考えたところこうなりました

次に各々の Lambda Function です

Lambda function "Generator"

定時起動して Bucket1 に書き出すだけ
Organizations Master Account に展開

この命令は Compliace Account ではなく、 Organizations Master Account で実施する必要がある
Bucket1 は Organizations Master Account ではなく、 Compliance Account 側に作成されることにしている。同作成とポリシーの設定（Organizations Master Accountからの書き込み許可）は次の "Transmitter" で扱う

Lambda function "Transmitter"

Bucket1 に書き出されたら起動し、情報を整形して Slack に配信する
Compliance Account に展開

Lambda function "Generator" で書き出された Report は準拠、非準拠全ての情報が書き出されたcsv となっています
見たい情報は非準拠だけですので、そもそも前工程の書き出しをさせる時点で非準拠だけというようなオプションを指定したいのですが見当たりません。しょうがないので、当 function 内でフィルタリング機能を内蔵することにします。具体的には非準拠のみ版 csv (ここでは noncompliants.csv とします) を生成、S3 に保存します(Bucket1 とは別、Bucket2 とします)

次にメッセージのコンテンツですが、非準拠数に応じて情報量が巨大となってしまう恐れがあるので、個別のリソースごとにメッセージを投稿するなどは避けることにしました。 ※1 そのかわり、 noncompliants.csv へのアクセス方法を通知します

通知を受け取る想定ユーザは組織のコンプライアンスチームであり、 Compliance Account(の Bucket2 に保存された noncompliants.csv) へのアクセス権を得ているとします。したがって当面、同ユーザらが通知を受け取った際は、自らのアクセス権で noncompliants.csv を任意に取得、運用してもらうこととしました。そこから先の最適化は将来課題とします

実装

こちらになります。前回同様 SAM ベースです

そして各々を sam deploy しますとこのような通知になります

これが一日一回送られてきます（デフォルトの場合）
Compliace Account の権限で、通知で示されたコマンドを実行すれば非準拠の一覧が取得できます
加えて各 Sattelite accounts(Member accounts) において Effective tag policy and noncompliants に飛ぶことでも確認可能

運用イメージ

この通知受領後のコンプライアンスチームのアクションとしては、非準拠リソースを有する各 account 所管チームにたいして、通知された非準拠情報に基づき修復を促す、というイメージです。

まとめ

ここまでで、当初目指していたことは実現できたといっていいのではないかと思います。すなわち、強制や遮断、禁止といった強い規制・介入を伴わずに、組織全体に対し、タグ付けのルールを施行し、かつ Slack 通知によってコンプライアンスチームの運用負荷を極力減らす、といった仕組みづくりです

まずはこの仕組みによって、組織のタグ付け文化をベストプラクティス（※pdf注意）により近づけていく足がかりとなれば幸いです。継続できていけば、後の厳格化や自動化なども、進めやすいかもしれませんね。

このシリーズは今回で最終回となります
最後までお付き合いいただき、ありがとうございます

note

※1 前回のように非準拠リソース数が一定数以下なら個別配信する、という仕様でもいいかもしれませんが見送り