The first thing most teams create in a new cloud account is a network. The console offers a default one, a template offers another, and within an hour there is a VPC or VNet with a handful of subnets labelled "public" and "private". It feels like a security decision. Mostly it is not.
A virtual network is a boundary in which you place addresses, routes, interfaces and controls. It does not, by itself, decide who can reach what. The labels on its subnets change nothing either: a subnet is "public" because of the routes and addresses its resources have, not because of what it is called. The useful questions are where to draw the boundaries, what each one is for, and how many you actually need.
This part answers those questions for Track, Hadeda Freight's shipment-tracking portal. Hadeda Freight is fictional, and its address ranges and figures are illustrative.
Your fenced property in someone else's estate
A virtual private cloud (VPC, the term used by AWS, Google Cloud and Huawei Cloud) or virtual network (VNet, Azure's term) is a logically isolated network inside a public cloud. The provider runs the physical network underneath for thousands of customers; your VPC is your fenced section of it, with an address space you choose.
Inside it you create the constructs from Parts 2 and 3: subnets, route tables, gateways and private DNS zones, plus the security controls that Part 5 covers. Out of the box, a new network is often more open internally than people expect. Resources in different subnets of the same network can usually reach each other unless a control says otherwise. Isolation from other customers is the provider's job. Isolation between your own workloads is yours.
Translating the providers
The four large providers serving South Africa solve the same problems with similar-sounding products. At the time of writing (October 2026), the rough translation is:
| Networking problem | AWS | Azure | Google Cloud | Huawei Cloud |
|---|---|---|---|---|
| Virtual network | VPC (regional) | Virtual Network (regional) | VPC network (global, with regional subnets) | VPC (regional) |
| Subnetwork | Subnet (one availability zone) | Subnet (spans the region's zones) | Subnet (regional) | Subnet |
| Instance-level policy | Security group (stateful) and network ACL (stateless) | Network security group and application security groups | Firewall rules targeting network tags or service accounts; firewall policies targeting secure tags or service accounts | Security group and network ACL (both stateful) |
| Managed outbound NAT | NAT Gateway | NAT Gateway | Cloud NAT | NAT Gateway |
| Private service access | PrivateLink and VPC endpoints | Private Link and private endpoints | Private Service Connect | VPC Endpoint |
| Private circuit | Direct Connect | ExpressRoute | Cloud Interconnect | Direct Connect |
| Central transit | Transit Gateway, Cloud WAN | Virtual WAN, hub VNet | Network Connectivity Center | Enterprise Router, Cloud Connect |
Treat this as a phrasebook, not a dictionary. Similar names do not guarantee identical behaviour, and the differences are where designs break. Two examples from the table: a network ACL is stateless on AWS but stateful on Huawei Cloud, so rules copied between them behave differently; and a Google VPC network is a global resource with regional subnets, so the AWS or Azure habit of "one VPC per region" does not carry over unchanged. Always check the current documentation for the exact service and region you plan to use.
The South African regions you will meet are AWS Africa (Cape Town), af-south-1; Azure South Africa North in Johannesburg; Google Cloud africa-south1 in Johannesburg; and Huawei Cloud AF-Johannesburg. At the time of writing (October 2026), the AWS, Azure and Google regions each have three availability zones. Azure's South Africa West region in Cape Town has no availability zones and restricted access, intended mainly for disaster-recovery pairing. Whether the specific service and feature you need is available in your chosen region is something to verify per service, every time. Our guide to Azure in South Africa goes deeper on one provider.
What a subnet actually does
A subnet gives a smaller address range to a group of resources inside a network. Depending on the provider it belongs to one availability zone or spans a region. More usefully, it is a boundary for four things at once:
- Routing: each subnet is associated with a route table, so subnets can send traffic different ways.
- Security policy: controls are often attached at subnet level, as a coarse layer under finer ones.
- Capacity: the subnet's size limits how many interfaces it can hold (remember the reserved addresses).
- Ownership: a subnet is a natural unit to hand to one team or one tier.
Some managed services also want a subnet of their own, delegated to them, and will not share it with VMs. Plan for that in the address plan rather than discovering it during deployment.
"Public subnet" is a shorthand, not a setting. A subnet becomes effectively public when its resources have public addresses and a route to the internet, and the controls permit inbound traffic. Remove any one of those and it is not public, whatever its name says. Azure makes the point well: for virtual networks created with API versions released after 31 March 2026, new subnets are private by default, with no implicit outbound internet access, and outbound access has to be designed in (Part 6). Older templates and existing networks keep the old behaviour, which is why the same diagram can produce different networks.
Track's network as boundaries
Hadeda's production network, 10.40.0.0/16, holds Track in a classic three-tier shape, plus a subnet for private endpoints.
The intended flows are short enough to write as sentences:
- Internet to the web and ingress tier on HTTPS only.
- Web tier to the application tier on the application port only.
- Application tier to the data tier on the database port only.
- Application tier to private endpoints for managed storage and other services.
- An approved management path from shared services to the application and data tiers.
- No route from the data tier to the internet at all.
Writing flows down like this is the habit that matters. Every arrow is an intended flow, and the absence of an arrow is a decision. Part 5 turns this list into firewall rules; Part 12 turns it into a full flow matrix with owners.
Notice what the subnets do and do not achieve. They give each tier its own routing and policy boundary, so the data tier can have no internet route even though the web tier needs one. They do not decide that a particular customer may see a particular shipment. That is application authorisation, and no amount of subnetting replaces it.
One large network or several?
A single large network is easy at first. Everything can reach everything, nothing needs peering, DNS is simple. It also gives a compromise a large blast radius and makes ownership vague: when everything shares a network, every change is everyone's problem. At the other extreme, a network per microservice creates a mesh of connections, private DNS zones and policies that nobody can reason about.
Split where a real boundary exists:
- production versus non-production;
- regulated versus ordinary workloads;
- different business or platform owners;
- separate lifecycle or connectivity requirements;
- an untrusted partner or acquired environment.
Hadeda applied exactly these. Production and non-production are separate networks. Shared services, where the platform team runs DNS resolvers, management access and the connectivity hub, are a third. When Swift Couriers arrived (Part 2), its network stayed separate and untrusted. Track, Billing and Depot Ops share the production network, separated by subnets and controls, because they share an owner model, a lifecycle and a risk profile. Giving each product team its own network might come later, when the platform has the automation to make that cheap (Part 9).
What is not a reason on its own: using a separate network in place of application authorisation, giving every microservice its own network, or splitting because a diagram looks tidier. Network isolation is one control in a larger trust model, not the model itself.
Common mistakes
- Treating the default network as a design. It was built for getting started, not for production.
- Believing the subnet label. A "private" subnet with a public IP and an internet route is public.
- Copying rules between providers. Stateless on one provider can be stateful on another.
- Forgetting delegated subnets. Some managed services need their own; retrofitting them breaks the address plan.
- Using network boundaries instead of authorisation. A subnet decides who can connect, not who may act.
Try it yourself
Design a network for Track's public API, a private application service and a managed database. Mark the address ranges (from Hadeda's plan), the expected flows, where internet traffic enters, how administrators reach the private tiers, and which component inspects outbound traffic. Then list one boundary you deliberately did not create, and why.
Test your understanding
A subnet is called "private" but its VM has a public IP and the subnet routes 0.0.0.0/0 to an internet gateway. Is it private?
Answer: No. Public addressing plus an internet route makes it effectively public. Only the controls now stand between it and the internet.
Why can a network ACL rule copied from AWS to Huawei Cloud behave differently?
Answer: AWS network ACLs are stateless, so return traffic needs explicit rules; Huawei Cloud network ACLs are stateful. The same rule set has different effects.
Hadeda keeps Track, Billing and Depot Ops in one production network. What would justify giving one of them its own?
Answer: A real boundary: different regulation, a different owner or lifecycle, or distinct connectivity needs. Team preference alone is not enough.
What does a subnet boundary not give you?
Answer: Business permission. It controls which systems can connect, not whether a user may see a particular customer's data.
What to take from this part
A VPC or VNet is a boundary, not a security guarantee. The controls inside it do the work.
Use the provider table as a phrasebook. Similar names hide different behaviour.
Write the flows before the rules. Every arrow is intended; every missing arrow is a decision.
Split networks at real boundaries, and only there. Too few gives blast radius; too many gives sprawl.
Next in the series: Firewalls, security groups and network policy: deciding which flows exist.
How CloudNala can help
We help teams move from a default network to a deliberate one: deciding where the real boundaries are, writing the intended flows for each tier, and translating the design accurately for the provider and South African region in use, including the behaviours that differ from what the team is used to on another cloud.
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