Expert cloud network architecture: four patterns and a decision method

There is a kind of architecture diagram that looks expert and is not. It has forty product icons, three firewalls, two transit hubs and a service mesh, and nobody in the room can say which requirement each one satisfies. It was assembled from reference architectures rather than designed from the problem.

Expert networking looks different. It turns business, security, availability and operational requirements into a small number of controlled traffic paths, then proves that those paths behave correctly, both when everything works and when something fails. The diagram is often simpler than the beginner's. The thinking behind it is not.

This final part brings the series together. It sets out four common patterns, a seven-step decision method, the review questions worth asking of any design, and a capstone exercise that designs Track end to end. Track is the shipment-tracking portal of Hadeda Freight, the fictional freight company we have followed since Part 1. Hadeda Freight is fictional, and its address ranges and figures are illustrative. Everything here is educational rather than a production configuration: adapt ranges, ports and patterns to the actual workload, and check them against current provider documentation and your own policy and regulatory requirements.

Four patterns

Most cloud networks are built from a handful of recurring shapes. Recognising which one fits saves a great deal of reinvention.

Pattern 1: internet-facing three-tier platform

Use it when the public must reach a web or API service while the application and data tiers stay private. Traffic arrives through public DNS, DDoS protection, a content delivery network and a web application firewall; an application load balancer passes it to private application services; those reach private data services; and anything outbound leaves through controlled egress.

The decisions that cannot be left implicit: who owns TLS certificates and their renewal; the WAF and API security policy; stateless scaling and session handling; private database connectivity; the egress allowlist and the path software packages come in by; zone distribution and health checks; and application-level authentication and authorisation. Track today is this pattern.

Pattern 2: hybrid enterprise platform

Use it when cloud applications depend on data-centre systems, or when sites need private, predictable connectivity. Branches connect to a data-centre edge; that edge connects to a cloud transit hub over a private circuit with a VPN as backup; application spokes and shared DNS and security services hang off the hub.

Key decisions: non-overlapping addressing; primary and backup routing policy; DNS forwarding and private endpoint resolution; encryption over every path, including the private circuit; physical carrier diversity; what happens during a disconnection; and dependency latency, which often dictates migration order. Hadeda's Midrand office, depots and Cape Town recovery site make it partly this pattern too, and it shows why physical diversity has to be checked rather than assumed: Hadeda's private circuit and the internet line carrying its VPN turned out to enter the Midrand building through the same duct.

Pattern 3: private API or data product

Use it when consumers need one service without broad network access. The consumer network reaches a private service endpoint, which leads to an API gateway in front of the provider service and its data.

This pattern narrows trust. The consumer receives access to the published service, not routes to every subnet behind it. That makes it the right answer for partners and, increasingly, for internal teams. Add consumer identity, quotas, schema governance, logging and a way to revoke access. Hadeda already uses it in one direction, consuming Swift Couriers' billing API through a private endpoint despite the two networks' overlapping ranges. When a large enterprise customer asks for private connectivity to the Track API, the same pattern applies in reverse, rather than a peering connection between two corporate networks.

Pattern 4: multicloud by workload role

Use it when different providers have clearly defined roles, for example core applications on one cloud and analytics or a specialist service on another, and the organisation can operate the resulting complexity. Users and sites connect through shared enterprise connectivity and identity; a governed data exchange links the clouds; operations and security evidence come together in one place.

The important word is role. Avoid making every workload portable across every cloud. Standardise what matters across them: interfaces, identity, policy, telemetry, data contracts and recovery evidence. Full runtime portability is expensive, and it often stops teams using the very capabilities that justified each provider in the first place.

The decision sequence

Patterns are a starting point, not a method. The method is a sequence of seven steps, each producing something the next one needs.

1. Define the workload and users. Name the business capability, where users are, which systems it depends on, which classes of data it handles and who is accountable.

2. Write the required flows. For every flow, record the fields below. This flow matrix is the single most useful network artefact you can produce.

3. Apply hard constraints. Confirm regional service availability, data flows, latency, recovery, provider quotas, regulatory and contractual requirements, existing connectivity and the skills the organisation actually has.

4. Select the smallest architecture that passes. Every gateway, appliance, peering, route and policy needs a reason traceable to a requirement. Remove anything that has none.

