The first workload in a new cloud account is usually built well. Somebody careful sets up the network, thinks about the firewall and documents the address range. The trouble starts with workload number six, built by a different team under deadline pressure, which copies the first network's settings, opens a port "for now" and peers directly to whatever it needs. By workload twenty there is no design, only an accumulation.
A landing zone is the answer to that accumulation. It sets up account or subscription structure, identity, policy, logging, security, networking and automation before many workloads arrive, so that the safe path is also the easiest one to follow. This part covers the networking half of that foundation.
It also marks the move in this series from building networks to designing shared ones. Parts 1 to 8 dealt with how traffic gets from one place to another. From here on, the harder questions are organisational: who owns a shared component, who may change it, and who gets called when it breaks.
The real question is not the topology
Architecture discussions about landing zones often start with "hub and spoke or mesh?" That is a reasonable question, asked too early. The questions that decide the design are these:
- Which capabilities must be shared, so they exist once rather than twenty times?
- Which controls must be central, because a mistake in one workload would affect everyone?
- What may product teams change themselves, and what needs approval?
- Who operates each shared part, around the clock, including when it fails?
Answer those and the topology mostly follows. Skip them and a beautifully drawn hub becomes a shared component nobody feels responsible for.
Hub and spoke, made concrete
We are still following Hadeda Freight, a South African freight company building Track, its shipment-tracking portal and API. Hadeda Freight is fictional, and its address ranges and figures are illustrative. Hadeda has a platform team of five and three product teams (Track, Billing and Depot Ops), with a small shared security and operations team.
Hadeda's hub sits in the shared-services range, 10.42.0.0/16, and holds the things every workload needs and no workload should build for itself:
- Hybrid gateways for the Midrand head office, the Durban and Gqeberha depots and the Cape Town disaster-recovery colocation site (the connection options came from Part 8).
- A central firewall and secure internet egress, so outbound traffic leaves through one inspected, logged path.
- DNS resolvers that forward between the office's DNS and the cloud's private zones, including
internal.hadeda.example. - Administrative access: a managed bastion or identity-aware proxy, so no workload needs a public management port.
- Network observability: flow logs, firewall logs and the tooling that queries them.
Workloads live in spokes. Production is 10.40.0.0/16 and non-production 10.41.0.0/16, and each attaches to the hub. Track, Billing and Depot Ops share the production spoke, separated by subnets and security groups, which suits three teams of this size. Spokes do not connect directly to each other, so nothing in non-production can reach production. Swift Couriers, the courier business Hadeda acquired, stays outside this structure altogether: its network overlaps 10.40.0.0/16 and is treated as untrusted, so Hadeda consumes its billing API through a private endpoint with no routes exchanged. That approach becomes a pattern of its own in Part 12.
The reserved range, 10.43.0.0/16, is the cheapest thing in the diagram. It costs nothing today and saves a renumbering project the day Hadeda opens a second region or makes another acquisition. The register that tracks all of this is still a spreadsheet the platform team owns, with IPAM tooling planned. That is fine at Hadeda's size, provided there is exactly one register and one owner.
Central inspection, distributed control, or both
Here is the design decision with the most money and risk attached to it.
Central inspection sends traffic through firewalls in the hub. It gives consistent policy, one place to collect evidence and one team that understands it. It also adds cost (firewalls charge per hour and per gigabyte processed), latency (traffic detours through the hub), routing complexity and a large blast radius: if the central firewall fails or is misconfigured, everything behind it is affected.
Distributed, cloud-native controls put security groups and network policies right next to each workload. Policy is close to what it protects, nothing hairpins through the hub, and one team's mistake stays in its own spoke. The price is that this only works with strong automation and governance. Fifty teams writing their own rules by hand produce fifty interpretations of the policy.
Most mature estates combine the two, roughly like this:
- Central inspection for internet egress and partner traffic, where consistency and evidence matter most.
- Cloud-native workload controls for east-west traffic between services inside a spoke.
- Application-layer authorisation at APIs and services, because no network control knows whether a user may see a particular shipment.
- Policy as code that prevents prohibited configurations, such as a public IP on a database subnet, from being deployed at all.
Hadeda follows this split. Depot scan events and customer traffic are inspected at the edge; Track's internal services are governed by security groups the Track team keeps as code in its own repository; and the pipeline rejects any rule that opens 0.0.0.0/0 on anything except the public gateway, along with any change that adds an internet route to a data subnet.
Route intent, and the asymmetric routing trap
A hub only inspects traffic that actually passes through it. So write down route intent: which paths must pass through inspection, in which direction. For Hadeda: "all traffic from any spoke to the internet goes through the hub firewall", and "traffic between production and non-production is denied, and would be inspected if ever allowed".
Then verify that routing implements that intent in both directions. The classic failure is asymmetric routing. A request from the Midrand office to a production server goes through the hub firewall, but the server's reply takes a more specific route straight back over the hybrid link. A stateful firewall sees only half of the conversation, decides the traffic is illegitimate and drops it. The symptom is a connection that half works, and it can take a long time to diagnose.
The fix is not a better diagram. Keep route tables, propagated routes, firewall policy and DNS behaviour as configuration in code, and test it. A flow test that sends real traffic from the office to production and checks that the reply arrives proves route intent. A diagram only asserts it.
Shared responsibility inside the organisation
Cloud providers talk about the shared responsibility model between themselves and their customers. Inside a landing zone there is a second one, between your own teams, and it needs writing down just as carefully.
The pattern in Hadeda's grid is deliberate. The platform team owns what is shared: the address register, the hub, the hybrid links and the DNS resolvers. Product teams own the detail of their own workloads: the precise flows in their security groups, their own DNS records and, always, application authorisation. Security and operations assure both, through monitoring, audit and testing, without becoming the team that has to approve every change.
The row that most often goes wrong is DNS. Platform teams run resolvers and delegate zones; workload teams create records. If nobody owns cleanup, private endpoint records pile up for services that no longer exist, and one day a new service inherits a stale name.
Self-service, checked, approved or prohibited
A responsibility grid says who owns what. The next question is how a change actually happens. A useful landing zone sorts network changes into four classes:
| Class | Examples at Hadeda | How it happens |
|---|---|---|
| Self-service | A new security group rule between two Track services; a DNS record in Track's own zone | Product team merges it; pipeline applies it |
| Automatically checked | A new subnet from the team's allocated range; a new private endpoint | Pipeline validates against policy, then applies |
| Manually approved | A new route to the hybrid link; a new internet egress destination | Platform team reviews the request |
| Prohibited | A public IP on a data subnet; peering between two spokes; a rule allowing 0.0.0.0/0 inbound to a workload | Policy as code blocks it outright |
The aim is to push as many changes as possible into the first two rows. A landing zone in which every change needs a ticket to the platform team is not a foundation. It is a queue, and teams under pressure find ways around queues.
When not to build a heavyweight hub
Everything above suits an organisation like Hadeda, with several teams, hybrid sites and regulated data. It does not suit everyone.
A small startup with one web application probably needs a single well-designed virtual network, managed ingress, private data services and clear egress control, not an enterprise firewall estate with a hub it has to staff. A central firewall pair can cost more per month than the whole application. Match the architecture to the risk and scale you actually have.
What a small organisation should do is build seams for growth: allocate addresses from a planned range rather than the provider default, keep network configuration in code from the start, and avoid choices that are hard to undo, such as overlapping ranges. Then introduce a hub when a real requirement arrives, such as a second team, a hybrid link or a regulator's question.
Common mistakes
- Building the hub before deciding who operates it. A shared firewall with no on-call owner fails at 2am with nobody to call.
- Letting spokes peer directly "just this once". Each shortcut bypasses inspection and turns the hub-and-spoke design back into an unmanaged mesh.
- Documenting route intent only in a diagram. Asymmetric routes are found by tests, not by reviewing pictures.
- Making every change a manual approval. Teams route around slow processes, usually by over-permitting.
- Copying an enterprise reference architecture into a five-person company. You pay for components and operating effort with no matching risk to reduce.
Try it yourself
Take Hadeda's platform team and its three product teams. Draw up a responsibility matrix for the network, using the grid above as a starting point, and add rows for internet egress allowlists, flow-log retention and private endpoint DNS records. Then sort ten realistic network changes into the four classes: self-service, automatically checked, manually approved and prohibited. For each one in the "manually approved" class, ask whether a policy check could move it to "automatically checked".
Test your understanding
Why does Hadeda keep a reserved /16 that nothing uses?
Answer: Because the address plan is the hardest part of the network to change later. A reserved range absorbs an acquisition, a new region or a new environment without renumbering or overlap.
A user in Midrand can open a connection to a production server, but it hangs after the first few packets. What should you suspect first?
Answer: Asymmetric routing. The request passes through the stateful hub firewall while the reply returns by a different route, so the firewall sees half the conversation and drops it.
Who should own the detailed rules in Track's security groups, and why not the platform team?
Answer: The Track team, because they know which flows the application needs. The platform team sets guardrails and policy checks, and security and operations audit the result.
When is a hub the wrong answer?
Answer: When there is one small workload, no hybrid connectivity and no team to operate it. Build seams for growth instead and add the hub when a real requirement arrives.
What to take from this part
Decide ownership before topology. Hub or mesh is the easier question; who operates each shared part is the one that matters.
Share capabilities once, in the hub. Gateways, egress, DNS and admin access should not be rebuilt in every spoke.
Combine central and distributed control. Inspect north-south traffic centrally, govern east-west traffic near the workload, and authorise in the application.
Prove route intent with tests. A diagram is a claim; a flow test that checks the return path is evidence.
Make the safe change the fast change. Push as many changes as possible into self-service and automated checks.
Next in the series: Zero trust, segmentation and service networking.
How CloudNala can help
We help platform teams design landing-zone networking around ownership as well as topology: what belongs in the hub, which controls are central, how route intent is written down and tested, and which changes can safely become self-service. Where a full hub is more than the organisation needs, we say so, and help it build the seams that let it grow into one later.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Network Review or write to us at consult@cloudnala.co.za