Simple AD受付終了｜Managed Microsoft AD移行ガイド

1. この記事について

Simple ADで開発・テスト環境や小規模アプリケーションの認証基盤を運用している方にとって、
2026年7月30日という日付は無視できない転換点です。既存顧客への影響は「全機能維持・新規ディレクトリ
作成も継続可」と限定的ですが、新規顧客の受付が終了するという事実は、Simple ADという選択肢が
今後どう位置づけられていくかを考える契機になります。

本記事は、Managed Microsoft ADへの移行設計に焦点を当てます。Managed Microsoft ADのエディション
選定（Standard/Enterprise/2024 Hybrid）や構築手順、移行後のEC2/RDS/FSx/WorkSpacesとの統合、
GPO・LDAPS・MFAによるセキュリティ強化といった「移行先を導入した後の運用」は、既存のAWS Directory
Service本番運用シリーズVol1で詳しく解説されています。本記事はそれらの詳細を前提としつつ、
「Simple ADから、いまどう脱出するか」という移行そのものの設計に特化します。

AWS Directory Service本番運用シリーズ Vol1 §3 — シームレスドメイン参加/EC2/RDS/FSx/WorkSpacesとの統合手順を読む →

1-1. 本記事のゴール

この記事を読み終えた時点で、読者は次の判断・設計ができる状態になります。

• 2026年7月30日の受付終了が自組織のSimple AD利用にどう影響するかを正確に切り分け、
  「今すぐ移行すべきか」「当面は現状維持でよいか」をStay/Migrateフレームワークで判断できる
• Simple ADが信頼関係・ADMT over trustに対応していないという制約から、なぜ「ネイティブな
  移行ツール」が存在しないのかを理解し、再構築＋ユーザー/グループ再作成という移行設計の
  必要性を説明できる
• パスワードがエクスポート不可であるためユーザー全員のパスワードリセットが避けられないという
  現実を踏まえ、移行計画に周知・リセット作業の工数を織り込める
• WorkSpaces（ディレクトリ差し替え不可のため再作成が必要）・EC2ドメイン再参加・LDAPアプリの
  向き先切替・DHCPオプションセット/DNS切替という4種のワークロードについて、カットオーバー順序を
  設計できる
• Managed Microsoft AD Standard・AD Connector（オンプレADを保有する場合）・セルフマネージド
  Samba on EC2という3つの移行先の特性を移行観点で比較し、自組織に適した選択肢を選べる
• Simple AD SmallからManaged Microsoft AD Standardへ移行した場合のコスト差の現実を把握し、
  緩和策（共有ディレクトリ・エディション選定）を検討できる

1-2. 読者像

本記事が想定する読者は、開発・テスト環境や小規模アプリケーションの認証基盤としてSimple ADを
既に運用しているインフラ担当者・クラウドアーキテクトです。2026年7月30日の受付終了という
ニュースを見て「自分たちのSimple ADはどうなるのか」「移行すべきかどうか」を判断する必要が
ある方を主な対象とします。

Managed Microsoft ADの版選定・構築手順・GPO設計といった移行先の詳細な運用知識をゼロから
学びたい方は、本記事末尾で参照するAWS Directory Service本番運用シリーズVol1を先に、または
並行して参照してください。本記事はMicrosoft ADの基礎知識（ドメイン・OU・GPOの概念）と、
Simple ADの現行運用経験があることを前提とし、「移行そのものをどう設計するか」に紙面を割きます。

すでにManaged Microsoft ADへの移行を決めており、カットオーバー手順の詳細だけを知りたい方は
§4から読み進めることもできます。

また、まだSimple ADを本番導入しておらず、これから3方式のいずれを選ぶか検討している方は、
本記事ではなくAWS Directory Service本番運用シリーズVol1 §1-3の3方式選定フローを先に
参照してください。本記事は「既にSimple ADを運用している環境から、いまどう脱出するか」を
扱う移行フェーズ向けの記事であり、新規導入時の選定基準は扱いません。

AWS Directory Service本番運用シリーズ Vol1 §1-3 — Managed Microsoft AD/AD Connector/Simple ADの3方式選定フローを読む →

1-3. なぜ今これを書くか

2026年7月30日の受付終了は、既存顧客にとって「今すぐ使えなくなる」変化ではありません。全機能を
維持したまま利用を継続でき、新規ディレクトリの追加作成も可能です。EOLやメンテナンスモードの
告知も現時点ではありません。この点を「サービス終了」「廃止決定」と誇張して伝える情報は不正確で
あり、本記事はAWS公式ドキュメントの記述範囲に限定して事実を伝えます。

とはいえ、受付終了という区切りには実務上の意味があります。第一に、新規プロジェクトでSimple ADを
選択肢に入れられなくなるため、既存のSimple AD運用チームは「今後もこの構成を前提にしてよいのか」
を検討する必要が生じます。第二に、Simple ADはもともと開発・テスト用途や信頼関係・スキーマ拡張が
不要な小規模用途に限定した位置づけであり、要件が育つにつれてManaged Microsoft ADへの移行が
必要になるケースは受付終了の有無にかかわらず発生します。今回の告知は、その移行検討を後押しする
タイミングとして機能します。

