Hub-and-spoke looks good, until you see the costs and the unmanageability.

Hub-and-spoke sounds like mature architecture.

Neat. Centralized. Manageable.

One hub for control, security, and routing. Surrounded by spokes that are connected in a predictable way.

On paper, it looks like order.

In practice, it often grows into something we don't want at all: an expensive and difficult-to-understand traffic junction.

Because the promise of simplicity lies mainly in... well, the picture. Not in the behavior of the system once your environment grows.

Initially, each additional spoke seems harmless. Until you realize what is happening beneath the surface.

Let's do some quick math: with N spokes, each spoke can communicate with N-1 other spokes via the hub. This means that the number of possible communication paths does not grow linearly, but quadratically: N × (N-1). With 10 spokes, you are already talking about 90 possible paths. With 100 spokes, that number rises to 9,900. And with 300 spokes, you're looking at around 90,000.

Without doing the math: before you know it, the whole thing gets completely out of hand.

That's no longer a network that a team can intuitively oversee. It's a traffic plan that your spreadsheet can still keep track of, but your people can no longer manage.

And that's where the real problem begins. Not only technically, but also commercially.

More paths mean more rules, more exceptions, more dependencies, more chances for errors, and more time wasted on changes, incidents, and audits. Every adjustment quickly affects more than one connection. Every disruption has more possible causes. Every step of growth makes the whole thing less transparent.

But that's not all. In the cloud, there's a unexpected surprise: the bill.

In Azure, hub-and-spoke is often rolled out around an Azure Firewall. This costs money not only because it is switched on, but also because all traffic passes through it. And because processing capacity has to grow with the load. With an average of 90 MB/s of traffic—which is modest rather than extreme for a serious enterprise environment—the cost of that firewall can easily and rapidly quadruple. And that's not even including the additional capacity costs.

What starts as central control can easily end up as central congestion.

And the larger the environment, the more expensive it becomes to continue believing that this is still simple.

More security, less hassle: smarter alternatives to hub-and-spoke

Hub-and-spoke is often sold as security architecture.

The reasoning sounds logical: if a system is compromised, you don't want it to serve as a springboard to the rest of your environment. That premise is fine. There's no debate about that. The problem lies elsewhere: hub-and-spoke is by no means the only way to limit lateral movement. And often it's not the smartest either.

Too many organizations solve a management issue with extra network complexity. Suppliers promote this extensively. As if security is mainly created by more paths, more central facilities, and more layers of control. But security does not automatically improve because your architecture becomes more expensive, heavier, and more abstract. Often the opposite happens: you build an impressive fence around a site that is still full of open doors internally.

If you want to seriously limit lateral movement, you must first look at reducing the attack surface.

Let's make it practical. Start by disabling services you don't use. What's not there can't be exploited. That sounds almost too simple, but that's exactly why it's often overlooked and skipped. Many vulnerabilities don't live in “exotic” software, but in ordinary services that were once necessary. They were never cleaned up and are still running obediently. On Windows, turning them off is sometimes more difficult than it should be. You can't just ignore SMB, but you can often ignore outdated and vulnerable forms of authentication within it. And why should the print spooler remain active on a server that is never used for printing? Every unnecessarily active component is a free tool for an attacker.

Next comes a classic that is strikingly and too often underestimated: the local firewall.

Many security discussions are conducted at the network or platform level. Meanwhile, the server itself can be an excellent gatekeeper. Servers in the same segment do not always need to communicate freely with each other. In many environments, this is even pure laziness. By allowing only strictly necessary communication and blocking the rest, you make cross-contamination with malware a lot more difficult. Not perfect, but effective. And above all, much more targeted than a generic architecture layer that ultimately has to let everything through anyway.

It also helps to separate management and service traffic.

A compromised server may sometimes access an application on another server. What you definitely don't want is for that same server to also have direct access to management interfaces. As soon as management paths and service paths become intertwined, you shorten the route to further escalation. Then an attacker not only has to hit a workload, but may also gain access to the control panel behind it. Separation reduces that risk. Provided, of course, that management interfaces cannot communicate freely with each other either.

If you are still running on-premises with your own network equipment, you can go one step further: with filtering at the network level.

This is similar to what a local firewall does, but outside the server itself. This makes it more robust. Servers within the same VLAN do not necessarily have to communicate with each other. The idea that “we put them together, so they can see each other” is technically easy, but not wise in terms of security. And may I say “lazy”? Filtering outside the system prevents a compromised server from also managing its own fence.

Another underestimated mistake lies in identity.

We all love Single Sign-On. Understandably so. Me too. It's convenient, fast, and user-friendly. But convenience comes at a price. If the same account can use applications and manage servers, you end up with functional and administrative traffic overlapping. Then an attacker doesn't even need to have direct administrative rights to retrieve valuable information. Even read rights can be enough to prepare for the next step. If you want to slow down lateral movement, you need to keep management accounts and user accounts strictly separate.

In line with this, local management accounts are often more sensible than having the same global power everywhere.

Not because local is necessarily better, but because it limits the spread of infection. Credentials that can be used on server A should not automatically grant access to server B. Otherwise, you create a domino effect that you call centralization but which poses a potential danger. That's not what you want.

And then there's another uncomfortable truth: IPv6 is often more secure than organizations think.

A lot of malware tries to do a quick neighborhood scan: what other systems are on this network? Under IPv4, that's easy to figure out. Under IPv6, it suddenly becomes practically impossible. The address space is so vast that ‘simply’ looking around turns from a quick scan into an operation that takes an absurd amount of time and generates suspicious traffic. That alone makes lateral exploration more difficult and much easier to detect.

The core idea is simple: counteracting lateral movement is sensible. But you don't automatically need an expensive hub-and-spoke landscape to do so. You can often achieve more with less ‘glamour’ and more discipline. Fewer open doors. Fewer unnecessary rights. Less implicit trust. And above all: less architecture as a cover for operational sloppiness.

What is sensible in your environment?

“Best practice” sounds appealing and safe. Until you discover that you have unintentionally adopted someone else's complexity. And believe me, it happens more often than we would all like.

The truth is simple: what makes sense and is “the very best practice” for one person may be unnecessarily expensive, difficult to manage, or downright awkward for your environment. Especially when it comes to choices around hub-and-spoke, security, and segmentation, there is no standard solution that always fits. Workloads, management burdens, risks, and growth plans simply vary too much for that.

There are alternatives, often more than enough. But which combination is sensible depends on your infrastructure, how you work, what you want to protect, and, above all, what you don't want to be burdened with in terms of costs and complexity.

Hub-and-spoke looks good, until you see the dependencies and the bill.

 

Do you have 30 minutes? Then I'll take a look with you at what makes sense in your situation.

Free of charge.

I've looked into the IT kitchens of so many organizations that I can immediately see where something isn't working properly. Call me the Gordon Ramsey of IT, but without the shouting.

Make a no-obligation appointment. You'll immediately know how you can set things up more securely, more intelligently, and more cost effective.