[アップデート] AWS Managed Microsoft ADにHybrid Editionが登場しました

しばたです。

今月頭にAWS Managed Microsoft ADの新エディションとなるHybrid Editionが登場しました。
AWSからはWhat's newとブログでアナウンスされています。

https://aws.amazon.com/about-aws/whats-new/2025/08/aws-directory-service-aws-microsoft-ad-hybrid-edition/

https://aws.amazon.com/blogs/modernizing-with-aws/extend-your-active-directory-domain-to-aws-with-aws-managed-microsoft-ad-hybrid-edition/

基本的にはAWSブログを見ていただければどの様なものかは伝わるのですが、実際に試したところ「かなり使いどころが難しい。」と感じたのでそのあたりを踏まえて本記事で共有したいと思います。

AWS Managed Microsoft AD Hybrid Edition とは？

今回新たに登場したHybrid Editionはその名の通り(主に)オンプレ環境とのハイブリッドとなり、既存のActive DirectoryドメインをAWS Managed Microsoft ADに延伸する形を採るエディションとなります。

前掲のブログより引用 : オンプレ環境にあるドメインを延伸する場合の構成図

従来のAWS Managed Microsoft AD (Standard/Enterpriseエディション)はAWSマネージドで独立したシングルフォレスト・シングルドメイン環境を提供するもので、既存のドメイン環境とは信頼関係を構築することで連携できましたが、今回登場したHybrid Editionでは既存ドメインの追加ドメインコントローラーとしてAWS Managed Microsoft ADを構成できる様になります。
これにより信頼関係の構築なしに既存ドメインをそのままAWSサービスから利用可能になります。

もちろん無条件で既存ドメイン環境を使えるわけではなく、事前に アセスメント を行いAWS Managed Microsoft ADでの使用に適切な環境であるかのチェックが行われます。
このアセスメントは一度きりではなく環境構築後定期的に実施されます。

これだけ聞くと理想のAWS Managed Microsoft AD環境の様に見えますが、実際には多くの制約がありユースケースも限定的です。

ユースケース

AWSの想定するユースケースとしては

• 既存ドメインをAWSに延伸
• 既存ドメインに依存するワークロードをそのままAWSで利用可能にする

となり、現時点ではあくまで 延伸 するだけであり「既存環境を捨てAWS Managed Microsoft ADだけに切り替える」ことはできません。

また、既存ドメインとAWS Managed Microsoft AD両方に対し定期的にアセスメントが実行される都合、マネージドサービスを使うと言っても必ずしも運用が簡素化されるわけでもありません。
EC2ですべてのドメインコントローラーを運用するよりは楽かもしれませんが、従来のAWS Managed Microsoft ADの様に「インフラ面はすべてAWSにお任せ」とはならないので注意が必要です。

運用のイメージとしてはAmazon RDS Customに近いと考えていただくのが良いでしょう。
以前の記事で

このためRDS Customを採用する場合は「丸投げではなくAWSと共にRDSを運用する覚悟」が必要となります。
ただカジュアルに「RDSをお気楽にカスタマイズできるものではない」ので決して誤解しないようにしてください。
覚悟を代償により柔軟な構成を得ることができる、という類のものです。

といったことを書きましたが、AWS Managed Microsoft AD Hybrid Editionも同じです。

スペックと料金

AWS Managed Microsoft AD Hybrid Editionのスペックと利用料金は公式ページでご確認ください。

• AWS Directory Service Pricing
  • 本日時点では英語版ページのみ更新済み

本日時点の内容を転記すると以下の通りです。

ざっくり言うと、スペックはEnterprise Editionと同等で料金はEnterprise Editionの1.7倍です。

この点からも気軽に使うものではなく特定の大規模環境向けのものであることがわかります。

前提条件

Hybrid Editionを利用するには既存のドメイン環境が次の前提条件を満たす必要があります。

