Entrazure
What gets built
This engagement productises the architecture described on the Azure landing zone service page. Same scope every time, which is what makes four weeks a commitment rather than an estimate.
Management group hierarchy and subscription vending. A structure that matches how the organization actually divides responsibility, by business unit, environment or regulatory boundary, plus a repeatable way to create the next subscription that does not involve anyone remembering a checklist.
Azure Policy. Region restriction, allowed services, required tags, encryption, diagnostic settings and SKU limits. Assigned at the level where a subscription owner in a hurry cannot bypass them. Deployed in audit mode first, so you see the blast radius before enforcement.
Identity baseline. Entra ID configuration, conditional access, Privileged Identity Management for administrative roles, break-glass accounts with a tested procedure, and a role model that grants what a job requires instead of Owner on everything. Deeper identity work belongs to cybersecurity and Entra ID.
Network. Hub-and-spoke topology, Azure Firewall or a third-party NVA if you hold the license, private endpoints and Private DNS zones for PaaS, and hybrid connectivity to what stays on premises. Public exposure is the exception and it is documented as one.
Observability and cost. Centralized Log Analytics, diagnostic settings applied by policy rather than by hand, Defender for Cloud at the plan that suits the estate, budgets and anomaly alerts per subscription.
Pipelines. GitHub Actions or Azure DevOps, planning on pull request and applying on merge, with OIDC federated credentials rather than long-lived secrets sitting in a variable group.
How the four weeks run
Week 1, decisions. The choices that are expensive to reverse: hierarchy shape, region strategy, identity model, network addressing, naming and tagging, Terraform or Bicep. Output is a decision record with the reason attached to each choice, so the person who asks why in two years gets an answer instead of a shrug. No deployment happens this week and that is deliberate.
Week 2, platform. Management groups, policy in audit mode, hub network, logging and the identity baseline deployed to a non-production subscription set and reviewed with your team against the decision record.
Week 3, production and pipelines. The same code promoted to production. Policy moves from audit to enforcement on the agreed date. Branch protection, review rules and the pipeline go live, and your engineers open their first pull request against the infrastructure while we are still in the room.
Week 4, handover. Documentation, runbooks, a walkthrough with the people who will operate it, and a written backlog of what we deliberately left out with an estimate against each item.
What you keep
- A Terraform or Bicep repository in your Git organization, with module documentation and a working plan and apply history.
- CI/CD pipelines and the federated credentials behind them, with no secret we hold.
- The week-one decision record.
- A policy set mapped to the controls an auditor asks about, which is the input to compliance architecture work if an audit is coming.
- Runbooks for subscription creation, break-glass access and policy exemption.
- The exclusion backlog, prioritized and estimated honestly.
What it costs you, in effort and access
Access: Owner on the tenant root management group for the duration, or a delegated equivalent your security team is comfortable with, plus a repository in your Git organization and the ability to create the service principals or federated credentials the pipelines use. If your change process requires an approval board, tell us in week one and we build the dates around it.
Effort: roughly four hours a week from a technical counterpart, concentrated in week one where the decision sessions run three to four hours across two or three days and need someone who can actually decide. An architect who has to check every answer with someone else turns a four-week build into a six-week one.
Prerequisite: agreement on the subscription hierarchy. Not the technical design, which is our job, but the organizational question of who owns what. If that is unresolved, the build stalls in week one.
Who this is for
Organizations of roughly 50 to 5,000 people either starting on Azure properly or holding an estate that grew without governance and now slows every project down. It sequences well ahead of a cloud migration, an AI engineering project or an audit, because all three expose an ungoverned estate within weeks. Where residency is the driver, the policy set is designed against the questions in Novarque sovereignty and Loi 25 from week one rather than retrofitted.
Who this is not for
If you run three virtual machines and have no growth plan, this is over-engineering and we will tell you so before invoicing you for it.
If nobody on your side can maintain infrastructure as code after handover, say so at the start. We will scope a simpler architecture your team can actually run, or a managed arrangement. Handing a sophisticated estate to a team that cannot operate it is a failed delivery that looks successful for about four months.
If the hierarchy question is political rather than technical, resolve it first. We cannot deploy around an unresolved argument about who owns which budget.
Where to start if you are unsure
The two-week assessment tells you whether this is the right next step or whether something else on the backlog outranks it.
Questions we get
Why four weeks, and what makes it slip?
Four weeks because the scope is fixed and the architecture is already decided. What makes it slip is never the code. It is an identity decision that needs an executive who is on holiday, a network prefix that has to be reclaimed from another team, or an approval path nobody mapped. All three are visible in week one, which is why week one is decisions rather than deployment.
What if we already have subscriptions and workloads?
That is the normal starting point. Existing subscriptions are moved under the new management group hierarchy without redeploying the workloads inside them. Policy is assigned in audit mode first so you can see what would fail before anything is enforced, then enforced on an agreed date. Nothing is deleted.
Terraform or Bicep?
Terraform by default, because most teams inheriting it can hire for it and because it covers the non-Azure resources that always turn up eventually. Bicep if your team already runs Bicep and intends to keep it, in which case forcing Terraform on them creates a maintenance problem in month three. We decide in week one and record the reason.
Do we get the code, and when?
From the first commit, in your Git organization, not ours. We work in your repository under your branch protection. If you stop the engagement in week two you still hold everything produced up to that point, and it is deployable.
What is explicitly not in the four weeks?
Workload migration, application refactoring, a full Entra ID tenant consolidation, ExpressRoute circuit procurement, and any third-party appliance whose license you do not already hold. Those are named as excluded before signature and appear in the handover backlog with an estimate, so the boundary is written down rather than discovered.
What happens after week four?
You run it. That is the point. Some clients take a small advisory arrangement for the first few months while their team builds confidence with the pipeline, and some take nothing. We do not make ongoing engagement a condition, and the handover is designed for a team that will never call us again.
Have a question about this work?
Three fields. An architect reads it and answers within one business day.