How should I configure a resilient Azure site-to-site VPN with dual Meraki WAN connections?

You’re generally on the right track, but a fully redundant design would normally use four tunnels: two from the primary Meraki WAN to the two Azure active-active gateway instances, plus two more from the secondary WAN to those same gateway instances. BGP can then control which paths are preferred. Use local preference on the on-premises side to prefer WAN1 for outbound traffic, and advertise the routes over the WAN2 tunnels with an additional AS-path prepend so Azure prefers the WAN1 paths for return traffic. This assumes the Azure gateway is configured to use AS-path length when selecting routes. The main challenge is understanding BGP behavior and then applying it consistently on both sides. Azure Virtual WAN can simplify much of this routing and failover design, although it adds cost compared with a standard virtual network gateway.

Before finalizing the design, clarify the Azure topology: whether everything is in one region, whether multiple VNets need to be connected, and whether an Azure Firewall or another central appliance is involved. For production environments, Virtual WAN is often easier to operate because it abstracts much of the routing and connectivity management, and it can better support this kind of resilient multi-site design. The tradeoff is that Virtual WAN is a paid service, whereas a conventional VNet and VPN gateway may be less expensive but require more manual BGP and failover configuration.

Another possible architecture is to deploy a virtual network appliance in Azure and terminate the tunnels there instead of relying entirely on the Azure VPN gateway. That can work, but it introduces another appliance to design, license, monitor, and maintain, so it is worth comparing the operational overhead against Virtual WAN or the native active-active VPN gateway design.