AWS Directory Service本番運用Vol1｜Managed Microsoft AD

1. AD基盤の本番課題とAWS Directory Serviceの全体像

WindowsワークロードをAWSで本番運用する際、Active Directory（AD）による認証・認可基盤は避けて通れません。ドメイン参加・グループポリシー・シングルサインオンといった要件を、自前のドメインコントローラー運用なしで実現する手段がAWS Directory Serviceです。

本セクションでは、AD基盤の本番課題を整理したうえで、Directory Serviceの3方式（Managed Microsoft AD / AD Connector / Simple AD）・既存EUC記事との違い・本記事全体の構成を説明します。

1-1. AD基盤の本番課題

AWSでWindowsワークロードを本番運用する際、Active Directory（AD）基盤の構築・維持は長年の課題です。オンプレミスでは複数のドメインコントローラー（DC）を手動で管理し、パッチ適用・バックアップ・フェイルオーバーをすべて自力で運用するのが当たり前でした。これをAWS上で再現しようとすると、EC2にWindows Serverを立て、AD DSロールをインストールし、マルチAZ構成のためのDCレプリカを維持する必要があります。

①ドメインコントローラーの可用性確保

ドメインコントローラーは認証の単一障害点になりやすいコンポーネントです。2台以上のDCをそれぞれ異なるAZに配置してPDCエミュレーターの冗長性を確保する必要があります。しかし自前構成では、DCの健全性監視・FSMO役割の移行・DNS統合の変更など、AD固有の運用負荷が継続的に発生します。AWSマネジメントコンソールで確認できる自動フェイルオーバーの仕組みがなく、障害時の対応はすべて手動になります。

②パッチとセキュリティ管理の複雑さ

Windows ServerへのOS・ADパッチ適用は計画的な再起動が必要で、ダウンタイムを避けるためのローリングアップデート手順を都度設計する必要があります。Active Directoryのセキュリティ設定（Kerberos制約付き委任・Protected Usersグループ・監査ポリシー）は高度な専門知識を要し、設定ミスがドメイン全体のセキュリティリスクに直結します。セキュリティパッチの適用漏れは、ADをターゲットとしたランサムウェア攻撃の攻撃面になります。

③オンプレADとのハイブリッド連携の複雑さ

多くの企業はオンプレミスにADフォレストを持ち、AWSへの移行過程でハイブリッド認証環境を一定期間維持する必要があります。AWSとオンプレAD間のDNS設計・帯域確保・信頼関係の設定は複雑で、設定ミスが全社認証障害を引き起こすリスクがあります。Direct Connect・Site-to-Site VPNの冗長化も、AD可用性と直結した設計要件です。

④Windows認証依存サービスとの統合

RDS for SQL ServerのWindows統合認証・FSx for Windows File Serverのファイル共有・EC2のドメイン参加は、いずれもAD基盤に依存しています。自前構成ではこれらサービスとの統合設定を個別に実施・維持する必要があり、サービスが増えるにつれて運用コストが増大します。特にEC2インスタンスの大量追加時にシームレスドメイン参加の設定を自動化できないと、人的ミスが増えます。

Auto Scalingグループでドメイン参加を自動化するには、Systems Manager State ManagerやLaunch Templateとの連携設計が必要で、設定が複雑になります。

⑤スキーマ拡張の不可逆性

Microsoft Exchange・その他のサーバー製品はADスキーマ拡張を前提とします。スキーマ拡張は不可逆的な変更のため、適用後のロールバックができません。自前のAD環境でスキーマを変更する場合、十分な事前検証と手動スナップショットが必須です。拡張内容の検証環境を別途用意する運用コストも無視できません。

⑥IDライフサイクル管理との連携

ユーザーの入社・異動・退職に伴うアカウント作成・権限変更・無効化を、AWSリソースへのアクセス権（IAM Role・リソースポリシー）と連動して管理する仕組みが必要です。AD単体では不十分で、IAM Identity CenterやLDAPブリッジとの統合設計が求められます。退職者アカウントの無効化漏れは内部不正リスクになるため、人事システムとの連携自動化が重要です。

AWS Managed Microsoft ADはこれらの課題を解消するフルマネージドサービスです。パッチ適用・自動バックアップ・マルチAZ冗長化はAWSが担当し、利用者はADの管理作業（GPO設定・OU設計・スキーマ拡張の計画）に集中できます。AWSが管理するDCはSLA 99.95%を提供し、本番ID基盤として必要な可用性を保証します。

1-2. 読者像

本記事は次のような読者を想定しています。

• AWSでWindowsワークロードを運用するインフラエンジニア: EC2上でWindows ServerやIISを動かし、RDS for SQL ServerでWindows統合認証を使いたい方。既存のオンプレADとの関係を整理したい方。
• AD移行プロジェクトを担当するクラウドアーキテクト: オンプレのADフォレストをAWSへ段階移行、もしくはハイブリッドAD構成で共存させる設計を検討している方。
• WorkSpaces・EUCのインフラ担当者: WorkSpacesやAppStreamのディレクトリ設定に迷い、Managed Microsoft ADとAD Connectorのどちらを選択すべきか判断したい方。
• セキュリティ・コンプライアンス担当者: GPO・LDAPS・RADIUSベースMFAによるセキュリティ強化や、CloudWatch Logsへの監査ログ転送の設定方法を知りたい方。

前提知識: AWSアカウントの基本操作（VPC・EC2・IAM）と、Active Directoryの概念的な理解（ドメイン・フォレスト・OU・GPOの概念）があることを前提としています。Managed Microsoft ADの深い運用経験がなくても、本記事を通じてAWSでのAD構築・運用の全体像を把握できます。

1-3. 3方式（Managed Microsoft AD / AD Connector / Simple AD）の使い分け

Directory Serviceが提供する3方式の特性と選択基準を理解することが、設計の出発点です。

Managed Microsoft AD エディション比較

方式選択フロー

Step 1: AWS上にADフォレストを新規作成する必要があるかを確認します。

• はい → Managed Microsoft AD（Standard・Enterprise・2024 Hybrid）を選択します
• いいえ（オンプレADをそのまま使いたい） → AD Connectorを選択します

Step 2: Managed Microsoft ADを選ぶ場合、オンプレADと同一フォレストで管理したいかを確認します。

• はい（既存フォレストにAWS DCを参加・信頼関係不要） → 2024 Hybrid editionを選択します
• いいえ（AWSに独立したリソースフォレストを作り、オンプレと信頼関係で連携） → StandardまたはEnterpriseを選択します

Step 3: StandardかEnterpriseかの判断は、必要なディレクトリオブジェクト数（ユーザー・グループ・コンピューター）が3万を超えるかどうかで決まります。3万を超えるならEnterprise、3万以下ならStandardが適切です。

Step 4: 作成後にエディションを変更できない点に注意します。StandardからEnterpriseへの変更（またはその逆）は既存ディレクトリの編集では実現できず、新しいディレクトリの作成と移行が必要です。将来のオブジェクト数の増加が見込まれる場合は、初期構築時にEnterpriseを選ぶか、Hybrid editionでオンプレ側の容量設計に合わせる判断を先に行います。エディション選定は後戻りの難しい決定であるため、現在のオブジェクト数だけでなく3〜5年の成長予測を踏まえて確定してください。

AD Connectorの注意点

AD ConnectorはディレクトリをAWS上に持たないため、オンプレADが利用不可になるとAWS側の認証も停止します。Direct Connect・Site-to-Site VPNの可用性がAD認証の可用性に直結するため注意が必要です。オンプレAD廃止・全面AWSへの移行を計画している場合は、Managed Microsoft ADへの移行を推奨します。

コストと可用性の初期判断

方式選択はコストにも直結します。Managed Microsoft AD（Standard・Enterprise・Hybrid）はマネージドDCの時間課金が発生する一方、AD Connectorはディレクトリ本体を持たないため相対的に安価です。ただしAD ConnectorはオンプレADへの依存と専用線の可用性がボトルネックになります。小規模でオンプレADが既に存在する場合はAD Connector、AWS主体でWindowsワークロードを集約する場合はManaged Microsoft ADという初期判断が、後の運用コストと可用性を大きく左右します。エディション選定と方式選定はいずれも後戻りが難しいため、設計フェーズで確定させることが重要です。

なお、いずれの方式を選ぶ場合でも、本番導入前にネットワーク（VPC・サブネット・DNS解決）とオンプレ接続（Direct Connect・Site-to-Site VPN）の前提条件を確認しておくと、ドメイン参加や信頼関係の構成時に発生しがちな手戻りを防げます。これらの前提は§2以降の各トピックでも繰り返し関わるため、本記事を通して意識してください。

Simple ADの利用範囲

Simple ADはSamba 4をベースとした廉価なAD互換ディレクトリです。本物のMicrosoft ADとは異なり、GPOの高度な設定・信頼関係・スキーマ拡張・FGPPが利用できません。開発・テスト環境や小規模アプリケーションの認証用途に限定して使用し、本番エンタープライズ環境では原則としてManaged Microsoft ADを選択してください。

IAM Identity Centerとの関係

3方式はいずれもIAM Identity CenterのIDソースとして登録できます。Managed Microsoft ADをIDソースにすることで、ADグループでAWSアカウントへのSSOアクセスを管理できます。IAM Identity Centerとの詳細な統合手順については§7で解説します。

本記事の構成

本記事（Vol1）は以下の流れで解説します。§2でManaged Microsoft ADの版選定とマルチAZ可用性設計を解説します。§3でEC2・RDS・FSx・WorkSpacesとのシームレスなサービス統合を説明します。§4でオンプレADとのハイブリッドAD連携（信頼関係・AD Connector・2024 Hybrid edition）を解説します。§5でGPO・スキーマ拡張・LDAPS・MFAのセキュリティ強化手法を説明します。§6で運用・監視・コスト設計を解説します。§7でWindowsワークロード統合認証基盤とIAM Identity Center連携の実戦パターンを示します。§8では詰まりポイントとアンチパターンをまとめます。

それでは§2から、Managed Microsoft ADの版選定・マルチAZ可用性設計の詳細を解説します。設計フェーズの読者は§2から順に読み進めてください。すでにManaged Microsoft ADを導入済みで特定トピックを参照したい場合は、必要なセクションへ直接移動して読み進められます。なお各セクションはできるだけ独立して読めるよう設計されています。

2. Managed Microsoft AD基礎 — 版選定 × マルチAZ可用性

