One downside I see to this is the cost of the host for what will likely be a idling machine for a long time. Ultimately these services end up pinging some API or kickstarting a workflow, and the host itself isn't always super busy.
Looking at other services provided by AWS, Lambda[1] seems like you could easily schedule tasks out of the box, and not pay for the host/capacity unless your script is running. If all you are doing is pinging other services, it won't even be running that long.
AWS Lambda functions can be triggered by external event timers, so functions can be run during regularly scheduled maintenance times or non-peak hours. For example, you can trigger an AWS Lambda function to perform nightly archive cleanups during non-busy hours.
That's a valid point and a good solution, you could easily replace the ECS with AWS Lambda for running your task without having idle machines, but the scheduler is still necessary. If you have more complex tasks or are using languages not supported by Lambda, ECS can still be a very cheap way around (you can use a t2.micro instance and share it across all of your jobs)
Agree, we have been using Dagobah (https://github.com/thieman/dagobah) for a simple cron on top of AWS. Lets you create DAG, email alerts and logs. (Disclaimer: I am a contributor to dagobah).
5 comments
[ 591 ms ] story [ 768 ms ] threadLooking at other services provided by AWS, Lambda[1] seems like you could easily schedule tasks out of the box, and not pay for the host/capacity unless your script is running. If all you are doing is pinging other services, it won't even be running that long.
[1] http://aws.amazon.com/lambda/
"Scheduled Tasks"
AWS Lambda functions can be triggered by external event timers, so functions can be run during regularly scheduled maintenance times or non-peak hours. For example, you can trigger an AWS Lambda function to perform nightly archive cleanups during non-busy hours.