One firewall outage during a business day is usually enough to change how an IT team thinks about resilience. A proper FortiGate high availability guide is not just about keeping packets moving. It is about protecting branch operations, remote access, compliance obligations and internal confidence when hardware fails, firmware needs attention or a site takes an unexpected hit.
For most organisations, FortiGate HA is worth considering as soon as the firewall becomes operationally critical. If the internet link supports revenue, staff productivity, customer services, cloud applications or inter-site traffic, a single appliance becomes a single point of failure. High availability reduces that risk, but only when it is designed with the right expectations. HA is not magic. It improves continuity, yet it still depends on clean switching, sensible session handling, stable links and hardware that is sized for the live environment rather than the bare minimum.
What this FortiGate high availability guide covers
At a practical level, FortiGate HA lets two or more FortiGate appliances operate as a cluster so one unit can continue traffic processing if another fails. In most business deployments, that means an active-passive pair. One unit handles production traffic while the secondary unit stays synchronised and ready to take over. In larger or more specialised environments, active-active can be considered, but it introduces more design nuance and is not automatically the better choice.
For SMB and mid-market buyers, active-passive is usually the cleaner option. It is easier to validate, simpler to operate and generally better aligned to straightforward continuity goals. If the priority is dependable failover without unnecessary operational overhead, active-passive often delivers the best value.
Choosing the right HA mode
The first decision is usually not whether to use HA, but which HA behaviour fits the risk profile. Active-passive is the standard recommendation because it is predictable. The primary FortiGate processes traffic and the secondary mirrors the session and configuration state. If the primary fails, the secondary assumes the role.
Active-active can distribute some load across cluster members, but it does not remove the need to size correctly. It also adds complexity around traffic distribution, troubleshooting and performance expectations. For many organisations, the gain is marginal compared with the operational simplicity of active-passive. If your team is small, or if you want a cleaner support model, active-passive is generally the more commercial decision.
There is also the question of whether HA is enough on its own. If both nodes sit on the same rack, same power domain and same switching path, you have reduced appliance risk but not removed infrastructure risk. That may still be acceptable. It depends on the business impact of an outage and the budget available. A pragmatic design often starts with dual firewalls, then improves switch, power and WAN resilience over time.
Sizing matters more than most buyers expect
A common mistake in any FortiGate high availability guide is treating the second unit as a dormant spare that does not need full production capacity. In reality, each appliance in the cluster should be capable of carrying the required traffic load when it becomes active. That includes security inspection overhead, VPN sessions, SSL inspection, SD-WAN policy processing and logging behaviour.
If the live box is already running hot during peak usage, HA will not fix that. It will simply fail over to another appliance with the same constraints. Proper sizing means allowing for growth, inspection services and real-world spikes, not just headline throughput figures from a datasheet.
This is where procurement and technical design need to stay aligned. The cheapest pair is not always the best-value pair if it limits features or creates another refresh event too soon. Cost discipline matters, but so does design integrity.
Key design rules before deployment
HA works best when both units are closely matched. In most deployments, that means the same FortiGate model, compatible firmware and consistent interface planning. Mixed assumptions around ports, transceivers, switch paths or WAN handoff can create avoidable instability.
Heartbeat links deserve particular attention. These are the communication paths that let cluster members monitor each other and maintain synchronisation. They should be direct, reliable and protected from congestion where possible. Using dedicated heartbeat interfaces is standard practice because it improves stability and reduces the chance that routine traffic affects cluster health.
Your switching design also matters. If failover depends on a single upstream switch that can itself fail, your HA design is only solving part of the problem. For stronger resilience, pair the firewall cluster with redundant switching and clean Layer 2 design. That does increase cost and planning effort, but it gives the HA pair a better foundation.
Configuration and synchronisation considerations
A FortiGate HA pair synchronises configuration between members, but not every operational element behaves identically in every scenario. Session pickup, routing behaviour, DHCP, VPN states and link monitoring need to be validated against your environment. If you rely on IPsec tunnels, remote users, VoIP or application-sensitive traffic, test those paths specifically.
Split-brain prevention is another area that deserves respect. If cluster members lose sight of each other under the wrong conditions, both may try to become primary. Good heartbeat design and sensible priorities reduce that risk. So does disciplined change control. HA problems often appear after ad hoc cabling changes, switch modifications or firmware work done without a rollback plan.
Pre-emption is another setting worth reviewing carefully. Some teams want the preferred unit to resume the primary role as soon as it returns. Others prefer the currently active node to stay active until a maintenance window. Neither approach is universally correct. If stability is the top priority, avoiding unnecessary failback is often the safer operational choice.
Firmware, licensing and support realities
HA planning should include firmware lifecycle and support arrangements, not just hardware. Cluster members should run supported and compatible FortiOS versions, and upgrades should follow a controlled path. The cluster can make maintenance safer, but only if the process is planned, tested and aligned to Fortinet guidance.
Licensing questions also come up early. Buyers want to know whether both units need subscriptions and how security services behave in an HA pair. The exact answer depends on the model, services and deployment intent, so this is one area where assumptions can become expensive. It is worth confirming the entitlement structure before procurement, especially when bundling support, UTM services, SD-WAN features or managed operations.
For Australian organisations, local support capability matters as much as licence status. If a failover event happens after hours, or if a firmware issue affects production, response quality becomes part of the solution value. That is one reason many buyers prefer to work with an authorised partner that understands both Fortinet architecture and local operational requirements.
Testing failover properly
Too many HA deployments are declared complete after the secondary node appears in the cluster dashboard. That is not a meaningful test. Real validation means checking what happens to traffic, sessions, VPNs, routing and monitoring when a device, link or power source fails.
Planned failover testing should be part of commissioning. Trigger a controlled role change and observe user impact. Test internet breakout, branch connectivity, remote access, east-west traffic if relevant, and any business-critical applications that are sensitive to interruption. Then document the behaviour clearly so operations staff know what to expect later.
It is equally important to test how the environment recovers. A clean failover is only half the story. You also want predictable alerts, visible logs and a well-understood path back to steady state.
When HA is the right investment
HA makes strong commercial sense when firewall downtime costs more than the second unit and the extra design effort. That threshold arrives earlier than some businesses think. A single outage can affect ERP access, cloud applications, phones, site-to-site VPNs, guest services, warehouse systems or remote users all at once.
Still, there are cases where HA is not the first priority. If an organisation has one internet service, one switch stack and no secondary power, a second firewall may not deliver the resilience uplift expected by management. It still helps, but the business case should be framed honestly. Sometimes the right answer is a staged roadmap: improve core connectivity first, then deploy HA, or do both where risk justifies it.
For teams weighing platform options, the best FortiGate HA design is usually the one that can be supported cleanly six months from now, not just the one that looks best in a proposal. Simplicity, serviceability and correct sizing will outperform clever but fragile architecture every time.
If you are planning a Fortinet refresh or designing for higher uptime, treat HA as part of the wider security and network operating model. Done properly, it gives you more than redundancy. It gives your team room to maintain, update and respond without holding the business hostage to a single box.