Managed Microsoft ADは、AWSがフルマネージドで提供する本物のMicrosoft Active Directoryです。本セクションでは、Standard/Enterprise/2024 Hybrid editionの版選定と、マルチAZによる可用性設計を解説します。

2-1. Standard / Enterprise エディション

Managed Microsoft ADのStandard editionとEnterprise editionは、いずれもAWSがフルマネージドで提供する本物のMicrosoft Active Directoryです。どちらを選ぶかは、ディレクトリオブジェクト数・信頼関係要件・コストによって決まります。

Standard edition — 中小規模向けの基本選択肢

Standardは最大30,000のディレクトリオブジェクト（ユーザー・グループ・コンピューターなど）をサポートします。中小企業や特定ビジネスユニット向けに設計されており、AWSにActive Directoryを新規構築したい場合や、オンプレミスADとの信頼関係を1件設定したい場合に適しています。

主な特徴:

• ディレクトリオブジェクト数: 最大30,000
• 信頼関係: 単一の双方向または一方向のフォレスト信頼
• コスト: Enterprise editionの約50%
• 用途: 中小企業/特定部門/検証・PoC環境

Standardは、AWSに新しいリソースフォレストを作成し、オンプレミスADとフォレスト信頼を結ぶ方式です。既存のADを拡張するのではなく、独立したAWS側のフォレストを新規作成し、信頼関係を通じてオンプレADユーザーがAWSリソースへアクセスできる構成にします。

Enterprise edition — 大規模・複数信頼関係向け

Enterpriseは最大500,000のディレクトリオブジェクトをサポートし、複数の信頼関係を設定できます。大規模エンタープライズ環境、複数のドメインやフォレストとの統合が必要なケース、グローバル企業の複雑なAD構成に最適です。

主な特徴:

• ディレクトリオブジェクト数: 最大500,000
• 信頼関係: 複数の双方向・一方向フォレスト信頼
• コスト: Standard editionの約2倍
• 用途: 大規模エンタープライズ/複数ドメイン統合/グローバル展開

EnterpriseもStandardと同様、AWSに新規リソースフォレストを作成します。Standardとの本質的な違いは「スケール」と「複数信頼関係への対応」です。また、Enterprise限定でマルチリージョンレプリケーションが利用でき、複数リージョンへのDC配置が可能になります。

Standard vs Enterprise 選択比較表

マルチリージョンレプリケーションはEnterprise専用機能です。複数リージョンにまたがるグローバル展開をする場合は必ずEnterpriseを選択してください。

版選定の基準

Standardを選ぶとき:

• ユーザー数が現在も将来的にも20,000以下で推移する見込み
• 信頼関係が1件で済む（オンプレADとの単純なフォレスト信頼）
• 単一リージョン運用
• コスト最適化を優先したい

Enterpriseを選ぶとき:

• ユーザー数が20,000を超える、または将来的な増加が見込まれる
• 複数のドメインやフォレストとの信頼関係が必要
• マルチリージョン展開が必要（グローバル組織）
• スケールアウト余地を長期的に確保したい

新規リソースフォレストの作成フロー

Managed Microsoft ADの作成はAWSコンソールまたはCLIで行います。

# Managed Microsoft AD（Enterprise）の作成例
aws ds create-microsoft-ad \
  --name "corp.example.com" \
  --short-name "CORP" \
  --password "Admin@Password123" \
  --edition "Enterprise" \
  --vpc-settings VpcId=vpc-12345678,SubnetIds=subnet-aaa,subnet-bbb \
  --description "Production Managed Microsoft AD"

作成完了後、AWS側にcorp.example.comというリソースフォレストが作成されます。このフォレストはオンプレミスADとは独立した新規フォレストです。既存のオンプレADとの統合は、信頼関係（フォレスト信頼）を設定することで実現します（§4で解説）。

ディレクトリの共有（マルチアカウント）

Managed Microsoft ADはAWS Resource Access Manager（RAM）を通じて複数のAWSアカウントからの利用が可能です。共有された側のアカウントはEC2ドメイン参加・RDS Windows認証などのサービス統合に活用できます。

共有時の課金の注意点:

• 共有先アカウント1件ごとに追加費用が発生（約$50/月）
• 共有元アカウントのディレクトリ自体の費用は別途発生
• マルチアカウント構成では事前に共有先アカウント数を確認し予算計画に組み込むことが重要

2-2. 2024 Hybrid edition — 既存フォレスト拡張方式

2024 Hybrid editionは、2024年に一般提供が開始されたManaged Microsoft ADの新しい展開オプションです。従来のStandard/Enterpriseとは根本的にアーキテクチャが異なります。

従来方式との根本的な違い

従来のStandard/Enterpriseは、AWSに新規リソースフォレストを作成し、オンプレADとフォレスト信頼関係を結ぶ方式でした。

• AWSに独立したADフォレストが1つ追加される
• 認証はオンプレADとAWS AD双方が関与する
• 信頼関係の設定・維持が必要（DNS委任/ファイアウォールルール/AD信頼ウィザード操作）

2024 Hybrid editionは全く異なるアプローチをとります。既存のオンプレADフォレストにAWSマネージドのドメインコントローラーを直接参加（Join）させる方式です。

• 新規フォレストを作成しない（既存フォレストを拡張する）
• 信頼関係は不要（同一フォレスト内）
• AWSが提供するのはマネージドDCの運用管理のみ
• オンプレADのユーザー・グループ・GPOをそのままAWSリソースへ適用できる

2024 Hybrid editionの仕様

2024 Hybrid editionの主な利点

信頼関係設定が不要になる点が最大のメリットです。信頼関係を結ぶためのDNS条件付きフォワーダー設定・ファイアウォールのポート開放・Active Directoryドメインと信頼のウィザード操作が不要になります。従来の方式ではこの設定フェーズで多くのトラブルが発生していました。

既存ADオブジェクトをそのまま利用できる点も重要です。オンプレADのユーザー/グループ/GPOをそのままAWSリソースへ適用できます。同一フォレスト内のオブジェクトとして扱われるため、認証フローがシンプルになります。

また、DNSは既存のものをそのまま活用できます。新規フォレストを作成しないため、DNSゾーン委任設定が最小限で済みます。

2024 Hybrid editionの制約と注意点

• 既存オンプレADフォレストが必須（AWS単独での新規AD作成には使えない）
• Direct ConnectまたはSite-to-Site VPNが必須（インターネット経由は不可）
• フォレスト機能レベルがWindows Server 2012 R2以上であること
• ADデータが全てAWS側DCにもレプリケーションされる（機密オブジェクトの取り扱い要注意）
• マルチリージョンレプリケーションは利用不可

版の選択フロー

オンプレADが存在するか？
├─ No → Standard または Enterprise を選択（新規リソースフォレスト作成）
│ユーザー数 < 30,000 → Standard
│ユーザー数 ≥ 30,000 または複数信頼・マルチリージョン → Enterprise
└─ Yes → 既存フォレストにAWS DCを参加させたいか？
 ├─ Yes（信頼関係不要で統合を簡略化したい） → 2024 Hybrid edition
 └─ No（独立したAWSフォレストを管理したい） → Standard または Enterprise

2-3. マルチAZ可用性とデプロイ手順

マルチAZ設計とドメインコントローラーの自動配置

Managed Microsoft AD（Standard/Enterprise/2024 Hybrid edition いずれも）は、作成時に指定した2つのサブネット（異なるAZ）に自動的にドメインコントローラー（DC）を配置します。

• 自動冗長化: AWSが2つのDCを管理します。どちらかのDCやAZが障害になっても、もう一方のDCで認証・ドメイン操作が継続します。
• ユーザー管理不要: DCの台数・配置・AD内部レプリケーションはAWSが全て管理します。手動でDCを追加・削除する必要はありません。
• DC IPアドレスの確認: 作成後にDirectory Serviceコンソールで確認できるDNSサーバーIPが実質的なDCのIPアドレスです。

VPC・サブネット要件

Managed Microsoft ADをデプロイする前に以下を確認してください。

1. 2つのサブネットが必要: 異なるAZにそれぞれ1つのサブネットを用意します。
2. プライベートサブネット推奨: DCを外部から直接到達させる必要はありません。インターネット接続のないプライベートサブネットへの配置を推奨します。
3. セキュリティグループ: Managed Microsoft ADが自動でセキュリティグループを作成します。手動で変更すると動作が不安定になるため、原則として変更しないでください。
4. DNS設定（重要）: Managed Microsoft ADを作成した後、VPCのDHCPオプションセットのDNSサーバーをManaged ADのDNSアドレスに変更します。これを怠るとEC2インスタンスがドメインを名前解決できず、ドメイン参加に失敗します。

デプロイ手順（コンソール）

1. AWSコンソールで「Directory Service」→「ディレクトリの作成」を選択します。
2. ディレクトリタイプ「AWS Managed Microsoft AD」を選択します。
3. エディション（Standard / Enterprise）を選択します。
4. ディレクトリのDNS名（例: corp.example.com）とNetBIOS名（例: CORP）を入力します。
5. 管理者（Admin）パスワードを設定します。
6. VPCと2つのサブネット（異なるAZに各1つ）を選択します。
7. 作成をクリックします。約20〜45分でプロビジョニングが完了します。

# 作成後のステータスとDNSアドレス確認
aws ds describe-directories \
  --directory-ids d-xxxxxxxxxx \
  --query 'DirectoryDescriptions[0].{Stage:Stage,DNSIpAddrs:DnsIpAddrs}'

作成完了後はStage: Activeになります。DnsIpAddrsに表示されるIPアドレスをVPCのDHCPオプションセットに設定します。

# DHCPオプションセットの作成と関連付け（DNS更新）
DHCP_OPT=$(aws ec2 create-dhcp-options \
  --dhcp-configurations Key=domain-name-servers,Values=10.0.0.10,10.0.1.10 \
  --query 'DhcpOptions.DhcpOptionsId' --output text)

aws ec2 associate-dhcp-options \
  --dhcp-options-id "$DHCP_OPT" \
  --vpc-id vpc-12345678

可用性と障害時の挙動

マルチリージョン展開（Enterprise限定）

Enterprise editionのみ、マルチリージョンレプリケーションが利用できます。セカンダリリージョンにDCを追加することで、リージョン間のレイテンシを最小化した認証と、リージョン障害時の継続運用が可能です。

# マルチリージョン追加（Enterprise専用）
aws ds add-region \
  --directory-id d-xxxxxxxxxx \
  --region-name ap-southeast-1 \
  --vpc-settings VpcId=vpc-99999999,SubnetIds=subnet-xxx,subnet-yyy

