Very few organisations live entirely in the cloud. There is a head office, a few branches or depots, perhaps a data centre or colocation rack that still runs something important, and one or more cloud networks. Users and systems in all of these places need to reach each other, privately and predictably, and keep doing so when a line goes down.
This part covers the connection options, how routes are exchanged between them, why connecting networks directly to each other stops scaling quickly, and what South African conditions add to the picture: long distances, carrier dependencies and the power cuts that every network design here has to assume.
Hadeda Freight is fictional, and its address ranges and figures are illustrative. Hadeda has a head office in Midrand (10.10.0.0/16), depots in Durban (10.11.0.0/20) and Gqeberha (10.11.16.0/20), a small recovery footprint in a Cape Town colocation facility (10.12.0.0/16), and its cloud estate in a Johannesburg region (10.40.0.0/14).
The connection options
| Option | What it provides | Typical use | Main limitation |
|---|---|---|---|
| Site-to-site VPN | Encrypted tunnel over the internet | Quick setup, backup path, moderate traffic | Internet performance varies |
| Client VPN or zero trust network access | User-to-resource access | Remote and mobile staff | Must integrate identity and device checks |
| Private circuit | Dedicated or partner connectivity via a carrier | Predictable enterprise hybrid traffic | Lead time, cost and provider dependencies |
| VPC or VNet peering | Private routing between two virtual networks | A small number of direct relationships | Non-transitive; a mesh grows badly |
| Transit hub | Central routing between many networks | Larger cloud and hybrid estates | Central blast radius if poorly designed |
| Private service publication | Access to one service, not a whole network | Partner and platform services | Needs a compatible service model and DNS |
The first question is not which product to buy. It is what needs to reach what. A remote engineer who needs one admin console needs user-to-resource access, not a tunnel into the whole network. A partner who needs one API needs that API published privately (Part 12 shows the pattern), not a route to every Hadeda subnet. Choosing the narrowest connection that does the job is the same least-privilege thinking as Part 5, applied to whole networks.
VPN versus private circuit
A site-to-site VPN builds an encrypted IPsec tunnel across the public internet between a site's router or firewall and the cloud provider's VPN gateway. It is quick to set up and cheap, and its performance is whatever the internet path gives it on the day.
A private circuit carries traffic over a carrier's network into the cloud provider's edge without crossing the public internet: Direct Connect on AWS, ExpressRoute on Azure, Cloud Interconnect on Google Cloud, Direct Connect on Huawei Cloud. It offers more predictable latency and throughput, at the cost of lead time, contracts and dependency on the carrier. In South Africa these circuits usually meet the cloud providers in carrier-neutral data centres in Johannesburg and Cape Town, such as those run by Teraco and Africa Data Centres, so the carrier's route from your building to that facility is part of the design.
One misunderstanding is worth correcting early: private does not mean encrypted. A private circuit keeps traffic off the internet; it does not encrypt it. If your policy requires encryption in transit, and for personal information it usually should, run encryption over the circuit as well, either at the network layer or in the application.
For a South African organisation, assess the whole route, not just the cloud end: the access circuit to your building, the carrier's network, the exchange or colocation facility, the provider's edge, the cloud region, and the failover path. Then add power. A depot router with no backup power turns every round of load-shedding into a network outage, however good the circuit is. Hadeda's depots keep their routers and scanners' access points on UPS and generator, and that is as much a network design decision as the choice of carrier.
BGP in plain language
When networks connect, each side needs to know which address ranges the other can reach. You can type static routes by hand, but they do not adapt when a path fails. Border Gateway Protocol (BGP) lets routers tell each other which address prefixes they can reach, and choose between paths according to policy.
In Hadeda's design, the Midrand router announces the whole office range, 10.10.0.0/16, over a site-to-site VPN. Its busiest subnet, 10.10.8.0/24, where the operations and reporting teams sit, is also announced over a private circuit. The cloud side announces 10.40.0.0/14 back. Because routers prefer the most specific route (Part 3 called this longest-prefix match), traffic for 10.10.8.0/24 uses the circuit while it is up. If the circuit fails, the /24 is withdrawn, the /16 over the VPN still covers those addresses, and traffic moves across without anyone editing a route table.
BGP knows nothing about applications. It knows which prefixes are reachable according to the announcements it has received. So it will happily follow a route that someone announced by mistake. Two controls are essential:
- Route filtering: each side accepts only the prefixes it expects from the other. The cloud accepts
10.10.0.0/16and10.10.8.0/24from Midrand, not a default route or someone else's ranges. - Maximum-prefix limits: a session that suddenly announces thousands of routes is shut down rather than allowed to flood the estate.
A wrong route announcement does not break one application. It can redirect traffic for the whole estate.
Peering versus transit
Peering connects two virtual networks directly, so they route to each other privately. It is simple and fast for a few relationships. It is also non-transitive on all three major hyperscalers at the time of writing (October 2026): if production peers with shared services, and shared services peers with non-production, production cannot reach non-production through shared services. Each pair that must talk needs its own peering.
That is where the arithmetic bites. To fully connect n networks with direct peerings you need n(n-1)/2 of them.
Three networks need 3 peerings. Ten need 45. Fifty need 1,225, each one to configure, route, secure and audit, and each one a place for an inconsistency to hide.
A transit hub changes the shape. Each network attaches once to a central routing service (a hub network with a firewall, or a managed service such as AWS Transit Gateway, Azure Virtual WAN, Google Cloud Network Connectivity Center or Huawei Cloud Enterprise Router), and the hub routes between them according to policy. Fifty networks need fifty attachments. The hub is also the natural place to inspect traffic between environments and to terminate hybrid connections.
The price is concentration. The hub carries everything, so a mistake in its route tables or a capacity limit in its firewall affects every network at once. Part 9 is about designing and operating that hub so its blast radius is understood and owned.
Hadeda's connectivity, and the backup that was not
Hadeda's design lands every site on one connectivity hub, which lives in the shared services network (10.42.0.0/16) alongside the DNS resolvers and management access:
- Midrand uses a site-to-site IPsec VPN for the whole office, plus a private circuit for its busiest subnet. Either path can carry that subnet if the other fails.
- Durban and Gqeberha send scanner events to the Track API's private address over site-to-site VPN on business fibre, with an LTE router for when the fibre drops. Scan events are small, so LTE capacity is enough to keep a depot working.
- The Cape Town colocation site connects over its own VPN, which carries database replication for recovery.
A backup needs routes, not just a link
One Saturday, Durban's fibre went down. The LTE router came up exactly as designed, and the scanners still could not post a single event. The LTE line had internet access, but no VPN tunnel and no route to the Track API's private address. The link had failed over; the routing had not. Scans queued on the handhelds until the fibre returned on Monday.
The fix was to bring up the depot's VPN tunnel over the LTE line as well, announce the depot range over it, and add a monthly test that unplugs the fibre and checks that a scan reaches the API. A backup path is a link, a tunnel, routes in both directions and DNS that still resolves. Test the whole of it, not the light on the router.
Two paths in one duct
On paper, Midrand had two independent paths. In practice, the first design review found that the circuit and the internet line carrying the VPN were from different providers but entered the building through the same duct from the same street. One cable cut during roadworks would have taken out both. The backup existed in the contract and not in the ground.
This is the most common hybrid connectivity failure, and it is why physical diversity has to be proven rather than assumed: ask carriers for route documentation, check building entry points, and test failover by actually disconnecting the primary path during an agreed window.
The acquisition that overlapped
About eighteen months after Track went live, Hadeda acquired a small courier business, Swift Couriers (also fictional). Swift's cloud network turned out to use 10.40.0.0/16, exactly the range of Hadeda's production network, so the two cannot simply be routed together. Part 2 explained why. Rather than translate addresses across the whole estate, Hadeda consumes the one thing it needs, Swift's billing API, through a private endpoint, with no route exchange between the networks at all. Swift's network stays separate and untrusted, and renumbering it is scheduled for its next platform refresh. The narrowest connection was also the quickest to deliver and the cheapest to undo.
Connection checklist
- Non-overlapping IPv4 and IPv6 ranges across every site and network.
- Forward and return routes, for every path, including failover.
- Advertised and accepted BGP prefixes, with filters and maximum-prefix limits.
- Bandwidth, latency and packet-loss requirements per flow.
- Encryption requirements, including over private circuits.
- DNS resolution in both directions (Part 6 showed what happens without it).
- Redundant devices, circuits, carriers and physical paths, with power to match.
- Monitoring at the site, carrier and cloud layers.
- Defined failure behaviour and tested runbooks.
- Data transfer, port and appliance processing costs.
Common mistakes
- Assuming two providers means two physical paths. They may share a duct, a pole route or an exchange.
- Treating a private circuit as encrypted. It keeps traffic off the internet; it does not protect it.
- Accepting any route a peer announces. One bad announcement can redirect the estate.
- Peering every network to every other. A mesh of fifty is 1,225 relationships nobody can audit.
- Expecting peering to be transitive. Traffic through a middle network needs a hub, not a chain of peerings.
- Backup links with no tunnel or routes behind them. The link fails over and the traffic still has nowhere to go.
- Backup paths that are never tested. The first real failover becomes the test.
- Forgetting power at the site. The router is down during load-shedding even when the fibre is fine.
Try it yourself
Design connectivity for Hadeda's Midrand office, a Cape Town recovery site and a workload in the Johannesburg cloud region. Include primary and backup paths, which routes each side announces and accepts, how DNS resolves in both directions, who owns the routing configuration, and the test you would use to prove the two Midrand paths are physically diverse.
Test your understanding
Production peers with shared services, and shared services peers with non-production. Can production reach non-production?
Answer: Not through those peerings. Peering is non-transitive, so the pair needs its own connection, or both need to attach to a transit hub that routes between them.
How many direct peerings does a full mesh of twelve networks need?
Answer: 12 × 11 / 2 = 66.
Is traffic on a private circuit encrypted?
Answer: Not by default. The circuit keeps traffic off the public internet. Encryption has to be added at the network or application layer if required.
What do route filters and maximum-prefix limits protect against?
Answer: A peer announcing routes it should not, by mistake or otherwise, which could redirect or black-hole traffic for the whole estate.
What to take from this part
Choose the narrowest connection that does the job. One service, one user or one network, not everything.
Private is not encrypted. Add encryption over circuits when the data requires it.
BGP trusts what it is told. Filter what you accept and cap how much.
Meshes do not scale; hubs concentrate risk. Choose the hub, then own its blast radius.
Prove physical diversity, and power the site. A backup that shares a duct is not a backup.
Next in the series: Enterprise landing-zone networking: shared foundations with clear ownership.
How CloudNala can help
We assess hybrid connectivity from the building to the cloud region: which paths exist, whether backups are physically diverse, which routes are announced and accepted, how DNS behaves in each direction, and how sites ride through power and fibre outages. Where an estate has grown a mesh of peerings, we plan the move to a transit hub with ownership and inspection designed in.
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