AWS Organizations環境でのAWS User Notifications AWS管理通知の構成パターン2選

2025.11.11
 はじめにAWS User NotificationsのAWS管理通知には、同じメールアドレスに対して重複した通知を送信しないようにする「重複排除（Deduplication）」機能があります。
2025年12月15日以降、AWS管理通知は全アカウントで強制的に有効化されます。この変更により、組織内の全アカウントでAWS Health関連（アカウント固有イベントのみ。パブリックイベントは対象外）の通知が自動的に送信されるようになります。
Starting December 15, 2025, AWS managed notifications will be enabled for all AWS accounts, including accounts where they were previously disabled. After this date, you can't disable AWS managed notifications.
https://docs.aws.amazon.com/notifications/latest/userguide/managing-notification-features.html
本記事では、全アカウントでAWS管理通知が有効な状態を前提に、AWS Organizationsでマルチアカウント運用している環境において、具体的な構成パターンを2つ紹介します。
 前提知識: AWS管理通知の集約と重複排除AWS管理通知には、「集約（Aggregation）」と「重複排除（Deduplication）」という2つの機能があります。
集約機能は、複数のメンバーアカウントで同じイベントが発生した場合、管理アカウントが1つの通知にまとめて受け取る機能です。管理アカウントまたは委任管理者がAWS管理通知を有効化するだけで機能します。
重複排除機能は、管理アカウントとメンバーアカウントが同じメールアドレスを使用している場合、メンバーアカウントへの個別通知を抑制し、管理アカウントに集約通知のみを送信する機能です。
詳細な動作パターンについては、以下の記事で解説しています。
https://dev.classmethod.jp/articles/aws-user-notifications-deduplication-patterns/
 同一アカウント内での重複に関する注意点AWS管理通知では、各カテゴリ（Security、Health Operations等）ごとに、どの連絡先に通知を送信するかを選択できます。


各カテゴリ
選択可能な連絡先は以下のとおりです。
プライマリ（ルートユーザーメール）
オペレーション（オペレーションに関する連絡先）
セキュリティ（セキュリティに関する連絡先）
請求（請求に関する連絡先）


アカウント連絡先



オペレーション,セキュリティ、請求の連絡先設定画面



プライマリの連絡先設定画面
重要な点として、同一アカウント内で同じメールアドレスを複数の連絡先に設定し、複数の連絡先をオンにすると、通知が重複して届きます。
例えば、ルートユーザーメールとセキュリティ連絡先の両方に ops@example.com を設定し、Securityカテゴリで両方をオンにした場合、ops@example.com に2通の通知が届きます。
User Notifications won't deduplicate events across shared account contacts within the same account.
AWSは、同じメールアドレスを複数の連絡先として設定しないことを推奨しています。
We recommend you unsubscribe identical account contacts.
https://docs.aws.amazon.com/notifications/latest/userguide/managed-notification-aggregation.html
本記事で紹介する構成パターンでは、この点を考慮した構成です。
 構成パターンの紹介ここでは、AWS Organizationsでマルチアカウント運用を行う際の、具体的な構成パターンを2つ紹介します。
 パターン1:管理アカウントの集約通知のみを受信（中央集権型）このパターンは、管理アカウントで組織全体の通知を一元管理し、メンバーアカウントからの個別通知は受け取らない運用方法です。
 管理アカウントの設定管理アカウントでは、以下のいずれかの設定方法を選択できます。
ルートユーザーメールのみを使用
すべての連絡先に同じメールアドレスを設定
 設定例1: ルートユーザーメールのみを使用管理アカウントでは、ルートユーザーメールのみメールアドレスを設定します。
├── ルートユーザーメール: ops@example.com
└── 代替連絡先
    ├── Security: 未設定
    ├── Operations: 未設定
    └── Billing: 未設定
AWS管理通知の設定（管理アカウント）
すべてのカテゴリでRootのみをオンにします。
Security カテゴリ:
├── Root: オン ✅
├── Operations: オフ
├── Security: オフ
└── Billing: オフ

Health Operations カテゴリ:
├── Root: オン ✅
├── Operations: オフ
├── Security: オフ
└── Billing: オフ

Account-Specific Issues カテゴリ:
├── Root: オン ✅
├── Operations: オフ
├── Security: オフ
└── Billing: オフ

