Azure Arc実践設計入門｜オンプレサーバー・Kubernetes・SQLをAzure管理下に統合するハイブリッドクラウド設計ガイド

「オンプレのサーバーはAnsibleで管理しているが、AzureのVMはAzure Portalで別に管理している。この二重管理、何とかならないか」
「クラウド移行の途中でしばらくハイブリッド構成が続く。オンプレとAzure全体に統一的なポリシーやモニタリングをどう設計すればいいか分からない」

こうした悩みを持つインフラエンジニアに向けて生まれたサービスが、Azure Arcです。

この記事では、Azure Arcの概要から主要コンポーネント、有効化の流れ、料金体系、設計上の注意点まで、オンプレ経験者にもわかりやすく解説します。単なる機能紹介にとどまらず、「どんな場面で使うのか」「どこでつまずきやすいか」を現場視点で掘り下げます。

Azure Arcが解決する問題：管理の二重化を終わらせる

オンプレ環境にサーバーが残りながら、一部をAzureに移行しているという状況は珍しくありません。このとき最も厄介なのが「管理の断絶」です。

オンプレのサーバーはAnsibleやSCCM（System Center）、PowerShellスクリプトで管理し、AzureのVMはAzure Portalから管理する——このようにインフラの管理ツールが二系統に分かれると、パッチ適用やポリシー適用、インベントリ収集のたびに操作が重複します。移行期間が長引くほど、この負担は積み重なります。

Azure Arcは、この断絶を解消するために設計されました。Azureのコントロールプレーン（Azure Resource Manager、ARM）を、オンプレや他社クラウド上のリソースにまで拡張できるサービスです。Azure上にないリソースであっても、Azureのリソースとして登録・管理できるようになります。

Azure Arcが提供する価値は大きく3点です。

・一元管理: オンプレ・Azure・他社クラウドのリソースをAzure Portalから統一管理
・Azure Policyの適用: コンプライアンスポリシーをオンプレのサーバーや他社クラウドにも適用可能
・Azure Monitorによる監視: メトリクス・ログをオンプレサーバーからもAzure Monitorに集約

Azure Arcの主要コンポーネント3種

Azure Arcは単一のサービスではなく、対象リソースの種類に応じたコンポーネントで構成されています。現時点（2026年10月）での主要な3つを整理します。

1. Azure Arc-enabled Servers

最も利用頻度が高いコンポーネントです。オンプレや他社クラウドのWindowsサーバー・LinuxサーバーにAzure Connected Machine Agentをインストールすることで、そのサーバーをAzureリソースとして管理できるようになります。

有効化すると、Azure Portalの「Azure Arc > サーバー」一覧に登録サーバーが表示され、拡張機能（Extension）のインストールや、Azure PolicyやAzure Monitorとの連携が可能になります。

2. Azure Arc-enabled Kubernetes

オンプレや他社クラウド（AWS EKS、GKEなど）のKubernetesクラスターをAzure管理下に置くコンポーネントです。クラスターにArc Agentをデプロイすることで、Azure Portalからクラスターの状態確認、Azure Policyの適用、GitOpsによる構成管理（Flux連携）ができるようになります。

Azure AKSとの違いは、クラスターそのものはAzure外で稼働し続ける点です。Arc側はあくまでAzureからの管理ポイントを提供するという位置づけで、既存クラスターを解体する必要はありません。マルチクラウド・ハイブリッドクラウドでKubernetesを運用している組織が、複数クラスターの設定一貫性を保つ手段として特に有効です。

3. Azure Arc-enabled Data Services

SQLマネージドインスタンス（SQL MI）やPostgreSQLサーバーを、オンプレ上のKubernetesクラスターに展開・管理するコンポーネントです。Azureのマネージドデータサービスのメリット（自動パッチ適用、高可用性構成、Azureからの監視）を、オンプレに持ち込める点が特徴です。

ただし、Arc-enabled Data Servicesは「間接接続モード」か「直接接続モード」を選択する必要があり、構成の複雑さが伴います。初期導入時は、Arc-enabled Servers→Arc-enabled Kubernetesの順で慣れてから検討するのが現実的です。

Arc-enabled Serversの有効化手順

最も基本的なArc-enabled Serversの有効化手順を整理します。Azureポータルからの操作のみで再現できるレベルで記述します。

1. 前提確認

登録対象のサーバーが以下の要件を満たしているか確認します。

・対応OS: Windows Server 2012以降、主要なLinuxディストリビューション（RHEL、Ubuntu、SLESなど）
・ネットワーク: サーバーからインターネットへのアウトバウンド通信（443ポート）が可能であること（またはプロキシ経由での接続が構成されていること）
・必要エンドポイント: management.azure.com、login.microsoftonline.com、*.guestconfiguration.azure.com等への443番ポートの通信許可

2. エージェントのインストール

Azure Portal → 「Azure Arc」→「サーバー」→「追加」から、インストールスクリプトを生成します。1台ずつ手動登録する場合と、スクリプトを使って一括登録する場合の2系統があります。

手動インストールの場合、生成されたスクリプト（PowerShellまたはShellスクリプト）を対象サーバーにコピーして実行します。

# Windowsの場合（PowerShell）: Azure Portalが生成したスクリプトを実行
.\OnboardingScript.ps1

# Linuxの場合（bash）
sudo bash OnboardingScript.sh

スクリプト実行後、デバイスコードによる認証が求められます。ブラウザでそのコードを入力して認証が完了すると、エージェントが対象のサブスクリプション・リソースグループに登録されます。

