AWS Health Dashboard and EventBridge Integration

The AWS Health Dashboard is the authoritative source of information about AWS service health. It consists of two distinct components:

When an AWS service experiences an issue that could impact customers, the AWS Health team creates an event. This event is classified into one of several categories:

Each event has a unique arn (Amazon Resource Name) and includes metadata such as service, region, startTime, endTime, statusCode, and eventTypeCategory. For accountNotification and scheduledChange, the event is automatically scoped to the affected account. For issue events, the PHD only shows the event if the affected resources overlap with your account (e.g., if the issue is in an Availability Zone where you have resources).

Amazon EventBridge (formerly CloudWatch Events) is a serverless event bus that ingests events from AWS services and routes them to targets (e.g., Lambda, SNS, SQS, Step Functions). The AWS Health service is a native event source for EventBridge. When a Health event is created or updated, it is automatically sent to the default event bus in the same account and region. However, there are critical nuances:

To integrate PHD events with EventBridge, you create a rule that matches the event pattern. The event pattern uses JSON structure to filter specific events. For example:

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

This rule triggers only on scheduled changes for EC2. You can further filter by region, eventTypeCode, statusCode, etc. The rule then sends the event to a target such as a Lambda function that can automate remediation (e.g., snapshot an EBS volume before retirement).

- Event Structure: Each Health event in EventBridge has a detail-type of "AWS Health Event". The source is always "aws.health". The detail object contains: - eventArn: Unique identifier. - service: The AWS service (e.g., "EC2", "RDS"). - eventTypeCode: A specific code (e.g., "AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED"). - eventTypeCategory: One of issue, accountNotification, scheduledChange. - region: The affected region. - startTime, endTime: ISO 8601 timestamps. - statusCode: open, closed, upcoming. - affectedEntities: An array of ARNs for the affected resources (only for account-specific events).

To configure the integration:

{
  "Effect": "Allow",
  "Principal": {
    "Service": "events.amazonaws.com"
  },
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-1:123456789012:function:my-function",
  "Condition": {
    "ArnLike": {
      "AWS:SourceArn": "arn:aws:events:us-east-1:123456789012:rule/my-rule"
    }
  }
}

To verify the integration:

aws health describe-events --filter "{\"services\":[\"EC2\"],\"eventTypeCategories\":[\"scheduledChange\"]}"

Note that you cannot manually create Health events; you must wait for actual events or use the AWS Health API to retrieve past events.

By default, Health events are delivered to the event bus in the same account and region as the event. To centralize health events from multiple accounts, you can use cross-account event buses in EventBridge. This requires:

For cross-region, you can create a rule in one region that sends events to a target in another region (e.g., a Lambda function in us-west-2). However, the event itself is region-specific; you cannot have a single rule catch all regions unless you create separate rules per region.

A large SaaS company runs thousands of EC2 instances across multiple accounts. When AWS schedules an instance retirement (e.g., due to underlying hardware degradation), the company needs to automatically snapshot the root volume, launch a replacement instance, and update DNS. They configure an EventBridge rule in each account that matches eventTypeCategory: "scheduledChange" and service: "EC2". The target is a Lambda function that checks the affectedEntities list, identifies the instance, creates an AMI, and launches a new instance in the same Auto Scaling group. They also send a notification to an SNS topic that posts to their internal ticketing system. This automation reduces the manual effort from 30 minutes per instance to near-zero and eliminates the risk of missing retirement deadlines. A common misconfiguration is forgetting to add the resource-based policy to Lambda, causing the rule to never trigger. Additionally, they had to increase the Lambda timeout to 5 minutes to handle large instances.

A financial services company uses AWS Organizations with 50 member accounts. They want a single dashboard that shows all Health events across all accounts. They set up a central event bus in the management account and create EventBridge rules in each member account that forward Health events to the central bus. The central bus then has rules that send events to a central SNS topic and a Step Functions workflow for incident management. They also use AWS Health's integration with AWS Config to trigger Config rules when a Health event occurs. For example, when an RDS maintenance event is detected, a Config rule checks if the database is encrypted. This centralized approach required careful IAM permissions: each member account needed a policy allowing events:PutEvents to the central bus, and the central bus needed a resource-based policy allowing member accounts to send events. They also had to handle cross-region events by creating separate rules per region. The main challenge was managing the 300 rule limit per event bus; they had to aggregate rules by service to stay within limits.

A gaming company uses a mix of EC2 and RDS instances. They receive scheduled change events for OS patching and RDS maintenance windows. They integrate Health events with AWS Systems Manager Automation. An EventBridge rule triggers a Systems Manager Automation document that patches the instance during the maintenance window, then reboots if necessary. They also use the statusCode field to detect when an event transitions from upcoming to open, triggering immediate action. The automation document includes error handling: if patching fails, it sends a notification to an SNS topic. They found that some events had affectedEntities with multiple ARNs, requiring the automation to iterate over each. They also had to ensure the Automation role had sufficient permissions to perform the patching. A pitfall was assuming that all scheduled changes have a startTime; some events use endTime as the deadline, and they had to adjust their logic accordingly.