![[re:Invent2019] [レポート] WIN312 – Windows ワークロードをサポートするための Active Directory on AWS のパターン解説 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2019/12/reinvent2019_report_eyecatch.jpg)
[re:Invent2019] [レポート] WIN312 – Windows ワークロードをサポートするための Active Directory on AWS のパターン解説 #reinvent
しばたです。
本当は去年末に書くつもりだったのが体調不良によりしばらくお蔵入りしてしまったためちょっと遅めのレポートです。
他の社員のレポート
このセッションは複数回に分けて開催されており、私が受ける前の日にまさをが先に受けておりレポート記事もすでに公開済みだったりします。
基本的な内容についてはこちらの記事をご覧頂ければと思います。
私はセッション後半で紹介される各パターンについて考察と私見を述べる形で本記事を書いていきたいと思います。
(楽しげなパターンが多く公開されており、先にレポート記事を書かれようが私もブログでいっちょかみしたくなったのです...)
セッション概要
Want to learn your options for running Microsoft Active Directory on AWS? When moving Microsoft workloads to AWS, it's important to consider how to deploy Microsoft Active Directory to support group policy management, authentication, and authorization. In this session, we discuss options for deploying Microsoft Active Directory to AWS, including AWS Directory Service for Microsoft Active Directory and deploying Active Directory to Windows on Amazon Elastic Compute Cloud (Amazon EC2). We cover such topics as integrating your on-premises Microsoft Active Directory environment to the cloud and leveraging SaaS applications, such as Office 365, with AWS Single Sign-On.
- Peter Pereira - Senior Product Manager, Amazon Web Services
- Vinod Madabushi - Principal Solutions Architect, Amazon Web Services
配信動画
1. Active Directory 基本的な展開パターン
1-1. EC2で既存ドメイン環境を拡張する
最初はオンプレ環境とAWS環境をVPNやDirect Connectでプライベート接続し、EC2のドメインコントローラーを追加するパターンです。
AWS側の耐障害性を高めるためにマルチAZ構成にします。
こちらは単純にEC2を追加のドメインコントローラーとして登録する
複数リージョンにまたがる場合も同様の手順で拡張でき、レイテンシーの観点からリージョンごとにドメインコントローラーを立てるのが推奨されるとの事でした。
1-2. Microsoft ADをリソースドメインとして展開する
次はAWS側にAWS Managed Microsoft AD(以後Microsoft AD)を立てオンプレ環境にあるドメインと(原則片方向の)信頼関係を結ぶパターンです。
信頼関係を基にMicrosoft ADからオンプレ側ドメインのユーザー情報などを使用する形となります。
オンプレ側ドメインに所属しないためMicrosoft ADは別ドメイン(下図では na. company.local ドメインとしている)です。
複数リージョンにまたがる場合はリージョン毎にMicrosoft AD環境を用意します。
(リージョン毎にドメイン名も分かれます。下図では eu. company.local が追加されています)
ちなみに、ここでは「リソースドメイン」をコンピューターオブジェクトとサービスオブジェクトのみを保持するドメインとして定義しています。
フォレスト設計におけるリソースフォレストとは意味合いが異なるで注意してください。
1-3. Microsoft ADをスタンドアロンで展開する
最後はMicrosoft ADを単体で用意するパターンです。
オンプレ環境にドメインが無い場合やオンプレ環境との連動が不要な場合に適用します。
複数リージョンにまたがる場合はリージョン毎にMicrosoft AD環境を用意し、inter region VPC peeringを使いVPC同士を接続、各ドメインで信頼関係を結ぶ様にします。
2. Active Directory design
ここからはマルチアカウント環境におけるActive Directory設計になります。
AWS Organaization配下でActive Directory専用のアカウントを設ける前提に立っています。
2-1. EC2で既存ドメイン環境を拡張する
1-1.の構成でAWS上にドメイン環境(専用アカウント)を用意し、別アカウント(下図ではApplication Account)からはAD Connectorを通じてドメイン参加する設計です。
VPC同士はTransig GatewayやVPC Peeringを使って接続します。
そしてこれが複数リージョンの場合は下図の様になります。
1-1.で説明したとおりレイテンシーの観点からリージョンごとにドメインコントローラーを立てるのが推奨されるのでこの様になります。
図は複雑ですがActive Directory構成の複雑さは専用アカウント内に閉じますので運用としてはそこまで複雑にならないと思われます。
2-2. Microsoft ADをリソースドメインとして展開する
次はAWS側にAWS Managed Microsoft AD(以後Microsoft AD)を立てオンプレ環境にあるドメインと(原則片方向の)信頼関係を結ぶパターンのマルチアカウント版です。
AWS側はマネージドなMicrosoft ADなため別アカウント(下図ではApplication Account)側はVPC同士が接続されていればOKで、シームレスなドメイン参加が必要な場合にアカウント共有を行う設計となります。
そして複数リージョンにまたがる場合は下図の様になります。
パッと見複雑に見えますが1-2.の構成と何ら変わらないことが分かるかと思います。
3. AWSサービスとの連携
ここからはセッション後半で説明されたRDS、FSx for Windowsといった各AWSサービスとの連携パターンについて解説します。
3-1. Microsoft AD と RDS、FSx for Windows
RDSやFSx for WindowsといったAWSサービスがドメイン連携するにはAWS基盤として認識されている必要がある(要はAWSのディレクトリIDが必要)のでRDSやFSx for Windowsを利用するアカウントに対しディレクトリを共有してやる必要があります。
3-2. AD on EC2 と RDS、FSx for Windows
次にAWS側がEC2を追加のドメインコントローラーにした場合です。
こちらはActive DirectoryにAWSのディレクトリIDが紐づいていないので、オンプレドメインに直接参加できるFSx for Windowsは問題ないのですが、RDSはこのドメインに参加できません。
RDSについてはAD Connectorを使えばディレクトリIDの紐づけができるのでこのドメインに参加できるはずですが、セッション中では触れられませんでした。
(訂正) RDS for SQL ServerはAD Connector非サポートでした。
3-3. AWS SSO統合アプリケーション と Microsoft AD
AWS SSOのIdPとしてMicrosoft ADを使用するパターンです。
AWS SSOではMicrosoft ADとオンプレ側ドメインで双方向の信頼関係が必須である点が注意事項として挙げられていました。
3-4. AWS SSO統合アプリケーション と AD on EC2
AWS SSOのIdPとしてEC2に展開したドメインコントローラーを使うパターンです。
AWS SSOがドメインを認識するためにAD Connectorが必要です。
AD Connectorは単一のドメインしかサポートしない点が制約となります。
3-5. AWS統合アプリケーション と Microsoft AD
WorkSpacesやAppStream 2.0といったAWS統合アプリケーションでMicrosoft ADを使う場合のパターンです。
WorkSpacesはVPCに展開する必要があるためネットワーク接続とAD Connectorが必要になりますが、それ以外のアプリケーションはVPCに依存しません。
(と、説明されたが少し怪しいです。たとえばAppStream 2.0はドメインに直接接続する形式なので明示されていないもののVPC依存な気がします)
3-6. AWS統合アプリケーション と AD on EC2
最後にAWS統合アプリケーションがEC2に展開したドメインコントローラーを使うパターンです。
セッションの最後でこちらの内容については前項とほぼ同様としか説明されなかったのですが、WorkSpaces以外のアプリケーションでもAD Connectorが必要になるはずです。
最後に
以上となります。
マルチリージョン、マルチアカウントにおけるActive Directory設計の知見が多くあり非常に参考になるセッションでした。
ただ一点だけ気になる点があり、このセッションではサイト設計については一切触れられませんでしたが、これはドキュメントにも記載されている(「リージョンに対して1つのActive Directoryサイト」)のでこの程度は話すまでもないという事だったんだと思います。
