Before meeting any product, understand the problem it solves. Once the problem is clear, every feature of Azure Arc looks sensible instead of random.

How estates became scattered

Few organisations are “all in one place.” Companies grow by acquiring other companies, each with its own data center. Rules about data privacy force some information to stay in a particular country or building. Factories and shops need computers right next to the machines and the customers, because a network failure must not stop the production line. Teams choose different clouds for different strengths. And some old systems cannot be moved, either because they are too fragile or because the vendor will not support them anywhere else. The result is a hybrid estate, meaning part on-premises and part in the cloud, and often a multicloud estate, meaning spread over several cloud providers.

The two obvious answers, and why they are not enough

The first answer is “move everything to Azure.” That is ideal for many workloads, but not all of them, and not at once. Migration takes years, some systems must stay where they are for legal or physical reasons, and during the long journey the estate is split anyway. The second answer is “buy a management tool for each environment.” That multiplies tools, and it still leaves no common view. Azure Arc takes a third path: leave the resources where they are and extend Azure’s management layer out to them.

An illustrative example

Consider a hypothetical retail group with 600 servers: 200 in Azure, 250 in two company data centers, 100 in another public cloud acquired with a subsidiary, and 50 small servers in stores. Before using Arc, the security team needed four consoles and three weeks to answer “which servers are missing this month’s security patch?” After connecting the 400 servers outside Azure with Arc, the same question is answered by one query across all 600 machines in a few seconds. A single policy now requires an owner tag everywhere, and updates are scheduled from one place.

Azure Arc has a manageable vocabulary. Learn these words once and every later chapter reads easily.

The words, one at a time

The central idea: the control plane travels, the workload stays

Beginners often assume that connecting a server to Azure Arc moves it to Azure, or that its data is copied to Azure. It does neither. The server keeps running exactly where it is, with the same programs and data. What Arc creates is a representation of the server in Azure Resource Manager, plus a secure two-way channel through which Azure can read information about the server and, if allowed, send management instructions to it. In technical terms, the control plane reaches out, while the data plane stays at home.

Three families of Arc

The word “hybrid” appears in many Microsoft products. Placing Arc next to its neighbours makes its job clear.

A short history

Microsoft announced Azure Arc in November 2019 at its Ignite conference, initially for managing servers and Kubernetes clusters outside Azure and for running selected Azure data services on any infrastructure. Over the following years the family grew: Arc-enabled SQL Server, support for VMware vSphere and System Center Virtual Machine Manager through the resource bridge, features such as Extended Security Updates delivered through Arc for older Windows Server versions, SSH access, and tighter links to Defender for Cloud and Azure Monitor. In parallel, Microsoft’s on-premises Azure-run platform, formerly Azure Stack HCI, was renamed Azure Local and uses Arc as its management foundation. Product names and packaging shift often, so treat any list in a book as a snapshot.

What Azure Arc gives you

What Azure Arc is not

• It is not a migration tool. Arc does not move workloads to Azure. Azure Migrate does that.
• It is not a replacement for the hypervisor or the hardware. Your virtualisation platform or physical server keeps working as before.
• It is not a VPN or a network. It needs outbound connectivity from the resource to Azure, but does not create private network links between sites.
• It is not free for everything. Connecting a server and viewing it is generally free, but many of the services you then switch on are charged. Chapter 15 explains.
• It is not required for the workload to run. If the link to Azure breaks, the server keeps serving its users. Only management actions pause.

Arc compared with related offers

Understanding the shape of the connection explains most behaviour, from what Azure can see to what happens when the network breaks.

