Centralized AWS Health Alerts with EventBridge, Lambda, and SES: A Practical Guide

Problem Statement & Impact

Managing multi-account AWS environments introduces significant complexity when tracking critical operational updates, performance degradations, scheduled infrastructure maintenance, and security deprecations from the AWS Health service. While native AWS Organizations capabilities provide aggregated views of organizational telemetry, these dashboards pull in telemetry indiscriminately across every linked member account. In multi-tenant environments, enterprise hosting platforms, or Managed Service Provider (MSP) structures where a single AWS Organization contains workloads from multiple distinct customers, this architectural design introduces severe operational friction and compliance violations.

When default notification mechanisms broadcast raw AWS Health payloads globally, administrators face three primary failure modes:

• Tenant Boundary Violations: Inability to cleanly scope alerts to specific customer accounts without leaking cross-tenant metadata, resource identifiers, or internal infrastructure topologies.
• Alert Fatigue and Noise: Stakeholders receive irrelevant telemetry concerning billing alerts, experimental sandboxes, or unrelated staging workloads, leading to missed critical production notifications.
• Granularity Deficits: Raw JSON payloads generated by AWS Health lack actionable context, business-level prioritization, or professional formatting, impeding rapid incident response and stakeholder communication.

The operational consequence of inaction includes delayed remediation for infrastructure degradation, extended downtime windows during unannounced hardware maintenance, and compromised internal service-level agreements (SLAs). To maintain robust security postures and reliable cloud operations, engineering teams require an automated, secure, cross-account telemetry pipeline that isolates AWS Health events at the source, aggregates them centrally, and delivers clean, actionable notifications to authorized stakeholders.

Root Cause Analysis & Architecture

The underlying technical challenge stems from the inherent design of the AWS Health API. AWS Health events are strictly regional and account-specific. They do not natively support direct cross-account pub/sub routing without an intermediate message broker. While AWS Control Tower and AWS Organizations can aggregate CloudTrail and security findings, native routing for `aws.health` events across disparate organizational units requires explicit event bus policies, resource-based permissions, and cross-account IAM trust relationships.

The solution relies on a decentralized-to-centralized serverless telemetry pipeline utilizing Amazon EventBridge, AWS Lambda, and Amazon Simple Email Service (SES). The data flow operates through four distinct phases:

1. Event Generation: When AWS detects an operational issue, scheduled maintenance, or security notice, an event is emitted within the local account and region’s default EventBridge event bus under the `aws.health` source namespace.
2. Cross-Account Forwarding: EventBridge rules deployed in each regional customer account capture the `aws.health` events and forward them securely across accounts to a custom EventBridge event bus residing within a centralized monitoring account.
3. Centralized Ingestion & Triggering: The custom event bus in the central account evaluates incoming JSON payloads against targeted event patterns, immediately invoking an AWS Lambda parsing function upon a match.
4. Transformation & Delivery: The Lambda function normalizes the raw event structure, extracts vital metadata (such as affected service, region, account ID, and description), generates a responsive HTML payload, and dispatches the notification via Amazon SES to verified recipient lists.

Step-by-Step Implementation & Remediation Guide

Deploying this multi-account infrastructure requires provisioning resources in both the spoke (customer) accounts and the central logging/monitoring account. Below are the precise configurations, AWS CLI commands, and Infrastructure as Code (CloudFormation) templates required to build the pipeline.

Step 1: Configure the Central Event Bus

First, create a custom event bus in the central monitoring account and attach a resource-based policy that explicitly allows spoke accounts to put events onto this bus.

aws events create-event-bus --name HealthCentralBus --region us-east-1

Apply the following JSON policy to the central event bus (`HealthCentralBus`) to permit trusted spoke account IDs to invoke `PutEvents`:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpokeAccountAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::111122223333:root",
          "arn:aws:iam::444455556666:root"
        ]
      },
      "Action": "events:PutEvents",
      "Resource": "arn:aws:events:us-east-1:999988887777:event-bus/HealthCentralBus"
    }
  ]
}

Step 2: Deploy the Customer Forwarder Template

Deploy the following AWS CloudFormation template into every spoke account and region where AWS Health monitoring is required. This template establishes an EventBridge rule matching all `aws.health` events and targets the central event bus ARN.

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Spoke account EventBridge rule to forward AWS Health events to central monitoring account.'

Parameters:
  CentralAccountID:
    Type: String
    Description: 'The AWS Account ID of the central monitoring account.'
  CentralRegion:
    Type: String
    Default: 'us-east-1'
    Description: 'The AWS Region where the central event bus resides.'

Resources:
  ForwarderRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: events.amazonaws.com
            Action: sts:AssumeRole
      Policies:
        - PolicyName: EventBridgeForwarderPolicy
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action: events:PutEvents
                Resource: !Sub 'arn:aws:events:${CentralRegion}:${CentralAccountID}:event-bus/HealthCentralBus'

  ForwardHealthEventsRule:
    Type: AWS::Events::Rule
    Properties:
      Name: 'ForwardAllHealthEvents'
      Description: 'Captures all AWS Health events and routes them to the central account.'
      EventPattern:
        source:
          - 'aws.health'
      State: 'ENABLED'
      Targets:
        - Id: 'CentralEventBusTarget'
          Arn: !Sub 'arn:aws:events:${CentralRegion}:${CentralAccountID}:event-bus/HealthCentralBus'
          RoleArn: !GetAtt ForwarderRole.Arn