• オンプレ環境またはEC2で2台のドメインコントローラーが必要 (1台だけではダメ)
• ドメインコントローラー2台ともSSMのマネージドノードであること
• ドメインコントローラーがRead-only(RODC)でないこと
• ドメインの機能レベルはWindows Server 2012 R2かWindows Server 2016であること
• Primary Domain Controller(PDC)に対して常に通信可能であること
  • そのうちPDCエミュレーターとRIDマスターは以下の条件を満たすこと
    • RFC1918のIPアドレス帯に存在すること
    • (EC2環境の場合) VPC CIDR内に存在すること
    • DNSサーバーのいずれかのIPと一致すること

アセスメントをSSM Run Commandで行う都合既存のドメインコントローラーはSSMのマネージドノードでなければなりません。
オンプレ環境のドメインコントローラーであってもマネージドノードにする必要があります。

また、サポートされる機能レベルがWindows Server 2012 R2かWindows Server 2016だけでありこれより古くても新しくてもダメなのでご注意ください。

• 参考 : Hybrid directory prerequisites

この他にもアセスメントでより細かい制約が課せられます。
こちらの詳細は別の記事で紹介したいと思いますが、一例を挙げると、

• SMBv1を無効にしていること
• ディスクに一定量の空きがあること
• Domain Adminsなどの管理者グループに5名以上のユーザーがいないこと (管理者が多すぎるとダメ)

といった点も別途チェックされます。

ドメインコントローラー内で動作する必要のあるサービス

前提条件の一つとしてドメインコントローラーでは以下のサービスが起動している必要があります。

• Active Directory Domain Services
• Active Directory Web Service (ADWS)
• COM+ Event System
• Distributed File System Replication (DFSR)
• Domain Name System (DNS)
• DNS Server
• Group Policy Client
• Intersite Messaging
• Remote Procedure Call (RPC)
• Security Accounts Manager
• Windows Time Server

こちらは一般的なドメインコントローラーであれば動作しているはずなのであまり気にしないで良いでしょう。

ドメインコントローラーに対する疎通要件

既存ドメインコントローラーに対して次の通信が許可されている必要があります。

• TCP/UDP 53 - DNS
• TCP/UDP 88 - Kerberos authentication
• UDP 123 - Time server
• TCP 135 - Remote Procedure Call
• TCP/UDP 389 - LDAP
• TCP 445 - SMB
• TCP 636 - Only needed for environments with Lightweight Directory Access Protocol Secure (LDAPS)
• TCP 49152-65535 - RPC randomly allocated high TCP ports
• TCP 3268 and 3269 - Global Catalog
• TCP 9389 Active Directory Web Services (ADWS)

こちらも一般的なドメインコントローラーであれば空いているポートかと思います。

事前準備

Hybrid Editionの環境を作る際は事前に以下の情報が必要です。

• ドメインのDNS名 (FQDN)
• ドメインのDNSサーバーのIPアドレス (2つ必要)
• ドメイン管理者の認証情報
  • この認証情報をSecrets Managerに登録します

このうちドメイン管理者の認証情報についてはSecrets Managerのシークレットを別途用意して保存する必要があります。

ドメイン管理者に求めれられる権限についてはドキュメントに記載が無かったのですが、新規にドメインコントローラーを追加しAWS関連の専用OUやオブジェクトを作成する作業が発生するので最低でもDomain Adminsが必要だと推測されます。

試してみた

ここからは実際にAWS Managed Microsoft AD Hybrid Editionの環境を構築して動作確認していきます。

0. 検証環境

今回は私の検証用AWSアカウントの東京リージョンにVPC一式と 英語版 Windows Server 2022 EC2二台を用意し、Active Directory環境(corp.contoso.comドメイン、機能レベルWindows Server 2016)を用意しておきます。

EC2にはAmazonSSMManagedInstanceCoreポリシーをアタッチしSSMマネージドノードとして利用可能にしています。
SSMを使うのでVPCからインターネットアクセス可能にしています。

具体的な構築手順は割愛しますが、GistにCloudFormationテンプレートとPowerShellスクリプトを残しておくので参考にしてください。。

• AWS Managed Microsoft AD Hybrid Editionの検証環境を作るためのスクリプト

この環境にAWS Managed Microsoft ADを構築して最終的に下図の構成とします。

初期Active Direcotry環境の確認

初期状態のActive Directoryの状態を確認しておくと次の通りです。

