Category: Security & Monitoring

In this post, I discuss the recent updates to AWS User Notifications, including Notification Hubs, Delegated Admins, and AWS Organizations integration.

Introduction

On 5 September 2025, AWS launched Organizational Notification Configurations for AWS User Notifications. This update lets AWS Organizations users manage alerts across their entire estate from a single account.

Prior to AWS User Notifications, creating alerts was a manual process using EventBridge rules, CloudWatch Alarms and SNS topics. I currently use this setup for root login alerts, and it’s definitely time for an upgrade. So in this post, I’ll walk through replacing those alerts with AWS User Notifications.

I will start by setting up a root login alert for a standalone account using AWS User Notifications. Next, I’ll check the results to see if this method improves on the previous alerting system. Finally, I will scale the updated configuration across my entire AWS Organization using the new centralised management features.

AWS User Notifications

In this section, I’ll use AWS User Notifications to set up a root login alert for a standalone AWS account.

User Notifications Introduction

AWS User Notifications is a fully managed service that delivers consistent, human-readable notifications from AWS services and custom applications. Notifications can be sent in various ways including email, mobile push notifications and the in-console Notification Centre.

Behind the scenes, the service acts as a central hub: it receives events from integrated AWS services, applies delivery and aggregation settings and then sends notifications to users based on their preferences.

Common use cases include:

• Operational Monitoring: Real-time alerts for infrastructure or service issues.
• Deployment & CI/CD Visibility: Notifications for build, deploy and pipeline events.
• Security Alerts: Immediate awareness of suspicious activity or configuration changes.

The service also supports grouping and scheduling, reducing alert fatigue by sending relevant notifications at optimal times rather than a constant stream of individual emails.

Accessing User Notifications

The AWS User Notifications service is accessible both by clicking the bell icon in the top navigation and by searching in the AWS console:

Selecting this loads the Notification Centre and presents several sections:

• Notification Configurations are the containers for the specific services and event rules you want to be notified about.
• Notification Hubs identify the AWS Regions where notifications are stored, processed and replicated.
• AWS Managed Notifications Subscriptions manages default AWS Health and service-level subscriptions for account contacts.
• Delivery Channels are locations where notifications are sent, including email addresses, chat channels and mobile devices.
• Organizations Settings enables AWS Organizations in AWS User Notifications.

There’s also a Quick Setup section with preconfigured CloudWatch, EC2 and Health options…

…and an area for notifications, aggregated by date received and by creator:

Now, let’s examine creating a notification in a standalone AWS account.

User Notifications In Single Accounts

In this section, I’ll create a User Notification in an AWS account not aligned with an AWS Organization to see how the service handles a high-priority security event.

Notification Hub Creation

My first task is creating a Notification Hub, as this account currently doesn’t have one. Notification hubs are account-level settings that define the AWS Regions where notifications are stored, processed and replicated. A hub must exist before any notification configurations can be created.

User Notifications stores notification configuration data in both the default region us-east-1 (N. Virginia), and in regions with configured rules. So, for notifications receiving alerts about events in eu-west-1 (Ireland) and eu-west-2 (London), User Notifications will first create the settings in N. Virginia. Then it will copy them to Ireland and London.

This account only uses Ireland currently, so my Notification Hub looks like this:

Notification Configuration Creation

With my Notification Hub set up, it’s time to build the logic that actually triggers an alert. Here, we define the alert triggers, how alerts will be sent and who will receive them.

As with many AWS services, I give a unique name and an optional description. Then I can choose my notification event rules:

The interface here is similar to other AWS event-driven services. Selecting an AWS service name from the list (like AWS Console Sign-in) filters the Event Type list. I can then select my source AWS regions using checkboxes.

That leaves the Advanced Filter area. This uses EventBridge event patterns to select a subset of events, which is helpful because some patterns generate lots of events. Unfortunately, unlike the EventBridge console, there is limited help here for creating event patterns.

Users wanting help should check out the EventBridge console, which lets users create templates using pattern forms and dropdowns. For example, in this screenshot from the EventBridge console, this event pattern looks for all sign-in events linked to a specific user ARN:

{
  "source": ["aws.signin"],
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": {
    "userIdentity": {
      "arn": ["userARN"]
    }
  }
}

{
  "source": ["aws.signin"],
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": {
    "userIdentity": {
      "arn": ["userARN"]
    }
  }
}

The detail section from this JSON array can then be copied from EventBridge and pasted into User Notifications with edits as needed. Here, I have modified the EventBridge event pattern to watch for all ConsoleLogin events where the userIdentity is of type Root:

After this, I can choose how often I want to receive these notifications. There are three aggregation options:

• Receive Within 5 Minutes: A good balance of aggregation and frequency. An acceptable default in most cases.
• Receive Within 12 Hours: Ideal for notifications that are not urgent or high-priority.
• Do Not Aggregate: Best suited for high-priority events, though it may generate a large number of notifications.

I’m using Do Not Aggregate for my root login alert so I’m notified immediately.

Creating Delivery Channels

