An extra 30% off every course until Sunday, October 11.Choose your certification →

Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.

3.3.1.1. AWS Services that Generate, Capture, and Process Events (Health, EventBridge, CloudTrail)

3.3.1.1. AWS Services that Generate, Capture, and Process Events (Health, EventBridge, CloudWatch)

Every operational incident starts with an event. Understanding which services generate events and how to route them determines whether your team learns about problems from dashboards or from angry customers.

Event sources and what they detect:
SourceEvents GeneratedUse Case
AWS HealthService disruptions, maintenance, abuse notificationsRegional/account-specific issues
EventBridgeAll AWS API activity + custom eventsCentral event routing
CloudWatch AlarmsMetric threshold breachesPerformance/availability alerting
GuardDutyThreat findings (compromised instance, IAM anomaly)Security incidents
CloudTrailAll API callsAudit and forensics
ConfigResource configuration changesCompliance drift
InspectorVulnerability findingsSecurity patching priorities
Event routing through EventBridge:
{
  "source": ["aws.health"],
  "detail-type": ["AWS Health Event"],
  "detail": {
    "eventTypeCategory": ["issue"],
    "service": ["EC2", "RDS"]
  }
}

AWS Health events are particularly important for incident response — they notify you when AWS itself is having issues that affect your resources. Personal Health Dashboard events are account-specific (your scheduled maintenance), while Service Health Dashboard events are global.

Event processing architecture:
  • Simple alerting: EventBridge → SNS → Email/Slack
  • Automated remediation: EventBridge → Lambda → fix the issue
  • Complex workflows: EventBridge → Step Functions → multi-step incident response
  • Audit trail: EventBridge → Kinesis Firehose → S3 → Athena

Paging and escalation (Systems Manager Incident Manager): a CloudWatch alarm or EventBridge event starts a response plan, which opens an incident record, pages responders through an escalation plan (ordered stages with acknowledgment timeouts), and can run an SSM Automation runbook automatically as soon as the incident starts. Contact channels (SMS, voice, email) and chat channels only notify people; the runbook is the part that acts. Note: Incident Manager stopped accepting new customers on November 7, 2025; existing customers can keep using it. For a new setup, AWS recommends Systems Manager OpsCenter for tracking operational issues and AWS Partner tools such as PagerDuty for paging and escalation.

Which Region receives Health events: account-specific regional events (e.g., EC2 instance retirement) are delivered to EventBridge in the Region where the affected resource lives (plus a copy in the us-west-2 backup Region). Only global events (e.g., IAM) go to us-east-1, so create the rule in the resources' Region. A typical proactive response to a retirement notice: EventBridge → SSM Automation that stops and starts the EBS-backed instance before the deadline, moving it to healthy hardware.

Exam Trap: AWS Health events for planned maintenance include an eventScopeCode of ACCOUNT_SPECIFIC — meaning the maintenance affects your resources specifically. If you see a Health event with ACCOUNT_SPECIFIC scope, you must act on it. PUBLIC scope events are informational about the broader service. The exam may ask you to distinguish between these scopes when designing alerting rules.

See how it connects
Alvin Varughese
Written byAlvin Varughese
Founder•20 professional certifications