書いたから…セーフ…間に合ってないけど…
今回の記事の経緯など
EC2の設定変更を検知して、意図しない変更がされる場合には設定を既定値に戻すような対応が必要になり、AWS Configについて調べました。
結論から言うと、AWS Configは使わずにEventBridgeを利用してEC2の設定変更を検知することになりました。
AWS Configとは
AWS Configはリソースの設定変更がされたときに設定値が評価され、設定によっては修復(設定値を規定値に設定すること)もできるサービスです。
例えば、アカウント内のEC2インスタンスが指定のインスタンスタイプになっているかどうかが一覧で表示できるようになります。
指定のインスタンスタイプかどうかは「準拠」「非準拠」で確認ができます。
非準拠のリソースを指定して、修復することもできます。
検知できるルールについて
検知できるルールはAWSで作成されたルールの他に、Lambdaで自分が検知したいルールを自由に作ることもできます。
(上記のスクリーンショットはAWSの管理ルールで作成したものです。)
今回AWS Configを使わなかった理由
準拠・非準拠の一覧が見れて、リソースを指定して修復ができるのはいいなと思いましたが、以下の理由から今回はAWS Configを利用するのを諦めました。
- 検知したときのパラメータにユーザ名が含まれていない
- 今回対応したかったインスタンスの設定変更でトリガーができない
もともと管理者ユーザが設定変更したときは検知や修復はしないという要件で、パラメータにユーザ名が入っていないのは厳しいという事になりました。
また、検知後すぐに修復がしたかったんですが、今回検知したかったインスタンスの設定変更でトリガーができないのもAWS Configを選ばなかった要因になりました。
今回の対応では、CloudTrailとEventBridgeでインスタンスの設定変更を検知して、Lambdaで修正するという案で進めることになりました。
まとめ
AWS Configは今回実際に利用はしませんでしたが、準拠・非準拠の状況が一覧となって確認できるのはとても良いなと思っています。
別の機会があれば利用するのを検討してみたいと思います。