Plan and prepare to deploy Azure landing zone for Nonprofits

Before you deploy Azure landing zone for Nonprofits, choose the deployment path, confirm the required Azure subscriptions and permissions, and prepare the operational inputs that the deployment uses.

Use this article before you start either the Azure portal deployment or the Azure CLI deployment. The same planning decisions apply to both deployment options.

Choose a deployment path

Azure landing zone for Nonprofits supports two primary deployment paths.

Path Choose this path when Required starting point
Foundation You need a compact platform baseline in one subscription, with fewer upfront decisions and optional simple networking. One existing Azure subscription. An empty or near-empty subscription provides the cleanest compliance starting point, but subscriptions that already contain resources are supported.
Expanded Platform You need stronger separation of duties, a dedicated hub network, and a platform structure that can grow as you add subscriptions or workloads. Existing management and connectivity subscriptions that are approved for this deployment.

Foundation doesn't create or modify a management-group hierarchy. Expanded platform also doesn't create the hierarchy, but it can apply an additional governance assignment to an existing platform management group when you provide a management group ID.

Subscription and scope requirements

Prepare the Azure subscriptions before deployment.

Requirement Foundation Expanded platform
Deployment scope Subscription scope. Tenant scope, with resources deployed into the selected platform subscriptions.
Subscriptions An existing foundation subscription. Existing management and connectivity subscriptions. For a compact evaluation, the same subscription can be selected for both roles only when that layout is intentional and approved.
Management group Not used by the foundation deployment. Optional. Provide an existing platform management group ID only when governance should also be assigned at that scope.
Existing resources Existing resources aren't modified or deleted. Resources that don't match the governance baseline might appear as non-compliant in Azure Policy. Existing platform subscriptions must be ready to host shared management and connectivity resources.

Expanded platform subscription procurement, management group creation, external governance approvals, and workload subscription design are outside the deployment flow. Complete those steps before you start the expanded platform.

Permission requirements

Azure deployments use Azure role-based access control (Azure RBAC) to manage Azure resources. Microsoft Entra roles manage directory resources such as users, groups, applications, and tenant administration. A Microsoft Entra administrator role doesn't automatically grant permission to manage Azure subscriptions or resources. For more information, see Azure roles, Microsoft Entra roles, and classic subscription administrator roles.

Use the least privilege required for the deployment and remove temporary elevated access after deployment.

Permission area Required access
Foundation deployment The signed-in identity needs Owner on the selected foundation subscription, or equivalent custom access that can create subscription deployments, Azure Policy assignments, and Azure RBAC role assignments.
Expanded platform deployment The signed-in identity needs permission to start tenant-scope deployments, Owner on every selected platform subscription, and permission to create Azure Policy set definitions and policy assignments on the supplied Platform management group when one is provided.
Automatic budget creation To create the budget automatically, the deployment identity needs Cost Management Contributor, Contributor, or Owner on the subscription where the budget is created. New subscriptions might need up to 48 hours before Cost Management budget features are available.
Microsoft Entra groups If you provide organization platform administrator or partner operator groups during deployment, use Microsoft Entra group object IDs, not user object IDs. The groups can also be configured after deployment.

If a Global administrator must temporarily elevate access to manage subscriptions or management groups, remove that elevated access when the work is complete. For more information, see Elevate access to manage all Azure subscriptions and management groups.

Prepare deployment inputs

Collect the following values before you start.

Input Required for Example value Notes
Deployment prefix Foundation and expanded platform npalz Use 3-12 lowercase letters, numbers, or hyphens. Keep the prefix stable for the life of the landing zone.
Primary Azure region Foundation and expanded platform eastus Choose the approved operating region for platform resources. Check service availability, latency, data residency, and compliance needs before deployment.
Foundation subscription Foundation <foundation-subscription-id> Existing subscription that receives the foundation baseline.
Management subscription Expanded platform <management-subscription-id> Existing subscription that hosts shared platform services such as Log Analytics, Key Vault, governance, monitoring, security baseline resources, access assignments, and the optional management subscription budget.
Connectivity subscription Expanded platform <connectivity-subscription-id> Existing subscription that hosts the dedicated hub network and connectivity governance baseline.
Service owner Foundation and expanded platform platform@example.org Email address or shared mailbox for the team that owns the platform baseline. The value is used for platform ownership tags.
Monthly budget amount Foundation and expanded platform 0 Use 0 to skip automatic budget creation. Use a positive whole number only when the budget amount and budget permissions are confirmed.
Budget contact emails Foundation and expanded platform when budget amount is greater than 0 finance@example.org,ops@example.org Required when the monthly budget amount is greater than 0.
Monitoring notification emails Foundation and expanded platform ops@example.org,alerts@example.org Required in the Azure portal flow. Use shared operational recipients that remain valid after handover.
Organization platform admins group object ID Foundation and expanded platform <group-object-id> Optional during deployment. Handover isn't complete until organization-owned admin access is configured.
Partner operators group object ID Foundation and expanded platform <group-object-id> Optional. Use only when a partner or managed services team needs delegated operational access.
Platform management group ID Expanded platform contoso-platform Optional. Use only when the Platform management group already exists and should receive an additional governance assignment.
Additional allowed regions Expanded platform westus3, centralus Optional. The primary region is always allowed. Add any other regions required for disaster recovery, compliance, or services that aren't available in the primary region.

Plan regions and naming

Choose a primary Azure region that meets the organization's compliance, data residency, latency, and service availability needs. Azure services and features aren't available in every region, so check the services that the platform and planned workloads require before deployment. For more information, see Select Azure regions.