Simple ADからManaged Microsoft ADへの移行を支援する、AWS提供のネイティブな移行ツールは
存在しません。Simple ADは信頼関係に対応していないため、Active Directory移行の定石である
ADMT（Active Directory Migration Tool）over trustという手法が使えないためです。この制約を
理解しないまま移行計画を立てると、「ツールで自動移行できるはず」という前提が崩れ、土壇場で
再構築や手作業でのユーザー再作成に追われてしまいます。本記事は、この制約を前提とした
現実的な移行設計を提供します。

なお本記事は、既に公開済みのAWS Directory Service本番運用シリーズVol1（Managed Microsoft ADの
版選定・構築・サービス統合・セキュリティ強化を解説）と対をなす、移行設計ガイドです。移行先での
詳細な構築・運用手順はVol1に委譲し、本記事は「Simple ADからどう脱出するか」という移行の設計と
実行に集中します。

1-4. 本記事の構成

本記事は次の流れで解説します。§2で2026年7月30日の受付終了が既存顧客に何をもたらすのかを
一次情報に基づいて正確に整理し、Stay（現状維持）とMigrate（移行）のどちらを選ぶべきかを
判断するフレームワークを示します。§3では、Simple ADが信頼関係に対応していないためADMT
over trustが使えず、ネイティブな移行ツールも存在しないという制約を出発点に、「再構築＋
ユーザー/グループ再作成」という移行設計の中身を解説します。

§4では、実際に移行を進める段階で直面するワークロード別の課題（WorkSpaces・EC2・LDAP
アプリケーション・DHCPオプションセット/DNS）を取り上げ、依存関係を踏まえたカットオーバー
順序を設計します。§5では移行先の選択肢（Managed Microsoft AD Standard・AD Connector・
セルフマネージドSamba on EC2）を移行観点で比較し、§6でコスト差の現実と緩和策を示します。
§7では移行ロードマップとチェックリストとして全体を整理し、§8でまとめます。

すでにStay/Migrateの判断が済んでおり、移行の実務手順だけを知りたい方は§3から、
カットオーバー手順を優先して確認したい方は§4から読み進めても構いません。各セクションは
できるだけ独立して読めるよう設計しています。

AWS公式— Simple AD受付終了の公式アナウンスを見る

2. 2026年7月30日の受付終了を正確に理解する — Stay/Migrateの判断フレームワーク

移行を検討する前に、まず「何が変わり、何が変わらないのか」を正確に理解する必要があります。
不正確な情報を前提に「今すぐ全面移行しなければならない」と判断すると、不要な工数と
コストを投じてしまいます。他方、既存顧客であれば影響がないため当面は何もしなくてよい、と
判断すると、将来のワークロード拡張で選択肢が狭まっている事実に気づけず対応が遅れます。
本節では、公式情報を踏まえた正確な理解と、自組織の状況に応じた判断フレームワークを示します。

サービスのライフサイクルに関する告知は、AWSに限らず「新規受付終了」「メンテナンスモード」
「EOL（提供終了）」という段階を踏むことが一般的ですが、それぞれ意味する緊急度はまったく
異なります。今回のSimple ADの告知がどの段階に該当するのかを正確に切り分けることが、
過剰反応（不要な緊急移行）と過小評価（必要な移行の先送り）の両方を避けるための第一歩に
なります。

2-1. 何が変わり、何が変わらないか（一次情報準拠）

AWS公式ドキュメントは、2026年7月30日の受付終了について次のように記述しています。

変わること

• 2026年7月30日以降、Simple ADは新規顧客への提供を終了します。これまでSimple ADを利用した
  ことがないAWSアカウントでは、新規にSimple ADディレクトリを作成できなくなります。
• AWS公式は移行先としてManaged Microsoft ADおよびAD Connectorを案内しています。新規に
  ディレクトリサービスを検討するアカウントは、これらの方式を選択することになります。

変わらないこと

• 既存顧客（受付終了前にSimple ADを利用した実績があるアカウント）は全機能を維持したまま
  利用を継続できます。既存ディレクトリの停止・強制移行はありません。
• 既存顧客は受付終了後も新規のSimple ADディレクトリを追加作成できます。「既存顧客」の
  範囲に「今後の新規ディレクトリ作成」が含まれる点は見落としやすいため注意が必要です。
• 2026年7月29日時点で、EOL（提供終了）やメンテナンスモードへの移行に関する告知はありません。
  今回の告知は「新規顧客の受付終了」のみであり、既存機能への制限や新機能開発の停止といった
  情報は公式ドキュメントに記載されていません。

この区別は移行計画の緊急度を左右します。「サービスが終了する」という誤った理解に基づけば
「即座に全面移行が必要」という結論になりますが、実際の一次情報は「新規顧客の受付終了」に
限定されています。本記事では、AWS公式ドキュメントの記述範囲を超えた解釈（「廃止決定」
「EOL」等）を用いず、事実に基づいた移行判断を提供します。

東京リージョンでの実務適合性

