Hi,

For your scenario, I would recommend going with a gateway cluster instead of a single gateway server. With 30 production semantic models and scheduled refreshes every couple of hours, a single gateway becomes a potential single point of failure.

A 2-node gateway cluster is usually a good starting point. The main benefit is high availability — if one gateway node is unavailable, Power BI can use the other node in the cluster for refresh operations.

Since you are currently using Import mode, I would focus more on reliability and refresh stability rather than adding too many gateway servers upfront. Keep the gateway machines dedicated, monitor refresh failures and resource usage, and scale only if you see bottlenecks.

If you later move to DirectQuery with Snowflake, I would revisit the design because the gateway will then become part of the live query path and concurrency/performance considerations will be different.

For the current architecture, I would start with a 2-node cluster and grow from there based on actual workload.

The gateway can run as a cluster only when all nodes share the same recovery key, and each node has to be on a supported version and able to reach Snowflake through the allowed network path.
Recovery key is what keeps the cluster consistent, so keeping it stored safely and using it when adding nodes is what keeps production stable. Safe operation is checking refresh logs, checking each node’s network path to Snowflake, and keeping the gateway updated.

manoj_0911 The two-node starting point you've been given is sound and I'd build the same thing. One correction on your question 3 though, because it changes what you get for the second VM.

A gateway cluster does not spread work across its members by default. Microsoft's page on gateway high availability and load balancing is unambiguous on this one: "All requests are routed to the primary instance of a gateway cluster. If the primary gateway instance isn't online, the request is routed to another gateway instance in the cluster." Out of the box a cluster is failover, full stop. Distributing requests is a separate setting and "Distribute requests across all active gateways in this cluster" that you turn on under Manage connections and gateways, and until you do, node two is an expensive standby.

That matters for you specifically rather than in general. Thirty models refreshing every two hours is a real concurrency profile, and if you stand the cluster up and assume it's balancing, you'll be pushing all of it through one machine while looking at a monitoring graph on the other one that stays flat and reading that as headroom. Turn the setting on deliberately and verify it, don't assume the cluster did it for you. In fairness to the docs, that page is a bit muddled about which algorithm applies when it describes the disabled state as round-robin in one sentence while stating plainly elsewhere that everything goes to the primary. The setting is the part I'd trust and act on; the algorithm underneath it is not worth planning around.

Second thing, and it comes straight out of your own constraint rather than from general advice. The only reason you're running a gateway at all is the Snowflake network policy. That policy allows egress IPs, and a cluster has one per node. Add the second node without adding its IP and you get failures that look random and intermittent, because they aren't random at all, they're every request that happened to land on the node Snowflake doesn't know about. Worth putting both IPs in the policy before the second node ever takes traffic, and worth writing down somewhere that adding a node means editing the policy, because it's exactly the kind of step that gets skipped at 2am eighteen months from now.

Third, on limits, since you asked about monitoring. Concurrency throttling on the gateway is enabled by default, while the CPU and memory thresholds both default to 0, which means disabled. So the first ceiling you meet in production is the concurrency one, not the sizing one, and it announces itself with its own message rather than as a generic refresh failure and the wording is "the gateway you selected can't establish data source connections because it's exceeded the concurrency limit set by your gateway admin". Knowing that string in advance saves you a couple of hours of blaming Snowflake the first time it appears.

Last one is free and isn't about hardware at all: with thirty models on a two-hour cycle, check they aren't all scheduled on the hour. Staggering them across the window costs nothing and does more for refresh reliability than the second node will.

Are both node IPs going into the Snowflake network policy, or is the plan to add the second one later?

Hi manoj_0911,

Thank you for reaching out to Microsoft Fabric Community.

Thank you ShahRukhSameer, ShivekMaharaj, Kagiyama_yutaka and PauReis for the prompt response.

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user's for the issue worked?  or let us know if you need any further assistance.

Thanks and regards,

Anjan Kumar Chippa