On this page · 9 sections
Summary. AWS Systems Manager can now manage Microsoft Azure virtual machines as hybrid managed nodes, and as of 30 June 2026 it does so at no per-node charge. AWS removed the advanced-instances tier that day, so registering any number of on-premises servers, edge devices, or other-cloud instances carries no registration or per-instance fee. That tier previously cost about $0.00695 per instance-hour, near $5 per instance each month, so for a fleet of 200 Azure VMs the change removes roughly $12,000 a year. The mechanism is a hybrid activation plus the SSM Agent, which reads a VM's identity from the Azure Instance Metadata Service. One more date matters: Systems Manager Application Manager closes to new customers on 30 July 2026, though that does not touch node management. This guide walks through the setup, compares Systems Manager with Azure Arc honestly, and shows what you can actually do to an Azure VM from AWS.
The appeal is a single operations plane. If your team already runs on AWS, one agent and one console now cover EC2 instances, on-premises servers, and Azure VMs together, which is fewer tools to learn, patch, and secure.
Why this changed, and why now
Systems Manager has supported hybrid and multicloud nodes for a while, but two things made mid-2026 the moment to act. First, the price. AWS stated in its June 2026 pricing update that "you can now register any number of on-premises servers, edge devices, or instances running in other cloud environments (hybrid and multicloud nodes) with AWS Systems Manager at no registration or per-instance charge." The cost objection that used to stall multicloud rollouts is gone.
Second, the integration got cleaner. Azure VMs now register through a native path that reads identity from the Azure Instance Metadata Service, so a registered VM associates with its real Azure identity rather than a generic managed-instance ID. Together, free registration and cleaner identity make managing Azure fleets from AWS a practical default for AWS-centric teams, not a workaround. For teams already working to control multicloud spend, our guide to cloud cost optimization for Indian companies pairs well with consolidating tools this way.
The setup, step by step
The flow mirrors any Systems Manager hybrid activation, with an Azure provider flag added at registration. The table lays it out.
| Step | What you do | Where |
|---|---|---|
| 1. Create an IAM service role | Grant the agent permission to call SSM | AWS IAM |
| 2. Create a hybrid activation | Generate an Activation Code and Activation ID | Systems Manager console |
| 3. Install the SSM Agent | Run the install on the Azure VM | Azure VM shell |
| 4. Register with the Azure provider | Pass code, ID, Region, and provider | Azure VM shell |
| 5. Verify the node | Confirm it appears as a managed instance | Fleet Manager |
The registration call on the Azure VM looks like this, using the code and ID from step 2:
sudo amazon-ssm-agent -register \
-code "ACTIVATION_CODE" \
-id "ACTIVATION_ID" \
-region "ap-south-1" \
-provider "Azure"
When you pass the Azure provider, the agent reads the VM's identity data from the Azure metadata endpoint and links the managed node to the source VM. After that, the machine shows up in Fleet Manager under managed instances, and you operate it like an EC2 host. The AWS hybrid activations documentation covers the IAM role and activation details in full.
What you can do to an Azure VM from AWS
Registration is the means; the point is the tooling. Once the Azure VM is a managed node, the standard Systems Manager capabilities apply to it. None of this requires opening inbound ports, because the agent connects outbound to AWS endpoints.
| Capability | What it does | Works on Azure VMs? |
|---|---|---|
| Patch Manager | Scans and installs OS patches on a schedule | Yes |
| Run Command | Runs scripts across a fleet without SSH | Yes |
| State Manager | Holds nodes to a defined configuration | Yes |
| Session Manager | Shell access with no open inbound ports | Yes |
| Inventory | Collects installed software and config data | Yes |
| Fleet Manager | Single console view of all managed nodes | Yes |
Session Manager is the quiet security upgrade here. Because access runs through the agent's outbound channel, you can retire internet-facing SSH and RDP on those Azure VMs and still get shell access, which shrinks the attack surface. In a year when exposed infrastructure is being weaponized by automated attackers, removing open management ports is worth doing on its own.
Systems Manager or Azure Arc: pick by control plane
This is the decision most teams actually face, and the honest answer is that it depends on where you already operate. Both tools manage hybrid and multicloud fleets; they differ in direction. Systems Manager is AWS-centric and pulls other-cloud nodes into the AWS console. Azure Arc does the reverse, extending Azure's governance model to resources outside Azure by installing an Arc agent on them.
| Dimension | AWS Systems Manager | Azure Arc |
|---|---|---|
| Control plane | AWS console and APIs | Azure portal and Resource Manager |
| Direction | Pulls Azure and on-prem into AWS | Pulls AWS and on-prem into Azure |
| Best when | Your team operates from AWS | Your team is standardized on Azure |
| Core tools | Patch, Run Command, State, Session | Azure Policy, Automation runbooks |
| Hybrid node pricing | Free since 30 June 2026 | Arc control plane free; some services metered |
| Philosophy | AWS-centric operations | Azure governance everywhere |
The tie-breaker is simple: choose the plane your engineers already live in. Running Azure VMs through Systems Manager makes sense when AWS is your primary home and Azure is the secondary footprint. If your compliance, identity, and policy already run through Azure, Arc is the more natural fit. Chasing a single tool for its own sake usually costs more in retraining than it saves.
The Application Manager sunset, and what it does not affect
One change is easy to misread. AWS Systems Manager Application Manager closes to new customers on 30 July 2026; to keep using it you must sign up before that date. This is a narrow deprecation of one feature, not of Systems Manager. Hybrid and multicloud node management, Patch Manager, Run Command, Session Manager, and the rest are unaffected, and AWS points existing Application Manager users toward alternative tooling such as myApplications on the console. Read the Systems Manager release history before you plan around any single sub-feature, because the platform keeps shifting which console surface owns application grouping.
India-specific considerations
For Indian enterprises running split estates across AWS Mumbai (ap-south-1), Azure, and on-premises data centers, the free hybrid-node change lands well. Many mid-market teams here kept Azure workloads unmanaged from their AWS console purely to avoid the per-instance tier, and that reason is now gone. Two practical notes. Register nodes to the AWS Region nearest your operations, usually ap-south-1, to keep latency and data-residency sensible under DPDP expectations. And use Session Manager to remove public SSH and RDP from Azure VMs, which both tightens security and simplifies the audit trail your team has to produce. For the wider cost picture across providers, our FinOps guide for AWS, Azure, and GCP in India covers where the real savings sit.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based cloud and engineering organization, founded in 2021 and assessed at CMMI Level 5, and an AWS partner. Our senior-led teams set up hybrid and multicloud management across AWS, Azure, and on-premises fleets, standardize patching and access with Systems Manager or Azure Arc, and design for DPDP-aligned data residency. If you want to unify a split estate onto one operations plane, talk to our cloud team for a multicloud management review.
References
_Last updated: 12 July 2026._
