Windows＋Active Directory環境でのAuto Scaling運用を自動化する方法

Windows OSのEC2インスタンスをAuto Scalingでスケーリング運用する際は、Sysprepやドメイン参加・離脱など、いろいろ考えなければならないことがあります。

青柳英明

2023.07.26

みなさん、こんにちは！
福岡オフィスの青柳です。

今回は、意外とよくある構成ではないかと思う「Windows」＋「Active Directory」＋「Auto Scaling」の環境で役立つテクニックを紹介します。

今回と類似した内容は、過去に千葉 (淳) がブログを執筆しています。

こちらのブログ記事は、Active Directoryを「AWS Directory Service」で構築した環境を対象としていました。

今回は、Directory Serviceを使わずに、EC2上にActive Directoryサーバーを構築した、いわゆる「AD on EC2」環境で動作するものとなっています。

システム構成

当ブログ記事で想定するシステム構成は以下の通りです。

中央にある「Auto Scalingグループ」で管理されたEC2インスタンスが、今回の主役です。

これらのEC2インスタンスは、ELBで負荷分散されるWebアプリケーションサーバーを想定していますが、例えば「処理負荷に応じてスケールするバッチサーバー」等でも構いません。

また、これらのEC2インスタンスはWindows OSであり、かつ、アプリケーションやミドルウェアの要件によりActive Directoryドメインへの参加が必要であるとします。

下の方に視線を移すと、Auto ScalingグループがEC2を起動する際のベースとなる「起動テンプレート」があります。この起動テンプレートに登録するAMIを初期作成または更新するために「雛型サーバー」と呼ぶEC2インスタンスを用意します。

再び中央のAuto Scalingグループに目を戻すと、Auto Scalingのスケールアウト・スケールインが実行される際に、Active Directoryドメインに関して以下の動作が行われる (行う必要がある) ことが描かれています。

スケールアウト時： EC2インスタンスを起動する際、Active Directoryへのドメイン参加を行う
スケールイン時： EC2インスタンスを終了する際、Active Directoryのドメイン参加を解除する

EC2インスタンスの起動・終了の際にActive Directoryドメインの参加・参加解除が何故必要なのか、という点については、普段Windowsを利用されている方であれば理解されているのではないかと思います。

念のため、簡単に解説したいと思います。

「Sysprep」について

まず、Windows特有の概念 (機能) である「Sysprep」について説明します。

Windows OS (サーバー・クライアント) では、あるコンピューターからディスクイメージの複製によって別のコンピューターを作成する場合に「Sysprep」という操作を行う必要があります。

ディスクイメージの複製を単純に行った場合、「SID」と呼ばれるコンピューター固有の識別子もそのまま複製されてしまい、同一のSIDを持つコンピューターが複数存在してしまうことになります。ディスクイメージの複製によって作成されたコンピューター上で「Sysprep」を実行することで、SIDの再生成が強制的に行われ、SIDの重複を回避することができます。

厳密に言うと「Sysprep」は必ず行わなければならない訳ではありません。しかし、Active Directoryドメインに所属するWindowsコンピューターの場合にはSIDの重複が様々な弊害をもたらすことが多いため (例えば「WSUS」の実行が正常に行えない等)、そのような場合に「Sysprep」が使用されます。

起動テンプレートを使ってEC2インスタンスを起動することは、まさにこの「ディスクイメージの複製によって別のコンピューターを作成する」ことに該当します。したがって、ディスクイメージ (＝AMI) を作成・複製する過程で「Sysprep」を実行する必要があるという訳です。

EC2インスタンスを起動する際にActive Directoryドメイン参加を行う理由

「Sysprep」の処理は、Active Directoryドメインに参加している状態では行うことができません。

何故かと言うと、Active Directory上でドメイン参加したコンピューターを管理する際に「SID」が使われるためです。ドメインに参加した状態でSysprepの処理が行われると、SIDが変更されるために管理上のコンピューターと実際のコンピューターとの整合性が取れなくなってしまいます。そのため、Sysprepツールを実行した際、もしコンピューターがドメインに参加している場合には、強制的にドメイン参加を解除してからSysprepの処理が行われるようになっています。