flowchart LR
  subgraph AZ["Azure"]
    ARM["Azure Resource Manager"]
    SVC["Policy, Defender, Monitor, Update Manager, Automation"]
    HIS["Arc connected machine service endpoints"]
  end
  subgraph ONP["On-premises data center"]
    SRV1["Server with Connected Machine agent"]
    K8S["Kubernetes cluster with Arc agents"]
    BRG["Resource bridge appliance"]
    VC["VMware vCenter"]
    BRG --- VC
  end
  subgraph OTH["Another cloud"]
    SRV2["Virtual machine with Connected Machine agent"]
  end
  SRV1 -->|"outbound HTTPS"| HIS
  K8S -->|"outbound HTTPS"| HIS
  BRG -->|"outbound HTTPS"| HIS
  SRV2 -->|"outbound HTTPS"| HIS
  HIS --> ARM
  ARM --> SVC
  SVC -.->|"instructions delivered through the agent"| SRV1

Reading the diagram

On the left side are Azure’s own services: Azure Resource Manager, which records resources, and the services that act on them, such as Policy, Defender, Monitor, and Update Manager. On the right are your outside locations: an on-premises data center with a server, a Kubernetes cluster, and a resource bridge attached to VMware vCenter, and another cloud with a virtual machine. Each outside resource runs a small piece of Arc software that makes an outbound secure connection to Azure over HTTPS. Because the connection starts from inside, you do not need to open inbound ports in your firewalls for it. Instructions from Azure travel back down the same connection, delivered by the agent, so Azure can, for example, install an extension on a server that sits behind a corporate firewall.

The components

What flows in each direction

Where the records live

Every Arc-enabled resource lives in a subscription and resource group you choose, in an Azure region. The region of the record is where its metadata is stored, such as name, tags, and properties. It does not define where the server runs. Choose a region close to the machines for lower latency and to meet data-residency needs for metadata. Because the record is an ordinary Azure resource, it supports tags, role-based access control, locks, and Azure Policy, just like a virtual machine in Azure.

Follow a single server as it joins Azure Arc, and you will understand identity, trust, and the agent’s daily behaviour.

sequenceDiagram
  participant Admin as Administrator or script
  participant Agent as Connected Machine agent
  participant Entra as Microsoft Entra ID
  participant Arc as Arc service in Azure
  participant ARM as Azure Resource Manager
  Admin->>Agent: Install agent and run connect command
  Agent->>Entra: Sign in using onboarding identity
  Entra-->>Agent: Access token with limited rights
  Agent->>Arc: Request to create machine resource
  Arc->>ARM: Create Arc machine resource in resource group
  ARM-->>Arc: Resource created with managed identity
  Arc-->>Agent: Identity details and certificate
  loop Every few minutes
    Agent->>Arc: Heartbeat with status
    Arc-->>Agent: Pending extension or policy requests
  end
  Agent->>Agent: Extension manager installs extensions
  Agent->>Arc: Report extension and compliance status

Step by step

The agent’s inner services

What happens when the connection drops

The machine continues running its workloads normally. Locally evaluated settings continue, and extensions already installed keep working, although those that need Azure, such as sending data to a cloud workspace, will buffer or fail until the link returns. In the portal the machine appears as disconnected after missed heartbeats. If a machine stays offline for a long time, measured in weeks in the documentation, its certificate can expire, and it must be reconnected. Check the current documented limit when you plan for ships, remote sites, or seasonal equipment.

Identity for software on the machine

Because every Arc machine has a managed identity, programs on it can request tokens from the local endpoint and use them to call Azure services, such as reading a secret from Key Vault or writing to storage, without storing passwords on the disk. You grant the machine’s identity roles on the target resource, exactly as you would for an Azure virtual machine. This is one of the most valuable but least understood benefits of Arc.

The most widely used part of Azure Arc is the ability to connect Windows and Linux servers. It is the foundation on which many other features rest.

What counts as a server

An Arc-enabled server can be a physical machine, a virtual machine on any hypervisor, or a virtual machine in another cloud. It simply needs a supported operating system, the ability to install the agent, and outbound network access to Azure endpoints. Windows Server and many common Linux distributions are supported, and the list of versions is documented and updated as new ones appear.

Ways to onboard

What an Arc-enabled server looks like in Azure

