Creating Event Rules for User Notificatiosn fails in Cloudformation

You need to create a separate notification configuration per rule. I have tried this below and it worked.

Resources:  
  NotificationConfiguration01:
    Type: AWS::Notifications::NotificationConfiguration
    Properties:
        AggregationDuration: LONG
        Description: 'demo'
        Name: 'unique01'

  NotificationConfiguration02:
    Type: AWS::Notifications::NotificationConfiguration
    Properties:
        AggregationDuration: LONG
        Description: 'demo'
        Name: 'unique02'


  EC2EventRule:
    Type: AWS::Notifications::EventRule
    Properties:
      EventPattern: "{\"detail\":{\"service\":[\"EC2\"],\"eventTypeCategory\":[\"issue\"],\"eventTypeCode\":[\"AWS_EC2_OPERATIONAL_ISSUE\"]}}"
      EventType: AWS Health Event
      NotificationConfigurationArn: !Ref NotificationConfiguration01
      Regions: 
        - us-east-1
      Source: aws.health
  # Event Rule for EC2 Operational Issues
  EKSEventRule:
    Type: AWS::Notifications::EventRule
    Properties:
      EventPattern: "{\"detail\":{\"service\":[\"EKS\"],\"eventTypeCategory\":[\"issue\"],\"eventTypeCode\":[\"AWS_EKS_OPERATIONAL_ISSUE\"]}}"
      EventType: AWS Health Event
      NotificationConfigurationArn: !Ref NotificationConfiguration02
      Regions: 
        - us-east-1
      Source: aws.health

When creating multiple AWS::Notifications::EventRule resources in CloudFormation that share the same source and event type, you're encountering an "AlreadyExists" error. This is happening because AWS User Notifications is identifying these rules as duplicates based on their core attributes.

The error message indicates that a resource with the identifier "arn:aws:notifications::783764604858:configuration/a01k97w9zgqv9j26zrvyszk8nnt|source=aws.health, eventType=AWS Health Event" already exists. This suggests that User Notifications is using a combination of the NotificationConfiguration ARN, source, and eventType as a unique identifier for rules.

Even though your rules have different EventPatterns (one for EC2 and one for EKS), they share the same:

• Source: aws.health
• EventType: AWS Health Event
• NotificationConfigurationArn: (the same reference)

To resolve this issue, you have a few options:

1. Create a single EventRule with a combined EventPattern that includes both services:

EventPattern: "{\"detail\":{\"service\":[\"EC2\",\"EKS\"],\"eventTypeCategory\":[\"issue\"],\"eventTypeCode\":[\"AWS_EC2_OPERATIONAL_ISSUE\",\"AWS_EKS_OPERATIONAL_ISSUE\"]}}"

2. Create separate NotificationConfiguration resources for each rule, so they don't share the same configuration ARN.

3. Use a different approach like AWS::Events::Rule (EventBridge rules) that forward to SNS topics, which can then be configured as channels in your notification configuration.

The status of EventRules can be monitored through their Status property, which can be ACTIVE, INACTIVE, CREATING, UPDATING, or DELETING. When troubleshooting CloudFormation deployments, you can use the describe-events command with the FailedEvents filter to quickly identify the root causes of deployment failures.
Sources
EventRuleStructure - AWS User Notifications
difficulties with EventBridge in CF template, unclear what causes the error | AWS re:Post
AWS::Notifications::EventRule EventRuleStatusSummary - AWS CloudFormation
Accelerate infrastructure development with CloudFormation pre-deployment validation and simplified troubleshooting | AWS DevOps & Developer Productivity Blog

I was able to loop through a var using this:

  Fn::ForEach::OperationalIssuesEventRules:
    - OPISSUE_Service
    - !Ref OPERATIONALISSUEServices
    - 'NotificationConfiguration${OPISSUE_Service}':
        Type: AWS::Notifications::NotificationConfiguration
        Properties:
          AggregationDuration: SHORT
          Description: !Sub ${ResourcePrefix} implementation of Notification configurtion for sending alerts to MSTeams
          Name: !Sub ${ResourcePrefix}_${OPISSUE_Service}
          Tags: 
            - Key: Deployment
              Value: !Ref TagName
            - Key: DeployDate
              Value: !Ref TagDate
            - Key: DeployedBy
              Value: !Ref TagDeployedBy  
      'EventRule${OPISSUE_Service}':
        Type: AWS::Notifications::EventRule
        Properties:
          EventPattern: "{\"detail\":{\"service\":[\"${OPISSUE_Service}\"],\"eventTypeCategory\":[\"issue\"],\"eventTypeCode\":[\"AWS_${OPISSUE_Service}_OPERATIONAL_ISSUE\"]}}"
          EventType: AWS Health Event
          NotificationConfigurationArn: !GetAtt
            - !Sub NotificationConfiguration${OPISSUE_Service}
            - Arn
          Regions: 
            - !Ref Regions
          Source: aws.health
      'NotificationChannel${OPISSUE_Service}':
        Type: AWS::Notifications::ChannelAssociation
        Properties:
          Arn: !Ref DeliveryChannel
          NotificationConfigurationArn: !GetAtt
            - !Sub NotificationConfiguration${OPISSUE_Service}

Now I have run into non-adjustable quota limits: Details Description The maximum number of notification configurations by Service and Event type you can create for a given AWS account.

It seems that without allowing wildcards this service is barely usable if you want to filter the events properly?