The nice thing about using SQS as an event source is that the event source is decoupled from the Lambda function. If there was some sort of issue on the Lambda side then the work items remain in the queue to be processed once things "return to normal" If you're invoking Lambda directly then that retry logic has to be baked in on your side.
What sort of tings could go wrong? A bug in your Lambda function. Some problem in the Lambda service. Some change that leads to the processing time taking far longer. Any of those things and more.
Plus, if you do get to the point where there are more events coming in you're already set up to handle it.
So not overkill, no.
You could always use eventbridge if you want decoupling - create a rule the will trigger your lambda from eventbridge and then send events to eventbridge instead of to SQS. The advantage is that in the future if you do need an SQS queue you can change your target to point to the queue instead of the lambda..
I would add a dead letter queue to your lambda if you don't already.
Step Functions SQS Queue in different regionasked 3 months ago
Polling using LambdaAccepted Answerasked a year ago
What IAM Permissions do I need to consume an SQS que from Lambda?asked a day ago
Invoke Lambda functions from S3 uploads at high scaleAccepted Answerasked 3 years ago
[Absolute beginner] - [Lambda Functions] - How large should a Function be?Accepted Answerasked 2 months ago
At what point is an AWS SQS queue overkill as a Lambda function's source?asked 9 months ago
sqs event triggers lambda directly, is there a way to delay that execution by 10-20 seconds?Accepted Answerasked 2 years ago
What if a Lambda function fails to process an SQS message within the visibility timeout of the queue?asked 2 months ago
Does SQS can invoke Lambda functions asynchronously ?asked 3 years ago
lambda take few seconds to return responseasked 8 months ago