日本国内から利用する読者にとって重要な確認事項として、移行元・移行先とも東京リージョン
（ap-northeast-1）で提供されているかという点があります。Simple ADはAWSの商用リージョンの
うちわずか6リージョンでしか提供されておらず、東京リージョンはその提供対象に含まれています。
移行先となるManaged Microsoft AD（Standard・Enterprise・2024 Hybrid）およびAD Connectorも
東京リージョンで提供されています。したがって、東京リージョンでSimple ADを運用している
読者は、リージョンをまたぐことなく同一リージョン内で移行を完結させられます。海外リージョンへ
の切り替えやレイテンシ設計の見直しは不要であり、本記事で解説する移行設計をそのまま
適用できます。

2-2. Stay/Migrateの判断フレームワーク

正確な事実を踏まえたうえで、自組織のSimple AD運用が「当面は現状維持でよいか」「移行すべきか」
を判断するための4つの問いを示します。

問い1: 今後、信頼関係・スキーマ拡張・高度なGPO・FGPPのいずれかが必要になる見込みはあるか

Simple ADはこれらの機能に非対応です。将来的にオンプレADとの信頼関係が必要になる、あるいは
アプリケーション要件でスキーマ拡張が必要になることが見えている場合は、その時点で結局
Managed Microsoft ADへの移行が必要になります。要件が明確化している場合は、受付終了を
きっかけに前倒しで移行するほうが、緊急対応より計画的な移行になります。

シナリオ例: 開発環境をSimple ADで構築していたが、M&Aやグループ会社統合により信頼関係が
必要になる可能性がある場合、Managed Microsoft AD移行はいずれ避けられません。受付終了を理由に
先送りする判断は取らず、要件が具体化した時点で計画的な移行に着手することを推奨します。

問い2: WorkSpaces・AppStreamなど、ディレクトリの差し替えが困難なサービスに依存しているか

WorkSpacesはディレクトリを後から差し替えることができず、移行にはWorkSpace自体の再作成が
必要です（詳細は§4-1）。こうしたワークロードは依存が浅いうちに移行するほうが得策です。
後になるほど再作成対象・工数ともに膨らみ、対応コストが増えかねません。

シナリオ例: 開発チーム数名がWorkSpacesを数台運用している程度であれば、移行に伴う
WorkSpaces再作成のコストは小さく、急ぐ理由はありません。一方、部門展開が進んでWorkSpaces
利用者が数十〜百人規模まで拡大しつつある場合は状況が異なります。利用者数の増加に比例して
再作成対象も増えるため、拡大の本格化前に移行しておくほうが総工数を抑えられます。

問い3: 現在のディレクトリオブジェクト数・アプリケーション数はどの程度か

小規模（ユーザー・グループ・コンピューターの合計が数十〜百程度）であれば、再構築＋
ユーザー再作成という移行アプローチの工数は限定的です。一方、数百〜数千規模のオブジェクトを
抱えている場合は、移行工数が無視できない規模になるため、早期に計画を立てる価値があります。

シナリオ例: 単一プロジェクトの検証環境としてユーザー数十名規模で運用している場合、
§3-3の再構築＋ユーザー再作成の手順をスクリプト化すれば1〜2日程度の作業で完了する規模感
です。一方、複数プロジェクトで共用するディレクトリとして育ってしまい、ユーザー・グループが
数百件規模になっている場合は、移行リハーサルとバルクインポートスクリプトの事前検証に
相応の準備期間を確保する必要があります。

問い4: 開発・テスト用途に限定されているか、本番相当の可用性・監査要件があるか

Simple ADは元々、開発・テスト環境や小規模アプリケーション向けの位置づけです。本番相当の
可用性・監査要件（詳細な監査ログ・MFA・LDAPS等）が求められるようになっている場合、
Simple ADの機能制約（高度なGPO非対応・監査機能の制約）自体がボトルネックになっている
可能性があり、受付終了の有無にかかわらず移行を検討すべき段階です。

シナリオ例: 検証用途として立てたSimple AD環境が、気づけば準本番的なワークロードの
認証基盤として使われ続けているケースは珍しくありません。用途が「検証」から「準本番」へ
なし崩し的に変わっている場合は、Simple ADの機能制約が既に運用上のリスクになっている
可能性が高く、受付終了のニュースを契機に用途を棚卸しする価値があります。

これら4つの問いのいずれかに「はい」が含まれる場合は、計画的な移行（Migrate）を推奨します。
すべて「いいえ」であり、かつ小規模・開発用途に限定される見込みが今後も続く場合は、
当面の現状維持（Stay）も選択肢になります。ただしStayを選ぶ場合も、§2-4で述べる
リスクを認識したうえでの判断としてください。

判断早見表

4つの問いへの回答を一覧化すると、次のように整理できます。

この早見表はあくまで目安であり、複数の問いに「はい」が該当する場合や組織のリスク許容度に
よって、最終判断が変わります。重要なのは、4つの問いを個別に検討し、
「なんとなく不安なので移行する／なんとなく大丈夫そうだから据え置く」という
曖昧な判断を避けることです。

2-3. 判断結果の記録と再評価タイミング

