Architecture best practices for Azure Local

(Platform and workload architecture) Define reliability targets and map dependencies. Define an availability service-level objective (SLO), a recovery time objective (RTO), and a recovery point objective (RPO) for each workload flow. When you calculate these targets, include planned maintenance, platform updates, hardware support, Azure connectivity, facility reliability, and operator response time. For more information, see Reliability metrics.

(Platform and workload architecture) Analyze and test failure modes. Use failure mode analysis to model failures across facilities, Azure connectivity, machines, storage, networks, VMs, applications, and operations. Identify correlated failures and single points of failure, and assign mitigations and owners. Before production, after material changes, and on a documented schedule based on workload criticality, test failover, failback, and recovery. Record the results and remediate any test that misses the workload SLO, RTO, or RPO target.

(Platform architecture) Use Premier Solution hardware for new hyperconverged deployments. Design around and procure an exact Premier Solution SKU and bill of materials from the Azure Local catalog that meets the workload capacity, performance, fault-domain, location, and lifecycle requirements. Premier Solutions provide the highest level of partner integration and validation, arrive preinstalled and preconfigured, and integrate firmware and driver servicing with the Azure Local update process. Use an Integrated System only when no Premier Solution meets a documented requirement, and record the additional deployment, update, and support responsibilities in the architecture decision.

(Platform architecture) Select and design a deployment architecture that provides the required fault-domain isolation.

• A standard hyperconverged deployment can contain 1 to 16 machines. Use a single-machine deployment only when workload interruption during machine failure or maintenance is acceptable. Use two or more machines for host-level high availability, and design redundant power, network adapters, switches, and storage paths to remove single points of failure.
• A rack-aware cluster distributes a single hyperconverged instance across two local availability zones in separate racks, rooms, or buildings. It can tolerate a rack failure, but it requires a new deployment, equal machine counts in each zone, all-flash storage, a dedicated storage network, and round-trip latency of 1 ms or less. Supported sizes range from 1+1 through 4+4 machines. Rack-aware clusters don't support external SAN storage.
• A disaggregated deployment separates compute from SAN storage and can scale from 1 to 64 machines. Design redundant Fibre Channel or iSCSI fabrics, multipath connectivity, controllers, and storage fault domains according to the supported disaggregated network reference pattern and SAN vendor guidance.
• Connected two-machine and rack-aware clusters require a cloud witness, which Azure Local creates in Azure Storage during deployment. Maintain outbound HTTPS connectivity on port 443 from every machine to Azure Storage, monitor the witness resource status, and follow the documented two-key rollover sequence if you rotate the storage account keys. For more information, see Deploy a cloud witness.

(Platform architecture) Reserve compute capacity for failures and maintenance. Use the Azure Local sizer to model normal demand, failover demand, update operations, and growth. For highly available workloads, reserve enough capacity to absorb the largest intended machine failure. If workloads must also tolerate a machine failure during maintenance, model the concurrent loss or unavailability of two machines. Validate that the surviving machines can meet workload targets under each intended condition rather than relying only on an N+1 or N+2 label.

(Platform architecture) Design storage resiliency for the deployment type.

• For hyperconverged deployments, select the appropriate Storage Spaces Direct resiliency and capacity efficiency. Three-way mirroring provides high performance and can tolerate two fault domains for standard clusters with enough machines. Rack-aware clusters require rack-level nested mirroring and support only two-way or four-way mirror volumes. For more information, see Fault tolerance and storage efficiency and rack-aware cluster requirements.
• For disaggregated deployments, align LUN, pool, controller, fabric, and replication design with the SAN failure domains. Test path failure and controller failover, and don't treat SAN redundancy as a substitute for backup.

(Platform architecture) Maintain and verify redundant platform dependencies. Use independent power feeds and validated network topologies with redundant physical and logical paths for management, compute, storage, and workload traffic. Before production and after material changes, verify that the loss of one power feed, network adapter, switch, storage path, or SAN controller doesn't exceed the workload SLO. Treat Azure Arc resource bridge as a critical management dependency, include its unavailability in monitoring and recovery planning, and protect it from unsupported deletion through the controls described in Operational Excellence. Keep the Azure Local solution, drivers, and firmware within supported combinations. For more information, see Infrastructure resiliency for Azure Local.

