@medikoo I have completed work on the branch linked to above to deploy EventBridge resources using CloudFormation. I have no doubt there will be changes needed as it is not a trivial change and I’ve had to do a lot learning about how the framework is operation to complete it. Are you happy for me to create a PR off of it and we can go from there?

Glad to help!

Just to recap, the workaround is not to use an imported value but passing the eventbus’ name instead of the ARN.

This virtually removes the ability of using eventbus’ ARN (it will only work when it’s hardcoded). I believe that’s fine as we can still use eventbus’ name. But, yes, it should be clarified in the documentation.

Summing up:

- eventBridge:
    eventBus: arn:aws:events:us-east-1:12345:event-bus/custom-private-events   # this will work! :)


- eventBridge:
    eventBus: custom-private-events   # this will work! :)


- eventBridge:
    eventBus: !Ref EventBus   # this will work! :)


- eventBridge:
    eventBus: !GetAtt EventBus.Name   # this will work! :)


- eventBridge:
    eventBus: !ImportValue EventBusName   # this will work as long as the Output refers to eventbus' name! :|


- eventBridge:
    eventBus: !GetAtt EventBus.Arn   # this WON'T work! :(

@DaveLo I’ve looked into that more deeply, and to me it appears that there’s inconsistency in our config design.

e.g. for S3 buckets or cognito user pools, resources are referenced by name, and via additional existing: true setting we eventually mark that given resource already exists, so there should not be creation attempt.

While in case of event bridge, we resolve the intention from the name format (if it’s an ARN, we imply existing: true, and if not, then we create).

I believe right way to approach it, is to bring same existing: true setting support to event bridge configuration (and ensure that that CF instructions are supported for name), that way it’ll work for you as expected. (Unfortunately to not break things in v1, we still need to support ARN resolution).

@pmuens What do you think about that?

Thank you both @cjuega and @capgadsx - I believe I know what the issue is here. In order to generate proper AWS:SourceArn we need to have the ability to extract name of the event bus. It was possible to do when using explicit arn passed as a string, however, when passing arn with CF intrinsic command, it’s impossible to reason about name, which results in invalid SourceArn being generated. The proper approach in that situation would be to pass imported name as suggested in workaround by @cjuega. I believe we should clarify that in the documentation.

What is the current situation regarding this case? Is a bug fix planned?

Thanks @DaveLo for looking into that.

Firstly, this issue comes from fact, that CloudFormation instructions are not normally supported on serverless configuration level. Technically they can be supported only if given setting value is propagated as is to CloudFormation template property (where given instruction is supported), but it requires further effort to implement such support.

Ideally Framework should fail with a meaningful error on such attempts, but it doesn’t (hence ugly errors as EventBus.startsWith is not a function). We plan to address that at #6562

Now, concerning your proposal (on bringing support for CF instruction format to eventBus property):

but exporting the Ref rather than the full Arn it seems to not realize the eventbus already exists.

Currently the framework assumes event bus exists, only if value passed to eventBus resolves to string that starts with arn. See, this setting is propagated as is to custom resource:

https://github.com/serverless/serverless/blob/2938a95b8711d3bfab1e665318f46f66db91d6a4/lib/plugins/aws/package/compile/events/eventBridge/index.js#L94

and then read here:

https://github.com/serverless/serverless/blob/2938a95b8711d3bfab1e665318f46f66db91d6a4/lib/plugins/aws/customResources/resources/eventBridge/lib/eventBridge.js#L10

Hey, I thought I might take a crack at this. I looked at how it’s handled in SQS events, but I don’t think it tracks exactly.

From looking at the code it looks like we always want the event bus name not the arn so that it can be used in constructing the rule arn. maybe it’s easier to import the name by exporting the external Ref (name for EventBridge)? Then you could look for Fn::ImportValue ((typeof EventBus !== 'string' && 'Fn::ImportValue' in EventBus) from sqs event) and workflow from there?

ruleResource = {
  'Fn::Join': [
    ':',
    [
      'arn:aws:events',
      { Ref: 'AWS::Region' },
      { Ref: 'AWS::AccountId' },
      { 
        'Fn::Join': [
          "/",
          [
            'rule',
            {'Fn::ImportValue':  EventBus['Fn::ImportValue' },
            RuleName
          ]
        ]
      }
    ],
  ],
};

@pgrzesik, do you mean before using the new useCloudFormation: true feature? I used to pass it explicitly in an envvar. Using !ImportValue thrown an EventBus.startsWith is not a function error as described in the bug report.

According to serverless’ doc, this should be supported:

- eventBridge:
    eventBus: arn:aws:events:us-east-1:12345:event-bus/custom-private-events
    pattern:
      source:
        - custom.private
    inputTransformer:
      inputPathsMap:
        eventTime: '$.time'
      inputTemplate: '{"time": <eventTime>, "key1": "value1"}'

After the changes implemented at https://github.com/serverless/serverless/pull/8437, I would expect the following to also be supported:

- eventBridge:
    eventBus: !GetAtt EventBus.Arn
    pattern:
      source:
        - custom.private
    inputTransformer:
      inputPathsMap:
        eventTime: '$.time'
      inputTemplate: '{"time": <eventTime>, "key1": "value1"}'

am I missing something?

I’m experiencing issues with this implementation in serverless@v2.28.0. Here is my setup:

provider:
  ...
  eventBridge:
    useCloudFormation: true

I have the following resource defined:

Resources:
  DomainEventBus:
    Type: AWS::Events::EventBus
    Properties:
      Name: ${env:PROJECT}-${env:STAGE}-events

Outputs:
  DomainEventBusArn:
    Value: !GetAtt DomainEventBus.Arn
    Export:
      Name: ${env:PROJECT}-${self:provider.stage}-DomainEventBusArn

Then, in my lambda definitions, I use !GetAtt DomainEventBus.Arn or !ImportValue DomainEventBusArn to indicate which eventbus triggers a lambda:

  events:
    - eventBridge:
        eventBus: !GetAtt DomainEventBus.Arn

Deployment works fine. It seems everything is correct. However, my lambdas are not triggered when events are sent to the bus. After some troubleshooting I have found lambdas’ Resource-based policy is wrong. In particular, AWS:SourceArn condition has a wrong ARN. It seems eventbus’ name is not extracted from the ARN in order to build rule’s ARN.

The quick workaround is to use !Ref DomainEventBus to use eventbus’ name instead of its ARN.

@stuartforrest-infinity, do you think your change may have broken this? Using ARN used to work when using custom resources to create the event bus.

I think guidance on importing the resources can be provided and potentially a helper script to output the required CloudFormation

@stuartforrest-infinity if it’s the case, then definitely we can include that, and all the instructions can be put into documentation of deprecation (we document each one here: https://www.serverless.com/framework/docs/deprecations/)

not authorized to perform: events:CreateEventBus

If you mean that this crash happens in custom resource lambda (during deployment), then it means that setup of access rules which this lambda needs, needs to be updated here:

https://github.com/serverless/serverless/blob/fbf99fa2abf9ce3bc13fc4a6c8439a650d3eaa4e/lib/plugins/aws/package/compile/events/eventBridge/index.js#L152-L168