[アップデート] AWS Managed Microsoft ADのエディション変更がAPIから可能になりました

2025.10.30
しばたです。
今月頭にAWS Managed Microsoft ADのエディション変更がAPIから可能になった旨のアナウンスがありました。
https://aws.amazon.com/about-aws/whats-new/2025/10/aws-directory-service-api-edition-upgrades/
つい先日こちらに気が付いたので実際に試してみました。
 従来の仕様と今回の更新内容従来最初に決めたAWS Managed Microsoft ADのエディション(Standard or Enterprise)は変更できず、何らかの事情によりアップグレードが必要になった際はサポートケースを起票の上AWSサポートとタイミングを調整し環境を更新するという特別対応が必要でした。
今回この部分がREST API(およびAWS CLIやAWS SDK)として提供され、サポートケースの起票無しにStandard EditionからEnterprise Editionへのアップグレードが任意のタイミングで可能になります。
 制限事項アップグレードに関する詳細は以下のドキュメントにまとめられており、併せて制限事項も記載されています。
Upgrading your AWS Managed Microsoft AD
こちらから主な制限を列挙しておきます。
アップグレード可能なのはStandard EditionからEnterprise Editionのみ。Hybrid Editionは対象外。
アップグレードは内部的には「ディレクトリサイズの拡張」として扱われる

一度Enterprise Editionにアップグレードした後にStandard Editionに戻すことは不可。
Standard Editionで取得したスナップショットはEnterprise Editionで利用不可。
現状使ってしまうとエラーとなりディレクトリのステータスに不整合を起こすので要注意。

アップグレードには4～5時間かかる。
本記事で試した際は約2時間で済んだ。環境によって特にドメインコントローラーの数によって変わると思われる。

アップグレードプロセスではドメインコントローラーを1台ずつ更新する。このためアップグレード中にダウンタイムが発生する可能性がある。
特にDNSが一時的に縮退状態になるので要注意。

アップグレードプロセスでドメインコントローラーのホスト名が変わるがIPアドレスは維持される。
LDAPSを使っている場合は新しい証明書が必要。
一度Enterprise Editionにアップグレードした後にStandard Editionに戻すことができないのが一番の注意点でしょう。

この仕様は従来通りだと思われますが、組織の規模が大きくなりStandard Editionではリソース不足になる場合がユースケースとして想定されています。
 試してみたここからは実際に試していきます。
私の検証用AWSアカウントの東京リージョンにStandard Editionのディレクトリ環境一つと管理用Windows Server 2025 EC2を1台用意しました。


検証用に用意したディレクトリ (corp.contoso.com ドメイン)
ドメイン名はcorp.contoso.com、DNSサーバー(=ドメインコントローラー)のIPは10.0.21.92と10.0.22.195になりました。

管理用EC2からドメインコントローラーを調べるとホスト名はそれぞれIP-C61301B6、IP-C6130274となっています。


ドメインコントローラーのホスト情報
両ホストの名前解決を試みるとこんな感じです。
PowerShell
# 各ドメインコントローラーの名前解決を試みた結果
PS C:\> Resolve-DnsName -Name IP-C61301B6

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
IP-C61301B6.corp.contoso.com                   A      1200  Answer     10.0.21.92

PS C:\> Resolve-DnsName -Name IP-C6130274

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
IP-C6130274.corp.contoso.com                   A      1200  Answer     10.0.22.195
また、動作検証用に手動スナップショット(before-upgrade)を取得しておきます。

(詳細は後述しますが本番環境でアップグレードを実施する際は取得しない方が良いです)
 エディションの変更マネジメントコンソール上にエディションを変更するUIは存在しません。

このため今回はAWS CLIから変更します。
AWS CLIはVer.2.31.5以降である必要があります。

AWS CloudShellからaws ds update-directory-setupコマンドを次の様にしてやればアップグレードできます。
CloudShell
# サイズを Small → Large に変えることでエディションを変える
aws ds update-directory-setup \
    --directory-id d-9567a44eb4 \
    --update-type SIZE \
    --directory-size-update-settings DirectorySize=Large
やることはエディションの変更ですがAWS CLI(API)としてはディレクトリサイズをLargeにする指示を出す形になります。
コマンドを実行すると下図の様に何も返さないものの、裏ではアップグレード処理が開始されます。


