If you’re used to building Serverless scheduled jobs(CRON jobs) using AWS Cloudwatch & Lambda, you’ll be familiar with the fact that the maximum frequency at which you can invoke your lambda is 1 minute. This means, if you need sub minute invocations, you’re out of luck out of the box. This is a requirement sometimes, like when you need to keep your DB updated with a fast changing sports score board or a commentary system that is updated multiple times per minute.

For those who are not familiar with this setup, a typical AWS Cloudwatch Event + Lambda CRON with logging enabled will have the following structure:

Drawn using cloudcraft.io

Cloudwatch will trigger events periodically at the set interval without you needing to run any application code for triggering. Its pretty cheap too, costing around $1 per million events. If you convert that into minute frequency, you can easily invoke a lambda or whatever continuously over a month for under $1, because if you keep triggering something every minute for a 31 day month, the number of invocations will be 24*60*31=44,640 events, which is way under 1 million. Below is an example using Serverless Framework for the service we just discussed:

A minimal serverless.yml file for a CRON lambda that is invoked every 1 minute

These CRON functions are very useful in building serverless application stacks, some of the use cases I can think of now are:

Building tiny housekeeping services like log file removal

Starting an external service sync like fetching a CSV file

Triggering a build pipeline every ‘x’ hours etc

Cloudwatch Event + Lambda CRONs are very reliable too, AWS says that there could be a deviation in seconds from the point of triggering and execution by lambda, at Diagnal, we use hundreds of Cloudwatch Event + Lambda CRON jobs across many projects, we are yet to see problems with Cloudwatch’s event triggering.