Great work arounds to run lambda on exact time yet there are some limits to keep in mind:

- DynamoDB will take up to 2 days to remove item by TTL, so accuracy is not within minutes or hours, but 2 days. You may ask to delete item at 9am today, it will e.g. after 2 days at 8am.

- Cronjob approach - the account limit is 100 rules per account. Possible to ask for increase but seem like it won't be great approach for anything at higher requirements. Surrounding CloudWatch APIs also have quite low limits.

- State machines for lambda - 2 types. one will allow up to 1 year of delay, another just 5 minutes.

I would say it's pretty great to just have some database table, e.g. dynamo db which holds in sort key timestamp when it should be triggered and just run lambda as cronjob with single CloudWatch rule. There is 1M invocations per account per month for free, so probably you won't pay anything for this, or if will pay, then it will be within 1 cent anyways. Dynamo has enough free capacity for something like this also. For Primary key if you have nothing, just add any string like "delayed-event" for SK timestamp. Use SK = delayed-event SK less then current timestamp. Run lambda once per minute or once per 15 minutes or whatever accuracy want to have and it will be resolved for any scale at very cheap or for free. Of course having PK as static string is not the best design for dynamo, but in this case it will work fine unless you have a lot lot lot of rows. If so, just create several PKs like delayed-event-group-1 delayed-event-group-2 and run crons per group, have up to some amount of rows, like 5M, it should work pretty fine until your PK collection is under 10Gb in size, so if you make PK attribute and SK attribute just single letters and save timestamp as attribute = t and value timestamp, it will be approx 15 bytes per row, in 10Gb you can push 600M rows. Not that bad. And 10Gb limit is hard for LSI only, for normal index there is no such limit, just your queries will become slow at this scale with single PK. Which can be resolved by launching new lambda for each 10M or 100M, just test if needed that scale, tl;dr; this approach can be very cost effective & have practically infinity scale.