Azure Arc

解決する課題

• オンプレミスや他クラウドにあるサーバー・Kubernetes を、Azure と同じ管理画面・同じ仕組みで統制したい
• 環境ごとにバラバラなガバナンス（パッチ・構成・コンプライアンス）を、Azure Policy で横断的に強制したい
• アクセス制御や監査を、場所を問わず Entra ID 認証 + Azure RBAC に統一したい
• セキュリティ監視や脆弱性評価を、クラウド内外の資源に同じ Defender / Monitor で当てたい
• 一部の Azure データサービス（SQL Managed Instance など）を、規制やレイテンシの都合でオンプレや他クラウド上で動かしたい

主要概念と用語

• Azure Arc: Azure 外（オンプレ・他クラウド・エッジ）の資源を Azure Resource Manager（ARM）の管理対象リソースとして投影し、Azure の管理機能を適用できるようにするプラットフォーム
• Arc 対応サーバー（Arc-enabled servers）: 物理/仮想マシンに Connected Machine エージェントを入れ、Azure リソースとして登録したもの。Policy・拡張機能・Monitor・Defender の対象になる
• Arc 対応 Kubernetes（Arc-enabled Kubernetes）: 任意の CNCF 準拠 Kubernetes クラスターを Azure に接続したもの。**GitOps（Flux）**による構成配布や拡張機能の展開ができる
• Arc 対応データサービス（Arc-enabled data services）: Arc 対応 Kubernetes 上で Azure SQL Managed Instance や PostgreSql を動かす仕組み。クラウド外でもマネージドに近い運用を実現
• 拡張機能（Extensions）: Arc 対応リソースへ機能を後付けする仕組み。Monitor エージェント、Defender、カスタムスクリプトなどを配布する
• 接続方式（Connectivity）: 完全接続のほか、送信のみ・プロキシ経由・プライベートリンクでの接続に対応。エージェントは原則 アウトバウンド HTTPS で Azure と通信する

仕様・制限・クォータ

• エージェントは **アウトバウンド HTTPS（443）**で Azure に接続する。インバウンドの口を開ける必要はなく、必要な FQDN への送信許可とプロキシ/プライベートリンク構成が前提になる
• Arc 対応サーバーへのエージェント導入と接続自体は追加料金なしで利用でき、課金は上に乗せる機能（後述）側で発生する
• Arc 対応 Kubernetes は CNCF 準拠の任意のディストリビューションを対象とし、特定ベンダーに縛られない
• リソースはリソースグループとリージョンに属する。Arc リソースのメタデータ管理リージョンはサポート対象が限られるため、設計時に確認する
• Arc 経由でもデータプレーンの実体はオンプレ/他クラウド側にある。Azure 側が握るのは管理面（コントロールプレーン）で、ネットワーク遮断時のローカル動作可否は機能ごとに異なる

内部の仕組み

Arc 対応サーバーでは、対象マシンに Connected Machine エージェントを導入します。エージェントはアウトバウンド HTTPS で Azure に接続し、そのマシンを ARM 上の 1 リソースとして登録します。登録されたリソースには Azure 側から拡張機能を配布でき、Monitor エージェントや Defender、構成管理などが後付けで動きます。

認証は Entra ID に統合され、各リソースには Arc のシステム割り当てマネージド ID が付与されます。これにより、オンプレのサーバーであっても Key Vault などへ資格情報なしでアクセスでき、認可は Azure RBAC に委ねられます。

Arc 対応 Kubernetes では、クラスターに**エージェント群（Pod）**をデプロイして Azure と接続します。**GitOps（Flux）**を有効にすると、Git リポジトリの宣言的構成がクラスターへ継続的に同期され、複数クラスターへ同じ構成を一括配布できます。

• Azure が握るのは管理面で、ワークロードの実体は接続先環境に残る
• Policy 評価・Defender 評価・Monitor 収集は、登録済みリソースに対してネイティブの Azure リソースと同じ経路で行われる
• 接続が切れた間も、エージェントが入った環境ではローカルのワークロードは動き続ける（管理面の更新が止まるだけ）

設計パターン / ベストプラクティス

