Hub-and-spoke topology
Why: A central hub for shared services, inspection and policy, with spokes that inherit governance consistently across both regions.
What we rejected: Isolated per-application networks with no shared inspection point.
Featured Work · Lakeland Dairies
Zero Trust Azure network across two regions in 21 days.
A hub-and-spoke design with Azure Firewall, Network Security Groups and Web Application Firewalls, deployed as code across two regions — built with the in-house team so they could run it afterwards.
- Client
- Lakeland Dairies
- Engagement
- Azure network deployment
- Duration
- 21-day engagement
- Regions
- North Europe (Ireland) · West Europe (Netherlands)
- Azure services
- Hub-and-spoke · Azure Firewall · NSGs · Web Application Firewalls
01 · Challenge
Modernise the Azure network for resilience and security.
As part of its digital transformation, Lakeland Dairies set out to modernise its network architecture in Azure to support resilience, security and cross-regional disaster recovery — a foundation robust enough to carry more workloads to the cloud over time.
02 · Constraints & requirements
What shaped the design.
- Production-ready across two Azure regions, with cross-regional disaster recovery.
- Centrally managed governance and a policy-driven approach.
- Security built in — network firewalls, web application firewalls and NSGs.
- The in-house team had to understand how future workloads would be delivered.
03 · Architecture
Hub-and-spoke, Zero Trust, dual region.
A centrally governed hub-and-spoke model implementing a Zero Trust approach: network firewalls, web application firewalls and NSGs driven by automation. Two regions with availability zones and multiple failover paths, backed by detailed design documentation.
House-style architecture diagram — hub-and-spoke across two regions
04 · Key decisions
Decision · why · what we rejected.
Central egress through Azure Firewall
Why: One place to inspect and log outbound traffic, with policy the in-house team can read and audit.
What we rejected: Per-spoke egress that scatters policy and logging across the estate.
Zero Trust segmentation (NSGs + WAFs)
Why: Assume breach: control east-west traffic and protect public entry points rather than trusting internal traffic.
What we rejected: A flat network that trusts anything already inside it.
Deployed as code
Why: Reviewable, repeatable and reproducible across two regions — and handed over with the design documentation.
What we rejected: Portal click-ops that cannot be reviewed, repeated or safely handed over.
05 · How we delivered
Mentoring-first, hands-on throughout.
We took a mentoring-first approach with hands-on guidance across the 21-day engagement, involving the client team in the build and delivering pre-training. By handover the team understood the environment — the point was never to leave them dependent on us.
06 · Outcomes
21Day engagement
2Regions
- A fully operational, production-ready Azure network across two regions.
- A disaster recovery architecture, validated and documented.
- A team equipped with practical knowledge to deliver future workloads.
Client quote
“As we continue migrating more workloads to the cloud, we partnered with Cloud Mechanix to establish a robust environment with the right governance, security, and automation in place. Cloud Mechanix's collaborative approach—particularly involving my team in the build process and delivering pre-training—was instrumental in helping us understand how we'll deliver future workloads in Azure.”