Overview

While configuring EFS restore alerts via AWS Backup → EventBridge → SNS, you may face a situation where:

✅ Broad rules work (source: aws.backup)
❌ Filtered rules do NOT trigger
❌ No alert received for restore

Even when configuration looks correct.

Problem Scenario

Working rule: Create this rule first as it activates on every event. This will assist in identifying whether the issue is with configuration or the JSON rule.

{
  "source": ["aws.backup"]
}

Event filtering mismatch (primary issue)

EventBridge requires exact matching.

👉 Problem:

• resourceType = "EFS" may not exist or match in actual event

👉 Result:

• Rule never triggers

Inconsistent AWS Backup event structure

AWS Backup events can vary:

• status vs state
• resourceType sometimes missing
• Actual resource identified using resourceArn

👉 Leads to: ❌ Strict filters fail

AM Role / Permission Issue (CRITICAL – your addition)

👉 This is a major hidden problem in many cases.

Even if EventBridge rule matches:

❌ SNS/email still may NOT be triggered

Finally we updated the JSON for the alert like EFS

{
  "source": ["aws.backup"],
  "detail-type": ["Restore Job State Change"],
  "detail": {
    "status": ["COMPLETED"],
    "resourceType": ["EFS"],
  }
}

Then it started working with the correct rules and the appropriate JSON syntax, which generates an SNS alert whenever a restore operation is performed on the Elastic File System (EFS) of AWS. This configuration ensures that all necessary stakeholders are promptly notified about the status of the restore operation, allowing for better monitoring and response times. By leveraging the power of AWS’s Simple Notification Service, system administrators can automate alerting processes, which significantly enhances operational efficiency and minimizes downtime during critical restoration tasks. Furthermore, these alerts can be customized to provide detailed information about each restore request, including timestamps and relevant parameters, making it easier for teams to assess the effectiveness of their data recovery strategies.