◇ Could this help me?
Yes for consolidation and infrastructure as code, with a large caveat on the method. The core argument is legitimate and often ignored: more vendors means more bills, more outages that are not yours to fix, and more places secrets can leak, and defining infrastructure in a file instead of by clicking is better for reasons that have nothing to do with AI, since it is reviewable, repeatable, and recoverable. The claims to push back on are that any working engineer would agree, which is not true because managed vendors exist precisely to absorb operational burden that a single-cloud setup hands back to you, and the implication that an agent writes the file and you are done. General practice, and the part to insist on is reviewing exactly what gets provisioned, especially network exposure and permissions, before anything is applied.
I want to understand the real trade-off before consolidating my stack onto one cloud provider. Take the services I currently use, described below, and map each one to its equivalent on a single provider. For each, be specific about what I would gain and what operational work I would be taking on myself that the current vendor handles for me. Then, if consolidation still makes sense, write the infrastructure as code, but before anything is applied, walk me through exactly what it provisions: every resource, its cost, what is reachable from the public internet, and every permission it grants. Flag anything more permissive than it needs to be, and let me apply it to a throwaway environment first.