StandardはマルチリージョンレプリケーションN/Aです。複数リージョン運用が必要になった場合は、Enterpriseへのアップグレードを検討してください。なお、Standard→Enterpriseへのアップグレードはin-placeでは行えません。新規Enterpriseディレクトリを作成してオブジェクトを移行する必要があります。

3. ドメイン参加&サービス統合 — EC2 × RDS × FSx × WorkSpaces

Managed Microsoft ADの価値は、AWSの各サービスがディレクトリを共有して統合認証を実現できる点にあります。本セクションでは、シームレスドメイン参加と各サービスの統合を解説します。

3-1. シームレスドメイン参加（EC2 Windows / Linux）

EC2のシームレスドメイン参加は、インスタンス起動時にManaged Microsoft ADのドメインへ自動参加させる機能です。従来のオンプレミス環境では、ドメイン参加のためにドメインコントローラーへのアクセス、管理者資格情報の入力、手動再起動という手順が必要でした。シームレスドメイン参加はこれらを自動化します。

EC2起動時のドメイン参加設定

EC2コンソールの「Advanced details」→「Domain join directory」でディレクトリを選択するだけで、インスタンス起動と同時にドメイン参加が完了します。AWS CLIで起動する場合は次の通りです。

aws ec2 run-instances \
  --image-id ami-xxxxxxxxxxxx \
  --instance-type t3.medium \
  --subnet-id subnet-xxxxxxxxxxxx \
  --security-group-ids sg-xxxxxxxxxxxx \
  --iam-instance-profile Name=EC2DomainJoin \
  --domain-id d-xxxxxxxxxxxx \
  --key-name my-key-pair

Launch Templateにディレクトリ設定を含めることで、Auto ScalingグループはEC2をドメインへ自動起動できます。スケールアウト時のコンピュータアカウントが指定OUへ自動作成されるため、GPO適用が自動で有効化されます。

必要なIAMロール

EC2インスタンスには以下のIAM管理ポリシーが必要です。

アプリサーバーには上記2ポリシーで十分です。管理用ワークステーションには AWSDirectoryServiceFullAccess を追加します。

Systems Manager経由の自動参加

既存のEC2インスタンスや後からドメイン参加させたいケースでは、SSM State Managerの AWS-JoinDirectoryServiceDomain ドキュメントを使用します。

aws ssm create-association \
  --name "AWS-JoinDirectoryServiceDomain" \
  --parameters \
 "directoryId=d-xxxxxxxxxxxx,\
 directoryName=corp.example.com,\
 directoryOU=OU=Servers\,OU=Corp\,DC=corp\,DC=example\,DC=com,\
 dnsIpAddresses=10.0.1.10\,10.0.2.10" \
  --targets Key=tag:Environment,Values=production \
  --schedule-expression "rate(30 minutes)"

--targets でタグを使ったターゲット指定が可能なため、新規起動したインスタンスに自動でドメイン参加を適用するパターンが組めます。

ドメイン参加後のWindows EC2設定

ドメイン参加が完了したWindows EC2には、以下の設定が自動適用されます。

• DNSサーバーがManaged Microsoft ADのIPアドレスに更新される
• 指定したOUにコンピュータアカウントが作成される
• ローカル管理者グループに AWS Delegated Administrators が自動追加される
• GPOが即時適用可能な状態になる

参加確認コマンド:

# ドメイン参加確認
(Get-WmiObject Win32_ComputerSystem).PartOfDomain

# DCへのアクセス確認
nltest /dsgetdc:corp.example.com

Linux EC2のドメイン参加

Linux EC2（Amazon Linux 2023/Ubuntu/RHEL）もシームレスドメイン参加に対応しています。手動参加する場合の手順は次の通りです。

# 必要パッケージのインストール（Amazon Linux 2023の例）
sudo dnf install -y realmd sssd sssd-tools oddjob \
  oddjob-mkhomedir adcli samba-common-tools krb5-workstation

# ドメイン探索
realm discover corp.example.com

# ドメイン参加（管理者資格情報が必要）
sudo realm join --user=Admin corp.example.com

# ホームディレクトリ自動作成の有効化
sudo authselect select sssd with-mkhomedir
sudo systemctl restart sssd

ドメイン参加後はKerberosチケットを使ったAD認証でのSSH接続が有効になります。管理作業は AWS Delegated Administrators グループのメンバーが sudo で実施できます。

OU配置の設計ポイント

シームレスドメイン参加では、コンピュータアカウントの作成先OUを指定できます。環境ごとのOUを事前に設計しておくと、各OUにリンクしたGPOで設定を自動適用できます。

Corp
├── Servers
│├── Production  ← 本番EC2
│├── Staging  ← ステージングEC2
│└── Development ← 開発EC2
├── Workstations ← 管理用EC2/WorkSpaces
└── ServiceAccounts ← サービスアカウント

OUへのGPOリンクで、パスワードポリシー・監査ポリシー・Windowsファイアウォール設定を環境ごとに自動適用できます。

3-2. RDS Windows認証 / FSx for Windows統合

RDS for SQL Server の Windows認証

Amazon RDS for SQL ServerはManaged Microsoft ADとのKerberos統合認証をサポートします。ADユーザー/グループでデータベース接続ができ、SQL Serverのローカルユーザー管理が不要になります。

設定手順は次の通りです。

1. RDS用IAMロールの作成

aws iam create-role \
  --role-name rds-directoryservice-role \
  --assume-role-policy-document '{
 "Version": "2012-10-17",
 "Statement": [{
"Effect": "Allow",
"Principal": {"Service": "rds.amazonaws.com"},
"Action": "sts:AssumeRole"
 }]}'

aws iam attach-role-policy \
  --role-name rds-directoryservice-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AmazonRDSDirectoryServiceAccess

2. RDS起動時のディレクトリ指定: コンソールの「Windows Authentication」でディレクトリIDとIAMロールを指定します。RDSインスタンスがドメインに参加し、SPN（Service Principal Name）が自動登録されます。

3. ADユーザーのSQL Serverログイン作成

-- Windowsログインの作成
CREATE LOGIN [CORP\SQLDBAdmin] FROM WINDOWS;
CREATE LOGIN [CORP\AppServiceGroup] FROM WINDOWS;

-- データベースへの権限付与
USE [AppDatabase];
CREATE USER [CORP\AppServiceGroup] FOR LOGIN [CORP\AppServiceGroup];
ALTER ROLE db_datareader ADD MEMBER [CORP\AppServiceGroup];
ALTER ROLE db_datawriter ADD MEMBER [CORP\AppServiceGroup];

Kerberosベース認証の仕組み

Windows認証はKerberosプロトコルで実現します。認証フローは次の通りです。

1. クライアントがManaged Microsoft ADからKerberos TGT（チケット交付チケット）を取得します
2. TGTを使ってSQL ServerのサービスチケットをDCに要求します（SPNを参照して対象サービスを特定）
3. サービスチケットをSQL Serverに提示し、パスワードレス認証を完了します

RDSにはSPNが自動登録されるため、オンプレミス環境で必要だった手動SPN登録は不要です。

RDS for PostgreSQL のKerberos認証

PostgreSQLもManaged Microsoft ADとのKerberos統合をサポートします。

# Kerberosチケット取得後の接続
kinit dbuser@CORP.EXAMPLE.COM
psql "host=mydb.xxxx.us-east-1.rds.amazonaws.com \
  dbname=myapp \
  user=dbuser@CORP.EXAMPLE.COM \
  krbsrvname=postgres"

FSx for Windows File Server の統合

FSx for Windows File ServerはManaged Microsoft ADとの完全統合により、WindowsファイルサーバーをAWSでフルマネージドに運用できます。

ファイルシステム作成時にディレクトリIDを指定すると、FSxがドメインへ参加し、指定OUにコンピュータアカウントが作成されます。ドメインに参加したWindowsクライアント/EC2からSMB共有として自動マウントが可能です。

# 永続マウントの設定
New-SmbMapping -LocalPath "Z:" `
  -RemotePath "\\fs-xxxxxxxxxxxx.corp.example.com\share" `
  -Persistent $true

ADグループを使ったフォルダ単位の細かいアクセス権設定が可能です。最小権限原則に従い、ADグループ単位でアクセスを制御します。Windowsエクスプローラーの「セキュリティ」タブからGUI操作でNTFS権限を設定できます。

DFS名前空間の活用

複数のFSxファイルシステムを単一名前空間にまとめ、ユーザーに対して統一フォルダパスを提供できます。

# DFSルートの作成
New-DfsnRoot -TargetPath "\\server\corp" `
  -Path "\\corp.example.com\data" -Type DomainV2

# DFSフォルダターゲットの追加
New-DfsnFolderTarget -Path "\\corp.example.com\data\projects" `
  -TargetPath "\\fs-xxxxxxxxxxxx.corp.example.com\projects"

DFS名前空間を使うと、FSxファイルシステムの移行やマルチリージョン展開時もユーザーのフォルダパスを変えずに済みます。

3-3. WorkSpaces統合とディレクトリ共有

WorkSpaces Personal / Pooled のドメイン参加方式

Amazon WorkSpacesはManaged Microsoft ADをID基盤として利用します。WorkSpaces作成時にディレクトリを指定することで、仮想デスクトップがドメインに参加し、ADユーザー/グループでサインインできます。

• Personal WorkSpaces: ユーザーごとの永続デスクトップです。ADユーザーアカウントに紐付き、ユーザーのOU配置に従ったGPO適用が可能です。プロファイルはWorkSpaces内に保持されます。

• Pooled WorkSpaces: セッション型の共有デスクトップです。ユーザーデータはS3/FSxに分離して保存するため、どのデスクトップにサインインしても同じ環境が再現されます。WorkSpaces Thin Clientとの組み合わせが増えています。

WorkSpaces管理コンソールからディレクトリを登録すると、ディレクトリ内に専用OUが作成されます。詳細な設定はEUC本番運用記事を参照してください。

AppStream 2.0 のディレクトリ統合

AppStream 2.0もManaged Microsoft ADと統合できます。ディレクトリ参加を設定することで、ADユーザー/グループによるアプリアクセス制御が可能になります。ユーザーのホームフォルダ（FSx/S3接続）とGPOが適用されます。

追加アカウント/VPCへのディレクトリ共有

