Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon EventBridge can monitor events generated by AWS services and route matching events to targets such as Amazon SNS, AWS Lambda, Step Functions, SQS, or other EventBridge event buses. A common pattern is detecting an EC2 instance state change and sending a notification or initiating automated remediation.
This lesson focuses on creating an EventBridge rule that matches EC2 termination events and sends them to an Amazon SNS topic with an email subscription.
Key Concepts
EventBridge event buses
An event bus receives events and evaluates them against rules. AWS services generally publish events to the account’s default event bus. You can also use:
- Custom event buses for application or domain events.
- Partner event buses for events from supported SaaS providers.
- Cross-account or cross-Region event delivery patterns for centralized event processing.
For EC2 service events, the default event bus is typically sufficient.
EventBridge rules
A rule defines:
- An event pattern that determines which events match.
- One or more targets that receive matching events.
- Optional scheduling, although this use case is event-based rather than scheduled.
An EC2 termination rule can match events with properties similar to:
{
"source": ["aws.ec2"],
"detail-type": ["EC2 Instance State-change Notification"],
"detail": {
"state": ["terminated"]
}
}
The event pattern can be made more specific by including an instance ID, Availability Zone, account, Region, or other event fields when those fields are available.
EC2 instance state-change notifications
EC2 publishes state-change events when an instance transitions between states such as:
pendingrunningstoppingstoppedshutting-downterminated
A rule can match one or more states. For example, terminated is useful for notifications, inventory updates, cleanup workflows, or security investigations.
SNS as an EventBridge target
Amazon SNS is useful when an event should be delivered to multiple subscribers or notification channels. For an email notification workflow:
- Create an SNS standard topic.
- Create an email subscription to the topic.
- Confirm the subscription through the email message.
- Select the topic as the EventBridge rule target.
An unconfirmed email subscription will not receive notifications.
Event payloads
The event delivered to the target is JSON and commonly includes information such as:
- Event type
- Event source
- AWS account ID
- Region
- Event timestamp
- EC2 instance ID
- New instance state
Applications can parse this payload to update an inventory database, invoke remediation, or create an operational record.
EventBridge and CloudTrail are different event sources
A key distinction for exam questions:
- EventBridge service events are generated directly by AWS services. EC2 instance state-change notifications are an example.
- CloudTrail events represent API activity, such as an identity calling
TerminateInstances.
An EventBridge rule for EC2 instance state-change notifications does not generally require a CloudTrail trail. CloudTrail is needed when the requirement is to capture and react to API calls or management events, rather than the resulting EC2 state transition.
Exam-Relevant Takeaways
- Use EventBridge for loosely coupled, event-driven routing between AWS services and applications.
- Use an EventBridge event pattern to filter events by source, detail type, and event fields.
- EC2 state-change notifications use the event detail type
EC2 Instance State-change Notification. - Route matching events to SNS for notifications, Lambda for code-based processing, SQS for durable asynchronous consumption, or Step Functions for multi-step workflows.
- An email SNS subscription must be confirmed before it can receive messages.
- EventBridge rules can have multiple targets, allowing one event to trigger several independent workflows.
- Do not confuse an EC2 state-change event with a CloudTrail API event. Choose CloudTrail when the requirement is auditing API calls, caller identity, or management activity.
- EventBridge delivery is asynchronous. Architect downstream processing to tolerate retries and duplicate handling where appropriate.
- Add permissions for targets when required. For example, EventBridge may need permission to invoke a Lambda function or publish to an SNS topic, depending on the target configuration and service integration.
Architecture Decision Guide
| Requirement | Recommended design | Why |
|---|---|---|
| Email or fan-out notification when an instance terminates | EventBridge rule to SNS | Simple, decoupled notification workflow |
| Run custom code when an instance stops | EventBridge rule to Lambda | Supports validation, enrichment, and remediation logic |
| Process events reliably at variable throughput | EventBridge rule to SQS | Provides buffering and independent consumer processing |
| Coordinate cleanup across several AWS services | EventBridge to Step Functions or Lambda | Supports orchestration and controlled error handling |
| Record every EC2 lifecycle event for later analysis | EventBridge to Kinesis Firehose, S3, or a processing service | Suitable for durable event collection and analytics |
| Identify who called an EC2 API operation | CloudTrail, optionally routed through EventBridge | CloudTrail contains API identity and request context |
| React to a service state transition | EventBridge service event | Does not depend on a CloudTrail trail for the state notification |
| Route events between accounts or Regions | EventBridge bus-to-bus forwarding | Enables centralized event processing and governance |
Common Exam Traps
- Assuming CloudTrail is required for every EventBridge rule: EC2 state-change notifications are native service events. CloudTrail is relevant when the rule matches CloudTrail API activity.
- Using SNS alone for event filtering: SNS distributes messages but is not the primary service for rich AWS event-pattern matching. EventBridge should perform the filtering.
- Forgetting subscription confirmation: An email subscription remains inactive until the recipient confirms it.
- Matching the wrong event type:
EC2 Instance State-change Notificationdescribes the lifecycle state event. It is different from an API event such asTerminateInstances. - Expecting guaranteed exactly-once processing: Event-driven systems should make consumers idempotent and account for retries or duplicate delivery.
- Filtering too broadly: A rule matching every EC2 state change can generate unnecessary notifications and invoke avoidable downstream processing. Filter by state, instance, account, or Region when appropriate.
- Confusing termination with stopping:
stoppedandterminatedhave different operational and cost implications. A termination rule will not match an instance that is merely stopped. - Assuming an event contains arbitrary application data: Service event schemas contain fields defined by the service. Use enrichment or a downstream lookup when additional context is needed.
Real-World Engineer Notes
- Use separate rules for different operational actions when notification, remediation, and audit workflows have different ownership or failure requirements.
- Include the account ID, Region, instance ID, state, and timestamp in notifications so operators can act without looking up basic context.
- For automatic cleanup, verify that the resource is truly orphaned before deleting snapshots, AMIs, volumes, or other related assets. Termination alone may not prove that a resource is safe to remove.
- Lambda targets are appropriate for short, event-driven tasks. Use Step Functions for workflows requiring retries, branching, waits, or explicit state tracking.
- SQS is preferable when downstream processing may be slow or temporarily unavailable. Configure a dead-letter queue for messages that repeatedly fail.
- Protect cross-account event routing with explicit event bus resource policies and least-privilege IAM permissions.
- Disable or delete temporary lab rules and subscriptions to avoid unwanted notifications and unnecessary operational clutter.
- CloudTrail and EventBridge can complement one another: EventBridge can initiate rapid automation, while CloudTrail provides a durable audit record of API activity when configured appropriately.
Quick Reference Summary
- Source: Amazon EC2 service events
- Event bus: Usually the default EventBridge event bus
- Event type:
EC2 Instance State-change Notification - Useful filter:
detail.state = terminated - Notification target: Amazon SNS
- Automation targets: Lambda, SQS, Step Functions, EventBridge bus, and others
- Email prerequisite: Confirm the SNS subscription
- CloudTrail requirement: Not normally required for native EC2 state-change events; required for auditing API calls and management activity
- Design principle: Keep event producers and consumers loosely coupled, and make consumers idempotent
Flashcards
1. What AWS service evaluates event patterns and routes matching events to targets?
Answer: Amazon EventBridge.
2. Which EventBridge event type represents an EC2 lifecycle transition?
Answer: EC2 Instance State-change Notification.
3. Which event field can be used to match only terminated instances?
Answer: detail.state with the value terminated.
4. Which EventBridge event bus normally receives AWS service events in an account?
Answer: The default event bus.
5. What must an email recipient do before an SNS email subscription becomes active?
Answer: Confirm the subscription using the link in the confirmation email.
6. Is a CloudTrail trail normally required for an EC2 state-change notification rule?
Answer: No. The notification is a native EC2 service event. CloudTrail is needed for API audit events and caller information.
7. Which target is a strong choice when events must be buffered for later processing?
Answer: Amazon SQS, optionally with a dead-letter queue.
8. Which target is suitable for a multi-step workflow with retries and branching?
Answer: AWS Step Functions.
9. Why should EventBridge consumers be idempotent?
Answer: Asynchronous event delivery can involve retries or duplicate processing, so repeating an event should not corrupt state or repeat an unsafe action.
10. What is the distinction between an EC2 state-change event and a TerminateInstances CloudTrail event?
Answer: The state-change event reports the instance lifecycle transition; the CloudTrail event records an API call, including the identity and request context.
Practice Questions
Question 1
A company wants to send an email whenever any EC2 instance in its account enters the terminated state. The solution should require minimal application code. Which design is most appropriate?
A. Configure an SNS topic to poll EC2 instance states.
B. Create an EventBridge rule matching EC2 terminated state-change events and target an SNS topic with a confirmed email subscription.
C. Create a CloudTrail trail and configure an S3 event notification for the trail bucket.
D. Run a scheduled Lambda function every minute to describe all EC2 instances.
Correct answer: B
Explanation: EventBridge natively receives EC2 state-change events and can filter for terminated. SNS provides the email notification path. Polling and scheduled inventory scans are less efficient, and S3 notifications from CloudTrail do not directly provide this event-driven workflow.
Question 2
An operations team must determine which IAM principal called the EC2 TerminateInstances API and then notify a security system. Which approach best meets the requirement?
A. Match EC2 terminated state-change events only.
B. Use CloudTrail management events and route matching CloudTrail events through EventBridge.
C. Use EC2 instance metadata and send it to SNS.
D. Configure an Auto Scaling lifecycle hook.
Correct answer: B
Explanation: CloudTrail records API activity, including the calling identity and request details. EventBridge can route matching CloudTrail events to the security system. A state-change notification confirms the result but does not provide the complete API audit context.
Question 3
A rule sends EC2 termination events to a Lambda function that removes related resources. Occasionally, the function is invoked more than once for the same instance. What is the best engineering response?
A. Assume EventBridge guarantees exactly-once delivery.
B. Make the Lambda operation idempotent and track processed instance events where necessary.
C. Replace EventBridge with an SNS topic because SNS guarantees exactly-once delivery.
D. Disable retries on all AWS services.
Correct answer: B
Explanation: Event-driven consumers should tolerate retries and duplicate delivery. Idempotency controls prevent repeated processing from causing destructive or inconsistent results.
Question 4
A company wants to perform several cleanup steps after an EC2 instance is terminated, including validation, waiting for dependent resources to become available, retries, and a final notification. Which target is the strongest fit?
A. Amazon SNS email subscription directly
B. AWS Step Functions started by an EventBridge rule
C. An EC2 user data script
D. A CloudTrail S3 data event
Correct answer: B
Explanation: Step Functions provides workflow state, branching, retries, waits, and failure handling. EventBridge can trigger the state machine when the EC2 event matches.
Question 5
An engineer creates an EventBridge rule targeting an SNS topic with an email subscription, but no email arrives after an instance is terminated. The rule shows matching invocations. What should be checked first?
A. Whether the EC2 instance has a key pair.
B. Whether the SNS email subscription was confirmed.
C. Whether the instance has an Elastic IP address.
D. Whether the EventBridge rule uses a custom event bus.
Correct answer: B
Explanation: SNS email subscriptions do not deliver messages until the recipient confirms the subscription. The invocation count indicates that EventBridge is matching and attempting to deliver the event.