オンプレADからAWS Managed Microsoft ADへ — 認証基盤移行の勘所

Windows資産をAWSへ動かすとき、最後まで悩みの種になるのがActive Directoryです。サーバーは移せても認証基盤を雑に扱うと、ドメイン参加やGPO、FSx連携で足を取られます。本記事では3つの方式を実務目線で比較し、ダウンタイムを抑えた段階移行の勘所を整理します。

01なぜAD移行は「サーバー移行のついで」で済まないのか

Windowsサーバーの移行は、いまやMGNによるP2V移行などで比較的スムーズに運べます。ところがActive Directory（AD）は、単なる1台のサーバーではなく「業務全体の認証と権限の土台」です。ここを軽く見ると、サーバーは動いているのにユーザーがログインできない、ファイルサーバーにアクセスできない、といった形で最後に詰まります。

ADが絡む依存関係は広範です。ドメイン参加したEC2、GPOで配布される設定、DNSによる名前解決、そしてFSx for Windows File ServerやRDS for SQL ServerのWindows認証まで、すべてADに紐づきます。だからこそ、移行方式の選定を移行初期の意思決定のなかで早めに固めておくことが重要です。

023つの方式 — Managed Microsoft AD / AD Connector / EC2セルフマネージド

AWS上でADを扱う選択肢は大きく3つです。どれが正解ということはなく、既存オンプレADの扱い方と、AWS側で動かすワークロードの要件で決まります。

• AWS Managed Microsoft AD：AWSが管理する本物のMicrosoft AD（実体はWindows Server上のAD DS）。2つのドメインコントローラーが別々のAZに自動配置され、パッチや冗長化はAWS側の責任です。スキーマ拡張・信頼関係・GPOに対応し、FSxやRDS for SQL ServerのWindows認証もこの方式でのみ利用できます。StandardとEnterpriseの2エディションがあります。
• AD Connector：AWS側にADの実体を持たず、認証リクエストをオンプレADへ転送するプロキシ（ゲートウェイ）です。情報をクラウドにキャッシュしません。小規模と大規模の2サイズがあり、スキーマ拡張やLDAPS、FSMOロール移動などには対応しません。重要な点として、FSx for Windows File ServerとRDS for SQL ServerはAD Connectorと連携できません。
• EC2上のセルフマネージドAD：EC2にWindows Serverを立て、自分でAD DSを構築・運用します。自由度は最大ですが、DC冗長化・バックアップ・パッチ・監視まですべて自社責任になります。

下図に、意思決定の軸を整理しました。

03共存パターン — 信頼関係とレプリケーション

現実の移行では、いきなりオンプレADを廃止することはほぼありません。多くは「オンプレADを残しつつAWS側にもADの足場を作る」共存フェーズを経由します。ここでの設計軸は2つです。

• 信頼関係（Trust）：AWS Managed Microsoft ADとオンプレADの間に双方向または一方向の信頼を張ります。これにより、オンプレのユーザー／グループを維持したまま、AWS側リソース（FSx、RDS、ドメイン参加EC2）へ認証を通せます。ユーザーオブジェクトを複製せず、既存の権限体系をそのまま活かせるのが利点です。
• DCのAWS側配置（レプリケーション）：セルフマネージドAD方式で、オンプレDCのレプリカとなる追加DCをEC2上に立てる構成です。同一ドメインを延伸するため信頼関係は不要ですが、AD DBそのものをAWSに複製するため、サイト設計・レプリケーショントラフィック・FSMO配置まで自社で面倒を見る必要があります。

多くのエンタープライズでは、既存のドメイン設計を壊さず段階移行できる「信頼関係」パターンが第一候補になります。ただし信頼関係にはオンプレADとAWS間の安定した接続が前提です。VPNとDirect Connectの選定や、重複CIDRの解消が事前に片付いていないと、認証が断続的に失敗する厄介な障害につながります。

04DNSとGPO — 見落とすと当日に効いてくる2大要素

AD移行のトラブルは、実のところDNSとGPOに集中します。この2つは「移行対象そのもの」ではないため計画から漏れやすく、しかしログインとポリシー適用の根幹を握っています。

