![[AWS] CLIでFSx for Windows構築 (AWS管理AD)](https://kacfg.com/wp-content/uploads/2022/12/aws-fsx-cli-aws-managed-ad-e1672489319240.jpg)
AD環境は AWS Managed Microsoft AD を使用したいです。
CLIでFSx for Windows File Server (FSx) を構築する手順を紹介します。
FSxはADへの参加が必要ですが、AD環境は簡単に用意できる AWS Directory Service の AWS Managed Microsoft AD (AWS Managed AD) を使用します。
本記事の内容
- FSxとAWS Managed ADをCLIで作成する
- FSxにEC2 (Windows) からSMB接続する
- 作成したFSxとAWS Managed ADをCLIで削除する
もくじ
FSx for Windowsの構築イメージ (AWS Managed ADにドメイン参加)
今回は以下の構成をCLIで作成します。（EC2の作成手順は割愛）
CLIは環境構築が不要なCloudShellを使います。
- AWS Directory Serviceの AWS Managed AD（ドメインコントローラー）
- FSxを作成し、AWS Managed ADにドメイン参加させる
- AWS Managed ADは必ずマルチAZになるが、FSxも高可用性のためマルチAZとする
FSx for Windows構築前の準備 (AWS Managed AD)
FSxを作成する前の準備作業についてです。
マネジメントコンソールを操作するIAMユーザーのIAMポリシー
マネジメントコンソールを操作するIAMユーザーのIAMポリシーは、テスト目的のためAdministratorAccessが付与されているものとします。
VPC、サブネット、EC2は事前に準備
以下リソースを事前に作成しておきます。（本記事ではこれらの作成手順はふれません）
- VPC、パブリックサブネット1a、プライベートサブネット1aと1c
- EC2 (Windows Server) をパブリックサブネット1aに配置
- EC2のセキュリテイグループは、[マイIP] からの [RDP (TCP, 3389)] インバウンドルールを許可
EC2 (Windows Server) のOSについては、僕はWindows Server2019（日本語版）で作成しました。
また、このEC2はドメイン参加させず、ワークグループ環境のままにしておきます。
FSxのセキュリテイグループ作成
マネジメントコンソールから、FSxにアタッチするセキュリテイグループを事前に作成しておきます。
FSxをマルチAZで作成する場合、アクティブとスタンバイのFSxが作成されますが、必要なセキュリテイグループは1つのみです。
インバウンドルールは以下の通り設定し、EC2からFSxにSMB接続できるようにしてください。
- タイプ：SMB (TCP, 445)
- ソース：EC2 (Windows Server) のセキュリテイグループID
なお、AWS Managed ADにアタッチするセキュリテイグループは作成不要です。
（リソース作成時に自動で作成され、必要なインバウンドルールもAWSが設定してくれるため）
FSxとDirectory Service (AWS Managed AD) のコストについて
FSxとDirectory Service (AWS Managed AD)は、リソース作成後にそれぞれ削除せず数日経つと、それなりのコストが発生します。
（Directory Serviceは、AWSアカウントで初めて使用した場合のみ決まった範囲内で30日間の無料枠あり）
コストが気になる人は、以下の料金見積もりツールなどで確認しておきましょう。
CLIでAWS Managed AD をデプロイ
では早速AWS Managed ADを作成していきます。
CLIの実行環境としてCloudShellを起動
最初にマネジメントコンソールからCloudShellを起動します。
CLI (aws ds create-microsoft-ad) に指定する変数を設定
まずは、CLI実行時に指定する変数にパラメータを代入していきます。
変数を利用すると、異なる用途や環境に対して、パラメータを変えるだけでCLIコマンドが再利用できるメリットがあります。
以下で指定しているパラメータはサンプルなので、自分の環境や用途にあった値に変えてください。
## Directory Serviceのエディション
# StandardとEnterpriseがある。今回はテスト目的なのでStandard
EDITION=Standard
## ディレクトリ(AWS Managed AD)のDNS名（2 ~ 64文字）
# DNSはVPC内でのみ解決される（パブリックに解決可能である必要はない）
# DNSの命名規則に従っていれば任意の名前でよい
DNS_NAME=aws-ad.example.com
## ディレクトリ(AWS Managed AD)のNetBIOS名（最大15文字）
# 空白または次の文字は使用できず、先頭を `.` で始めることはできない
# \ / : * ? " < > |
# NetBIOS名はWindows内で大文字に自動変換される
# マネコンの "ディレクトリのNetBIOS名" を大文字で表示させたいため、以下値は大文字にした
NETBIOS_NAME=AWS-AD
## ディレクトリ(AWS Managed AD)の説明（何でもいい）
DESCRIPTION="AWS Managed Microsoft AD to verify FSx for Windows File Server"
## AWS Managed ADのデフォルト管理ユーザー「Admin」のパスワード（8 ~ 64文字）
# 英小文字、英大文字、数字、特殊文字の4つのカテゴリから3つ以上含める必要がある
# 「admin」は含めることはできない
# 「XXXXXXXX」は任意の文字列に変えてください
ADMIN_PASSWORD=XXXXXXXX
## ディレクトリ(AWS Managed AD)を配置するVPC ID
# 「xxxx...」は自分のVPC IDに変えてください
VPC_ID=vpc-xxxxxxxxxxxxxxxxxx
## ディレクトリ(AWS Managed AD)を配置するサブネットID
# 少なくとも2つのサブネットを指定し、それぞれ異なるAZに存在する必要がある
# 今回はパブリックサブネットのAZ1aとAZ1cを使用するため、以下の変数名にした
# 「xxxx...」と「yyyy...」は自分のパブリックサブネット1aと1cのサブネットIDに変えてください
SUBNET_ID_A=subnet-xxxxxxxxxxxxxxxxxx
SUBNET_ID_C=subnet-yyyyyyyyyyyyyyyyyy
CLI (aws ds create-microsoft-ad) でAWS Managed ADを作成
変数が代入できたらaws ds create-microsoft-adコマンドでAWS Managed ADを作成します。
# 一つ前の手順でDESCRIPTION変数の値に空白を含めたため、6行目の変数は "" で括る
aws ds create-microsoft-ad \
--edition ${EDITION} \
--name ${DNS_NAME} \
--short-name ${NETBIOS_NAME} \
--description "${DESCRIPTION}" \
--password ${ADMIN_PASSWORD} \
--vpc-settings VpcId=${VPC_ID},SubnetIds=${SUBNET_ID_A},${SUBNET_ID_C}
aws ds create-microsoft-adコマンドの詳細は以下の公式ドキュメントから確認できます。
aws ds create-microsoft-adコマンド実行後は、AWS Managed ADのディレクトリIDが出力される。
{
"DirectoryId": "d-xxxxxxxxxx"
}
ディレクトリID (d-xxxxxxxxxx) は次のステップでFSxを作成するとき使用します。
テキストエディタなどにメモしておいてください。
作成が完了するまで20分程かかるので、他の作業でもしながら待ちましょう。
AWS Managed ADのステータスはaws ds describe-directoriesで確認できます。
aws ds describe-directories | \
jq '.DirectoryDescriptions[].DirectoryId,.DirectoryDescriptions[].Stage'
今回のディレクトリIDについて、ステータスがCreatingからActiveに変われば作成完了。
マネジメントコンソールのDirectory Serviceからも、作成したリソースの [ステータス] が [アクティブ] になっていることを確認しておきましょう。
AWS Managed ADのセキュリテイグループ
AWS Managed ADを作成すると、本リソースにアタッチされるセキュリティグループは自動的に作成されます。
セキュリティグループ名は ["ディレクトリID"_controllers] となります。
以下はインバウンドルールです。ほとんどのルールが0.0.0.0/0で全ての接続元を許可していますね。
しかし、基本的にAWS Managed ADは同じVPC内からしかアクセスできないのでご安心ください。
CLIでFSx for Windowsをデプロイ
AWS Managed ADが作成できたので、続いてFSxを作成します。
CLI (aws fsx create-file-system) に指定する変数を設定
AWS Managed AD同様に、CLI実行時に指定する変数にパラメータを代入します。
以下で指定している値はサンプルなので、自分の環境や用途にあった値に変えてください。
## FSxストレージタイプを指定
# FSxストレージ容量の最小はSSDは32GB、HDDは2,000GB
# 今回はSSDを使用（SSD 32GBとHDD 2,000GBだと、HDDの方がコストが高くなるため）
STORAGE_TYPE=SSD
## FSxストレージ容量をGBで指定
STORAGE_GB=32
## FSxスループット容量をMB/秒で指定
# マネコンからFSxを作成する場合の最小は32MB/秒
# CLIだとFSx作成時または作成後に下位レベルの 8 or 16MB/秒に設定できる
# - これらの値はテストや開発向けだが、スループット容量のコストを抑えられる
# - 設定するには監査ログを無効にする必要がある（後述の変数で "AUDIT_LOGLEVEL=DISABLED" とする）
# - 8MB/秒だとストレージ容量が拡張できないといった制約がある
THROUGHPUT_MB=32
## アクティブFSxを配置するサブネットID
# AWS Managed AD作成時に指定した1つめのサブネットにする
# 「xxxx...」は自分のプライベートサブネット1aのIDに変えてください
SUBNET_ID_A=subnet-xxxxxxxxxxxxxxxxxx
## スタンバイFSxを配置するサブネットID
# 今回はマルチAZとするためスタンバイサブネットも使用する
# AWS Managed AD作成時に指定した2つめのサブネットにする
# 「yyyy...」は自分のプライベートサブネット1cのIDに変えてください
SUBNET_ID_C=subnet-yyyyyyyyyyyyyyyyyy
## FSxにアタッチするセキュリティーグループID
# 事前準備の「FSxのセキュリテイグループ作成」で作成したセキュリティーグループを指定
# 「xxxx...」は自分のセキュリティーグループ IDに変えてください
SG_ID=sg-xxxxxxxxxxxxxxxxxx
## FSxのファイルシステム名
# Nameタグとして設定される
# 値は自分の好きな名前に変えてください
FSX_NAME=fsx-windows-awsad-test
## AWS Managed ADのディレクトリID
# 「xxxx...」は先ほど作成した自分のディレクトリIDに変えてください
DIRECTORY_ID=d-xxxxxxxxxx
## FSxのデプロイタイプ
# 今回はマルチAZとする
DEPLOYMENT_TYPE=MULTI_AZ_1
## FSxの週次メンテナンスウインドウ開始時間
# 1つめの数値は月曜から日曜を0~7で指定
# 2つめの数値は開始時間をUTCで指定
# 以下の場合は毎週月曜 JST 04:00
MAINTENANCE_START_TIME=7:19:00
## FSxの日次バックアップ開始時間をUTCで指定
# 以下の場合はJST 23:00
BACKUP_START_TIME=14:00
## FSx日次バックアップの保管日数
# 以下の場合は1世代保管する
BACKUP_RETENTION=1
## FSx上のファイル／フォルダ／ファイル共有の監査ログ出力設定
# "SUCCESS_AND_FAILURE" は成功および失敗の両方をCloudWatchLogsに出力する
# ロググループ名は任意の名前を設定できるが今回は指定しない
# この場合のロググループ名はデフォルトで "/aws/fsx/windows" となる
AUDIT_LOGLEVEL=SUCCESS_AND_FAILURE
CLI (aws fsx create-file-system) でFSx for Windowsを作成
次にaws fsx create-file-systemコマンド実行し、FSx for Windowsを作成します。
aws fsx create-file-system \
--file-system-type WINDOWS \
--storage-type ${STORAGE_TYPE} \
--storage-capacity ${STORAGE_GB} \
--subnet-ids ${SUBNET_ID_A} ${SUBNET_ID_C} \
--security-group-ids ${SG_ID} \
--tags Key=Name,Value=${FSX_NAME} \
--windows-configuration \
"ActiveDirectoryId=${DIRECTORY_ID}, \
DeploymentType=${DEPLOYMENT_TYPE}, \
PreferredSubnetId=${SUBNET_ID_A}, \
ThroughputCapacity=${THROUGHPUT_MB}, \
CopyTagsToBackups=true, \
WeeklyMaintenanceStartTime=${MAINTENANCE_START_TIME}, \
DailyAutomaticBackupStartTime=${BACKUP_START_TIME}, \
AutomaticBackupRetentionDays=${BACKUP_RETENTION}, \
AuditLogConfiguration={\
FileAccessAuditLogLevel=${AUDIT_LOGLEVEL},\
FileShareAccessAuditLogLevel=${AUDIT_LOGLEVEL}}"
aws fsx create-file-systemコマンドの詳細は以下の公式ドキュメントから確認できます。
aws fsx create-file-systemコマンド実行後の出力例。
{
"FileSystem": {
"OwnerId": "123456789012",
"CreationTime": "2023-02-04T23:42:03.274000+00:00",
"FileSystemId": "fs-xxxxxxxxxxxxxxxxxx",
"FileSystemType": "WINDOWS",
"Lifecycle": "CREATING",
"StorageCapacity": 32,
"StorageType": "SSD",
"VpcId": "vpc-xxxxxxxxxxxxxxxxxx",
"SubnetIds": [
"subnet-xxxxxxxxxxxxxxxxxx",
"subnet-yyyyyyyyyyyyyyyyyy"
],
"KmsKeyId": "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"ResourceARN": "arn:aws:fsx:ap-northeast-1:123456789012:file-system/fs-xxxxxxxxxxxxxxxxxx",
"Tags": [
{
"Key": "Name",
"Value": "test-fsx-windows"
}
],
"WindowsConfiguration": {
"ActiveDirectoryId": "d-xxxxxxxxxx",
"DeploymentType": "MULTI_AZ_1",
"PreferredSubnetId": "subnet-xxxxxxxxxxxxxxxxxx",
"ThroughputCapacity": 32,
"WeeklyMaintenanceStartTime": "7:19:00",
"DailyAutomaticBackupStartTime": "14:00",
"AutomaticBackupRetentionDays": 1,
"CopyTagsToBackups": true,
"AuditLogConfiguration": {
"FileAccessAuditLogLevel": "SUCCESS_AND_FAILURE",
"FileShareAccessAuditLogLevel": "SUCCESS_AND_FAILURE",
"AuditLogDestination": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/fsx/windows:log-stream:audit_fs-xxxxxxxxxxxxxxxxxx"
}
}
}
}
作成が完了するまで30分程かかります。休憩などしてしばらく待ちましょう。
現在のステータスはaws fsx describe-file-systemsで確認できます。
# FILESYSTEM_IDに上記で出力された "FileSystemId" (5行目) の値を代入する
FILESYSTEM_ID=fs-xxxxxxxxxxxxxxxxxx
# "aws fsx describe-file-systems" 実行
aws fsx describe-file-systems \
--file-system-ids ${FILESYSTEM_ID} | \
jq '.FileSystems[].Lifecycle'
出力結果がCREATINGからAVAILABLEに変われば作成完了。
マネジメントコンソールのFSxからも、作成したリソースの [ステータス] が [利用可能] になっていることを確認しておきましょう。
FSx作成時に同時に作成されるリソース
今回は監査ログを出力するように設定したので、CloudWatchLogsロググループ/aws/fsx/windowsとログストリームが自動作成されます。
また、対象のAWSアカウントでFSxを初めて作成した場合は、IAMロールAWSServiceRoleForAmazonFSx（サービスにリンクされたロール）も自動作成されます。
作成したFSx for Windowsへの接続確認
それでは、EC2からFSxにSMB接続してみましょう。
AWS Managed ADのIPアドレス確認
マネジメントコンソールのDirectory Serviceから、作成したAWS Managed ADの [ディレクトリ ID] をクリックします。
[ネットワークとセキュリティ] タブの [DNS アドレス] の2つのIPアドレスを、テキストエディタなどにメモします。
EC2 (Windows) のDNSサーバー設定
次にクライアントPCからEC2にRDP接続し、以下手順でEC2のDNSサーバーをAWS Managed ADのIPアドレスに変更します。
コマンドプロンプトを起動し、以下を実行してWindowsの [ネットワーク接続] を開く
%SystemRoot%\system32\control.exe ncpa.cpl
↓
[イーサネット] を右クリックし [プロパティ] をクリック
↓
インターネット プロトコル バージョン4 (TCP/IPv4) を選択し [プロパティ] をクリック
↓
[次のDNSサーバーのアドレスを使う] を選択し、一つ前の手順でメモしたAWS Managed ADの2つのIPアドレスをそれぞれ [優先DNSサーバー] と [代替DNSサーバー] に設定
↓
[OK] をクリックし、[ネットワーク接続] 画面を閉じる
FSxのデフォルトDNS名確認
マネジメントコンソールのFSxから、作成した [ファイルシステム ID] をクリックします。
[ネットワークとセキュリティ] タブの [DNS 名] （FSxのデフォルトDNS名）を、テキストエディタなどにメモします。
FSxのデフォルトDNS名は ["amznfsx" + "英数ランダムの8文字" + "ドメイン名"] となります。
EC2からFSxにSMB接続する
FSxにSMB接続する方法として以下の2通り紹介します。
方法1: エクスプローラから直接FSxに接続
エクスプローラーを起動し、[\\FSxのデフォルトDNS名] で接続します。
資格情報のダイアログが表示されるので、以下の通り [ユーザー名] と [パスワード] を入力して [OK] をクリック。
- ユーザー名: admin@aws-ad.example.com（ユーザー名の @ 以降はAWS Managed AD作成時に指定したディレクトリのDNS名にしてください）
- パスワード：Directory Service作成時に指定した "Adminユーザー" のパスワード
参考
- AWS Managed ADのデフォルト管理ユーザー「Admin」でFSxに接続する
- Windowsのユーザー名は大文字と小文字が区別されないため "admin" と入力してもよい
- 本記事の構成の場合、ユーザー名の @ 以降のDNS名は必ず指定する必要がある
認証が成功すると、FSxに接続しshareフォルダが見えます。
shareフォルダは、FSx作成後にデフォルトで存在する共有です。
方法2: NWドライブ(Z)にFSxのshareをマウントしてエクスプローラから接続
マネジメントコンソールのFSxから、作成したファイルシステムにチェックを入れ、[アタッチ] をクリックします。
クライアントPCのZドライブにFSxをマウントするnet useコマンドが表示されるので、それを使用します。
コマンドプロンプトを起動し、以下を実行します。
## Zドライブがマウントされていないことを確認
net use
新しい接続は記憶されます。
一覧にエントリが存在しません。
## ZドライブにFSxをマウントする
# 「amznfsxxxxxxxx.aws-ad.example」は自分のFSx デフォルトDNS名に変えてください
net use Z: \\amznfsxxxxxxxx.aws-ad.example\share
## ユーザー名とパスワード入力
# 入力するユーザー名とパスワードは、一つ前の手順 [方法1: エクスプローラから直接接続] を参照してください
'amznfsxxxxxxxx.aws-ad.example.com' のユーザー名を入力してください: admin@aws-ad.example.com
amznfsxxxxxxxx.aws-ad.example.com のパスワードを入力してください:
コマンドは正常に終了しました。
## ZドライブにFSxがマウントされたことを確認
net use
新しい接続は記憶されます。
ステータス ローカル名 リモート名 ネットワーク名
-------------------------------------------------------------------------------
OK Z: \\amznfsxxxxxxxx.aws-ad.example.com\share
Microsoft Windows Network
コマンドは正常に終了しました。
エクスプローラーを開き、ZドライブにマウントされたFSxのshareフォルダにアクセスできることを確認してください。
作成したFSxとAWS Managed ADをCLIで削除
リソース削除はFSx → AWS Managed ADの順に行います。
FSxが存在している時にAWS Managed ADを削除しようとしても、エラーになります。
以下はマネジメントコンソールから操作した時のエラー画面です。
CLIでFSx for Windows File Server を削除
FSx作成後、CLI実行時に指定した「日次バックアップ開始時間」を過ぎていた場合は、バックアップが取得されている可能性があります。
しかし、FSxを削除すると自動取得したバックアップも一緒に削除されるので、手動でこのバックアップを削除する必要はありません。
FSxはaws fsx delete-file-systemで削除します。
# FILESYSTEM_IDに削除対象のFSxファイルIDを代入する
FILESYSTEM_ID=fs-xxxxxxxxxxxxxxxxxx
# "aws fsx delete-file-system" 実行
# "SkipFinalBackup=true" でFSx削除前のバックアップは取得しない（デフォルトだと取得）
aws fsx delete-file-system \
--file-system-id ${FILESYSTEM_ID} \
--windows-configuration \
"SkipFinalBackup=true"
aws delete-file-systemコマンドの詳細は以下の公式ドキュメントから確認できます。
aws fsx delete-file-systemコマンド実行後の出力例。
{
"FileSystemId": "fs-xxxxxxxxxxxxxxxxxx",
"Lifecycle": "DELETING",
"WindowsResponse": {}
}
FSx削除完了まで20分程かかります。しばらく待ちましょう。
削除のステータスはaws fsx describe-file-systemsで確認できます。
aws fsx describe-file-systems \
--file-system-ids ${FILESYSTEM_ID} | \
jq '.FileSystems[].Lifecycle'
出力結果がDELETINGから以下に変われば削除は完了。
An error occurred (FileSystemNotFound) when calling the DescribeFileSystems operation:
File system 'fs-xxxxxxxxxxxxxxxxxx' does not exist.
マネジメントコンソールからもFSxが削除されたことを確認しておきましょう。
監査ログの出力を設定した場合に作成される、CloudWatchLogsロググループ/aws/fsx/windowsとログストリームは自動削除されません。これらが不要な場合は手動で削除してください。
FSxにアタッチされていたIAMロールAWSServiceRoleForAmazonFSxも自動削除されませんが、これは削除しなくても特に問題ないでしょう。
CLIでAWS Managed Microsoft AD を削除
AWS Managed ADはaws ds delete-directoryで削除します。
# DIRECTORY_IDに削除対象のDirectory ServiceディレクトリIDを代入する
DIRECTORY_ID=d-xxxxxxxxxx
# "aws ds delete-directory" 実行
aws ds delete-directory \
--directory-id ${DIRECTORY_ID}
aws ds delete-directoryコマンドの詳細は以下の公式ドキュメントから確認できます。
aws ds delete-directoryコマンド実行後は、コマンド実行後は、以下の通りディレクトリIDが出力される。
{
"DirectoryId": "d-xxxxxxxxxx"
}
まだFSxの削除が完了していない場合は、以下エラーが発生しAWS Managed ADの削除に失敗します。
An error occurred (ClientException) when calling the DeleteDirectory operation: Cannot delete the directory because it still has authorized applications. : RequestId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx
5分程でAWS Managed AD削除は完了します。
削除のステータスはaws ds describe-directoriesで確認できます。
aws ds describe-directories | \
jq '.DirectoryDescriptions[].DirectoryId,.DirectoryDescriptions[].Stage'
今回のディレクトリIDについて、出力がDeletingから非表示に変われば削除完了。
マネジメントコンソールからもAWS Managed ADが削除されたことを確認しておきましょう。
AWS Managed AD作成時に自動作成されたセキュリティグループは、自動的に削除されます。
CLIでFSx for Windowsを作成 (AWS Managed AD)：まとめ
CLIでAWS Managed ADを使用したFSx for Windowsを作成・削除する手順を紹介しました。
コマンドさえ準備しておけば、コピペだけで簡単にリソースを作成したり削除できる点がCLIの魅力ですよね。
テストなどで素早くFSxを作成・削除したい場合に、本記事を参考にしてもらえれば幸いです。