Most cloud networks do not fail because of a bad design on day one. They fail on day 400, when a fourth team asks for a new VPC, a partner needs private connectivity, and nobody can say with confidence which route table sends traffic where. Hub-and-spoke is the pattern most enterprises reach for, but it only holds up if you treat it as an operating model and not just a diagram.
Start With a Hub That Does Few Things Well
The hub should own shared services and inspection, nothing else. In practice that means egress control, east-west and north-south firewalling, private DNS resolution, and hybrid connectivity to on-premises sites. When teams start placing application workloads, jump boxes and one-off tooling in the hub, blast radius grows and change windows get tense.
On Azure this is typically a hub VNet with a firewall tier, such as Palo Alto VM-Series appliances or a native option, plus VNet peering to each spoke. On AWS the same role is played by a Transit Gateway with dedicated route tables for inspection, shared services and workload attachments. On GCP, VPC peering has transitivity limits, so plan for Network Connectivity Center or a deliberate appliance routing design from the start.
Segment Spokes by Trust, Not by Team
A common mistake is creating one spoke per team. Teams change, reorganize and merge, and the network ends up mirroring an org chart that no longer exists. A more durable approach is to segment by environment and data sensitivity: production, non-production, regulated workloads, and a sandbox with no path to production data.
This matters most in healthcare and financial services, where auditors ask a simple question: show me every path that can reach this data. If your spokes are grouped by trust level, the answer is a short list of route table entries and firewall rules, not a spreadsheet exercise.
Make Routing and Firewall Policy Code, Not Tickets
Hub-and-spoke gets fragile when changes happen in the console. We build network landing zones in Terraform with modular, environment-based deployments, so a new spoke is a pull request that adds a peering, route table associations and a baseline set of firewall rules. Reviewers can see exactly what a change opens up before it is applied.
A few practices that pay off quickly: keep address space allocation in a single source of truth so overlapping CIDRs never reach a peering request, enforce default deny between spokes and open flows explicitly, and run policy checks in the pipeline so a route that bypasses inspection fails the build instead of reaching production.
Design DNS and Observability Before You Need Them
DNS is the part of the network that teams discover too late. Decide early where private zones live, how conditional forwarding works between clouds and on-premises, and who owns each zone. Split-horizon surprises are a frequent cause of outages that look like application bugs.
Equally important is visibility. Flow logs, firewall logs and DNS query logs should land in one place where your security team can use them, for example Microsoft Sentinel, alongside Defender for Cloud findings. A network you cannot observe is a network you cannot defend or troubleshoot.
Plan for the Multi-Cloud Boundary
If you run workloads across AWS, Azure and GCP, resist the urge to build a mesh of point-to-point tunnels. Pick one or two interconnect locations, define a clear transit model, and keep the cross-cloud paths narrow and well documented. Most cross-cloud traffic should be API calls and replication, not chatty application internals. If a design needs high-volume east-west traffic between clouds, that is usually a signal to revisit workload placement.
Where to Go From Here
A sound network foundation makes everything built on top of it cheaper and safer, from Kubernetes clusters on EKS, AKS and GKE to agentic AI workloads that need governed access to internal systems. If your hub-and-spoke design has grown organically and you want an independent review, or you are planning a landing zone across more than one cloud, our team can help. Book a consultation at https://cloudevtech.net/contact/ and we will walk through your current topology and the next sensible step.
#CloudNetworking #Terraform #Azure #AWS #GCP