The resource has a name, resource group, subscription, region, tags, operating system details, agent version, status, and a list of installed extensions. It supports role assignments, policy, locks, and activity logs. It is not a virtual machine in Azure: you cannot resize it or start it from the portal, because Azure does not control its power. The commands Azure can issue are those the agent and extensions provide.

Common first steps after onboarding

Disconnecting and deleting

You can disconnect a server from Arc by running the disconnect command, which removes the resource and the identity, and you can uninstall the agent. Deleting only the Azure resource without disconnecting leaves the agent running, which will then try to reconnect or fail, creating noise. Follow the documented order. Also remember that removal of the resource removes policy assignments and extension management for it, so plan clean-ups for retired servers to avoid paying for unused services.

Once a server is connected, Azure’s management services can reach it. This chapter tours the main ones in plain language.

Extensions: how capabilities are delivered

Each capability above is delivered by an extension, a package that the agent downloads, installs, configures, and monitors. For example, the Azure Monitor Agent extension collects logs, and the Defender-related extensions gather security data. Extensions are versioned and can be updated automatically. They can be installed from the portal, from policy, or by templates. Because extensions run on your server, often with high privileges, they deserve the same scrutiny as any other software, which is why Chapter 13 covers allow and block lists.

Policy-driven management at scale

The real power appears when you combine Arc with Azure Policy. With a few assignments at a management group, you can state that every Arc-enabled server must have the monitoring extension, must be assessed for updates, must carry an owner tag, and must send its logs to a central workspace. A DeployIfNotExists policy installs missing extensions automatically on new and existing machines, and reports non-compliance for any that fail. Estates of thousands of servers become manageable because rules replace manual clicks.

One view across everything with Resource Graph

Because Arc machines are Azure resources, Azure Resource Graph can query them together with native Azure virtual machines. A single query can list every server with an unsupported operating system, every machine missing a tag, or every machine that has not checked in recently, regardless of where it runs. This ends the spreadsheet era of inventory.

Kubernetes clusters multiply fast and are hard to keep consistent. Arc brings them under one roof wherever they run.

A short explanation of Kubernetes

Kubernetes is software that runs many containers across a group of machines, restarts them when they crash, and scales them with demand. A cluster is one such group. Companies end up with many clusters: a few in Azure Kubernetes Service, some on-premises, some in other clouds, and small ones at the edge in shops or factories. Each cluster has its own settings, add-ons, and version, and keeping them aligned by hand is a recurring nightmare.

What Arc-enabled Kubernetes does

flowchart TD
  DEV["Platform engineer commits desired state"] --> GIT["Git repository"]
  GIT --> FLX1["Flux agent in on-premises cluster"]
  GIT --> FLX2["Flux agent in other cloud cluster"]
  GIT --> FLX3["Flux agent in edge cluster"]
  FLX1 --> APP1["Apps and settings applied"]
  FLX2 --> APP2["Apps and settings applied"]
  FLX3 --> APP3["Apps and settings applied"]
  APP1 --> RPT["Compliance state reported to Azure"]
  APP2 --> RPT
  APP3 --> RPT
  POL["Azure Policy assignments"] --> RPT

GitOps in plain words

GitOps means that Git is the single source of truth for how a cluster should look. Instead of someone running commands against each cluster, they change files in a repository. A small agent inside each cluster, Flux, regularly checks the repository and makes the cluster match. If someone changes the cluster by hand, the agent corrects the drift. If a cluster is destroyed, a new one can be pointed at the repository and rebuilt to the same state.

Why pull is safer than push

Traditional deployment tools push changes into clusters, which means they need credentials with strong rights to every cluster, usually from outside. GitOps pulls from inside, so the cluster needs only read access to the repository, and no external system holds cluster-admin credentials. Clusters behind firewalls with no inbound access can still be managed, because the connection is outbound only.

Cluster extensions