Stay/Migrateの判断を一度下したら、それで終わりにはなりません。4つの問いへの回答は、組織やプロジェクトの
状況変化に応じて「いいえ」から「はい」へ変わり得るため、判断結果を記録し、定期的に見直す
仕組みを持つことを推奨します。

判断結果の記録

Stayと判断した場合は、次の情報を簡潔に記録しておくと、後から状況が変わった際の判断が
スムーズになります。

• 判断日と、4つの問いそれぞれへの回答（はい/いいえとその理由）
• 現在のディレクトリオブジェクト数・利用アプリケーション数・WorkSpaces利用者数の概算
• 次回見直しの予定時期

再評価のタイミング

次のようなイベントが発生した際は、Stay/Migrateの判断を再評価するタイミングとして
意識してください。

• 新しいアプリケーションやワークロードをディレクトリに接続する計画が持ち上がったとき
• WorkSpacesやEC2の利用者・台数が明確に増加傾向にあると分かったとき
• オンプレADとの統合やM&Aなど、信頼関係が必要になる可能性のある組織変化が発生したとき
• 半期・年次などの定期的なインフラ棚卸しのタイミング

受付終了という一次情報自体は「既存顧客に影響なし」ですが、判断を一度きりのものとせず、
状況変化に応じて見直す運用にしておくことで、次項で述べる「要件の後追いによる緊急移行」の
リスクを継続的に抑えられます。

2-4. 移行を先送りするリスク

「既存顧客には影響がない」という理解のもとStayを選んだ場合でも、先送りには具体的な
リスクが伴います。

第一に、要件の後追いによる緊急移行のリスクです。前項の問い1〜4のいずれかが後から
「はい」に変わった場合（信頼関係が突然必要になる、WorkSpacesの利用規模が急拡大するなど）、
計画的な移行の時間的余裕がないまま、緊急対応として移行を迫られることになります。

第二に、パスワードリセットの周知タイミングを逃すリスクです。後述するとおり、
Simple ADからManaged Microsoft ADへの移行ではユーザー全員のパスワードリセットが
避けられません（§3-3）。この周知には一定のリードタイムが必要であり、緊急移行では
利用者への影響説明が不十分なまま実施することになりかねません。

第三に、Simple ADの機能制約が事業要件のボトルネックになり続けるリスクです。受付終了の
有無にかかわらず、Simple ADは高度なGPO・信頼関係・スキーマ拡張に対応していません。
事業成長に伴ってこれらの要件が発生した場合、Simple ADのままでは対応できず、結局は
移行が必要になります。早期に移行しておくことで、要件発生のたびに個別対応する手間を
避けられます。

第四に、移行担当者の異動・引き継ぎによる知見の散逸リスクです。「受付終了は既存顧客に
影響しない」という正確な理解は、告知を確認した時点の担当者には共有されていても、
数年後に担当者が異動・交代した際には引き継がれていない可能性があります。判断結果を
記録する運用（§2-3）を徹底しておくことで、担当者が変わっても正確な経緯と判断根拠を
維持できます。

これら4つのリスクはいずれも「今すぐ発現するものではないが、先送りするほど対応コストが
増える」という共通の性質を持ちます。Stayという判断自体は合理的な選択肢ですが、
「判断した後に放置する」のではなく、§2-3の記録・再評価の運用と組み合わせることで、
リスクを継続的にコントロールできます。

これらのリスクを踏まえ、本記事の後半では移行を選択した場合の具体的な設計手順を
解説します。

3. 移行影響の差分と制約駆動の移行設計

本節では、一般的な3方式（Managed Microsoft AD / AD Connector / Simple AD）の選定基準や
Managed Microsoft ADのエディション比較には立ち入りません。それらは既に公開済みのAWS
Directory Service本番運用シリーズVol1で詳しく解説されています。本節が扱うのは、
「Simple ADからManaged Microsoft ADへ移行する際に何が問題になるか」という移行影響の
差分に限定した比較と、そこから導かれる移行設計です。

3-1. Simple AD → Managed Microsoft ADの移行影響差分

移行を設計するうえで押さえるべき差分は、次の3点に集約されます。

この3点はいずれも独立した問題ではなく、連鎖しています。信頼関係が組めないため、
一般的なAD間移行の定石であるADMT over trust（信頼関係を張ってオブジェクトを段階的に
移行するツール）が使えません。信頼関係を前提としない移行ツールもSimple AD向けには
提供されていないため、結局は新しいManaged Microsoft ADディレクトリを構築し、ユーザー・
グループをそこに再作成するという設計に帰着します。そしてパスワードはエクスポートできない
仕様であるため、再作成したユーザーには新しいパスワードを設定する（＝全員のパスワード
リセット）ことが避けられません。

3-2. なぜネイティブ移行ツールが使えないのか — 信頼関係非対応の壁

Active Directory間の移行では、ADMT（Active Directory Migration Tool）を使い、移行元と
移行先のドメイン間にフォレスト信頼または外部信頼を確立したうえで、SID履歴を維持しながら
段階的にオブジェクトを移行する手法が一般的です。この手法であれば、ユーザーのパスワードを
維持したまま、業務影響を抑えつつ段階的な移行が可能になります。