(Platform architecture) Keep hardware drivers and firmware in an OEM-supported combination. For Premier Solutions and Integrated Systems, use the OEM-provided Solution Builder Extension (SBE) package through the Azure Local Solution Update workflow when the model supports it. For Validated Nodes, or systems without SBE update integration, follow the OEM compatibility matrix and documented servicing process to apply an equivalent validated driver and firmware bundle. Track the hardware package version on every machine, avoid component-by-component updates outside the OEM process, and verify instance health, redundancy, and workload operation after servicing.

(Virtual machine resiliency) Design VMs and applications to survive infrastructure failures. If a surviving machine has sufficient capacity, Azure Local can restart an affected VM on that machine. This restart interrupts service and doesn't make a singleton application highly available. Deploy at least two application instances for each critical workload tier, use health-aware traffic routing, and replicate state. Distribute their VMs across physical machines or local availability zones, and place their VHDs on separate storage paths where possible. On standard clusters, use anti-affinity where supported. On rack-aware clusters, assign redundant VMs to different local availability zones. Use non-strict placement, which is the default, when a VM must fail over to the other zone. Use strict placement only when the VM must remain in its assigned zone, such as for a compliance requirement, because it goes down if that zone fails. Choose the placement when you create the VM because updating the placement configuration of an existing VM isn't supported. Rack-aware clusters don't support VM affinity rules. For more information, see Virtual machine resiliency for Azure Local.

(AKS workload resiliency) Spread AKS nodes and workload replicas across rack-aware cluster zones. Configure the AKS control plane and worker nodes to spread across the physical machines and zones. Use more control-plane nodes than the number of physical machines in one zone, and size worker node pools to distribute nodes across all physical machines. Verify the resulting zone distribution because the underlying availability sets aren't zone-aware. Deploy multiple pod replicas with Kubernetes pod anti-affinity. Test rack failure and recovery. Don't treat this design as control-plane high availability because rack-aware clusters have only two zones and a zone failure can affect the control-plane majority.

(Workload resiliency) Separate local high availability from disaster recovery. A cluster, including a rack-aware cluster, remains one Azure Local instance and one administrative and storage failure boundary. For highly critical or latency-sensitive workloads, deploy across two or more independent Azure Local instances or locations to mitigate brief performance variations that can occur during VM live migration. Select application-native replication, Hyper-V Replica, or a supported Azure Site Recovery configuration based on the workload RTO, RPO, consistency, and failover requirements. Document target capacity, identity, network and DNS dependencies, startup order, traffic cutover, failback, and Azure management reconnection. Test planned and unplanned failover before relying on the design, and run a nondisruptive test failover at least monthly for critical workloads. For more information, see Workload resiliency for Azure Local and Redundancy recommendations.

(Virtual machine and workload resiliency) Implement and test backup and recovery. Storage and cluster redundancy don't protect against data corruption, accidental deletion, ransomware, or site loss. Never store backup data on the same Azure Local instance as the protected workload, and don't host the only backup repository on that instance. Keep backup copies, repository services, and credentials outside the source instance's administrative and storage failure boundary. Maintain an isolated or immutable copy. If you require recovery from a site failure, store a copy in a different physical location. Set backup frequency to meet the workload RPO, and set retention based on recovery and compliance requirements. Regularly test file, application, and full-VM recovery. Evaluate Microsoft Azure Backup Server and supported partner products. The Azure Site Recovery extension for Azure Local VMs (preview) is only for test environments. For production replication from Azure Local to Azure, manually configure the supported Hyper-V-to-Azure architecture. Treat replication as disaster recovery, not as a backup substitute, and review the current recovery and failback limitations before adoption.