• 参考 :
  • Active Directory ドメイン サービスでドメインとフォレストの機能レベルを上げる
  • Flexible Single Master Operation (FSMO) ロールを移譲する

# フォレスト機能レベル
PS C:\> Get-ADForest -Identity 'corp.contoso.com' | Select-Object ForestMode

       ForestMode
       ----------
Windows2016Forest

# ドメイン機能レベル
PS C:\> Get-ADForest | Select-Object -ExpandProperty Domains | ForEach-Object { Get-ADDomain $_ } | Select-Object Name, DomainMode

Name        DomainMode
----        ----------
corp Windows2016Domain

# Readonly、FSMO
PS C:\> $domainControllers = Get-ADDomainController -Filter *
>> foreach ($dc in $domainControllers) {
>>     Write-Output "Name: $($dc.Name)"
>>     Write-Output "IsReadOnly: $($dc.IsReadOnly)"
>>     Write-Output "OperationMasterRoles:"
>>     foreach ($role in $dc.OperationMasterRoles) {
>>         Write-Output "- $role"
>>     }
>> }
Name: ADDS01
IsReadOnly: False
OperationMasterRoles:
- SchemaMaster
- DomainNamingMaster
- PDCEmulator
- RIDMaster
- InfrastructureMaster
Name: ADDS02
IsReadOnly: False
OperationMasterRoles:

機能レベルがWindows Server 2016でFSMOの各種役割はすべてadds01にある状態です。

1. 事前準備 (AWS Secrets Managerシークレットの作成)

最初に事前準備としてドメイン管理者の認証情報を記録したSecrets Managerシークレットを用意します。

• 参考 : Hybrid directory prerequisites

非常に強い権限を持つ認証情報を保存するためなのか、このシークレットはAWSが用意するデフォルトのKMSキーではなく利用者が独自に用意したKMSキーで暗号化する必要があります。

KMSキーの要件としては、

• 対称キー
• 使用法は「暗号化および復号化」
• シングルリージョンキー

となり、キーポリシーを次の様にds.amazonaws.comサービスと必要最低限のロールだけに操作を許可する様にしてやります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<caller-account>:role/<role_used_to_create_directory>"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    { 
       "Sid": "Allow use of the KMS key on behalf of Directory Service", 
       "Effect": "Allow", 
       "Principal": {
         "Service": "ds.amazonaws.com"
       }, 
       "Action": "kms:Decrypt", 
       "Resource": "*"
    }
  ]
}

KMSキーが出来上がったらSecrets Managerシークレットを以下の様に作成します。

• シークレットタイプ : その他
• キーと値
  • customerAdAdminDomainUsernameキーに管理者ユーザー名を記載 (例: administrator)
    • ドメイン名の記載は不要
  • customerAdAdminDomainPasswordキーに管理者ユーザーのパスワードを記載
• 暗号化キー : 前の手順で作成したKMSキー

今回はCloudShellから次のコマンドを実行してKMSキーとシークレットを作成しました。
シークレットには一番権限の強いadministratorの情報を記載しています。

• KMSキー : my-aws-managed-microsft-ad-hybrid
• シークレット : my-aws-managed-microsoft-ad-hybrid-admin

# KMSキー作成 : my-aws-managed-microsft-ad-hybrid 
kms_key_id=$(aws kms create-key --description 'Key for AWS Managed Microsoft AD Hybrid Edition' \
    --key-usage 'ENCRYPT_DECRYPT' \
    --origin 'AWS_KMS' \
    --no-multi-region \
    --query 'KeyMetadata.KeyId' \
    --output text)
echo $kms_key_id 
# エイリアスの割り当て
aws kms create-alias --alias-name 'alias/my-aws-managed-microsft-ad-hybrid' \
    --target-key-id $kms_key_id

# 権限の追加 : 環境に応じて要カスタマイズ
key_policy=$(cat << EOF
{
  "Version": "2012-10-17",
  "Id": "key-default-1",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::$(aws sts get-caller-identity --query 'Account' --output text):root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    { 
       "Sid": "Allow use of the KMS key on behalf of Directory Service", 
       "Effect": "Allow", 
       "Principal": {
         "Service": "ds.amazonaws.com"
       }, 
       "Action": "kms:Decrypt", 
       "Resource": "*"
    }
  ]
}
EOF
)
aws kms put-key-policy --key-id $kms_key_id --policy "$key_policy"

