Centralized AWS Health Alerts with EventBridge, Lambda, and SES

Problem Statement

Managing multiple AWS accounts across different regions of deployment makes it difficult to track AWS Health events such as outages, scheduled maintenance, or deprecations. AWS Organizations provides an aggregated view of these events, but since it operates at the organization level, it pulls in performance and billing alerts from all accounts within that organization. This creates several challenges in environments where a single AWS Organization contains accounts from multiple customers:

• No ability to scope alerts to only the relevant customer accounts.
• Customers may receive irrelevant or noisy notifications.
• Lack of clear separation between different customers’ events.

To solve this, we needed a system that could:

• Collect AWS Health events from only the relevant customer accounts.
• Work seamlessly across all AWS regions.
• Route events to a central monitoring location.
• Deliver professional, branded email alerts instead of raw JSON.
• Be automated, scalable, and easily repeatable through CloudFormation.

The Solution

We designed a serverless, cross-account pipeline using EventBridge, Lambda, and SES. The flow looks like this:

• Customer accounts: EventBridge rules in each required region capture aws.health events and forward them cross-account.
• Central account: Hosts a custom EventBridge bus (Health-bus) that receives all forwarded events.
• EventBridge rules: On the central bus, rules trigger a Lambda function for every incoming event.
• Lambda + SES: The Lambda parses and formats the Health event and uses Amazon SES to send it as a clean HTML email to customer stakeholders.

This ensures each customer receives only their own alerts, in a form that’s easy to read and act upon.

Architecture Overview

The architecture is built from three components:

1. Customer accounts

• EventBridge rules in every region where AWS Health events should be monitored.
• Rules forward events securely to the central custom bus.

2. Central account

• A dedicated EventBridge bus to aggregate events.
• Rules attached to this bus to trigger the Lambda function.

3. Lambda and SES

• Lambda extracts details such as service, region, account ID, description, and timestamps.
• It builds an HTML email and delivers it using Amazon SES.
• Because AWS Health is regional, forwarding rules must be deployed in each region the customer wants covered.

Deployment with CloudFormation

To make the solution repeatable, we created two CloudFormation templates:

1. Customer Forwarder Template

• Deployed in each customer account and region.
• Creates a rule named ForwardAllHealthEvents to forward all AWS Health events to the central bus.

2. Central Aggregator Template

• Deployed once in the central monitoring account.
• Creates the custom event bus.
• Sets up a rule to invoke the Lambda function.
• Deploys the Lambda code from S3.
• Leaves SES setup (sender/recipient verification, sandbox exit) as a manual step.

The Email Experience

Instead of raw JSON, customers receive structured HTML emails with:

• Service and category (issue, scheduled change, or notification).
• Region and account ID.
• Event time in UTC.
• A clear description.
• A direct link to the AWS Health Dashboard. 

Cost Considerations

• EventBridge → $1 per million events on a custom bus.
• Lambda → $0.20 per million invocations (lightweight usage costs almost nothing).
• SES → $0.10 per 1,000 emails, with 62,000 free emails per month when sent from EC2 or Lambda in us-east-1.

For most customers, the monthly cost is only a few dollars.

Results

With this setup in place, we achieved:

• Real-time AWS Health alerts across accounts and regions.
• Clean separation of events per customer within a shared AWS Organization.
• Branded, customer-friendly email notifications.
• Automated, repeatable deployment through CloudFormation Stacksets.

If your teams are struggling with fragmented AWS Health alerts, this approach provides a proven, low-cost way to centralize and streamline communication. Start small with a single account and region, then expand as needed — the design scales effortlessly.