CODEWITHSUNDEEP
aws-lambdaamazon-dynamodb
ArielB
ArielB

Reputation: 1274

serverless - dynamo streams - how to setup destinationConfig?

i have the following lambda configuration:

MyFunc:
handler: my_handler
timeout: 60
role: myrole
events:
  - stream:
      type: dynamodb
      arn: <<dynamo_db_stream_arn>
      startingPosition: LATEST
      maximumRetryAttempts: 3
      destinations:
        onFailure: <sqs_queue_arn>
      enabled: True

Yet, when deploying, i don't see that the onFailure is even rendered in the cloudformation template. i've set it up as said in this documentation: https://serverless.com/framework/docs/providers/aws/events/streams/

Any idea what i'm missing?

==========================

So, completing Snickers3192's answer - I actually am not sure what's wrong with the configuration above, as serverless should support it, but eventually what i did is created the stream handler in another resource, so basically my serverless looks like that:

functions:
  MyFunc:
  handler: my_handler
  timeout: 60
  role: myrole

resources:
  Resources:
    MySourceMapping:
      Type: AWS::Lambda::EventSourceMapping
      DependsOn: MyFuncLambdaFunction
      Properties:
        EventSourceArn: <dynamo_db_stream_arn>
        FunctionName: MyFunc
        MaximumRetryAttempts: 3
        StartingPosition: LATEST
        DestinationConfig:
          OnFailure:
            Destination: <sqs_queue_qrn>

Upvotes: 0

Views: 499

Answers (2)

jdcotter
jdcotter

Reputation: 413

I think you're just missing "arn:"

Here's what worked for us.

      maximumRetryAttempts: 10
      maximumRecordAgeInSeconds: 300
      bisectBatchOnFunctionError: true
      destinations:
        onFailure:
          arn:
            Fn::GetAtt:
              - fileReducerDeadLetterQueue
              - Arn
          type: sqs

Upvotes: 2

Derrops
Derrops

Reputation: 8137

Even though I like serverless framework, I don't recommend using it for anything other than developing Lambda functions, I wouldn't even use the http event for creating an API gateway. Stick to the unix philosophy do one thing good, that's how I feel serverless should stick to that, not try and become another terraform or something, it isn't.

So create your Lambda functions in serverless and that's it. Do the other stuff else where. If the resource can be managed effectively in Cloudformation AWS::Lambda::EventSourceMapping, then you can use that. If it makes sense to put it at the bottom of the serverless.yml in resources: you can do that, but if not then let it have it's own template.

There is quite a number of permissions needed for setting up your lambda for DynamoDB streams, I wouldn't trust serverless to do that for you. A proper AWS prod setup as well might not let some external tool create iam roles as well.

As soon as you differ the slightest little bit from the serverless default cloudformation template, you'll have problems, probably you are spending hours right now, on a tool which was supposed to save you time, therefore defeating it's purpose. I suggest making more stacks than less, and using conventions when one stack needs a Lambda in another, this is actually more manegable as when one thing fails you can still update other stacks, and swap stacks as you change, you can't do that if you stick it all in a serverless.yml.

Upvotes: 0

Related Questions