# AWS Managed Microsoft AD用のシークレットを作成
aws secretsmanager create-secret \
    --name "my-aws-managed-microsoft-ad-hybrid-admin" \
    --description "Secrets for AWS Managed Microsoft AD Hybrid Edition administrative user." \
    --secret-string "{\"customerAdAdminDomainUsername\":\"administrator\",\"customerAdAdminDomainPassword\":\"P@ssword\"}" \
    --kms-key-id $kms_key_id

作成した結果が次の様になっていればOKです。

作成されたKMSキー

KMSキーポリシーに ds.amazonaws.com サービスにに対する操作権限がある

シークレットはこんな感じ。

Secrets Managerシークレット

暗号化キーの指定と登録されているキーが正しいこと

2. アセスメントの作成

ここからAWS Managed Microsoft AD環境を作るのですが、最初にアセスメントを作成し、アセスメントに合格したらディレクトリを作る二段階の作業となります。
マネジメントコンソールのDirectory Serivceを開き、「ディレクトリのセットアップ」をクリックします。

ディレクトリタイプを「AWS Managed Microsoft AD」にすると新たに「既存のADドメインをハイブリッドディレクトリで拡張」という選択肢が増えているのでこれを選択します。

Hybrid Editionの料金や概要が表示されるのでそのまま「次へ」をクリックします。

一部日本語訳が狂っていますがそのうち修正されるでしょう...

次にアセスメントのために既存のドメイン情報を記入します。
既存ドメインのFQDN(corp.contoso.com)とDNSサーバーのIPアドレス2つを設定します。

画面中段ではAWS Managed Microsoft ADを作るVPCとサブネット2つを選びます。
ここは従来のAWS Managed Microsoft ADと同じです。
最後にオプションでセキュリティグループの指定欄がありますが、未指定の場合はAWSが一時的に疎通確認に必要なセキュリティグループをマネージドノードに割り当てるので今回はそのままにしておきます。

画面下部にはアセスメント対象となるSSMマネージドノード(=ドメインコントローラー)を2台選択します。
ここにインスタンスがリストアップされない場合はSSMの設定が誤っている可能性が高いので適宜見直してください。

「次へ」をクリックすると最終確認になり、「評価を作成」ボタンをクリックするとアセスメントが開始されます。

アセスメントには20～30分かかるとされているので完了するまで待ちます。
今回は約35分かかかりました。

アセスメントの詳細画面はこんな感じです。

アセスメントでのテストは全部で43項目あり初回作成時(既存環境に対するチェック)はそのうち38項目実施されました。
最終的にすべてのテストに合格すると完了です。

各テストの結果は画面下部のマネージドノードを選択すると確認できます。

3. ディレクトリの作成

アセスメントに合格した状態で「ハイブリッドディレクトリを作成」ボタンをクリックするとAWS Managed Microsoft ADディレクトリの作成に移ります。

ここで事前準備で作成したSecrets Managerシークレットを指定します。

それ以外の情報はアセスメント結果から取得されるのでそのまま「ハイブリッドディレクトリを作成」ボタンをクリックすればOKです。

これでディレクトリの作成が開始され20～45分程度かかります。

ただ、今回は私の画面操作が悪かったのかディレクトリの作成に合わせてもう一度新規にアセスメントが実行され、

• 2回目のアセスメント 35分
• ディレクトリの作成 20～45分

だけ時間がかかってしまいました。
あとは通常のAWS Managed Microsoft AD同様完成を待つだけです。

最終的にディレクトリの作成が完了するとこんな感じになります。

エディションが「Hybrid」となり、ドメインは既存のcorp.contoso.comとなります。
同名の別ディレクトリではなく既存のcorp.contoso.comそのものです。

作業としてはこれで完了です。

4. 作成したディレクトリの確認

