We have a bunch of work that requires large, process heavy, calculations, so yes, vendor lock-in is a concern for us as it can mean either huge cost increases, if the vendor changes pricing for the required instances upwards, or huge savings if a competitor can do the same computations for less. We solve this problem by making sure we can trash servers and spin them up elsewhere if needs be (mostly via terraform etc).

I don't think this should apply to anyone running some hosts for web applications though.

Just out of interest, when have AWS increased their prices?

Never.

It's a overblown concern for many, considering that the major clouds are massive companies that will likely be around far longer than most of their customers (or will acquire them). Every new client actually contributes to the longevity of a cloud provider. There's also lots of competition to offer similar features and many services can be mixed/matched easily (eg: we run on GCP but use Azure event hubs).

My main concern with vendor lock-in in hosting (not just cloud), is that it'll easily turn business problems into ops problems. Credit card suspended because of (possibly spurious) "suspicious activity"? Cloud account suspended for non-payment. Trouble with hosting company x invoicing? Same result. Spurious DMCA takedown filed? Maybe a TOS violation - account suspended. Etc...

It's not so much that most of these would be permanent - but it does add risk of downtime from the "not ops domain" to the ops domain.

And multiple providers isn't a universal fix - but it might mitigate some risk.

I think that vendor lock-in on a cloud is more about reliance on technologies designed for a specific cloud. AppEngine, DynamoDB, or Cloud Formation being examples. To avoid lock in, use technologies like Kubernetes, MongoDB, or Terraform instead. That way jumping clouds is at least possibly without a rewrite.

It is important for those not on the cloud: dedicated servers and colo.

You should pluralize that 'colo' then.

I've been through datacenter power outages, refusal to renew, and difficulty in getting circuits in a timely manner in multiple Tier 4 datacenters.

Self-hosting is only as good as your planning, strategy, and execution, which is much the same as the cloud world. You're probably safer running a single EC2 instance than running a single dedicated server in some random colo, but certainly running your own geographically distributed infrastructure is likely better than relying on a single AWS availability zone (for example).

However, it's a great idea to open up peoples' eyes to the idea of how being on a major cloudy provider can make you collateral damage of an attack that never would have targeted you if you were in DIY mode.