You would need a VMX (note there is a lower cost VMX-s "small") in each Azure DC where you wanted to terminate AutoVPN connections to use Azure transit.
HOWEVER, you still have the issue where the /24 will be preferred by AutoVPN.
I'm thinking to solve this you will need to expand the subnet used by each of those branches. An example would be a /23. Just don't use the second half of the /23.
Going back to your original approach, you could then use the non-Meraki VPN configured for the original /24. The /24 over the non-Meraki VPN should then take precedence over the /23 advertised over AutoVPN.
But lets say I modified the Azure part, if I then had the same /24 network to the Azure (3rd party) IPsec as is advertised by the AutoVPN end, then there would be two /24 with the same subnet, but here im guessing that the AutoVPN route would have a better metric then the Azure (3rd party) one ?
So it basically would not work, unless I put a vMX in Azure ?
But lets say I put 3 in vMX, one in each Azure DC, could they then have the static route between each other ?
Im guessing that would be possible right. - So if each Azure vMX is the Hub, and I have meraki support filter out routes from AutoVPN ?
I just realized that what we need are a kind of AutoVPN group configuration. - So only hubs and stubs in a Group will exchange information. And they will not exchange information with hubs and stubs in another group. - Make it so 🙂