Why Your Network Can Often Be Reduced to 2 or 4 Core Devices

This page is intentionally written in English.

This article discusses architecture, not products.

Questions about specific implementations are welcome. This article focuses on architectural intent, but practical discussions are always encouraged.

Executive Summary

Conclusion first:
In many enterprise environments, the most rational starting point is simple: connect all servers directly to a firewall platform with sufficient physical port capacity.

Many enterprise networks have become more complex than the business itself requires.

Over time, additional devices are introduced to solve local or short-term problems: more switches for port shortages, separate controllers for wireless, and additional security layers added incrementally. While each decision may have been reasonable in isolation, the accumulated result is often a network that is expensive to operate, difficult to explain, and structurally inefficient.

This document proposes a different perspective.

In many ordinary enterprise environments, the core network and security function can often be consolidated into 2 or 4 core security devices, without sacrificing resilience or future growth. This is not an argument for aggressive minimalism, but for disciplined architecture.

The key principle is simple: network design should start from the actual server structure and real port requirements, not from predefined switch hierarchies or historical design patterns.

A reduced core device count has direct economic implications. Every additional device consumes power continuously, generates heat, occupies rack space, and introduces operational overhead. Energy cost is no longer a stable variable; it is increasingly influenced by external factors beyond the organization’s control.

Reducing unnecessary device count therefore becomes not only an efficiency measure, but a form of structural risk mitigation.

Importantly, this approach does not eliminate future expansion. Access switching and wireless infrastructure can be added later in a controlled and integrated manner, without destabilizing the core architecture.

For clarity, this document uses Fortinet-based examples. However, the architectural principles described here are vendor-neutral and applicable to any integrated network security platform capable of centralizing policy, routing, and control.

The objective is straightforward: to build networks that are easier to explain, safer to operate, more resilient to change, and economically rational over their entire lifecycle.

Before: When Port Count, Not Architecture, Drives the Design

The diagram below shows a typical enterprise network that has grown through incremental decisions rather than architectural intent.

Firewalls, Layer-3 switches, access switches, environment-specific devices, and edge routers have been added over time to solve local problems such as port shortages, segmentation, or redundancy requirements.

As a result, servers are no longer connected where policy and routing decisions are made. Instead, they are placed behind multiple layers of switching, each introducing additional power consumption, operational complexity, and failure points.

In this structure, device count is driven not by necessity, but by historical layering. Redundancy exists, but responsibility is fragmented. The network works, but it is difficult to explain, difficult to operate safely, and expensive to maintain over time.

The difference between these two diagrams is not technology. It is intent.

After: When Architecture, Not Port Count, Defines the Network

The diagram below shows the same environment after the network has been redesigned around architectural intent rather than incremental expansion.

The number of devices has been reduced significantly, but this reduction is not the goal. It is the result of concentrating routing, policy enforcement, and failure domains into a small number of clearly defined core security devices.

It is also worth noting that there are platforms where additional switching capacity can be introduced in an SDN-style manner, with firewalls and switches operating under a unified control plane. In such cases, both components effectively behave as a single logical system, significantly reducing configuration effort and operational overhead.

Similarly, some platforms integrate wireless LAN controller functionality as a native capability rather than as a separate appliance. The existence of these designs further demonstrates the generality of the network architecture proposed here.

The intent of this approach is not to depend on a specific product feature set, but to show that concentrating control, policy, and expansion under a coherent architectural model is broadly achievable across modern network platforms.

“

In this structure, servers are connected directly to the firewall layer. Layer-3 control and security policy are enforced at a single, well-defined point, eliminating the need for intermediate routing and switching layers that previously existed only to compensate for port limitations.

As a result, the core architecture becomes easier to explain, easier to operate, and easier to expand. Redundancy is preserved, but responsibility is no longer fragmented across multiple device types and layers.

Fewer always-on devices mean lower baseline power consumption and fewer long-term operating constraints.

This is not a design that eliminates future growth. Access switching and wireless infrastructure can still be added where needed, but they are added as extensions of a stable core rather than as structural dependencies.

The reduction from twenty devices to four is therefore not an exercise in minimization. It is a correction of architectural focus.

Design assumptions behind this architecture:

First, the firewall platform directly terminates external circuits. This removes the need for separate edge routing devices and ensures that routing decisions, security policy, and failure boundaries remain aligned.

Second, multiple LAN-side default gateways are defined per segment on the firewall. This allows internal segmentation requirements to be met without introducing additional routing devices solely for gateway distribution.

These are not the core message of this design. They are practical implementation assumptions that support the architectural objective: reducing unnecessary devices while keeping responsibility centralized and explicit.

Conclusion

Many networks are complex not because the business truly requires it, but because complexity has been allowed to accumulate.

By starting from the real server structure, estimating realistic port requirements, separating server and network renewal, minimizing unnecessary Layer-2 sprawl, and treating power cost as a structural design input, networks can remain simpler, safer, and economically rational over time.

This is why the question is not “how many devices do we have,” but “why do we need them at all.”

This Is Not a Theory

The approach described in this article is not hypothetical. It is based on actual network redesign and consolidation projects.

If you are operating a network with excessive device count, this kind of structural simplification may already be possible in your environment.

We provide architecture design and implementation support for these transformations.

→ See also: Architecture Philosophy
→ Related: 20+ to 4: HA Firewall Consolidation

Contact for Deployment Validation