この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
園部です。
AWS Config Rules（ 以下、 Config Rule ） では事前に定義したルールと AWS リソースの状況を評価することが出来ます。非準拠と評価されたリソースを発見し、通知や修復アクションを実行することで、リスクを回避することが可能です。（ 詳細は、ドキュメントや Black Belt をご参照ください。)
先に述べた事前に定義するルールには以下の2種類があります。
- マネージドルール： AWS 側で用意している一般的なベストプラクティスとされるルール
- カスタムルール： lambda を利用してユーザー側で作成するルール
今回、マネージドルールに新しく8つのルールが追加されました。
Feature： AWS Config updates managed rules
Description: With this release, AWS Config supports the following managed rules- api-gw-execution-logging-enabled
- ec2-stopped-instance
- elasticache-redis-cluster-automatic-backup-check
- emr-master-no-public-ip
- rds-enhanced-monitoring-enabled
- s3-account-level-public-access-blocks
- sagemaker-endpoint-configuration-kms-key-configured
- service-vpc-endpoint-enabledFor more information, see List of AWS Config Managed Rules.
今回は全ての新しいルールを検証するのではなく ec2-stopped-instance をピックアップして、他のサービスと連携しながら対応するシナリオをやってみたいと思います。ピックアップしたルール以外が気になる方は上記のリンクからチェックしてみてください。
ec2-stopped-instance 概要
許可された日数よりも停止している EC2 の有無をチェックし、存在する場合を 非準拠 と評価します。
Checks whether there are instances stopped for more than the allowed number of days. The instance is NON_COMPLIANT if the state of the ec2 instance has been stopped for longer than the allowed number of days.
Identifier: EC2_STOPPED_INSTANCE
Trigger type: Periodic
AWS Region: All supported AWS regions
Parameters:
allowedDays (Optional) The number of days an ec2 instance can be stopped before it is NON_COMPLIANT. The default number of days is 30.
やってみる
検証シナリオ
- 本番環境アカウントであり、原則停止している EC2 は存在しない
- リカバリを実施した後、古い EC2 を削除し忘れている
- Config Rule で定期的にチェックする
- AWS Systems Manager OpsCenter( 以下、OpsCenter ) でタスク管理を行う
- 非準拠の EC2 へ対応（削除）する
CloudWatch Event で Config Rule と OpsCenter の紐付け設定
Config Rule での結果を OpsCenter へ OpsItem として登録されるように CloudWatch Event を設定します。
CloudWatch >>> ルール >>> ルールの作成 >>> イベントソースには Config Rule の内容を選択、ターゲットには OpsCenter へ OpsItem を追加する内容を選択 >>> 設定の詳細 を選択します
任意の名前を入力 >>> ルールの作成 を選択します
ステータスが アクティブ になっていることを確認します
Config ルール作成と評価実施
現在の EC2 の状況は以下の通りです。
AWS Config >>> ルール >>> ルールを追加 >>> 新しく追加となった ec2-stopped-instance を選択します
ルールのパラメータ を 0 に変更 >>> 保存 を選択します
（今回は検証のため即時発見としたいので 0 としています）
保存されると初回の評価が実行されます
ルール( ec2-stopped-instance )非準拠が発見されました!
OpsCenter でのタスク管理と対応の実施
Config Rule の画面から 「修復」アクションや、自動修復を事前に設定するなどして対応することも可能ですが、今回は OpsCenter にタスクとして登録を行い、対応を実施してみたいと思います。
AWS Systems Manager >>> OpsCenter を選択します
Config Rule の結果が OpsItem として登録されています
詳細をみていきます
関連リソースに対象となる EC2 を追加します
運用データで詳細を確認することができます
ステータス、優先度などの情報を入力します
EC2 インスタンスが不要なので削除します
ランブック >>> AWS-TerminateEC2Instance を選択 >>> 実行 を選択します
対象 EC2 インスタンスID を入力 >>> 実行 を選択します
しばらくすると完了し、 EC2 が削除されます
Config Rule の再評価を実行します
（今回は検証のため手動にて再評価を実行します）
※ 再評価する対象を既に削除しているので、リソースが見つからないと結果が出ます。
OpsCenter 側には新しくステータスが変更となった OpsItem が登録されます
ナレッジ蓄積のために、今回の対応内容を運用データへ追加します
二つの OpsItem を関連付けます
二つともステータスを 解決済み へ変更します
これで一連の発見から対応まで完了となります。
さいごに
Config Rules を利用することで、人が実施していた定期的なチェックを置き換えることも可能です。また自動化するにしても Managed Rules に要件が合うものがあればそちらを利用することで管理からも解放されます（内容の理解は必要です...）。 Managed Rules は結構たくさんあるので、一度リストを確認してみると自チームにあったものがあるかもしれないのでオススメです。
またConfig で非準拠となった際に メール や Slack に通知されているチームは多いのではないかと思います。そして、そこからチケット管理システムへ登録するケースもあるかと思います。今回、チケット管理と対応を実行出来る OpsCenter を利用したシナリオを実施しました。 OpsCenter 自体チケット（インシデント）管理としては少し物足りない部分もありはしますが OpsCenter 上で ランブック（Automation など）の実行や AWS リソースの確認が出来るため、オペレーターの負荷を下げることも可能です。
それでは、今回はこれにて失礼いたします。
5
