Assuming that a retry or a slight time drift isn't the end of the world. Another possible method would be to cron an orchestration lambda once a minute that then turns around and creates delayed sqs messages. You can then use the sqs lambda trigger to invoke your target lambda.
Use the SQS SendMessage DelaySeconds API (it's native likely all of AWS sdk's) as an off set for the number of sub minute calls one wants to make. For example if you want to make a call every 5 seconds you would create 12 messages
delaySeconds: 00
delaySeconds: 05
delaySeconds: 10
delaySeconds: 15
- ...
With this approach one must pay special attention to sqs's lambda invoke and retry logic. If multiple tries is a problem be sure to setup a DLQ and consider using a FIFO queue. AWS, by design, may invoke the target lambda more then once. Note that standard SQS queues are: at-least-once delivery, and FIFO queues are: exactly-once processing. It's also possible to have some time drift with this approach as CloudWatch may invoke the orchestration lambda a few seconds "after" the minute.
Is this approach better then long running the orchestration lambda, or even a step function? Eh, that depends on a lot of things. Personally I find the idea of leaving a lambda running in a wait state wasteful, you have to pay for that lambda doing nothing most of the time, and if it's a large lambda those costs are not trivial. Using a step function seems like overkill and a much more complex setup then a sqs integration.
At least to me, it seems better to have it spin up, schedule a set of tasks via sqs and die. This is more complex then a long running lambda, has some concurrency issues one must contend with, but it is all "serverless" if that's where one wants to be.
With all that said, lambda isn't the best fit for everything- if this is a "forever" kind of task consider using ECS/Fargate/EC2, as there is a good chance it's cheaper and ultimately less complex.