DNS：ADはDNSに強く依存します。ドメイン参加もKerberos認証も、SRVレコードの正しい解決が前提です。AWS Managed Microsoft ADは自身のDNSを持つため、VPCのDHCPオプションセットやRoute 53 Resolverの転送ルールで、オンプレドメインとAWSドメインの相互解決を明示的に設計する必要があります。「なんとなく名前が引ける」状態で本番に入ると、フェイルオーバー時などにSRVレコードが引けず認証が落ちます。

GPO：オンプレで長年育ってきたGPOは、移行先ADへ自動では移りません。Managed Microsoft ADでは管理者権限が制限される（Domain Adminsは付与されない）ため、GPOはAWSが用意する専用OU配下で、委任された権限の範囲で運用します。既存GPOの棚卸しと、AWS側で再現すべきポリシーの取捨選択が必要です。移行しない不要GPOを一緒に持ち込まないことも、この機会の隠れた価値です。

• ドメイン参加サーバーが参照するDNSサーバー設定を、移行前後で明示的に切り替える手順を用意する
• SYSVOL上のスクリプトやログオンスクリプトの依存を洗い出す
• 証明書自動配布（AD CS連携）など、GPO外の依存も忘れずに棚卸しする

05ドメイン参加とFSx / RDS連携の実務

AWS側でWindowsワークロードを動かすうえで、ドメイン参加と各サービス連携は避けて通れません。

EC2のドメイン参加：Managed Microsoft ADとSSMを組み合わせたシームレスドメイン参加を使うと、起動時に自動でドメイン参加させられます。手作業のdjoinを1台ずつ行う運用から解放されるため、台数が多い移行では効果が大きい仕組みです。Windowsサーバー移行の落とし穴で触れたSID・ライセンス周りと合わせて設計します。

FSx for Windows File Server：Windowsファイルサーバーの移行先として有力ですが、AD連携はManaged Microsoft ADまたはセルフマネージドADに限られ、AD Connector経由では利用できません。ここがAD Connectorを選べない典型的な理由になります。

RDS for SQL Server：Windows認証を使う場合、Managed Microsoft ADと連携します（近年は自己管理ADとの連携もサポート）。こちらもAD Connectorとは組み合わせられません。DBのWindows認証要件があるかどうかは、方式選定を左右する重要な分岐です。DMSによるDB移行と並行して、認証方式を早めに確定させてください。

06ダウンタイムを避ける段階移行の型

認証基盤は「止められない」性質上、ビッグバン移行はリスクが高すぎます。EMWでは段階移行を基本としています。下図に典型的な流れを示します。

段階の流れは概ね次の通りです。

• Step 1：足場の構築　AWSにManaged Microsoft ADを立て、VPNまたはDirect Connectで安定した接続を確保。DHCPオプションセット／DNS転送を設定します。
• Step 2：信頼関係の確立　オンプレADとの双方向信頼を張り、両方向でのDNS解決と認証を検証します。
• Step 3：ワークロードの段階移行　EC2・FSx・RDSを少数から順にAWS側ドメインへ組み込み、影響範囲を区切りながら進めます。
• Step 4：切り戻し可能な状態でのカットオーバー　問題があればオンプレADに戻せる状態を保ちつつ本番切替。詳細は無停止移行とカットオーバー当日の考え方が役立ちます。

この型はSIer向けの移行全体フローの一部として組み込むと、他ワークロードのスケジュールと整合が取りやすくなります。認証基盤だけを孤立させず、全体計画のなかに位置づけることが成功のポイントです。

—まとめ

AD移行は「サーバーの引っ越し」ではなく「認証と権限の土台の再設計」です。FSxやRDS for SQL ServerのWindows認証を使うならManaged Microsoft AD、オンプレADを正とし続けるならAD Connector、特殊要件があればEC2セルフマネージドと、要件から方式が決まります。

そして成否を分けるのは、多くの場合DNSとGPO、そして信頼関係の張り方という「地味な部分」です。ここを段階移行で丁寧に検証し、常に切り戻せる状態を保つことが、ダウンタイムを避ける最大の近道になります。EMWはKeycloakなどOSS認証基盤の構築実績も含め、オンプレとクラウドの認証を橋渡ししてきました。方式選定から共存設計、カットオーバーまで、手を動かしながら伴走します。