Thanks for your quick response. Understood, provided I need anyconnect VPN, I must deploy vMX with no Av Zone.
Still a couple of doubts related to vMX redundancy in Azure:
In case you must deploy vMX in two different AZ Regions, then I think you can't solve the HA using Azure Functions.
I think best approach is deploying two standalone vMX hubs, each inside one of the peered Regions. Ok, you have to pay for two meraki licenses. However, you do not have to worry about complex HA scenarios or adding the route server (still do not know how vMX can run BGP against it as I read it required BGPoIPSec)
vMX in Region 1 would publish vnets in Region1 and vMX in region2 would inject vnets in Region 2. Inside Azure, UDRs for subnets in Region 1 would route the on-prem prefixes towards vMX in Region 1. UDRs for subnets in Region 2, towards vMX in Region 2. All of this is a simplification, because in real world there is a FW applicance between server vnets and the vMX. So UDRs would point to the FW and FW to the vMX. It should work.
In this scenario I am aware subnet UDR for the vMX would require specific routes towards the customer server vnets towards the FW appliance. So AutoVPN decapsulated traffic will be sent to the FW from the vMX. However, I have to study how the vMX will send outgoing traffic to the FW.
When you deploy a vMX, Azure provides you with a basic ENI so you automatically get Azure internet access and vMX registers with Meraki cloud. So once registered, I will need to modify it to make control and also AutoVPN and Annyconnect traffic to be sent to the FW (as we do for on-prem Hubs). Azure assigns you a dynamic IP in your vnet and sets Azure vnet-reserved DGw .1 as vMX DGw. I suppose changing vMX subnet UDR to route 0.0.0.0 towards the FW IP would work: Traffic towards vnets would pass the FW, traffic towards internet would also be sent to the FW. And I guess Azure would still apply source nat to internet traffic sourced by the vMX vnet IP. Is my assumption right?