5. Model normal and failure paths. Show forward and return routes, DNS answers, identity dependencies, inspection points and the capacity of each secondary path.

6. Define ownership. State who provisions, approves, monitors, patches, pays for, troubleshoots and changes each shared component.

7. Automate and test. Use infrastructure as code, policy as code, configuration validation, flow tests, synthetic checks and recovery exercises. A diagram is a hypothesis until deployed behaviour proves it. If you are early on this road, start small with infrastructure as code.

Fifteen review questions

Use these on any network design, your own included. A design that cannot answer one of them has a gap, not a detail to fill in later.

1. Can every required flow be traced from name resolution to the return packet?
2. Are public, private, management and service-to-service paths kept separate?
3. Does every allow rule have a source, destination, protocol, port, purpose and owner?
4. Are overlapping address spaces prevented centrally?
5. Can office and cloud clients resolve private service names correctly?
6. Does any workload have a public IP only because administration was easier?
7. Is outbound traffic controlled and observable?
8. Are identity and application authorisation present, beyond network allowlists?
9. Will stateful inspection see both directions of every connection?
10. What happens when one zone, circuit, DNS service, firewall or certificate fails?
11. Has the secondary path's capacity been tested under load?
12. Are cross-region and cross-border data paths documented?
13. Can the team identify which users a network fault affects, using current telemetry?
14. Are high-volume flows costed across NAT, inspection, zones and regions?
15. Can the design be recreated and validated from code?

Capstone: design the Track network

Here is the exercise that pulls the twelve parts together. Treat it as a real design task.

The scenario. Hadeda Freight is building Track for South African business customers, who reach it over the internet. Drivers use a mobile app. Track calls an external payment provider and sends email and SMS through an external messaging service. Operational staff work from Midrand and remotely. Customer names, phone numbers and delivery addresses, which are personal information under POPIA, are stored in a managed database. Depot scanners in Durban and Gqeberha post scan events. A large enterprise customer may later require private connectivity. The target recovery time is four hours and the maximum acceptable data loss is fifteen minutes.

Produce:

1. A context diagram showing users, external services and trust boundaries.
2. An address plan with production, non-production and private-endpoint ranges (the plan from Part 2 is a good start).
3. A DNS design covering public and private names, including the depots.
4. A flow matrix for user, application, database, operations, monitoring and external-provider traffic.
5. An ingress and egress design.
6. A decision on public or private access for every managed service.
7. A remote administration design with no public SSH or RDP.
8. A zone and disaster-recovery design tied to the four-hour RTO and fifteen-minute RPO.
9. A logging and alerting plan.
10. A three-year network cost model.
11. Five failure tests.
12. A responsibility matrix.

An opening answer. The high-level view looks like this.

This is only the first page of the answer. A complete design still needs the routes, DNS behaviour, security rules, identities, recovery mechanics, cost model, monitoring and ownership behind every line in that picture. If you can produce all twelve deliverables and defend each one against the fifteen review questions, you are working at the level this series set out to reach.

Provider cautions

The patterns are provider-neutral. The details are not. At the time of writing (October 2026), these are the points most worth checking on each platform. Similar product names do not mean identical behaviour.

AWS. Designs commonly use regional VPCs, subnets in each availability zone, route tables, security groups (stateful), network ACLs (stateless), internet and NAT gateways, VPC endpoints, Transit Gateway, Route 53 Resolver, Elastic Load Balancing and Direct Connect. Check which resources are zonal, where cross-zone traffic creates cost, how routes propagate and whether the endpoint type supports the service you need. AWS charges for every public IPv4 address, in use or idle.

Microsoft Azure. Designs commonly use VNets, subnets, user-defined routes, network security groups, Azure Firewall, NAT Gateway, Private Link with private DNS zones, Application Gateway, Load Balancer, Front Door, Virtual WAN, VPN Gateway and ExpressRoute. Check subnet delegation, private endpoint DNS, forced tunnelling, route precedence, gateway SKU, zone support and whether the exact feature is available in South Africa North. New virtual networks created with API versions released after 31 March 2026 get private subnets by default, without default outbound internet access; older templates and API versions can still create subnets that have it, so check what your infrastructure code actually produces.