Step 3: Deploy the Lambda Normalization Function

In the central monitoring account, deploy an AWS Lambda function running Node.js or Python to process incoming events. Below is a production-ready Python 3.11 implementation that parses the AWS Health payload and formats an HTML email for Amazon SES.

import os
import json
import boto3
from botocore.exceptions import ClientError

ses_client = boto3.client('ses', region_name=os.environ.get('AWS_REGION', 'us-east-1'))
SENDER_EMAIL = os.environ['SENDER_EMAIL']
RECIPIENT_EMAIL = os.environ['RECIPIENT_EMAIL']

def lambda_handler(event, context):
    print("Received event: " + json.dumps(event))
    
    detail = event.get('detail', {})
    service = detail.get('service', 'UNKNOWN_SERVICE')
    event_type_code = detail.get('eventTypeCode', 'UNKNOWN_CODE')
    event_arn = detail.get('arn', 'N/A')
    region = detail.get('region', 'GLOBAL')
    account_id = event.get('account', 'UNKNOWN_ACCOUNT')
    start_time = detail.get('startTime', 'N/A')
    
    description_obj = detail.get('eventDescription', [{}])
    description = description_obj[0].get('latestDescription', 'No description provided.') if description_obj else 'No description provided.'
    
    subject = f"[AWS Health Alert] {service} incident in {region} (Account: {account_id})"
    
    html_body = f"""
    
    
    
        

            
AWS Health Operational Notice
            

                

                    
Service:
                    
{service}
                
                

                    
Account ID:
                    
{account_id}
                
                

                    
Region:
                    
{region}
                
                

                    
Event Code:
                    
{event_type_code}
                
                

                    
Start Time:
                    
{start_time}
                
            
            
Description
            
{description}
            
Event ARN: {event_arn}
        
    
    
    """
    
    try:
        response = ses_client.send_email(
            Source=SENDER_EMAIL,
            Destination={'ToAddresses': [RECIPIENT_EMAIL]},
            Message={
                'Subject': {'Data': subject, 'Charset': 'UTF-8'},
                'Body': {'Html': {'Data': html_body, 'Charset': 'UTF-8'}}
            }
        )
        print(f"Message ID: {response['MessageId']}"),
    except ClientError as e:
        print(e.response['Error']['Message'])
        raise e
        
    return {'statusCode': 200, 'body': json.dumps('Health alert processed successfully.')}

Production Hardening & Edge Cases

Implementing cross-account monitoring pipelines in enterprise environments requires addressing several architectural edge cases, rate limits, and failure modes:

• Amazon SES Sandbox Limitations: Newly provisioned SES accounts operate in the SES Sandbox, which restricts email dispatch exclusively to verified email addresses and domains, and enforces a strict sending quota (200 emails per 24-hour period). Production deployment requires submitting a service quota increase request through the AWS Support Center to exit the sandbox and configure proper DKIM, SPF, and DMARC DNS records.
• Event Throttling and Limits: EventBridge custom buses support up to 100,000 requests per second by default, but downstream targets like AWS Lambda concurrency limits must be appropriately scaled. Ensure that unreserved account concurrency does not starve the Lambda function during widespread regional AWS outages.
• Multi-Region Resilience: Because AWS Health events originate regionally, failing to deploy the customer forwarder template across all active regions results in blind spots. Automation tools such as AWS CloudFormation StackSets should be leveraged to enforce baseline deployment across all organizational units and regions simultaneously.
• Duplicate Event Suppression: AWS Health occasionally emits state-change events multiple times for the same underlying incident (`AFFECTED_ENTITY`, `UPCOMING`, `RESOLVED`). Lambda functions processing these events should implement deduplication logic using Amazon DynamoDB if notification noise reduction is required.

To validate the pipeline from a staging or testing account without waiting for an actual AWS outage, developers can inject a synthetic test event directly into the custom event bus using the AWS CLI:

aws events put-events --entries '[
  {
    "Source": "aws.health",
    "DetailType": "AWS Health Event",
    "Detail": "{\"service\": \"EC2\", \"eventTypeCode\": \"AWS_EC2_MAINTENANCE\", \"arn\": \"arn:aws:health:us-east-1:111122223333:event/EC2/AWS_EC2_MAINTENANCE_TEST\", \"region\": \"us-east-1\", \"startTime\": \"2026-03-30T12:00:00Z\", \"eventDescription\": [{\"latestDescription\": \"This is a simulated AWS Health operational notice for testing pipeline integrity.\"}]}",
    "EventBusName": "HealthCentralBus"
  }
]'

Diagnostic Verification & Checklist

Post-deployment validation ensures that cross-account event propagation, IAM permissions, and email delivery mechanisms function without degradation. Use the following verification matrix to audit the environment:

Continuous monitoring of CloudWatch Alarms configured on Lambda `Errors` and `Throttles` metrics ensures rapid notification if IAM trust policies expire or cross-account resource policies are inadvertently modified during subsequent infrastructure updates.