しかしSimple ADはSamba 4ベースの実装であり、Active Directoryのフォレスト信頼機能に
対応していません。そのため、Managed Microsoft AD側からSimple AD側へ信頼関係を張ってADMTで
段階移行する、という一般的な移行パスがそもそも成立しません。AWSもSimple AD専用の
ネイティブ移行ツールを提供していません。

この制約を移行計画の前提として最初に共有しておくことが重要です。「ツールで自動移行できる
はず」という前提でスケジュールを組んでしまうと、実際に着手した段階になって信頼関係を使えない
ことが判明し、計画を作り直すことになります。制約は移行設計の出発点であり、後から回避できる
ものではありません。

3-3. 再構築＋ユーザー/グループ再作成という移行設計

信頼関係が使えない以上、移行設計は「新しいManaged Microsoft ADディレクトリを構築し、
Simple AD側のディレクトリ情報を元にユーザー・グループを再作成する」という形に集約されます。
具体的な手順は次のとおりです。

Step 1: Simple AD側のディレクトリ情報をエクスポートする

Simple ADはLDAPプロトコルに対応しているため、ldifde（Windowsクライアントからの接続時）
やLDAPクライアントツールを使い、ユーザー・グループ・OU構造をLDIF形式でエクスポートできます。
パスワードのハッシュ値はエクスポートに含まれない（そもそもSamba形式のハッシュはAD標準の
形式と互換性がない）ため、エクスポートするのは属性情報（ユーザー名・所属グループ・
OU構造・表示名等）に限られる点を最初に認識しておきます。

Step 2: Managed Microsoft AD側にOU構造とグループを先に作成する

エクスポートしたLDIF情報を元に、Managed Microsoft AD側にOU構造とセキュリティグループを
先に構築します。グループのネスト構造やOU設計は、Simple AD時代の構造をそのまま踏襲する
必要はなく、この移行を機に整理する組織も多くあります。

Step 3: ユーザーオブジェクトを再作成し、初期パスワードを設定する

PowerShellのNew-ADUserコマンドレットやAWS Toolsを使い、エクスポートした属性情報を元に
ユーザーオブジェクトを再作成します。パスワードはエクスポートできないため、初期パスワードを
新規に設定し、初回ログオン時のパスワード変更を強制する設定（ChangePasswordAtLogon）を
組み合わせることで、利用者自身に新しいパスワードを設定してもらう運用が一般的です。

Step 4: 移行対象範囲を確定し、周知スケジュールを組む

全ユーザーのパスワードリセットが発生するため、移行日・作業内容・新しいログオン情報の
受け取り方法を事前に利用者へ周知する必要があります。周知から実際の切り替えまで、
組織規模に応じて1〜4週間程度のリードタイムを見込むと、問い合わせ対応の負荷を
抑えられます。

この「再構築＋再作成」というアプローチは、一般的なAD間移行と比べると手作業が多く
見えますが、Simple ADの利用規模（開発・テスト用途、小規模アプリケーション向け）を
踏まえれば、多くの場合は数十〜百程度のオブジェクト規模に収まり、スクリプト化すれば
現実的な工数で完了します。数百〜数千規模のオブジェクトを抱える場合は、LDIFのバルク
インポート用スクリプトを事前に検証し、テスト環境で移行リハーサルを行うことを推奨します。

4. ワークロード別カットオーバー設計

ディレクトリ本体の移行設計が固まったら、実際にSimple ADに接続している各ワークロードを
どの順序で新しいManaged Microsoft ADへ切り替えるかを設計します。ワークロードの種類に
よって制約が異なるため、それぞれの特性を踏まえたカットオーバー順序が重要です。

4-1. WorkSpaces — ディレクトリ差し替え不可、再作成前提の移行

WorkSpacesは、稼働中のWorkSpaceインスタンスが参照するディレクトリを後から差し替える
ことができません。あるディレクトリに紐づけて作成したWorkSpaceは、そのディレクトリに
固定されます。そのためSimple ADからManaged Microsoft ADへの移行では、既存のWorkSpaceを
「移行」するのではなく、新しいディレクトリに紐づけて新規にWorkSpaceを作成し、利用者の
データを移行するという設計になります。

具体的な手順は次のとおりです。

1. 新しいManaged Microsoft AD側でWorkSpacesディレクトリ登録を完了させる
2. 利用者ごとに新しいWorkSpaceを新ディレクトリ配下で作成する
3. 利用者データ（マイドキュメント・デスクトップ上のファイル等）を、共有ストレージ経由や
   バックアップ/リストア機能を使って新WorkSpaceへ移行する
4. 利用者に新WorkSpaceへの接続情報を通知し、旧WorkSpaceの利用を停止する
5. 旧WorkSpace・旧ディレクトリを削除する

WorkSpacesはユーザー数が多いほど作業量が線形に増えるため、カットオーバー全体の中でも
最も工数を要する場合があります。移行対象のWorkSpaces利用者数を早期に棚卸しし、
バッチ移行のスケジュールを他のワークロードより先に確定させることを推奨します。

4-2. EC2ドメイン再参加

EC2インスタンス（Windows Server）は、ドメインからの離脱（Remove-Computer）と新ドメインへの
参加（Add-Computer）という標準的な手順で切り替えられます。WorkSpacesと異なり、
インスタンス自体を作り直す必要はありません。

