I learned about Azure Arc a couple of years ago so it’s been around for some time, but surely seems to be gaining some exposure and popularity.
This post is intended as a very quick introduction to Azure Arc and I intend to cover additional Azure Arc features in upcoming blog posts.
What is Azure Arc?
Azure Arc is an Azure based service where non-native Azure compute workload telemetry and can be delivered directly to Azure tenants for a number of Azure services. Azure Arc is a flexible form of connectivity intended to deliver security, management options, and governance across an opportunistic environment. You can find more from Microsoft’s website site here https://azure.microsoft.com/en-us/products/azure-arc
How can Azure Arc be Deployed?
At the time of this writing, non-Azure compute workloads can consist of Linux and Windows servers, as well as Kubernetes and SQL servers. Once the workload has been provisioned with Azure Arc, the workload will appears within the tenant as if the workload is present and hosted in Azure. This is particularly helpful where regulatory compliance and system configurations can be managed and applied. Not only can the workload be managed in a SCCM-style pane of glass, but the the Arc agent can be leveraged for other Azure services as well, such as log collection for Microsoft Sentinel.
What does Azure Arc Cost?
Currently, Azure Arc is offered to deployed free of cost which includes some baseline features but any serious feature opportunities come at additional costs. We will review some of the additional features beyond the free plan in future posts.
How to Provision a Workload to Azure Arc
Provisioning an non-Azure system is quite straight forward and already well documented so there’s no real need for me to repeat what already exists out there. Generally speaking, the deployment process requires simply logging into a desired tenant, search for Azure Arc, then select the deployment style. If the required workloads to be provisioned are single digit in quantity, one can simply select the “Add a Single Server” route but deploying more, you will probably prefer the “Add multiple servers”option. Both options produce a Powershell script but there is one differentiating factor; the single server option relies on the installing user to add Azure credentials within the installation process, whereas the multiple server option requires an Azure Service Principal for ease of installation.
After downloading the Powershell script, the script can be deployed using your favored RMM tool, or the tedious manual process if the workload count is low. It’s literally that straight forward.
Conclusion
In this post, we took a brief look at Azure Arc, some of it’s benefits, and a general idea for how it is installed. Keep an eye out for future posts which will go into more detail of some features, both free and paid.
If you enjoyed this post or were able to take anything from it, consider buying someone else a coffee the next time you’re in line – make someone’s day.