以上のため、起動テンプレートからEC2インスタンスを起動した際は、必然的に「ドメインに参加していない状態」となっています。要件上EC2インスタンス (Windowsサーバー) がドメイン参加を必要とするのであれば、EC2インスタンスを起動する際に別途「ドメイン参加の処理」を行ってあげる必要があります。

EC2インスタンスを終了する際にActive Directoryドメイン参加解除を行う理由

ドメイン参加の解除は、必ず行わなければならないものではありません。ただし、管理上の観点から、終了したEC2インスタンス (Windowsサーバー) はドメイン参加を解除した方が良いのではないかと思います。

Auto Scalingでスケールアウト・スケールインが繰り返し行われると、その度に新しいEC2インスタンスが起動 (作成) され、古いEC2インスタンスが終了 (削除) されます。終了したEC2インスタンスは2度と同じ個体が使われることは無く、たとえコンピューター名やIPアドレスが別であってもActive Directory上では「異なるコンピューター (の個体)」として扱われます。つまり、EC2インスタンスの起動・終了を繰り返すと、Active Directory上に「既に存在しなくなったコンピューター」の管理情報が残ることになります。これを避けるために、EC2インスタンスが終了したタイミングでドメイン参加を解除した方が良いという訳です。

動作の仕組み

システム構成で説明した全体の仕組みについて、いくつかのパートに分けて詳しく解説します。

雛型サーバーの初回構築／更新

まず、Auto Scalingで使用する起動テンプレートに登録する「AMI」を用意する一連の流れを説明します。

手順(1) 雛型サーバーを作成 (または更新)

AMIを用意するために、雛型となるサーバーを1台構築します。雛型サーバーは、もしミドルウェアやアプリケーションの設定を行ったり動作テストを行うために「ドメイン参加」が必要であれば、この時点でドメインに参加しておいて問題ありません。ドメイン参加が不要であればワークグループ環境で構築作業を行います。

サーバーの構成や設定を変更する必要がある場合、雛型サーバーに対して変更を行います。例えば、ミドルウェアのバージョンアップやパッチ適用を行ったり、アプリケーションの改修を適用する等を行います。

手順(2) Sysprepを実行

雛型サーバーの初回構築、または更新の作業が完了しましたら、「Sysprep」の実行を行います。

オンプレミス環境の場合にはマイクロソフトが配布している「Sysprepツール」をサーバーにインストールして実行するのですが、AWS環境 (AWSが提供している公式Windows AMIから起動したEC2インスタンス) の場合は「EC2Launch settings」を使用します。 (EC2Launch settingsはデスクトップのショートカットまたはスタートメニューから実行できます)

手順に従ってEC2Launch settingsの操作を行うと、内部でSysprepが実行されて、完了後に自動的にシャットダウン (EC2インスタンス停止) が行われます。

Sysprepが実行されたコンピューターは、一旦SIDが削除されます。そして、次にOSが起動する際に「OOBE (Out of Box Experience)」という初期化処理が実行され、その際にSIDが新しく設定されます。

(Sysprepとは、このOOBEを実行するための準備設定 (System Preparation) を行う機能・ツールなのです)

手順(3) AMIを作成

EC2インスタンスの停止後、AMIを作成します。作成したAMIが、いわゆる「ゴールデンイメージ」となります。

手順(4) 起動テンプレートを作成

起動テンプレートを新規に作成するか、もしくは、既存の起動テンプレートを更新して新しい「バージョン」を追加します。この時、前の手順で作成したAMIを参照するように設定します。(更新の際は設定を変更します)

もう一つの構成パターン

上記の手順では、雛型サーバー上でSysprepを実行することにより、以下のような懸案が生じる場合があります。

Sysprep実行によりドメイン参加が解除されるため、次のサーバー更新の際に再度ドメイン参加を行わなければならない (雛型サーバーでドメイン参加が必要な場合)
SysprepによりSIDが変更されることにより、ミドルウェアのライセンス管理の問題が起きてしまう