Hybrid Editionでは詳細画面下部のタブの構成が他のエディションと大きく異なる形になっているので一つずつ確認していきます。

4-1. セルフマネージドAD

セルフマネージドADタブにはアセスメントで使用したマネージドノードの情報とアセスメント結果を確認できます。

アセスメントは1時間に1回程度の頻度で実施され都度評価が更新されます。

4-2. ネットワークとセキュリティ

ネットワークとセキュリティタブにはAWS Managed Microsft AD側の基本情報が表示されます。

Hybrid Editionでは既存のドメイン環境を延伸し、ドメイン環境に対する完全な管理者権限を利用者が持っているためAWSマネジメントコンソールには必要最低限の項目しか表示されない形になっています。

4-3. スケールと共有

スケールと共有タブではディレクトリの共有とドメインコントローラーの追加が可能です。

これらの機能はHybrid Editonでも利用可能です。
最初に紹介したAWSブログにディレクトリの共有を使いクロスアカウント環境を構築する構成も載っているので改めてご確認いただくと良いでしょう。

4-4. アプリケーション管理

アプリケーション管理タブではHybrid Editionで利用可能なアプリケーションの一覧が記載されています。

見た瞬間にわかると思いますが、現状他のエディションと比べて対応アプリケーションが少ないです。
現状FSxとRDSだけ対応している形となります。

他エディションとの比較表を用意すると以下になります。
よく使うであろうAmazon WorkSpacesやAWS Client VPNはHybrid Edition非対応なので気をつけてください。

4-5. メンテナンス

メンテナスタブにはモニタリング設定のみ存在します。

他のエディションにあるスナップショット(バックアップ)に関連する機能がHybrid Editionにはありません。
既存ドメインの延伸ということでバックアップは利用者の責務になる様なのでこちらも注意が必要です。

4-6. 他のエディションにある機能

他のエディションではマネジメントコンソールからユーザーとグループの管理ができましたが、Hybrid Editionでは利用不可となっています。
グループやユーザーの管理は既存環境と同様の方法で行う必要があります。

# Hybrid Editionでユーザー管理を有効にしようとするとサポート外エラーになる
~ $ aws ds describe-directory-data-access --directory-id d-9567bfca5f

An error occurred (UnsupportedOperationException) when calling the DescribeDirectoryDataAccess operation: Directory Service Data feature is not supported for this directory type. 

ちなみにですが、「ディレクトリ管理EC2インスタンスの作成」はHybrid Editionでも可能でした。

5. 作成後Active Direcotry環境の確認

PowerShellから作成後Active Directory環境を確認すると次の通りです。
Hybrid Editionは既存ドメイン環境の延伸なので、ドメインコントローラーが4台構成になりました。

# ドメインコントローラーにAWS Managed Microsoft ADのインスタンス(IP-C61301B7, IP-C61302CC)が増え4台構成に
PS C:\> Get-ADDomainController -Filter * | Select-Object HostName, Ipv4Address, OperatingSystem

HostName                     Ipv4Address OperatingSystem
--------                     ----------- ---------------
adds01.corp.contoso.com      10.0.21.99  Windows Server 2022 Datacenter
adds02.corp.contoso.com      10.0.21.239 Windows Server 2022 Datacenter
IP-C61301B7.corp.contoso.com 10.0.21.85  Windows Server 2019 Datacenter
IP-C61302CC.corp.contoso.com 10.0.22.146 Windows Server 2019 Datacenter

AWS Managed Microsft ADで使用する各種AWS管理のOUなどが既存ドメインに作成され、追加のドメインコントローラーはAWS ReservedOU配下に存在します。

また、サイト構成が他エディションと異なりAWSマネージドなドメインコントローラーはリージョン別のサイトに登録される形になっています。
こちらはマルチリージョン構成の時と似た形です。

FSMOの各機能は移動せずADDS01にあり続ける形でした。

