はじめに
2025年8月にManaged Microsoft ADにHybrid Editionが追加されたので
各エディションの違いを確認し、最後に実際に試していきます。
AWSの記事はこちらです。
AWS記事リンク
AWS Directory ServiceにManaged Microsoft ADとは
AWS Managed Microsoft ADは、AWS Directory Serviceの中の機能の一つでAWSクラウド内に実際のMicrosoft Active Directoryを実行するフルマネージドサービスです。
AWS側の管理ソースでActive Directoryを提供し、既存のオンプレミスADと連携してディレクトリを管理していきます。
各エディションの概要
AWS Managed Microsoft ADは今までStandard EditionとEnterprise Editionがありました。
ユースケースの違いとしては主にActive Directoryのドメイン規模が小中規模か大規模化で使い分けています。
既存のエディション主な違いは以下の通りです。
| 項目 | Standard Edition | Enterprise Edition |
|---|---|---|
| ユーザー数上限 | 最大5,000ユーザー | 最大500,000ユーザー |
| ドメインコントローラー数 | 2台（デフォルト）以上 | 2台（デフォルト）以上 |
| 月額料金（東京リージョン） | 約$44 | 約$292 |
| 追加DCの料金 | 約$55/月 | 約$146/月 |
| ディレクトリオブジェクトの ストレージ |
1GB | 17GB |
| フォレスト機能レベル | Windows Server 2012 R2 | Windows Server 2012 R2 |
| ドメイン機能レベル | Windows Server 2012 R2 | Windows Server 2012 R2 |
| 推奨用途 | 中小規模組織 基本的なAD機能 |
大規模組織 高度なAD機能が必要 |
Hybrid Editionは、既存のエディションと同じくActive DirectoryをAWS上に拡張する機能ですが、拡張方法が異なります。
Standard EditionとEnterprise EditionはActive Directoryの信頼関係機能で拡張をしていましたが、Hybrid Editionは同じドメインのままドメインコントローラーを追加する形で拡張をしています。
信頼関係について
Active DirectoryにおいてのHybrid Editionのメリットを説明する前に、信頼関係とついて馴染みのない方もいるかと思いますので、簡単に説明します。
信頼関係
信頼関係は独立したドメイン環境Aとドメイン環境Bがドメインの境界を越えてアクセス可能にする仕組みです。各ドメインの独立性は保持したまま運用が可能です。
信頼関係は一方方向のみの信頼関係や双方向の信頼関係などを選択できます。
利用例は、企業の吸収合併を行った際に信頼関係を設定することで、どちらからのドメイン環境を再構築することなくスムーズにドメイン環境を拡張できます。
Hybrid Editionのメリットデメリット
既存のManaged Microsoft ADは信頼関係を設定することでドメイン環境をAWSに拡張しており、ドメイン名は異なっていました。
そのため、Hybrid Editionで行うことでStandard EditionとEnterprise Editionと比べて以下のような点で優れていると感じています。
- AWS移行が容易になる
- ドメイン名が共通であるため、移行の考慮事項が減る
- Active Directory運用の簡素化
- 既存のADフォレスト名と組織構造が維持される
- 同じドメイン名であるためアプリケーションの連携が容易
- 管理すべきドメイン名が減る
ただし、コスト面を考えるとHybrid Editionは Enterprise Editionよりも高価であるため注意が必要です。
将来的にAWS環境に移行するためのワンステップとしてやサービス利用料以上の運用負荷軽減が見込める場合などのユースケースでの利用になると思われます。
最後に先ほどの比較表にHybrid Editionを追加してみました。
| 項目 | Standard Edition | Enterprise Edition | Hybrid Edition |
|---|---|---|---|
| ユーザー数上限 | 最大5,000ユーザー | 最大500,000ユーザー | 最大500,000ユーザー |
| ドメインコントローラー数 | 2台（デフォルト）以上 | 2台（デフォルト）以上 | 2台（デフォルト）以上 |
| 月額料金（東京リージョン） | 約$44/月 | 約$292/月 | 約$547/月 |
| 追加DCの料金 | 約$55/月 | 約$146/月 | 約$273.7/月 |
| ディレクトリオブジェクトの ストレージ |
1GB | 17GB | 17GB |
| フォレスト機能レベル | Windows Server 2012 R2 | Windows Server 2012 R2 | Windows Server 2012 R2 or 2016 |
| ドメイン機能レベル | Windows Server 2012 R2 | Windows Server 2012 R2 | Windows Server 2012 R2 or 2016 |
| 推奨用途 | 中小規模組織 基本的なAD機能 |
大規模組織 高度なAD機能が必要 |
大規模組織 高度なAD機能が必要 |
ハンズオン
環境
それでは実際に設定をしてみます。
今回はオンプレミス環境の準備ができないため、AWS環境内で構築していきます。
構成図のEC2がオンプレミス環境で稼働しているドメインコントローラーに見立てて設定していきます。
環境はリージョンは東京リージョンで、EC2のOSはWindows Server 2025を使用し、フォレスト機能レベル、ドメイン機能レベルはともにWindows Server 2016です。
既存のドメインとしては「worktest.internal」を設定しています。
AWSのVPC作成やEC2の作成、OS内のActive Directoryの作成手順は省略します。
事前考慮事項
今回はAWS環境内のため設定は不要でしたが、前提条件としてSystems Managerのマネージドノードにドメインコントローラーが設定されている必要があります。オンプレミス環境のドメインコントローラーに対して設定する際は、事前にAWS Systems Managerハイブリッドアクティベーションを行いAWS上で表示できるようにする必要があります。
また、記事作成時点でフォレスト機能レベル、ドメイン機能レベルはともにWindows Server 2012 R2か2016しか対応してません。
Windows Server2025から使用可能であるWindows Server 2025の機能レベルは対応していませんのでご注意ください。(評価時にレプリケーションエラーで失敗し気づきました。)
設定の流れ
今回はマネジメントコンソールでの設定していきます。
大まかな流れとして以下のように進めます。
- 事前のシークレット作成
- 評価の作成
- リソース作成
事前sercret作成
手順の途中にサービスアカウントの認証情報を保存するためにSecrets ManagerのシークレットのARNを指定するため事前に作成が必要です。
シークレットのキーの指定が固定だったり、KMSの作成が必要だったりとするため、こちらの手順も記載します。
まずはKMSでキーを作成します。AWSのKMSマネージドキーでは設定できないため、カスタムキーを作成します。
Directory ServiceのHybrid Editionがクロスアカウントに対応していないため同じAWSアカウントでの作成が必要です。
キーポリシーで注意する点は以下の記載を追記してDirectory Serviceがキーの復号できるようにしておく必要があります。
{
"Sid": "Allow use of the KMS key on behalf of Directory Service",
"Effect": "Allow",
"Principal": {
"Service": "ds.amazonaws.com"
},
"Action": "kms:Decrypt",
"Resource": "*"
}
KMSキーを作成したら、Secrets Managerからシークレットを作成します。
こちらもDirectory Serviceと同じAWSアカウントである必要があります。
シークレットは「その他の種類のシークレット」を選択し、以下の2つのキー/値を指定します。
キーの名称は固定であるため、自身でユニークな名称を使用しないようにしましょう。
- customerAdAdminDomainUsername/ADのユーザー名
- customerAdAdminDomainPassword/ドメインユーザーのパスワード
ユーザー名はドメインを記載せず、ユーザー名のみの記載です。
あとはシークレットのローテーションなどは設定不要でシークレットの作成を進めます。
細かい手順については、以下のドキュメントでも記載があるため参照ください。
AWSドキュメント
評価の作成まで
シークレットの事前準備が終われば、リソース作成といきたいところですが、まずはリソース作成前にリソースが作成可能かのテストを行う必要があるため、その手順を記載します。
「Directory Service」のリソースを開き、「ディレクトリのセットアップ」を選択します。
ディレクトリの選択画面で早速画面が変わっています。今まではAWS Managed ADドメインを新規作成しかできませんでしたが、「既存のADドメインをハイブリッドエディションで拡張」の選択肢が増えています。
今回はこちらを選択していきます。
続いて、設定値を入力していきます。
既存のDNS名とドメインコントローラーのIPアドレス、AWS Managed Microsoft ADを設定するVPCと既存のドメインコントローラーのノードを選択します。
必要事項を入力するとまずは評価の作成が行われます。評価の作成時点では実際のリソースは作成されず、ディレクトリのフォレスト追加が可能かの評価が行われます。
評価が作成されるとDirectory Service画面に評価の項目が追加されます。
評価の作成は最大30分かかるとドキュメントに記載されてますので、一定期間後の結果を確認します。
ちなみに評価の作成はほぼ30分かかりました。
評価が完了したら、結果を確認します。
上記画像の評価をクリックすると詳細を確認できます。
主に以下のカテゴリでテストが行われていることが確認できました。
- ドメイン検証テスト
- リモート接続テスト
- 特権テスト
- ネットワークテスト
- レプリケーションテスト
- システムテスト
- ドメインヘルステスト
各カテゴリで詳細なテストが行われています。
もしテストの失敗があるとエラーメッセージが出力されます。
エラーの詳細はAWSのドキュメントにすでに記載があるため、エラー内容の詳細と対応事項に沿って修正を行い再度評価を実施します。
評価テストのエラーメッセージ
評価が成功をしない限りリソースは作成できません。
リソース作成
評価が成功したらようやくリソースの作成です。
成功した評価を選択し、「ハイブリッドディレクトリを作成」をクリックするとリソースの作成画面に移れます。
リソースの作成では最初に作成したシークレットを選択し、ハイブリッドディレクトリを作成をクリックして待ちます。
リソースが無事に作成できました。
私が検証したときには2時間弱かかったので既存のエディションと比べてもリソース作成時間がかなり長かったです。
設定のタブは以下の通りでした
デフォルトではログの出力が無効化されているため「ネットワークとセキュリティ」タブで有効化するとCloudWatch Logsにセキュリティログを出力することが可能です。
設定値確認
最後にDC内で設定を確認してみます。
Active Directoryのドメインコントローラーを確認するとドメインコントローラーにDirectory Serviceで作成されたリソースOUが追加されていることが分かります。
今回で作成された一連のオブジェクトはAWS Delegated GroupsとAWS ReservedのOUに格納されています。
コマンドから確認してもドメインコントローラーとしてDirectory Serviceで作成されたコンピュータがドメインコントローラーとして認識されています。
まとめ
以上、AWS Directory Services Managed Microsoft ADのハイブリッドエディションの概要と設定でした。
今までと大きく異なるのはドメインコントローラーとして追加されるという点です。
将来的に移行を行いたいといった要件の第一ステップとしてAWSにドメイン環境やアプリケーションを拡張していく使い方がいいかと思いました。
フォレスト機能レベルやドメイン機能レベルが最新のWindows Server2025に対応していないですが、現在稼働しているActive Directoryの大半は2025未満であるため、ハンズオンをするとき以外、現状そこまで気にならないかなと思います。