Basically not a concern worth trying to mitigate up front.<p>The amount of engineering effort that gets wasted trying to avoid cloud vendor lock-in far outweighs any benefits.<p>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.<p>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 (<a href="https://www.vice.com/en/article/xgx5bw/amazon-aws-shuts-down-nso-group-infrastructure" rel="nofollow">https://www.vice.com/en/article/xgx5bw/amazon-aws-shuts-down...</a>).
Not big, because I ensure that I don't use any platform-unique services and I document my configuration.<p>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.<p>I generally prefer to administer FreeBSD boxes to Linux, fwiw.
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).