The networking stack in Azure or AWS are so different that they require a different mindset to work, especially securely. If your networking needs are simple you are very lucky.
Often there are proprietary solution to proprietary problems you would otherwise not have in the first place.
I used AWS for a long time but I am back to hosting myself. What arcane network requirement would that entail? I don't think there are benefits even for government scale problems.
The private links in Azure are particularly specific.
After you translate the vocabulary, the process is pretty similar until you get to security items, like ACLs or packet-inspection firewalls. You're still setting up VLANs in the form of subnets, routers in the form of transit gateways, sites in the form of VPCs, inter-site connectivity through peering connections, you get the idea.
If there's one thing I've learned in my IT career, it's that most "new" ideas are just rebrands of existing concepts, and that the real expertise comes from being able to translate marketing-speak into concrete, interchangeable fundamentals. Public Cloud is, largely but not entirely, no different in this regard.
Coming from IT land, the answer is simple: you don't use them in the first place, and you grit-and-bear the replacement cost if and when the time comes. This is a negative on my research notes, slide decks, and papers when it comes to evaluating various cloud platforms for our workloads, and yet it's also the number one reason we're forced into a specific provider (some leader loves their proprietary tooling, and forces us to use it).
Look, I'm not saying these proprietary tools are bad, per se, just that they have a steeper cost than initially presented to the consumer in terms of architecture complexity and inevitable migration. The very first question you should be asking before consuming niche or proprietary products from vendors is, "Can I do this in a standard way that's more portable?" For stuff like Azure Functions, the answer is emphatically yes - but it comes at the cost of managing additional infrastructure, which is often the main reason companies want to use those tools in the first place (a misguided notion about throwing out infrastructure to save money).
As for the solved problem of compute (VMs and Containers), well, literally any cloud provider should have that ready to go. The question is whether or not your org is willing to retain the talent needed to build and support your clouds internally, or if they'd rather pay higher outsourcing costs with vendor lock-in instead.