Firewall data sheets make capacity look simple. Find the throughput number, compare it with the internet circuit, and choose a model with room to spare. That approach works only when the firewall is forwarding clean, predictable traffic under the same conditions used for the number being compared.
Production environments are different. Traffic is encrypted. Intrusion prevention, application control, antivirus, web filtering, DNS security, segmentation, VPN, logging, and SD-WAN may operate at the same time. Session rates rise during login surges or application reconnects. High availability changes what one appliance may need to carry. A future circuit upgrade can invalidate the original assumptions.
That is why FortiGate sizing cannot be reduced to one throughput figure. The right model is the one that can apply the intended security policy to the real traffic mix, at peak conditions, during failure and maintenance states, with enough headroom for growth. Anything less turns a security control into a performance constraint.
Basic firewall throughput measures high-speed packet forwarding with a limited policy workload. It is useful for understanding the platform's raw networking capacity, but a next-generation firewall is purchased to do more than route packets. Once security services inspect content and applications, the workload changes.
Fortinet therefore publishes several performance categories. Depending on the model, these can include firewall throughput, IPsec VPN throughput, SSL inspection throughput, NGFW throughput, threat protection throughput, concurrent sessions, and new sessions per second. The values are not interchangeable because they represent different test conditions and security functions.
A common sizing mistake is to compare a fully inspected production workload with the raw firewall number. The appliance may still pass traffic, but latency, CPU utilization, session setup, logging delay, or user experience can deteriorate as inspection load increases. The correct comparison starts with the security profile that will actually be enabled.
This describes Layer 3 and Layer 4 packet forwarding under the vendor's stated test methodology. It can help validate interface and routing capacity, but it should not be used alone for a deployment that expects full next-generation inspection.
NGFW testing typically reflects application control and intrusion prevention under defined conditions. It is closer to many enterprise use cases, but teams still need to read the exact assumptions in the data sheet, including traffic mix and enabled services.
This represents a broader inspection workload that may include firewall, intrusion prevention, application control, and malware protection. For environments planning to enable multiple FortiGuard security services, it is often a more relevant starting point than raw forwarding performance.
Encrypted traffic must be decrypted before many controls can inspect its contents, then re-encrypted before it continues. That process adds compute work and certificate-handling complexity. NIST notes that enterprises rely on visibility into TLS-protected traffic for functions such as intrusion detection, troubleshooting, and fraud monitoring. The inspection requirement therefore affects both security design and capacity.
Site-to-site overlays, remote access, and SD-WAN designs may encrypt large portions of traffic. VPN throughput matters when the FortiGate terminates those tunnels, particularly when the same traffic is also subject to security inspection.
Two networks can move the same number of gigabits while placing very different demands on a firewall. A file transfer may use a small number of long-lived sessions. A customer-facing platform, busy branch, or application environment may create hundreds of thousands of short connections. The session table must absorb the peak, not just the daily average.
Connection storms occur during shift changes, application restarts, failovers, software updates, or service recovery. A firewall can have enough aggregate bandwidth and still struggle to establish sessions at the required rate. This metric is especially important for high-volume web, contact center, retail, and data-center workloads.
Small packets require more processing per unit of bandwidth than large packets. Voice, transactional traffic, video, backups, SaaS, and east-west application flows all behave differently. A realistic profile should account for the mix instead of treating every gigabit as equal.
Detailed logging, multiple security profiles, complex objects, application identification, external integrations, and high event volume add operational load. These features are part of the value of the platform, but they should be included in design and validation rather than enabled after sizing is complete.
Encryption protects confidentiality, but it can also hide malicious content from controls that cannot inspect inside the session. Deep inspection creates visibility by terminating the encrypted connection, validating policy, inspecting the content, and establishing a new protected connection. That adds work to every eligible flow.
The correct design is not necessarily to decrypt everything. Privacy, legal, application compatibility, certificate pinning, and business requirements may justify exclusions. The sizing model should therefore classify traffic: what must receive deep inspection, what receives certificate inspection, what is exempt, and how those proportions may change.
This policy exercise is as important as the hardware choice. Overestimating exclusions creates security blind spots. Assuming universal deep inspection without testing can break applications or consume capacity unnecessarily. The production target should be evidence-based and validated with the organization's own application portfolio.
Use historical monitoring to capture sustained peaks, bursts, seasonal events, backup windows, and failover behavior. Average utilization hides the moments when the firewall matters most.
Document intrusion prevention, malware protection, application control, web and DNS filtering, SSL inspection, segmentation, VPN, SD-WAN, and logging requirements by traffic class. Map each policy to the relevant vendor performance category.
Collect concurrent sessions, new sessions per second, protocol mix, packet sizes, and connection duration. Include shift changes, login storms, and recovery events rather than relying on a quiet baseline.
Add internet circuits, private WAN, cloud on-ramps, site-to-site VPN, remote users, east-west segmentation, and planned upgrades. A FortiGate may inspect more traffic than the public internet circuit alone suggests.
In an active-passive pair, confirm that one appliance can carry the required production load when its peer is unavailable. In clustered or distributed designs, model maintenance, link failure, device failure, and traffic rebalancing. High availability does not create capacity if the surviving state is undersized.
Account for user growth, new branches, higher-speed circuits, cloud migration, additional inspection, software changes, and the expected hardware lifecycle. Headroom should be tied to plausible business events, not added as an unexplained percentage.
Use configuration review, test traffic, a pilot site, or a proof of concept to compare assumptions with observed behavior. Monitor CPU, memory, session use, latency, drops, inspection performance, and log flow. A model becomes defensible when evidence supports it.
Sizing only to current ISP bandwidth ignores internal segmentation, VPN, cloud, and future circuit capacity. Using average traffic ignores peaks. Selecting the raw firewall number ignores the intended security services. Applying one branch model everywhere ignores differences in applications, sessions, resilience, and local growth.
Another mistake is treating oversizing as the only safe response. A larger appliance may add cost, rack, power, and licensing commitments without addressing poor policy design. The objective is not the biggest firewall. It is enough capacity for the defined workload, with justified headroom and a clear expansion path.
Fortinet publishes model-specific data sheets and a product comparison tool covering threat protection, SSL inspection, session capacity, interfaces, and other performance characteristics. FortiGate also consolidates NGFW, routing, SD-WAN, segmentation, VPN, and ZTNA capabilities within FortiOS.
That breadth makes the sizing exercise more important, not less. Teams need to identify which functions will run on the appliance, which traffic each function will process, and how capacity changes during failover and growth. The data sheet supplies benchmarks. The architecture supplies meaning.
Condado starts with traffic, applications, security policy, topology, resilience, and business growth. We assess the existing environment, define the inspection model, map the workload to relevant Fortinet performance measures, compare suitable FortiGate models, and design the deployment and migration plan around continuity. This makes FortiGate sizing an architecture decision supported by evidence rather than a product guess.
We also account for what happens after installation: policy activation, logging, failover validation, certificate deployment, application exceptions, and performance baselining. This reduces the risk of buying capacity that looks sufficient on paper but cannot support the controls the organization intended to use.
Learn More about Condado’s Cybersecurity practice →
Firewall capacity is not a single number because security is not a single operation. Inspection depth, encryption, session behavior, application mix, logging, resilience, and growth all shape production performance.
A disciplined sizing process turns those variables into an architecture the business can rely on. It gives security teams room to enable the controls they selected, infrastructure teams a stable performance baseline, and leaders a clear explanation for the investment. That is the purpose of effective FortiGate sizing.
Request a security and capacity assessment to align FortiGate hardware, inspection policy, resilience, and growth with your real environment.
Get in touch →
Claudeforce connects Salesforce data, workflows, permissions, and business logic with Anthropic’s Claude. Here’s what has shipped, what remains early, and what enterprises should evaluate.
Condado has become part of One Primero — a consolidated operating brand bringing Condado's contact center expertise and Tricension's technology delivery capability together under one name. Same team, same relationships. New name.