Arc-enabled clusters can host extensions, such as the Flux extension, the Azure Monitor and Defender components, the Azure Policy add-on, secrets store drivers for Key Vault, and application platform extensions. They are installed and updated through Azure, so you do not run separate installation procedures per cluster.

Related offers: AKS on your own hardware

For running Kubernetes on your own hardware, Microsoft provides AKS enabled by Arc, which delivers a managed-style Kubernetes experience on Azure Local and some other platforms. It handles cluster creation, upgrades, and integration with Azure management. Names and supported platforms evolve, so verify current options before choosing.

Databases are among the most valuable and most closely guarded systems. Arc extends Azure’s data management to databases that run elsewhere.

Arc-enabled SQL Server

If you run Microsoft SQL Server on a connected Windows or Linux server, you can have an Arc-enabled SQL Server resource appear in Azure. The server’s Arc agent installs an extension for SQL Server that discovers instances and databases, and reports on them. Once connected, you gain several capabilities.

• Inventory and licence insight. See every instance, its edition, version, and processor count, across the estate. This helps with licence planning and audits.
• Best practices assessment. Regular automated checks of configuration, performance, and reliability settings, with recommendations.
• Security. Microsoft Defender for SQL assessments and threat detection. Authentication with Microsoft Entra ID, where supported, reduces dependence on local SQL accounts.
• Monitoring. Performance data collected into Azure Monitor.
• Licensing options. Some licensing models, such as pay-as-you-go billing for SQL Server through Azure, are enabled through Arc. Terms depend on agreements, so check them with Microsoft or a licensing specialist.
• Migration readiness. Assessments that estimate effort and target options for moving databases to Azure later.

Arc-enabled data services

Beyond managing existing databases, Arc can run certain Azure data services on Kubernetes you operate, such as Azure Arc-enabled SQL Managed Instance and PostgreSQL. The idea is that you get cloud-style database features, like fast provisioning, elastic scaling, built-in high availability, and automated backups, on your own hardware, in a place where data must stay. A data controller component in the cluster manages these databases and reports usage to Azure. It can operate in different connectivity modes: directly connected to Azure, or indirectly connected with periodic exports of usage data for places with limited connectivity.

Choosing between options

Custom locations

To deploy services such as data services or application services onto an Arc-enabled cluster, Azure needs a target that it understands. A custom location is that target. It is an Azure resource that maps to a namespace in a cluster, so you can say “deploy this database to the Warehouse-London custom location” and Azure Resource Manager makes it happen using the cluster’s agents. It lets teams use the normal Azure portal, templates, and role assignments to deploy into on-premises clusters.

Many organisations run thousands of virtual machines on platforms such as VMware vSphere. Arc lets teams manage them from Azure without moving them.

The resource bridge

The Azure Arc resource bridge is a lightweight appliance, delivered as a virtual machine, that you deploy into your local environment. It acts as a translator between Azure Resource Manager and the local management system, such as VMware vCenter, System Center Virtual Machine Manager, or Azure Local. It reaches out to Azure over an outbound connection, receives requests like “create a virtual machine from this template,” and carries them out locally through the platform’s own interfaces.

flowchart LR
  USER["Engineer in Azure portal or pipeline"] --> ARM["Azure Resource Manager"]
  ARM -->|"outbound channel from bridge"| BR["Arc resource bridge appliance"]
  BR --> VC["vCenter or SCVMM or Azure Local"]
  VC --> HOSTS["Hypervisor hosts"]
  HOSTS --> VMS["Virtual machines"]
  BR -.->|"inventory sync"| ARM
  ARM -.->|"guest management via Arc agent"| VMS

What this enables

Azure Local

Azure Local is Microsoft’s hyperconverged infrastructure solution for running virtual machines, containers, and Azure services on hardware in your own site, for example a store, a factory, or a data center that must stay local. It is managed through Arc: you register the system with Azure, and from then on its clusters, virtual machines, and Kubernetes clusters appear in the portal, receive updates, and follow Azure Policy. It suits scenarios with low latency needs, strict data location rules, or limited connectivity. Hardware choices, licensing, and feature sets are determined by Microsoft and partners, so consult current documentation.

