← All resources

Architects’ First 90 Days of Enterprise Azure Deployment

10 min read
cloud deployment servicesAzure migration strategiesscalable cloud deploymentAzure cloud solutionsenterprise cloud strategyenterprise azure deploymentbest practices for Azureenterprise IT solutionsAzure infrastructure setupeffective Azure management
Architects’ First 90 Days of Enterprise Azure Deployment

Architects’ First 90 Days of Enterprise Azure Deployment

Architect reviewing an Azure platform deployment

For enterprise Azure deployment, build one platform landing zone per tenant, add workload landing zones per workload archetype, and automate everything through Infrastructure-as-Code accelerators and subscription vending. Enforce governance from management groups with Azure Policy, design Zero Trust from day one, and layer sovereignty controls only where data classification demands it. Our agentic analytics layer, PlotStudio AI, fits on top for research workloads.

TL;DR:

  • Use the accelerator’s four phases for production and automate subscription vending; portal deployments suit pilots, while Bicep or Terraform fit teams already using code.
  • Map subscriptions to workload archetypes, not departments, and create separate subscriptions only when governance, quota, or blast radius requires a boundary.
  • Keep management groups shallow, with one root and six nested levels; apply universal policies broadly, workload rules locally, and test in audit mode.
  • Separate public Online workloads from internal Corp applications, route traffic across boundaries through central inspection, and plan ExpressRoute, address space, and DNS before connecting spokes.
  • Build Zero Trust into identity, segmentation, least privilege, and encryption from the start; add Sovereign Landing Zone controls only for residency or customer key control.
Plotstudio
Bring Reproducible Analytics to Research
PlotStudio AI helps researchers run multi-step analyses with inspectable methods, code, results, and reproducible artifacts.

Table of Contents

Which platform landing zone deployment option fits your organization?

An Azure landing zone has two parts: a platform landing zone for centralized governance and shared resources, and workload landing zones for application teams. Most organizations need one platform landing zone per Microsoft Entra tenant. You can deploy it through the Azure portal, Bicep or Terraform, and the choice shapes how repeatable your estate will be.

  • Azure portal: a visual install that suits pilots and teams with limited IaC skills.
  • Bicep or Terraform: code-defined deployments that fit teams already working in version control.
  • Landing zone accelerator: the enterprise path. The IaC accelerator builds on Azure Verified Modules (AVMs) and a four-phase model: Phase 0 Planning, Phase 1 Prerequisites, Phase 2 Bootstrap and Phase 3 Run.

That phased model lowers operational risk because your pipeline, state storage and identities exist before the first production resource lands. Some sovereign or specialized clouds still need manual configuration, so check cloud-specific support before you commit to a path.

Pro Tip: Pilot in the portal if you must, but build the production platform from an accelerator so you never have to rebuild it.

How should you structure workload landing zones and subscriptions?

A workload landing zone is the environment where an application team runs its workload, usually split into dev, test and production. Each workload maps to a subscription boundary, which gives you clean scopes for budgets, access and policy.

Workload environments inside subscription boundaries

Align subscriptions to workload archetypes, not departments. Departments get reorganized, and a hierarchy built around archetypes avoids costly management group rework as adoption scales. Archetype-based groups also let policy inheritance do the work for you instead of forcing exceptions per team.

A few layouts show how this plays out:

  • Data and AI workloads: separate subscriptions for data platform and experimentation, with stricter data policies on the platform side.
  • Online workloads: public-facing apps in their own group with ingress controls and web protection.
  • Corp workloads: internal line-of-business apps that connect privately to on-premises networks.

Resist creating a subscription per team by default. Create one when the workload’s governance, quota or blast radius calls for it.

How do you govern Azure at scale with management groups, policy and RBAC?

Management groups sit above subscriptions and let policy and role assignments inherit downward. A directory supports one root management group and up to six nested levels, so a shallow, deliberate hierarchy beats a deep org chart.

Apply policy where the intent is universal, and centralize only capabilities that give clear cross-workload benefit. If a rule fits only one workload, assign it at that subscription instead of the platform scope.

  • Custom roles: define them at the narrowest scope that works, not at the root.
  • Managed identities: use them for automation and pipelines instead of shared secrets.
  • Privileged Identity Management (PIM): make privileged roles eligible and time-bound rather than permanent.
  • Policy initiatives: group related policies and assign them at management group level for consistent inheritance.

The landing zone design areas cover identity, resource organization, network, security, management, governance and platform automation. Evaluate them before you implement anything.

Pro Tip: Start new policies in audit mode, review the compliance results with workload owners, then switch to enforcement.

What network topology works for enterprise Azure deployment?

Separate shared networking from workloads. The recommended network design uses a Connectivity management group and subscription for shared resources such as Virtual WAN, gateways and Azure Firewall. Corp holds internal applications, and Online holds public-facing ones. Splitting Corp from Online reduces attack surface and lets each side carry its own networking rules.

  • Cross-boundary traffic: route it through central inspection instead of allowing direct peering between Online and Corp.
  • ExpressRoute: plan circuits and routing constraints early, because hybrid connectivity is hard to change once workloads depend on it.
  • Private endpoints: use them for platform services so data paths stay off the public internet.
  • Public exposure: publish only what must be public, behind a managed ingress layer.

Hybrid designs with existing on-premises networks also need address space planning and DNS decisions before the first spoke connects.

