One thing I haven't seen mentioned yet: The infrastructure setup. If you're only running a VM or a container this won't be a problem, but if you have any setup

One thing I haven't seen mentioned yet: The infrastructure setup. If you're only running a VM or a container this won't be a problem, but if you have any setup that creates stacks on demand, needs dynamic DNS entries, does service discovery or similar - which you will most likely have in any medium to large setup -, you'll discover that switching cloud providers will involve a lot of friction in your application. This will be especially fun if some steps are synchronous (i.e. single API call) with cloud provider A, but callback-based with cloud provider B. Terraform can help a bit, but a lot of examples I've seen are very AWS-dependent and it won't be as simple as changing the API key to deploy it somewhere else (however, you'll still have somewhat of a documented infrastructure, so there's that). OpenShift and Kubernetes help a lot, but you'll be paying extra for using the non-native abstractions of your specific cloud and, at least in my experience, some quirks will still end up in your app - most likely somewhere in inbound routing and monitoring. That being said, vendor lock-in is a big topic, but depending on your situation, your really need to look at how much risk you are mitigating for your effort. None of the big clouds is likely to shut down unexpectedly (not even GCP) and no matter how much you prepare, moving a large infrastructure from cloud A to cloud B is always going to be both expensive and time-consuming; you will not do this for a minor reduction in the bill. If you really want to avoid lock-in, the actual way is to go multi-cloud, but this will be a lot of extra effort and I'd wager the expense is not worth it for most companies (except for backups).