2.2.4. SNS Notifications and AWS User Notifications

💡 First Principle: An alert that reaches the wrong person at the wrong time is as bad as no alert. SNS is the notification bus that carries alerts from AWS services to humans and other systems. Understanding its delivery model — fan-out to multiple subscribers — is key to building reliable alerting architectures.

SNS Core Concepts:

Fan-out Pattern: One SNS message can trigger multiple actions simultaneously. This is a critical architecture pattern:

A standard SNS topic pushes each message to its subscribers and does not store it for them to pull or re-read later. When each consumer must work at its own pace and retry independently, subscribe a separate SQS queue per consumer: each queue is that consumer's durable buffer.

Message Filtering: Without filtering, every subscriber receives every message — including noise irrelevant to their role. A subscription filter policy is a JSON document that specifies attribute conditions. Only messages with matching attributes are delivered to that subscriber.

{
  "severity": ["CRITICAL", "HIGH"],
  "environment": ["production"]
}

AWS User Notifications is a newer service that provides a unified notification experience across AWS. It aggregates notifications from multiple AWS services (Health events, Security Hub findings, CloudWatch alarms) and delivers them to multiple channels (email, AWS Console Mobile App, and Slack or Microsoft Teams chat channels through Amazon Q Developer in chat applications) with a consistent format. Think of it as a managed notification hub that sits above individual service alerts.

⚠️ Exam Trap: SNS topics are regional — a topic in us-east-1 is separate from a topic in us-west-2. If you need cross-region alerting, either replicate the alarm configuration in each region or route events through EventBridge cross-region before publishing to SNS.

AWS Health Dashboard: AWS's Own Alerts About Your Resources:

CloudWatch alarms tell you what your metrics are doing. AWS Health tells you what AWS is doing that affects you: an operational issue in a Region, a scheduled EC2 instance retirement, an end-of-support date for your RDS engine version, an S3 bucket that might allow public access. The dashboard needs no setup and costs nothing, and all customers can receive the same events through EventBridge at no charge. Only the programmatic AWS Health API requires a Business-level or higher AWS Support plan.

Every event has a scope (PUBLIC or ACCOUNT_SPECIFIC) and a category: issue, accountNotification, scheduledChange or investigation.

Organizational View: Enable it in the AWS Health console from the management account of an organization with all features enabled. Best practice is to register a delegated administrator member account so the operations team can see and act on events without using the management account. Once enabled, the management account or delegated administrator receives a single EventBridge feed of Health events from every account; member accounts' own rules keep working. In that feed, the event's top-level account is the receiving account; detail.affectedAccount names the account that is actually impacted, so route or filter on that field. Organizational events are retained for 90 days, and that quota can't be increased.

Health Events in EventBridge — Automated Response:

{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"],
  "detail": {
    "service": ["EC2"],
    "eventTypeCategory": ["scheduledChange"]
  }
}

A typical automation: when AWS Health sends AWS_EC2_PERSISTENT_INSTANCE_RETIREMENT_SCHEDULED for an EBS-backed instance, an EventBridge rule starts a Systems Manager Automation runbook that stops and starts the instance so it moves to healthy hardware before the retirement date. The instance must be managed by Systems Manager. Other common targets are SNS, Lambda, SQS and Amazon Q Developer in chat applications.

Since December 15, 2025, AWS Health emails are delivered through AWS managed notifications in AWS User Notifications, where you choose which event categories each contact receives. Public events are not available through AWS managed notifications — to receive those, create an EventBridge rule or a user-configured notification.

⚠️ Exam Trap: The RSS feed on the public Service health page is not the way to automate. It shows only public events, and AWS warns its format can change. Automated response to Health events — including account-specific events such as scheduled maintenance — goes through an EventBridge rule with "source": ["aws.health"].

Reflection Question: Your team has 5 sub-teams, each responsible for different services. All alerts currently go to one SNS topic, and every engineer gets paged for every alert. How would you redesign the alerting architecture using SNS features?