Show HN: Cronyo – A simple CLI to manage your cron jobs on AWS | Hacker News Reader

Show HN: Cronyo – A simple CLI to manage your cron jobs on AWS

github.com

86 pointsgingerlime13 comments

We replaced Kinesis Analytics with Kinesis Firehose + AWS Batch with Spot pricing to process analytics offline from blobs stored in S3, and it was a significant cost saving for us.

Spot pricing gives you EC2 instances at 70% to 90% discounts, and the complexity of bidding for those is handled by AWS Batch out-of-the-box.

Batch supports Lambda as a compute node, too, fwiw, and is free to use (that is, you only pay for the resources Batch runs your jobs on). If you're into ECS/K8s, AWS Fargate supports spot pricing, and scheduled or CW Events triggered invocations.

This looks awesome! I've built almost exactly these lambdas at work but without even thinking about a nice CLI, really like it. I'm a bit confused about how many lambdas end up deployed - do you deploy a new one per unique or multiplex crons onto eg your `http_post` one?

One thing I've been wanting to do for ours is to support KMS enrypted headers which it would decrypt before sending, so we don't have plaintext API keys etc. stored in the repo. Have you thought about anything like that yet?

Have you thought about storing your secrets in SSM or Secrets Manager, giving you lambda role(s) permissions to decrypt and using the appropriate APIs to call them? I use SecretString in SSM for a lot of things and it works quite well. There's a QPS limit but you can pay for a higher level of service now and move the bar up.

Thanks for the pointer, I'll look into those services as well. :)

Watch out for the charges. Accessing secrets through API costs money

Also watch out for throttling of GET requests/get-parameters API calls. I've found Parameter Store with SecureString sufficient enough but the throttling can kill the Lambda if it gets invoked frequently.

For things like this you can abuse organization accounts. They take a few seconds to bootstrap and now you have a completely independent resource limit for that specific service.

I’m afk so will keep it brief :)

The signing keys are stored in your config file and then uploaded with the lambdas. I think it’s reasonably secure if you trust AWS and the key is never transmitted.

Not too sure I understand the question about the lambdas. There are two at the moment (post and get) and they can be used by any cron job. You can also use your own lambdas and you don’t need to deploy the built in ones if you don’t want.

The signing keys thing you did (with HMAC) is nice, but not quite what I'm talking about - I'm thinking about secrets in headers/cookies for the requests you're making. An issue I have with my current approach that I think this would also have is if you didn't want them to be in plaintext.

On the lambdas, I think from your blog post I understand what you're doing - you call the Lambda with an event which describes the task from Cloudwatch events. I didn't actually realise you could pass input from those events so that's what I was missing - because if you add an event as a trigger to a Lambda from the Lambda UI you can't give it a custom event as far as I can tell. I really like your approach, it's much cleaner.

Currently I have a lambda per cron, and each has a list of tasks to run on that schedule defined in a file deployed as part of it. Having an event per cron/lambda/task combination as you do is much more flexible and much more understandable.

Thank you. I'm glad to hear. Perhaps best to discuss via a github issue if you have further questions or suggestions?

I'm not entirely sure the concern over plaintext, if the request is over https and it's signed, but happy to explore options :)

This is fantastic!

In production, I use a cron SaaS but for personal projects, this is perfect because the one I use for free requires me to login every month and re-up my free plan (which is 100% fine and I'm happy to do it).

Thanks so much for creating this and helping guys like me with their pet projects!

Looks great! Starred for later.

Clean readme as well.

i like the extensive readme and blog post. Thank you!

Reply on news.ycombinator.com