I did look at Kinesis too, but for my use case, it didn't really help much over SQS. There is still no way to put a Kinesis event "in the future" so that I won't see it for a second, and I would have had to set the batch size to 1, if I was using Kinesis as a means to throttle an activity.
In the spirit of treating this like Lego, I suppose that maybe I could have uses SES to email itself an HTTP request description, and counted on the email lag to keep requests spread out over time. But at this point, things are getting so weird that I think it's time to just admit that "work on something at a specific pace, then go to sleep for a few hours" isn't the sort of task that the serverless architecture is well suited for. Serverless is for tasks that you want done on demand, as quickly as possible, imo.
In the spirit of treating this like Lego, I suppose that maybe I could have uses SES to email itself an HTTP request description, and counted on the email lag to keep requests spread out over time. But at this point, things are getting so weird that I think it's time to just admit that "work on something at a specific pace, then go to sleep for a few hours" isn't the sort of task that the serverless architecture is well suited for. Serverless is for tasks that you want done on demand, as quickly as possible, imo.