![[アップデート] AWS Managed Microsoft ADでマルチリージョンレプリケーションがサポートされました](https://devio2023-media.developers.io/wp-content/uploads/2019/05/aws-directory-service.png)
[アップデート] AWS Managed Microsoft ADでマルチリージョンレプリケーションがサポートされました
しばたです。
先日AWS Managed Microsoft ADで1つのディレクトリ環境を複数のリージョンに展開できる新機能が発表されました。
AWS公式の発表は以下となります。
本記事ではこの機能の解説と実際に試してみた結果について書いていきます。
AWS Managed Microsoft ADでのマルチリージョンレプリケーションの基本
この機能の技術的な詳細は以下のドキュメントにあります。
先述のアナウンスとこちらのドキュメントの内容をベースに基本的なところを解説します。
仕組みについて
この機能の仕組み自体はかなりシンプルで、最初に構築したディレクトリ環境をPrimary Regionとし、追加のリージョンにドメインコントローラーを追加する形となります。
追加したリージョンのディレクトリ環境はリージョン名と同一のサイトに配備されPrimary Regionとサイト間レプリケーションにより設定を同期させます。
(内部的な実装まではわかりませんが、設定上はActive Directoryの通常のサイト間レプリケーションをしてるだけの様に見受けられます)
各リージョンのディレクトリ環境は同一のディレクトリIDを持ち、管理上は各リージョンに同一IDのディレクトリが存在する形となります。
Global Features と Regional Features
この機能の追加により複数リージョンで単一のディレクトリを管理することができる様になったため、全リージョンに影響するディレクトリ全体に関わる機能をGlobal Features、リージョン毎個別の機能をRegional Featuresとドキュメント上では呼称しています。
現時点では、
- 信頼関係の構築
- スキーマ拡張
- スナップショット(バックアップ)の作成
がGlobal Featuresとなっている様で、これらの機能はPrimary Regionからのみ設定可能となっています。
追加したリージョンからは設定の参照のみ可能となっています。
上記以外の機能はRegional Featuresとなり各リージョン毎で設定します。
例えばWorkSpacesなどの各サービスとの紐づけは従来通りリージョン毎となります。
(各サービス自体がリージョン毎で分離されてるので当然と言えば当然ですね)
ちょっと間違えそうなのがディレクトリのアカウント間共有でこれもリージョン毎の設定です。
前提条件
AWS Managed Microsoft ADでマルチリージョン環境を構成するための前提条件は以下となります。
条件1. 対象リージョンなど
2020年11月25日時点でこの機能は以下のリージョンで利用可能です。
- 米国東部 (バージニア北部)
- 米国東部 (オハイオ)
- 米国西部 (北カリフォルニア)
- 米国西部 (オレゴン)
- AWS GovCloud (米国東部)
- 米国西部 (オレゴン)
- アジアパシフィック (ムンバイ)
- アジアパシフィック (ソウル)
- アジアパシフィック (シンガポール)
- アジアパシフィック (シドニー)
- アジアパシフィック (東京)
- カナダ (中部)
- 欧州 (フランクフルト)
- 欧州 (アイルランド)
- 欧州 (ロンドン)
- 欧州 (パリ)
- 欧州 (ストックホルム)
- 南米 (サンパウロ)
東京リージョンでも既に使えますし、利用可能なリージョンは順次増えていくことでしょう。
また、実際に試せてはいませんが既存のディレクトリでも利用可能とのことです。
条件2. エディション
AWS Managed Microsoft ADはその規模に応じてStandard Edition、Enterprise Editionの2エディションありますが、マルチリージョンレプリケーションはEnterprise Editionのみで提供されます。
気軽に試しにくいのは残念ですが用途からすると妥当だとは思います。
条件3. 同一AWSアカウントであること
マルチリージョンレプリケーションは同一アカウント内にあるリージョンが対象となります。
複数アカウントにまたがる構成の場合はディレクトリのアカウント間共有との併用が必要です。
条件4. 各リージョンごとでVPC CIDRが重複しないこと
こちらはドキュメントに記載されていなかったのですが、ディレクトリを配備する各リージョン(VPC)でVPC CIDRは重複してはいけません。
リージョンを追加する際にCIDRの重複が検知されると、
The directory d-xxxxxxxxxx could not be replicated to region us-east-1 due to a overlapping VPC CIDR.
といった旨のエラーメッセージが表示され追加に失敗します。
この仕様はAcitve Directoryの仕組みを考えると妥当かつ仕方ないと思いますが、ネットワーク設計は事前に検討しておく必要があり、既存のディレクトリ環境にカジュアルにリージョンを増やせるわけではないのでご注意ください。
条件5. VPC Peeringは不要
こちらは前提条件というより前項に対する補足になるのですが、マルチリージョンレプリケーションを行うにあたりVPC Peeringの設定は不要です。
各リージョンはAWS内部の管理ネットワークを介して接続されレプリケーションもその管理ネットワークを介して行われている様です。
実質的にVPC Peeringを必要とするディレクトリのアカウント間共有とは異なる仕様となります。
試してみた
ちょっと前置きが長くなりましたが、ここから実際に試していきます。
検証環境
検証環境は下図の通りです。
東京リージョンに10.0.0.0/16のVPCを作成しその中のPrivate Subnetに最初にディレクトリ環境を構築します。
このディレクトリをバージニア北部にある10.10.0.0/16のVPC内のサブネットに追加していきます。
東京リージョンにBastionとなるWindows Serverを立てディレクトリ内部の設定を確認していきます。
本記事では各VPC、サブネットを構築する手順およびBastionの構築手順は割愛します。
1. Primary Regionでのディレクトリ作成
はじめに東京リージョン(Primary Region)でディレクトリを作成します。
作り方は通常の場合と何ら変わりないためここは軽くスクリーンショットを列挙する程度に留めておきます。
大事なのはエディションを「Enterprise Edition」にしてください。
今回はcorp.shibata.techというドメインを作っています。
(Enterprise Editionを選びます。ドメイン名等は環境に応じて)
(配置サブネットは環境に応じた設定に)
しばらく待つとディレクトリが作成されます。
新たに「マルチリージョン」という列が増えています。
2. Additional Regionでのディレクトリ追加
続けてこのディレクトリに新しいリージョンを増やします。
ディレクトリの詳細画面に「マルチリージョンレプリケーション」欄が増えていますので、この欄にある「リージョンを追加」ボタンをクリックします。
すると下図の画面に遷移しますので、ディレクトリを追加したいリージョンを選び、さらにVPC、サブネットの配備情報を設定します。
あとは「追加」ボタンをクリックすると対象リージョンにディレクトリを追加します。
ディレクトリの追加にはかなり時間がかかるので完了まで待ちます。
(アナウンスでは最大45分とのことでしたが体感1時間くらいかかった気がする...)
ステータスが「アクティブ」になれば追加完了です。
Primary Regionは「Asia Paciffic (Tokyo) - プライマリ」の様に名前に「プライマリ」が付きかならず1行目に表示されます。
2行目以降が追加したリージョンになります。
リージョン名の部分をクリックするとそのリージョンのコンソールに移動します。
(ちょっとわかりにくいですが上図はバージニア北部に切り替わっています。併せてディレクトリIDが同一のままであることも見て取れます)
これでディレクトリ追加は完了です。
あとは環境に応じた設定を行ってください。
ちなみに、先述のGlobal Featuresに関して、例えば信頼関係の構築だと下図の様にPrimary Regionだと変更可能、追加されたリージョンだと変更不可となります。
(東京リージョンだと信頼関係を追加可能)
(バージニア北部だと参照のみ可能)
3. Active Directoryの設定の確認
ここからはBastionからActive Directoryの設定周りを確認してみます。
ドメインコントローラー
ドメインコントローラーは下図の様にリージョン毎に2台ずつ計4台あります。
こちらは最小構成なので必要に応じてリージョン毎のドメインコントローラーの数を増やすことも可能です。
サイト設定
サイト設定はこんな感じです。
Primary RegionではデフォルトのサイトFefault-First-Site-Nameが使われ、追加したリージョンではリージョン名と同一のus-east-1サイトが使われます。
AWS Managed Microsoft ADのFefault-First-Site-Nameサイトは初期設定で10.0.0.0/8、172.16.0.0/12、192.168.0.0/16のCIDRが対象となっており[1]、追加されたus-east-1サイトはVPC CIDRの10.10.0.0/16とAWS内部ネットワークと思しき198.18.0.0/23が対象となっています。
こちらは初期設定ですので実際のネットワーク構成に合わせて変更可能です。
(例えばVPC Peering経由でAWS Managed Microsoft ADを使う場合、Peering先のCIDRを登録しないといけないです)
サイト間レプリケーションの間隔はデフォルト設定の3時間となっており、スケジュールの変更はできませんでした。
FSMO
当然といえば当然ですが、FSMOはPrimary Regionにありユーザーによる移動はできません。
一応試してみましたがFSMOを移動しようとするとアクセス権エラーとなりました。
ユーザー情報
具体的な用途はわかりませんが、追加リージョンに対する管理用のランダム名ユーザーが増えていました。
こちらはAWS ReservedなOUにいるので利用者がどうこうできるものではありませんが気になったので記載しておきます。
最後に
以上となります。
従来AWS Managed Microsoft ADを複数リージョンで運用する際はリージョン毎にディレクトリを作成し信頼関係を結ぶ必要がありました。
信頼関係による構成はお世辞にもシンプルとはいえず、今回のマルチリージョンレプリケーションは大規模なディレクトリを運用している方にとっては待望の機能だったのではないかと思います。
ネットワーク設計は事前に考えておかないといけませんが、追加の作業自体は一瞬であり、本来非常にめんどうくさい作業であるAcitve Directory環境構築が瞬時にできてしまうのは本当にすごいと思います。
大規模環境向けの機能ですので使う機会は少ないかもしれませんが、もしその機会が訪れた際はぜひ検討してみてください。
これは従来からの仕様です ↩︎