(Platform architecture) Preserve the security baseline and drift protection. Azure Local automatically applies the security baseline during deployment and assigns the AzureWindowsBaseline Azure Policy Machine Configuration to each physical machine in Audit mode to report compliance with the Azure compute security baseline. This assignment doesn't configure or remediate settings. Keep drift control enabled through the deployment-installed AzureStackOSConfigAgent PowerShell module, which refreshes protected security settings every 90 minutes. View and download the security settings for the deployed Azure Local solution version, OS build, and identity model. The expected Audit compliance score can be less than 100% by design because settings such as minimum password length are customer-defined and aren't protected by drift control. Configure these settings according to your organization's requirements, investigate other noncompliance, and permit exceptions only when they have an owner, compensating control, and expiration date.

(Platform and workload architecture) Map regulatory requirements to assurance evidence. For hyperconverged deployments, review Azure Local and security standards for certifications, evaluation status, and implementation guidance that apply to the deployed version. Map each required control to the platform, workload VMs and applications, external dependencies, and operational processes. Don't treat platform certification or baseline compliance as proof that the workload meets its regulatory obligations. Retain the supporting evidence, and assign an owner to each gap or exception.

(Platform architecture) Remediate hardware firmware and driver vulnerabilities. Monitor security advisories from Microsoft and your hardware OEM for the exact deployed hardware SKU. Apply security fixes by using the OEM SBE package through Azure Local Solution Updates where supported, or the OEM-documented equivalent process for Validated Nodes and systems without SBE update integration. Prioritize actively exploited and high-impact vulnerabilities, record any deferred update with an owner and compensating controls, and verify Secure Boot, Trusted Platform Module, BitLocker, network, and storage operation after servicing.

(Platform and workload architecture) Centralize security posture and threat detection. For hyperconverged deployments, use Azure Local syslog forwarding to send infrastructure security events from every physical machine to a customer-managed SIEM. In production, use TCP with server authentication and TLS; use mutual certificate authentication where possible. Don't use unencrypted TCP, UDP, or skipped certificate validation. Verify the configuration on every machine, test event delivery, correlate platform and workload events with identity and network signals, and define an owned response process.

(Workload architecture) Protect workload operating systems and applications. Platform security controls don't protect the guest operating system or applications. Apply endpoint detection and response, vulnerability management, antimalware, secure configuration, data backup and recovery processes and timely guest patching to Azure Local VMs. Use Microsoft Defender for Servers and Azure Update Manager, or equivalent controls, based on workload risk and support requirements. Monitor coverage and remediation, and include workload findings in the owned incident-response process.

(Platform and workload architecture) Use segmentation to limit the impact of a compromise. Apply the following segmentation strategies.

• Identity. Separate platform administration, workload operation, security monitoring, and backup duties. Use built-in Azure RBAC roles for Azure Local VMs, grant access at the narrowest practical scope, and regularly review privileged assignments. Use Conditional Access and time-bound elevation for privileged Azure operations. Protect emergency and local administrative identities separately from daily operator accounts.

• Network. Separate workload tiers and trust boundaries into Azure-managed logical networks. Apply network security groups (NSGs) to logical networks for a shared baseline and to Azure Local VM network interfaces for workload-specific controls. Start with deny-by-default inbound access, add only required flows, and preserve required platform management and monitoring paths. Manage these controls through Azure rather than local SDN tooling. For more information, see Network security groups for Azure Local.

• Review Recommendations for building a segmentation strategy for additional information.

(Platform architecture) Protect every platform administration identity. Azure RBAC controls Azure operations but doesn't replace controls for administration of the physical machines and cluster.

• For Active Directory-based deployments, restrict the domain users and groups that can administer the physical machines or cluster. Use a dedicated Lifecycle Manager (LCM) deployment account with a unique password for each instance, scope its delegated permissions to that instance's dedicated organizational unit (OU), and tightly control and monitor access to the account. Treat the OU as an Azure Local platform boundary, not as a conventional Windows Server OU: block Group Policy inheritance to prevent inherited policies from conflicting with the platform configuration. Use the Active Directory preparation PowerShell module to automate this configuration, or meet the same requirements through your existing AD process. The LCM account is a local administrator on every physical machine and is used for servicing, repair, scale-out, and domain-join operations. For routine physical-machine administration, nest a dedicated AD operator group in the local Administrators group on each machine. Limit membership to approved, trained operators, monitor changes, and regularly review access.
• For local identity with Azure Key Vault deployments, maintain the non-built-in local administrator account used across the physical machines, use one Key Vault per instance, and restrict who can retrieve local administrator, RecoveryAdmin, and BitLocker recovery secrets. Limit vault role assignments to approved operators and the required Azure Local managed identities, and alert on Key Vault access or backup failures.

