Amazon EC2でActive Directory（AD）サーバーを構築し接続・管理してみた

1. 実際に構築してみた

1-1. 今回の構成

今回の構成では、AWS上にWindowsサーバーを構築しActive Directoryを構成し、同サブネットにクライアントPC相当のWindowsサーバーを構成しドメイン参加させます。

各Windowsサーバーへのリモートデスクトップ接続はフリートマネージャー経由で行います。

1-2. Windows Serverの構築

VPCの作成

今回は東京リージョンに専用のVPCを作成しました。「VPCなど」を選びサブネットも作成します。IPv4 CIDRブロックは 10.0.0.0/16 、IPv6 CIDRブロックなし。サブネットはアベイラビリティゾーン(AZ)1つで構成しました。

Windowsサーバーの構築

EC2インスタンスを新規作成します。

マシンイメージは Microsoft Windows Server 2025 Base とします。

インスタンスタイプは t3.medium とし、ログイン用のキーペアを新規作成します。

ネットワークは先ほど作成したVPCのパブリックサブネットに配置とし、同VPCからの通信を全て受け入れるようにセキュリティグループを修正します。また、パブリックIP (EIP) を有効化します。

ストレージ(EBS)はデフォルトの30GiBとしました。

これらの設定が完了したら「インスタンスを起動」をクリックします。

作成が完了すると以下のような画面となります。

「インスタンスに接続」をクリックしてサーバーの構築を継続します。

フリートマネージャー経由でサーバーへ接続

今回はAWSマネジメントコンソールで完結するフリートマネージャーでRDP接続を行います。サーバーインスタンスの起動後しばらく経過するとフリートマネージャーが利用できるようになります(赤枠)。

サーバー設定作業中に 管理者パスワードが必要になるケースもあるので「パスワードを取得」をクリックします。

事前に作成したキーペアをアップロードすることで取得できます。

フリートマネージャーでRDP接続

リモートデスクトップ接続は事前作成したキーペアを利用し「接続」をクリックします。

接続が完了すると以下のようにブラウザ経由で接続ができます。操作をする際は右上の最大化ボタンを利用すると効率が良いです。

日本語設定

必須ではないですが日本語が必要な場合は歯車の設定(Settings)の Time&Language から日本語パックをインストールします（読み上げ機能等は不要なので省いています）。

「Set as my Windows display language」をオンにすると日本語UIとなります。なおサインアウトが必要なケースがあるので、サインアウトし再接続します。

Active Directory の設定

サーバーマネージャーを起動し、「Add Roles and Features」をクリックすると。

Before you beginの内容を読み「Next」で進みます。

インストールタイプの設定では「Role-based or feature-based installation」を選び次に進みます。

サーバーロールの選択では「Active Directory Domain Services」と「DNS Server」を選択します。

Active Directory Domain Services を選択すると以下のような画面が出るので「Add features」を押します。

DNS Server を選択すると以下のような画面が出るので「Add features」を押します。

Features ではそのまま次に進みます。

Active Directory Domain Services(AD DS) では情報を確認し次へ進みます。

DNS Server では情報を確認し次へ進みます。

インストール確認の内容を確認し「Install」をします。

インストールが完了すると下記のような画面となるので「Close」で閉じます。

ドメインコントローラーの設定

Active Directory のインストールが完了すると、サーバーマネージャー上に情報アイコンが表示されます。

展開すると、ADの機能のみインストールされただけでドメインコントローラーとしての設定がされていないことが分かります。

「Promote this server to a domain controller」をクリックしてドメインコントローラーの設定を行います。

Deployment Configuration では管理対象とするドメイン(ここでは「example.local」とします)を設定します。

Domain Controller Options ではDSRM (ディレクトリサービス復元モード)のパスワードを設定します。パスワードは厳重な管理が必要となりますので注意をしてください。

DNS Options ではドメイン委任関連の警告が出ていますが、新しいフォレストで最初のドメインを構築しているため問題ありません。そのまま次に進みます。