Billing カテゴリ:
├── Root: オン ✅
├── Operations: オフ
├── Security: オフ
└── Billing: オフ
 設定例2: すべての連絡先に同じメールアドレスを設定管理アカウントでは、すべての連絡先に同じメールアドレスを設定します。
├── ルートユーザーメール: manage@example.com
└── 代替連絡先
    ├── Security: manage@example.com
    ├── Operations: manage@example.com
    └── Billing: manage@example.com
AWS管理通知の設定（管理アカウント）

同一アカウント内で同じメールアドレスを使用しているため、各カテゴリで1つの連絡先のみオンにして重複を避けます。

各カテゴリーごとに同じ連絡先でもよいですし、Rootなど1つのみでも構いません。
Security カテゴリ:
├── Root: オフ
├── Operations: オフ
├── Security: オン ✅
└── Billing: オフ

Health Operations カテゴリ:
├── Root: オフ
├── Operations: オン ✅
├── Security: オフ
└── Billing: オフ

Account-Specific Issues カテゴリ:
├── Root: オフ
├── Operations: オン ✅
├── Security: オフ
└── Billing: オフ

Billing カテゴリ:
├── Root: オフ
├── Operations: オフ
├── Security: オフ
└── Billing: オン ✅
 メンバーアカウントの設定メンバーアカウントでは、ルートユーザーメールのみメールアドレスを設定します。
├── ルートユーザーメール: 何でもよい
└── 代替連絡先
    ├── Security: 未設定
    ├── Operations: 未設定
    └── Billing: 未設定
メンバーアカウントでは、すべてのカテゴリをオフにします。連絡先の設定は不要です（プライマリ以外は設定しても構いませんが、代替連絡先を設定していないので、通知されません）。
AWS管理通知の設定:
├── Security カテゴリ: すべてオフ
├── Health Operations カテゴリ: すべてオフ
├── Account-Specific Issues カテゴリ: すべてオフ
└── Billing カテゴリ: すべてオフ
 動作同じイベントが管理アカウントとメンバーアカウントA・Bで発生した場合、以下のように動作します。
管理アカウント: ops@example.com に集約通知を1通受信（全3アカウントの情報を含む）
メンバーアカウントA: 通知なし（すべてオフのため）
メンバーアカウントB: 通知なし（すべてオフのため）
結果: ops@example.com に合計1通のみ
このパターンでは、管理アカウントのみが ops@example.com に通知を送信します。メンバーアカウントはすべてオフなので通知を送信しません。集約機能により、管理アカウントが全メンバーアカウントの情報を含む通知を受け取ります。
なお、メンバーアカウント側でカテゴリごとに管理アカウントと同じ連絡先を有効化しても、重複排除により同じ動作になります。しかし、わざわざメンバーアカウントで連絡先を設定するのは手間なので、不要です。
メリットは以下があります。
管理アカウントの集約通知のみが ops@example.com に届く
メンバーアカウントでの設定作業が最小限（すべてオフにするだけ）
デメリットは以下があります。
メンバーアカウント個別の通知は受け取れない
推奨される用途は、全アカウントを同じチームが管理している場合や、中央集権的な運用体制に推奨されます。
 パターン2：アカウントごとに異なるメールアドレスを使用（分散管理型）このパターンは、管理アカウントで組織全体の集約通知を受け取りつつ、各メンバーアカウントも個別に通知を受け取る運用方法です。各アカウントで異なるメールアドレスを使用するため、重複排除は機能しません。
 管理アカウントの設定管理アカウントでは、すべての連絡先に同じメールアドレスを設定します。
├── ルートユーザーメール: manage@example.com
└── 代替連絡先
    ├── Security: manage@example.com
    ├── Operations: manage@example.com
    └── Billing: manage@example.com
同一アカウント内で同じメールアドレスを使用しているため、各カテゴリで1つの連絡先のみオンにして重複を避けます。
Security カテゴリ:
├── Root: オフ ☐
├── Operations: オフ ☐
├── Security: オン ✅
└── Billing: オフ ☐

Health Operations カテゴリ:
├── Root: オフ ☐
├── Operations: オン ✅
├── Security: オフ ☐
└── Billing: オフ ☐