このような場合には、下図のような構成をとると良いかもしれません。

雛型サーバー上で直接Sysprepを実行するのではなく、一旦「一時作業用AMI」を作成して、そこから起動した「一時作業用EC2インスタンス」に対してSysprepを実行します。

この方法ですと、作業のステップは増えますが、雛型サーバー上で直接Sysprepを実行しなくてよいというメリットがあります。

Auto Scalingスケールアウト時の処理

Auto Scalingのスケールアウトの発生に伴いEC2インスタンスのプロビジョニングが行われると、予め設定している「User Dataスクリプト」が実行されます。

スクリプトでは、主に次の2つの処理を行います。

自インスタンスのタグに「コンピューター名」を設定する
- スケールイン時の処理で、インスタンスのタグからOS上のコンピューター名を取得する必要があるため、このタイミングでタグを設定します (詳細は後述)
PowerShellコマンドレッド「Add-Computer」を実行して、自コンピューターをドメインに参加させる

ドメイン参加に必要な各種パラメーターは、パスワードなどの秘匿情報が含まれます。

ですので、User Dataスクリプトにパラメーターを直接埋め込むのではなく、Systems Managerパラメーターストアに格納した情報を参照するようにしています。

Auto Scalingスケールイン時の処理

スケールイン時の処理は、スケールアウト時の処理と同様にEC2インスタンス上で「ドメインから離脱するコマンド」を実行すれば良いように思われるかもしれません。

しかし、その方法だと、期待通りにドメイン参加の解除が行われない場合があります。

EC2インスタンスが終了するシチュエーションとしては、EC2インスタンスが「予期しない終了」をした場合や、ハングアップ状態に陥ったためにAuto Scalingのヘルスチェックで強制終了させられる場合は、何らかの処理を実行するタイミングが無いため、この方法は使えないということになります。

そこで、以下のような処理を実装することにしました。

EventBridgeを使い、Auto Scalingのイベント「EC2インスタンスが正常に終了した」をトリガーにLambda関数を実行する
Lambda関数は、「Systems Manager Run Command」を使いActive Directoryドメインコントローラーに対してスクリプトを投入する
スクリプトでは、PowerShellコマンドレット「Remove-ADComputer」を実行して、Active Directory上に残っているコンピューター情報を削除する

この時、EventBridgeのイベントから対象サーバーの「インスタンスID」を取得することはもちろんできるのですが、Windowsコンピューター名はイベント情報に含まれていません。「Remove-ADComputer」コマンドレットはインスタンスIDではなくコンピューター名を指定する必要があるため、何らかの方法で対象サーバーのコンピューター名を取得する必要があります。

そこで、スケールアウト時の処理で「EC2インスタンスのタグ情報に、自身のコンピューター名をセットする」を行った訳です。スケールイン時のスクリプトでは、インスタンスIDを使ってタグ情報を検索し、コンピューター名を取得するという処理を組み込んでいます。

環境構築手順

では、ここからは、これまでに説明したシステム構成および処理内容を踏まえて、実際の環境を構築していきます。

VPC環境

最初に説明した「システム構成」の図を参考に、VPC環境を作成します。

例えば、以下のようなリソースを作成します。(設定内容の説明は割愛します)

VPC
インターネットゲートウェイ
サブネット (パブリック×2、プライベート×2)
NATゲートウェイ
ルートテーブル

Active Directory関連

Active Directoryドメインコントローラーの作成

Windows EC2インスタンスを作成して、Active Directoryドメインコントローラーにします。

Active Directoryドメインサービスのインストール方法、ドメインコントローラーへの昇格方法については、下記ブログが参考になるかと思います。

今回は「example.com」というドメイン名で新規ドメインを作成しました。

ドメインに関する設定

Auto Scaling対象サーバーを格納するOUの作成

Windowsサーバーをドメイン参加させると、デフォルトではドメインルート直下の「Computers」コンテナに格納されます。