NetBIOS ドメイン名が自動的に設定されるので次に進みます。

AD DSのデータベースのパス指定はデフォルトを利用します。そのまま次へ進みます。

オプション内容を確認し次へ進みます。

最後にDNS関連に関する警告と操作完了後に自動再起動する旨の警告が表示されます。

DNSに関しては既存のDNSインフラストラクチャと統合する場合には追加の設定を行う必要がありますが、今回は必要としないため問題ありません。

「Install」を押してドメインコントローラーをインストールします。

インストールが完了すると自動的に再起動しリモートデスクトップは切断されます。

Active Directory の操作

Active Directoryのインストールには少々時間がかかります。しばらく待ってから再度サーバーへ接続します。

再度接続し、スタートメニューを見ると Active Directory 関連機能が追加されています。

ドメインにユーザーを追加するため「Active Directory Users and Computers」を起動します。

起動すると以下のようなウィンドウが開きます。左ペインのツリー内に作成したドメイン(ここでは example.local) 配下の「Users」を右クリックし「新規作成」→「ユーザー」とたどります。

ドメイン内にユーザーを作成します。

パスワードは後にドメインログオンをする際に必要となりますので控えておいてください。

作成されたユーザーが一覧に掲載されます。このユーザーに権限をつけるため、選択して右クリックし「Add a group…」を選択します。

今回は以下のグループに所属させます。

• Administrators – ドメイン管理者
• Domain Users – ドメイン内の一般ユーザー
• Remote Desktop Users – リモートデスクトップで接続するため

上記のグループ名を入力し「名前の確認」を押すことでグループの選択ができます。最後に「OK」を押します。

以上で、EC2でWindowsサーバー内に Active Directory を機能追加し、ドメインコントローラーの設定が完了しました。

1-3. クライアント用Windowsの構築

ドメイン参加用に実物のPCを用意するのは中々難しいところです。今回はEC2でWindows サーバーを立てドメインに参加させます。また費用を抑えるためスポットインスタンスとします。

EC2でWindowsサーバーを構築する

マシンイメージは Microsoft Windows Server 2025 Base、インスタンスタイプは t3.large としました。今回、キーペアは ADサーバー に使用したものと同じものを利用します。

ネットワーク設定ではADサーバーと同一サブネットに配置をします。パブリックIPの自動割り当てはなしとします。

ストレージはデフォルトの30GiBとします。

今回はスポットインスタンスを利用するため「高度な詳細」を展開し、購入オプションで「スポットインスタンス」を選択します。

準備ができたら「インスタンスを起動」で作成を開始します。

フリートマネージャーで接続する

インスタンスの作成が完了したら接続をします。

前述しましたが起動してSession Managerが有効になるまで暫く待つとフリーとマネージャー経由でRDPが有効になるので接続します。

クライアント用のWindowsサーバーへログオンしたら、必要に応じて日本語化パックのインストール、国の変更、タイムゾーンの変更などを行います(手順は前述と同様です)。

ドメイン参加のためのDNS設定

ドメイン参加のために必要なDNSの変更を行います。

設定→ネットワークとインターネット→イーサネットと辿ります。

イーサネット設定を少しスクロールダウンし「DNSサーバーの割当て」で「編集」をクリックします。

DNS設定の編集画面がでるので、IPv4の「優先DNS」にActive Directory サーバーのIPアドレスを入力します。

ドメイン参加

ドメイン参加の操作を行うために、設定→システム と辿り「ドメインまたはワークグループ」とクリックします。

システムのプロパティが開きます。「コンピュータ名を変更したり、ドメインやワークグループを変更したりするには[変更]をクリックしてください」の記載の通り「変更」をクリックします。

コンピュータ名/ドメイン名の変更画面がでるので、下段の「所属するグループ」で「ドメイン」を選択し、前操作で構築したドメインを入力してOKを押します。

