... with automatically managed updates, backups, monitoring, auto-scaling, auto-replication ...
The managed services are a huge part of the lock-in with AWS services, because even though they generally cost more than the competitors, they can often come out equal after accounting for those aggregate hours lost to doing those things.
Lock-in refers to the effect of being unable to change vendors due to switching costs. This can be things like a large amount of effort/money required that a company just cant afford or sometimes the lack of any other vendor who can even offer the same product or service.
In this case, there is basically 0 switching cost since relational databases are everywhere and you can always take your data/schema with you. This new migration service actually makes it even easier than before.
It's not lock-in if you don't want to leave – that's just being competitive. Real lock-in would be something like removing an export function or introducing a proprietary storage backend with incompatible semantics so anyone leaving would need to rewrite application logic.
If you want to talk lock-in, look at services like Lambda where there isn't a direct counterpart (although the model there is so simple that most users could port relatively quickly).
When the vendor lets you export your data in a form that you can easily import into your own copy of the exact same software, I fail to see how that is "lock-in". If the vendor increase the cost of the service or changes other terms in a way that's unfavorable to you, you can easily leave, that's the opposite of lock-in.
You can't really accuse a vendor of lock in just because his product is priced lower than it would cost you to do it yourself.
I think that's a very rigid definition of "lock-in" that implies it must be done with some anti-competitive malice. That's not how I've encountered the term in my past, so I'm welcome to other interpretations.
Per (not authoritative, obviously) wiki:
"In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs."
I agree with this. It shouldn't require that the service is purposefully preventing you from changing; lock-in can occur because a service offers advantages that prevent changing by virtue of some other cost.
"lock-in" implies some sort of lock. "I don't won't to leave because the service saves me so much money" is not a lock, you can leave, you just choose not to because it's better for you to stay. And if the vendor increases his price you can just take your data and go - your same application will run on another vendor's hosted MySQL instance.
If I say I'll pay you $1 if you sit in my office for an hour, you can't say that you were "locked in" by me, if Mary offers you $2 to sit in her office, you can walk over to her office and get more money.
That definition makes it very clear why people are disagreeing with you. Switching costs are those incurred by the difficulty of switching, and not the marginal cost of one provider or another. If internet provider A is $80 / month, and provider B is $60 / month, the switching cost has nothing to do with the $20 monthly discrepancy, or any speed differences, and rather represents how easy it is to cancel my subscription by being on hold for hours or cancellation fees.
Is it really "lock-in" if you use it because it's cheaper and better for you and migrating somewhere else is as simple as a database export?
I can see something like DynamoDB being vendor lock-in since you can't just download your data into your own self-hosted DynamoDB instance, but if you're using a standard off-the-shelf RDS database (MySql, PostgreSQL, Sql/Server, etc), I don't think you can call it lock in when you're staying only because it's easier than running it yourself.
