Wanting to trigger Lambda 10 minutes after receiving webhook.

Thanks @uri and @Ravisankar C for your quick answers. OK, it all seems a lot more confusing and complicated than it need be.

I think many people find the term "trigger" particularly confusing because we often think of a "trigger" as being something that causes an event, rather than something that keeps looking for an event to happen and using up quota.

With your suggestions finally I have figured out how to do this (with a bit of help from Claude AI! Sadly Amazon Q didn't seem to understand what I wanted).

Step 1: Create a rule by running the code below manually once (adding the arguments of course). Step 2: Go to your lamdba function and add a Cloudwatch Events trigger with the name of the trigger. Step 3: Now set your lambda code to run this below when the dropbox webhook is received (or whatever trigger you want) and it should work.

Here's the code if anyone else needs it:

async function createOneOffSchedule (ruleName, delayMinutes, functionArn, payload) {
  const cronExpression = createFutureCronExpression(1)
  const putRuleCommand = new PutRuleCommand({
    Name: ruleName,
    ScheduleExpression: `cron(${cronExpression})`,
    State: 'ENABLED'
  })

  const putTargetsCommand = new PutTargetsCommand({
    Rule: ruleName,
    Targets: [{ Id: 'LambdaTarget', Arn: functionArn, Input: JSON.stringify(payload) }]
  })

  try {
    await ebClient.send(putRuleCommand)
    await ebClient.send(putTargetsCommand)
    console.log(`One-off schedule "${ruleName}" created successfully.`)
  } catch (error) {
    console.error('Error creating one-off schedule:', error)
  }
}

function createFutureCronExpression (minutesOffset) {
  const date = new Date()

  date.setMinutes(date.getMinutes() + minutesOffset)

  const hours = date.getUTCHours()
  const minutes = date.getUTCMinutes()
  const dayOfMonth = date.getUTCDate()
  const month = date.getUTCMonth() + 1
  const year = date.getUTCFullYear()

  return `${minutes} ${hours} ${dayOfMonth} ${month} ? ${year}`
}

You are correct regading the trigger, however, as SQS doesn't support triggering other services, and we want to make the integrations as seemless as possible, and open new workloads, we created the pollers that look for the messages. BTW, polling an empty queue like this costs less than $0.26 per month.

A few points regarding the code that you wrote:

1. You wrote the code (in a Lambda function?) to configure the infrastructure. We have other, better suited options for that like CLoudFormation, SAM and CDK.
2. You are using the old way of creating schedules, using the Event Bus rules. We have the EventBridge Scheduler which allows to create one time schedules (as well as cron and rate based). There is no need to create rules. When you create the schedule, you define the target.

I am not sure how DropBox calls the webhook, but I would assume it does so for every file uploaded, this means that you will create multiple schedules for each folder. Make sure you handle that properly. Maybe each time you get a new webhook, you should update the previous one, so that it will invoke a few minutes after the last file is uploaded, to make sure that all are there.

Thank you @uri for that detailed but clear explanation.

I ended up creating a trigger like that because I asked Amazon Q what the best alternative to SQS and it suggested EventBridge, but wasn't so good at writing the code. So I asked a different AI and it suggested the code above. I couldn't find any way to create an event the "new" way that used cron and could deliver a small payload. It seems to work perfectly for my case.

Regarding multiple triggers: Yes, you are right it might retrigger lots of times, so this is what I put in place, based on quite a bit of testing. We know it never takes more than 10 minutes to upload the files. Some files are small and will produce multpiple rapid triggers, so we want Lambda to respond as fast as possible so a concurrent Lambda isn't triggered. Therefore:

As soon as Lamba is triggered by the first webhook, drop a lockfile and set the timer going. When the next webhook comes in, if there's a lockfile, quickly return an "OK" to Dropbox but go no further. When the EventBridge trigger arrives, process the Dropbox folder. Because the Webhooks requests arrive in quick succession, it's very unlikely that the Lambda will have gone to sleep and deleted the lockfile in between, but try and delete the lockfile anyway in case it still exists. From my testing, Lambda is responding in <20ms to Webhooks, and there's been no concurrency, so that's fine.

When I have more time later in the year I might try and re-work it the "proper" way :)

What do you mean by a lock file? A file in /tmp folder of the function? If this is the case, this is not tye right approach. Although it MAY be that we will reuse the same instance, it may well be that we will create new ones, especially if you have files uploaded to 2 folders calling the webhook. Use state inside the function is not recommended, and if it worked for you, it is pure luck.

You should keep the state in some external source, like DynamoDB. Use the DropBox folder name as the key and use DDB conditional writes to make sure that only one instance triggers the schedule.

BTW, based on what I see in your code, you do not need cron expressions, you need one time schedules. If you use the EventBridge Bus rules for this, you will very soon run out of your rule limit (300). EB does not delete the rules. You will need to delete them yourself. Maybe you can find some good code examples here.