ドメイン参加するための資格情報の確認があるので、作成したドメイン内のユーザーの情報を入力します。もしエラーが出た場合は、Active Directory と DNS の疎通ができていない可能性がありますので、セキュリティグループの見直しをしてみてください。

確認が完了すると「〇〇ドメインへようこそ。」というウェルカムメッセージが表示されます。

次に再起動する旨のメッセージがでるので再起動します。

以上でドメイン参加が完了です。

1-4. ドメインログオンをしてみる

クライアントがドメイン参加したので、ログオンして確認をしてみます。

同じくフリートマネージャーを利用しますが、キーペアではなくユーザー認証情報でログオンします。

ログオン途中の画面です。クライアント用マシンにADユーザーでログインできています。

ログオン完了後に Settings → Accounts と辿りアカウント情報を確認してみます。今回作成したドメインのユーザーとしてログオンできていることが確認できました。

以上でクライアントマシンへのドメインログオンの確認は完了です。

1-5. リモートデスクトップ接続をしてみる

次にWindowsサーバーへドメインユーザーでログオンすることを試します。

ADのドメイン内に別ユーザー(ここでは試験 二郎)を作成します。Domain User、Remote Desktop Users グループに所属させておきます。

ADサーバーインスタンスの接続からフリートマネージャーでRDP接続を行います。

ログイン途中の画面です。ADサーバーにドメインユーザーでログインできていることが分かります。

ログイン完了後の画面です。ドメインユーザーでADサーバーへログインできていることが確認できました。

以上でリモートデスクトップログインの確認は完了です。

Active Directory のクラウド移行に関するご相談はこちら

2. 運用TIPs

2-1. バックアップと復元

Active Directory のバックアップにはいくつかの方法があります。

• Windows Server 標準のバックアップを利用
• サードパーティツールを利用
• AWSの機能を利用

ここではAWS環境ならではの「AWSの機能を利用」について説明します。

AWS バックアップ

AWS Backup はAWSネイティブのバックアップ機能で、サーバーの情報を丸ごとバックアップ・復元ができる便利なサービスです。

AWSバックアップを利用するメリット

• 管理の容易さ: AWS管理コンソールから一元的にバックアップ・復元ができるもので、定期的なバックアップを指定したり、ライフサイクル管理(保存期間の指定)などができます。
• 整合性: WindowsのVSS（Volume Shadow Copy Service）と連携することで、ADデータベースの整合性を保った状態のバックアップ（アプリケーション整合性バックアップ）を取得できます。
• コスト効率: バックアップデータをAmazon S3の低コストなストレージクラス（コールドストレージなど）へ自動的に移動させるライフサイクルポリシーを設定でき、長期的なコストを最適化できます。
• 安全性: バックアップデータをボールトに分離して保管するため、ランサムウェアなどの攻撃に対する耐性が高まります。

AWSバックアップのデメリット

• 復元の粒度: 基本的にインスタンス全体やEBSボリューム単位での復元が主となります。ADの特定のユーザーやグループなど、オブジェクト単位での直接的な復元はできません。オブジェクト単位で復元したい場合は、一度別の場所にインスタンスを復元し、そこから手動でオブジェクトを抽出・復旧するなどの手順が必要になります。
• AD固有の復元プロセス: ADのAuthoritative Restore（権威リストア）のような特殊な復元プロセスを直接サポートしているわけではないため、復旧シナリオによっては追加の操作が必要になります。

2-2. 情報セキュリティ

構築したADの情報セキュリティについても重要です。少なくとも以下の点についてはしっかりと考慮をするようにしてください。

ネットワークセキュリティ

• 本番運用を行うドメインコントローラーは、インターネットから直接アクセスできないプライベートサブネットに配置するのが大原則です。ADの管理を行うための踏み台サーバーや管理用端末を、ドメインコントローラーとは別の管理用サブネットに配置し、通信を厳密に制御するようにしましょう。
• またセキュリティグループでは必要最小限のポートのみを開けるように心がけましょう。

IAMによるEC2インスタンスへのアクセス制御

