Multi-Cloud Consulting · Microsoft Azure
An Azure foundation that every new subscription inherits
We design and build Azure landing zones on the Cloud Adoption Framework: management groups, policy assignments, hub-and-spoke networking and compliant templates, all in Terraform. Subscriptions placed in the hierarchy inherit their controls, and your team keeps the code.
The problem
Where this usually breaks down
Every workload negotiates its foundation
Without a landing pattern, each team picks its own address space, firewall rules and tags. Each choice is defensible alone, and together they overlap, drift and resist audit.
Controls nobody can evidence
When auditors ask which subscriptions enforce a control, the answer takes an investigation instead of a query, because policy was set per subscription by hand rather than inherited.
Hybrid routing arranged per project
Each application team arranges its own path to on-premises systems, so inspection, name resolution and routing have no single owner, and one missing route quietly bypasses the firewall.
What we do
What we set up, and how each part works
We work in your repositories and through your change process, so everything we set up can be reviewed, run and changed by your engineers after we leave.
Management groups and policy at scale
We lay out platform and landing zone management groups on the Cloud Adoption Framework hierarchy, then assign Azure Policy initiatives and role entitlements at each level. A subscription inherits its controls the moment it is placed.
A connectivity hub peered to every spoke
The hub-and-spoke network centres on a connectivity subscription whose hub holds Azure Firewall, ExpressRoute and VPN gateways, and private DNS resolution. Each spoke peers to it, and user-defined routes send its traffic through the firewall.
Subscription vending with a baseline attached
New subscriptions are requested through a merge request and created by Terraform in the right management group. Spoke networking, budgets, tags, Microsoft Defender for Cloud and diagnostic settings are in place before the application team arrives.
Identity, privileged access and secrets
We structure Microsoft Entra ID groups and role assignments per management group and keep standing privileged access to a minimum. Secrets and certificates live in Azure Key Vault, not in pipeline variables or configuration files.
Compliant templates for workloads
Virtual machine and platform templates fix the SKU, extensions, in-guest policy, backup and tagging, so the compliant configuration is also the easiest one to deploy. Recovery Services vaults and backup policy are part of the landing zone itself.
Changes only through the pipeline
The Terraform lives in your repository and runs through Azure Pipelines or your existing CI, with the plan posted to each merge request for review. A change made by hand in the portal shows up as drift instead of passing unnoticed.
Reference architecture
The architecture as it was delivered
Figures from published engagements, reproduced unchanged. Open any figure full size, or read the write-up it comes from.
- Read the write-up: A governed Azure foundation a bank could build on
Figure 1 — Hub-and-spoke interconnection between the connectivity subscription and an application landing zone, including the compliant VM template baseline every workload inherits.
Open full-size image: Figure 1 — Hub-and-spoke interconnection between the connectivity subscription and an application landing zone, including the compliant VM template baseline every workload inherits. - Read the write-up: Omnichannel banking on Microsoft Azure, private by default
Figure 2 — Network architecture: one connectivity hub peered to separate application and managed-service virtual networks, each with its own planned address range.
Open full-size image: Figure 2 — Network architecture: one connectivity hub peered to separate application and managed-service virtual networks, each with its own planned address range.
What you keep
What stays with your team when we finish
Everything is committed to your repositories or written into your documentation, under your access controls. Nothing depends on us to keep running.
Landing zone Terraform in your repository
Modules for management groups, policy, networking and subscription vending, with the plan reviewed on every merge request and applied only by the pipeline.
A policy and exemption register
Every Azure Policy assignment with its scope, effect and owner, and every exemption with its reason and the date it is next reviewed.
Network and address plan
The hub and spoke address ranges, route tables, firewall rule collections and DNS design, written down so the next spoke follows a known pattern.
Runbooks and decision records
Decision records for the hierarchy, connectivity and identity choices, and runbooks for subscription requests, policy exemptions, break-glass access and firewall changes.
How we work
How an engagement runs, phase by phase
Each phase ends with something your team reviews and signs off before the next one starts. We work inside your change control, not around it.
01
Governance model first
We agree who owns what before any resource exists: the management group hierarchy, naming and tagging, cost attribution and the policy set, recorded as decisions your architects sign off.
02
Network and connectivity design
We design the hub, the spoke pattern, address ranges, routing and DNS together with your network team, including how ExpressRoute or VPN reaches your data centres.
03
Build the platform in code
The landing zone is written as Terraform modules and applied through your pipeline into a test hierarchy first. Policy effects and routing are checked there before production subscriptions depend on them.
04
Onboard workloads and hand over
The first application subscriptions are vended through the new process with your engineers at the keyboard. They keep the modules, the pipeline and the runbooks, and extend all three without us.
Technology
The tools this work runs on
Each group says whether a tool appears in our published work, so you can tell what we have shown from what we offer.
Run in production
- Azure
- Azure Firewall
- ExpressRoute
- Microsoft Defender for Cloud
- Azure Key Vault
- Microsoft Entra ID
- Terraform
- Azure DevOps
Offered, not in published work
- Azure Policy
Evidence
Published work behind this service
Each statement below points to a write-up you can read in full, with the architecture and the stack as they were delivered.
For a bank, we built an Azure landing zone with policy assigned at each management group and a hub holding Azure Firewall and ExpressRoute, deployed from Terraform.
For a bank’s omnichannel platform, we designed an Azure network where one connectivity hub peers to separate application and managed-service networks, with Azure Firewall on every inbound path.
Questions
What teams ask before we start
We already use the Azure landing zone accelerator. Is this different?
It builds on the same Cloud Adoption Framework model. We use the reference implementation where it fits your hierarchy and replace the parts that do not, such as naming, network ranges or policy effects. The result stays Terraform you can read and change.
Can you work with our existing subscriptions and network?
Yes. Existing subscriptions move into the new management groups in planned batches, with policy set to audit first so we can see what would break before enforcing it. Existing connectivity is folded into the hub once the routing is agreed with your network team.
What access do you need to our tenant?
Reader access across the management group hierarchy for the assessment. For build work, we propose every change as a Terraform merge request and your pipeline applies it under an identity you control. Nothing reaches the tenant outside your change process.
Do we need ExpressRoute, or is a VPN enough?
A VPN is enough for many estates, especially early on or for modest traffic. ExpressRoute makes sense when you need private, predictable connectivity to your data centres. The hub is designed so either can be added or replaced without changing the spokes.
Who runs the landing zone after handover?
Your platform team. They work in the repository with us from the start, review the plans, run the subscription vending process and own the policy register. We can stay on for reviews, but nothing depends on us being there.
Related services
What teams often need alongside this
AWS foundations and governance
A multi-account AWS organisation with OUs, service control policies and account vending in Terraform, so new workloads start governed.
On-premises and hybrid cloud
Private connectivity, one identity boundary and shared governance between your data centres and the cloud, with each side kept operable.
Infrastructure as code with Terraform
Terraform modules, a plan reviewed on every merge request, applies only from the pipeline, and drift reported before it becomes an incident.
Next step
Plan your Azure landing zone with us
Tell us about your tenant, your subscriptions and the workloads queued behind them. We will work out with you which parts of the foundation to settle first.