3.2.3.1. Event-Driven, Asynchronous Design Patterns (S3 Events, EventBridge to SNS/Lambda)
3.2.3.1. Event-Driven Design Patterns for Monitoring
Event-driven monitoring replaces periodic polling with instant reaction. Instead of checking every 5 minutes, your system reacts the moment something happens.
Core pattern: Event Source → EventBridge Rule → Target (Lambda, SNS, SSM, Step Functions)
Common event-driven monitoring patterns:
| Event Source | Event | Automated Response |
|---|---|---|
| EC2 state change | Instance terminated unexpectedly | SNS alert + investigate via Lambda |
| Config rule | Resource becomes non-compliant | SSM Automation remediation |
| GuardDuty | High-severity finding | Lambda isolates instance (modify SG) |
| Health Dashboard | Service degradation in your region | Trigger DR failover runbook |
| CodePipeline | Pipeline execution failed | SNS to Slack + create incident ticket |
| CloudTrail | Root login detected | SNS alert + Lambda disable root keys |
# EventBridge rule pattern: match EC2 instance state changes
{
"source": ["aws.ec2"],
"detail-type": ["EC2 Instance State-change Notification"],
"detail": {
"state": ["terminated", "stopped"]
}
}
EventBridge vs. CloudWatch Events: EventBridge is the evolution of CloudWatch Events — same API, more features. EventBridge adds custom event buses, schema registry, archive/replay, and third-party SaaS integrations. For the exam, treat them as the same service.
Exam Trap: EventBridge rules in one region only match events from that region. If you need to react to events in us-west-2 but your automation runs in us-east-1, you must either create rules in us-west-2 or use EventBridge cross-region event buses to forward events. A common mistake is creating a rule in the wrong region and wondering why it never triggers.