• EC2インスタンスにはIAMロールをアタッチし、AWSリソース（S3など）へのアクセス権を管理します。アクセスキーをインスタンス内に保存するのは避けてください。
• 本コラムで紹介したような Session Manager経由でサーバーにアクセスする構成を推奨します。これにより、ポートを開けずにセキュアなシェルアクセスやリモートデスクトップ接続が可能になり、監査ログも取得できます。

パスワードポリシー

• 複雑さ、履歴、有効期間、定期的なパスワード変更、アカウントロックアウトポリシーなどを適切に設定しましょう。
• 管理者用アカウントなど、特定のグループに対してより厳格なポリシーを適用します。

ログ取得・監視・監査

• セキュリティインシデントの早期発見と事後調査のために、ログの取得と監視は不可欠です

2-3. コスト管理

• インスタンスタイプは要件に合わせて選定を行いましょう。Windows Serverの起動後は一度に大量のリクエストをさばくことがなければ小さなインスタンスタイプでも十分な性能が出ます。また管理用の端末を別途用意することで、サーバーでGUIを動作させる必要がなくなりサーバースペックを抑えることができます。
• 開発・検証環境としての用途の場合は、利用しない夜間や休日にインスタンスを停止することでコストを大幅な削減が可能です。

Active Directory のクラウド移行に関するご相談はこちら

3. AWS上に構築したActive Directory サーバーの利用例

3-1. 検証環境として利用

EC2なら、必要な時にだけADサーバーを起動し、検証が終わればすぐに破棄する「使い捨て」な環境を低コストで実現できます。本番環境を汚すことなく、新しいアプリケーションの動作確認や、グループポリシー設定のテストを安全かつ迅速に行えます。

利用動機：

• 本番環境のActive Directoryに影響を与えずに、アプリケーションの認証テストやグループポリシーの検証がしたい。
• プロジェクトごとに独立したテスト環境が欲しいが、物理サーバーを毎回用意するのはコストも時間もかかる。
• Active Directoryに未習熟であり、本番作業の前に訓練をしたい。

利用例:

• ドメインユーザー認証が必要なWebアプリケーションの開発・動作検証
• 新しいグループポリシー（GPO）設定のリハーサル
• アクセス権限設定のテストシナリオ実施

3-2. AWS上のWindowsサーバーの管理基盤として利用

EC2で構築したADサーバーに各Windowsサーバーをドメイン参加させることで、ユーザーアカウントやパスワードポリシーを一元管理できます。これにより、管理者は単一のアカウントで各サーバーにサインインでき、セキュリティと運用効率が大幅に向上します。

利用動機：

• AWS上で複数台のWindows Server (Webサーバー、APサーバーなど) を運用しているが、サーバーごとにローカルアカウントを管理していて煩雑。
• 管理者が退職した際、どのサーバーにアカウントが残っているか把握しきれない。

利用例:

• 複数台のEC2インスタンスへのRDP（リモートデスクトップ）接続をADアカウントで統一
• RDS for SQL Server の認証をWindows認証で統合
• ユーザーの入社・退職・異動に伴うアカウント管理の効率化

3-3. ファイルサーバー(Amazon FSx for Windows Server)の認証基盤として利用

AWSが提供するフルマネージドなファイルサーバー「Amazon FSx for Windows File Server」は、Active Directoryとの連携が前提となります。EC2で構築したADを利用することで、ユーザーやグループに基づいた従来のWindowsと同様のアクセス権制御（ACL）が可能になります。

利用動機：

• AWS上で、オンプレミスのような詳細なアクセス権管理ができるファイルサーバーを使いたい。
• 部門や役職ごとに、フォルダへのアクセス権を細かく設定したい。

利用例:

• 部門共有フォルダやプロジェクト共有フォルダの構築
• ユーザーごとのホームディレクトリの提供
• Windowsのエクスプローラーから使い慣れた操作でファイル共有

Active Directory のクラウド移行に関するご相談はこちら

4. なぜAWS（EC2）上にADを構築するのか

