はじめに
目的
本ドキュメントは、AWS上で提供されるManaged Microsoft AD（以下、Managed AD）について分かりやすくまとめたものです。Managed ADの特徴、オンプレミスのActive Directoryとの統合方法、エディション選定、主要機能、セキュリティや信頼関係に関するポイントを順を追って解説します。
対象読者
クラウド移行を検討しているIT担当者、既にAWSを利用していてADの運用を簡素化したい方、社内システムの認証基盤を見直すマネージャーなどを想定しています。専門家でない方にも理解できるよう、専門用語は最小限にし具体例を交えて説明します。
本ドキュメントの使い方
各章は独立して読めますが、初めての方は第2章から順に読むと全体像がつかみやすいです。具体的な設計や運用の判断に使えるよう、実務で意識すべき点も取り上げます。
AWS Managed Microsoft ADとは
概要
AWS Managed Microsoft ADは、Amazon上で運用される「完全に管理された」Active Directoryサービスです。MicrosoftのActive Directoryと互換性があり、ドメイン参加やユーザー認証、グループポリシーなどをクラウドで利用できます。運用の多くをAWS側が自動で行うため、日々の管理負荷を減らせます。
仕組み（簡単に）
AWSはVPC内に高可用性を持つドメインコントローラーのペアを自動作成します。監視・障害復旧・データレプリケーション・スナップショット・ソフトウェア更新をAWSが管理します。ご自身はVPCやサブネット、セキュリティグループで接続を整えるだけで使い始められます。
利用シーン（具体例）
- Windowsサーバをドメイン参加してシングルサインオンにする。
- ADグループで社内アプリやファイルサーバのアクセス制御を行う。
- RDS for SQL Serverなど、AD認証が必要なAWSサービスと連携する。
利点と注意点
利点は運用負荷の軽減と高可用性、既存のADと互換性がある点です。注意点は、一部の管理権限が制限されるためスキーマ変更など高度な操作ができないこと、ネットワーク設計やコストを事前に検討する必要がある点です。必要に応じてオンプレADとの信頼関係を構築できます。
責任分界モデル（Shared Responsibility Model）
概要
AWS Managed Microsoft ADでは、AWSと利用者（顧客）が責任を分担します。AWSは基盤側の可用性やインフラ面を管理し、顧客はディレクトリ設定やアクセス制御などの論理的な運用を管理します。分担を理解すると運用やセキュリティ対策が明確になります。
AWSの責任（例）
- ディレクトリサービスのインフラ可用性の確保（複数AZでの冗長化など）
- ドメインコントローラーのOSやミドルウェアへのパッチ適用
- 物理的・ネットワーク的なインフラのセキュリティと監視
具体例：ハードウェア障害やゾーン障害時の自動フェイルオーバーはAWS側で対応します。
顧客の責任（例）
- パスワードポリシーやアカウントロックアウトなどの設定
- OUやグループポリシー、個別オブジェクトのアクセス制御（ACL）の運用
- ディレクトリの論理復元や誤操作からの復旧手順の準備
- オンプレADとの信頼関係の作成・管理
- LDAP over SSL（LDAPS）や多要素認証（MFA）の導入
具体例：重要な管理者アカウントはMFAを必ず有効にし、機密OUのアクセスを最小権限にしてください。
実践的な対策
- パスワードポリシーは最低要件を設け、定期的に見直す
- 重要データやスキーマ変更は事前にバックアップと復元手順を確認
- LDAPSやVPNで通信を暗号化し、管理トラフィックを限定する
- 監査ログを有効にして異常を早期検知する
責任の境界を明確にすると、運用の抜けや不一致を防げます。
エディションの種類と選択基準
エディション一覧
- Standard Edition
- Enterprise Edition
- Hybrid Edition
各エディションの特徴
- Standard Edition：中小規模向けです。AWS上でユーザーやデバイスを管理し、基本的な認証機能を提供します。たとえば社内システムをAWSに移行する小規模チームに適します。
- Enterprise Edition：大規模向けで冗長性やスケールを重視します。複数拠点や多くのユーザーを抱える組織で安定した運用を実現します。
- Hybrid Edition：既存のオンプレミスADを拡張してAWSと統合します。同一ドメイン名で運用したい場合や、既存のポリシーやグループをそのまま使いたい場合に便利です。
選択基準（具体例を交えて）
- 規模：ユーザー数や拠点数が多ければEnterpriseを検討します。少人数ならStandardで十分です。
- 統合ニーズ：オンプレと同一ドメイン名で運用したければHybridを選びます。
- 管理負担：AWSに管理させたい場合はStandard/Enterpriseでリソースフォレストを作り、既存ADとは信頼関係を結びます。既存ADを自分で管理したい場合はHybridが向きます。
- コストと可用性：冗長性や災害対策を重視するならEnterpriseを推奨します。
選ぶ際はまず利用シナリオと優先順位（コスト／可用性／管理方法）を明確にしてください。
主な機能と利用シーン
機能の要点
- ディレクトリ認識ワークロードの実行：Microsoft SharePoint、カスタムの.NETアプリ、SQL Serverベースのアプリなど、ドメイン参加やWindows認証を必要とするアプリをそのまま動かせます。
- ユーザー・グループ管理の自動化：2024年9月以降、AWS CLIやAPIでユーザー・グループのCRUD操作が可能になり、プロビジョニングや同期をスクリプトや自動化ツールで実装できます。
- 他サービスとの統合：Amazon RDS、WorkSpaces、IAM Identity Center、FSxなどと連携し、シングルサインオンやファイル共有、仮想デスクトップの認証を一元化できます。
具体的な利用シーン
- レガシーな社内アプリをクラウドへ移行する場合：既存の認証やグループ制御を変えずに移行できます。例として、社内の.NET業務アプリをドメイン参加させてそのまま稼働させるケースがあります。
- ファイルサーバのクラウド化：FSxと組み合わせて、従来のNTFSアクセス権を維持したまま共有フォルダを提供できます。
- 仮想デスクトップ環境：WorkSpacesと連携し、ユーザー認証やグループポリシーを統一できます。
- データベース認証の統合：Amazon RDS（SQL Server）などでドメイン認証を使う運用が可能です。
運用上のポイント
- 自動同期を導入してユーザー作成・削除のライフサイクルを整備してください。CLI/API対応によりHRシステムと連携しやすくなっています。
- ネットワーク設定やレプリケーション、バックアップを事前に確認し、アクセス権は最小権限で運用してください。
これらの機能を活用すると、既存のWindows認証基盤をほぼそのままクラウドへ移行し、運用の自動化と他AWSサービスとの統合が図れます。
セキュリティと信頼関係
概要
AWS Managed Microsoft AD（以下、Managed AD）とオンプレミスやセルフマネージドAD（以下、セルフAD）との間で信頼関係を構築すると、ユーザーとリソースの認証・アクセスが横断的に可能になります。例えば、オンプレのユーザーがManaged ADに参加したEC2にログオンできるようになります。
信頼関係の種類と動作
- 外向き（フォレスト/ドメイン）信頼：Managed ADがセルフADを信頼する一方向や双方向の信頼を設定できます。AWSサービスから外向きにアクセスするケースが多いです。
- レルム/フェデレーション：KerberosやSAMLを用いた連携も可能で、アプリケーション単位での認証に便利です。
設定の主な手順（概略）
- DNS解決と名前解決を準備（オンプレ側からManaged ADのDNSが参照できること）。
- ネットワーク接続を確立（VPNやDirect Connect、VPCピアリング）。
- 必要なポートを開放（AD用のTCP/UDPポートを限定的に許可）。
- AWSコンソールで信頼関係を作成し、双方で確認応答を行う。
セキュリティ上の配慮
- 最小権限：信頼したアカウントやグループにのみ権限を付与します。
- ネットワーク制御：セキュリティグループやACLでアクセス元を限定します。
- 暗号化とキー管理：必要な証明書や通信は暗号化し、鍵はAWS KMS等で管理します。
- ログと監査：CloudTrail、Amazon CloudWatch Logs、Windowsイベントログで認証・信頼の変更を監査します。
運用のポイント
- 定期的に信頼関係とDNS設定を確認します。
- パスワードポリシーや多要素認証（MFA）を併用してリスクを低減します。
- 信頼が不要になったら速やかに切断し、関連する権限を削除します。
これらを守ることで、ハイブリッド環境でも安全に認証とアクセス管理を行えます。
