Fortinet SD-WAN Hub Placement Part 3: Cloud, SASE, and the Death of "The DC" as the Default

Part 1 established the traditional model — hub in the DC, because that’s where the apps, the security stack, and FMG/FAZ all lived. Part 2 showed what happens once one MSSP serves many customers through ADOMs: the placement question stops having a single answer and becomes a per-customer design exercise, anchored by one constant — every hub, wherever it sits, still has to maintain a working BGP-on-loopback relationship back to the central FMG/FAZ.

This post follows that per-customer exercise into the two situations that come up most often when “where do we put the hub” stops meaning “which DC”: the customer whose applications have moved to a public cloud, and the customer who’s leaving the DC-centric WAN model behind altogether in favour of SASE. They’re related but distinct problems, and worth taking one at a time.

Cloud placement: the hub goes where the VPC is

When a meaningful share of a customer’s application estate sits in Azure, AWS, or GCP, the Part 1 logic — “put the hub where the things it serves actually are” — points the hub straight at the cloud. That’s usually the right call, but it changes several things that were settled, comfortable defaults in the DC-based model.

The hub becomes a virtual appliance, with everything that implies. A FortiGate-VM in a VNet/VPC behaves like its hardware counterpart for routing, policy, and IPsec purposes — but it inherits the cloud platform’s networking model underneath. That means thinking about things that simply didn’t exist in a DC rack:

• Throughput is licensed and metered, not a property of the chassis you bought. Sizing the VM (and its licence tier) for the overlay’s actual aggregate throughput — not the throughput of a single spoke, the sum across every spoke that hub serves — is a cost decision as much as a technical one. Get it wrong in either direction and you’re either paying for headroom nobody uses or watching CPU-bound software crypto become the bottleneck during a failover storm.
• Availability is the cloud platform’s model, not FortiGate HA’s model. Active-passive HA across availability zones, or a scale-set of active hubs behind a cloud load balancer, are both viable — but they’re cloud-native HA patterns layered on top of (or instead of) the FortiGate HA most of this blog’s enterprise material assumes. The Resilience series’ active/standby reasoning still applies at the design level; the mechanism that implements it is different.
• The “underlay” is the cloud provider’s SDN, and it has opinions. Azure VNets, AWS VPCs, and GCP VPCs all have their own routing constructs — route tables, transit gateways/hubs, peering — that sit underneath the FortiGate’s overlay and have to cooperate with it rather than fight it. A loopback /32 that BGP wants to advertise has to actually be routable through the cloud platform’s fabric to wherever it needs to go next; that’s a platform-specific exercise (UDRs in Azure, route tables and a Transit Gateway in AWS, custom routes and a Cloud Router in GCP) layered on top of the FortiOS BGP config from Resilience Part 2.

The “DC” the hub now serves might not even be one of the customer’s choosing in the long run. A cloud landing zone built three years ago for one application can quietly become the de facto hub location for an entire region’s traffic, simply because that’s where the first FortiGate-VM got deployed and nobody’s revisited the decision since. Cloud placement decisions age the same way DC placement decisions do — they just age faster, because cloud estates reshape themselves more often than buildings do.

Multi-cloud multiplies the question, it doesn’t change its shape. A customer running workloads across Azure and AWS doesn’t need two unrelated hub designs — they need the same placement logic (“where do the things this hub serves actually live, and what’s the best on-ramp to them”) applied twice, with a clear-eyed view of whether one hub can sensibly serve both clouds (via cloud-to-cloud interconnects, which adds its own latency and cost) or whether two cloud-resident hubs, peered the same way DC1/DC2 hubs were in the Resilience series, is the cleaner answer. In practice, “two hubs, one per cloud, each close to its own workloads” tends to win on the same grounds active/standby DC pairs won in that series: smaller failure domains, easier-to-reason-about traffic flow, and no temptation to run cross-cloud transit through a customer’s overlay.

And the constant from Part 2 doesn’t move. Whichever cloud the hub lands in, it still needs a clean, monitored, properly-firewalled path back to the MSSP’s (or the enterprise’s own) FMG/FAZ — FGFM on TCP/541, encrypted log forwarding, the works — riding on a BGP-on-loopback relationship that doesn’t care whether the underlay is an MPLS tail, an internet circuit, or a cloud provider’s backbone. That part of the design is genuinely placement-agnostic, which is exactly why it was worth establishing first, in Part 1, before any of this complexity got layered on top.

