I think that the AWS vendor lock-in won't come from single features such as databases from specific vendors, but rather the ecosystem of Route53, elastic load balancers, S3, EBS, AMIs, Glacier, RDS, CloudFormation templates, SQS, security groups, libraries like boto, auto scaling groups, and everything else besides instance provisioning. Of course you can implement most of these yourself, e.g., HAProxy for ELBs, rabbitmq for SQS, but all that requires application code changes and significantly more configuration management.
So far I've been able to avoid vendor lock-in on the code level (besides S3, but the S3 API is simple and has become pretty much a standard for object storage).
On the infrastructure level, the "lock-in" part is not so much the technology, all of that is relatively easy to replace. But it would take me two additional FTE's to configure and manage everything AWS offers as a service ourselves.
But that applies to a lot of things these days, AWS just happens to be a one stop shop for a growing range of commodity services.
> but all that requires application code changes and significantly more configuration management.
And not to talk about making them highly available, scalable, having to continuously monitor and so on takes time, effort and involves significant opportunity costs.
Imagine business folks telling engineers about an upcoming promotion campaign that bring in 3X more load. Outside of AWS (or cloud provided service) one has to sit and plan for scaling up all the individual components (rabbitmq, haproxy etc.,) which really becomes pain after a few iterations.