Design considerations

• Bridge placement and sizing. Deploy the bridge on a stable network segment with access to vCenter or the management platform and to Azure endpoints. Plan for its own backup or redeployment.
• Credentials. The bridge uses an account in the local platform. Give it only the permissions required, and rotate its credentials.
• Upgrades. The bridge appliance has its own update cycle. Falling behind can break connectivity or features.
• Scale. Understand the documented limits for inventory size and operations per bridge.
• Roles. Define who can create and who can delete machines, to avoid self-service becoming an uncontrolled sprawl.

Connecting resources is easy. Keeping thousands of them organised, secure, and accountable is where design pays off.

flowchart TD
  ROOT["Tenant root group"] --> CO["Company management group"]
  CO --> PLAT["Platform"]
  CO --> LZ["Landing zones in Azure"]
  CO --> HYB["Hybrid and multicloud"]
  HYB --> HDC["Subscription On-premises data centers"]
  HYB --> HEDGE["Subscription Edge and branch sites"]
  HYB --> HMC["Subscription Other cloud workloads"]
  HDC --> RGP["Resource groups by site and application"]
  HEDGE --> RGE["Resource groups by region"]
  HMC --> RGM["Resource groups by cloud account"]
  CO -.->|"Baseline policies for all resources"| CO
  HYB -.->|"Arc specific policies"| HYB

Where to put Arc resources

Arc resources live in ordinary subscriptions and resource groups. A common pattern is to create a management group for hybrid and multicloud resources, with separate subscriptions for on-premises data centers, edge sites, and workloads from other clouds. This lets you assign Arc-specific policies, for example requiring approved extensions and private connectivity, at that group, and apply company-wide baselines above it. Resource groups may follow site, application, or owner, depending on how teams work. Keep it simple, and consistent with how Azure resources are organised.

Tagging strategy

Tags can be set during onboarding and enforced or inherited with policy. Consistent tags make updates, security reports, and billing sensible.

Role-based access

Azure role-based access control applies to Arc resources just as to Azure ones. Useful built-in roles include Azure Connected Machine Onboarding (can create Arc machine resources, ideal for the automation identity), Azure Connected Machine Resource Administrator (manage Arc machines and extensions), and standard Reader, Contributor, and Owner. Assign roles to groups at the lowest sensible scope. Separate who can onboard machines, who can install extensions, who can see data, and who can administer the operating system.

Policies for a healthy hybrid estate

• Require tags and inherit them from resource groups.
• Deploy monitoring, security, and update extensions automatically.
• Audit Arc machines that are disconnected, running old agent versions, or running unsupported operating systems.
• Restrict which extensions may be installed, and whether remote access features are enabled.
• Require private connectivity for Arc services where your network design supports it.
• Apply Kubernetes security policies to Arc-enabled clusters.

Ownership and operating model

Decide who owns what. A platform team usually owns the Arc fabric: onboarding automation, policy, agent versions, and shared monitoring. Application teams own what runs on their machines. Security teams own the baselines and response. Write down these boundaries, and agree on how teams request exceptions and report problems. Technology alone does not create governance; clear responsibilities do.

Connecting one server by hand is a five-minute task. Connecting five thousand needs a plan, an identity, a process, and checks.

flowchart TD
  A["Inventory servers and sites"] --> B["Design subscriptions, resource groups, and tags"]
  B --> C["Create onboarding service principal with minimal role"]
  C --> D["Prepare network access and proxy settings"]
  D --> E["Pilot with a small group"]
  E --> F{"Pilot successful"}
  F -->|"No"| G["Fix issues and repeat pilot"]
  G --> E
  F -->|"Yes"| H["Deploy agent and connect in waves using automation"]
  H --> I["Verify connection and tags"]
  I --> J["Policy installs extensions and baselines"]
  J --> K["Report coverage and handle exceptions"]

