From the perspective of an outside, boots on the ground Developer/architect, I’ve never worried about “vendor lock in”, I believe you should choose your infrastructure wisely and go all in. But, I do worry about “Lambda lock-in” for APIs. I like the optionality of being able to deploy my APIs anywhere just by changing the CI/CD pipeline.
That’s why I recommend using proxy integration. Every language supported by Lambda has a method to just throw your standard API in lambda without tying yourself to it.
Here is an example for Node/Express
https://github.com/awslabs/aws-serverless-express
Python/Flask (ignore the DDB part):
https://www.serverless.com/blog/flask-python-rest-api-server...
C#/Web API
https://aws.amazon.com/blogs/developer/deploy-an-existing-as...
I totally agree on Lambda first. The only reason we did not do that is because when we started this product I was not well versed with Lambda and serverless and preferred to work with something that I dealt with previously.
If I could go back in time, I would set up all our applications on serverless.