> I am pretty sure the AWS business model is to get you to write your own code that interacts with the API so that when you think about switching to another provider, you realize that you're throwing away months of work and decide not to.
Same applies to all other cloud providers.
Typically, you solve this problem partially with tools like Terraform, etc. However, of course there is never a one-size-fits-all solution for such things. Vendor lock-in is an issue that many companies try to solve by adopting standard solutions, but that's it. Kubernetes for example is one of these solutions.
While Terraform the tool can be used across cloud providers, Terraform configurations cannot.
Each terraform file uses modules that are quite specific to the individual services provided by a given cloud. These cannot be simply swapped out without rewriting the config.
In general, that's something that should be known in advance when someone chooses a cloud provider. As I mentioned, there is no one-site-fits-all solution. :/ Vendor lock-in is a serious issue for some enterprise companies, and in such cases you could propose something like a hybrid cloud. It's an expensive effort that could save your butt in the future.
No, the same does not apply to all other cloud providers. Earlier this year, I had a moment where I wrote a Kubernetes definition for one public cloud provider, and then was able to reuse the definition on three other public clouds. Portability via Kubernetes and CNCF is real, AWS is lock-in.
Also, do you really want to support Amazon's human-rights-abuse parade?
Same applies to all other cloud providers.
Typically, you solve this problem partially with tools like Terraform, etc. However, of course there is never a one-size-fits-all solution for such things. Vendor lock-in is an issue that many companies try to solve by adopting standard solutions, but that's it. Kubernetes for example is one of these solutions.