Considerations and limitations for Azure landing zone for Nonprofits

Review these considerations when you need to understand what Azure landing zone for Nonprofits does and doesn't do. For deployment planning and required inputs, see Plan and prepare to deploy Azure landing zone for Nonprofits. For deployment steps, see Deploy and configure Azure landing zone for Nonprofits.

For a diagram-based view of the deployment profiles and platform topology, see Azure landing zone for Nonprofits architecture.

Installer scope

Azure landing zone for Nonprofits deploys a platform baseline. It doesn't deploy application workloads, migrate existing workloads, design workload network topology, or replace customer security and operating model decisions.

Use the deployment result and post-deployment tasks to confirm what was created, skipped, or deferred before treating the environment as ready for operations.

Customer responsibilities

The organization and its implementation partner remain responsible for decisions and operations outside the deployment scope.

Before and after deployment, confirm ownership for:

  • subscription selection, subscription readiness, and any required management-group hierarchy
  • regulatory, data residency, and regional requirements
  • budget approval, cost monitoring, and recurring charge acceptance
  • workload architecture, workload security, and workload migration
  • operational ownership, alert response, and incident management
  • ongoing maintenance, lifecycle management, and updates to deployed resources when Azure services, APIs, or resource versions change
  • privileged access review and removal of temporary deployment access

Azure landing zone for Nonprofits provides baseline controls and follow-up signals. It doesn't certify that every workload, operating process, or security requirement is complete.

Foundation boundaries

Foundation deploys into one existing subscription. It doesn't create, modify, or require a management-group hierarchy.

You can use Foundation with an empty, near-empty, or existing subscription. Existing resources stay in place. The deployment doesn't move, delete, or reconfigure existing resources outside the landing-zone-managed resource groups.

Foundation doesn't assign an allowed-locations policy. If the organization needs regional deployment restrictions, use the expanded platform or apply separate governance after deployment.

Expanded platform boundaries

Expanded platform requires existing management and connectivity subscriptions. The deployment doesn't create subscriptions.

Expanded platform can apply governance to an existing platform management group when platformManagementGroupId is supplied. It doesn't create or reorganize the management-group hierarchy.

For compact evaluations, you can select the same subscription for both management and connectivity only when that layout is intentional and approved. For steady-state operations, separate platform subscriptions usually provide clearer ownership and separation of duties.

Governance behavior

Foundation applies the baseline governance controls for the foundation subscription, but it doesn't enforce allowed locations.

Expanded platform applies required platform tags and allowed-locations governance to the selected platform subscriptions. If an existing platform management group is supplied, expanded platform can also add governance at that scope.

Review existing resources after deployment. The deployment doesn't move or delete them, but Azure Policy compliance views can show whether resources match the governance baseline that applies to the selected path.

Cost-sensitive choices

Some deployment options create recurring charges or require separate cost approval.

  • Budget creation is optional. Use 0 for the monthly budget amount to skip automatic budget creation.
  • Log Analytics costs depend on diagnostic log volume and retention.
  • The Key Vault network firewall and Foundation NSG don't add Azure service charges.
  • Private endpoint access adds private link and DNS operational considerations.
  • Microsoft Defender for Cloud coverage for Key Vault and Storage is optional and paid.
  • Future connectivity services, such as VPN gateways, ExpressRoute gateways, Azure Virtual WAN, Azure Firewall, and DDoS Network Protection, are outside the deployment and must be estimated separately.

Defender coverage

The optional Defender baseline can enable paid Defender coverage for Key Vault and storage when approved. Existing paid Defender plan settings remain unchanged when the Defender baseline is set to none.

Azure landing zone for Nonprofits doesn't enable Defender plans for App Service, SQL, Virtual Machines, or Kubernetes. Enable workload-specific Defender plans separately when those workloads exist and recurring charges are approved.

Key Vault lifecycle and access

The deployment creates a platform Key Vault. Key Vault names are globally unique, and a soft-deleted vault can block reuse of the same generated name until the vault is recovered, purged, or the retention period expires.

Foundation leaves purge protection off by default for evaluation reversibility. Enable purge protection before storing platform secrets that must survive accidental deletion. Expanded platform enables purge protection by default unless it's disabled for evaluation teardown.

The Key Vault public endpoint is enabled by default, but its firewall denies public IP and virtual-network data-plane traffic. The deployment supplies no firewall allow rules and doesn't allow a trusted-service bypass. Treat the IP and virtual-network allowlists as deployment-owned and use private connectivity for durable data-plane access.

Private Key Vault access changes the network path that administrators and workloads use. Enable private endpoint access when durable Key Vault data-plane access is required and DNS/network operations are ready to support it.

Networking limits

Foundation networking is optional. When you enable it, the application subnet disables defaultOutboundAccess and uses a network security group (NSG) that denies internet ingress and egress. Workload teams must add narrowly scoped higher-priority allow rules and an explicit outbound connectivity method when required. If you enable private Key Vault access in foundation, you must also enable the simple foundation network baseline.

Expanded platform deploys a dedicated hub network in the connectivity subscription. It can reserve a GatewaySubnet, but it doesn't create a VPN gateway, ExpressRoute gateway, Azure Virtual WAN, public IP address, or connection object.

The deployment doesn't create NAT Gateway for foundation, Azure Firewall, DDoS Network Protection, workload spokes, workload peering, or application network connectivity. Plan those capabilities separately when they're required.

Foundation to expanded platform transitions

Azure landing zone for Nonprofits doesn't automatically peer an existing foundation virtual network with a new expanded platform hub. If the existing foundation virtual network must stay reachable during a transition window, use Peer a foundation virtual network with an expanded platform hub.

This procedure applies only to existing foundation deployments that include the simple network baseline. It isn't a general migration path for all workloads.

The existing foundation and the new expanded platform address spaces must not overlap. Remove temporary peerings after workloads no longer depend on connectivity to the existing foundation virtual network.

Readiness after deployment

A successful deployment doesn't always mean the environment is ready for steady-state operations. Items such as customer-owned administrator access, partner operator access, budget creation, private connectivity validation, and alert-response readiness can still require follow-up.

Review the deployment result and complete follow-up actions before handover. For more information, see Post-deployment tasks for Azure landing zone for Nonprofits.

See also

  • Last updated on