2. Choose the deployment scenario

Readable vector view · pan horizontally on smaller screensOpen full-size SVG

2. Choose a scenario and size the learning environment

Start with the workload and operational requirements, not the deployment script. Azure Local is useful when applications need local execution, low-latency access to equipment or data, and a consistent Azure management experience. Azure-hosted VMs or managed AKS may be simpler when there is no local execution requirement. Connected Azure Local still needs its documented outbound endpoints; this guide does not describe disconnected operation.

Understand the actual lab topology

Azure management plane / Australia East resource region
                         |
LocalBox-Client — Standard_E32s_v6, 32 vCPU, 256 GiB
  +-- AzLHOST1 — nested Azure Local node, 96 GiB
  +-- AzLHOST2 — nested Azure Local node, 96 GiB
  |     +-- clustered storage, resource bridge, workload VMs / AKS
  +-- AzLMGMT — nested management host
        +-- domain controller / DNS
        +-- router / NAT and workload-network routing

The two node allocations consume 192 GiB before the management host, appliances, and outer operating system are considered. Memory assigned to a nested host is not all available to application guests. The sample VM is only 2 vCPU and 4 GiB; the AKS exercise uses one worker plus its control plane. These are learning sizes, not application sizing recommendations or highly available AKS designs.

Reserve networks before provisioning workloads

1. Check for address conflicts with your workstation, VPN, Azure virtual network, and existing lab networks. A VLAN label alone does not establish routing or security isolation.
2. Reserve the platform infrastructure pool, AKS control-plane/node/VIP addresses, and VM pool without overlap. Keep the router and DNS addresses reachable from each intended network.
3. Plan access through Bastion to LocalBox-Client, then through AzLMGMT where necessary. The second-level workload subnet is not automatically routable from Azure Bastion.
4. Inspect the outer host before adding workloads. Preserve free memory and storage for infrastructure operations; do not increase guest sizes merely because virtual CPUs can be overcommitted.

# Run on LocalBox-Client, not on your personal workstation.
Get-VM -Name 'AzLHOST1','AzLHOST2','AzLMGMT' |
  Select-Object Name, State, ProcessorCount,
    @{Name='StartupGiB';Expression={$_.MemoryStartup / 1GB}}
Get-Volume | Select-Object DriveLetter, HealthStatus, SizeRemaining, Size

Keep the public guide public-safe

Budget for the outer VM, managed disks, Bastion, NAT gateway, public IPs, storage, and monitoring. Deallocating the VM does not remove all charges. Use your own approved cost estimate and cleanup plan; the recorded lab is not a pricing quote.

2.1 Convert the scenario into a measurable admission contract

Before chapter 3, the service owner supplies peak/steady CPU, committed memory, usable storage, IOPS/latency, growth, maintenance windows, dependency criticality, data classification, and supported guest/application versions. Specify RPO (acceptable data loss) and RTO (acceptable recovery duration) as approved values; “high availability” is not a value. The lab has not established either objective. Size the physical design for the surviving capacity after the largest allowed node/fault-domain loss, including platform appliances, AKS control planes, update drain, and rebuild overhead. Count usable resilient capacity, not the sum of raw drives or provisioned virtual disks.

Proposed physical target: validated nodes, independent power feeds and appropriately separated racks/fault domains, redundant switches/links, and N+1 compute headroom must align with the selected supported topology. CSV access and S2D resiliency permit shared workload placement but do not make every simultaneous fault survivable. Confirm the exact mirror/parity scheme, supported node count, repair reserve, quorum model, and witness reachability with the OEM/platform team. A witness is a quorum vote, not backup or a third copy of workload data. Keep backups and recovery dependencies outside the cluster failure domain and prove restores with application-consistent checks.

Observed lab limitation: the outer VM, its disks, virtual switches, nested router, and domain services are common dependencies for both simulated nodes. A successful nested-node exercise cannot validate rack/power isolation, NIC redundancy, RDMA throughput, or production S2D fault tolerance. Outer-VM loss can remove all nodes at once. Do not report a platform resiliency design as tested merely because two nested node names exist.

2.2 Approve flows, not just address ranges

Use the full Azure Local firewall matrix and release-specific AKS/bridge requirements as inputs. An Azure subscription, Local management group, or Arc registration creates no packet route. Arc infrastructure Private Link is not an assumed option. Network ATC owns the converged switch and cluster migration-network configuration; use its supported intent/override paths, not ad hoc per-host edits. Workload logical networks consume the existing supported switch; they do not repair an incorrect physical trunk.

2.3 Record ALZ decisions and stop/go ownership

The architecture page separates the single-subscription lab from the proposed ALZ Local hierarchy. Map this stage's resource-organization decision to Local's Azure Local Clusters and Applications subscriptions; map shared identity, connectivity, management and security services to the corresponding Platform subscriptions. Tenant/billing and identity decisions establish authorized scope; network and management decisions establish reachability and recovery; governance/security establish policy and privileged access; automation records the pinned configuration and reversible change. These are design decisions, not resources already deployed here.

The platform owner approves capacity and supported hardware; network/identity owners approve flows and AD dependencies; the workload owner approves RPO/RTO and restore tests; security reviews access and logs; the cost owner approves the disposable scope. Start applicable Azure Policies in Audit, checking aliases, resource types, API versions, bridge deployment and upgrades before Deny. Do not broadly require public-network-disabled on every resource: that can break supported Arc infrastructure. Remediation identities receive only the necessary scope, not tenant-wide administration.

Exit evidence: approved IP/pool reservations, capacity arithmetic, support matrix, masked role/tenant/billing fields, dependency tests, and an owned rollback/cleanup record. If capacity, DNS or policy compatibility fails, stop before creation and revise that input. Roll back the proposed reservations/configuration through their owners; do not erase existing cluster networks or shared dependencies. Re-enter only after the failed gate has repeatable evidence.

Sources

• Pinned LocalBox entry point and allowed VM sizes; memory and network configuration.
• Official LocalBox connection and nested routing guidance.
• Microsoft Learn: production workload isolation, availability, and dependencies.