# FSMOの移動は発生しない : ADDS01に全役割が残る
PS C:\> $domainControllers = Get-ADDomainController -Filter *
>> foreach ($dc in $domainControllers) {
>>     Write-Output "Name: $($dc.Name)"
>>     Write-Output "IsReadOnly: $($dc.IsReadOnly)"
>>     Write-Output "OperationMasterRoles:"
>>     foreach ($role in $dc.OperationMasterRoles) {
>>         Write-Output "- $role"
>>     }
>> }
Name: ADDS01
IsReadOnly: False
OperationMasterRoles:
- SchemaMaster
- DomainNamingMaster
- PDCEmulator
- RIDMaster
- InfrastructureMaster
Name: ADDS02
IsReadOnly: False
OperationMasterRoles:
Name: IP-C61301B7
IsReadOnly: False
OperationMasterRoles:
Name: IP-C61302CC
IsReadOnly: False
OperationMasterRoles:

余談1 : FSMOを移動してみる

FSMOをAWSマネージドなドメインコントローラーに移動できるのか気になったので試してみました。
PowerShellで次のコマンドを実行し一つずつ移動してみます。

# 動作確認もあるのでひとつずつ移動してみる
Move-ADDirectoryServerOperationMasterRole -Identity IP-C61301B7 -OperationMasterRole PDCEmulator
Move-ADDirectoryServerOperationMasterRole -Identity IP-C61301B7 -OperationMasterRole SchemaMaster
Move-ADDirectoryServerOperationMasterRole -Identity IP-C61301B7 -OperationMasterRole DomainNamingMaster
Move-ADDirectoryServerOperationMasterRole -Identity IP-C61301B7 -OperationMasterRole RIDMaster
Move-ADDirectoryServerOperationMasterRole -Identity IP-C61301B7 -OperationMasterRole InfrastructureMaster

結果としてはエラーなく普通に移動できてしまいました。

# FSMOの移動はふつうにできてしまう...
PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity IP-C61301B7 -OperationMasterRole PDCEmulator

Move Operation Master Role
Do you want to move role 'PDCEmulator' to server 'IP-C61301B7.corp.contoso.com' ?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity IP-C61301B7 -OperationMasterRole SchemaMaster

Move Operation Master Role
Do you want to move role 'SchemaMaster' to server 'IP-C61301B7.corp.contoso.com' ?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity IP-C61301B7 -OperationMasterRole DomainNamingMaster

Move Operation Master Role
Do you want to move role 'DomainNamingMaster' to server 'IP-C61301B7.corp.contoso.com' ?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity IP-C61301B7 -OperationMasterRole RIDMaster

Move Operation Master Role
Do you want to move role 'RIDMaster' to server 'IP-C61301B7.corp.contoso.com' ?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity IP-C61301B7 -OperationMasterRole InfrastructureMaster

Move Operation Master Role
Do you want to move role 'InfrastructureMaster' to server 'IP-C61301B7.corp.contoso.com' ?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

# FSMOの各機能が IP-C61301B7 に移動していることがわかる
PS C:\> $domainControllers = Get-ADDomainController -Filter *
>> foreach ($dc in $domainControllers) {
>>     Write-Output "Name: $($dc.Name)"
>>     Write-Output "IsReadOnly: $($dc.IsReadOnly)"
>>     Write-Output "OperationMasterRoles:"
>>     foreach ($role in $dc.OperationMasterRoles) {
>>         Write-Output "- $role"
>>     }
>> }
Name: ADDS01
IsReadOnly: False
OperationMasterRoles:
Name: ADDS02
IsReadOnly: False
OperationMasterRoles:
Name: IP-C61301B7
IsReadOnly: False
OperationMasterRoles:
- SchemaMaster
- DomainNamingMaster
- PDCEmulator
- RIDMaster
- InfrastructureMaster
Name: IP-C61302CC
IsReadOnly: False
OperationMasterRoles:

しかしながらその後のアセスメントでこの点がチェックされエラーとなってしまいました。
「AWSドメインコントローラー非FSMO所有者テスト」によりFSMOの各役割が既存環境側にあることが定期チェックされました。

FSMOをAWS管理のドメインコントローラーに移動するとエラー

なお、この状態でもActive Directoryとしては普通に使えAWS Managed Microsoft ADのステータスも「アクティブ」のままでした。
例えば既存環境の障害により一時的にFSMOをAWS側に移動するといった行為は許容されている様です。