それでも問題は無いのですが、Auto Scalingで多くの台数にスケールアウトする可能性がある場合には、専用のOUを用意してそちらにサーバーを格納することをお勧めします。 (他のドメイン参加サーバーと混在すると管理が煩雑になるため)

今回は、ドメインルート直下に「Servers」というOUを作成することにします。

OUの識別名 (DN: Distinguished Name) はOU=Servers,DC=example,DC=comとなります。

ドメイン参加用ユーザーの作成

Windows EC2インスタンスがドメインに参加する際に使用する「コンピューターをドメインに追加できる権限」を持ったユーザーを作成します。

例えば、以下のような諸元で作成します：

ユーザーログオン名： domjoin@example.com
パスワードの設定
- ユーザーは次回ログオン時にパスワードの変更が必要：いいえ
- パスワードを無期限にする：はい

与える権限 (所属グループ) は、とりあえず「Domain Users」で構いません。より厳密に権限をコントロールする場合には、ローカルログオン権限などを除外すると良いでしょう。

雛型サーバーおよびゴールデンイメージ

EC2インスタンス

雛型サーバーとなるEC2インスタンスを作成します。

例えば、以下のような諸元で作成します：

インスタンス名： example-base
AMI： Windows_Server-2022-Japanese-Full-Base-2023.07.12
インスタンスタイプ： t3.medium (2vCPU, 4GiBメモリ)
ネットワーク
- VPC：＜作成したVPC＞
- サブネット：＜作成したプライベートサブネット#1＞

その他、セキュリティグループやIAMインスタンスプロファイルを適宜設定します。

雛型サーバーの設定

まず、雛型サーバーをActive Directoryドメインへ参加させます。

「TCP/IPv4のプロパティ」の設定で、優先DNSサーバー欄にドメインコントローラーのIPアドレスを指定する
「コンピューターのプロパティ」画面から、ドメイン「example.com」への参加の操作を行う

ドメインに参加した後、今回はWebアプリケーションサーバーの想定ということで、IISサービスをインストールしておきます。

Sysprepの実行

雛型サーバーの構築と一通りの設定が終わりましたら、Sysprepを実行します。

スタートメニューから「Amazon Web Services」→「Amazon EC2Launch settings」の順に選択してEC2Launch settingsを起動します。

この画面でSysprep関連の設定を行います。

基本的に各項目はデフォルトのままで問題ありません。

必要に応じて設定を変更する場合は、AWS公式ドキュメントを参照してください。

EC2Launch を使用した Windows インスタンスの設定 - Amazon Elastic Compute Cloud

もし設定を変更した場合は、画面下部の「Save」をクリックして設定を保存することを忘れないようにします。

準備ができましたら、「Shutdown with Sysprep」をクリックします。

確認ダイアログが表示されますので、「はい」をクリックします。

処理中ダイアログがしばらく表示された後、EC2インスタンスが自動的にシャットダウン (停止) します。

ゴールデンイメージAMI

雛型サーバーのEC2インスタンスからAMIを作成します。

AMI作成時の設定で、特筆すべき点はありません。通常通りにAMIを作成してください。

(停止済みのインスタンスが対象ですので、「再起動しない」のチェックボックスは有効にしても無効にしても結果は変わりません)

AMIの作成が完了しましたら、これがゴールデンイメージとなります。

Systems Managerパラメーターストア

EC2インスタンスがドメイン参加を行う際に使うパラメーターを登録します。パスワード等の秘匿情報はUserDataに直書きするのではなく、パラメーターストアを参照することを推奨します。

以下の5つのパラメーターを登録してください。

名前	種類	値
/active-directory/domain-name	String	ドメイン名 (例：「example.com」)
/active-directory/server-instance-id	String	ドメインコントローラーのEC2インスタンスID (例：「i-XXXXXXXXXXXXXXXXX」)
/active-directory/ou-path	String	コンピューターを格納するOUの識別名(DN) (例：「OU=Servers,DC=example,DC=com」)
/active-directory/join-domain-username	String	ドメイン参加用ユーザー名 (例：「domjoin」)
/active-directory/join-domain-password	SecureString	ドメイン参加用ユーザーのパスワード