Managed Microsoft ADは、単一ディレクトリを複数のAWSアカウント/VPCから利用するディレクトリ共有をサポートします。組織横断のAD基盤として有効なパターンです。

設定手順は次の通りです。

1. ディレクトリを所有するアカウントで共有設定を実施します
2. 共有先アカウントが招待を承認します
3. 共有先アカウントのVPCでディレクトリのDNSエンドポイントへ到達できるルーティングを設定します

# AWS Organizationsを使ったディレクトリ共有
aws ds share-directory \
  --directory-id d-xxxxxxxxxxxx \
  --share-notes "本番アカウント向け共有" \
  --share-target Id=123456789012,Type=ACCOUNT \
  --share-method ORGANIZATIONS

ディレクトリ共有にはEC2/RDS/FSx/WorkSpacesのすべてのサービスが利用できます。共有ディレクトリの利用自体に追加料金はなく、ディレクトリ所有アカウントのDirectory Serviceコスト（時間課金）のみが発生します。マルチアカウントでWindowsワークロードを展開するランディングゾーン構成では、ネットワークアカウントまたはセキュリティアカウントにディレクトリを集約し、各アカウントに共有するパターンが一般的です。

4. ハイブリッドAD — オンプレADとの信頼関係 × AD Connector

既存のオンプレミスActive DirectoryをAWSと連携させる方法は複数あり、要件によって選択が分かれます。本セクションでは、信頼関係・AD Connector・Hybrid editionの3つのアプローチを解説します。

4-1. フォレスト信頼関係（Standard / Enterprise）

Standard/Enterpriseエディションは、AWS上に新規のリソースフォレストを作成し、オンプレミスADと信頼関係を結ぶ方式を採用します。オンプレADのユーザーがAWS側のリソース（EC2・RDS・FSxなど）にアクセスする際、フォレスト信頼を通じて認証が透過的に行われます。

フォレスト信頼の前提条件

フォレスト信頼を設定するには、AWS側とオンプレ側のネットワーク接続が必要です。具体的には、AWS Direct ConnectまたはAWS Site-to-Site VPNを通じて、Managed Microsoft ADのVPCとオンプレADの間でDNSおよびKerberos/LDAPポートが疎通している必要があります。

主要なポート要件は以下のとおりです。

信頼の方向性と種類

フォレスト信頼には一方向と双方向があります。

• 一方向信頼（片方向）: AWS側のリソースフォレストがオンプレフォレストを「信頼する（Trusting）」側となり、オンプレADのユーザーはAWS側のリソースにアクセスできます。逆方向のアクセスは不可です。オンプレユーザーがAWSリソースを利用するシナリオ（RDS for Windows・FSxへの接続など）では片方向の信頼で十分です。
• 双方向信頼: 双方が互いを信頼するため、AWS側のアカウントがオンプレリソースにもアクセスできます。より広範な統合が必要な場合に選択しますが、セキュリティ境界が広がる点に注意が必要です。

Standardエディションの制限

StandardエディションでサポートされるのはExternalドメイン信頼（単一ドメイン間）のみです。フォレスト全体をカバーするフォレスト信頼はEnterpriseエディション専用機能です。オンプレ側が複数ドメインを持つフォレスト構成の場合はEnterpriseエディションを選択してください。

DNS条件付きフォワーダーの設定

信頼関係を設定する前に、双方のDNSに条件付きフォワーダー（Conditional Forwarder）を追加する必要があります。

AWS側のManaged Microsoft ADでは、Route 53プライベートホストゾーンまたはAD内のDNS管理ツールからオンプレドメインのフォワーダーを設定します。オンプレ側のDNSサーバーにはAWS Managed Microsoft ADのDNSエンドポイントIPアドレスへのフォワーダーを追加します。

# オンプレ側のWindowsサーバーでPowerShellにて条件付きフォワーダーを追加する例
Add-DnsServerConditionalForwarderZone `
  -Name "corp.aws.example.com" `
  -MasterServers 10.0.0.10, 10.0.1.10 `
  -ReplicationScope Forest

AWSコンソールからの信頼設定手順

1. AWS Directory Serviceコンソールで対象ディレクトリを選択します。
2. 「信頼関係」タブを開き、「信頼関係の作成」をクリックします。
3. 信頼タイプ（フォレスト/外部ドメイン）、オンプレ側ドメイン名、信頼方向、信頼パスワードを入力します。
4. 条件付きフォワーダーのIPアドレスを入力し、「作成」を実行します。
5. オンプレ側のActive Directoryドメインサービスで同じ信頼パスワードを使い、対応する信頼関係を作成します。
6. 双方で「信頼の検証」を実行し、ステータスが「Verified」になることを確認します。

SIDフィルタリング（検疫）

フォレスト信頼には、クロスフォレストで不正なSID（セキュリティID）の転送リスクがあります。Managed Microsoft ADはデフォルトでSIDフィルタリング（SID Quarantine）を有効化しており、信頼されたフォレストからSID履歴を含む認証トークンが到来しても、余分なSIDを除去します。これはセキュリティ上の重要な保護機能です。無効化は推奨しません。

4-2. AD Connector（認証プロキシ方式）

AD Connectorは、AWS上にADデータベースを持たず、オンプレADへの認証プロキシとして機能するサービスです。Managed Microsoft ADがリソースフォレストを作成するのに対し、AD Connectorはすでに存在するオンプレADをそのまま利用します。

AD Connectorの仕組み

AD Connectorは、AWS上で動作するプロキシとして以下の処理を行います。

1. ユーザーがAWSサービス（WorkSpaces・EC2・アプリケーションなど）に認証要求を送信します。
2. AD ConnectorがオンプレADへLDAP/Kerberos認証リクエストを転送します。
3. オンプレADが認証結果を返し、AD Connectorが応答をAWSサービスへ中継します。

AD Connector自体はディレクトリデータを保持しないため、ユーザー情報の二重管理が不要です。

サイズの選択

AD Connectorのユースケース

AD Connectorが有効なシナリオは次のとおりです。

• WorkSpaces + オンプレAD統合: WorkSpacesをオンプレADのユーザーアカウントで管理したい場合、AD ConnectorはAWS上に新規フォレストを作成せずに統合できます。オンプレADの単一IDソースを維持できる利点があります。
• 段階的クラウド移行: まずAD Connectorでオンプレ認証を利用し、移行完了後にManaged Microsoft ADへ切り替えるといったアプローチが可能です。
• コスト優先: Managed Microsoft ADよりも料金が低く、小規模環境でのコスト削減に有効です。

AD Connectorの制限事項

AD Connectorには重要な制限があります。

• 書き込み操作不可: AD Connectorを通じたADへの書き込み（ユーザー作成・パスワードリセットなど）はできません。読み取り専用の認証プロキシとして機能します。
• オンプレ依存: Direct ConnectまたはVPN接続が切断されると認証が停止します。可用性はオンプレADとネットワーク接続に依存します。
• 一部AWSサービス非対応: RDS for Windows認証はManaged Microsoft ADのみ対応です。AD ConnectorではRDS for Windowsの統合認証を利用できません。
• DNS要件: AD ConnectorのVPCで、オンプレDNSへ名前解決を転送する設定が必要です。

Managed Microsoft ADとの使い分け

4-3. Hybrid edition（既存フォレスト拡張）

2024年に一般提供が開始されたHybrid editionは、従来の「AWSに新規フォレストを作成して信頼を結ぶ」方式とは根本的に異なるアプローチです。既存のオンプレADフォレストにAWS上のドメインコントローラー（DC）を直接参加させ、単一フォレストのまま拡張します。

Hybrid editionの動作原理

Standard/Enterpriseエディションでは、AWS側に独立したリソースフォレストを作成してオンプレADと信頼関係を結びます。一方、Hybrid editionは既存オンプレフォレストのメンバーDCとしてAWSに追加されます。

この方式により以下が実現します。

• 信頼関係が不要: 同一フォレスト内にDCが配置されるため、クロスフォレスト認証の複雑さが排除されます。
• 既存ユーザー・グループポリシーの継承: オンプレADで定義されたGPO・OU・グループ設定がそのままAWS側DCにも適用されます。
• レプリケーション: オンプレDCとAWS側DCの間でAD標準のレプリケーションが行われ、ディレクトリ内容が同期されます。

スペックと上限

Hybrid editionの主要な仕様は次のとおりです。

Hybrid editionの利点

• シングルサインオンの簡略化: 信頼関係を経由しないため、KerberosチケットのクロスフォレストSID変換などが発生せず、SSO設定がシンプルになります。
• 管理一元化: オンプレADの管理者が既存ツール（Active Directory管理センター・PowerShell AD module）でAWS側DCも管理できます。追加の権限設計や委任設定が不要です。
• GPO適用の一貫性: AWS上にドメイン参加したEC2インスタンスにも、オンプレADで定義したGPOがそのまま適用されます。

既存AD環境への影響と考慮点

Hybrid editionは既存フォレストを拡張するため、導入前に以下を十分に検討してください。

• DC追加の影響: 新規DCをフォレストに参加させるため、既存のスキーマバージョン・機能レベル（Forest Functional Level/Domain Functional Level）との互換性を確認します。
• レプリケーショントポロジー: Direct Connect/VPNの帯域とレイテンシが、ADレプリケーションのパフォーマンスに影響します。高レイテンシ環境では、サイトリンクコストを調整してレプリケーションスケジュールを最適化します。
• Direct ConnectのSLA: Hybrid editionはオンプレDCとの同期を前提とするため、ネットワーク接続の可用性がAWS側DC機能に直結します。冗長化されたDirect ConnectまたはバックアップとしてのVPN構成を推奨します。
• ADデータのAWS側保持: Hybrid editionでは全ディレクトリデータがAWS側DCにもレプリケーションされます。機密性の高いADオブジェクト（サービスアカウント・特権グループなど）がAWS側に複製される点をセキュリティポリシーと照らし合わせてください。
• 削除操作の影響範囲: オンプレADでのオブジェクト削除はAWS側にも伝搬します。スコープを意識した操作が必要です。

移行パターン: オンプレADからの段階移行

既存環境からHybrid editionへ移行する場合、段階的アプローチが有効です。

フェーズ1 — 調査・準備

現行オンプレAD環境の機能レベル・スキーマバージョン・ディレクトリオブジェクト数・レプリケーション健全性を確認します。特に、Hybrid editionがサポートするAD機能レベルの要件（Windows Server 2012 R2以上のDomain/Forest Functional Level）を満たしているかを事前検証します。

# オンプレPowerShellでフォレスト機能レベルを確認
Get-ADForest | Select-Object Name, ForestMode
Get-ADDomain | Select-Object Name, DomainMode

フェーズ2 — テスト環境での検証

本番フォレストへの参加前に、テスト用ADフォレストでHybrid editionのDC追加をリハーサルします。GPO適用の挙動・レプリケーション所要時間・AWSリソース（EC2）のドメイン参加を検証します。

フェーズ3 — 段階的本番移行

1. Direct Connect/VPNの疎通確認とADポートの開放
2. AWS Managed Microsoft AD（Hybrid edition）ディレクトリの作成
3. 既存フォレストへのDC参加設定
4. レプリケーション完了の確認（オブジェクト数・最終レプリケーション日時）
5. 一部EC2インスタンスをAWS側DCでドメイン参加し動作確認
6. 全体切り替えと監視強化

フェーズ4 — 安定稼働後の最適化

ADサイトリンクコストを調整してAWS側EC2の認証がAWS側DCを優先的に使うよう誘導します。これにより、Direct ConnectやVPNを経由するKerberos認証トラフィックを削減し、認証レイテンシと帯域コストを改善できます。

# AWS側DCのサイトリンクコストを低く設定してローカル優先認証を実現
Set-ADReplicationSiteLink -Identity "AWSToOnPremLink" -Cost 200
Set-ADReplicationSiteLink -Identity "AWSInternalLink" -Cost 100

5. 管理&セキュリティ — GPO × 委任管理 × スキーマ拡張 × LDAPS × MFA

Managed Microsoft ADは本物のMicrosoft Active Directoryをフルマネージドで提供するため、GPO・スキーマ拡張・LDAPS・MFAといったエンタープライズADの管理機能をほぼそのまま利用できます。一方で、ドメインコントローラー（DC）そのものへのアクセスはAWSが管理するため、自己管理ADとは異なる制約と運用パターンを理解しておく必要があります。本セクションでは、Managed Microsoft AD特有の管理・セキュリティ設計を体系的に解説します。

5-1. GPO（グループポリシー）と委任管理

Group Policy Management Console（GPMC）での管理

Managed Microsoft ADのGPO管理は、ドメイン参加した管理用EC2 WindowsインスタンスにRSATツールをインストールして行います。GPMCはWindows Server管理ツールに含まれており、次のPowerShellコマンドでインストールできます。

# RSAT（Remote Server Administration Tools）のインストール
Install-WindowsFeature -Name GPMC, AD-Domain-Services, RSAT-AD-Tools

# ドメインへの接続確認
Get-ADDomain

管理用EC2はドメイン参加後、Managed Microsoft ADの「AWS Delegated Administrators」グループに追加したユーザーでRDP接続します。このグループがGPMC操作を含む委任管理権限の起点となります。

デフォルトGPOとカスタムGPO

Managed Microsoft ADには、作成直後から以下のデフォルトGPOが存在します。

デフォルトGPOのうち「AWS Managed Active Directory Policy」はAWSが管理するポリシーであり、変更・削除は禁止されています。誤って編集しようとすると拒否されますが、万一問題が発生した場合にAWSサポートへの問い合わせが必要になります。

カスタムGPOは自ら作成したOUに対してのみ適用が可能です。具体的には、ドメイン直下の自作OU（例：「Corp」「Servers」）に新規GPOをリンクし、パスワードポリシー・スクリーンセーバーロック・ソフトウェア配布・ドライブマッピングなどを設定します。

# カスタムOUの作成
New-ADOrganizationalUnit -Name "Servers" -Path "DC=corp,DC=example,DC=com"

# GPOの作成とリンク
New-GPO -Name "ServerBaselinePolicy"
New-GPLink -Name "ServerBaselinePolicy" -Target "OU=Servers,DC=corp,DC=example,DC=com"

AWS管理ドメインでのGPO制限事項

Managed Microsoft ADでは、DCそのものへのログインやDCのレジストリ直接操作はできません。そのため、DCのシステムフォルダへのGPO適用や、一部のDCセキュリティ設定の変更は制限されています。具体的な制限として、以下の点に注意が必要です。

• DC OU直下へのGPO作成不可: ドメインコントローラーが配置される「Domain Controllers」OUにはAWSが管理するGPOのみが適用されます。管理者はこのOUへ新規GPOをリンクできません
• スキーママスターへの直接アクセス不可: FSDMOロールはAWSが管理し、直接操作はできません
• Active Directoryのサービスアカウントに対する変更不可: AWSServiceAccounts OUに存在するサービスアカウントは変更禁止です

これらの制限は、DC側の安定稼働をAWSが保証するために設けられており、通常のWindowsワークロード管理には支障がありません。

組織単位（OU）への権限委任

Managed Microsoft ADでは「AWS Delegated Administrators」グループに属するユーザーが、特定のOU管理権限を下位ユーザーに委任できます。委任管理はGPMC・ADUCいずれからも設定可能です。

# OU管理権限の委任（ADUCの委任ウィザード相当をPowerShellで実行）
$ou = "OU=Sales,OU=Corp,DC=corp,DC=example,DC=com"
$group = "CORP\SalesAdmins"

# OU内のユーザー管理権限を委任
$acl = Get-Acl -Path "AD:$ou"
$identity = New-Object System.Security.Principal.NTAccount($group)
$adRights = [System.DirectoryServices.ActiveDirectoryRights]::CreateChild `
-bor [System.DirectoryServices.ActiveDirectoryRights]::DeleteChild
$type = [System.Security.AccessControl.AccessControlType]::Allow
$rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($identity, $adRights, $type)
$acl.AddAccessRule($rule)
Set-Acl -Path "AD:$ou" -AclObject $acl

