A regional hospital group — six clinics, a billing back office, a patient-facing appointment portal, and a brand-new Moodle site for staff compliance training — has just moved its first workloads to the cloud. The platform team did what almost every team does on its first project: they created one big virtual network, dropped everything into it, and shipped. It works. It also terrifies the new security lead, who asks one question in the architecture review that the team cannot answer: “If the public appointment portal gets popped, what stops the attacker from reaching the database that holds patient records?” In a flat network, the honest answer is “nothing.” The portal, the billing system, the training server, and the patient database can all reach each other freely, because they share one address space with no internal walls. This article is about the first real fix for that problem — network segmentation using a hub-spoke topology — explained from the ground up, with no assumed background beyond knowing what a virtual network is.
Healthcare makes the stakes concrete. The hospital is under HIPAA-style data-protection rules, so a breach of patient records is not just embarrassing — it is reportable, finable, and career-ending. The appointment portal is deliberately exposed to the public internet, which makes it the most likely thing to be attacked. And the organization is growing: two more clinics are joining next year, each needing its own systems. A flat network fails all three pressures at once — it gives an attacker free movement, it puts the exposed thing next to the sensitive thing, and it gets messier and more dangerous with every new system bolted on. Segmentation is how you contain a breach, separate the exposed from the sensitive, and keep growing without the network becoming a single fragile blast radius.
What “segmentation” actually means
Segmentation is the practice of splitting one network into smaller, isolated zones and controlling exactly what is allowed to cross between them. The mental model that helps beginners most is a building. A flat network is a warehouse: one giant open floor where anyone who gets through the front door can walk anywhere. A segmented network is an office building with locked internal doors — reception, the finance department, the server room — where getting into the lobby does not get you into the vault. The locked doors are the point. You are not trying to keep everyone out (you can’t — the portal must be reachable); you are trying to make sure that getting into one room does not hand over every room.
In cloud terms, those “rooms” are separate networks or subnets, and the “locked doors” are firewall rules and routing decisions that say which zone may talk to which, on which ports, in which direction. The goal is least privilege at the network layer: by default nothing talks to anything, and you open only the specific paths the application genuinely needs. This is the network half of Zero Trust — the principle that being “inside the network” should grant you nothing on its own.
Why a hub-spoke topology
Once you accept that you need many isolated zones, a new problem appears: those zones still need a few shared things. Every workload needs DNS. Every workload needs a controlled way out to the internet for patches and updates. Every workload’s traffic should pass through a common inspection point so the security team has one place to watch. You do not want to rebuild all of that separately in each zone — that is wasteful, inconsistent, and a nightmare to audit.
Hub-spoke is the topology that solves exactly this. You build one central network — the hub — that holds the shared services every workload needs. Then each workload gets its own isolated network — a spoke — that connects only to the hub, never directly to its sibling spokes. Visually it looks like a bicycle wheel: a central hub with spokes radiating out, and no rim connecting the spokes to each other.
The shape gives you three things at once. Centralization: shared services and security inspection live in one place, built once. Isolation: spokes cannot reach each other by default, so the billing spoke and the public-portal spoke are walled apart even though both connect to the hub. Scalability: adding the seventh clinic next year means standing up one new spoke and peering it to the hub — the hub and every existing spoke are untouched. That last property is why this pattern is the backbone of nearly every enterprise cloud landing zone, the standardized network-and-governance foundation teams lay down before workloads arrive.
Architecture overview
Picture the hospital’s network as one hub and three spokes. The hub is the shared core. It contains a firewall appliance — concretely Azure Firewall if they are on Azure, or a Palo Alto VM-Series virtual appliance if they want the same vendor and feature set they run on-premises — which is the single chokepoint all cross-zone and internet-bound traffic must pass through. The hub also holds shared DNS, the connection back to the hospital’s on-premises data center (a VPN or dedicated private link), and a small management/jump-host subnet that administrators use to reach everything else.
The three spokes are the isolated workload zones:
- Spoke A — Public portal: the internet-facing appointment booking app. Exposed to the public, therefore treated as the least trusted zone.
- Spoke B — Billing & records: the back-office billing system and the patient-records database. The most sensitive zone, holding the data HIPAA cares about.
- Spoke C — Staff training: the Moodle learning platform running mandatory compliance and clinical-safety courses for staff. Internal, moderate sensitivity.
Each spoke connects to the hub through network peering — a direct, private link between two cloud networks. The critical design choice is what beginners almost always get wrong: peering is not transitive. Spoke A is peered to the hub, and Spoke B is peered to the hub, but that does not mean A can reach B. Two peerings to a common partner do not chain together. So out of the box, the public portal in Spoke A simply has no network path to the patient database in Spoke B. That single property — the absence of a path — is the answer to the security lead’s question, and it comes for free from the topology before you write a single firewall rule.
Following the traffic: control and data flow
Walking one real request through the design makes the moving parts click.
A patient books an appointment (north-south traffic — in and out of the cloud). A patient on the public internet hits the appointment portal. Before the request reaches the cloud at all, it passes through Akamai at the edge — a content delivery and web-application-firewall layer that terminates TLS close to the user, absorbs DDoS floods, and blocks common web attacks (SQL injection, cross-site scripting) so that obvious malicious traffic never even arrives at the hospital’s network. Clean traffic then lands on the load balancer in front of Spoke A and is served by the portal application. So far, everything stays inside Spoke A.
The portal needs a patient’s record (east-west traffic — between zones). Here is where segmentation earns its keep. The portal must look up whether a patient already exists, which means it needs to reach a service in Spoke B. It cannot go directly — there is no peering between A and B. Instead the request is routed to the hub, where the firewall appliance inspects it against an explicit rule: Spoke A may reach exactly one API endpoint in Spoke B, on port 443, and nothing else. If the request matches, the firewall forwards it; if anything else in Spoke A tries to reach anything else in Spoke B — say, a direct connection to the database port — the firewall denies it and logs the attempt. The route that forces this detour is set with a user-defined route (a custom routing rule) on each spoke that sends cross-zone traffic to the firewall’s address instead of letting the cloud find a shortcut.
An administrator patches the Moodle server (management traffic). An engineer does not connect to the Moodle box from the open internet. They reach the jump host in the hub’s management subnet (ideally through a brokered service like Azure Bastion, so no server ever exposes a public RDP/SSH port), and from there the firewall permits a controlled hop into Spoke C. One narrow, watched door for administration, instead of a remote-access port open on every server.
The shape of this is the whole lesson: traffic within a zone flows freely; traffic between zones is forced through the hub firewall and allowed only by explicit rule; traffic from the internet is filtered at the edge first. Default-deny between zones, allow-by-exception, every exception logged.
The two kinds of traffic, and why the names matter
You will hear “north-south” and “east-west” constantly, and they are worth nailing down because they map directly to two different defenses.
| Traffic type | What it is | Hospital example | Primary control |
|---|---|---|---|
| North-south | Traffic entering or leaving the cloud (to/from the internet or on-prem) | A patient reaching the appointment portal | Edge WAF (Akamai) + the hub firewall on the way out |
| East-west | Traffic moving between internal zones | The portal querying the records service | The hub firewall + non-transitive peering |
The reason a flat network is dangerous is that it has no east-west control at all. Everything inside can talk to everything else, so once an attacker is in (north-south, through the exposed portal), their east-west movement — the “lateral movement” that turns one compromised box into a full breach — is unimpeded. Hub-spoke segmentation is, at its core, a way to put a controlled wall in the east-west direction. That is the part flat networks miss and the part that contains a breach.
Where the firewall lives, and what it does
The firewall appliance sitting in the hub is the heart of the design, so it is worth being precise about its job. It is the single inspection and enforcement point for all traffic that crosses a boundary — spoke-to-spoke, spoke-to-internet, and spoke-to-on-premises. Centralizing it in the hub means you write and audit your rules in one place rather than maintaining a separate firewall per workload.
Beginners often confuse the firewall with the cloud’s built-in subnet-level rules (security groups / network ACLs), so the distinction matters. The lightweight built-in rules are good at simple, stateless “allow port 443 from this subnet” decisions and should absolutely be used as a first layer right on each spoke’s subnets. The hub firewall is the heavier, smarter layer: it does stateful inspection (it understands a connection as a whole, not just individual packets), fully-qualified-domain-name filtering (allow outbound only to *.windowsupdate.com, deny the rest of the internet), threat intelligence (block known-malicious IPs automatically), and it produces the centralized log of every cross-zone decision. Whether that appliance is the cloud-native Azure Firewall or a third-party Palo Alto VM-Series is largely a question of feature depth and whether the team already has the vendor’s skills — the position in the architecture is identical either way. A simple outbound rule on the appliance looks like this in plain terms:
# Hub firewall — allow Moodle (Spoke C) to fetch OS + plugin updates, nothing else outbound
Rule: allow-moodle-updates
source: 10.3.0.0/24 # Spoke C app subnet
destination: *.ubuntu.com, *.moodle.org, *.php.net
protocol: TCP/443
action: Allow
# Everything else outbound from Spoke C → Deny (default), and logged
That one rule captures the philosophy: the training server may reach exactly the three places it needs for patches, and the rest of the internet does not exist to it.
How the layers reinforce each other
Segmentation is necessary but not sufficient on its own — a wall with one door still needs someone watching the door. In a real hospital build, the hub-spoke network is the foundation that several other tools plug into, and naming where each one fits keeps the picture honest:
| Tool | What it does | Where it fits in hub-spoke |
|---|---|---|
| Entra ID / Okta | Identity provider — verifies who a person or service is before granting access | The identity layer above the network; the jump host and management plane require a verified identity, so “inside the network” is never enough on its own |
| HashiCorp Vault | Secrets manager — stores and leases credentials, certificates, and keys | Lives in or near the hub as a shared service; the billing app in Spoke B fetches its database password from Vault at runtime instead of hardcoding it |
| CrowdStrike Falcon | Endpoint detection — watches each server for malicious behavior | An agent on the VMs inside every spoke; if an attacker does breach a spoke, Falcon detects the activity inside the wall |
| Wiz | Cloud security posture — scans the whole environment for misconfigurations | Continuously checks that no spoke peering or firewall rule has accidentally opened a forbidden path; catches segmentation drift |
| Dynatrace / Datadog | Observability — traces traffic, latency, and health across zones | Shows where requests flow between hub and spokes, so a broken or slow cross-zone path is visible quickly |
| ServiceNow | IT service management — tickets, approvals, change records | Any new firewall rule or new spoke goes through a change request, so the network’s allowed paths are documented and approved, not silently edited |
The relationship to remember: segmentation contains the blast radius, identity decides who gets in, and detection catches what gets through. Entra ID or Okta authenticate the human or service; the network ensures even an authenticated portal can only reach its one permitted endpoint; CrowdStrike Falcon watches for trouble inside each zone; Wiz makes sure the walls have not quietly developed holes; ServiceNow keeps a paper trail of every door that was opened. No single layer is the whole defense — they are concentric, and the network is the ring that stops a single compromise from becoming a total one.
How it gets built, and kept honest
Two practices keep a hub-spoke network from rotting, and both are about discipline rather than cleverness.
Define the network as code. The hub, the spokes, the peerings, and the firewall rules are all described in Terraform — declarative files that say exactly what the network should look like — and applied through an automated pipeline rather than clicked together by hand in a portal. Server-level configuration inside the spokes (installing and hardening the Moodle stack, the billing app) is handled with Ansible. The reason this matters for segmentation specifically: when the topology is code, a reviewer can see in a pull request that someone is trying to add a peering between Spoke A and Spoke B and block it before it merges. A hand-built network has no such checkpoint. The pipeline that applies the Terraform — GitHub Actions, Jenkins, or Argo CD, depending on the team’s tooling — runs the change only after the ServiceNow change request is approved, tying the technical action to a governance gate.
Verify the walls continuously. Writing a default-deny rule is not the same as proving the deny actually holds. Wiz scans the live environment and flags if a spoke was accidentally given a route to a sibling or if a firewall rule is more permissive than intended — segmentation drift is the quiet failure where the network slowly becomes flat again through well-meaning one-off changes. Pairing the as-code definition (the intended state) with continuous posture scanning (the real state) is how the hospital keeps the security lead’s question answered six months from now, not just on launch day.
Failure modes a beginner will actually hit
Three mistakes are nearly universal on a first hub-spoke build, and recognizing them early saves a lot of pain.
- Expecting peering to be transitive. A team peers every spoke to the hub, then is baffled that Spoke A cannot reach Spoke B. This is not a bug — it is the design working. If A genuinely needs to reach B, you route that traffic through the hub firewall and add an explicit allow rule; you do not peer the spokes directly (doing so quietly defeats the whole segmentation).
- Forgetting the user-defined routes. Peering creates a possible path to the hub, but the cloud will still try to send spoke-to-spoke traffic by the most direct route it can find. Without an explicit route that says “send cross-zone traffic to the firewall’s IP,” traffic can bypass the firewall entirely — you have a firewall in the hub that nothing is forced through. The routes are what make the firewall mandatory rather than optional.
- Overlapping address ranges. If Spoke A and Spoke C are both numbered
10.0.0.0/24, they cannot be peered to the same hub — the addresses collide and routing breaks. Plan a non-overlapping IP plan for the hub and every current and future spoke before building anything. This is unglamorous and the single most common reason a hub-spoke rollout stalls.
Cost and the honest tradeoffs
Hub-spoke is not free, and a beginner should know what they are buying.
The clearest cost is the firewall appliance, which runs continuously and is one of the more expensive line items in a small cloud bill — whether it is the hourly charge for Azure Firewall plus data processed, or the licensing and compute for a Palo Alto VM-Series. There is also per-gigabyte cost for traffic that crosses peerings, which is why you keep chatty, same-tier traffic within a spoke and only force genuinely cross-zone traffic through the hub. And there is operational overhead: every legitimate new path needs a firewall rule, which is friction by design — that friction is exactly what stops paths from being opened carelessly, but it is real work.
| Tradeoff | What you gain | What it costs |
|---|---|---|
| Centralized hub firewall | One place to inspect, log, and audit all cross-zone traffic | A standing, non-trivial monthly bill and a single point that must be made highly available |
| Default-deny between spokes | A breach in one zone cannot reach the others | Every real cross-zone need becomes a deliberate, reviewed rule — more process |
| Hub-spoke vs. one flat network | Containment, isolation, clean scaling to new workloads | More moving parts, an IP plan to maintain, routes to get right |
The honest framing for a first-timer: a flat network is genuinely simpler and cheaper today, and for a throwaway prototype with no sensitive data it can be the right call. The moment you have something exposed to the internet sitting near something you cannot afford to lose — which describes the hospital exactly — the flat network’s simplicity is a loan against a future breach. Hub-spoke is the standard way enterprises pay that debt down deliberately instead of all at once during an incident.
When you do not need it (yet)
Segmentation should match the risk, not the fashion. A single internal app with no public exposure and no regulated data does not need three spokes and a firewalled hub on day one — that is over-engineering, and the cost and complexity will not pay for themselves. The signals that you have crossed into needing hub-spoke are concrete: you have something exposed to the internet, and you have something sensitive enough that a breach is reportable or business-ending, and you expect to keep adding workloads. The hospital ticks all three, which is why it is a textbook case. If you tick none, a well-configured single network with good subnet-level rules is a perfectly responsible starting point — just design the IP plan as if a hub is coming, so the upgrade is additive rather than a rebuild.
The shape of the win
Six months after the hospital adopts hub-spoke, the security lead’s original question has a real answer. If the public appointment portal gets compromised, the attacker is trapped in Spoke A — they have no network path to the patient records in Spoke B, because the topology never gave them one and the hub firewall denies and logs every probe toward it. The Moodle training server, the billing system, and the records database each sit behind their own wall. Identity through Entra ID or Okta decides who may even reach the management plane, HashiCorp Vault keeps the database password out of the application’s code, CrowdStrike Falcon watches inside each spoke, Wiz proves the walls still stand, and ServiceNow records every door that was ever opened. None of that required exotic technology — it required taking one flat network and giving it internal walls, putting the shared services and the firewall in a central hub, isolating each workload in its own spoke, and forcing every crossing through one inspected, logged chokepoint. That is the entire idea of hub-spoke segmentation, and it is the first architecture pattern worth getting right, because nearly every other piece of a serious cloud platform is built on top of it.