(Platform architecture) Secure every customer-owned infrastructure management plane. Isolate and restrict administrative access to baseboard management controllers, network switches, SAN controllers, backup systems, and facility-management interfaces. Use a segmentation strategy with dedicated management networks and privileged identities, protect credentials in an approved secrets system, disable unused services, control vendor remote access, and collect security logs where supported. Assign owners for firmware and certificate lifecycle, vulnerability remediation, and periodic access review.

(Platform and workload architecture) Manage the identity and credential lifecycle. Use Microsoft Entra ID for Azure control-plane access and a trusted identity provider for workload access. Require multifactor authentication for privileged operations, avoid shared accounts, and store credentials in an approved secrets system. For hyperconverged deployments, use the supported Azure Local secret rotation workflows for the Lifecycle Manager (LCM) deployment user password, cloud witness keys, applicable service principal secrets, and internal infrastructure secrets so that dependent secret stores remain synchronized. Respond to expiration and suspected-compromise alerts, use the procedure for the deployed software version, and verify platform operations after rotation.

(Platform and workload architecture) Classify and protect data. Use workload data classification to set segmentation, encryption, key-management, backup, retention, and recovery requirements. Keep BitLocker enabled for Azure Local boot and locally managed data volumes, and export recovery material to an access-controlled location outside the instance. For disaggregated deployments, require SAN encryption at rest and resilient external key management. Encrypt application traffic across workload and management trust boundaries.

(Workload architecture) Use trusted launch for supported Azure Local VMs. Require generation 2 images, Secure Boot, and virtual Trusted Platform Module protections unless a documented workload constraint prevents the use of these protections. For more information, see Trusted launch for Azure Local VMs.

(Platform and workload architecture) Continuously verify security controls. Use Azure Policy at the management-group or subscription scope to report platform and workload compliance. Apply deny, modify, or deploy effects only to supported resource types after testing their operational impact. Don't treat an AzureWindowsBaseline Audit result as enforcement or remediation. Use exemptions only with an owner, compensating control, and expiration date. For examples, see Azure policies.

(Platform and workload architecture) Build a lifecycle cost model. Include acquisition, facilities, support, software, Azure services, workload migration, backup, recovery, operations, and refresh costs. Allocate shared platform costs to workload owners and review estimates against actual usage.

(Platform architecture) Choose the lowest-cost architecture that meets the reliability and performance targets. Compare standard hyperconverged, rack-aware hyperconverged, and disaggregated designs by their licensing tier, usable storage, reserved failover capacity, network fabric, support, and operational complexity. For a supported small standard hyperconverged deployment, compare switched and switchless storage-network patterns. A switchless pattern can avoid dedicated storage switches, but include its adapter and cabling requirements, topology constraints, operational complexity, and future scale-out path in the decision. Include the cost of duplicated rack infrastructure for rack-aware clusters and the SAN, redundant fabrics, and specialist skills for disaggregated deployments. Use the Azure Local sizer and validated Azure Local catalog, but validate the model with the hardware and storage vendors.

(Platform architecture) Select the Azure Local licensing tier before finalizing the architecture. Azure Local has two service tiers: L1 and L2. Connected hyperconverged deployments without SAN-attached disks use L1. Any cluster with SAN-attached disks uses L2, including a hyperconverged cluster that also uses external SAN storage. The Azure Hybrid Benefit for Azure Local, based on eligible Windows Server Datacenter licenses with active Software Assurance, applies to L1 but not L2. Include the higher L2 service fee and separate SAN, fabric, support, and skills costs in the disaggregated business case. For current terms, see Azure Local pricing.

