Preventing this from happening requires a clued-in CTO and equivalent senior level leadership who can defend against such 'attack' methods and knows the difference between, for instance, paying a monthly recurring cost to host a Linux/KVM virtual machine and paying for some totally 'cloud' SaAs.

Further, it needs people in decision making roles who understand and value the strategic differences between having an infrastructure concept that is trapped in one provider's proprietary software tooling ecosystem (aws, azure, etc), vs things built on open standards that are portable.

> Preventing this from happening requires a clued-in CTO and equivalent senior level leadership

Most CTOs (and increasingly M2s and M3s) I've met are what I call "box architects". You know the ones who love drawing boxes, moving one box inside another box, drawing a line between 2 boxes or changing a unidirectional arrow into a bidirectional one, then declaring the hard part is done and now we need any random engineer to implement that or "Is there an AWS service that does that? I just don't see the value in us doing it in house".

A "super optimized tools" is just a box that you swap for another box and the "minor changes" will be just a couple of arrows than need to change or another box to swap for another box. You get them to feel good about doing architect stuff plus the 10x reduction in the bill. They can always replace that box with another box later after all.

> Preventing this from happening requires a clued-in CTO and equivalent senior level leadership who can defend against such 'attack' methods and knows the difference between, for instance, paying a monthly recurring cost to host a Linux/KVM virtual machine and paying for some totally 'cloud' SaAs.

And the reality is eventually you'll get a clueless one, and everything will revert to the mean.

And the mean is heavily influenced by marketing propaganda.