Azure Arc-Enabled Servers: A Practical Approach

As the public cloud becomes more widely used, multi-cloud or hybrid approaches are becoming more prevalent.

These names are an attempt to respond to a common concern: how can you protect yourself by not putting all your eggs in one basket?

The Azure Arc package was created recently in response to this question. As you can see in this introductory video about the difficulties of monitoring within a hybrid environment (only available in French) it is part of a package and not a stand-alone service.

In this post, we show you a more practical way to use Azure Arc-enabled servers, the component of Arc specifically designed for managing servers in hybrid mode.

In our scenario, we will focus on using Azure to manage compute instances hosted by other cloud providers.

We will start with the architecture and then look at how to implement our hybrid monitoring.

Azure Arc Server: Design Principles

As stated in the introduction, this post is about Azure Arc server.

We can use this service to connect information about the server’s status to Azure and implement monitoring from a single point: the Azure console.

The servers are connected to Azure Arc through an agent. In reality, two agents are involved:

• The first agent, the Azure Connected Machine agent, handles the connecting part and makes it possible to obtain an inventory of the hybrid resources
• The second agent, the Log Analytics agent, which is well-known within Azure technical circles, can be used to retrieve metrics and logs from these resources.

About the Connected Machine Agent

There is a lot of information about the Connected Machine agent in the Azure documentation. Without repeating all of this documentation here, in a nutshell, this agent establishes an Azure Arc connection to the instance it is deployed on. The data transfer is protected by HTTPS, and a proxy can be set up if needed.

In terms of how it works, the Connected Machine agent comprises three components:

• The Hybrid Instance Metadata Service (HIMDS), which authenticates the server to Azure AD and manages its connection to Azure Arc
• The guest configuration agent, which, among other things, does compliance checks
• The extension agent, which lets you add other extensions, such as the custom script, Azure monitoring agent, or log analytics agent extensions

Note that traffic from servers connected to Azure Arc will go through the Internet by default, even if it is encapsulated with TLS.

In addition, the agent logs in to Azure AD using a registration application set up during the initial installation process.

What If We Want a Private Connection?

For a few years now, when designing Azure architectures, the question of a private connection has been raised. In response, the Product teams have improved the Platform as a Service (PaaS) services by creating the Private Link solution. This solution lets you maintain a connection to the PaaS instances over a completely private network.

Arc-enabled servers in a network that connects to Azure through a Private Peering ExpressRoute can use Azure Private Link Scope to keep this same schema.

As with any Private Link strategy, a server-to-Azure Arc connection architecture must be well thought out.

Please note that these concepts will not be covered in more depth in the rest of this post.

Connected Machine Agent Requirements

Some requirements must be met.

First, if the outbound traffic is controlled by an appliance that manages rules based on Fully Qualified Domain Names (FQDNs), the required URL can be found in the Azure documentation:

aka.ms

download.microsoft.com

packages.microsoft.com

login.windows.net

login.microsoftonline.com

pas.windows.net

management.azure.com

*.his.arc.azure.com

*.guestconfiguration.azure.com

guestnotificationservice.azure.com, 
*.guestnotificationservice.azure.com

azgn*.servicebus.windows.net

*.blob.core.windows.net

dc.services.visualstudio.com

The list of operating systems (OS) compatible with the Connected Machine agent can be found in the Azure documentation, as can information about compatible versions.

• Windows Server 2008 R2 SP1, 2012 R2, 2016, 2019, and 2022
• Windows IoT Enterprise
• Azure Stack HCI
• Ubuntu 16.04, 18.04, and 20.04 LTS
• CentOS Linux 7 and 8
• SUSE Linux Enterprise Server (SLES) 12 and 15
• Red Hat Enterprise Linux (RHEL) 7 and 8
• Amazon Linux 2
• Oracle Linux 7 and 8

We’ll learn more about how onboarding works in practice later on. For now, let’s focus on observability.

About Telemetry Feedback

We have only covered the Connected Machine agent up to this point. As we’ve seen, it comes with a tool for managing extensions.

Other well-known extensions in Azure interact with this component. Except for the inventory, which is based on the metadata provided by the HIMDS, no information feedback would be possible without them.

For telemetry purposes, additional agents must be installed to monitor Arc-enabled servers.

Agents to consider include old favorites like the Log Analytics agent or the long-awaited Azure Monitor Agent, which should ultimately replace a number of existing agents in the Azure ecosystem and streamline data reporting.

Agents can be added when the servers are onboarded into Azure Arc. The easiest method is to use the portal or Azure Policy.

Case Study: Managing EC2 Instances in Azure Arc Server

In the opening, we talked about a hybrid cloud strategy. In this next section, we’ll discuss how to ensure that EC2 instances in AWS remain visible from Azure.

How About IaC?

There is a lot of talk about Infrastructure as code (IaC) and many tools to choose from. The well-known Terraform from Hashicorp is one such tool.

If the IaC skills have already been developed in Terraform, the versatility of this tool may make it easier to switch to a different cloud provider in the event of multi-cloud hybridization after an initial transition to Azure. Something to consider!

Note the helpful content offered by Microsoft in the Github Azure Arc Jumpstart repository, which includes an example that matches our use case.

Onboarding an EC2 Instance

Preparation in Azure is the first step in adding an instance from another provider to Azure Arc.

The Azure portal walks the user through the onboarding process by identifying the requirements:

Here are the URLs needed for the network connectivity discussed earlier:

A target resource group and the OS of the server(s) must be specified:

Authentication follows, where we notice that an application must be registered with the Azure Connected Machine Onboarding role below:

In an IaC approach, we might consider creating the main service using the Azure Active Directory provider:

An onboarding script can be retrieved at the end of all these steps, depending on the OS selected:

Script provided for a Windows server

Script provided for a Linux server

With the Terraform templatefile() function, the user data configuration of EC2 instances can be used to automate the onboarding process.

⚠️Note: Although creating an EC2 instance is relatively quick, the onboarding process can take some time.

Once done, we can see the Arc-enabled servers in the Azure portal.

Hybrid Observability in Action

Now we have some Arc-enabled instances, let’s look at observability.

The server is visible after onboarding, but it does not show anything.

Navigate to the extension section to start retrieving information.

There, you will find the same agents that have already been suggested for the installation:

Additionally, if you have a log analytics workspace available, you can automatically enable the log analytics agent installation in Insights:

After installation, the Log Analytics and Dependency agents will be added to the extensions:

When the agents are working, the Insight section tells you about the resources used:

And about the server’s running processes:

We can see that the HIMDS process is running, which, as mentioned earlier, makes it possible to get the metadata needed for the Azure Arc inventory.

Last but not least, Azure Advisor gives us recommendations for Arc-enabled servers, especially if, as in this case, we do not yet have AzurePolicy to install the monitoring agents:

That wraps up our brief introduction to Azure Arc servers.

Find Out More about Azure Arc-Enabled

Azure Arc-enabled servers let you make servers from other providers visible in Azure. The onboarding process is straightforward, but planning is necessary to ensure scalability.

As soon as the Connected Machine agent is used to set up onboarding and inventory, observability from Azure is almost instant.

Further reading:

• Integrating onboarding credentials in a vault native to the cloud provider and, in our example, using an identity and access management (IAM) role to retrieve the secret for the main service
• Using Azure Policy, for example, to automate the installation of monitoring agents and integration with Defender for Cloud

Want to learn more about hybridization? Read the other posts in this series now:

• IoT: How to Implement a Hybrid Project?
• Defender for Cloud: Microsoft’s Security Monitoring Solution
• The hybrid workstation
• Using Spark with Kubernetes (K8s)
• Hybrid applications