Preparation

Tools for large deployments

Agent updates and lifecycle

The agent is updated regularly. You can update it manually, with your software distribution tools, or, for some versions, through Azure Update Manager and automatic mechanisms. Do not let agent versions fall far behind, because older versions may lose support and miss features and fixes. Monitor the version distribution and set a policy for the maximum age.

Machines you cannot or should not onboard

• Unsupported operating systems. Very old or unusual systems may not run the agent. Consider network-level monitoring, compensating controls, or migration plans.
• Appliances and locked-down devices. Vendor appliances often forbid third-party agents. Manage them by their own tools.
• Machines about to be retired. The effort may not be worthwhile.
• Template images. Do not connect a master image and then clone it; the clones would share an identity. Install the agent but leave the connect step to first boot.

Arc creates a management path between Azure and machines that may be anywhere. Used wisely, it improves security across the estate. Used carelessly, it becomes a new route for attackers.

Two sides of the coin

On the positive side, Arc extends modern controls to places that had none: threat detection, vulnerability scanning, consistent baselines, central logging, passwordless access, and fast patching. On the cautionary side, the same connection means that anyone who controls the Azure side with high privilege may be able to run code on the connected machines. The security of Azure subscriptions and identities therefore becomes part of the security of every connected server.

Protect the Azure side

• Strong identity. Require multifactor authentication and conditional access for anyone with rights to Arc resources. Use Privileged Identity Management for time-limited elevation.
• Least privilege. Separate roles for onboarding, reading, managing extensions, and running commands. The ability to install extensions or run commands on servers is equivalent to administrator access to them.
• Separate scopes. Place high-value servers in their own resource groups or subscriptions with tighter access.
• Locks and alerts. Use locks on critical Arc resources and alerts on changes such as new extensions, role assignments, and agent configuration.
• Protect onboarding credentials. Vault the service principal secrets and limit where they can be used.

Protect the machine side

Network security options

Using Arc to raise security

• Enable Defender for Cloud on all connected servers and clusters for a single secure score.
• Assess vulnerabilities and track fixes through Update Manager.
• Apply machine configuration baselines for operating system hardening.
• Use Microsoft Entra sign-in and SSH through Azure instead of shared local passwords and open management ports.
• Keep certificates fresh with the Key Vault extension.
• Collect security logs centrally with Microsoft Sentinel or another SIEM.

Because Arc depends on an outbound connection, networking is the commonest source of onboarding problems and of surprises at remote sites.

What the agent needs

The agent needs to make outbound HTTPS connections, on the standard secure web port, to a set of Azure service names. These cover Microsoft Entra authentication, Azure Resource Manager, the Arc service itself, the guest configuration service, and the download locations for extensions. Microsoft publishes the current list, which can be expressed as service tags or as DNS names. The agent does not need any inbound ports for its management channel. Time must also be reasonably accurate on the machine, since certificate and token checks depend on the clock.

Common network patterns

Offline and disconnected situations

Bandwidth and data volume

The management channel itself uses little bandwidth. The heavy items are the data you choose to send: logs, metrics, and security events to Azure Monitor and Defender; extension downloads; and update packages. For sites with poor links, use data collection rules to filter what you send, schedule heavy downloads for off-peak times, and consider local caching or distribution points for updates.

DNS and certificates

• Machines must resolve Azure service names correctly. With Private Link, internal DNS must map those names to private addresses.
• TLS-inspecting firewalls that replace certificates can break the agent’s connection. Exempt Arc destinations from inspection.
• Root certificates must be current on older operating systems, otherwise secure connections fail.
• Keep time synchronised using NTP, as clock errors cause strange authentication failures.

The basic Arc connection is inexpensive, but the services you attach are not always free. Understanding where the charges arise prevents surprises.

The general principle

