Basically not a concern worth trying to mitigate up front.
The amount of engineering effort that gets wasted trying to avoid cloud vendor lock-in far outweighs any benefits.
In my experience, teams who go out of their way to avoid using cloud vendor tools for fear of lock-in end up needing more engineers and more time to accomplish the same task. Are you really gaining any benefits by avoiding vendor lock-in if you have to invest another $200-400K per year or more in hiring additional engineers to get the job done? The answer is almost always no.
I always advise teams to use whatever cloud vendor tools are available to accelerate their timelines and lighten the engineering load. If you arrive at an unlikely situation that requires vendor change, you can always invest the extra engineering effort after that decision is made. Don’t invest the effort for a hypothetical vendor change that will likely never happen.
I'm not making those decisions for a large company or with proprietary data, so it's not a big deal for me. However, I would think this could become a bigger concern if AWS starts doing more takedowns that I would consider ESG or mob demanded (https://www.vice.com/en/article/xgx5bw/amazon-aws-shuts-down...).
If by ESG you mean Environmental, Social and Corporate Governance, I don't recall Amazon ever justifying a takedown explicitly in those terms. I'm also not aware of any occasion of Amazon taking down a site that was clearly motivated by mob demands. Could you be a bit clearer about what you are talking about? (I have not clicked on the link you provided).
Not big, because I ensure that I don't use any platform-unique services and I document my configuration.
I'm using Dropbox and I'm evaluating Hetzner, neither of which has specialist services that are interesting for me; I'm also evaluating the new Julia compute platform and the GCP as providers that do have unique service offerings I might become interested in.
I generally prefer to administer FreeBSD boxes to Linux, fwiw.
I just find it nicer to admin: things work the way I expect them. Two things in particular: I can configure FreeBSD jails easily and be confident in the security model, where Linux containers are just way too complicated if you want to run untrusted code. Second, systemd logging really rubs me up the wrong way, especially if something goes wrong when setting up a box.
There's only one thing FreeBSD can do that Linux can't, which is Capsicum that I don't use, but for basic sysadmin I just find it nicer. The only Linux technology I really miss in FreeBSD land is KVM.
On top of my head the bigger deals are how reliable our backup and recovery processes are, how well-documented and well-tested those are, how we manage operating costs, how we avoid vendor-specific features (which makes migrating easy).
The amount of engineering effort that gets wasted trying to avoid cloud vendor lock-in far outweighs any benefits.
In my experience, teams who go out of their way to avoid using cloud vendor tools for fear of lock-in end up needing more engineers and more time to accomplish the same task. Are you really gaining any benefits by avoiding vendor lock-in if you have to invest another $200-400K per year or more in hiring additional engineers to get the job done? The answer is almost always no.
I always advise teams to use whatever cloud vendor tools are available to accelerate their timelines and lighten the engineering load. If you arrive at an unlikely situation that requires vendor change, you can always invest the extra engineering effort after that decision is made. Don’t invest the effort for a hypothetical vendor change that will likely never happen.