AWS認定資格 WEB問題集＆徹底解説セキュリティ専門知識（SCS）

会員登録/ログイン

1. サービス概要

AWS User Notificationsは、AWSの各サービスから届く通知を1か所で設定・確認するためのサービスです。 Amazon EventBridgeに流れるAWSサービスのイベント（CloudWatchアラームの状態変化、GuardDutyの検出結果、AWS Healthのイベント、コンソールへのサインインなど）を条件で選び、マネジメントコンソールの通知センター・メール・チャット・モバイルアプリへ、コードを書かずに届けられます。

通知には、AWS Health・AWS Marketplace・請求とコスト管理などのサービスが既定で送るAWS管理の通知と、利用者が通知設定（notification configuration）を作って発生させるユーザー設定の通知の2種類があります。 EventBridgeルールとAmazon SNSトピック、Lambdaによる整形を組み合わせて自作していた通知の仕組みを、マネージドに置き換えられる点が特徴です。

2. 主な特徴と機能

2.1 通知設定とイベントルール

通知設定は、通知したいサービスとイベントルールをまとめた入れ物です。イベントルールでは、AWSサービス名・イベントの種類・対象リージョンを選び、必要に応じてJSONのイベントパターンによる詳細フィルター（例: 重大度が一定以上のGuardDuty検出結果だけ）を指定します。 1つの通知設定の中に複数サービスのイベントルールを置けるため、「セキュリティ運用チーム向けの通知」のように受け手単位でまとめて管理できます。 リージョンをルールの中で複数指定できるので、リージョンごとに同じ設定を作り込む必要がありません。

2.2 集約設定

同じ種類のイベントが短時間に大量発生したときに通知が溢れないよう、複数のイベントをまとめて1つの通知にする集約設定があります。 選択肢は「5分以内に受信」（推奨・既定）、「12時間以内に受信」、「集約しない」の3つで、優先度の高い通知は短い集約、低い通知は長い集約を選びます。

2.3 配信チャネル

• コンソール通知センター: 既定の配信先。コンソール上部のベルアイコンから確認できる。
• メール: 宛先ごとに確認メールで検証する。メーリングリストを1つの宛先として登録すれば、メンバーの増減に再検証は要らない。
• チャット: Amazon Q Developer in chat applications（旧AWS Chatbot）経由でSlack、Microsoft Teamsなどのチャネルへ送る。
• AWS Console Mobile Application: スマートフォンへのプッシュ通知（SMSではない）。

2.4 通知ハブ

通知ハブは、通知データを保存・処理・複製するリージョンを決めるアカウント単位の設定です。通知設定を作る前に少なくとも1つ選ぶ必要があり、最大3リージョンまで指定できます。 通知設定そのものは米国東部（バージニア北部）に保存され、ルールで指定したリージョンにも複製されます。

2.5 組織単位の通知設定

AWS Organizationsと統合し、管理アカウントまたは委任管理者（最大5アカウント）が、組織全体や特定のOUのアカウントを対象とする通知設定を作れます（2025年9月に一般提供）。 アカウントの参加・離脱に合わせて対象が自動的に更新され、メンバーアカウントには読み取り専用の設定が作られます。

3. アーキテクチャおよび技術要素

1. 各AWSサービスがイベントをAmazon EventBridgeのデフォルトイベントバスへ送る。
2. User Notificationsは、通知設定のイベントルールに対応する管理されたEventBridgeルールを、指定された各リージョンに作成する。
3. 一致したイベントは通知ハブに集められ、集約設定に従ってまとめられる。
4. 通知は人が読みやすい形に整形され、関連するコンソール画面への導線付きで通知センターに表示される。
5. 同時に、メール（Amazon SESのエンドポイント経由）、チャット（Amazon Q Developer in chat applications経由）、モバイルアプリへ配信される。

複数アカウントのイベントを1か所で受けたい場合は、組織単位の通知設定を使うか、EventBridgeのクロスアカウントのイベント転送で受信側アカウントにイベントを集めてから通知設定を作ります。

4. セキュリティと認証・認可

• IAMによる制御: 通知設定・配信チャネル・通知ハブの作成や変更は、リソースレベルの権限を含むIAMポリシーで制御する。閲覧だけ許可する運用も可能。
• 宛先の検証: 新しいメールアドレスには確認メールが送られ、検証が済むまで配信されない。検証はアドレスを追加したアカウントにサインインして完了させる。
• チャット連携の権限: Slack / Teamsのチャネル設定はAmazon Q Developer in chat applications側で行い、チャネルに割り当てるIAMロールとガードレールポリシーで、チャットからの操作範囲を最小限にする。
• サービスリンクロール: User Notificationsは、EventBridgeルールの管理や組織情報の参照にサービスリンクロールを使う。
• 監査: 通知設定の作成・変更はCloudTrailに記録される。
• セキュリティイベントの見落とし防止: rootユーザーのサインイン、GuardDutyの重大な検出結果、Security Hub CSPMの検出結果などを通知対象にし、運用チームへ確実に届ける。

5. 料金形態

User Notifications自体は追加料金なしで利用できます。

• User Notifications: 通知設定の作成や通知の配信にサービスとしての料金はかからない。
• 関連サービス: 通知の元になるサービス（CloudWatchアラーム、GuardDutyなど）や、自分で追加したEventBridgeのクロスアカウント転送などは各サービスの料金に従う。
• 自作構成との比較: EventBridgeルール＋SNS＋Lambdaで通知を作り込む場合に比べ、構築・保守の手間と関数の実行コストを減らせる。

6. よくあるアーキテクチャ・設計パターン

• セキュリティ運用チームへの通知: GuardDuty（重大度中以上）、AWS Health、CloudWatchアラーム、コンソールサインインのイベントルールを1つの通知設定にまとめ、メーリングリストとSlackへ送る。
• マルチリージョンの一括設定: イベントルールの対象リージョンに複数リージョンを指定し、リージョンごとの設定作業をなくす。
• アラート疲れの抑制: 集約設定を「5分以内に受信」にし、短時間に連続するイベントをまとめて受け取る。優先度の低い通知は「12時間以内」にする。
• 組織全体の通知: 委任管理者アカウントで組織またはOU単位の通知設定を作り、新しいアカウントにも自動で適用する。
• 当番者への即時連絡: 重大なイベントだけをAWS Console Mobile Applicationへのプッシュ通知に設定する。

7. 設定・デプロイ手順（ハンズオン例）

1. コンソール上部のベルアイコンから通知センターを開き、「通知ハブ」で保存・処理に使うリージョン（最大3つ）を選ぶ。
2. 「通知設定」→「通知設定を作成」を選び、名前と説明を入力する。
3. イベントルールを追加する。例: サービス名「GuardDuty」、イベントの種類「GuardDuty Finding」、リージョンに対象の全リージョンを選び、詳細フィルターで重大度を絞る。
4. 同じ通知設定にAWS Health、CloudWatchアラームの状態変化、コンソールサインインのルールも追加する。
5. 集約設定で「5分以内に受信」を選ぶ。
6. 配信チャネルとしてメール（メーリングリスト）を追加し、Amazon Q Developer in chat applicationsで作成したSlackチャネルを選ぶ。
7. 作成後、確認メールで宛先を検証し、テスト用のアラームなどで通知が届くことを確認する。

8. 試験で問われやすいポイント