Auto Scaling環境

IAMロール

EC2インスタンスに割り当てるIAMロールを作成します。(実際には起動テンプレートの設定でIAMロールを指定します)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateTags",
                "ssm:GetParameter"
            ],
            "Resource": "*"
        }
    ]
}

セキュリティグループ

ロードバランサーおよびEC2インスタンスに割り当てるセキュリティグループを作成します。

ALB用セキュリティグループのインバウンドルール

タイプ	プロトコル	ポート	ソース
HTTP	TCP	80	0.0.0.0/0

EC2用セキュリティグループのインバウンドルール

タイプ	プロトコル	ポート	ソース
HTTP	TCP	80	＜上記で作成したALB用セキュリティグループ＞

Elastic Load Balancer (ALB) ターゲットグループ

ターゲットグループを作成します。

この時、Auto Scalingグループを作成する際に対象ターゲットグループとして指定できるような設定にします。

ターゲットタイプ：インスタンス
プロトコル： HTTP
ポート： 80
VPC：＜作成したVPC＞

ヘルスチェックは、Windowsサーバーに導入したWebサービスに合わせて適切に設定します。

「ターゲットの登録」は、この時点では行いません。

Elastic Load Balancer (ALB) ロードバランサー

ターゲットグループに続いて、ロードバランサーを作成します。

スキーム：インターネット向け
VPC：＜作成したVPC＞
マッピング：＜作成したプライベートサブネット#1/#2＞
セキュリティグループ：＜作成したALB用セキュリティグループ＞
リスナー
- プロトコル： HTTP
- ポート： 80
- デフォルトアクション：＜上記で作成したターゲットグループ＞

EC2起動テンプレート

起動テンプレートを作成します。

「Auto Scalingのガイダンス」にチェックを入れておきます。

AMIの指定では、「自分のAMI」→「自己所有」を選択します。

リストに「＜作成したゴールデンイメージAMI＞」が表示されているはずですので、選択します。

インスタンスタイプ：「起動テンプレートの設定に含めない」を選択 (※Auto Scalingグループで設定)
キーペア：＜任意のキーペアを指定＞ (※Administratorパスワードのデコードが不要であれば指定不要)
サブネット：「起動テンプレートの設定に含めない」を選択 (※Auto Scalingグループで設定)
セキュリティグループ：＜作成したサーバー用セキュリティグループ＞

「高度な詳細」を展開します。設定する箇所は2つあります。

IAMインスタンスプロフィール：＜作成したIAMロール＞

User DataにPowerShellスクリプトを記述します。

<powershell>
[string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
$instance_id = (Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/instance-id)
New-EC2Tag -Resource $instance_id -Tag @{Key = "ComputerName"; Value = $Env:COMPUTERNAME}
$domain_name = (Get-SSMParameter -Name "/active-directory/domain-name").Value
$ou_path = (Get-SSMParameter -Name "/active-directory/ou-path").Value
$username = (Get-SSMParameter -Name "/active-directory/join-domain-username").Value
$password = ConvertTo-SecureString -String (Get-SSMParameter -Name "/active-directory/join-domain-password" -WithDecryption:$true).Value -AsPlainText -Force
$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $password
Add-Computer -DomainName $domain_name -OUPath $ou_path -Credential $credential -Restart
</powershell>

EC2 Auto Scalingグループ

Auto Scalingグループを作成します。

起動テンプレート：＜上記で作成した起動テンプレート＞
バージョン：「Default」を指定

VPC：＜作成したVPC＞
アベイラビリティゾーンとサブネット：＜作成したパブリックサブネット#1/#2＞

インスタンスタイプは、今回は検証のため「t3.medium」固定としました。本番運用では、スポットインスタンスの利用などを検討すると良いかと思います。

ロードバランシング：「既存のロードバランサーにアタッチする」→「ロードバランサーのターゲットグループから選択する」
ターゲットグループ：＜上記で作成したALBのターゲットグループ＞

グループサイズは、現時点では「希望」「最小」「最大」いずれも「0」にしておきます。

全てのリソースの構築が終わってから「希望するキャパシティ」の数を1以上に設定して、動作を確認したいと思います。

スケールイン時の処理のための設定

IAMロール

Lambda関数に割り当てるIAMロールを作成します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeTags",
                "ssm:GetParameter",
                "ssm:SendCommand",
                "ssm:GetCommandInvocation"
            ],
            "Resource": "*"
        }
    ]
}

