Ask a team whether their service is highly available and the answer is often about servers: "It runs in three availability zones." That is a good start and a dangerous place to stop. The same service can still fail because it depends on one DNS resolver, one firewall, one certificate, one database, one identity provider or one office circuit. Availability is not a property of the servers. It is a property of the whole path a user's request travels, and the path fails at its weakest point.
This part covers the expert-level work of designing that path for the bad day: mapping every dependency, choosing between zones and regions honestly, collecting the evidence that tells you what broke, understanding the performance terms that get confused in incident calls, and following the money, because network cost is often where cloud bills surprise people most.
Availability is a property of the path
Start with a user journey, not with infrastructure. For Hadeda Freight, the fictional freight company we have followed through this series, the critical journey is a customer checking where a shipment is on Track. Hadeda Freight is fictional, and its address ranges and figures are illustrative. Track's target is 99.9% monthly availability, which allows roughly 43 minutes of downtime a month.
Then map every synchronous dependency: everything that must respond before the customer sees an answer.
For each box and each line, ask six questions:
- What can fail?
- How is the failure detected?
- Does traffic fail over automatically, or does someone have to act?
- Is the data consistent after failover?
- Does the secondary path have enough capacity to carry the full load?
- When was this last tested?
The map usually reveals something uncomfortable. Hadeda's application tier was spread across three zones, each sized to carry half of peak traffic so that losing one zone still leaves enough capacity. But the external payment provider and the identity provider were single dependencies outside its control. The answer was not to make them redundant (Hadeda cannot) but to design how Track behaves when they are slow or down: tracking pages still load, payments queue with a clear message, and sign-in sessions last long enough to ride out a short identity outage.
Zones and regions
Availability zones are separate data centres, or groups of data centres, within one cloud region, with independent power, cooling and networking. Spreading a workload across zones protects against a data-centre-scale failure. Regions are separate geographic areas, which protect against a failure that takes out a whole area. A second zone is not a disaster-recovery region.
South Africa has a specific constraint here. At the time of writing (October 2026), the hyperscale providers' main South African regions each have three availability zones: AWS Africa (Cape Town), Azure South Africa North in Johannesburg and Google Cloud's Johannesburg region. But a second local region for disaster recovery is not available on every provider. Azure has a South Africa West region in Cape Town, but it has no availability zones and access is restricted, granted on request for disaster-recovery-type scenarios. AWS and Google Cloud each have one South African region. Oracle has one Johannesburg region with a single availability domain.
So a South African design must answer the disaster-recovery question explicitly, and there are several honest answers:
- Backup and restore into another zone or another local facility, accepting a longer recovery time.
- Degraded local operation, where the most important functions keep working when the cloud region is unavailable.
- A second provider or a local data centre as the recovery location.
- An approved region outside South Africa, which raises data-transfer cost, latency, contractual and regulatory questions, including how POPIA's conditions for cross-border transfer are met. That is a question for your legal and privacy advisers, not your network team.
Hadeda's targets for Track are a recovery time (RTO) of four hours and a maximum data loss (RPO) of fifteen minutes. That is achievable with continuous database replication to the Cape Town colocation facility and a tested runbook to bring Track up there. It is not achievable by hoping the region does not fail.
Observe the network
When something does fail, the team needs evidence, quickly. Useful network evidence includes:
- Flow logs, showing which connections were accepted and rejected.
- Firewall, WAF, gateway and load balancer logs.
- DNS query logs and resolver health.
- Route and BGP state, including what was advertised and when it changed.
- VPN tunnel and private-circuit health.
- Packet loss, latency, jitter and throughput measurements.
- Synthetic transactions run from the places users actually are, for Hadeda including the depots.
- Application traces showing how long each network call took.
- Configuration changes and policy violations, because many outages start with a change.
Each kind of evidence answers a different question. Metrics tell you latency rose. Logs may identify a denied flow. Traces show which dependency slowed down. Packet capture shows what actually crossed an interface. Start with the least invasive evidence that answers the question and move deeper only when you need to. Packet capture on a production interface is powerful, expensive to store and may capture personal information, so it should not be the first tool you reach for.
Latency, bandwidth and packet loss
These terms get used loosely in incident calls, and the confusion leads to wrong fixes:
- Latency is the time data takes to travel, usually measured as round-trip time.
- Bandwidth is the carrying capacity of a link.
- Throughput is the useful data rate actually achieved.
- Packet loss is the proportion of packets that do not arrive.
- Jitter is variation in delay, which matters for voice and real-time traffic.
The most expensive misunderstanding is that more bandwidth fixes slowness. It often does not. Suppose a reporting application in Midrand makes 200 sequential database calls to a cloud region, each needing a round trip. Doubling the circuit's bandwidth leaves every one of those round trips exactly as long. The fix is to reduce the round trips (batch the queries, or move the application next to its database), not to buy a bigger pipe.
Follow the money: network cost
Cloud network charges are spread across many small meters, which is why they are easy to miss in a design review. They often include:
- internet egress (data leaving the cloud);
- traffic between regions;
- traffic between availability zones;
- NAT gateway processing;
- firewall and security appliance processing;
- load balancer hours and data units;
- private endpoints, per hour and per gigabyte;
- public IPv4 addresses, which now cost money on the major providers;
- VPN and private connectivity ports;
- carrier cross-connects in the colocation facility;
- duplicated inspection, where one byte is billed several times.
That last item deserves a picture. Here is one of Hadeda's early designs for nightly backups, before review.
None of the four meters is large on its own, and none of them appears on a compute quote. Together, on a backup stream measured in terabytes, they became one of the larger lines on Hadeda's monthly bill. The redesign wrote backups through a private endpoint to storage in the same region, which removed the NAT hop and the detour through a firewall in another zone, and left the copy to the second region to the storage service's own replication. The inter-region meter remains, because a disaster-recovery copy has to cross a region boundary somewhere. The other three were design choices nobody had made deliberately. Draw the billable path for every high-volume flow before the architecture is approved. Our cloud cost audit checklist covers the wider picture.
Failure exercises
A recovery plan that has never been exercised is a hope. Test realistic events, starting with the ones that are cheapest to simulate:
- one availability zone becomes unavailable;
- the primary VPN tunnel fails;
- DNS returns an incorrect or stale record;
- a certificate expires;
- a route is withdrawn, or another network advertises one it should not;
- the firewall reaches its capacity limit;
- the private circuit reports "up" while application packets are being lost;
- a cloud service's public endpoint is disabled before its private DNS is ready;
- a dependency moves to a different IP range.
For each exercise, record how long recovery took, how much data was lost, which steps were manual, which monitoring gaps appeared and what will be fixed. Hadeda runs one exercise a month in non-production and two a year against production during a planned window. The first exercises followed the weekend when the Durban depot's fibre failed and the LTE backup had no route to the API's private address. The route was fixed, and the next depot exercise, a simulated fibre cut during load-shedding (the UPS and generator kept the routers up, as designed), proved the LTE path could now carry scan events. It also found that name resolution did not follow the traffic onto the backup path, which became the next fix.
Common mistakes
- Equating three zones with high availability. The shared DNS, identity and external dependencies still fail as single points.
- Assuming a second local region exists. On several providers it does not, or access is restricted.
- Buying bandwidth to fix latency. Round trips do not get shorter on a wider link.
- Costing compute but not the path. Zone crossings, NAT, inspection and region transfer add up per gigabyte.
- Writing runbooks nobody has run. The first real failure becomes the test.
Try it yourself
Pick Track's shipment-lookup transaction. Draw its dependency map, then define one service-level indicator each for DNS, network reachability, edge delivery and backend calls, for example "99.95% of DNS queries for api.hadeda.example from the depots resolve within 100ms". Then write one failure test for each of those four layers, including what you expect to happen and how you will know.
Test your understanding
Track runs in three availability zones. Name two dependencies that could still take it down.
Answer: Any single dependency on the path, for example the DNS service, the identity provider, the external payment provider or a single certificate.
Why can't Hadeda assume it will fail over to a second South African region?
Answer: Not every provider has a second local region, and where one exists it may be restricted. The disaster-recovery approach must be chosen and documented explicitly.
Doubling a circuit's bandwidth did not speed up a chatty reporting application. Why not?
Answer: The application was limited by the number of sequential round trips, which is latency. Bandwidth does not change the length of a round trip.
Why might one gigabyte of backup data be billed four times?
Answer: Each boundary on its path can carry its own meter: crossing zones, firewall processing, NAT processing and transfer between regions.
What to take from this part
Map the path, not the servers. Every synchronous dependency is a place to fail.
Make the disaster-recovery answer explicit. In South Africa, a second local region cannot be assumed.
Collect evidence before you need it. Flow logs, DNS logs, synthetic checks and traces turn guesses into diagnoses.
Fix latency with fewer round trips. Bandwidth solves a different problem.
Draw the billable path. High-volume flows should be costed boundary by boundary before approval.
Next in the series: Expert cloud network architecture: four patterns and a decision method.
How CloudNala can help
We help teams find the single points of failure hiding behind multi-zone deployments, choose an honest disaster-recovery approach for South African constraints, put the right network evidence in place before the next incident, and trace high-volume flows boundary by boundary so the network bill stops being a surprise.
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