Azure Local and LocalBox Guide / L400 architecture and landing zones

L400 edition · Azure landing-zone design mapping · Recorded lab: October 2026 · Identifiers masked

L400 architecture: Azure landing-zone alignment

An editable six-view design pack connects the governance model to actual deployment boundaries, protocols, resource ownership, application access and operational acceptance gates. Read it alongside all six revised chapters.

Name the layers correctly: Azure Local is the infrastructure product; Jumpstart LocalBox is the sandbox used to explore it; LocalBox-Client is this lab's outer Azure VM. Azure landing zones describe the enterprise design target, not an installation performed by LocalBox. See the component overview and shared terminology reference.

Download editable draw.io pack Download six-page PDF Download all six editable SVGs

Alignment is not a compliance claim. The landing-zone hierarchy is an enterprise target design. The recorded LocalBox implementation used one disposable subscription and resource group; enterprise management-group placement, centralized security services and production recovery controls were not deployed or proven by this guide. Labels explicitly distinguish target, recorded and unverified controls.

1. Translate CAF design areas into implementable boundaries

The current Azure landing-zone reference model separates the platform landing zone from workload landing zones. Its management-group hierarchy includes Local alongside Corp and Online. Local can organize Azure Local cluster resources and application subscriptions. This is governance taxonomy, not a command that automatically moves resources across subscriptions or establishes hybrid routes.

Choose resource placement with the service's supported subscription, resource-group and custom-location constraints. A diagram with separate cluster/application subscriptions does not prove that every Azure Local VM or AKS cross-subscription arrangement is supported. Validate the actual provider/API and identity permissions before implementing separation; retain a documented exception where the service requires co-location.

CAF / ALZ design area	L400 design decision	Evidence needed for acceptance	Recorded lab boundary
Billing and tenant	Define tenant ownership, subscription vending, environment boundaries and chargeback.	Approved subscription placement and financial owner; limits, budget/action ownership; actual billing fields remain [MASKED].	No new enterprise billing hierarchy or hard spending cap was deployed.
Identity and access	Separate Microsoft Entra ID authentication and PIM, Azure RBAC, domain cluster permissions, guest SSH, Kubernetes authorization and emergency access.	Role assignments at intended scopes, approved eligible activations, successful authorization tests, and audited break-glass procedures.	Existing authorized account/domain/key paths were used; a workgroup local account was not granted new domain cluster rights.
Resource organization	Platform subscriptions own shared services. Workload teams own application resources within supported Local/Corp/Online placements.	Management-group inheritance, resource owner, lifecycle boundaries, naming/tag rules, and supported resource relationships.	One subscription/resource group. Sandbox is the intended learning model; actual enterprise MG membership was not inventoried.
Connectivity	Select hub-spoke or vWAN by requirements, redundant hybrid connectivity, compatible DNS/egress and explicit administrative paths.	Bidirectional routes, resolution, allowed endpoint tests, failure tests, firewall ownership and baseline captures.	Bastion Basic, NAT, a private outer host and nested routed VLANs; no enterprise hub/VPN/ExpressRoute was deployed.
Security	Apply supported host, Azure and Kubernetes controls without breaking resource bridge, update or guest provisioning dependencies.	Compatible policies, threat detection, image provenance, least privilege and remediation ownership.	Public ingress was not created for workloads. Enterprise Defender/Sentinel coverage was not verified.
Management	Specify diagnostic streams, DCRs, retention, alert routing, health models, update windows, backup/restore and capacity headroom.	Real events reach the intended workspace; alert action reaches its owner; restore and maintenance tests meet declared RPO/RTO.	Recorded validation, update and application observations. A workspace resource alone is not operational coverage.
Governance	Start new initiatives in compatible Audit modes, review findings, then promote individual enforcement controls with change approval.	Policy effect, scope, exclusions, remediation identity, exception owner/expiry and regression evidence.	No broad tenant policy, Credential Guard bypass or blanket cluster ACL grant was introduced.
Automation	Pin reviewed IaC/source, protect secrets, separate validate/what-if from create and preserve failure-boundary evidence.	Reproducible artifact versions, secure parameter handling, bounded retries, operation IDs retained privately and tested recovery paths.	Publisher media access required custom recovery; an unmodified end-to-end upstream reproduction is not claimed.

