I understand that when a Lambda times-out, it returns an error.
Once the Lambda times-out, though, I'd like to know if it's immediately killed by AWS, or if it can potentially continue running for an arbitrary amount of time in the background (detached from the original request, so to speak).
I ask because it's important in my situation that when a Lambda times out, all processing inside that Lambda also stops immediately. If AWS does not guarantee this, then I will need to implement my own measures to ensure this for myself, i.e. by periodically checking against the clock and manually halting execution beyond the timeout.
(p.s. if Lambdas are killed immediately on timeout, I'd like to know how AWS achieves keeping the Lambda in a warm, initialised state for subsequent invocations. I.e. it cannot simply be that it kills the process on timeout, otherwise the Lambda would be cold for next time...)
From what you've posted I think you will need some sort of orchestration than relying on the behavior characteristics of the AWS service. Rather develop using the matching service to meet your requirements.
This may mean instead of calling vanilla Lambda, you use a StepFunction to handle the Lambda timeout, clean-up on fail, and retry logic. Or maybe you need an actual lock with a TTL and you may use DynamoDB for this with a TTL attribute enabled, it will all depend on your requirements.
In general I don't think you can rely that Lambda, or any service (rather than an ACID transaction with in a database) will execute in a strongly consistent manor which you can rely on. If your requirements are not too strict, you may get away with simply delaying the invocation of the next attempt. This could be done with an SQS delay queues. FIFO can help you with preventing duplicates as well if you decide to use SQS.