部門ごとのAD管理者にOU単位の権限を委任することで、中央集権型の管理負荷を分散できます。ただし委任先に「AWS Delegated Administrators」グループと同等の権限を付与することは、DCの管理権限に影響する可能性があるため推奨されません。

5-2. スキーマ拡張ときめ細かいパスワードポリシー

スキーマ拡張の実施手順

Managed Microsoft ADはスキーマ拡張（Schema Extension）をサポートしています。Exchange・Lync・SharePointなどのMicrosoft製品や、サードパーティアプリケーションが追加のオブジェクトクラス・属性をADスキーマへ登録する際に必要となります。

スキーマ拡張はAWSマネジメントコンソールから実施します。手順は以下のとおりです。

1. LDIFファイルの準備: 拡張内容をLDIF（LDAP Data Interchange Format）形式で記述したファイルを準備します
2. S3バケットへのアップロード: LDIFファイルをS3バケットにアップロードします
3. コンソールからの適用: Directory Serviceコンソールでディレクトリを選択し、「スキーマの拡張」セクションからS3のLDIFファイルURIを指定して実行します
4. ステータスの確認: 拡張処理には数分かかる場合があります。コンソールで「Successful」となれば完了です

# CLIでのスキーマ拡張実行
aws ds add-schema-extension \
  --directory-id d-1234567890 \
  --create-snapshot-before-schema-extension \
  --ldif-content file://schema-extension.ldif \
  --description "Exchange 2019 schema extension"

--create-snapshot-before-schema-extensionフラグを指定することで、適用前に自動スナップショットが作成されます。万一の際の復旧手段として必ず有効化してください。

きめ細かいパスワードポリシー（Fine-Grained Password Policy）

デフォルトのパスワードポリシーはドメイン全体に一律適用されますが、Fine-Grained Password Policy（FGPP）を使うことで、グループや特定ユーザーごとに異なるポリシーを設定できます。

FGPPはActive Directory Administrative Center（ADAC）またはPowerShellで設定します。