2. Read the six views in sequence

Reading layout: the diagrams now use compact, proportional canvases and large labels. The full L400 explanations remain as ordinary text below each view, rather than being compressed into tiny boxes. On a smaller display, pan the diagram horizontally or select Open full-size SVG; the image is not squeezed into unreadable text.

The Azure SVG icons are taken from the verified draw.io Azure2 library and embedded in the files. They remain portable when opened without access to the original icon URL. The images below are native draw.io vector SVG exports, not screenshots, with editable diagram data retained. Click a view to open its full-size SVG and zoom without raster blur, or save the SVG and open it with draw.io Desktop. The complete .drawio file has six editable page tabs. An Azure icon denotes a service type, not proof that its proposed target control was deployed.

View 01 — landing-zone governance target

Azure landing-zone target governance and current lab boundaries — Editable SVG. Proposed platform/workload ownership and the current single-subscription lab exception. Dashed governance arrows mean inheritance, not network traffic. Subscription, tenant, account, credential and billing values remain masked.

Do not model management groups as routed network segments. Network and policy changes are related decisions but require separate implementation artifacts. The diagram's platform boxes identify accountable teams for identity, connectivity, security and management; they are not a list of newly created subscriptions.

View 02 — actual Azure deployment and nested network

Recorded Azure VNet, Bastion, NAT and nested LocalBox networks — Editable SVG. Recorded outer-host access and nested-network boundaries. This model does not invent Azure subnet prefixes or pretend that the nested VM subnet is automatically reachable through Bastion.

Browser access reaches Bastion over HTTPS; Bastion reaches the outer host over private RDP 3389. Hyper-V console/PowerShell Direct then reaches a nested server. NAT supplies outbound translation for allowed dependencies; it is not an application firewall. Arc control connectivity does not make the cluster management network a VPN endpoint. A native-client or IP-based Bastion path requires the appropriate SKU, feature configuration and actual routing—not only an Arc resource ID.

Detailed addresses, outside the diagram: the recorded outer Azure NIC is 172.16.1.4. Its nested management vNIC is 192.168.1.20; AzLMGMT is 192.168.1.11, the nested router is 192.168.1.1, and DNS is 192.168.1.254. These are different interfaces and routing scopes, not alternative addresses for one Azure subnet. The lab's workload VLAN 110 uses 10.10.0.0/24 and VLAN 200 uses 192.168.200.0/24. Exact Azure VNet subnet prefixes are intentionally not asserted without evidence.

View 03 — runtime fabric, storage and identity

Azure Local fabric, node networks, shared storage and quorum dependencies — Editable SVG. Node membership, VM ownership, CSV coordination, storage durability and quorum are separate responsibilities. Physical target requirements are explicitly marked as additional evidence, not represented as properties of nested hardware.

Storage Spaces Direct uses the cluster's real storage layout. A cloud witness contributes to quorum; it neither stores workload copies nor supplies a third execution node. A CSV owner is its coordinator, not necessarily the node running a VM stored on that CSV. The final Azure Local VM's configuration and disks remain on shared cluster storage during the supported same-cluster move.

Storage-network detail: StorageA uses 10.71.1.10 on AzLHOST1 and 10.71.1.11 on AzLHOST2, VLAN 711. StorageB uses 10.71.2.10 and 10.71.2.11, VLAN 712. SMB storage communication and any physical RDMA design must be validated against the actual supported hardware/network reference; nested virtual switches do not demonstrate production RDMA capability. Each recorded node was allocated 96 GiB. Available memory is dynamic and must be checked before placing or moving a workload.

AD DS/DNS/time services are dependencies of this AD-based lab. Microsoft Entra ID access to the Azure resource is not a substitute for domain authorization to Failover Cluster Manager. A production design must keep management identity and recovery paths available during cluster failure, and must validate physical capacity, independent failure domains and release-supported networking. Network ATC-managed configuration must be changed through supported mechanisms, not arbitrary local VLAN or switch edits.

View 04 — AKS provisioning and application access

