The pricing structure is reasonable for now, but we are uneasy about becoming dependent and locked into lambda, should the pricing change dramatically in the future (this is Amazon, after all).
Is this a valid concern? And, if so, how can it be mitigated?
That said, the cost of the data itself is going to likely drive where you go. Porting functions to another provider is likely to be a challenge; each implementation has special unicorn warts to it.
If the concern includes leaving aws in general, data is a bigger issue. It's incredibly expensive to move data out of AWS, both in time(you probably have to make something distributed) and money. Also, if you choose one of the really native datastores like dynamodb, that could require a lot of code rewrite. But actually leaving, especially for price, is not something Ive heard many people do - often engineering time is worth so much more than servers its gotta be significant to make sense.
The other thing is with a large amount of data you hit weird performance issues. Say you want to copy all your files on s3. One typical way of doing this is s3distcp in emr/hadoop, so you get distributed copying. But generally listing is single threaded, and if you have billions of files your cluster spends a noticeable amount of time idle while the master is doing the listing operation. Also list api costs can add up. S3 inventory probably alleviates this, it didnt exist at the time.
So ignoring 'BigData', how would you shift a mysql database out. its either take downtime or do streaming replication or something. Gotta keep consistency, not lose writes, etc.
moving stateless code around is so much easier than dealing with data. theres basically zero straight monetary cost to the move, you just deploy it somewhere else.
1. Cost saving because of zero cost for small usage each month
2. Ha if one provider is down reroute to the other
3. Reduces lock-in
Perhaps they will all eventually offer other languages as well, but at least it used to be node.js 6.x that was common on all three.