CLOUDMECHANIX
Book a call
Consulting

Azure Firewall & networking.

Central egress, inspection and segmentation — designed so your team can read the policy, audit it and own it. We build hub-and-spoke networks with Azure Firewall at the centre, and rule structures that stay maintainable as the estate grows.

Book a call
The problem

You'll recognise this.

Your Azure network grew more complex with every workload. Every project added a subnet, a route, a firewall exception. It worked each time — but no one can say the security is sound. It feels like the vulnerable on-premises network has simply been relocated to the cloud.

The cost shows up later: a failed security review, an outage caused by a route change nobody understood, and a network that gets harder to change every quarter. Meanwhile developers and operators grow frustrated, slowed down by central IT.

What you get

Senior depth, handed over.

  • A hub-and-spoke network with Azure Firewall for central egress and inspection.
  • Firewall policy and rule collections structured to stay readable and auditable.
  • Logging wired into Log Analytics so you can see what is happening on the network.
  • A design built for on-demand self-service.
  • Reliable security against modern threats, from outside and inside.
How we'd approach it

The decisions that matter.

Hub-and-spoke with central egress.

Why: One inspected, logged path out of Azure means one place to set policy and one place to look when something is wrong. Spokes stay simple.

What we'd rule out: Per-spoke egress that fragments policy and logging across the estate.

Segment into Azure landing zones.

Why: Splitting applications into smaller, isolated virtual networks forces an attacker to cross the firewall to move laterally. You get more control, stronger inspection from a next-generation firewall, and a better chance of catching an intruder early.

What we'd rule out: Large, flat virtual networks holding many applications — the vulnerable on-premises VLAN, rebuilt in Azure.

Deploy the network as code.

Why: Reviewable, repeatable and free of portal drift. The topology, the policy and the routing are defined in Bicep or Terraform and changed through a pipeline.

What we'd rule out: A portal-built network nobody can reproduce or safely change.

Deployed as code

Infrastructure as code, not click-ops.

Everything we build is defined in code, so every change is recorded, reviewable and repeatable. We work in Bicep or Terraform, and can run it through Azure DevOps or GitHub, whichever your team already uses.

We maintain our own libraries of proven, reusable code that give a project a rapid start — up to an entire enterprise-scale collection of Azure landing zones. Our code is written to be run in production and maintained by your own people: readable, adaptable, and boring in the ways that matter.

What you get

Deliverables.

  • A hub-and-spoke topology design with a next-generation firewall at the centre.
  • A firewall policy structure — collections and groups — built to stay readable.
  • The routing (user-defined routes) design that forces traffic through inspection.
  • Logging wired into Log Analytics so network activity is visible.
  • The whole network defined in Bicep or Terraform, and a handover to your team.
  • Automation that enforces the design and its security controls, keeping manual effort to a minimum.
Out of scope

What it isn't.

  • Migrating from a third-party network virtual appliance is possible but scoped separately.
  • Application-layer web filtering (Front Door or Application Gateway WAF) is related but a separate piece of work.
  • Changes to your on-premises firewalls or routers sit with your network team.
The shape of it

How it fits together.

Hub-and-spoke with central inspection and micro-segmentation
On-premises and remote sites
Untrusted by default
Internet
Inbound blocked, egress controlled
Hub virtual network
Azure Firewall
Single inspection and egress point
Spoke virtual networks
Workload 1
Network security groups
Micro-segmentation
Workload 2
Network security groups
Micro-segmentation
Workload N
Network security groups
Micro-segmentation
No direct path between spokes — east-west traffic is inspected
Azure Virtual Network Manager  ·  Network Watcher and flow logs  ·  Azure Monitor
Segmentation defined centrally. Traffic visible end to end.
Every flow, north-south and east-west, passes through one inspection point your team can read and audit.
Hub-and-spoke with Azure Firewall for central, inspected egress.

A central hub virtual network holds Azure Firewall. Each workload sits in its own spoke virtual network, peered to the hub. User-defined routes send traffic from the spokes through the firewall, so egress and inter-spoke traffic are inspected and logged in one place. Firewall policy is organised as a hierarchy of rule collection groups rather than a flat list. All firewall and network logs flow to a Log Analytics workspace. The whole topology is defined as code.

How we work

With your team, not around them.

We design the topology, agree the policy structure with you, and build it with your team so the people who run it understand it.

Who it's for: We work with mid-to-large enterprise, State and semi-State bodies, education, and the partner consultancies who bring us in when a client needs senior Azure depth.

Questions

Frequently asked.

Azure Firewall or a third-party appliance?
Both can work. Azure Firewall is native, scales without you managing VMs, and integrates with Azure logging and policy. We will tell you honestly if your requirements point elsewhere.
Can we use a third-party firewall?
Yes. Palo Alto Networks, for example, offers Cloud NGFW — a next-generation firewall delivered as a native Azure service, deployed and managed as an Azure resource, including with Bicep. We size the engine to your requirements rather than defaulting to one.
Do we need Azure Firewall Premium?
Only if you need its specific features — TLS inspection, IDPS, URL filtering. Many estates are well served by Standard. We size it to what you actually need.
How do the rules stay manageable over time?
By structuring policy as a hierarchy from the start, and by keeping it in code so every change is reviewed. Rules stop being a mystery pile.
Can you integrate with our existing on-premises network?
Yes — hub-and-spoke is designed to. We plan the connectivity (ExpressRoute or VPN) and routing with your network team.
Bicep or Terraform?
Whichever your team already uses. We work in both and run them through Azure DevOps or GitHub.
Who runs it after you leave?
Your team. The network is defined in code they hold, with the policy structure documented, so changes are routine rather than risky.
Proof

Proof

We built a Zero Trust Azure network for Lakeland Dairies — hub-and-spoke, Azure Firewall, across two regions, delivered in a 21-day engagement. Read the case study.

Related consulting

Often needed alongside.

Azure Security & Zero Trust

Identity-first designs that assume breach — built to stand up to NIS2 and an auditor.

Learn more

Azure Landing Zones

Enterprise-scale foundations built to the Well-Architected Framework — governance, networking and identity from day one.

Learn more

Talk to an Azure architect, not a salesperson.

Fixed scope, fixed price — quoted on enquiry.

Book a callAzure Environment Review