Datacentre Thinking in Azure Networking

The network design arrives as a Visio diagram that looks like the old datacentre, drawn bigger. One hub vNet. Forced tunnelling of all internet traffic through an on prem appliance. ExpressRoute to Auckland. Everything inspected, everything centralised.

For some NZ organisations, that is genuinely correct. For many, it is a datacentre replica wearing cloud clothes, and it carries a permanent tax in latency, cost, and engineering time.

Symptoms of Datacentre Thinking

• All internet egress hairpins on prem. A workload in Azure NZ North talking to a SaaS API in Sydney routes via your Auckland office’s firewall, adding latency, cost, and a dependency on your on prem estate that contradicts your datacentre exit strategy.
• One giant shared vNet because “routing is simpler.” Segmentation is done by someone’s good intentions rather than NSGs or architecture.
• No design for the trans Tasman reality. A significant share of NZ workloads consume services only available in Australia East, and eventually the design degenerates into ad hoc peering and a mess of UDR exceptions.
• The network team owns the design; nobody else was consulted. Six months in, app teams discover the hub firewall inspects everything at a throughput cost, and the “simple” architecture cannot be changed without a programme.

NZ Specific Design Considerations

1. Azure NZ North changes the conversation, partially

With the Auckland region available, in country residency and latency to NZ users are much improved. But be clear eyed:

• Service availability: NZ North does not have full service parity with Australia East. Design with a documented “which region hosts what” decision, and do not assume every PaaS service exists locally.
• Trans Tasman traffic: if you will peer or connect to Australia East, understand the latency (~20 to 30ms Auckland to Sydney), the egress costs, and whether you will route that traffic through your hub or directly.

2. Decide egress on purpose, not by inertia

“Forced tunnelling to on prem” is a datacentre era default. Instead:

• If you are a public sector agency or CPS 234 entity, centralised inspection may be a deliberate, defensible requirement. Build it, but document it as a decision with a cost, and consider Azure Firewall in the hub rather than backhauling to on prem.
• If you are a cloud native commercial business, direct internet egress with a cloud native stack (Azure Firewall / WAF, Microsoft Defender for Cloud, plus your SASE provider if you have one) is usually faster, cheaper, and more resilient than hauling traffic through an office.

3. Hybrid connectivity sized for NZ geography

• ExpressRoute (via Auckland/Wellington meet me points) or VPN? ExpressRoute is justified for consistent latency, high volume hybrid workloads and regulated environments. Site to site VPN is frequently good enough for NZ SMB scale. Do not gold plate.
• The Wellington question: if your primary site is Wellington, have an honest conversation about regional disaster scenarios. A single region Azure design with on prem in the same metro shares more risk than a diagram admits. This is one place where Australia East as a secondary is a rational NZ choice, not an extravagance.

4. Centralised inspection vs distributed. Document the trade off.

Both hub centralised and spoke direct designs are valid. What is unforgivable is an undocumented one. Write down: what traffic is inspected, by what, why, and what it costs in latency and throughput. “We chose a secured virtual hub because X” ages well; “that is how it was set up” does not.

Recommendations by Organisation Shape

The test: draw your data flows for one real workload: user to app, app to database, app to SaaS, backup to DR. If any arrow surprises you, the design was inherited, not chosen.