• ガバナンスの統一: Azure・オンプレ・他クラウドを Arc で投影し、Azure Policy でコンプライアンスを横断強制する。準拠状態を 1 つのダッシュボードで把握する
• 資格情報レス化: Arc のマネージド ID + Key Vault で、オンプレ サーバーからもシークレットなしで認証する
• Kubernetes の構成統一: 多数のクラスターへ **GitOps（Flux）**で同じアドオン・ポリシーを配布し、構成ドリフトを抑える
• 段階導入: まず Arc 対応サーバーで在庫把握と Defender/Monitor を当て、次に Policy 強制、最後にデータサービスや GitOps へ広げる
• タグ運用の統一: Arc リソースにも Azure と同じタグ体系を付与し、コスト配賦と棚卸しを一元化する

運用・監視

• エージェントの接続状態を監視する。最後に接続した時刻が古いリソースは、ネットワーク・プロキシ・証明書を順に確認する
• Azure Monitor / Log Analytics を Arc リソースにも拡張し、オンプレ サーバーの OS 内部指標やログを収集する
• Update Manager で Arc 対応サーバーのパッチ評価・適用をクラウド内外まとめて運用する
• Azure Policy のコンプライアンス状態を定期的に確認し、非準拠リソースを是正する
• エージェントの自動アップグレード方針を決め、バージョン乖離による不具合を防ぐ

コスト

Arc 対応サーバーの接続そのものは追加料金なしで使えるのが基本です。費用は、その上で利用する機能側で発生します。具体的には、Defender for Cloud による保護、Azure Monitor のログ取り込み、Update Manager の一部機能、Arc 対応データサービスの実行などが課金対象になります。つまり「つなぐだけ」なら無償で在庫把握とガバナンスの土台を作り、付加機能を当てた分だけ課金される、という考え方です。変動する単価は公式の料金ページで都度確認してください。

セキュリティ

• 認証は Entra ID に統合され、Arc リソースのアクセス制御は Azure RBAC で一元化される。オンプレ サーバーにも同じ認可モデルを適用できる
• 各 Arc リソースにはマネージド ID が付くため、オンプレからも資格情報をハードコードせず Key Vault などへ認証できる
• 通信はアウトバウンド HTTPS のみで、インバウンドの穴を開けない。閉域要件にはプライベートリンクで対応する
• Microsoft Defender for Cloud を Arc 対応サーバー/Kubernetes に当て、クラウド外資源にも脆弱性評価・脅威検知を効かせる
• エージェント導入や登録の権限は最小権限で配り、誰がどの環境を Arc 化できるかを統制する

Well-Architected の観点

• オペレーショナル エクセレンス: クラウド内外の資源を 1 つの管理面（ARM・Policy・Monitor）に集約し、環境ごとに分かれた運用手順を統一できる。構成は GitOps や IaC で宣言的に管理し、ドリフトを抑える
• セキュリティ: 認証を Entra ID、認可を Azure RBAC に統一し、オンプレ サーバーにもマネージド ID と Defender を適用。資格情報レス化と横断的な脅威検知で、攻撃面と管理の分断を同時に減らせる

試験で問われるポイント

関連サービス・比較

Arc は AWS で言えば、ハイブリッド管理の Systems Manager と、オンプレ Kubernetes の EKS Anywhere を合わせたような位置づけです。Azure の管理面をそのままクラウド外へ延ばす点が特徴です。

ハンズオン / CLI例

# Arc 用の拡張機能をインストール
az extension add --name connectedmachine

# オンプレ/他クラウドのサーバーを Arc に接続（対象マシン上で実行）
# 事前に Connected Machine エージェントを導入しておく
azcmagent connect \
  --resource-group demo-rg \
  --tenant-id "<tenant-id>" \
  --location japaneast \
  --subscription-id "<sub-id>"

# 接続済みの Arc サーバー一覧を確認
az connectedmachine list \
  --resource-group demo-rg \
  --query "[].{name:name, status:status, os:osName}" -o table

# Kubernetes クラスターを Arc に接続（クラスターへ接続できる端末で実行）
az extension add --name connectedk8s
az connectedk8s connect \
  --name demo-arc-k8s \
  --resource-group demo-rg \
  --location japaneast

# Arc 対応 Kubernetes に GitOps（Flux）構成を割り当て
az k8s-configuration flux create \
  --name app-config \
  --cluster-name demo-arc-k8s \
  --resource-group demo-rg \
  --cluster-type connectedClusters \
  --url "https://github.com/<org>/<repo>" \
  --branch main \
  --kustomization name=app path=./deploy prune=true