Lambda関数

Lambda関数を作成します。今回はPythonを使用しました。

前項で作成したIAMロールを割り当てて、コードを記述します。

import boto3
import json
import time

parameter_store_key_adserver = "/active-directory/server-instance-id"
parameter_store_key_username = "/active-directory/join-domain-usernamea"
parameter_store_key_password = "/active-directory/join-domain-passworda"

ec2_client = boto3.client('ec2')
ssm_client = boto3.client('ssm')


########################################
# Lambdaハンドラーメソッド
########################################
def lambda_handler(event, context):
    # for debug
    print(json.dumps(event))

    # イベントデータからインスタンスIDを取得
    instance_id = event['detail'].get('EC2InstanceId', '')

    # インスタンスIDに対応するコンピューター名を取得
    computer_name = get_computer_name(instance_id)

    # SSMパラメーターストアからパラメーターを取得
    adserver = get_parameter_store(parameter_store_key_adserver, False)
    username = get_parameter_store(parameter_store_key_username, False)
    password = get_parameter_store(parameter_store_key_password, True)

    # コンピューターオブジェクトをドメインから削除
    result = send_run_command(target, computer_name, username, password)


########################################
# インスタンスIDに対応するコンピューター名を取得
########################################
def get_computer_name(instance_id):
    # EC2インスタンスに付与されているタグリストを取得
    response = ec2_client.describe_tags(
        Filters=[
            {
                'Name': 'resource-id',
                'Values': [
                    instance_id,
                ],
            },
        ],
    )

    # タグキー「ComputerName」に該当するタグ値を取得
    tags = response['Tags']
    for tag in tags:
        if tag['Key'] == 'ComputerName':
            computer_name = tag['Value']

    return computer_name


########################################
# SSMパラメーターストアからパラメーターを取得
########################################
def get_parameter_store(key, decryption):
    response = ssm_client.get_parameter(
        Name=key,
        WithDecryption=decryption
    )
    value = response['Parameter'].get('Value', '')
    return value


########################################
# コンピューターオブジェクトをドメインから削除
########################################
def send_run_command(target, computer_name, username, password):
    # ドメインコントローラーに対してSSM Run Commandをリモート実行する
    response = ssm_client.send_command(
        InstanceIds=[
            target,
        ],
        DocumentName='AWS-RunPowerShellScript',
        Parameters={
            'commands': [
                '$username = "' + username + '"',
                '$password = ConvertTo-SecureString -String "' + password + '" -AsPlainText -Force',
                '$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $password',
                '$computer_name = "' + computer_name + '"',
                'Remove-ADComputer -Identity $computer_name -Credential $credential -Confirm:$false',
                'if ($? -eq $false) {exit 1}',
            ],
        }
    )

    # コマンドIDを取得
    command_id = response['Command']['CommandId']

    # コマンド実行終了の待ち合わせ
    while True:
        time.sleep(1)
        response = ssm_client.get_command_invocation(
            CommandId=command_id,
            InstanceId=target,
        )
        status = response['Status']
        if status == 'Success' or status == '' or status == 'Failed' or status == 'TimedOut' or status == 'Cancelled':
            return status

EventBridgeルール

EventBridgeのルールを作成します。

EC2 Auto Scalingからのイベントをトリガーにするため、「イベントパターンを持つルール」を選択します。

イベントソース： AWSイベントまたはEventBridgeパートナーイベント