# Fine-Grained Password Policyの作成
New-ADFineGrainedPasswordPolicy `
  -Name "PrivilegedAccountPolicy" `
  -Precedence 10 `
  -MinPasswordLength 14 `
  -PasswordHistoryCount 30 `
  -MaxPasswordAge "30.00:00:00" `
  -MinPasswordAge "1.00:00:00" `
  -LockoutThreshold 5 `
  -LockoutDuration "00:30:00" `
  -LockoutObservationWindow "00:30:00" `
  -ComplexityEnabled $true `
  -ReversibleEncryptionEnabled $false

# グループへの適用
Add-ADFineGrainedPasswordPolicySubject `
  -Identity "PrivilegedAccountPolicy" `
  -Subjects "Domain Admins"

FGPPの優先度（Precedence）が低い数値ほど優先されます。複数ポリシーが競合する場合、最も低いPrecedence値のポリシーが適用されます。Managed Microsoft ADではAWSが内部アカウント向けにPrecedence 1のポリシーを使用しているため、カスタムポリシーは10以上の値を推奨します。

5-3. LDAPS（LDAP over TLS）とMFA

サーバー側LDAPS設定

LDAP（ポート389）は平文通信のため、認証情報の盗聴リスクがあります。Managed Microsoft ADはACM（AWS Certificate Manager）のプライベート証明書を使ったサーバー側LDAPS（ポート636）をサポートしています。

サーバー側LDAPSの設定手順は以下のとおりです。

1. ACMでプライベートCAを作成: ACMプライベートCAを作成し、ルートCAを発行します
2. 証明書の要求と発行: Managed Microsoft ADのDNS名（例：corp.example.com）を含むサーバー証明書をACMから発行します
3. ディレクトリへの関連付け: Directory Serviceコンソールの「LDAPSの有効化」から証明書ARNを指定します

# CLIでのLDAPS有効化
aws ds enable-ldap-s \
  --directory-id d-1234567890 \
  --type Client

# 証明書の登録
aws ds register-certificate \
  --directory-id d-1234567890 \
  --certificate-data file://server-cert.pem \
  --type ClientLDAPS

証明書はマルチAZで両方のDCに自動適用されます。証明書の有効期限が近づくと、Directory Serviceコンソールに警告が表示されます。ACMのプライベートCA証明書は自動更新されますが、更新後にディレクトリへ再登録する作業が必要な点に注意してください。

クライアント側LDAPS

クライアント側LDAPSでは、Managed Microsoft ADがLDAPクライアントとして外部ディレクトリへの接続を暗号化します。AD ConnectorがオンプレミスADとLDAPS接続する際に使用します。

# AD ConnectorでのクライアントLDAPS有効化
aws ds enable-ldap-s \
  --directory-id d-0987654321 \
  --type Server

# CA証明書の登録（オンプレADのCA証明書）
aws ds register-certificate \
  --directory-id d-0987654321 \
  --certificate-data file://onprem-ca.pem \
  --type ClientCertAuth

RADIUSベースMFA設定

Managed Microsoft ADは、RADIUSプロトコルを使ったMFA統合をサポートしています。Microsoft NPS（Network Policy Server）やDuo・RSA SecurIDなどのMFAサービスをRADIUSサーバーとして配置し、Directory Serviceから認証リクエストを転送する構成です。

設定手順は以下のとおりです。

1. RADIUSサーバーの準備: VPC内またはオンプレミスにRADIUSサーバーを配置し、Managed Microsoft ADのDCからの通信（UDP 1812）を許可します
2. ディレクトリへのRADIUS設定: コンソールまたはCLIでRADIUSサーバーのIPアドレス・ポート・共有シークレットを登録します
3. MFAの有効化: 設定完了後、MFA対応サービスでの認証時にRADIUS OTPが要求されるようになります

# MFAの有効化
aws ds enable-radius \
  --directory-id d-1234567890 \
  --radius-settings '{
 "RadiusServers": ["10.0.1.50"],
 "RadiusPort": 1812,
 "RadiusTimeout": 30,
 "RadiusRetries": 3,
 "SharedSecret": "MySharedSecret123!",
 "AuthenticationProtocol": "MS-CHAPv2",
 "DisplayLabel": "MFA Code",
 "UseSameUsername": false
  }'

UseSameUsername: falseの場合、ADユーザー名とRADIUSユーザー名を別々に管理できます。MS-CHAPv2プロトコルはパスワードをハッシュ化して送信するため、PAP（平文）より安全です。RADIUSサーバーへの通信は必ずVPC内部またはVPN経由にし、インターネット経由での公開は避けてください。

MFA対応サービスと適用範囲

RADIUS MFAが有効化されると、以下のサービスでの認証時にMFA OTPが要求されます。

WorkSpacesのMFA有効化は、WorkSpacesコンソールのディレクトリ設定から行います。Client VPNは、エンドポイント作成時に「Active Directory認証」を選択し、Managed Microsoft ADのディレクトリIDを指定します。

全ユーザーへの即時強制適用前に、管理者アカウントのパイロット導入でRADIUS接続の安定性・レイテンシ・ロックアウト挙動を検証することを推奨します。RADIUS障害時はMFA要求が応答タイムアウトとなり、対象サービスへのログインが不可になります。RADIUS冗長化（サーバーを複数登録）は本番要件として必須です。

6. 運用・監視・コスト

Managed Microsoft ADは本番のID基盤であるため、可用性・バックアップ・コストの設計が運用品質を左右します。本セクションでは、スナップショット・監視・コスト構造を解説します。

6-1. スナップショットとバックアップ

Managed Microsoft ADはAWSがフルマネージドで運用するサービスですが、万が一のディレクトリ破損や誤操作に備えたスナップショット管理を正しく理解することが重要です。

自動スナップショット

Managed Microsoft ADはデフォルトで毎日自動スナップショットを取得します。自動スナップショットの保持期間はデフォルトで30日（最大35日）に設定可能です。

# 自動スナップショットの一覧確認
aws ds describe-snapshots--directory-id d-xxxxxxxxxx--snapshot-type Auto--query 'Snapshots[*].{Id:SnapshotId,Status:Status,Created:StartTime}'--output table

自動スナップショットはAWSが無償で管理します。ユーザー側での設定は保持日数の調整のみです。保持期間の変更はDirectory Serviceコンソールのディレクトリ詳細画面から行います。

手動スナップショット

重要な変更（スキーマ拡張・OU再編成・GPO一括変更）の前後には手動スナップショットを取得することを推奨します。

# 手動スナップショットの作成
aws ds create-snapshot--directory-id d-xxxxxxxxxx--name "before-schema-extension-2026-06-11"

手動スナップショットは5個まで保持できます（ソフトリミット）。古いスナップショットを定期的に削除してリミット超過を防いでください。

# 手動スナップショットの削除
aws ds delete-snapshot--snapshot-id s-xxxxxxxxxx

スナップショットからの復元

スナップショットからの復元はAWSマネジメントコンソールまたはCLIから実行します。復元時はディレクトリが一時的にオフラインになるため、メンテナンスウィンドウ内での実施を推奨します。

# スナップショットからの復元
aws ds restore-from-snapshot--snapshot-id s-xxxxxxxxxx

復元時の注意点:

• 復元後、スナップショット取得時点以降に変更されたユーザー・グループ情報は失われます
• DNS設定・信頼関係の構成はスナップショットに含まれないため、復元後に再設定を要する場合があります
• マルチAZ構成（本番環境の標準）では、両AZのDCが同時に復元されます
• 復元操作はDirectory ServiceコンソールのSnapshotsタブから実施します（CLIから直接は操作不可の場合があります）

バックアップ戦略のベストプラクティス

マルチAZ障害時の自動フェイルオーバー

Managed Microsoft ADはマルチAZ構成のため、1つのAZが障害になっても残りのAZのDCで認証が継続します。AWS側のフェイルオーバーは自動的に行われます。ユーザーの操作は不要です。

ただし、フェイルオーバー中は一部の管理操作（GPO更新・スキーマ拡張・スナップショット取得）が一時的に利用不可になる場合があります。本番のメンテナンス作業はAWSのヘルスダッシュボードでAZ状況を確認してから実施することを推奨します。

6-2. 監視と運用

Managed Microsoft ADはAWSが管理するため、DC自体の監視は不要です。しかし、ディレクトリの健全性・認証エラー・ログ転送はユーザー側で設定する必要があります。

CloudWatch Metrics（ディレクトリメトリクス）

Managed Microsoft ADは以下のCloudWatchメトリクスを自動公開します。

# CloudWatchアラームの作成例（DCの不健全状態検知）
aws cloudwatch put-metric-alarm--alarm-name "ManagedAD-UnhealthyDC"--namespace "AWS/DirectoryService"--metric-name "DirectoryServiceDomainControllersUnhealthy"--dimensions Name=DirectoryId,Value=d-xxxxxxxxxx--statistic Sum--period 300--threshold 1--comparison-operator GreaterThanOrEqualToThreshold--evaluation-periods 1--alarm-actions arn:aws:sns:ap-northeast-1:123456789012:alert-topic

CloudWatch Logsへのセキュリティイベントログ転送

ドメインコントローラーのWindowsイベントログ（セキュリティ監査ログ）をCloudWatch Logsへ転送することで、認証失敗・権限昇格・アカウントロックアウトをSIEM統合や自動アラームで検知できます。

ログ転送の有効化手順:

1. AWSコンソールで「Directory Service」→対象ディレクトリを選択します
2. 「ログの転送」タブを開きます
3. 「ログの転送を有効にする」をクリックします
4. 転送先のCloudWatch Logsロググループを選択（または自動作成）します

# CloudWatch Logsへのログ転送有効化（CLI）
aws ds enable-log-subscription--directory-id d-xxxxxxxxxx--log-group-name /aws/directoryservice/d-xxxxxxxxxx

ディレクトリ健全性の確認

Managed Microsoft ADの健全性はDirectory Serviceコンソールで確認できます。確認項目は以下のとおりです。

• ドメインコントローラーの状態（Active / Creating / Impaired / Failed）
• ADレプリケーションの健全性
• DNS設定の正確性
• 信頼関係の状態（オンプレADとの信頼を設定している場合）

ディレクトリの状態がImpairedやFailedになった場合はAWSサポートへの連絡が必要です。

認証エラーとアカウントロックアウトの監視

大量の認証失敗はランサムウェアやブルートフォース攻撃の兆候である場合があります。WindowsイベントID 4625（認証失敗）・4740（アカウントロックアウト）をCloudWatch Logsで検知し、Lambda/SNS経由で即時アラームを設定することを推奨します。

CloudWatch Logs Insightsを使ったアカウントロックアウト検知クエリ例:

fields @timestamp, @message
| filter @message like /EventID=4740/
| sort @timestamp desc
| limit 20

定期的な設定ドリフト検査

GPO・OU・委任管理の設定は、作業ミスや不正変更によってドリフトが発生しやすいコンポーネントです。AWS Configカスタムルールまたは定期的なスクリプトで期待値との乖離を検知する仕組みを整備することを推奨します。

ログ転送コストの管理

CloudWatch Logsへのログ転送は別途CloudWatch Logsの料金（取り込み・保存）が発生します。イベントログの重要度に応じてフィルタリングを設定し、不要な詳細ログを絞り込むことでコストを管理してください。

6-3. コスト構造

Managed Microsoft ADのコストはエディション・稼働時間・共有設定によって決まります。

エディション別時間課金

最新の単価はAWS公式の価格ページを参照してください。リージョンによって価格が異なります。

ディレクトリ共有時の追加課金

1つのManaged Microsoft ADを複数のAWSアカウントで共有する場合、共有先アカウント側にアクセス時間課金が発生します。

• ディレクトリ本体（作成アカウント）: 通常のエディション時間課金
• 共有先アカウント: 共有されたディレクトリへのアクセス時間課金（エディション課金より安価）
• 同一アカウント内の追加VPCアタッチ: 追加課金なし

マルチアカウント組織でディレクトリを共有する場合は、RAM（Resource Access Manager）経由で共有先アカウントにディレクトリを共有することで、アカウントごとに個別のManaged Microsoft ADを立てるよりコストを抑えられます。

スナップショットのコスト

• 自動スナップショット: 無償（AWSが管理）
• 手動スナップショット: スナップショット保存ストレージ料金（S3標準と同等）

手動スナップショットは5個までのため、定期的な削除でストレージコストを管理できます。

コスト最適化のポイント

①開発・テスト環境ではSimple ADまたはAD Connectorを検討

本番レベルのGPO・スキーマ拡張・信頼関係が不要な開発・テスト環境では、Simple ADまたはAD Connectorを使うことでコストを大幅に削減できます。Simple ADはManaged Microsoft ADに比べ月額で大幅に低コストになります。

②未使用ディレクトリの削除

Managed Microsoft ADは稼働している間、課金が継続します。不要になったディレクトリはすぐに削除してください。ディレクトリ削除前にスナップショットを取得しておくことで、後から復元が可能です。

③ディレクトリ共有でアカウント間コストを最適化

複数のAWSアカウントで同じAD基盤が必要な場合、各アカウントに個別にManaged Microsoft ADを立てるより、1つのディレクトリを共有する方がトータルコストを下げられます。組織内のベースラインアカウント（Security AccountやInfraアカウント）にManaged Microsoft ADを集約し、全アカウントに共有するパターンを推奨します。

④ログ転送コストの管理

CloudWatch Logsへのログ転送は別途CloudWatch Logsの料金（取り込み・保存）が発生します。保存期間を適切に設定し（セキュリティ要件に応じて90日〜1年）、不要な詳細ログを絞り込むことでコストを管理してください。

30日間無料トライアル

新規作成のディレクトリは作成日から30日間、ディレクトリ使用料が無償になる無料トライアルが適用されます（リージョン・エディションに関わらず適用）。PoC（概念検証）や初期設計段階での検証コストを削減できます。無料トライアルは1つのディレクトリにつき1回のみです。

7. 実戦統合パターン — Windowsワークロード認証基盤

本セクションでは、Managed Microsoft ADを実際のエンタープライズ環境に組み込む統合パターンを、既存のEUC・IAM Identity Centerとの連携を含めて解説します。

7-1. Windowsワークロード統合認証基盤

Managed Microsoft ADを採用する最大の価値は、EC2・RDS・FSx・WorkSpaces・IAM Identity Centerを単一のID基盤で束ねる「統合認証基盤」を実現できる点にあります。本セクションでは、これらのサービスを組み合わせた実践的な統合パターンを解説します。

統合認証基盤の全体像

代表的なWindowsワークロード統合の構成は次のようになります。

1. ID基盤: Managed Microsoft AD（Standard/Enterprise）がドメインコントローラーとして認証を提供
2. Windows計算リソース: EC2 Windows ServerがシームレスドメインでADに参加し、KerberosでSQL Server（RDS）やファイルサーバー（FSx）へアクセス
3. 仮想デスクトップ: WorkSpacesが同一ディレクトリを参照し、AD資格情報でサインイン
4. AWS管理アクセス: IAM Identity CenterがManaged Microsoft ADをIDソースとしてSSOを提供し、ADグループでAWSアカウントの権限を管理

この構成では、ユーザーがオンプレADアカウント（またはManaged Microsoft ADアカウント）1つで、仮想デスクトップ・ファイルサーバー・データベース・AWS管理コンソールのすべてにアクセスできます。パスワードの重複管理をなくし、セキュリティと利便性を両立します。

ハイブリッド構成でのオンプレAD連携

既存のオンプレAD環境とManaged Microsoft ADをフォレスト信頼またはHybrid editionで統合することで、オンプレのID管理を維持しながらAWSサービスへのアクセスを実現します。

フォレスト信頼方式（Standard/Enterprise）の場合:

• オンプレADユーザーが信頼関係を通じてAWS側EC2・RDS・FSxにアクセスできます
• パスワード変更はオンプレADで行い、AWS側への同期は不要です
• 既存ADグループをそのままAWS側リソースの権限制御に利用できます

# オンプレADユーザーがAWS RDS for SQL Serverへアクセスする接続文字列（.NET例）
$connStr = "Server=mydb.xxxx.us-east-1.rds.amazonaws.com;" +
  "Database=AppDB;" +
  "Integrated Security=SSPI;"

Integrated Security=SSPI を指定するだけで、Kerberosチケットを使った自動認証が機能します。フォレスト信頼が正しく設定されていれば、オンプレユーザーは資格情報を入力することなくRDSへ接続できます。

EUC記事との連携方法

既存のEUC本番運用記事（WorkSpaces/AppStream）との連携では、本記事がAD基盤の設計・運用を担当し、EUC記事がWorkSpaces/AppStreamの固有設定を担当します。AD管理者がディレクトリのOU設計・GPO設計・グループ設計を担い、EUC管理者がその基盤を利用してWorkSpaces/AppStreamを設定する役割分担が効果的です。

WorkSpaces向けのOU設計例:

Corp
├── WorkSpaces
│├── Finance  ← 財務部門WorkSpaces（厳格なGPO適用）
│├── Engineering ← エンジニアWorkSpaces（開発ツール配布）
│└── General  ← 一般ユーザーWorkSpaces
└── AppStream
 └── SharedFleet ← AppStream共有フリートEC2

WorkSpaces/AppStreamの詳細設定については、EUC本番運用記事を参照してください。

コスト最適化パターン: ディレクトリ共有でのコスト配分

複数のAWSアカウントでWindowsワークロードを運用する場合、ディレクトリ共有を活用するとコストを最適化できます。

ディレクトリ共有のコスト構造:

1つのManaged Microsoft ADディレクトリを組織内の複数アカウントに共有することで、アカウントごとにディレクトリを作成するよりもコストを削減できます。Standard editionを組織の基盤として1つ運用し、全アカウントに共有するパターンが推奨です。

7-2. IAM Identity Center連携

IAM Identity CenterはManaged Microsoft ADをIDソース（Directory）として直接登録できます。これにより、ADユーザー/グループでAWSアカウントへのSSOアクセスが実現します。

IAM Identity CenterへのManaged Microsoft AD登録

設定手順は次の通りです。

1. IAM Identity Centerコンソールを開き、「設定」→「IDソース」→「変更」を選択します
2. 「Active Directory」を選択し、Managed Microsoft ADのディレクトリIDを指定します
3. IDソースの変更を確認・適用します

# CLIでのIdentity Center設定確認
aws sso-admin list-instances
aws sso-admin describe-instance--instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxx

ADグループを使ったAWSアカウントへの権限付与

IAM Identity CenterでManaged Microsoft ADを使用する場合、ADグループをそのままアクセス許可セット（Permission Set）に紐付けられます。

1. ADグループの作成: Managed Microsoft AD上で権限管理用グループを作成します

# ADグループの作成
New-ADGroup -Name "AWSAdmins" `
  -SamAccountName "AWSAdmins" `
  -GroupCategory Security `
  -GroupScope Universal `
  -Path "OU=AWSGroups,OU=Corp,DC=corp,DC=example,DC=com"

1. Permission Setの作成: IAM Identity Centerでアクセス許可セットを作成します

# 管理者用Permission Setの作成
aws sso-admin create-permission-set--instance-arn arn:aws:sso:::instance/ssoins-xxxx--name "AdminAccess"--description "管理者アクセス"--session-duration PT8H

1. ADグループとAWSアカウントの紐付け: IAM Identity Centerコンソールから「AWSアカウント」→対象アカウント→「グループを割り当て」でADグループとPermission Setを指定します

グループベース権限設計のベストプラクティス

IAM Identity Center + Managed Microsoft ADでの権限設計では、ADグループを次のように設計します。

ユーザーの権限変更はAD管理者がグループメンバーを変更するだけで反映されます。IAM Identity Center側の設定変更は不要です。

SSOポータルでのログインフロー

1. ユーザーがSSOポータル（https://xxxxxx.awsapps.com/start）にアクセスします
2. Managed Microsoft ADの資格情報（ドメインアカウント）でサインインします
3. 自分が所属するADグループに基づき、アクセス可能なAWSアカウントとロールが表示されます
4. 対象のアカウント/ロールをクリックするとAWSマネジメントコンソールまたはCLI認証情報が取得できます

MFAが有効な場合、§5-3で設定したRADIUS MFAがSSOポータルのサインイン時にも適用されます。

CLI/SDK経由のSSOアクセス

開発者がIAM Identity Center経由でCLIを使用する場合は、aws configure sso コマンドで設定できます。

# IAM Identity Center向けCLIプロファイルの設定
aws configure sso
# SSO session name: corp-sso
# SSO start URL: https://xxxxxx.awsapps.com/start
# SSO region: ap-northeast-1
# (ブラウザが開いてADログイン画面が表示される)

# 設定済みプロファイルを使ったコマンド実行
aws s3 ls --profile prod-developer

CI/CDパイプラインからのアクセスには、IAM Identity Centerのサービスアカウント機能（Trusted token issuer）を使ったOIDCベースの認証が推奨されます。

7-3. マルチアカウント・ディレクトリ共有と2024 Hybrid edition活用

マルチアカウントでのAD基盤設計

大規模なAWS Organizations環境では、ディレクトリ共有を組み合わせたAD基盤設計が重要です。代表的なパターンは次の通りです。

パターンA: セキュリティアカウントに集約

Organizations Root
├── Management Account← 管理アカウント (IAM Identity Center)
├── Security Account  ← Managed Microsoft AD (共有元)
│└── directory shared to ↓
├── Production Account← EC2/RDS/FSxがADを共有利用
├── Staging Account← 同上
└── Development Account  ← 同上

このパターンでは、Security AccountにManaged Microsoft ADを配置し、Control TowerのAccount Factoryで作成した全アカウントにディレクトリを共有します。組織全体でWindows認証を一元管理できます。

パターンB: Hybrid editionでオンプレ連携

2024年に一般提供されたHybrid editionは、既存のオンプレADフォレストにAWS DCを直接参加させます。このパターンでは次の効果があります。

• 移行フェーズ中のフォレスト信頼設定が不要になります
• オンプレのGPO・OU・グループをそのままAWS側でも利用できます
• ADユーザーがオンプレとAWSの両方で同一資格情報を使えます（同一フォレスト内）

移行フェーズでのHybrid edition活用パターン:

1. フェーズ1（共存）: オンプレADのフォレストにHybrid edition DCを追加。既存の認証基盤に影響なく、AWS側EC2のドメイン参加先として機能させる
2. フェーズ2（段階移行）: アプリケーションを順次AWSへ移行。ADログイン/グループポリシーはそのまま引き継ぎ
3. フェーズ3（ADの段階的クラウド移行）: オンプレDCを削減し、AWS側DCの比率を高めていく。最終的にオンプレDCをゼロにすることも可能

ディレクトリ共有のスケール設計

大規模なランディングゾーンでは、ディレクトリの共有先アカウント数が増加します。アカウント数が多い場合は次の点を考慮します。

• 共有数の上限: 1つのManaged Microsoft ADディレクトリから最大5アカウント/VPCに共有可能です（上限緩和申請で拡張可能）
• ADサイトの設計: 各アカウントのVPCをADサイトとして設定し、最寄りのDCへの認証トラフィックを誘導します
• 条件付きフォワーダー: IAM Identity CenterからManaged Microsoft ADへの名前解決が正しく機能するよう、Route 53プライベートホストゾーンとの整合性を確認します

8. 詰まりポイントとアンチパターン・まとめ

Managed Microsoft ADの本番運用では、AD固有の落とし穴があります。本セクションでは、現場で頻出する詰まりポイントとアンチパターン、そして次のステップを示します。

8-1. よくある詰まりポイント

Managed Microsoft ADの本番運用では、以下のポイントで詰まりやすいです。

詰まりポイント1: Standard版でオブジェクト数が上限に近づく

症状: ユーザー・グループ・コンピューターの合計が増加するにつれて、オブジェクト作成時にエラーが発生する。

原因: Standard editionのディレクトリオブジェクト上限は30,000です。組織の成長とともに上限へ近づくと、新しいオブジェクトの作成が拒否されます。

対処法: Directory Serviceコンソールのディレクトリ詳細画面でオブジェクト数を定期的に確認してください。25,000を超えたらEnterpriseへの移行計画を立ち上げることを推奨します。Standard→Enterpriseのin-placeアップグレードは不可なため、新規Enterpriseディレクトリを作成してオブジェクトを移行する作業が必要です。

詰まりポイント2: 2024 Hybrid editionとStandard/Enterpriseを混同してしまう

症状: 「Managed Microsoft ADを使えば信頼関係が不要になる」と誤解して選択すると、Standard/Enterpriseの場合に信頼関係設定の複雑な作業を強いられる。

原因: 信頼関係が不要になるのは「2024 Hybrid edition」のみです。Standard/Enterpriseは新規リソースフォレストを作成するため、オンプレADとの統合には信頼関係（フォレスト信頼）の設定が必要です。

対処法: 版の選択前に本記事の「§2 版選定フロー」を確認してください。既存フォレストにAWS DCを参加させたい場合はHybrid editionを選択し、Direct Connect/VPNの接続が前提条件であることも併せて確認します。

詰まりポイント3: シームレスドメイン参加でSSMエラーが発生する

症状: EC2インスタンスのシームレスドメイン参加（SSM経由）が失敗し、「Instance is not responding to SSM」や「Failed to join domain」エラーが発生する。

原因: SSMエージェントが正常に動作していない、またはEC2インスタンスのIAMロールにAmazonSSMManagedInstanceCoreポリシーが付与されていない。あるいはSSMエンドポイントへのVPCルートが存在しない。

対処法: EC2のIAMロールにAmazonSSMManagedInstanceCoreポリシーを付与してください。またSSMエージェントが最新版であることをFleet Managerで確認します。プライベートサブネットの場合はSSMのVPCエンドポイント（com.amazonaws.ap-northeast-1.ssmなど3種）を作成する必要があります。

詰まりポイント4: VPC DNSの設定漏れでドメイン参加が失敗する

症状: EC2インスタンスがドメインコントローラーに到達できず、「DNS名前解決エラー」が発生してドメイン参加コマンドが失敗する。

原因: Managed Microsoft ADを作成した後、VPCのDHCPオプションセットのDNSサーバーアドレスをManaged ADのDNSアドレスに変更していない。

対処法: Directory Serviceコンソールの「ディレクトリの詳細」画面に表示されるDNSアドレスをコピーし、VPCのDHCPオプションセットに設定してください。既存のEC2インスタンスは再起動するとDHCP設定が反映されます。

# Managed ADのDNSアドレス確認
aws ds describe-directories \
  --directory-ids d-xxxxxxxxxx \
  --query 'DirectoryDescriptions[0].DnsIpAddrs'

詰まりポイント5: 信頼関係の方向性の設定ミス

症状: オンプレADユーザーがAWSリソースにアクセスできない、または逆方向の意図しないアクセスが発生する。

原因: 信頼関係には一方向信頼と双方向信頼があり、方向性を誤って設定している。「Trusting（信頼する側）」と「Trusted（信頼される側）」の概念を混同している場合が多いです。

対処法: 「AWSリソースへのアクセスにオンプレADのアカウントを使いたい」なら、AWSフォレストがオンプレフォレストを信頼する一方向信頼で十分です。双方向信頼は双方のユーザーが相互アクセスする場合に使用します。設定後はnltest /sc_verify:オンプレドメイン名コマンドで接続を確認します。

詰まりポイント6: LDAPS証明書の更新漏れによる突然のLDAP接続断

症状: LDAPS（636番ポート）経由のアプリケーション接続が突然失敗し始める。本番環境での障害として顕在化するケースが多いです。

原因: LDAPS用に設定したサーバー証明書の有効期限切れ。証明書の自動更新設定がない場合や、更新後のディレクトリへの再登録を失念した場合に発生します。

対処法: LDAPS用証明書の有効期限を確認し、有効期限の90日前からCloudWatch Eventsで通知アラームを設定してください。ACMのプライベートCA証明書は自動更新されますが、更新後にDirectory Serviceコンソールから新しい証明書を再登録する作業が必要です。古い証明書は有効期限が切れた後に削除します。

詰まりポイント7: スキーマ拡張の不可逆性を事前に周知していない

症状: テスト用にスキーマ拡張を実施し、不要になったため削除しようとしても削除できない。テスト用の属性やオブジェクトクラスが本番ディレクトリに永続的に残留する。

原因: Active Directoryのスキーマ拡張は不可逆操作です。一度拡張したスキーマ属性は無効化（deactivated）はできますが、完全に削除することはAD仕様上できません。

対処法: スキーマ拡張は本番環境では慎重に行ってください。テスト用の検証ディレクトリを別途作成し、スキーマ拡張の影響を十分に確認してから本番に適用します。スキーマ拡張の実施前には必ずスナップショットを取得し、--create-snapshot-before-schema-extensionオプションを活用してください。

詰まりポイント8: ディレクトリ共有時の追加課金の見落とし

症状: マルチアカウント環境でディレクトリを共有したところ、AWS請求額が予想を大幅に超えた。

原因: ディレクトリを共有した先のアカウントごとに追加費用が発生します。10アカウントで共有した場合は追加費用が10倍になります。この課金体系がドキュメントの目立たない箇所に記載されており、見落とされやすいです。

対処法: マルチアカウント構成でディレクトリを共有する際は、共有先アカウント数に応じたコストを事前に試算し、予算へ組み込んでください。全アカウントで共有するのではなく、本当に必要なアカウント（EC2のドメイン参加を要するワークロードを持つアカウント）のみへ共有先を絞ることが、コスト最適化の第一歩です。

コスト確認には、AWS Cost ExplorerでサービスフィルターとしてAWS Directory Serviceを選択してください。アカウント単位・月次でのコスト推移を可視化できます。共有先アカウントを削減した場合、その月の翌月分から費用が減少します。

8-2. アンチパターン → 正解

Managed Microsoft ADの運用でよく見られるアンチパターンと、正しい設計を整理します。

8-3. コストと課金体系

Managed Microsoft ADの費用を把握せずに導入すると、想定外の請求を受けるケースがあります。主な課金要素を整理します。

版ごとの時間課金（東京リージョン概算）

料金はAWSの公式料金ページを必ず参照してください。リージョンにより異なります。

ディレクトリ共有の追加課金

Managed Microsoft ADを別のAWSアカウントへ共有すると、共有先アカウントごとに月額約$50の追加費用が発生します。10アカウントへ共有している場合は共有費用だけで$500/月になります。

同一アカウント内での別VPCへのディレクトリ共有（VPC追加関連付け）には追加費用は発生しません。費用が発生するのは、異なるAWSアカウントへの共有のみです。

コスト最適化のポイント

開発・ステージング・本番で全て異なるディレクトリを作成すると費用が3倍になります。開発環境では1つのディレクトリをOU単位で分離して共有する構成や、Simple ADで代替する構成を検討してください。OU設計とFGPPによるパスワードポリシー分離で、本番環境と開発環境の分離は十分に実現できます。

8-4. まとめ

本記事では、AWS Directory Service / Managed Microsoft ADの本番運用について、版選定・マルチAZ可用性・信頼関係・ハイブリッドAD統合・GPO管理・スキーマ拡張・LDAPS・MFA・コスト・詰まりポイントまでを体系的に解説しました。

Directory Service 使い分けサマリー

Managed Microsoft ADが解決する本番課題

自社でドメインコントローラーを運用する場合、パッチ適用・バックアップ・マルチAZ可用性の確保・DR設計にエンジニアリングリソースが必要です。Managed Microsoft ADはこれらをAWSにオフロードし、エンジニアはビジネスロジックの構築に集中できます。

特に2024 Hybrid editionは、オンプレADフォレストをそのまま拡張できるため、「信頼関係なしでのAWS統合」が実現可能になりました。オンプレADを長年維持してきた組織にとって、クラウド拡張の新しい選択肢として評価に値します。

認証・認可基盤はシステム全体の根幹であり、障害の影響範囲が広いサービスです。Managed Microsoft ADのフルマネージド化により、DCの障害対応・フェイルオーバー・バックアップリストアをAWSに委ねることで、運用チームは本来の業務に専念できる環境が整います。IAM Identity CenterとManaged Microsoft ADを組み合わせることで、AWSアクセス管理と既存のAD運用を一元化し、組織横断のID基盤として活用できます。

本番運用チェックリスト

導入前後に以下を確認することで、主要な失敗パターンを回避できます。

【版選定・初期設定】

• 版（Standard/Enterprise/Hybrid edition）の選定は組織の規模・要件に基づいて実施
• VPCのDHCPオプションセットのDNSアドレスをManaged ADのDNSに設定済み
• マルチAZ用に異なるAZの2サブネットを用意済み
• 管理者（Admin）アカウントのBreak Glass手順を整備し、日常運用は委任管理ユーザーで実施

【セキュリティ強化】

• LDAPS証明書の有効期限アラームをCloudWatchで設定済み（90日前通知推奨）
• スキーマ拡張はスナップショット取得後に実施（取り消し不可の事前周知済み）
• RADIUS MFAの冗長構成（複数RADIUSサーバー）を実装済み
• 特権アカウント向けFGPP（Fine-Grained Password Policy）を設定済み

【コスト管理】

• ディレクトリ共有先アカウント数を最小化してコストを最適化済み
• 開発環境では本番とは別のSimple ADまたはOU分離設計を採用
• 共有先アカウントの月次コストをAWS Cost Explorerで定期確認

Vol2 予告

Vol2では、ドメイン参加とサービス統合（EC2/RDS/FSx/WorkSpaces）の実践手順・ハイブリッドADの信頼関係設定詳細・GPO設計・スナップショットと監視・コスト最適化を詳しく解説予定です。

本記事はAWS Directory Service本番運用シリーズの第1回として、基礎となる版選定とセキュリティ設計を扱いました。Vol2以降では実装・統合・運用の深掘りをお届けします。