(Platform and workload architecture) Govern metered Azure service costs. Set budgets and ownership for monitoring ingestion and retention, Defender plans, backup storage, replication, and recovery testing. Collect the minimum telemetry that supports security, reliability, and operations, and review cost per workload alongside service health. For more information, see Cost Optimization guidance for Log Analytics.

(Workload architecture) Optimize utilization without consuming resiliency headroom. Consolidate compatible workloads and use the right execution model, including VMs or AKS enabled by Azure Arc, based on operational maturity, isolation, and performance requirements. Don't place steady-state demand into compute or storage capacity reserved for failures, updates, repair, and growth.

(Platform and workload architecture) Reconcile forecast cost with measured demand. On a defined schedule, compare the lifecycle cost model with actual workload CPU, memory, storage, network, licensing, support, and metered Azure service consumption. Right-size or retire unused resources, consolidate compatible workloads, and tune data collection before procuring more capacity. Reforecast growth and update showback or chargeback so that workload owners understand both allocated platform cost and variable Azure service cost.

(Platform architecture) Use Azure as the management plane. Organize instances and workload resources into a consistent resource hierarchy, apply Azure RBAC, Policy, tags, and locks at scale, and monitor Azure connectivity as a platform dependency. Don't update or reconfigure individual machines outside supported Azure Local workflows.

(Platform architecture) Protect Azure Arc resource bridge from unsupported deletion. Don't manually delete the Azure Arc resource bridge appliance VM or its Azure resource. An appliance VM has a generated name, for example, b87c0800d573287d885ab2021e127c340ca56772d6c9c-control-plane-0-355435a4; the name varies by deployment. For Azure Local, manually deleting the Azure Arc resource bridge appliance VM or its Azure resource can leave stale service-side registrations and associations between Azure and the Azure Local instance. These inconsistencies can cause subsequent workload deployment, update, or management operations to fail. Deleting the Azure Arc resource bridge appliance without Microsoft guidance can disrupt management of the Azure Local environment and require assistance from Microsoft Support to restore management operations. For more information, see Azure Arc resource bridge maintenance operations.

(Platform and workload architecture) Use reviewed automation for repeatable changes. Apply infrastructure as code design to Azure Local workload resources, policy assignments, monitoring, alerts, and network controls. For Azure Local VMs in hyperconverged deployments, use the supported Azure Resource Manager, Bicep, or Terraform deployment methods documented in Azure Local VM management. Keep environment-specific values separate, validate changes in a representative nonproduction environment, and retain a tested rollback or recovery path. Roll out fleet-wide changes in stages, starting with representative lower-risk instances. Stop and investigate if health or performance degrades.

(Platform and workload architecture) Plan address space and network dependencies before deployment. Reserve nonoverlapping IP address ranges for platform and workload growth. Document ownership for routing, DNS, proxy, firewall, and NSG configuration. Include address exhaustion and connectivity failures in change reviews. Azure Arc Private Link isn't supported for Azure Local infrastructure or Azure Local VMs, so Arc endpoints must resolve to public IP addresses. Allow the required outbound endpoints and disable HTTPS inspection for Azure Local traffic. For new deployments, consider Azure Arc gateway to significantly reduce, but not eliminate, the endpoints that your firewall or proxy must allow. You can't enable Arc gateway after deployment. Support for Azure Local infrastructure and Azure Local VMs is generally available, but support for AKS on Azure Local is preview. For more information, see Azure Local network deployment considerations and logical networks.

(Platform and workload architecture) Implement end-to-end observability. Define a health model that maps facilities, hardware, Azure connectivity, platform, VM, and application dependencies to workload service-level indicators. Use Azure Monitor Agent and data collection rules for required logs. Add VM insights and application telemetry for VM workloads, and use Container insights, managed service for Prometheus, and workload telemetry for AKS enabled by Azure Arc where supported. Set Azure Monitor retention based on operational and compliance requirements, and route actionable alerts to an owned response process. Test that an application failure produces the expected signal and response. Avoid collecting telemetry that has no owner or response action.

