Introduction
Azure Arc provides a centralized control plane to manage, secure, and monitor performance or licensing compliance on resources running outside of Azure. This helps organizations manage virtual machines deployed across different physical and cloud locations, including on the Nutanix Cloud Clusters (NC2) solution when deployed across public clouds like AWS, Azure and Google Cloud.
By combining NC2 with Azure Arc, you can build a true hybrid cloud architecture while maintaining centralized management and compliance through the Azure control plane.
Fig 01. Workloads can be managed and via Azure Arc
Microsoft provides these instructions for connecting native AWS EC2 and Google Cloud Compute Engine instances to Azure Arc using the multi cloud connector, but what do you need to do differently for NC2 VMs?
The good news is that it's reasonably straightforward once you know how. To demonstrate this we’ll take a look specifically at running a Windows 2025 VM running on NC2 in AWS, though it could also be used for other operating systems supported by ARC on NC2 in other clouds.
Azure Arc Connected Machine Agent (AzCM)
The first thing to note is that the "multicloud connector" mentioned in the above document is designed specifically for native cloud APIs (AWS and Google Cloud) and does not possess the integration capability required to discover or manage Nutanix hosted workloads. But thankfully it's not actually required as it's really just a vehicle to install what is required, the Azure Arc Connected Machine Agent (AzCM) on your VM.
Installing AzCM can be done manually, but in an enterprise environment it's more likely to be scripted and rolled out using whatever automation / management tools you have in place. Microsoft helpfully provides a really good script generator to help with this within the Azure Portal. Broadly, the process is:
- Create a new application registration with the permissions listed in the Microsoft documentation (e.g. the “Azure Connected Machine Role”) and create a client secret.
- In the Azure Portal go to the “Azure Arc” page and click the Onboard button under machines.
This takes you to a page titled “Onboard Existing machines with Azure Arc” where you enter details (Including: Subscription, Resource group, Region, OS etc.) for the onboarding script to be generated. We disabled SQL Server for our demonstration, but if that’s something you are interested in then more information is available here.
Choose “Authenticate machines automatically” and select the service principal of the Application you registered in step 1 and then click “Download and Run script”. - Edit the Powershell script generated to add in a Client secret for the Application registered in step 1 to assign it to the “$ServicePrincipalClientSecret” variable.
- Run the Powershell script as an administrator on the Windows machine you want to manage with Azure Arc. The script downloads the AzCM agent and connects it to your Azure subscription.
For more detailed instructions on how to automate the onboarding of Windows Server instances and deploy the agent, refer to the official Microsoft documentation for connecting hybrid machines to Azure Arc.
Installing the agent is a reasonably trivial task. But what is more important is that your environment’s networking is set-up to allow the agent to connect back to Azure. Without this being set up first, the script will actually fail.
Azure Arc Connectivity Considerations
To enable Azure Arc communication, VMs running on NC2 (in any cloud) must be able to route traffic securely out to the Azure control plane, either over the internet or to a private endpoint. For simplicity we’ll just discuss connecting over the internet.
Ensure your egress routing and firewalls permit outbound traffic on TCP Port 443 to the following endpoints:
- *.his.arc.azure.com (Hybrid Instance Service)
- login.microsoftonline.com (Authentication)
The AzCM agent requires strictly outbound communication over HTTPS. No inbound ports need to be opened to your VMs either in your Nutanix Flow policies, or cloud network security groups or firewalls.
Note: The AzCM agent requires a "heartbeat" connection to Azure at least once every 30 days. If the server is disconnected for longer, Windows Server 2025 will enter a "Notification Mode" until connectivity is restored.
Security Considerations
When bridging AWS infrastructure to the Azure control plane from VMs on NC2, employ a defense-in-depth approach:
- Microsegmentation: Use Nutanix the Flow Network Security (FNS) solution to apply granular, VM-level zero-trust policies to your Windows Server workloads within the AHV cluster. - As of NCI (Nutanix CLoud Infrastructure) 7.6 FNS can do this to specific domain names (e.g. login.microsoftonline.com) but not to wild card domains (e.g. *.his.arc.azure.com) so either manual updates of the IPs or a script is needed to keep the IPs available.
- AWS Security Groups: AWS Network Security Groups can be applied at the subnet level to restrict broader ingress traffic from the public internet, ensuring that only necessary outbound traffic to the required Azure endpoints is permitted.
- Third-Party Virtual Appliances: 3rd-party networking virtual appliances (e.g., from Palo Alto) are supported with some NC2 configurations. These can be used to enforce advanced egress filtering and deep packet inspection before traffic leaves the customer subscription.
- Proxied Internet Access: If you’re using a Proxy server or service for internet access you’ll need to configure it to allow the above URLs.
- Private Connectivity: If you are operating a true multi cloud environment consider using existing connectivity (a VPN or a cross-cloud connection) to a private endpoint in an Azure VNET in your Azure tenant. You can then configure your DNS and routing to direct Azure Arc traffic securely via that private connection rather than sending it over the public internet.
Operational Considerations
Be aware that some Azure Arc features only work with certain operating systems, or operating system versions. For example, Extended Security Updates and Hot Patching are limited to specific Windows operating systems and PAYG (Pay-As-You-Go) Windows licensing can only be applied to Windows Server 2025. Additionally, some advanced functions may not work with Linux VMs, so always check the latest Microsoft documentation for the latest compatibility information.
Another key consideration is making sure that any VMs that are deleted are also removed from Arc in the Azure Portal. This is not an automatic process so configuring your monitoring or service management tools to report on this, especially to prevent overpaying on Windows or SQL licensing.
Conclusion
Besides the hybrid cloud management capabilities, one additional benefit of this architecture is the ability to leverage Windows Server 2025 Pay-As-You-Go (PAYG) licensing via Azure Arc, wherever your workloads run. The PAYG model is billed as an Azure Service to your subscription, and because it is metered via an in-guest agent, it can move with the VM as that VM moves between on premises and cloud migrations. This allows you to run Windows Server 2025 on AWS or Google Cloud bare-metal on a consumption basis, avoiding complex License Included Reserved Instance lock-ins and providing the agility to spin down dev/test instances to optimize licensing spend.
©2026 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and all Nutanix product and service names mentioned are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned are for identification purposes only and may be the trademarks of their respective holder(s).
Certain information contained in this content may link or refer to, or be based on, studies, publications, surveys, and other data obtained from third-party sources. While we believe these third-party studies, publications, surveys, and other third-party data are reliable as of the date of publication, they have not independently verified unless specifically stated, and we make no representation as to the adequacy, fairness, accuracy, or completeness of any information obtained from a third-party. Our decision to publish, link to or reference third-party data should not be considered an endorsement of any such content.