Microsoft generally does not charge for the Arc control-plane features of connecting a server or a Kubernetes cluster and viewing it as an Azure resource, with features such as inventory, tagging, and role-based access control included. You pay for the Azure services that you then use on those resources, and for some specific Arc offerings. Exact packaging and prices change, so always confirm on the official pricing pages and with your Microsoft representative.

A worked example

These figures are invented to show the arithmetic only. Suppose a company connects 500 servers. Basic connection is included. It enables a security plan on 300 of them at a per-server monthly price, collects logs from 200 of them at an average of 2 gigabytes per server per month, and buys extended security updates for 20 older servers by core. The monthly bill adds three elements: 300 times the security price, 400 gigabytes of log ingestion times the ingestion rate, and the update fee for the old servers. The company can control the total by choosing which servers get the paid plans, by filtering logs, and by retiring the old servers.

Ways to manage cost

A hybrid estate has many places to fail. Good monitoring and a clear troubleshooting method shorten every incident.

Where to look

Common problems and their usual causes

A calm method for investigating

Arc is a strong answer to some questions and the wrong answer to others. This chapter helps you decide.

flowchart TD
  Q["You have resources outside Azure"] --> A{"Can and should they move to Azure"}
  A -->|"Yes"| MIG["Plan migration with Azure Migrate and related tools"]
  A -->|"No or not yet"| B{"Do you want Azure management for them"}
  B -->|"Yes"| C{"What kind of resource"}
  B -->|"No"| OTHER["Keep existing tools and review later"]
  C -->|"Servers"| ARCS["Azure Arc enabled servers"]
  C -->|"Kubernetes"| ARCK["Azure Arc enabled Kubernetes"]
  C -->|"SQL Server"| ARCD["Azure Arc enabled SQL Server"]
  C -->|"VMware or SCVMM"| ARCB["Arc resource bridge"]
  C -->|"Need Azure services on own hardware"| LOCAL["Azure Local"]
  MIG --> ARCS

The options compared

Arc and migration together

Arc is often a stage on the way to migration, not an alternative. Connecting servers first gives you inventory, dependency information, and a consistent security and update approach while the migration is planned. Some workloads remain connected permanently because there are reasons they cannot move. The two tools answer different questions: Arc asks “how can I manage and govern this where it is?” and Azure Migrate asks “how can I move this to Azure?”

Questions to settle the design

• Which resources will stay outside Azure, and for how long?
• What do we want to manage centrally: inventory, patching, security, monitoring, configuration?
• Which network pattern fits our rules: direct, proxy, or private?
• Who owns onboarding, policy, and incident response for the hybrid estate?
• Which paid services are justified for which resources?
• How will we handle sites with weak or intermittent connectivity?

Teams that succeed with Azure Arc repeat a few good designs. Teams that struggle repeat a few familiar mistakes. Knowing both saves time.

Patterns that work

Habits compared

Four decisions worth recording

Teams that write down their key decisions avoid arguing about them again a year later. These short records use the common format of context, decision, and consequences. They are illustrative examples, not mandates.

This chapter gathers the advice of the whole book into one checklist to use before launch, during reviews, and after incidents.

Best practices

Common mistakes

The following scenarios are invented illustrations built from common situations. They are not case studies of real companies, and the numbers are examples chosen to make the ideas concrete.

Short answers to the questions beginners ask most often.

You began with a head teacher phoning forty schools. You now have the blueprint for a single control tower that sees every one of them.

Azure Arc extends Azure’s control plane to resources that run anywhere. A small agent, a set of cluster pods, or a resource bridge makes an outbound secure connection and creates a representation of the resource in Azure Resource Manager. From then on, Azure Policy, tags, role-based access, Resource Graph, Update Manager, Defender for Cloud, Monitor, and GitOps can govern servers, clusters, databases, and virtual machines wherever they are, without moving them. Success depends on design before deployment, narrow identities, controlled extensions, a reliable network path, thoughtful cost choices, and daily attention to health.