Google Cloud. VPC networks are global resources with regional subnets, which is a different mental model from AWS and Azure; do not carry a regional-VPC model across unchanged. Designs commonly use VPC firewall rules and firewall policies (including hierarchical policies), Cloud NAT, Private Service Connect, Cloud Load Balancing, Cloud DNS, Network Connectivity Center, Cloud VPN and Cloud Interconnect. Confirm routing mode, how firewall policies target workloads, Shared VPC ownership and regional availability in africa-south1.

Huawei Cloud. Designs commonly use VPCs, subnets, security groups, network ACLs (which on Huawei Cloud are stateful, unlike AWS's), Elastic IP, NAT Gateway, VPC Endpoint, Elastic Load Balance, Cloud Connect, Enterprise Router, VPN and Direct Connect. Confirm feature and region availability in AF-Johannesburg, connectivity partner options, operational support and the exact behaviour of managed services.

On-premises and private cloud. The fundamentals are the same: address management, routing, segmentation, firewalls, load balancing, DNS, identity, observability and recovery. Physical switches, routers, cabling, hypervisors and appliances add lifecycle, capacity and maintenance work that public cloud abstracts away, but they do not change the concepts.

A hands-on lab path

Reading builds understanding; labs build judgement. Use a sandbox account with strict budget alerts and no production data.

Delete lab resources after each exercise, and confirm that billable public IPs, NAT gateways, firewalls, private endpoints and connectivity gateways are really gone. They are the items most likely to keep charging after the lab is forgotten.

Further reading

Product behaviour, regional availability and pricing change, so use current first-party documentation before implementing anything:

• Microsoft Learn: Azure Virtual Network documentation and Azure Architecture Center: networking
• AWS: Amazon VPC User Guide and Well-Architected Framework, reliability pillar
• Google Cloud: VPC documentation and Network Connectivity Center
• Huawei Cloud: Virtual Private Cloud documentation
• IETF: RFC 1918, private address allocation and RFC 8200, IPv6
• NIST: SP 800-207, Zero Trust Architecture and SP 1800-35, Implementing a Zero Trust Architecture

Common mistakes

• Designing from reference architectures instead of flows. Components arrive without requirements, and nobody can say which one to remove.
• Making every workload portable across every cloud. The cost is high and it blocks the capabilities that justified each provider.
• Using peering where a published service would do. It hands a partner routes to far more than the one API they need.
• Stopping at the diagram. Without routes, DNS behaviour, identities, cost and ownership, the design is not finished.
• Treating the design as done once deployed. Without flow tests and failure exercises, nobody knows whether the network matches the intent.

Test your understanding

An enterprise customer wants private connectivity to the Track API. Which pattern fits, and why not peering?

Answer: Pattern 3, a private API published through a private service endpoint. It gives the customer one service, not routes into Hadeda's network, and access can be revoked cleanly.

What is the single most useful network artefact, and why?

Answer: The flow matrix. Every rule, route, inspection point and owner can be traced back to a row in it, and anything that cannot be traced is a candidate for removal.

In multicloud, what should be standardised across providers, if not the runtime?

Answer: Interfaces, identity, policy, telemetry, data contracts and recovery evidence.

When is a network design finished?

Answer: When deployed behaviour, tested in success and failure, matches the intended flows, and every shared component has an owner. Until then, it is a hypothesis.

What to take from this part, and from the series

A beginner learns the names of the components. Packets, addresses, DNS, routes, subnets and gateways.

An intermediate engineer connects and secures them. Firewalls, NAT, private endpoints, load balancing and hybrid links.

An advanced engineer designs shared patterns and failure behaviour. Landing zones, segmentation, resilience and cost.

An expert makes the trade-offs visible. They remove unnecessary paths, assign ownership and build evidence that the deployed network matches the intended architecture.

That is the end of the series. To revisit any part, start from Part 1: how network communication works or the series page.

How CloudNala can help

We review cloud network designs the way this series teaches: starting from the flows rather than the products, checking each component against a requirement, testing the failure paths and the billable paths, and making sure every shared piece has an owner. For teams building their first landing zone or their first hybrid link, we help produce the flow matrix and the decisions that sit behind it.

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