実行しても特に値は返さないがアップグレード処理は進行する
ディレクトリの状態を確認するとステータスが「更新中」になっていることが分かります。
あとは更新が完了するまで待つだけです。

今回はほぼ初期状態のディレクトリをアップグレードしたのですが約2時間かかりました。

ざっくりドメインコントローラー1台あたり1時間です。
 アップグレード中の挙動制限事項の節で
アップグレードプロセスではドメインコントローラーを1台ずつ更新する。
と記載した様にアップグレードプロセスはドメインコントローラー1台ずつ更新する流れになります。

外から見える限りで処理を追ったところ、
アップグレード対象のドメインコントローラーがドメインから離脱
新しいホストがドメインに参加
この時点で当該のIPアドレスに対してPingは通るがDNS等の通信は不可という状態に
新しいホストのDNS Aレコードは作られず名前解決は不可

新しいホストがドメインコントローラーに昇格
ここでも新しいホストのDNS Aレコードは作られずまだ名前解決は不可

昇格後しばらく経つとDNS Aレコードが増え名前解決可能に
この時点で既存のIPアドレスが再利用される形になる

の手順をすべてのドメインコントローラーが完了するまで繰り返す形になっていました。

処理時間は1台あたり約1時間程度かかりましたが、こちらは環境によって変わるかもしれません。[1]
今回の場合だと、初期状態でIP-C61301B6、IP-C6130274の2台あるドメインコントローラーのうちIP-C6130274が最初にドメインコントローラーおよびドメインから離脱しました。


IP-C6130274 がドメインコントローラーから離脱
この時点でDNSからもレコードが消えており名前解決ができなくなっています。

ただ、当該IP(10.0.22.195)に対してPingだけは疎通する形でした。
PowerShell
# メインコントローラーから離脱した時点で名前解決不可
PS C:\> Resolve-DnsName -Name IP-C6130274
Resolve-DnsName : IP-C6130274 : DNS 名がありません。
発生場所 行:1 文字:1
+ Resolve-DnsName -Name IP-C6130274
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (IP-C6130274:String) [Resolve-DnsName], Win32Exception
    + FullyQualifiedErrorId : DNS_ERROR_RCODE_NAME_ERROR,Microsoft.DnsClient.Commands.ResolveDnsName

# Pingは通る
PS C:\> ping 10.0.22.195

10.0.22.195 に ping を送信しています 32 バイトのデータ:
10.0.22.195 からの応答: バイト数 =32 時間 =1ms TTL=128
10.0.22.195 からの応答: バイト数 =32 時間 =1ms TTL=128
10.0.22.195 からの応答: バイト数 =32 時間 =1ms TTL=128
10.0.22.195 からの応答: バイト数 =32 時間 =1ms TTL=128

10.0.22.195 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 1ms、最大 = 1ms、平均 = 1ms

# DNSのポートは空いていない
PS C:\> Test-NetConnection -ComputerName 10.0.22.195 -Port 53
警告: TCP connect to (10.0.22.195 : 53) failed

ComputerName           : 10.0.22.195
RemoteAddress          : 10.0.22.195
RemotePort             : 53
InterfaceAlias         : イーサネット
SourceAddress          : 10.0.21.206
PingSucceeded          : True
PingReplyDetails (RTT) : 2 ms
TcpTestSucceeded       : False
この時点でもう一台(IP-C61301B6)の方は正常に動作を継続しています。
その後新しいホスト(IP-C6130216)がドメインに参加し、


IP-C6130216 がドメインに参加するがまだドメインコントローラーではない
暫くするとドメインコントローラーに昇格し、最終的に既存のIPアドレスが再利用されます。


IP-6130216 がドメインコントローラーに昇格
この流れをもう一台(IP-C61301B6)の方でも繰り返し、


IP-C61301B6 は IP-C613016F に切り替わる
最終的に新しいホストIP-C613016F、IP-C6130216の2台構成になります。
ホスト名(と、おそらく実体となるEC2)は変わりましたがIPアドレスは従来のものを引き継ぎます。
PowerShell
# ドメインコントローラーのホストは変わったがIPアドレスは変わらず
PS C:\> Resolve-DnsName -Name IP-C613016F

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
IP-C613016F.corp.contoso.com                   A      1200  Answer     10.0.21.92

