Security teams do not deploy a next-generation firewall to win a single connection speed test. They deploy it to apply policy, inspect encrypted traffic, and stop threats before those threats reach production workloads. That is why the more practical question is not whether deep inspection introduces overhead. It does. The real question is whether the firewall continues to scale as real workloads add concurrent users, sessions, and downloads.
In our benchmark, OCI Network Firewall showed that it can do exactly that. Under a repeatable heavy-download workload, with TLS decryption and intrusion prevention enabled, throughput increased materially as concurrency rose. The result is not that a deeply inspecting firewall behaves like an unconstrained direct path with no security controls. The result is that OCI Network Firewall delivered steady aggregate throughput growth as client load increased, which is the behavior security teams need when protected traffic grows.
Why OCI Network Firewall matters
OCI Network Firewall is a managed next-generation firewall service designed to place inspection and policy enforcement directly in the application traffic path. The broader product value comes from capabilities such as network filtering, URL-aware controls, intrusion detection and prevention, and SSL/TLS inspection. Those are exactly the kinds of controls security teams need when they want stronger protection for north-south and east-west traffic, but they are also the controls that raise the performance question. This benchmark focuses on one of the most demanding combinations: TLS decryption plus intrusion prevention under increasing concurrent load.
Our broader benchmark work also included reference testing with Palo Alto VM-based deployments in OCI and Azure Firewall Premium in Azure. That comparative data is useful, but this post intentionally keeps the spotlight on the OCI customer question: what happens to protected throughput when OCI Network Firewall is asked to inspect more simultaneous traffic?
Figure 1. Simplified lab topology used to isolate OCI Network Firewall scaling behavior
What we tested
We kept the test design intentionally simple so the benchmark would reflect firewall scaling rather than application complexity. A client VM ran Siege, a backend web server served the content, and OCI Network Firewall sat in the traffic path between them. The client and server were sized so they would not become the primary bottleneck.
- Traffic profile: repeated downloads of a 1 MB PDF file to create a heavy-transfer scenario.
- Concurrency steps: 1, 10, 20, 30, and 40 simulated clients.
- Inspection mode in the OCI Network Firewall path: TLS decryption enabled and intrusion prevention enabled.
- Run duration: approximately 60 seconds per execution based on Siege output.
- Test focus: scalability of protected throughput, not a broad feature bake-off or workload sizing guide.
Scope and caveats
This is a synthetic benchmark, not a universal sizing recommendation. Results reflect one lab topology, one traffic pattern, one inspection posture, and one test duration. Workload mix, policy complexity, file sizes, session behavior, and rule design can change observed performance. Cross-platform comparisons should also be treated carefully because deployment model, datapath implementation, and inspection mode are not perfectly identical across services.
Benchmark result: throughput rises with concurrency
In the heavy-download scenario with TLS decryption and intrusion prevention enabled, OCI Network Firewall throughput increased as more clients were added. The measured throughput values below summarize the main result.
| Simulated concurrent clients | Measured throughput MegaByte/s (MB/s) |
| 1 | 5.98 |
| 10 | 53.68 |
| 20 | 98.515 |
| 30 | 130.81 |
| 40 | 161.99 |
That increase from 5.98 to 161.99 megabytes per second (MB/s) represents roughly 27x higher throughput between the 1-client and 40-client test points. The more important message for customers is not the headline multiplier by itself, but what it indicates operationally: the service continued to add useful aggregate throughput as concurrency rose, instead of flattening early under inspected traffic.
The benchmark also showed something equally important for honest interpretation. At very low client counts, the relative cost of deep inspection is more visible than it is under heavier concurrent load. That is consistent with what security teams should expect from a firewall doing real work such as decryption and prevention. Compared with a direct path that applies no firewall controls at all, low-concurrency traffic will show a larger performance penalty. But as more clients were added in this test, OCI Network Firewall scaled upward in a way that is far more representative of shared production environments.
What the benchmark means for security teams
First, this result reinforces that single-client measurements are not enough to judge the practical value of an inspected security path. A one-client test emphasizes fixed inspection overhead. Real enterprise traffic, however, is usually an aggregate of many users, sessions, API calls, downloads, and service-to-service connections occurring at the same time.
Second, the benchmark suggests that OCI Network Firewall becomes more meaningful when evaluated against realistic concurrency rather than against an idealized no-firewall path. That is the customer decision point: not whether security controls are faster than no controls, but whether the protected path scales well enough for the workload it is meant to secure.
Third, the test helps frame capacity planning more accurately. For teams considering TLS inspection and IPS in front of production applications, concurrency is a first-order sizing variable. The wrong lesson from a benchmark is to look only at the smallest test case. The right lesson is to size against the traffic shape the environment will actually generate.
Why this matters
Encrypted traffic is now the norm, which means security teams increasingly need decryption and prevention in the traffic path if they want meaningful inspection. Without that visibility, malicious content, risky destinations, and policy violations can move through approved connections unnoticed. The concern, of course, is that turning those controls on will create a throughput bottleneck. This benchmark gives a more grounded answer: there is overhead, especially at low concurrency, but OCI Network Firewall demonstrated that inspected throughput can scale materially as protected demand increases.
That is valuable not only for application teams but also for platform and security architects. It means performance discussions can move away from a narrow no-firewall baseline and toward a more practical question: how much protected throughput can the service sustain as the number of active clients grows? For teams standardizing on OCI-native security controls, that is the question that better aligns with production planning.
Key takeaways
- OCI Network Firewall showed steady throughput growth as concurrent client count increased, even with TLS decryption and intrusion prevention enabled.
- The benchmark supports a product message centered on protected scalability, not on a simplistic comparison with an uninspected direct path.
- Low-client tests matter, but they should not be the only lens for judging a deeply inspecting firewall in production-like environments.
- Concurrency should be treated as a primary sizing input when evaluating inspected traffic paths in OCI.
- Broader vendor comparisons belong in a carefully caveated companion discussion because deployment architecture and inspection semantics differ across platforms.
Conclusion
OCI Network Firewall is valuable because it is not just a traffic pass-through. It is where customers can apply inspection and enforcement that modern workloads actually require. That changes the performance conversation. The right benchmark question is not whether a firewall is faster than no firewall. The right question is whether a firewall with meaningful security controls can continue to scale as protected traffic grows.
In this benchmark, the answer was yes. With TLS decryption and intrusion prevention enabled, OCI Network Firewall throughput rose from 5.98 to 161.99 megabytes per second (MB/s) between the 1-client and 40-client test points. For security teams running real workloads, that is the more relevant result: OCI Network Firewall showed that it can add throughput as concurrency increases while maintaining the value of deep inspection. That is the story this benchmark should tell.