Cloud networking is the system of roads, addresses, gates, traffic rules and delivery services that lets users, applications and data reach one another safely. That sentence is simple. The implementation is not. Opening one web page can involve DNS, an internet service provider, several routers, a firewall, a load balancer, an application, a database, and a response that travels back through the same path or a different one.
In the cloud, most of those parts are software. They can be created in minutes, which is exactly what makes them useful, and exactly what lets a mistake spread across an estate before anyone notices. A firewall rule that once needed a change request and a technician now takes one line of code and one approval that nobody reads closely.
This twelve-part series builds the mental model one layer at a time. It is not a tour of AWS, Azure, Google Cloud or Huawei Cloud product names. It is about the networking problem underneath the products, because once that is clear, provider terminology becomes translation rather than mystery. Parts 1 to 4 are the foundations, 5 to 8 move into practical cloud design, and 9 to 12 cover the decisions expected of senior engineers and architects. The material is educational: every range, port and target in it must be adapted to your real workload and checked against current provider documentation before anything is built.
The running example
Every part uses the same company so the pieces join up. Hadeda Freight is fictional, and its address ranges and figures are illustrative.
Hadeda is a South African freight business of about 600 people, with a head office in Midrand, depots in Durban and Gqeberha, and a small disaster-recovery footprint in a Cape Town colocation facility. It is building Track, a customer portal and public API that shows where a shipment is, at track.hadeda.example. Customers use it from browsers, drivers use a mobile app, depot scanners post scan events to it, and it calls a payment provider and an SMS service. Customer names, phone numbers and delivery addresses pass through it, so POPIA applies.
By Part 12 we will have designed Track's network end to end. In this part we only need one thing from it: a customer opening the tracking page.
Start with a parcel
Imagine sending a parcel from Johannesburg to Cape Town. It needs a destination address, a return address, a delivery method, and rules about what the courier may carry. It passes through several distribution centres, and at each one somebody reads just enough of the label to decide where it goes next. Nobody opens it.
A network packet works the same way. It is a small unit of data with addressing information on the outside. Each router along the path reads the destination, chooses the next hop and passes it on. A large file or web page is split into many packets, which may take different routes, and the receiving system puts them back together.
Two details of the parcel analogy matter more than they first appear. First, the return address: a reply has to find its way back, and in networking the return path is a separate journey that can fail on its own. Second, the label is not the contents: a router knows where a packet is going, not whether the person sending it is allowed to do what they are asking. Both ideas come back repeatedly in this series.
The vocabulary you actually need
| Concept | Plain meaning | Example at Hadeda |
|---|---|---|
| Host or device | A participant on the network | A laptop in Midrand, a depot scanner, a cloud VM |
| IP address | A numeric network address | 10.40.20.15 |
| Packet | A small unit of transmitted data | One piece of an HTTPS request |
| Protocol | Agreed rules for a conversation | TCP, UDP, ICMP, HTTP, TLS |
| Port | A numbered entrance to a service on a host | HTTPS normally listens on TCP 443 |
| Router | Chooses the next network path | A cloud route table plus the provider's routing |
| Firewall | Allows or denies defined flows | Permit HTTPS from the load balancer to the app |
| DNS | Turns names into addresses | track.hadeda.example to an IP address |
If an IP address is the building, the port is the door. A server can run several services at one address, and the port tells the operating system which one should receive the packet. That is why "the server is reachable" and "the service is reachable" are two different claims.
Layers without the textbook fog
The OSI model has seven layers. It is a useful vocabulary for troubleshooting, but everyday cloud work groups them more simply:
| Practical layer | What it is concerned with | Typical examples |
|---|---|---|
| Link | Moving data across the local medium | Ethernet, Wi-Fi, a virtual network interface |
| Network (Layer 3) | Addressing and routing between networks | IPv4, IPv6, IP routes |
| Transport (Layer 4) | The conversation between two programs | TCP, UDP, ports |
| Application (Layer 7) | What the request actually means | HTTP, DNS, SMTP, gRPC |
You will hear "Layer 4" and "Layer 7" constantly from Part 5 onwards. A Layer 4 device sees addresses, protocols and ports. A Layer 7 device understands the request itself: the hostname, the path, the headers. That difference decides what a firewall or load balancer can and cannot do for you.
TCP sets up a connection, numbers the data, retransmits what goes missing and delivers it in order. That reliability costs a little time, which is why it carries web pages, APIs and database traffic. UDP sends datagrams with no delivery guarantee and less overhead, which suits DNS lookups, voice, video and telemetry, where a late packet is worthless anyway. HTTP/3 is an interesting middle case: it runs over QUIC, which uses UDP underneath and builds its own reliability on top. So "web traffic is TCP" is no longer always true, and a firewall that only permits TCP 443 will quietly push modern browsers back to older HTTP versions.
Follow one request
Here is what happens when a customer opens Track to check on a delivery.
The browser asks a DNS resolver for track.hadeda.example and gets back a public IP address. It opens an HTTPS connection to that address on TCP 443, which lands on Hadeda's load balancer. The load balancer forwards the permitted request to an application instance. The application queries the database on the database port and gets rows back. The response then travels back the way it came.
The important thing is what does not happen. The customer's browser never connects to the database. There are at least four separate conversations here, each with its own source, destination, protocol, port and security rule. When someone says "Track is slow", the fault could be on any one of them while the others are perfectly healthy. Good networking work starts by refusing to treat the whole chain as one thing.
The five questions behind almost every network fault
Whatever the size of the estate, the same five questions find most problems:
- What name or address is the client trying to reach?
- To which IP address does that name resolve, for this client?
- Which route will carry the packet there, and which will carry the reply back?
- Which protocol and port does the service use?
- Which control permits or denies the flow?
They look basic, and they are. What changes with seniority is not the questions but the scale at which you ask them: across three clouds, a hybrid link and forty teams' worth of firewall rules. Notice that question 2 says "for this client". In Part 3 we will see how the same name can legitimately return different addresses to an employee in Midrand and a customer on their phone, and why that single fact explains so many "it works for me" tickets.
Consider a Monday morning at Hadeda. The Durban depot reports that scanners cannot post scan events, while Midrand staff say Track is fine. Walking the five questions: the scanners use the same API name (question 1 is fine); the depot's resolver returns the right address (question 2 is fine); but the depot's fibre line went down over the weekend and the LTE backup does not have a route to the API's private address (question 3). Nothing in the cloud changed. The answer was a route on the depot's side, found in ten minutes because nobody started by restarting servers.
Encryption is not authorisation
One more idea belongs in the foundations because it is so often confused. TLS, the "S" in HTTPS, encrypts traffic and proves that the server holds a certificate for the name you asked for. It does not tell the server that you are allowed to do what you are asking. A perfectly encrypted request from a compromised account is still a request from a compromised account.
Network controls, encryption and application authorisation are three different layers of defence. This series spends most of its time on the first two, but it will keep pointing at the third, because an open port never grants business permission. The application still has to decide whether this caller may see this customer's shipment.
Common mistakes
- Saying "the network is down" before identifying the failed hop. It sends everyone looking everywhere and wastes the first hour of an incident.
- Treating a successful ping as proof the application works. Ping uses ICMP; Track uses HTTPS on TCP 443. They are different flows, and many networks block ICMP anyway.
- Opening every port because the required one is unknown. It turns an hour of investigation into a permanent exposure nobody remembers to close.
- Checking the forward path and ignoring the return path. The request arrives, the reply takes a route that is blocked or goes somewhere else, and the symptom looks like a timeout.
- Treating encryption as proof the other party is authorised. TLS protects the conversation; it does not vouch for the person having it.
Try it yourself
Open your browser's developer tools on the Network tab and load any website you use at work. For the main page request, note the hostname, the protocol (HTTP/1.1, HTTP/2 or HTTP/3), the remote address and port, the response status and the time taken. Then run nslookup or dig on the same hostname from your laptop and from a phone hotspot, and compare the addresses you get back. If they differ, you have just seen why question 2 says "for this client".
nslookup track.hadeda.example
dig +short track.hadeda.example
(The Hadeda names will not resolve, since .example is reserved for documentation. Use a real site you are permitted to test.)
Test your understanding
A colleague says the server is reachable because ping works. Why is that not enough to say Track works?
Answer: Ping tests ICMP to the host's address. Track needs HTTPS on TCP 443 to reach the load balancer, then separate flows to the application and database. Any of those can be blocked while ping succeeds.
Why does the customer's browser never need a route to the database?
Answer: Because it only talks to the load balancer. The application makes its own, separate connection to the database, so the database can stay private and unreachable from the internet.
Which of the five questions would you ask first if staff in one office can reach a service but staff in another cannot?
Answer: Question 2: what address does the name resolve to for each office. Different resolvers giving different answers is the most common cause of that pattern.
What does HTTP/3 change about the assumption that web traffic is TCP?
Answer: HTTP/3 runs over QUIC, which uses UDP. A rule that only allows TCP 443 still works, because browsers fall back to older versions, but it silently loses HTTP/3's benefits.
What to take from this part
A request is several conversations, not one. Each has its own source, destination, port and rule, and each can fail alone.
Ask the five questions in order. Name, resolved address, route both ways, protocol and port, then the control that decides.
The return path is a separate journey. Check it as deliberately as the forward one.
Encryption protects a conversation; it does not authorise it. The application still decides who may do what.
Next in the series: IP addresses, CIDR and an address plan you will not regret.
How CloudNala can help
When a team cannot tell whether a problem is the network, the platform or the application, we help them trace it flow by flow: what resolves where, which routes carry it, which controls decide it. Then we turn what we find into a runbook the team can use without us the next time.
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