カットオーバーの実務上の注意点は次のとおりです。

• ドメイン再参加にはインスタンスの再起動が伴うため、業務影響を最小化する時間帯を選定する
• ドメイン離脱前に、ローカル管理者アカウントでのログオンが可能な状態を確認しておく
  （新ドメイン参加が何らかの理由で失敗した場合の切り戻し手段として）
• グループポリシーで配布していた設定がある場合、新ディレクトリ側で同等のGPOを事前に
  準備してから切り替える
• サービスアカウントでドメインアカウントを使っているアプリケーションがある場合、
  再参加後にサービスの再起動・認証情報の更新が必要になる

EC2はWorkSpacesと比べて自動化しやすく、Systems Manager Automationやスクリプトを使った
一括ドメイン再参加も現実的です。移行対象のインスタンス台数が多い場合は、自動化を
前提に手順を設計してください。

4-3. LDAPアプリケーションの向き先切替

Simple ADのLDAPエンドポイントに直接接続しているアプリケーション（認証基盤としてLDAP
バインドを行うカスタムアプリケーション等）は、接続先エンドポイントとバインドDNを
新しいManaged Microsoft AD側の値に切り替える対応が必要です。

• LDAP接続文字列（ホスト名・ポート）を新ディレクトリのDNSアドレスへ更新する
• バインドDN・OU構造がSimple AD時代と異なる場合、アプリケーション側の検索ベースDN設定も
  合わせて更新する
• LDAPS（LDAP over SSL）を使っている場合、新ディレクトリの証明書に対応した設定へ更新する

アプリケーションの数が多い場合、切り替え漏れが発生しやすいポイントです。Simple ADに
接続しているアプリケーションの棚卸しを移行計画の初期段階で実施し、チェックリスト化
しておくことを推奨します（棚卸しチェックリストの例は§7で示します）。

AWS Directory Service本番運用シリーズ Vol1 §5 — GPO・委任管理・スキーマ拡張・LDAPS・MFAの設定詳細を読む →

4-4. DHCPオプションセット/DNS切替とカットオーバー順序

VPC内のリソースがディレクトリのDNSサーバーを自動的に参照する設定を組んでいる場合、
VPCのDHCPオプションセットが指すDNSサーバーアドレスを、Simple ADのDNSから新しいManaged
Microsoft ADのDNSへ切り替える作業が最終段階になります。

推奨するカットオーバー順序は次のとおりです。

1. 新しいManaged Microsoft ADディレクトリを構築し、ユーザー・グループを再作成する（§3-3）
2. 影響範囲が限定的なワークロード（一部のEC2インスタンスやテスト用アプリケーション）から
   先行して新ディレクトリへの接続を確認する
3. WorkSpaces利用者の移行を計画的に進める（§4-1、最も時間を要するため早めに着手）
4. LDAPアプリケーションの向き先を切り替える（§4-3）
5. 残るEC2インスタンスのドメイン再参加を実施する（§4-2）
6. すべてのワークロードが新ディレクトリへの接続を完了したことを確認したうえで、
   VPCのDHCPオプションセットを新ディレクトリのDNSサーバーへ切り替える
7. 一定期間（利用状況を監視できる期間）を置いたうえで、旧Simple ADディレクトリを削除する

DHCPオプションセットの切替を最後に置くのは、この切替が影響範囲の広い一括変更であり、
個別ワークロードの移行が完了する前に実施すると、まだ移行できていないワークロードが
新ディレクトリを参照してしまい認証エラーを起こすためです。個別ワークロードの移行を
先行させ、DHCP/DNS切替は「全ワークロードの移行完了確認後の最終スイッチ」として
位置づけることで、切り戻しリスクを最小化できます。

5. 移行先の選択肢比較（移行観点のみ）

Managed Microsoft ADが唯一の移行先というわけではありません。本節では、Simple ADからの
移行を検討する際に現実的な選択肢となる3つの方式を、移行観点に限定して比較します。
Managed Microsoft ADのエディション選定（Standard/Enterprise/2024 Hybrid）の詳細な
判断基準は、既存のAWS Directory Service本番運用シリーズVol1に委譲します。

5-1. Managed Microsoft AD Standard

信頼関係・スキーマ拡張・高度なGPO・FGPPといったSimple ADで対応できなかった機能が
必要な場合の第一候補です。AWSがフルマネージドでドメインコントローラーを運用するため、
運用負荷がかかりません。§3-3で解説した「再構築＋ユーザー再作成」という移行設計が
そのまま当てはまります。

オブジェクト数が最大3万程度までの環境であればStandardエディションで十分です。
将来的にオブジェクト数が3万を超える見込みがある場合はEnterpriseエディションを、
オンプレADと同一フォレストで運用したい場合は2024 Hybrid editionを検討します
（エディション選定の詳細な判断基準はVol1 §2を参照してください）。

AWS Directory Service本番運用シリーズ Vol1 §2 — Standard/Enterprise/2024 Hybrid editionの詳細な選定基準を読む →

5-2. AD Connector（オンプレADを保有する場合）