(Platform architecture) Operationalize platform security-event forwarding. For hyperconverged deployments, enable Azure Local syslog forwarding as part of the platform monitoring baseline. Verify that events arrive from every physical machine, alert on collection gaps, assign owners for retention and detection rules, and retest delivery after deployment and material changes. Follow the authenticated and encrypted transport guidance in the Security section.

(Platform architecture) Use built-in cluster performance metrics. For hyperconverged deployments, use cluster performance history to query curated Health Service metrics that are dynamically aggregated across machines. Use these point-in-time metrics to investigate current cluster, machine, and volume performance and capacity. Use Azure Monitor for retained trends and alerts.

(Platform architecture) Use Azure Local LENS for supplementary fleet-level visibility. After you establish Azure Local Insights and owned alerting as the monitoring baseline, import the Azure Local LENS workbook into Azure Monitor to compare instance health, update status, capacity, machines, VMs, and AKS Arc clusters across subscriptions. Use its System Health tab to aggregate the latest system health-check results that Azure Local publishes to Azure Resource Manager and identify issues across the subscriptions you can access. The workbook and its Azure Resource Graph-based views have no additional charge. Optional Log Analytics-based performance and forecasting views incur data ingestion and retention costs. This community-driven workbook isn't officially supported by Microsoft, so don't make it the only monitoring or incident-detection path.

(Platform architecture) Operationalize daily system health checks. Review the system health checks that Azure Local runs every 24 hours, even when no update is pending. Review results for an individual instance in the Azure portal or locally by using PowerShell, and use the Azure Resource Manager results for centralized fleet review. Route Critical and Warning results to an owned response process, review the affected machines and remediation guidance, resolve the underlying issues, and rerun the checks to verify recovery. Treat these results as continuous platform-health signals and as an input to update planning. Critical results block solution updates, and Warning results require remediation or an explicit decision to bypass. After update content is downloaded, review the update readiness checks separately because they use validation logic from the target release and can produce different results.

(Platform architecture) Validate before deployment and after material changes. Run the Azure Local environment checker before deployment and use supported validation checks before updates, hardware expansion, network changes, and storage changes. Resolve failures rather than bypassing them, and retain results with the change record.

(Platform architecture) Manage the Azure Local solution lifecycle through supported orchestration. Azure Local identifies releases by year and month (YYMM). Assess each release promptly and schedule updates so every instance remains within six months of the most recent release. Before rollout, review known issues, the hardware vendor's Solution Builder Extension (SBE) release information, and the AKS versions supported by the target Azure Local release. Test and validate the target solution update and SBE package, including firmware and driver content, on a representative nonproduction instance that matches the production hardware model and configuration. Use the validation results as a quality gate, and then follow safe deployment practices to roll out the update to production instances in stages, starting with a representative lower-risk instance. If the target release doesn't support a deployed workload-cluster version, upgrade that AKS cluster through each required Kubernetes minor version before updating the platform. Apply Azure Local and available SBE content through the Solution Update workflow; don't update individual physical machines. Plan for reduced capacity while workloads are moved off each machine, pause when health checks fail, and verify platform and workload health after every update.

(Platform architecture) Use the supported lifecycle for extensions on physical machines. Keep automatic upgrade enabled for extensions that support it. Extensions that don't support automatic upgrade are updated through the Solution Update process. Monitor extension health and version consistency across the instance, and use manual extension upgrade only when the Azure Local extension-management guidance supports it. Don't manually update platform-managed extensions that the guidance excludes from manual upgrade.

(Workload architecture) Manage workload updates independently from the platform. Define update rings and maintenance windows for VM guest operating systems, applications, and AKS workload clusters. Use Azure Update Manager or an equivalent supported process for guest patching. Before an Azure Local update, inventory every AKS workload-cluster version and review What's new in AKS Hybrid and Edge on Azure Local for the versions supported by the target release, deprecations, security notices, and release-specific changes. Use the supported cluster upgrade process to complete required sequential Kubernetes upgrades before the platform update. Validate updates on representative lower-risk workloads, monitor compliance and application health, and retain a tested rollback or recovery path.