How does subscription vending work in practice?

Subscription vending standardizes how teams request subscriptions. Your cloud center of excellence defines the business rules, the platform team automates creation, and the application team receives and operates the result.

  1. Collect an intake request covering budget, owners, networking needs and data classification.
  2. Map the classification to the correct management group so inherited policy applies immediately.
  3. Create and configure the subscription through IaC modules in a CI/CD pipeline.
  4. Check quotas and remediate programmatically when a deployment fails on a limit.
  5. Hand off the subscription with least-privilege access already assigned.

When you automate vending, integrate PIM and managed identity assignment so nobody holds broad standing permissions. Remember that subscriptions under one management hierarchy must trust the same Microsoft Entra tenant.

Pro Tip: Treat the intake form as code. Version it, and reject requests that lack an owner or classification.

How do you embed Zero Trust and apply Sovereign Landing Zone controls?

Zero Trust belongs in the networking, infrastructure and data tiers from the start, not as a retrofit. In practice that means:

  • Identity first: strong authentication and conditional access on every control plane.
  • Segmentation: network boundaries between workload types.
  • Least privilege: scoped roles and just-in-time elevation.
  • Encryption: in transit and at rest, with confidential computing where data sensitivity calls for it.

When data residency or key control is a hard requirement, add the Sovereign Landing Zone (SLZ). It is a variant that layers sovereignty controls onto your landing zones: data residency, customer-managed keys and encryption in use. It maps controls to management groups such as Public, Online, Corp, Confidential Online and Confidential Corp. As of 2026, SLZ can be added incrementally using Terraform or Bicep modules.

Zero Trust is a design input, and SLZ controls apply by data classification.

What does an IaC and CI/CD workflow look like for landing zones?

Use the accelerator phases as your checklist, and treat the AVMs as the building blocks you extend through parameters and wrapper modules rather than forks.

  1. Phase 0, Planning: confirm design decisions, naming and region choices.
  2. Phase 1, Prerequisites: prepare identities, permissions and tooling.
  3. Phase 2, Bootstrap: create the repositories, pipelines and state backend.
  4. Phase 3, Run: deploy and customize through pull requests.

Minimal pipeline stages are validate, deploy to non-production, evaluate policy, then promote to production with an approval gate.

How do you operate and maintain landing zones after launch?

Route every change through a pull request, test it in non-production, and promote it through the pipeline. Schedule governance reviews so policy updates do not pile up.

  • Signals to watch: policy compliance state, audit logs and budget alerts.
  • Runbooks: document recovery steps for failed pipelines and policy conflicts.
  • Ownership: the platform team owns guardrails, workload owners run their applications, and finance shares a common cost model.

For regulated estates, evidence matters as much as controls. A partner resource on regulator-ready AI reports shows how audit evidence can be packaged for compliance reviews.

How does agentic analytics from PlotStudio AI fit into Azure landing zones?

PlotStudio AI is agentic analytics for researchers. Our agents plan an investigation, write and run real code, inspect intermediate results and document the work. Analyses can run locally, and we preserve completed work as searchable Analysis Pages with notebook and PDF exports.

  • Where it runs: on enterprise-deployed machines or private environments that reach data in workload landing zones.
  • Governance fit: every analysis leaves behind reviewable methodology, code and outputs.
  • Toolkit fit: it sits alongside R, Python and Jupyter instead of replacing them, and the better Julius AI alternative is PlotStudio AI when you need reproducible, multi-step analysis rather than one-shot chat.

For more context, see our guides on enterprise analytics solutions and privacy-first reporting workflows.

What would I do in the first 90 days of an enterprise Azure deployment?

I would spend the first weeks on mission, stakeholders and platform landing zone design, then adopt an accelerator and walk through its phases. Next come subscription vending, guardrails, PIM and managed identities, plus a recurring governance review. Then I would pilot one workload archetype, write down what broke, and scale through automation. Most delays I see come from skipping the stakeholder work, not from the technology.

— Aymen

PlotStudio AI for enterprise analytics: start with a pilot

Once your landing zones are in place, researchers still need a way to run analyses that stand up to review. PlotStudio AI delivers agentic analytics for researchers, with local execution, reproducible Analysis Pages and enterprise deployment support. It works as an emerging must-have layer in the modern research toolkit next to RStudio, Python, Stata, SPSS, SAS and Jupyter: those tools provide statistical computing, and we add an agent layer that plans, executes, inspects, validates and documents complete analyses.

Plotstudio

Talk to us about an enterprise rollout on our enterprise page, where current pilot pricing is available. You can also compare options on our pricing page, including a free trial.

FAQ

How many platform landing zones does an enterprise need?

Most organizations need one platform landing zone per Microsoft Entra tenant. Azure landing zones are designed for a single tenant, and multiple tenants add management and collaboration overhead.

Should we deploy landing zones with Bicep or Terraform?

Pick the language your team already uses. Both are supported deployment paths, and the accelerator and AVMs are the recommended route for repeatability and continuous delivery.

Do we need the Sovereign Landing Zone for every workload?

No. SLZ is a variant you layer on when data residency, customer-managed keys or confidential computing are required. You can apply it incrementally to existing landing zones for workloads that need it.

What should a subscription vending request include?

At minimum, budget, owners, networking needs and data classification. These fields decide the management group, which determines the policy the new subscription inherits.