AKS on Azure Local operator, control plane, worker, service, logical network and CLI tunnel — Editable SVG. One required control-plane VM plus one small worker is the intentional lab configuration. The resource bridge's management Kubernetes and the application's AKS cluster are not the same cluster.

Trace provisioning separately from runtime traffic. ARM and the local operator create workload VMs from a static logical network; successful provisioning does not imply both nodes are Ready. The application service selects Ready pod endpoints. A private ClusterIP is internal to Kubernetes. The diagnostic tunnel uses a local Arc API proxy and kubectl's authorized forwarding stream; port 47031 is not the website, and port 8087 is not a new public ingress.

Recorded sizing and runtime controls: the control plane used Standard_K8S3_v1 (4 vCPU / 6 GiB), and the worker used Standard_A2_v2 (2 vCPU / 4 GiB). The NGINX pod requested 25 millicores / 32 MiB and was limited to 250 millicores / 128 MiB, with readiness/liveness HTTP probes and no automatic service-account-token mount. The service's selectors must resolve to a Ready backend. These controls and the version/size discovery commands remain in chapter 4; they are not compressed into tiny diagram labels.

View 05 — VM migration and owner proof

Planned Ubuntu VM live migration, shared disk state, owner telemetry and direct guest Arc SSH tunnel — Editable SVG. Requested source-to-target sequence, not proof of a completed user move. The recorded Python observer and the new NGINX tutorial example use different guest/local ports and have different freshness semantics.

A live migration transfers running state between eligible healthy nodes and leaves shared disks in place. The guest's hostname/IP do not identify its physical owner. Read cluster Owner Node and correlate it with guest boot/application identities. The existing owner publisher writes a timestamped observation, which the app marks stale after 15 seconds. Website access uses Arc SSH to the guest identity; a private tunnel reconnect alone does not prove that the guest rebooted.

The new NGINX tutorial generates an installation/boot-time identity snapshot on guest port 8081. It is not silently upgraded into the recorded live telemetry application on 8080. When testing NGINX, query host placement separately. Do not expose a domain administrator password or cluster control API inside a workload web application.

View 06 — implementation gates and control gaps

Deployment acceptance gates and actual versus proposed landing-zone controls — Editable SVG. Stage gates require evidence before promotion. L400 detail includes stop conditions and ownership, not only additional services or arrows.

Each stage has an entry condition, authorized change, measurable exit condition and recovery boundary. A timed-out client is not a reason to submit a duplicate deployment. A disconnected local tunnel is not a reason to reboot a cluster. A failed dependency does not authorize recreating a storage pool. Retain operation evidence privately, inspect the actual failed layer and use release-supported recovery procedures.

3. Physical-target acceptance before production

Validate organization and supported scope. Confirm actual MG placement, subscription ownership, region choice, custom-location/provider relationships and operational team boundaries. The resource model must be supported, not only visually separated.
Prove end-to-end access. Test Microsoft Entra ID authorization, private administrative routing, DNS/time, local domain access, guest SSH and Kubernetes authorization independently. Do not treat success at one surface as access to all others.
Prove compatibility and capacity. Check supported hardware, patch/firmware combinations, guest support, reserve capacity, workload/storage networking and maintenance behavior at representative load.
Prove governance compatibility. Audit policies against the actual Azure Local, bridge, Arc and workload APIs. Do not assume all resources can use Private Link or survive blanket deny-public-access policies. Use the release's documented endpoint requirements.
Prove recoverability. Define workload RPO/RTO, test application-consistent backups and restore, preserve identity access and verify operational response. Quorum, mirrored storage, live migration and backup solve different failure modes.
Record evidence and unresolved gaps. Publish a design decision record and named owner for every exception. A drawing and a green provisioning state do not constitute an ALZ compliance assessment.

Sources and diagram provenance

Current Azure landing-zone model and Local management-group taxonomy.
CAF landing-zone design areas.
Azure Local hyperconverged baseline architecture.
AKS on Azure Local logical-network requirements.
Supported local-tool and Azure-control-plane VM operations.
Official draw.io Azure2 SVG library; these authored diagrams are not Microsoft reference diagrams or screenshots.