The SASE migration: when the destination stops being a place at all

Cloud placement is still, fundamentally, “move the hub closer to where the apps now live.” SASE migration is a different kind of change, because it removes the assumption that there’s a place to be close to.

In a DC-centric (or cloud-centric) model, the hub’s job includes being the policy enforcement point and the egress point for centrally-steered traffic — and that only makes sense if there’s a hub-adjacent location for that enforcement to happen. SASE inverts that: the security stack — SWG, CASB, ZTNA, the works — moves into the provider’s distributed cloud, reachable from anywhere, and the customer’s traffic is meant to break out near the user, not get backhauled to a hub for inspection and then sent on its way.

That has real consequences for what a hub is even for, in a SASE-converged design:

• Internet and SaaS steering increasingly bypasses the hub by design. If the SASE provider’s PoPs are doing the inspection and the breakout, traffic that used to traverse “spoke → hub → DC perimeter → internet” now wants to go “spoke → nearest SASE PoP → internet” directly. Routing that traffic to the hub anyway, just because that’s where it’s always gone, reintroduces exactly the backhaul penalty the migration was supposed to remove.
• What’s left for the hub to do shrinks to the things SASE doesn’t (yet, or ever) cover — typically site-to-site connectivity for traffic that’s genuinely internal (branch-to-branch, branch-to-residual-DC, branch-to-cloud-VPC), and anything that needs a stateful, FortiOS-specific policy treatment the SASE layer doesn’t provide. The hub doesn’t disappear; its job gets smaller and more specific.
• Migrations are gradual, and “gradual” means hybrid for a long time. Almost nobody flips a switch from DC-centric to SASE-centric overnight. The realistic in-between state has some traffic still legitimately wanting the hub (because the destination is still in a DC or a cloud VPC the hub serves) and some traffic that should now go straight to a SASE PoP — and the steering policy that decides which is which becomes the single most important piece of the design. Get it wrong in one direction and you backhaul traffic that didn’t need it; get it wrong in the other and you send traffic that needed inspection straight past the controls that were supposed to catch it.
• The hub’s placement question becomes “where does it still add value”, not “where is it close to the action”. Once a customer is meaningfully SASE-converged, a hub that exists mainly to anchor the residual site-to-site overlay doesn’t need to chase application locality the way Parts 1 and 2 describe — it needs to sit somewhere that gives it good connectivity to the remaining things it serves, which by this point might be a much shorter list than it used to be.

The constant, one more time, because it’s worth repeating

Across all three parts of this series — DC, customer-centric MSSP placement, cloud, and now SASE — exactly one thing about hub design hasn’t moved: the BGP-on-loopback relationship between the hub and whatever it needs to stay reachable to, including (always, everywhere) the FMG/FAZ management plane.

That’s not a coincidence, and it’s worth naming as the actual takeaway of this series, not just a recurring footnote. Loopback peering was never a DC-specific trick — it’s a placement-agnostic routing pattern that happens to have been first explained, on this blog, in a DC-centric context. Once you see it that way, the whole arc of this series collapses into a single observation:

The hub’s job — terminate tunnels, anchor routing, enforce policy, stay reachable to its management plane — is portable. The hub’s location was only ever a function of where the things it serves happen to be. Move those things, and the right answer to “where does the hub go” moves with them, without the underlying design needing to change at all.

That’s the question worth asking, every time an estate changes shape: not “should we move the hub”, but “have the things this hub serves moved — and if they have, has anyone actually gone back and checked whether the hub is still in the right place?” Often, the honest answer is that nobody has, because the original placement decision felt so obviously correct at the time that it stopped looking like a decision at all. Parts 1 through 3 of this series were, in the end, an attempt to make that decision visible again — so it can be revisited on purpose, rather than discovered by accident during the next migration.

Series recap

Part	Topic
1	The traditional model — hubs in the DC, the FMG/FAZ relationship, BGP on loopback as the connective tissue
2	The MSSP shift — multi-tenant FMG/FAZ via ADOMs, and why hubs become customer-centric
3 (this post)	Placement in practice — cloud (Azure/AWS/GCP) and the migration from DC-centric to SASE-centric designs

If there’s one thread to pull on next, it’s the steering-policy problem this post ended on — the hybrid state where some traffic still wants the hub and some wants the nearest SASE PoP, and the policy has to get that split right at scale, per customer, without anyone having to hand-tune it site by site. That’s a series of its own.