AWS Active Directory導入ガイド：4つの選択肢とSSO・MFA・権限管理の実装パターン比較
このブログはこんな人向け
- AWS環境でActive Directory（AD）を導入・連携したい方
- AWSのADサービスの違いが分からず迷っている方
- オンプレADとAWSの連携や、運用負荷・コストの違いを知りたい方
この記事で得られること
- AWSで利用できるAD導入方式の全体像が分かる
- それぞれの方式のメリット・デメリット・ユースケースが分かる
- SSO、MFA、権限管理（IAMロール/Permission Set）を含めた選択基準が分かる
- 自社に合ったAD導入方法を選ぶための判断材料が得られる
前提知識
- AWSマネジメントコンソールの基本操作ができる
- Active Directoryの基本用語（ドメイン、OU、ユーザー、グループなど）を知っている
- IAM、Permission Set、Identity Center の概念を大まかに理解している
AWSでActive Directory（AD）を導入する際の選択肢比較
はじめに
AWS環境でActive Directory（AD）を導入する際、いくつかの選択肢があります。本記事では、それぞれの特徴やメリット・デメリット、そして重要な SSO、MFA、権限管理 の観点を含めて比較し、どのような場合にどの方式を選ぶべきかを解説します。
比較の軸
AD導入方式を評価する際、以下の観点で検討することが重要です：
| 観点 | 説明 |
|---|---|
| 運用負荷 | AWSの自動化に頼れるか、自前の保守が必要か |
| コスト | 月額費用や隠れコスト |
| 可用性 | SLA、フェイルオーバー、冗長性 |
| 拡張性 | AD機能の充実度（スキーマ、グループポリシーなど） |
| AWSサービス連携 | RDS、WorkSpaces等との統合容易性 |
| カスタマイズ性 | 特殊要件への対応可能性 |
| SSO / MFA | Identity Center、外部IdPとの連携による集約認証 |
| 権限管理 | Permission Set、IAMロール、グループベースの運用 |
選択肢一覧
- AWS Managed Microsoft AD（マネージドAD）
- Simple AD
- AD Connector
- EC2上にActive Directoryを構築
1. AWS Managed Microsoft AD（マネージドAD）
概要
AWSが提供するフルマネージドなMicrosoft Active Directoryサービス。高可用性や自動バックアップ、スケーラビリティが特徴。
メリット
- 運用管理が不要（パッチ適用やバックアップもAWSが実施）
- AWSサービス（RDS、WorkSpaces等）との連携が容易
- マルチAZ対応で高可用性
- Identity Centerのアイデンティティソースに直接対応 → ADグループをそのままPermission Setで管理
- Password Policy、信頼関係設定など、AD機能が充実
デメリット
- コストが比較的高め
- 一部のAD機能に制限あり（スキーマ拡張など）
- AWS外のリソースとの連携には工夫が必要
SSO / MFA / 権限管理
- SSO: Identity Centerを使い、Managed ADグループをユーザーソースとして活用。ユーザーがAWSコンソールにサインインする際、ブラウザでIdentity Centerのポータルを経由して認証。
-
MFA: IdP側（Entra ID等）でMFA必須化するか、IAMロール条件で
aws:MultiFactorAuthPresentを強制。 - 権限: Permission Setで標準化。グループベースの割り当てで、人事異動＝グループ変更で自動追随。
ユースケース
- AWS上でADを新規構築したい
- 運用負荷を最小化したい
- マルチアカウント環境で一元的なアクセス制御を実現したい
- Identity Centerでの集約認証を目指す
2. Simple AD
概要
AWSが提供する、Sambaベースのシンプルなディレクトリサービス。Microsoft ADの一部互換機能を持ち、コストを抑えて簡易的なディレクトリサービスを利用したい場合に適しています。
メリット
- コストが安い
- 運用管理が不要（マネージドサービス）
- 小規模環境やテスト用途に最適
デメリット
- Microsoft ADの全機能は利用不可（信頼関係や一部グループポリシーなど非対応）
- スケールや可用性に制限あり
- Identity Centerのアイデンティティソースとして非対応
- AWSサービスとの連携も一部制限
SSO / MFA / 権限管理
- SSO: Identity Center、外部IdPのアイデンティティソースとして直接利用できない。ユーザー直接ログイン（IAMユーザー+MFA）に頼ることになり、一元的なSSO構成が難しい。
- MFA: IAMユーザーのMFAで対応する必要があり、IDプロバイダ側の MFA と比べて運用効率が低い。
- 権限: IAMロールを直接ユーザーに付与する方式となり、Permission Setの利点を活かせない。
ユースケース
- 小規模な社内システムやテスト環境
- 本格的なAD機能が不要な場合
- コストを最優先したい場合
3. AD Connector
概要
オンプレミスのActive DirectoryとAWSサービスを連携するためのプロキシサービス。AD自体はオンプレミスに存在し、WorkSpaces等での認証に使う。
メリット
- オンプレADの認証情報をそのままAWSで利用可能
- AWS上にADを新規構築する必要なし
- コストが比較的安価
デメリット
- オンプレADの可用性・パフォーマンスに依存
- Identity Centerのアイデンティティソースとして非対応
- AWSコンソール（マネジメントコンソール）への一元的なSSO構成が困難
- WorkSpaces、RDS等での認証用途に限定的
SSO / MFA / 権限管理
- SSO: WorkSpaces やアプリケーション層での認証中継は可能だが、AWSコンソール全体を集約するIdentity Center的な機能は実現できない。外部IdPにより SAMLフェデレーション構成が必要。
- MFA: オンプレAD側でMFAを実装するか、SAMLフェデレーション経由で外部IdPのMFAを活用。
- 権限: オンプレADのグループをそのままAWSサービスで活用する形になり、Permission Setの集約管理には向かない。
ユースケース
- 既存のオンプレADを活用したい
- AWS移行の過渡期
- WorkSpaces等の特定AWSサービス認証を既存ADで実現したい
- ただしAWSコンソール集約SSO が必須の場合は、外部IdP化が別途必要
4. EC2上にActive Directoryを構築
概要
EC2インスタンス上にWindows Serverを立て、ADを自前で構築・運用する方式。
メリット
- フルコントロールが可能（スキーマ拡張や細かな設定も自由）
- AWS外のリソースとも柔軟に連携
- 既存のオンプレADとの信頼関係構築等が可能
デメリット
- 運用・保守の手間が大きい
- 可用性やバックアップも自分で設計・実装が必要
- 障害時の対応も自分で行う必要あり
- ライセンス（Windows Server 、CAL等）のコスト
SSO / MFA / 権限管理
- SSO: Identity Centerのアイデンティティソースとしては非対応。外部IdP化（AD FSやAzure AD Connectでの Entra ID ハイブリッド化）により、SAMLフェデレーション構成を実装。
- MFA: AD FS + Multi-Factor Authentication、または Entra ID ハイブリッド化で、IdP側MFAを活用。
- 権限: SAMLフェデレーション経由で AWSロール AssumeRole、または IAMロールのトラストポリシー設定で EC2上の AD を信頼。Permission Set の一元管理はできないため、IaC（CloudFormation等）で手動管理。
ユースケース
- 特殊なAD構成や高度なカスタマイズが必要
- 既存の運用ノウハウがある
- オンプレADとの複雑な連携が必須
- ただし通常はEntra ID等の外部IdP化を推奨
統合比較表
| 項目 | AWS Managed Microsoft AD | Simple AD | AD Connector | EC2上にAD構築 |
|---|---|---|---|---|
| 運用負荷 | 低 | 低 | 低 | 高 |
| コスト | 高 | 低 | 低 | 中〜高 |
| 可用性 | 高 | 中 | オンプレ依存 | 設計次第 |
| 拡張性 | 一部制限 | 低 | オンプレ依存 | 高 |
| AWSサービス連携 | ◎ | △ | ◯ | △ |
| カスタマイズ性 | △ | × | × | ◎ |
| Identity Center IDソース | ◯ | × | × | × |
| SSO（Identity Center） | ◯（直接対応） | × | × | × |
| SSO（外部IdP/SAML） | ◯（IdP連携可） | △（IdP次第） | △（IdP次第） | ◯（IdP化必要） |
| MFA（推奨実装） | IdP側MFA | IAMユーザーMFA | オンプレAD or IdP側MFA | AD FS or IdP側MFA |
| 権限管理（Permission Set） | ◯（グループベース） | × | × | × |
| グループ同期（SCIM） | ◯（内蔵） | × | × | △（IdP化で対応） |
シナリオ別おすすめ構成
1. 新規AWS環境・マルチアカウント・最小運用負荷を重視
推奨: AWS Managed Microsoft AD + Identity Center
- Managed ADでIDストアを構築
- Identity Centerで Permission Set を定義し、ADグループで割り当て
- MFA: IdP側（Entra ID等のハイブリッド化）で必須化
- 利点: 一元的な権限管理、グループ変更で自動追随、AWSサービス統合が最良
2. 既存オンプレADがあり、段階的にAWS移行
推奨: AD Connector（短期） → Entra ID ハイブリッド化 + SAML/Identity Center（中長期）
- 過渡期: AD Connector で WorkSpaces 等の認証を実現
- 同時進行: Entra ID を オンプレAD とハイブリッド化
- 最終形: SAMLフェデレーション、外部IdPとしてAWSコンソールもカバー
- グループ同期: SCIM で自動化
3. 小規模スタートアップ・とにかくコスト最小化
推奨: Identity Center（内蔵ストア）または Simple AD
- 小規模: Identity Center 内蔵でユーザー管理を簡潔に
- テスト環境: Simple AD で基本動作確認
- 注意: グループ同期や権限の一元化は限定的
4. 既存運用が複雑・特殊カスタマイズが必須
推奨: EC2上のAD（Entra ID ハイブリッド化後、SAML化を推奨）
- 特殊な AD 構成が必要な場合のみ
- ハイブリッド化により最終的には IdP 化
- 可用性・バックアップは自前で実装
決定フローチャート
1. AWS環境は新規 or 既存？
├─ 新規
│ └─ マルチアカウント計画あり？
│ ├─ YES → AWS Managed AD + Identity Center
│ └─ NO → Identity Center内蔵 or Simple AD
│
└─ 既存
└─ オンプレADあり？
├─ YES（小〜中規模）
│ └─ AWS移行スピード重視？
│ ├─ YES → AD Connector（短期）→ Entra ID Hybrid化（中期）
│ └─ NO → 最初からEntra ID Hybrid化 + SAML
│
├─ YES（複雑要件）
│ └─ EC2上AD → Entra ID Hybrid化 + SAML
│
└─ NO → AWS Managed AD新規構築 + Identity Center
まとめ
AWSでADを導入する際は、以下の優先順位で検討します：
- SSO・MFA・権限管理を一元化できるか → Identity Centerのアイデンティティソース対応が重要
- 既存リソースの活用可能性 → オンプレADがあれば、段階的にIdP化
- 運用負荷とコストのバランス → マネージドサービスを優先
- 特殊要件への対応 → 必要に応じてEC2上AD or 外部IdP
一般的な推奨:
- 新規 + マルチアカウント → AWS Managed AD + Identity Center
- 既存AD活用 + 段階的移行 → AD Connector → Entra ID Hybrid → SAML
- 小規模・テスト → Identity Center内蔵 or Simple AD
- 複雑カスタマイズ → EC2上AD + Entra ID Hybrid + SAML
各オプションの運用負荷を最小化し、グループベースの権限管理で人事異動への対応を自動化することが、中長期の成功につながります。