AWS環境でActive Directory（AD）を利用する場合、主な選択肢として「AWS Managed Microsoft AD」と「Amazon EC2上にActive Directoryを構築する」の2つがあります。

この2つは似ているようで、管理責任、コスト、機能、柔軟性において大きな違いがあります。どちらを選択するかは、要件や運用体制によって決まります。

4-1. AWS Managed Microsoft ADとの比較

両者の比較を以下に記します。

• 横にスクロールします

4-2. 敢えて EC2 で Active Directory を構築する意義

マネージドサービスである AWS Managed Microsoft AD にメリットが多くあるように見えますが、EC2で構築する意義がいくつかあります。

① 完全な管理者権限（Domain/Enterprise Admins）の掌握

これがEC2を選択する最大の理由と言えます。AWS Managed Microsoft ADでは、サービスの安定性とセキュリティを担保するために、ユーザーはDomain AdminsやEnterprise Adminsといった最高レベルの管理者権限を持つことができません。

特殊なアプリケーションの要件: 一部のアプリケーション（例: Microsoft Exchange Serverの旧バージョン、特定のID管理ツールなど）は、インストールや設定の過程でDomain Admins権限やEnterprise Admins権限を要求します。これらのアプリケーションを利用するには、EC2上にADを構築するしかありません。

高度なセキュリティ構成: ADの階層管理モデル（Tier Model）や、Red Forest (ESAE) といった高度なセキュリティアーキテクチャを厳密に実装するには、最高権限によるオブジェクトのアクセス許可（ACL）の深いレベルでのカスタマイズが必要となり、EC2が必須となります。

② 自由なスキーマ拡張と変更

ADの「スキーマ」とは、ディレクトリ内に作成できるオブジェクト（ユーザー、コンピューターなど）の種類や、それらが持つ属性（名前、電話番号など）を定義しています。

一部のソフトウェア(Microsoft Exchange, Skype for Business (Lync) や、特定のCAD/PLMソフトウェアなど)は、ADのスキーマを大幅に拡張・変更する必要があります。AWS Managed ADでもスキーマ拡張は可能ですが、既存のコア属性の変更ができないなどの制約があるため、要件を満たせない場合があります。EC2であれば、オンプレミス環境と全く同じように自由なスキーマ操作が可能です。

③ ドメインコントローラーへの直接アクセスとソフトウェア導入

EC2インスタンスは、ユーザーが管理する通常のサーバーです。そのため、リモートデスクトップ（RDP）で直接サインインできます。

• サードパーティ製エージェントの導入: セキュリティ監視、資産管理、ログ転送などのために、ドメインコントローラー自体に専用のエージェントをインストールする必要がある場合、EC2でなければ実現できません。（例: Splunk Universal Forwarder, CrowdStrike Falconなど）
• 詳細なトラブルシューティング: ADに関する深いレベルでの問題解析やパフォーマンスチューニングを行いたい場合、サーバーに直接アクセスして、OSレベルのツールやコマンドを実行できることが重要になります。

④ 割り切った構成でコスト削減

Active Directory はそれほど負荷の高いサービスではなく比較的小さなインスタンスタイプでの運用も可能です。

また組織内での運用が前提となるため統制が効きやすく、Windows端末のログイン制御のみに利用するといった限定的な用途であれば高可用性もある程度犠牲にできると割り切れるのであれば、シングル構成 + AWS Backupというシンプルな構成にすることでランニング費用を抑えることができます。

Active Directory のクラウド移行に関するご相談はこちら

5. まとめ

本コラムでは、EC2でActive Directory環境を構築する手順をご紹介しました。また AWS で Active Directory を構築する際の注意点やマネージドサービスとの比較も行いました。

これで物理サーバーがなくてもActive Directoryを気軽に試せる環境が手に入れることができるようになります。必要な時にだけ使えるクラウドならではの手軽さとコスト効率をぜひ実感してみてください。

Active Directory のクラウド移行に関するご相談はこちら