社内に既にオンプレミスのActive Directoryを保有しており、Simple ADは特定用途の
補助的なディレクトリとして使っていたに過ぎない、というケースでは、AD Connectorが
選択肢になります。AD ConnectorはAWS上にディレクトリ本体を持たず、認証リクエストを
オンプレADへプロキシする方式です。

この場合の移行は「Simple AD上のユーザー・グループを再作成する」のではなく、
「AWSサービスの認証先をオンプレADへ向け直す」という設計になります。オンプレAD側に必要な
ユーザー・グループが既に存在していれば、ユーザー再作成の手間なくManaged Microsoft ADへの
移行と大きく異なる進め方になります。ただし、AD ConnectorはオンプレADに依存するため、
Direct ConnectやSite-to-Site VPNの可用性がAWS側の認証可用性を左右する点は注意が必要です。

5-3. セルフマネージドSamba on EC2（コスト最小の新規構築）

Simple AD自体がSamba 4ベースであったことを踏まえ、「マネージドサービスの利用料を
最小化したい」という要件が強い場合、EC2上にSambaベースのディレクトリサービスを
セルフマネージドで構築するという選択肢もあります。AWSの公式マネージドオファリング
ではないため、OSパッチ適用・バックアップ・可用性設計（マルチAZ配置やレプリケーション）
をすべて自組織で担う必要があります。

この選択肢は、開発・テスト用途に限定され、かつ運用チームにSambaやLinuxサーバー運用の
知見が既にある場合に現実的です。本番相当の可用性・監査要件が求められる場合は、運用負荷と
リスクを踏まえれば、総合的なコストは多くの場合Managed Microsoft ADのほうが低くなります。
慎重に比較検討してください。

5-4. 選択フロー

3つの選択肢を、次の順序で検討することを推奨します。

Step 1: 信頼関係・スキーマ拡張・高度なGPO・FGPPのいずれかが必要か、または本番相当の
可用性・監査要件があるかを確認します。いずれかに該当する場合はManaged Microsoft AD
（§5-1）を選択します。

Step 2: 該当しない場合、既にオンプレADを保有しており、そのオンプレADのユーザー・
グループをそのまま使いたいかを確認します。該当する場合はAD Connector（§5-2）を
選択します。

Step 3: いずれにも該当せず、開発・テスト用途に限定され、かつ運用チームに
Samba/Linux運用の知見がある場合のみ、セルフマネージドSamba on EC2（§5-3）を
検討します。判断に迷う場合、あるいは知見が不十分な場合は、運用負荷の低いManaged
Microsoft AD Standardを選ぶほうが安全です。

多くのSimple AD利用者にとって、実務上の第一候補はManaged Microsoft AD Standardに
なります。オンプレADを保有している組織のみ、AD Connectorとの比較検討を行うのが
現実的な進め方です。

6. コスト差の現実と緩和策

移行を検討するうえで避けて通れないのがコストの跳ね上がりです。本節では、Simple ADから
Managed Microsoft ADへ移行した場合のコスト差の現実と、その緩和策を解説します。

6-1. Simple AD → Managed Microsoft ADのコスト跳ね上がり

ap-northeast-1（東京）リージョンの参考単価（AWS Directory Service本番運用シリーズVol1
§6-3に基づく）で比較すると、次のとおりです。

Simple AD SmallからManaged Microsoft AD Standardへ移行すると、単純比較で月額コストは
約3.3倍になります。Enterpriseエディションを選ぶ場合はさらに跳ね上がります。最新の単価は
リージョンや為替の影響を受けるため、実際の移行判断ではAWS公式の価格ページで最新値を
確認してください。

この跳ね上がりは、Simple ADが「開発・テスト向けの廉価なディレクトリ」として設計されて
いるのに対し、Managed Microsoft ADは「本番相当の可用性・機能を備えたフルマネージド
ディレクトリ」であるという設計思想の違いに起因します。機能とコストはトレードオフの
関係にあり、単純な「値上げ」として捉えるのではなく、必要な機能に見合った投資として
評価することが重要です。

AWS Directory Service本番運用シリーズ Vol1 §6 — 運用・監視・コスト最適化の詳細を読む →

6-2. 緩和策

コスト差そのものを解消できませんが、次の緩和策で総コストを抑えられます。

①複数アカウントでのディレクトリ共有

1つのManaged Microsoft ADを複数のAWSアカウントで共有すると、共有先アカウントの課金は
ディレクトリ本体の作成アカウントより安価な「アクセス時間課金」になります。複数の
開発・テスト環境それぞれにSimple ADを個別に持っていた場合、Managed Microsoft AD移行を
機に1つのディレクトリへ集約し、RAM（Resource Access Manager）経由で共有する設計に
すると、アカウントごとに個別のManaged Microsoft ADを立てるよりコストを抑えられます。

②エディション選定の見直し

移行前のSimple AD運用でオブジェクト数が小規模（数十〜数百）であることが分かっている
場合、Enterpriseエディションではなく Standardエディションで十分なケースがほとんどです。
将来の成長予測を踏まえつつも、現時点で不要な機能・容量への過剰投資を避けることが
コスト最適化の基本です。