Foundation doesn't enforce an allowed-locations policy. Expanded platform applies an allowed-locations policy to the selected platform subscriptions. The primary region is always included, and you can add other approved regions during deployment.

The deployment creates a platform Key Vault. Key Vault names are globally unique, and a soft-deleted vault can block reuse of the same name until the vault is purged or the retention period expires. If a previous deployment used the same naming pattern, confirm that no soft-deleted vault is blocking the new deployment. For more information, see Azure Key Vault recovery management with soft delete and purge protection.

Plan cost decisions

Estimate the recurring platform costs before deployment. Actual costs depend on region, currency, agreement type, usage volume, and the options you enable. Use the Azure pricing calculator with the target subscriptions and agreement pricing when you need an estimate for approval.

Decision Cost guidance
Monitoring data volume The Log Analytics workspace is usually the most usage-sensitive baseline cost. Costs grow with diagnostic log ingestion, retention, and any future workload telemetry. For a small platform baseline, ingestion can stay modest; for busy subscriptions or long retention, it can become a main monthly cost driver. Review Azure Monitor pricing.
Key Vault usage The shared platform Key Vault is typically a lower-order cost for small baseline usage, but costs grow with secret, key, and certificate operations, premium key choices, and certificate renewals. Review Key Vault pricing.
Key Vault network firewall The deny-by-default Key Vault firewall doesn't add an Azure service charge. The public endpoint remains enabled unless private connectivity is selected, but the firewall has no IP or virtual-network allow rules and doesn't allow a trusted-service bypass.
Private Key Vault connectivity Private endpoint access adds private link charges and can add networking and DNS operational overhead. Enable it when durable Key Vault data-plane access is required and the recurring cost is approved. Review Azure Private Link pricing.
Microsoft Defender for Cloud The optional Defender baseline can create recurring security-plan charges. It can be materially higher than the core platform baseline when subscriptions contain protected resources. Enable paid plans only after the security owner approves the recurring cost. Review Microsoft Defender for Cloud pricing.
Future connectivity resources Expanded platform can reserve a GatewaySubnet, but it doesn't deploy a VPN gateway, ExpressRoute gateway, Azure Firewall, DDoS Network Protection, or workload spokes. Those resources can add significant recurring charges if you add them later. Estimate them separately before implementation.

Plan budget decisions

Decide how the deployment should handle the monthly subscription budget.

Decision Guidance
Budget scope Foundation creates the budget on the foundation subscription. Expanded platform creates the budget on the management subscription.
Creation timing Create the budget during deployment only when the subscription and permissions are ready. Use 0 to skip automatic budget creation and create the budget manually after deployment.
Monthly amount Enter a non-negative whole number in the target subscription billing currency. Use an amount that matches the organization's approved operating budget for the platform baseline.
Budget contacts When the monthly budget amount is greater than 0, provide one or more budget contact email addresses. Use durable finance or operations recipients that can receive 80% and 100% budget notifications.
Budget readiness Automatic budget creation requires Cost Management Contributor, Contributor, or Owner on the target subscription. New subscriptions might need up to 48 hours before Cost Management budget features are available. If these prerequisites aren't ready, use 0 and create the budget manually later. For more information, see Create and manage budgets.

Plan security decisions

Review security-related choices before deployment.

Choice Guidance
Microsoft Defender for Cloud Defender coverage for Key Vault and storage is optional and paid. The default leaves existing paid Defender plan settings unchanged. Defender plans for App Service, SQL, Virtual Machines, and Kubernetes aren't enabled by this deployment. Enable them separately when those workloads exist and recurring charges are approved.
Key Vault purge protection Foundation leaves purge protection off by default so evaluation deployments remain easier to remove. Expanded platform enables purge protection by default for steady-state platform environments. Turn purge protection on before storing platform secrets that must survive accidental deletion.
Key Vault network access The default public endpoint is protected by a deny-by-default firewall with empty IP and virtual-network allowlists. Treat these allowlists as deployment-owned and use private connectivity when durable Key Vault data-plane access is required.
Private Key Vault connectivity Private endpoint access changes how administrators and workloads reach Key Vault. Enable it when durable private data-plane access is required and DNS/network operations are ready to support it.

Plan monitoring and handover

Monitoring notification emails are required in the Azure portal flow because the baseline creates service health and planned maintenance alert routing. Use durable shared mailboxes or distribution lists instead of temporary deployment users. If an advanced deployment path leaves monitoring recipients empty, configure them before treating the environment as alert-response ready.

Organization platform administrator and partner operator groups are optional during deployment. If those group object IDs are left blank, the deployment can still succeed, but handover isn't complete until customer-owned operational access is configured and verified.

Plan networking

Foundation networking is optional. When selected, foundation creates a simple single-subscription virtual network baseline. The application subnet has defaultOutboundAccess disabled and uses an NSG that denies internet ingress and egress. The baseline doesn't create NAT Gateway, Azure Firewall, a route table, or another outbound connectivity method. Workload teams must add only the required higher-priority NSG allow rules and an approved explicit outbound design.

If you enable private endpoint access for Key Vault in foundation, you must also enable the simple network baseline.

Expanded platform creates a dedicated hub virtual network in the connectivity subscription. You can reserve a GatewaySubnet so a VPN gateway, ExpressRoute gateway, or Azure Virtual WAN can be added later, but this deployment doesn't create those gateway resources or connection objects.

This deployment doesn't create Azure Firewall, DDoS Network Protection, workload spokes, workload peering, or application workloads. Plan those capabilities separately when they're required.

Next steps

  • Last updated on