イベントソース： AWSのサービス
AWSのサービス： Auto Scaling
イベントタイプ： Instance Launch and Terminate
インスタンスイベント：「特定のインスタンスイベント」 → 「EC2 Instance Terminate Successful」
グループ名：「特定のグループ名」 → 「＜作成したAuto Scalingグループ名＞」

ターゲットタイプ： AWSのサービス
ターゲットを選択： Lambda関数
機能：＜作成したLambda関数＞

動作確認

それでは、実際の動作を確認してみたいと思います。

スケールアウト時の動作

Auto Scalingグループの「希望するキャパシティ」の数が、現在「0」になっていますので、これを「1」以上に変更します。

しばらくすると、Auto ScalingによってEC2インスタンスがプロビジョニングされます。

EC2インスタンスが起動して、ステータスチェックの表示が「OK」になって、更にしばらく待つと、裏でUser Dataスクリプトが実行されます。

User Dataスクリプトの処理によって、起動したEC2インスタンスに「ComputerName」タグが設定されました。

更にしばらく待つと、Active Directoryドメイン参加が実行されて、ドメインコントローラー上に対象EC2インスタンスのコンピューター名が登録されたことが確認できました。

スケールイン時の動作

今度は、「希望するキャパシティ」の数を、現在の値から減らしてみます。

しばらくすると、Auto Scalingによって余剰となったEC2インスタンスが終了されます。

更にしばらく待つと、ドメインコントローラー上で管理されているコンピューターの情報が、削除されたことが確認できました。

また、Systems Manager Run Commandの実行履歴を確認することで、正常にコンピューター情報の削除が行えたかどうかを確認することもできます。

おわりに

ちょっと処理内容が複雑になってしまった感はありますが、AWS Directory Service環境ではなく「AD on EC2」環境であっても、Auto Scaling運用に伴うドメイン参加・ドメイン参加解除の自動化が行えることが分かりました。

該当する環境で運用されている方がいらっしゃいましたら、試してみて頂ければと思います。

Windows＋Active Directory環境でのAuto Scaling運用を自動化する方法

システム構成

「Sysprep」について

EC2インスタンスを起動する際にActive Directoryドメイン参加を行う理由

EC2インスタンスを終了する際にActive Directoryドメイン参加解除を行う理由

動作の仕組み

雛型サーバーの初回構築／更新

手順(1) 雛型サーバーを作成 (または更新)

手順(2) Sysprepを実行

手順(3) AMIを作成

手順(4) 起動テンプレートを作成

もう一つの構成パターン

Auto Scalingスケールアウト時の処理

Auto Scalingスケールイン時の処理

環境構築手順

VPC環境

Active Directory関連

Active Directoryドメインコントローラーの作成

ドメインに関する設定

Auto Scaling対象サーバーを格納するOUの作成

ドメイン参加用ユーザーの作成

雛型サーバーおよびゴールデンイメージ

EC2インスタンス

雛型サーバーの設定

Sysprepの実行

ゴールデンイメージAMI

Systems Managerパラメーターストア

Auto Scaling環境

IAMロール

セキュリティグループ

Elastic Load Balancer (ALB) ターゲットグループ

Elastic Load Balancer (ALB) ロードバランサー

EC2起動テンプレート

EC2 Auto Scalingグループ

スケールイン時の処理のための設定

IAMロール

Lambda関数

EventBridgeルール

動作確認

スケールアウト時の動作

スケールイン時の動作

おわりに

イベント

EVENT【6/5（水）】QuickSightとTableauのデモで営業分析を解説！アクションに繋げるダッシュボード設計

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会 〜フィンテック / リテール 業界案件特集〜 を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金） 名古屋】クラスメソッドグループの会社説明会を開催します！

関連記事

AWS CDK の aws_s3_assets モジュールを使ってアップロードしたアセットを、EC2 インスタンスにダウンロード可能にしてみた

[アップデート]最後にAMIを使ってEC2インスタンスを立てた日時が確認できるようになりました

RHEL에서 EFS 마운트 시 발생하는 Error: Unable to find a match: build/amazon-efs-utils*rpm 문제 해결

[アップデート]AMIの登録解除保護を設定できるようになりました

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！