③開発・テスト用途を維持する場合はSimple AD継続も選択肢

§2-2のStay/Migrateフレームワークで「Stay」に該当した場合、無理に移行してコストを
増やす必要はありません。既存顧客はSimple ADの利用を継続でき、新規ディレクトリの
追加作成も可能です。移行はコスト増を伴う投資判断であるため、機能要件が発生していない
限り、急いで移行する必要はないという判断も合理的です。

7. 移行ロードマップ・チェックリスト

これまでの内容を踏まえ、移行を選択した場合の全体ロードマップとチェックリストを
まとめます。

フェーズ1: 判断・棚卸し（1〜2週間）

• [ ] §2-2のStay/Migrateフレームワークで移行要否を判断する
• [ ] Simple AD上のディレクトリオブジェクト数（ユーザー・グループ・OU）を棚卸しする
• [ ] Simple ADのLDAPエンドポイントに接続しているアプリケーションを棚卸しする
• [ ] WorkSpaces・EC2インスタンスなど、ディレクトリに依存するワークロードを一覧化する
• [ ] 移行先（Managed Microsoft AD / AD Connector / セルフマネージドSamba）を§5-4の
  選択フローで確定する

フェーズ2: 移行先の構築（1週間程度）

• [ ] Managed Microsoft ADディレクトリを構築する（版選定・マルチAZ配置の詳細はVol1 §2参照）
• [ ] OU構造・セキュリティグループを設計・作成する（§3-3 Step 2）
• [ ] 必要なGPO・LDAPS・MFAの設定を準備する（詳細はVol1 §5参照）

フェーズ3: ユーザー移行・周知（1〜4週間、組織規模に応じて）

• [ ] Simple AD側の属性情報をLDIF形式でエクスポートする（§3-3 Step 1）
• [ ] ユーザーオブジェクトを再作成し、初期パスワード・強制変更を設定する（§3-3 Step 3）
• [ ] パスワードリセットを伴う移行であることを利用者へ事前周知する（§3-3 Step 4）

フェーズ4: ワークロードのカットオーバー（§4の順序に従う）

• [ ] WorkSpaces利用者を新ディレクトリへ移行する（§4-1、最も時間を要するため優先着手）
• [ ] LDAPアプリケーションの向き先を切り替える（§4-3）
• [ ] EC2インスタンスのドメイン再参加を実施する（§4-2）
• [ ] 全ワークロードの移行完了を確認したうえで、DHCPオプションセット/DNSを切り替える（§4-4）

フェーズ5: 旧環境の停止・確認

• [ ] 一定の監視期間を置き、新ディレクトリでの認証エラーが発生していないことを確認する
• [ ] 旧Simple ADディレクトリを削除する（削除前に必要に応じてバックアップを取得する）

このロードマップは目安であり、組織規模やワークロード数に応じて各フェーズの所要期間は
変動します。特にフェーズ3（ユーザー移行・周知）とフェーズ4（WorkSpaces移行）は、
利用者数に比例して工数が増えるため、早期の棚卸しが全体スケジュールの精度を左右します。

8. まとめ

AWS Directory Service Simple ADは、2026年7月30日に新規顧客への提供を終了します。
既存顧客への影響は限定的で、全機能を維持したまま利用を継続でき、新規ディレクトリの
追加作成も可能です。EOLやメンテナンスモードへの移行という告知は、2026年7月29日時点では
ありません。この正確な理解を出発点に、本記事ではStay/Migrateの判断フレームワークと、
移行を選んだ場合の制約駆動の設計を解説しました。

Simple ADからManaged Microsoft ADへの移行における最大の制約は、信頼関係に非対応で
あるためADMT over trustが使えず、ネイティブな移行ツールも存在しないという点です。
この制約から、移行設計は「新しいディレクトリを構築し、ユーザー・グループを再作成する」
という形に帰着し、パスワードのエクスポート不可により全ユーザーのパスワードリセットが
避けられません。この現実を移行計画の前提として最初に共有しておくことが、後からの
手戻りを防ぐ最大のポイントです。

ワークロード別には、WorkSpacesのディレクトリ差し替え不可という制約が最も大きな
工数要因になります。EC2ドメイン再参加・LDAPアプリの向き先切替・DHCPオプションセット/
DNS切替という順序で、影響範囲の小さいものから段階的にカットオーバーを進めることで、
切り戻しリスクを抑えた移行が可能です。

移行先はManaged Microsoft AD Standardが多くのケースで第一候補になりますが、オンプレAD
を保有している組織はAD Connectorも比較検討する価値があります。コストは単純比較で
数倍に跳ね上がりますが、ディレクトリ共有やエディション選定の見直しで緩和できます。
一方で、機能要件が発生していない場合は、既存顧客のSimple AD継続利用も引き続き
合理的な選択肢です。

Managed Microsoft ADへ移行した後の版選定・構築手順・サービス統合・セキュリティ強化の
詳細な運用手順は、AWS Directory Service本番運用シリーズVol1で解説しています。本記事の
移行設計と合わせて参照することで、Simple ADからの脱出からManaged Microsoft ADの
本番運用確立までを一気通貫で進められます。