Finally, I need to choose where the notifications actually go. I can select up to fifty delivery channels per configuration, which are separate from the in-console Notification Centre.

I have three choices:

• Emails: This uses Amazon SES API endpoints to deliver email notifications from @aws.com addresses. Each new email address must be validated before it can receive notifications, making distribution lists preferable at scale.
• Chat Channels: This uses AWS Chatbot to push alerts into Slack and Microsoft Teams.
• Mobile Devices: This uses push notifications via the AWS Console Mobile Application.

Despite my best efforts, I couldn’t get any mobile push notifications to trigger during testing. I’ll use email for now and will publish a follow-up post if I figure out what I’m missing with push notifications.

Outcomes

With the notification configuration complete, let’s review what AWS creates and how the notification looks. Navigating back to the My Notification Configurations tab, I can see my new RootLogins configuration:

Looking at the details, AWS shows the event pattern JSON and links to the underlying managed rules that are stored in EventBridge (1 rule per selected region):

These links lead to EventBridge, which holds and controls the rules:

So what does the actual alert look like? Below is the email generated when I performed a test root login. It is a big improvement over the old SNS text walls, organised into two clean and distinct sections:

The Event Detail: This identifies what happened (Console Login), who did it (Root), and the outcome (Success):

The Notification Metadata: This provides the context of the User Notification itself, including the source ARN and the AWS region:

This is a massive improvement over my previous alerting. The formatting makes it much easier to read the details without visually parsing raw JSON.

A quick security reminder: Just like the previous method, these emails expose AWS account IDs. If forwarding these to external ticketing systems or shared mailboxes, keep any data exfiltration policies in mind.

Now that we have a working setup in a standalone account, let’s see how this scales across AWS Organizations.

User Notifications In AWS Organizations

In this section, I explore how AWS User Notifications integrates with AWS Organizations.

Management & Member Accounts

Before continuing, I want to briefly explain the concepts of AWS Organizations Management accounts and Member accounts for those unfamiliar with them:

• Management Account: The administrative core of an AWS Organization. Used for centralised billing, account creation and governing policies across the entire estate.
• Member Accounts: Accounts within an AWS Organization. Member accounts are subject to the guardrails and management structures defined by the Management Account.

Review the AWS Terminology & Concepts documentation for further details.

Enabling Trusted Access

Before I can do anything with AWS User Notifications at an AWS Organization level, I must enable trusted access. AWS offers useful prompts when a section needs trusted access but it hasn’t been enabled yet:

The included links lead directly to Organizations Settings within the User Notifications console. Trusted access is enabled from here:

Once Trusted Access is enabled, the Notification Configurations section displays the AWS Organization structure:

Now let’s start configuring things!

Organizational Configuration

From the Management account, I can apply a single configuration (such as my Root Login alert) across my entire AWS Organization. I can either use checkboxes to select my entire AWS Organization or a subset of Organizational Units, or use the Advanced Filters to target a list of specific AWS account IDs.

Once an Organization Notification Configuration is live, its visibility depends on the account:

• Management account: Visible in the My Notification Configurations tab, with full control and visibility granted through appropriate IAM permissions.
• Member accounts: Visible as read-only notification configurations in the Organization Notification Configurations tab:

Notifications from Organization Notification Configurations are only sent to the Management account, not to the Member accounts where the events occur. Additionally, Member accounts cannot edit or delete these rules.

If these limitations are undesirable, the Management account can appoint up to five Member accounts as delegated administrators:

Delegating notification administration to dedicated Security or Operations member accounts enables the management of Organization Notification Configurations without needing access to the Management account. This method streamlines operations and reduces the risk of Management account abuse or compromise. It also ensures that those responding to alerts can manage the related rules.

Summary

In this post, I explored recent updates to AWS User Notifications, including Notification Hubs, Delegated Administrators and enhanced support for scaling within AWS Organizations.

AWS User Notifications greatly simplifies the process of receiving and managing alerts across AWS Organizations member accounts. It reduces operational overhead and complexity, and offers a centralised, cross-account interface for managing notifications while maintaining the granular control AWS users expect.

That said, there are a few areas where I’d love to see the service evolve:

• Cross-account Chatbot support: I have a dedicated member account for Chatbot configurations to avoid duplication, but I haven’t yet found a clean way to route User Notifications there.
• EventBridge Feature Parity: The Advanced Filters are great, but I’d love to see the full EventBridge sandbox testing experience integrated directly into the User Notifications UI.
• Linking Existing Rules: I already have some EventBridge rules in use. The ability to import or associate existing EventBridge rules with AWS User Notification Configurations would save time.
• Simpler Testing: A straightforward “Send Test Notification” button per delivery channel would significantly improve usability.

Overall, AWS User Notifications transforms a process with many moving parts into something centralised, transparent, and far easier to operate at scale. While it isn’t perfect, it’s already making my life easier and I’m excited to see where it goes from here.

Finally, watch this official AWS demo for a clear overview of AWS User Notifications in action:

Like this post? Click the button below for links to contact, socials, projects and sessions:

Thanks for reading ~~^~~