本記事は BIPROGY/ユニアデックス 社内 AWS コミュニティ「BIPROGY AWS Ambassador」の定期投稿企画第 8 回目の記事です。
他の記事は BIPROGY_AWS_Ambassador タグ、あるいは弊社の Organization ページからご覧ください。
はじめに
AWS Config を使用してリソースの変更やコンプライアンスを監視している際、
非準拠リソースを迅速に検知し、適切な担当者に通知することは非常に重要です。
本記事では、AWS Config の非準拠判定を通知する 5 つの方法と、それぞれの特徴や実装方法について紹介します。
※本記事は 2025 年 11 月時点 の情報を元に作成しています。
5 つの方法
- Config 標準の通知機能
- EventBridge + SNS
- EventBridge + Lambda + SNS
- EventBridge（入力トランスフォーマー）+ SNS
- AWS UserNotification を使用した通知
1. Config 標準の通知機能
概要
AWS Config には標準で通知機能が備わっており、設定変更や評価結果を Amazon SNS トピック経由で通知できます。AWS Config の配信チャネルから簡単に有効化できる、シンプルな方法です。
設定手順
前提条件
■ AWS Config ルール、SNS トピック（サブスクリプション：自身の Eメールなど）は設定済み
■ 適切な権限が設定済み（Config の IAM ロールや SNS のリソースベースポリシー）
- [AWS Config コンソール] ＞ [設定] → [データと配信」を [編集]
- [Amazon SNS トピックへのストリーム設定の変更と通知]を有効化 & 宛先 SNS トピックを指定し [保存]
以上で設定完了です。
通知イメージ
特徴
この方法は設定が非常に簡単ですが、以下の課題があります。
- 非準拠以外も含む全ての設定変更イベントが通知される
- 通知が多すぎて重要なアラートが埋もれる
- 通知の件名・本文がカスタマイズできない
- JSON がそのまま送られ、可読性が低い
非準拠イベントのみを対象にした通知を行いたい場合には不向きです。
アラート疲れを起こし、重要な通知を見逃すリスクが高まります。
2. EventBridge + SNS
概要
Amazon EventBridge を使用して、AWS Config の非準拠発生イベントのみをフィルタリングし、SNS トピック経由で通知する方法です。
設定手順
前提条件
■ AWS Config ルール、SNS トピック（サブスクリプション = 自身の E-mail 等）は設定済み
■ 適切な権限が設定済み（Config の IAM ロールや SNS のリソースベースポリシー）
■ EventBridge ルールの作成手順
-
EventBridge コンソール ＞ [バス] ＞ [ルール] より [ルールの作成]を選択
-
ルールタイプ [イベントパターンを持つルール] を選択
-
イベントパターンを以下のように設定（JSON 構文は後述）
-
ターゲットにSNSトピックを指定
-
[ルールを作成] し設定完了
{
"source": ["aws.config"],
"detail-type": ["Config Rules Compliance Change"],
"detail": {
"messageType": ["ComplianceChangeNotification"],
"newEvaluationResult": {
"complianceType": ["NON_COMPLIANT"]
}
}
}
通知イメージ
特徴
「1. Config 標準の通知機能」と比較して、非準拠イベントのみ通知できる点が大きな利点です。設定もシンプルなため運用負荷は低めです。
ただし次の課題が残ります。
- 通知の件名・本文がカスタマイズできない
- JSON がそのまま送られ、可読性が低い
簡易的な通知としては十分ですが、通知内容を整形したい場合は次の方法 3 を検討してください。
3. EventBridge + Lambda + SNS
概要
EventBridge で非準拠イベントを検知し、Lambda で通知内容を整形して SNS 送信する方法です。Lambda を経由することで、メールの件名や本文を柔軟にカスタマイズできます。
設定手順
前提条件
■ AWS Config ルール、SNS トピック（サブスクリプション：自身の Eメールなど）は設定済み
■ 適切な権限が設定済み（Config の IAM ロールや SNS のリソースベースポリシー、Lambda 関数の実行 IAM ロール）
■ Lambda 関数の作成手順
後程、EventBridge ルールのターゲットとして Lambda 関数を指定するため、先に Lambda から作成します。今回は Python での一例を紹介します。
※本記事では Lambda 関数の作成手順の詳細は省略しております。詳細手順については下記公式ドキュメントをご参照ください。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/getting-started.html#getting-started-create-function
import json
import boto3
import os
# 環境変数より SNS トピック ARN を取得
sns_topic_arn = os.environ['SNS_TOPIC_ARN']
def lambda_handler(event, context):
sns = boto3.client('sns')
# EventBridge イベントから必要な情報を抽出
# デフォルト値「不明」
detail = event.get('detail', {})
resource_type = detail.get('resourceType', '不明')
resource_id = detail.get('resourceId', '不明')
rule_name = detail.get('configRuleName', '不明')
account_id = detail.get('awsAccountId', '不明')
# メール件名と本文の作成
subject = f"【要確認】[Config] 非準拠リソース検出: {resource_id}"
message = f"""
AWS Config により、以下のリソースが非準拠と判定されました。
リソースタイプ: {resource_type}
リソース ID: {resource_id}
適用ルール: {rule_name}
AWSアカウント ID: {account_id}
詳細は AWS Config コンソールにてご確認ください。
"""
# SNS経由でメール通知を送信
response = sns.publish(
TopicArn=sns_topic_arn,
Subject=subject,
Message=message
)
return {
'statusCode': 200,
'body': json.dumps('SNS通知を送信しました')
}
■ EventBridge ルールの作成手順
「EventBridge + SNS」と同様のイベントパターンを使用しますが、ターゲットを SNS トピックではなく、新しく作成した Lambda関数に設定します。
以上で設定完了です。
通知イメージ
特徴
この方法は最も柔軟性が高く、実運用に適していることが多いです。
- 通知の件名および本文をカスタマイズ可能
- 条件分岐や Teams/Slack 連携などの拡張が可能
- リソース情報を整形し、可読性を向上できる
一方で下記の課題は残ります。
- Lambdaのコード管理が必要
- ランタイムや依存関係のメンテナンスが発生する
- 設定は方法がやや複雑
通知内容に詳細な要件がある場合や、外部連携が必要な場合はこの方法がおすすめです。
4. EventBridge（入力トランスフォーマー）+ SNS
概要
EventBridge の「入力トランスフォーマー」機能を使い、イベントデータを整形して SNS に送信する方法です。Lambda 関数を経由することなく EventBridge の設定のみで通知内容をカスタマイズします。
設定手順
前提条件
■ AWS Config ルール、SNS トピック（サブスクリプション = 自身の E-mail 等）は設定済み
■ 適切な権限が設定済み（Config の IAM ロールや SNS のリソースベースポリシー）
■ EventBridge ルールの作成（入力トランスフォーマー付き）
-
「2 EventBridge + SNS」と同様の手順でターゲットに SNS トピックを選択した後、[追加設定] より [入力トランスフォーマー] を設定
-
ターゲット入力トランスフォーマーの [入力パス] 設定に JSON 形式で抽出する値を設定（JSON 構文は後述）
-
ターゲット入力トランスフォーマーの [テンプレート] に通知本文の形式を記載（文面は後述）
以上で設定完了です。
[入力パス]
{
"configRuleName": "$.detail.configRuleName",
"resourceType": "$.detail.resourceType",
"resourceId": "$.detail.resourceId",
"awsAccountId": "$.account"
}
[入力テンプレート]
"AWS Configにより、以下のリソースが非準拠と判定されました。"
"リソースタイプ: <resourceType>"
"リソースID: <resourceId>"
"適用ルール: <configRuleName>"
"AWSアカウント: <awsAccountId>"
"詳細は AWS Config コンソールをご確認ください。"
通知イメージ
特徴
Lambda 関数の運用コストを避けつつ、ある程度の通知整形が可能なバランスの良い方法です。
- Lambda 関数不要（ランタイム管理・セキュリティパッチ対応不要）
- 通知内容を整形可能で可読性向上
- EventBridge 直結なので遅延が少ない
- SNS 通知の「件名」のカスタマイズは不可
シンプルに見やすい通知を作りたいケースや、Lambda 関数の運用は避けたい場合に最適です。
5. AWS UserNotification を使用した通知
概要
AWS UserNotification の機能を使用して AWS Config 非準拠判定を通知します。
設定は AWS UserNotification 内で完結するため簡単に実装できます。
設定手順
-
[AWS UserNotification コンソール] ＞ [配信チャネル] ＞ [E メール] ＞ [E メールの追加] より通知先となる E メールを設定
その後メール検証などを経て登録。 -
[AWS UserNotification コンソール] ＞ [通知設定] ＞ [通知設定を作成]
-
[イベントルール] 画面にて以下の項目で設定
■ AWS のサービスの名前：Config
■ イベントタイプ：Config Rules Compliance
■ 特定のメッセージタイプ：ComplianceChangeNotification
■ 任意のルール名：✓
■ 任意のリソースタイプ：✓
■ 任意のリソース ID：✓
■ リージョン：Config ルールを有効化しているリージョンを指定（複数可）
-
[配信チャネル] にて登録した E メールを指定
以上で設定完了です。通知設定がアクティブになるまで数分要します。
通知イメージ
特徴
EventBridge や SNS、Lambda の設定が不要なため、管理工数を最小限に抑えつつ通知を実装できる点が最大の利点です。そのため、小規模環境や運用負荷を抑えたいケースでは非常に有効です。
まとめ
以上、Config 非準拠判定を通知する 5 つの方法をまとめてきました。
改めて、各方法の特徴を下記にまとめます。
| 方法 | 実装難易度（簡単さ） | カスタマイズ性 | 運用負荷（軽さ） |
|---|---|---|---|
| 1. Config 標準通知※ | ★★★★★ | ★☆☆☆☆ | ★★★★★ |
| 2. EventBridge + SNS | ★★★☆☆ | ★★☆☆☆ | ★★★☆☆ |
| 3. EventBridge + Lambda + SNS | ★☆☆☆☆ | ★★★★★ | ★☆☆☆☆ |
| 4. EventBridge（トランスフォーマー）+ SNS | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
| 5. AWS UserNotification | ★★★★★ | ★☆☆☆☆ | ★★★★★ |
※非準拠判定のみ通知することはできません
おわりに
AWS Config の非準拠リソースを迅速に検知し、関係者へ適切に通知することは、セキュリティとガバナンスの維持において非常に重要です。
本記事では、通知を実現する 5 つの方法を比較し、それぞれの特徴や適用シーンを紹介しました。環境規模や運用体制、通知要件に応じて最適な構成を選定することで、運用効率と可視性を大きく向上できます。
今後も新しい AWS サービスや機能のアップデートを踏まえ、よりスマートで効果的な通知設計を検討していきましょう。
We Are Hiring!