1

What is the best way to migrate invocation of Lambda function from Cloudwatch event to Event Source Mapping(Triggers) with minimum risk and downtime?

Our application uses cloudwatch event rule to invoke Lambda at fixed rate, which then polls SQS queue to get messages, we want to automatically invoke the lambda using SQS trigger(ESM).

Brainstormed a couple approaches:

Option 1. Hookup both, trigger and cloudwatch event to existing Lambda, then slowly deprecate event rule.
Option 2. Using duplicate lambda with event source as SQS queue and divide the traffic, deprecate original lambda later.
Option 3. Add additional SQS(subscribed to same SNS) and Lambda pair which uses the trigger, deprecate the original later. I am sure many teams might have done similar migration, any insights would be appreciated.

John Rotenstein
  • 241,921
  • 22
  • 380
  • 470
clumsycoder
  • 11
  • 2
  • I’m not sure any of these options will work without a little bit of tweaking to the lambda source code. I think there is a difference in the payload shape/structure between `sqs.receive_messages` and the event sent directly by SQS – deric4 Feb 20 '22 at 19:38
  • Yes, Lambda code will need to be refactored. In Option 1, I'll have to figure out a way to deserialize the object on the basis of payload(whether its event or message), if there is any such thing. – clumsycoder Feb 21 '22 at 17:04

1 Answers1

0

Your option 2 in the simpler way to switch.

Since you have CW event schedule, you lambda can execute maximum once per minute as the minimum precision for schedules is 1 minute.

  1. Create new lambda
  2. Set concurrency for old lambda to zero
  3. Enable SQS trigger for new lambda
  4. Delete event schedule trigger in old lambda
omuthu
  • 5,948
  • 1
  • 27
  • 37