3. 登録の確認

Azure Portal → 「Azure Arc」→「サーバー」一覧に対象サーバーが表示されれば登録完了です。ステータスが「Connected」になっていることを確認してください。

登録後は「拡張機能」タブからAzure Monitor Agent（AMA）やゲスト構成エクステンションをインストールすることで、Azure Monitorへのログ収集が始まります。

Azure PolicyとMonitorによる一元管理

Arc-enabled Serversを導入する最大のメリットの一つが、Azure Policyをオンプレサーバーにも適用できる点です。

例えば「登録サーバー全台にAzure Monitor Agentがインストールされていること」を必須要件として定義し、未適用サーバーを自動的に検出・是正（DeployIfNotExists効果）させることができます。これにより、オンプレ側の設定ドリフトをAzure側のポリシーエンジンで抑制できます。

Azure Monitorとの統合では、登録サーバーのCPU使用率・メモリ・ディスクといったメトリクスをAzure側で収集できます。オンプレのZabbixやNagiosを即座に置き換えるのではなく、段階的に補完ツールとして使い始めるアプローチが現実的です。

Microsoft Defender for Cloudとの連携では、Arc登録サーバーのセキュリティ状態スコアをAzure側で可視化でき、脆弱性の有無や設定の不備を横断的にチェックできます。セキュリティポリシーをオンプレとAzureで一本化する上で、欠かせない連携です。

料金の仕組み（2026年10月時点）

Azure Arc自体の登録機能（Arc-enabled Servers・Arc-enabled Kubernetes）は、基本的に追加料金なしで利用できます。ただし、Arcを通じて有効化するサービスには個別の課金が発生します。

コスト管理の観点では、「まずArc登録だけして付随サービスは段階的に有効化する」戦略が有効です。登録だけであれば実質無料で始められるため、サーバーインベントリの把握ツールとして最初のステップに使えます。

設計時の主な考慮点

1. ネットワーク設計

Arc-enabled Serversのエージェントは、サーバーからAzureのエンドポイントへのアウトバウンド通信（443ポート）が必要です。プロキシ経由での通信も可能ですが、エージェントのインストール時にプロキシ設定を渡す必要があります。

インターネットへの直接通信を禁じているオンプレ環境では、Private Link（Azure Private Endpoint）経由の接続が選択肢になります。ただしPrivate Link経由の構成はVPN/ExpressRoute接続が前提となり、ネットワーク設計の複雑度が増します。

2. サービスプリンシパルと権限

スクリプトによる大量サーバーの一括登録では、サービスプリンシパルを使った認証が求められます。必要最小限の権限（「Azure Connected Machine Onboarding」ロール）をサービスプリンシパルに付与し、他の用途に使い回さないことが原則です。

3. タグ設計

Arc登録したサーバーは、AzureリソースグループとリソースタグでAzureのリソースと同様に管理できます。オンプレサーバーに「環境（prod/dev）」「部門」「アプリ名」などのタグを付与することで、Azure Cost Managementやポリシーのスコープ管理が容易になります。オンプレ側のCMDBとタグ定義を事前に揃えておくと、後から整合させる手間が省けます。

よくあるつまずきと対処法

エージェントが「Disconnected」になる

一般的には、プロキシの設定漏れや、必要なAzureエンドポイントへのアクセスがファイアウォールでブロックされているケースが多いです。まずazcmagent checkコマンドで接続テストを実施し、どのエンドポイントに到達できないかを特定するのが最短の切り分け方法です。

# Linux: 接続確認コマンド
sudo azcmagent check

# Windows（PowerShell）
azcmagent check

出力に「FAILED」が含まれるエンドポイントが分かれば、そこをファイアウォールで開けば解決するケースがほとんどです。

Azure Policyが適用されない

Policyの割り当てから評価サイクル（最大24時間）が経過しないと、コンプライアンス状態が更新されません。即時評価をトリガーするには、Azure CLIでaz policy state trigger-scanコマンドを実行するか、Azure Portalの「コンプライアンス」→「今すぐ評価」ボタンを使います。

Arc-enabled Kubernetesでflux-system Namespaceが増えた

GitOps（Flux）を有効化すると、クラスターにflux-systemなどのNamespaceと関連Podが自動作成されます。これはGitOpsエージェントの動作に必要なリソースであり、削除すると設定が失われます。Arcの導入前に、既存クラスターの運用チームにこの点を共有しておくことが重要です。

Arc-enabled Serversとオンプレの既存監視ツールの競合

既存のZabbixやNagiosのエージェントが入っているサーバーにAzure Monitor Agentを追加する場合、監視設定が重複してメトリクスが二重収集されることがあります。よくある対処は、段階的に既存エージェントを無効化しながらAzure Monitor側の設定を検証していく方法です。一度に全台を切り替えるのは避け、試験的に数台から始めるのが無難です。

本記事のまとめ

Azure Arcを使うと、オンプレサーバー・Kubernetesクラスター・データサービスをAzureのコントロールプレーンで一元管理できます。Arc登録自体は基本無料で始められるため、まずはサーバーインベントリの把握やAzure Policy適用の基盤として活用するところからスタートするのが現実的です。

ハイブリッドクラウドの管理コストに悩んでいるなら、まずArc-enabled ServersでオンプレサーバーをAzure管理下に置くところから試してみてください。登録作業そのものは30分程度で完了します。