(Platform and workload architecture) Prepare support and incident response. Define health-alert ownership, escalation paths, vendor contracts, diagnostic-data handling, and runbooks for loss of Azure connectivity, hardware failure, update failure, capacity pressure, and workload recovery. Regularly exercise the runbooks and incorporate findings into automation and monitoring.

(Platform and workload architecture) Define performance targets for critical workload flows. Establish targets for latency, throughput, input/output operations per second (IOPS), concurrency, and completion time. Define these targets for normal demand, peak demand, maintenance, and intended failure conditions. Include the application, VM, compute, memory, network, and storage path in the measurement boundary.

(Platform architecture) Select a balanced, validated architecture. Use the Azure Local catalog and vendor sizing guidance to match processor, memory, adapters, switches, drives or SAN, and support limits to the workload profile. Avoid optimizing one subsystem while another remains the bottleneck.

(Platform and workload architecture) Size compute, memory, and accelerators from measured workload demand. Profile representative workloads to determine processor architecture, physical core count, clock speed, memory capacity and bandwidth, and GPU model or partitioning requirements. Validate VM vCPU, memory, and GPU allocations under production-like concurrency, including workloads with overlapping peaks. Use workload placement to limit contention and preserve the capacity reserved for failures and updates. Don't rely on aggregate core and memory capacity alone.

(Platform architecture) Size for degraded conditions and growth. Use the Azure Local sizer as an input, then verify that compute, memory, network, and storage targets remain achievable during peak demand, an intended machine or rack failure, rolling updates, storage repair, backup, and forecast growth. Define thresholds and procurement lead time for scale-out or refresh.

(Platform architecture) Design network performance for the deployment type.

• For switched standard hyperconverged deployments, use at least two dedicated RDMA-capable physical adapter ports for the storage intent, with each path connected to a different switch in the validated top-of-rack pair. Configure the intent through Network ATC, use SMB Multichannel for path resiliency and bandwidth aggregation, and configure Data Center Bridging end to end when you use RDMA over Converged Ethernet (RoCE). Use a supported fully converged intent only when reducing adapter and cabling cost outweighs traffic isolation, and validate that compute, live migration, repair, backup, and path-failure traffic don't cause workload contention.
• For rack-aware clusters, use the required dedicated storage network and validate bandwidth and latency across both local availability zones during repair and zone failure.
• For disaggregated deployments, size Fibre Channel or iSCSI paths for workload and recovery traffic, and validate multipath behavior during adapter, fabric, controller, and path failure. Don't apply S2D RDMA guidance to SAN storage paths.

(Platform architecture) Design storage performance for the deployment type.

• For standard hyperconverged deployments, use measured workload latency and throughput to select the storage media, volume resiliency, and capacity efficiency. Include repair traffic and data-efficiency processing in the model.
• For rack-aware clusters, use the required all-flash design and account for nested-mirror write amplification, dedicated storage-network capacity, and inter-zone latency.
• For disaggregated deployments, validate the complete path through host bus adapters or network adapters, redundant fabrics, SAN controllers, cache, pools, and LUNs. Size for controller or path failover, not only the aggregate SAN specification.

(Platform and workload architecture) Baseline and load-test the complete workload path. Test from representative VMs with production-like concurrency and data. Measure normal, peak, update, failover, repair, backup, and recovery conditions before production and after material hardware, firmware, network, storage, or workload changes. Use synthetic tools to isolate component limits, but use workload-level tests to determine whether the end-to-end performance targets are met.

(Platform and workload architecture) Monitor saturation and scale before targets are breached. For hyperconverged deployments, use Azure Local Insights to collect platform performance and health signals using Azure Monitor. Correlate workload service-level indicators with CPU scheduling, memory pressure, network latency and drops, storage latency and throughput, path health, and remaining usable capacity. Define scale or optimization triggers that account for procurement and change lead time.