An easy conclusion to draw, but not supported by fact.

The fact is that none of the large players dictate how the resources in their clouds are to be created and managed.

There are a number of options, including:

1. Creating them manually using a web-based console application to create and manage resources like databases, virtual servers, load balancers, etc,

2. Scripting them using proprietary scripting languages provided by the cloud provider like Amazon's AWS Cloud Development Kit (CDK), or

3. Scripting them using cloud-agnostic, third-party languages like Hashicorp's Terraform, which can generate AWS, Azure, Google Cloud, and other resource scripts.

Many (most) companies decide early on that the risks of "lock-in" are negligible and that they will intentionally utilize not only proprietary scripting languages but (worse) proprietary services that are not available from other cloud providers in a way that would make switching easy.

Then the monthly bills start coming. And growing. And instead of taking responsibility for their own short-sighted, rush-to-initial-profitability decisions, they can't just snap their fingers and switch providers.

This has exactly zero to do with the big providers' size or intentions. This is, as usual, organizations making decisions with serious long-term implications too quickly and not investing in a long-term strategy for moving data and workloads in whole or in part if/when business considerations make that necessary.

Unfortunately, regulatory agencies are generally staffed with people who find email confusing and challenging, let alone the intricacies of modern cloud-native architectures, and public opinion is pre-biased against large organizations, despite the fact that they've grown large primarily by being first (pioneers and risk-takers) and by doubling down with sound strategies and investments.

The playing field is and has been incredibly level. Convincing organizations not to put their high-level playing pieces in harm's way because doing so seems expedient is actually the problem.