That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2.

On top of that, many of AWS's services use standard API's. It's not hard to move away from RDS or Elasticache, you're just using SQL/Redis anyways...

If we're talking about something like SQS, ok, well you can just as easily say you're "locked in" when you use RabbitMQ because there is work involved to not be using RabbitMQ.

There are a finite set of this to trigger the function and they become central to

API Gateway, kinsesis, s3 change/addition...

It definitely has more lock in potential than more "vanilla" offerings like EC2, RDS, S3.

You could name a replacement/competitor service for each of the above, but if the Lambda is triggered by S3 changes then that's a big barrier to putting your static files elsewhere

> That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2.

The major difference is that Lambda hooks into your developer tooling, and source code, in a way that EC2 doesn't.

Sure, you can use Lambda without calling AWS APIs from your app... But you'll be using SDKs, tools and documentation that push you to do so, every day. It will require conscious thought and effort in your development to avoid lock-in, and over time the required effort will increase, because more and more third-party tools and libraries will switch to proprietary dependencies, dragging you along with them.

To me, that's the opposite of lock-in. You can leave AWS because you can move away from any one service easily without affecting the others. There are even vendors who directly implement (for example) S3's API so you have almost no code to change.

Traditional vendor lock-in is when you can't move away from (e.g.) your Oracle database because you've got a dozen different applications that will need simultaneous rearchitecting if you ever want to get away from it.