余談2 : EC2を1台落としてみる

FSMOが移動できるなら既存環境のドメインコントローラーをシャットダウンしても動作自体はすると思い実際にEC2を1台シャットダウンしてみました。
結果としてはAcitve Directoryとしては問題無く使えましたが、アセスメントの「リモートポート接続テスト」で失敗しました。

今度はアセスメントの結果が完全に「失敗」していますが、これでもActive Directory環境としては継続利用可能です。

余談3 : EC2を2台とも落としてみる

続けてもう一台のEC2もシャットダウンしてみたところ、こちらもアセスメントは失敗するもののActive Directory環境としては継続利用可能でした。

今回は先にFSMOを移動しているのですんなり継続利用できていますが、実環境において既存ドメインコントローラーの障害が起きた際は事前にFSMOの強制移動が必要になる場合があると思うのでご留意ください。

6. AWS Managed Microsoft AD環境の削除

最後にFSMOの各役割をadds01に戻したうえでAWS Managed Microsoft AD環境を削除してみます。

削除の確認が出るので「確認」して削除します。

ディレクトリの削除自体は他エディションと同様です。
しばらく待てば削除が完了します。

削除が完了した時点でActive Directory上ではAWS管理のドメインコントローラーとAWS ReservedOUが削除され、AWS Delegated GroupsOUとcorpOUはそのまま残る形になっていました。

AWSが用意したサイトやグループポリシーも残り続けていました。

利用者により内容が更新されうる部分については残しておく方針の様です。
既存環境への影響を減らす配慮が見て取れます。

ちなみに、この状態で再度アセスメントを行うと「AWS リザーブド OU テスト」で既存GPOがある旨のエラーで失敗するので

• AWS Hybrid Managed Active Directory Policy
• AWS Managed AppLocker Policy
• AWS Reserved Policy:User

については未使用であれば手作業で削除しておくと良いでしょう。

補足 : OSの言語に要注意

この他の注意点としては、現時点では既存環境のOSが英語版Windows Serverでないとアセスメントに失敗します。
これは、アセスメント内のいくつかのテストでコマンドを実行した結果の文字列解析を行っており、非英語OSでは期待した結果を得られないことが原因となります。

一例を挙げると、レプリケーション状態をチェックする「レプリケーションテスト」においてrepadmin /showrepl * /repsto /csvコマンドの結果を解析する部分があるのですが、非英語環境だとCSVのヘッダ名称が英語でなくなるため予期せぬ結果になってしまいます。

# ・・・全略・・・

# この関数で repadmin /showrepl の結果をPowerShellのカスタムオブジェクトに変換
# ただし、CSVのヘッダはOSの言語設定で変わるのでカスタムオブジェクトのプロパティ名が言語依存になっている
Function Find-DetailedDCReplicationStatus {
    $RawData = $(repadmin /showrepl * /repsto /csv 2> $Null)
    $RawData = $RawData | Where-Object { $_ -notlike "showrepl_ERROR*" }
    Return $RawData | ConvertFrom-Csv
}

# ・・・中略・・・

    # replication result between resource domain controller and destination domain controller
    $DetailedDCReplicationResults = Find-DetailedDCReplicationStatus
    ForEach ($ReplicationResult in $DetailedDCReplicationResults) {
        # ↓ "Number of Failures" というプロパティ名は英語環境でのみ有効。他言語だと別名になってしまう...
        if ($ReplicationResult."Number of Failures" -gt $FailLimit) {
            $UniqueFailedDSAs[$ReplicationResult."Destination DSA"] = $true
        }
    }

# ・・・後略・・・

終わりに

だいぶ長くなりましたが以上となります。

AWS Managed Microsoft AD Hybrid Editionは一見すると理想のマネージドActive Directory環境の様に見えますが、実際にはAmazon RDS Customの様に特定の大規模環境において覚悟をもって使う類のものでした。

ほとんどの方にとってはHybrid Editionを採用せずとも他エディションを使い既存ドメイン環境と信頼関係を構築するだけで十分事足りるはずです。
利用費も高額なので採用に際しては十分な検討と検証を行うことをお勧めします。