Account-Specific Issues カテゴリ:
├── Root: オフ ☐
├── Operations: オン ✅
├── Security: オフ ☐
└── Billing: オフ ☐

Billing カテゴリ:
├── Root: オフ ☐
├── Operations: オフ ☐
├── Security: オフ ☐
└── Billing: オン ✅
なお、先程の設定例1のように、ルートユーザーメールのみを使用する設定でも構いません。
 メンバーアカウントの設定各メンバーアカウントでは、管理アカウントとは異なるメールアドレスを設定します。これにより、重複排除は機能せず、各アカウントが個別に通知を受け取ります。
メンバーアカウントA
├── ルートユーザーメール: team-a@example.com
└── 代替連絡先
    ├── Security: team-a@example.com
    ├── Operations: team-a@example.com
    └── Billing: team-a@example.com
同一アカウント内で同じメールアドレスを使用しているため、各カテゴリで1つの連絡先のみオンにして重複を避けます。
Security カテゴリ: Security のみオン ✅
Health Operations カテゴリ: Operations のみオン ✅
Account-Specific Issues カテゴリ: Operations のみオン ✅
Billing カテゴリ: Billing のみオン ✅
メンバーアカウントB
├── ルートユーザーメール: team-b@example.com
└── 代替連絡先
    ├── Security: team-b@example.com
    ├── Operations: team-b@example.com
    └── Billing: team-b@example.com
メンバーアカウントBも同様に、同一アカウント内で同じメールアドレスを使用しているため、各カテゴリで1つの連絡先のみオンにして重複を避けます。
Security カテゴリ: Security のみオン ✅
Health Operations カテゴリ: Operations のみオン ✅
Account-Specific Issues カテゴリ: Operations のみオン ✅
Billing カテゴリ: Billing のみオン ✅
先程の例のように、ルートユーザーメールのみを使用する設定でも構いません。
 動作同じイベントが管理アカウントとメンバーアカウントA・Bで発生した場合、以下のように動作します。
管理アカウント：manage@example.com に集約通知を1通受信（全3アカウントの情報を含む）
メンバーアカウントA：team-a@example.com に個別通知を1通受信（自アカウントの情報のみ）
メンバーアカウントB：team-b@example.com に個別通知を1通受信（自アカウントの情報のみ）
結果：合計3通（各アカウント1通ずつ）
このパターンでは、各アカウントで異なるメールアドレスを使用しているため、重複排除は機能しません。
管理アカウントは集約通知を受け取り（全アカウントの情報を含む）、各メンバーアカウントは個別通知を受け取ります（自アカウントの情報のみ）。
また、各アカウント内で同じメールアドレスを使用しているため、各カテゴリで1つの連絡先のみオンにして重複を避ける必要があります。
メリットは以下があります。
各チームが自アカウントの通知を直接受け取れる
各チームが独立して運用できる
デメリットは以下があります。
管理アカウントも別途集約通知を受け取るため、組織全体の通知数が増える
重複排除は機能しない（各アカウントで異なるメールアドレスを使用しているため）
各アカウントで同じ設定を維持する必要がある（各カテゴリで1つの連絡先のみオン）
推奨される用途は、アカウントごとに異なるチーム・部門が管理している場合や、分散管理体制に推奨されます。
特定のメンバーアカウントだけ個別通知を受け取りたい場合、そのメンバーアカウントでは、管理アカウントと異なるメールアドレスを設定してください。重複排除は同じメールアドレスの場合のみ機能します。
 まとめAWS User NotificationsのAWS管理通知における具体的な構成パターンを2つ紹介しました。
パターン1（中央集権型）は、管理アカウントで組織全体の通知を一元管理し、全アカウントを同じチームが管理している場合に適しています。
パターン2（分散管理型）は、各アカウントで個別に通知を受け取りつつ、管理アカウントでも集約通知を受け取る運用方法です。アカウントごとに異なるチーム・部門が管理している場合に適しています。
いずれのパターンでも、同一アカウント内で同じメールアドレスを複数の連絡先として設定する場合は、各カテゴリで1つの連絡先のみをオンにして重複を避けることが重要です。
組織の運用体制に合わせつつ、1つの例として参考になれば幸いです。