AWS の EC2 上で動く Linux や Windows を Azure にレプリケーションしようとして、「Azure Site Recovery の Mobility Service がどうしても入らない」「カーネルが非対応と言われて詰んだ」と悩むケースは少なくありません。実はこれは OS やカーネルの問題ではなく、ほとんどが「使うべきエージェントを間違えている」ことが原因です。本記事では、EC2 を Azure Migrate / Azure Site Recovery で保護・移行する際にハマりやすいポイントと、正しいワークフローを具体的な手順とチェックリストで整理します。
EC2 Linux に Azure Site Recovery Mobility Service がインストールできない本当の原因
Ubuntu 22.04 / 24.04 や Red Hat Enterprise Linux 8 / 9 を EC2 で稼働させ、Azure Site Recovery（ASR）の Mobility Service を入れようとすると、次のような状況に陥ることがあります。
- 公式ドキュメントどおりにインストーラーを持ってきて実行しても毎回失敗する
- エラーメッセージとして
ASRMobilityServiceKernelNotSupportedV2などが表示される - カーネルを変えても（例：
5.15.0-1072-azureなどに変更）改善しない
ここで多くの人が「EC2 のカーネルが Azure Site Recovery に対応していないのでは？」と考えてしまいます。しかし、問題の本質は カーネルではなく「エージェントの系統」 にあります。
ASR Mobility Service には用途の違う 2 系統がある
Azure Site Recovery の Mobility Service には、見た目は似ていても用途の異なるエージェントが存在します。これがややこしさの根本です。
| 系統 | 主な用途 | 想定される環境 | インストール方法 | EC2 での扱い |
|---|---|---|---|---|
| 汎用エージェント （オンプレ／VMware／物理サーバー向け） | オンプレミスサーバーや VMware / Hyper-V VM の保護 | 物理サーバー、VMware、Hyper-V | 管理者が手動でダウンロードし、OS 上で実行 | 非対応 インストール前に厳密なカーネルチェックを行い、エラー終了する |
| AWS（EC2）向けエージェント | AWS 上の EC2 インスタンスの保護・移行 | AWS EC2 | Azure Migrate が自動プッシュ配布 手動実行は想定されていない | こちらが正しい選択 |
多くのトラブルは、オンプレ／VMware 用の 汎用エージェントを EC2 に手動インストールしようとしたこと に起因しています。汎用エージェントはインストール前に厳密なカーネルチェックを行い、想定外の環境（EC2 など）ではエラーを返します。その結果、ログや画面上では「カーネル非対応」のように見えるのです。
代表的なエラーメッセージの例
ログの一例として、次のようなメッセージが出力されます。
ASRMobilityServiceKernelNotSupportedV2: The current kernel is not in the supported list.
このメッセージだけ見ると、Ubuntu や RHEL のカーネルを疑いたくなりますが、実態は「そもそも EC2 を対象にしていないエージェントを使った」という構造的なミスマッチです。
カーネルを変えても解決しない理由
「5.15 系のカーネルなら動くらしい」「Azure のカーネルイメージに寄せてみよう」といった対応を試すケースもありますが、エージェント自体の系統が違う限り、カーネルをいじっても意味がありません。
- 汎用エージェントは「サポートされるハードウェア／ハイパーバイザー／ディストリビューションの組み合わせ」を前提に作られている
- EC2 はその前提に含まれておらず、サポート対象外として扱われる
- そのため、どんなカーネルに変更してもインストール前チェックで落ちる
正しくは、「EC2 用の別系統のエージェントを Azure Migrate からプッシュインストールさせる」必要があります。
正しい解決策：Azure Migrate によるプッシュインストールに切り替える
EC2 に対して Azure Site Recovery の Mobility Service を導入する場合、手動インストールは不要かつ非推奨です。Azure Migrate のレプリケーション構成画面から、アプライアンスにプッシュインストールさせるのが唯一の正攻法と言ってよいでしょう。
推奨フローの全体像
具体的には、次のような流れで作業を進めます。
- Azure ポータルで Azure Migrate プロジェクトを作成する
- 「サーバーの移行」ワークロードを選択し、「AWS 上のサーバー」を選ぶ
- Azure Migrate アプライアンスをセットアップし、AWS アカウント／EC2 のディスカバリーを行う
- 移行対象の EC2 インスタンスを選択し、レプリケーションの構成を行う
- レプリケーション構成時に、Azure Migrate が EC2 用の Mobility Service を自動プッシュ
- 以降、通常どおりレプリケーション／テストフェールオーバー／本番移行を実施
ポイントは、Mobility Service 用のパッケージを自分でダウンロードして持ち込まないことです。Azure Migrate アプライアンスが、対象 OS／環境（EC2）に応じた正しいエージェントを自動で取得し、配置してくれます。
手動インストールをやめるべき理由
- EC2 とオンプレ／VMware では前提となる環境が異なり、汎用エージェントでは検証されていない
- 手動取得したパッケージは、どのシナリオ向けか一見では判別しづらい
- 将来的なアップデート時も Azure Migrate からの自動更新が前提となっている
結果として、「Mobility Service は Azure Migrate に任せる」という割り切りが、最も安全で運用負荷も低い選択になります。
EC2 上の Windows Server 2019 でもプッシュインストールできるのか
Linux では Azure Migrate によるプッシュインストールが必須であることが分かりました。同じ EC2 でも Windows Server 2019 の場合はどうでしょうか。
結論から言うと、Windows Server 2019（EC2）でも Azure Migrate を使ったプッシュインストールが可能です。レプリケーションの構成ウィザードを進めていくと、Windows 用の Mobility Service が自動的に配布・インストールされます。
- Linux と同様、手動インストールは不要
- Windows 固有のサービス登録やドライバ設定も、Azure Migrate が一括で対応
- アップデートも Azure 側の管理下で自動化しやすい
オンプレの Windows Server に汎用エージェントを手動インストールしていた経験がある場合でも、EC2 では習慣で手動インストールしないことが重要です。
Red Hat Enterprise Linux 8 / 9（EC2）の事前準備
続いて、RHEL 8 / 9 を EC2 から Azure に移行する際の「事前準備」を整理します。ここで押さえるべきポイントは、Mobility Service そのものではなく、Azure Migrate がプッシュインストールできるための前提条件です。
RHEL 8 / 9 で確認すべき前提条件
| 項目 | 内容 | 確認のポイント |
|---|---|---|
| 管理ユーザー | sudo 実行権限を持つユーザーが存在し、Azure Migrate アプライアンスから認証できること | パスワード認証／鍵認証のどちらを使うかをあらかじめ決め、運用ポリシーと合わせる |
| SSH 接続 | アプライアンスから対象 EC2 への SSH 接続が可能であること | セキュリティグループや NACL、OS のファイアウォールで 22/TCP が許可されているか |
| アウトバウンド通信 | EC2 インスタンスから Azure のエンドポイントへ HTTP/HTTPS で接続できること | 企業プロキシやインターネットゲートウェイの設定、SSL インスペクション有無を含めて確認 |
| 時刻同期 | NTP などで時刻が適切に同期されていること | AWS Time Sync Service または独自 NTP サーバーなど、どこに同期しているかを把握 |
| OS / カーネル | サポート対象の RHEL 8 / 9 系であり、極端に独自カスタムされていないこと | 独自ビルドカーネルや特殊なセキュリティモジュールの有無を確認 |
| セキュリティ製品 | ウイルス対策ソフトや EDR がインストーラーやサービス登録をブロックしていないこと | 必要に応じて Mobility Service 関連のプロセスやパスを除外設定 |
これらを満たしていれば、RHEL 8 / 9 でも Azure Migrate のプッシュインストールで問題なく Mobility Service が導入できます。逆に言えば、事前準備を怠ると Azure Migrate 側で「接続できない」「認証エラー」「タイムアウト」といった別のトラブルに発展します。
よくあるハマりどころ
- SSH は開いているが、踏み台サーバー経由でしか接続できない構成になっている
- ゼロトラスト製品や EDR が、未知のインストーラーとして Mobility Service をブロックしている
- 本番系だけインターネットアクセスが制限されており、Azure のエンドポイントに到達できない
こうした制約がある場合は、Azure Migrate アプライアンスをどこに置くか、どのネットワーク経路を使うかを事前に設計しておくことが大切です。
Azure Migrate を使うために必要なロール・権限
技術的な準備だけでなく、Azure 側の権限設計も重要です。「サブスクリプションの所有者だから何でもできる」と思いがちですが、Azure Migrate は Azure 資源と Entra ID（旧 Azure AD）の双方にまたがる操作を行うため、複数種類のロールが絡んできます。
Azure サブスクリプション側のロール
Azure Migrate プロジェクトを作成し、レプリケーションやストレージアカウントなどをデプロイするには、少なくとも次のロールが必要です。
| 操作 | 必要なロール | 補足 |
|---|---|---|
| Azure Migrate プロジェクトの作成 | サブスクリプションまたはリソースグループに対する Contributor（共同作成者）以上 | Owner であれば Contributor の権限も包含する |
| ストレージアカウントや Recovery Services コンテナーの作成 | 同じく Contributor 以上 | 細かくロールを分ける場合はリソースグループ単位で付与 |
| レプリケーション構成・フェールオーバー操作 | Azure Site Recovery 関連リソースに対する Contributor 以上 | 運用担当者向けに専用ロールを付与することも多い |
Entra ID（Azure AD）側の権限：アプライアンス登録
Azure Migrate アプライアンスは、Azure 側に「アプリケーション登録」として登録され、API 経由で情報を送信します。この登録を行う際には、Entra ID 側の権限も関わってきます。
- 基本的には、Application Developer ロール以上があればアプリ登録が可能
- もしくは、テナント設定で「ユーザーがアプリケーションを登録できる」が有効になっている場合、個別ロールが不要なこともある
- より強い権限として、Cloud Application Administrator なども利用される
Azure Migrate は、VMware / Hyper-V / 物理サーバー / AWS / GCP いずれのワークロードでも、基本的なロール要件は共通です。事前にテナント管理者と調整し、誰がアプライアンス登録を行うか、どのアカウントを使うかを決めておきましょう。
依存関係分析とアプリ検出：新エクスペリエンスの仕様
旧 UI の Azure Migrate では、「エージェント型の依存関係分析」やサーバー内にインストールされたアプリケーション検出（特に .NET / SQL Server など）が提供されていました。しかし、新しい UI（エクスペリエンス）では仕様が変わっています。
依存関係分析：エージェント型からエージェントレスへ
| 世代 | 方式 | 特徴 |
|---|---|---|
| 旧エクスペリエンス | エージェント型（Microsoft Monitoring Agent を VM にインストール） | 詳細なプロセス情報が取れる一方、エージェント配布の運用コストが高い |
| 新エクスペリエンス | エージェントレスの接続依存関係分析 | アプライアンスがネットワークレベルで TCP 接続などを可視化。 エージェント型は提供終了している |
つまり、新 UI では エージェントを詰め込んで細かく見る時代から、ネットワークベースの軽量な可視化へとシフトしていると理解すると分かりやすいでしょう。
アプリケーション検出の扱い
- Azure Migrate（サーバー移行）の新 UI は、あくまでサーバー単位の発見が中心
- Windows 上の SQL Server については、Azure Migrate の SQL アセスメント拡張機能で検出・評価が可能
- 一方で、Linux 上の SQL Server（例：RHEL） は自動検出の対象外になっている
- .NET アプリケーションのモダナイズについては、App Service Migration Assistant や App Containerization など、用途別のツールを併用するのが基本
そのため、「Azure Migrate だけでアプリも依存関係も全部見たい」という期待を持つとギャップが生まれます。インフラ移行の入口として Azure Migrate を使い、その後のアプリ近代化には専用ツールを組み合わせるという役割分担を意識することが重要です。
うまくいかない時の最短チェックリスト
Mobility Service のインストールやレプリケーションがうまくいかないときに、最低限押さえておきたいチェックポイントをまとめます。原因を切り分ける際の「ファーストエイド」として活用してください。
チェックリスト
- 手動インストールを試していないか？
→ まずはここを疑うべきです。EC2 の場合は必ず Azure Migrate によるプッシュインストールに切り替えてください。 - アプライアンスから対象 VM へ到達できているか？
→ SSH（Linux）、RDP / WMI（Windows）など、前提となるポートと認証方式を確認します。 - OS がサポート範囲か？
→ 非常に古い OS や、ベータ版に近い最新ディストリビューションは避け、サポートリストに載っているバージョンを選びましょう。 - セキュリティソフトや OS の保護機能に阻まれていないか？
→ EDR / AV / SELinux / AppArmor などがインストーラーやサービス登録をブロックしていないか確認します。 - 時刻ずれがないか？
→ レプリケーションは証明書やトークン、有効期限管理に敏感です。NTP の設定は必ず点検しましょう。 - プロキシ設定は適切か？
→ アプライアンスや移行元 VM がインターネットに出ていく際のプロキシ設定に漏れがないかを確認します。
上記は「OS やカーネルのせい」に見える症状でも、実はネットワークや権限周りに起因しているケースが多いポイントです。特に EC2 のような IaaS 環境では、クラウド側のセキュリティグループと OS 側の両方を見ないと原因にたどり着けないことがよくあります。
実運用を意識したベストプラクティス
最後に、単に「動かす」だけでなく、運用まで見据えたときに意識しておきたいベストプラクティスをまとめます。
テスト環境で一度フローを通しておく
- 本番ワークロードに触る前に、小さな EC2（検証用）で Azure Migrate のフローを一通り試しておく
- Mobility Service のプッシュインストール～テストフェールオーバーまで経験しておくことで、本番移行時の心理的ハードルが大きく下がる
タグとネーミングルールを活用する
- Azure Migrate プロジェクトやレプリケーション対象 VM にタグを付け、どの AWS アカウント／VPC に対応するかを明示しておく
- 移行元と移行先で名前がごちゃごちゃにならないよう、接頭辞や環境名（prod / stg / dev）を統一
ロール分担を明確にする
- Azure 側のロール（Contributor / Owner / Application Developer）と、AWS 側の権限（EC2 読み取り権限など）の境界を整理
- 誰がどのフェーズ（評価／レプリケーション設定／フェールオーバー試験／本番移行）を担当するか定義しておく
ログと監査の取り扱いを決めておく
- Azure Migrate / Site Recovery のログを、Log Analytics や SIEM に集約するかを事前に決める
- 移行作業が監査対象となる場合、その証跡をどこに残すか（チケットシステム、Wiki、ツールログなど）を決めておく
これらを意識しておくことで、「とにかく動かした」移行から、「再現性があり運用に耐える」移行プロジェクトへとレベルアップできます。
まとめ
本記事のポイントを改めて整理します。
- EC2 Linux に Mobility Service がインストールできない原因は、多くの場合「エージェントの取り違え」です。
- Azure Site Recovery の Mobility Service には、オンプレ／VMware／物理サーバー向けの汎用エージェントと、AWS（EC2）向けの専用エージェントの 2 系統があります。
- 汎用エージェントは EC2 ではサポートされず、
ASRMobilityServiceKernelNotSupportedV2などのカーネル非対応エラーとして現れることがあります。 - EC2 では手動インストールをやめ、Azure Migrate 経由のプッシュインストールに切り替えることが唯一の解決策です（Linux / Windows 共通）。
- RHEL 8 / 9 などの Linux では、管理ユーザー・SSH・アウトバウンド通信・時刻同期・セキュリティ製品など、一般的な前提条件を満たしておけば問題なくレプリケーションを構成できます。
- Azure Migrate の利用には、Azure 側の Contributor / Owner ロールと、Entra ID 側の Application Developer 以上が関わります。
- 依存関係分析はエージェントレス方式が現行仕様であり、アプリ検出やモダナイズには Azure Migrate 以外のツール（DMS や App Service Migration Assistant など）を組み合わせるのが前提です。
- うまくいかないときは、手動インストールの有無・アプライアンスからの到達性・時刻同期・セキュリティ製品によるブロックなどを優先的に確認すると、原因を絞り込みやすくなります。
「EC2 に Mobility Service が入らない」という現象だけを見ると、どうしても OS やカーネル、AWS 固有の仕様を疑いたくなります。しかし、実際には 「Azure Migrate を中心にした正しいワークフローを踏むかどうか」が成否を分けることがほとんどです。手動インストールからの発想をいったん手放し、Azure Migrate に仕事を任せることで、安定したレプリケーションと移行を実現していきましょう。
コメント