PS C:\> Resolve-DnsName -Name IP-C6130216

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
IP-C6130216.corp.contoso.com                   A      1200  Answer     10.0.22.195
最終的にディレクトリのステータスが「アクティブ」になれば完了です。

エディションが「Enterprise」に更新されたのが見て取れます。


アップグレード完了
ちなみにaws ds describe-directoriesコマンドで取得できる内容に関してはDirectoryDescriptions.Stageが更新中(Updating)に変わるだけで、それ以外の情報はアップグレード中変化しませんでした。
AWS Managed Microsoft ADのドメインコントローラーはデフォルトで2台なのでアップグレード中はほぼ全時間1台に縮退した状態になります。

アップグレードによるディレクトリの全面停止は無いものの、一定期間DNSの応答が遅延(場合によってはタイムアウト)するタイミングが発生しDNSに依存するシステムにも連鎖的に影響を及ぼす可能性があるのでご留意ください。
 補足1 : ダウングレードはできない制限事項で触れた通り一度アップグレードしたディレクトリのダウングレードはできません。
aws ds update-directory-setupコマンドでディレクトリのサイズをSmallに戻せそうですが、実際にコマンドを実行すると「不正なパラメーター指定」エラーとなります。
CloudShell
# サイズを Large → Small には戻せずエラーになる
~ $ aws ds update-directory-setup \
>     --directory-id d-9567a44eb4 \
>     --update-type SIZE \
>     --directory-size-update-settings DirectorySize=Small

An error occurred (InvalidParameterException) when calling the UpdateDirectorySetup operation: Invalid size type : RequestId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ちなみにLargeからLargeへの変更も別のエラーになります。
CloudShell
# ちなみに Large → Large も別のエラーを返す
~ $ aws ds update-directory-setup \
>     --directory-id d-9567a44eb4 \
>     --update-type SIZE \
>     --directory-size-update-settings DirectorySize=Large

An error occurred (DirectoryInDesiredStateException) when calling the UpdateDirectorySetup operation: Directory d-9567a44eb4 is already in the desired state. : RequestId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 補足2 : アップグレード前エディションのスナップショットを復元してしまった場合!注意

本番環境では絶対に試さないでください。
今回意図的にアップグレード前にスナップショットを取得しておいたので、アップグレード後にこちらを復元するとどうなるのか試してみました。
制限事項に「アップグレード前のスナップショットは使用不可」とあったので操作自体制限されるのかと思ったのですが、そうではなく復元の指示はあっさりできてしまいました。
少しの間ディレクトリの状態が「リストア中」になりますが、
その後すぐリストアに失敗しディレクトリの状態が「障害(Impaired)」になってしまいました。
ディレクトリの状態は時間が経てば回復する場合がありますが、今回のケースで回復するかまでは確認できませんでした...
通常のメンテナンス関連の問題の場合、 AWS は 40 分以内にこれらの問題を解決します。トラブルシューティングのトピックを確認した後も、ディレクトリの障害の状態が 40 分以上続く場合は、AWS サポート センターまでお問い合わせください。
AWS Managed Microsoft AD ディレクトリのステータスについて
このため最悪AWSサポートへの依頼が必要になってしまうのでアップグレード前のスナップショットは復元しないでください。
なお、AWS CLI等から各スナップショット詳細を調べてもエディションに関する情報はありませんでした。

将来的にどうなるかはわかりませんが現時点ではスナップショットのエディションを判別する方法が無いのが現状です。
CloudShell
# 現状AWS CLI(およびREST API)からスナップショットのエディションは取得できない
~ $ aws ds describe-snapshots 
{
    "Snapshots": [
        {
            "DirectoryId": "d-9567a44eb4",
            "SnapshotId": "s-95659c7a26",
            "Type": "Manual",
            "Name": "before-upgrade",
            "Status": "Completed",
            "StartTime": "2025-10-27T09:20:02.357000+00:00"
        }
    ]
}
AWS Managed Microsoft ADのスナップショットを復元する機会自体かなり少ないものですが、誤操作を防ぐためアップグレード後は直ちに古いスナップショットを消しておくのが良さそうです。
 最後に以上となります。
これまで特別対応が必要だったものが任意のタイミングで実行可能となり便利になりました。

アップグレードが容易にできる様になったことでAWS Managed Microsoft ADの導入もより気軽にできるのではないかと思います。

脚注
今回はほぼ初期状態のドメインで試しています ↩︎