COLUMN

2020.09.02 ｜ Writer：ちばちゃん

【第３回】AWS を活用したファイルサーバー構築（EC2-FSx）

企業がクラウドを利用する目的として挙げるものの一つが「ファイル保管・データ共有」です。SaaSを利用する場合も多いですが、さまざまな理由からファイルサーバーをAWSの仮想インスタンス（EC２インスタンス）とストレージサービスを組み合わせて構築して運用する場合も多くあります。

そこで、AWS上でファイルサーバー環境を構築する際の4つのシステム構成とそれぞれのメリット・デメリット、構築手順について、4回に分けて解説します。

なお、AWSの基本的なサービスについてご存じない場合には、本サイトの別コラム「AWS入門　初心者が覚えておくべきAWSの基本」を先にお読みいただくことをお勧めいたします。

AWS上でファイルサーバーを構築する場合には、AWSのストレージサービスの中からひとつを選択しAmazon EC2と組み合わせて構築します。
以下にAWSのストレージサービスの一覧を示します。
本サイトには、それぞれのストレージサービスについてのコラムもありますので、深く知りたい方は下表のストレージ名からリンクされるコラムをご参照ください。また、ファイルサーバーの構築におけるAmazon EBS、EFS、S3についての比較を知りたい方は、「AWSでファイルサーバーを構築する際のストレージの選び方」をご参照ください。

ストレージサービス名	特徴
Amazon EBS	EC2用仮想ハードディスク。EC2からマウントして使用。
Amazon EFS	EC2用のNAS相当。複数のEC2からのマウントが可能。Linux限定。
Amazon FSx	EFSのWindows対応版。OSがWindowsのEC2で使用。
Amazon S3	クラウド型オブジェクトストレージサービス。EC2と組み合わせて運用する場合はStorage Gatewayサービスを使用する。

これまで、Amazon EC2とAmazon EBSの組み合わせ、Amazon EC2とAmazon EFSの組み合わせについて解説してきました。
今回はAmazon EC2とAmazon FSxの組み合わせについて解説します。

Amazon FSxについて

Amazon FSxは以下の２種類のファイルシステムをサポートしています。

Amazon FSx for Windows

ビジネスアプリケーション向け。
Microsoft Windowsファイルシステム向けFSxです。
Amazon EFSがLinux向けの共有ファイルシステムであるのに対し、Windows Serverに対応したもので、複数のWindows Serverからマウント可能です。
Windowsの他、LinuxやMacOSのインスタンスからのマウントも可能です。

Amazon FSx for Lustre

高性能ワークロード向け。
オープンソースのLustre(ラスター)ファイルシステム向けFSxです。Lustreの起動や実行を簡単に、経済的に利用できます。
Lustre：大規模のクラスターコンピューティング、スーパーコンピュータ向けに開発された並列分散ファイルシステムです。
数万規模のクライアント、数百台のサーバ上に搭載された数十PBのストレージ、合計1万TB/s以上のI/Oスループットを有します。

Amazon FSx for Windowsについて

サーバメッセージブロック(SMB)プロトコルを介してアクセス可能なフルマネージド型ファイルストレージを提供するサービスで以下のメリット、デメリットがあります。

メリット：

Windowsシステムとの高い親和性

基盤部分がネイティブなWindowsファイルシステムであるため、Windowsベースのアプリケーションが完全互換性のある共有ファイルストレージとしてアクセスが可能

多様なアクセス方法

SMBプロトコルをサポートしているため、Windows Serverの他、MacOSやLinuxのインスタンスとも接続可能。またVMware Cloud on AWS, Amazon Workspace, Amazon AppStream 2.0インスタンスとの接続も可能

フルマネージド型

ファイルサーバーのソフトウェアの更新やバックアップなどのファイルストレージ管理が不要

容量やスループットを自由に設定可能

最大64TBまで容量の設定が可能で、8Mbpsから2048 Mbpsの範囲でスループットの変更が可能

Multi-AZ選択による高可用性、耐障害性を実現

メインとなるアベイラビリティーゾーンの他に障害やメンテナンスによるサービスダウン回避のため、別のアベイラビリティーゾーンの設定が可能

デメリット：

構築に時間がかかる

１回の構築に約15~30分必要

Active Directory (AD)連携が必須

既存のADが無い場合、AWS Managed Microsoft ADを新規に構築すると約20～40分の作業時間が必要

容量、スループット以外の設定変更不可

FSxファイルシステム名、アベイラビリティーゾーンの変更(Multi-AZ⇔Sigle-AZの変更を含む)やストレージ種別の変更（SSD⇔HDD）、連携するADの変更などは構築時以降、変更不可

1.概要

Amazon EC2とAmazon FSx for Windowsで構成されるファイルサーバーを以下に示します。

上記の構成について解説します。

２つのEC2インスタンス

今回はEC2インスタンスを２つ作成します。
１つはWindowsインスタンス、もう一つは踏み台サーバ用のLinuxインスタンスです。
ファイアウォールに阻まれてWindowsインスタンスに直接リモートデスクトップ接続できない場合、踏み台サーバを経由してWindowsインスタンスにアクセスするために用意します。

AWS Managed Microsoft AD

FSxの前提条件としてFSxと同じVPC上にActive Directoryが構築されている必要があります。今回はAWS Managed Microsoft ADを使用します。

(補足)Active Directoryは当初はAWS Managed Microsoft ADである必要がありましたが、現在は既存のActive Directoryでも利用可能になりました

２つのアベイラビリティーゾーンとサブネット

AWS Managed Microsoft ADの前提条件として、少なくとも２つの異なるアベイラビリティーゾーンにそれぞれ異なるサブネットが用意されている必要があります。
今回はアベイラビリティーゾーンとサブネットをそれぞれ２つ作成します。

なお、本コラムではAmazon VPCについては構築手順のみを開設します。Amazon VPCについて深く知りたい方は、「クラウド上にプライベートネットワーク空間を構築できるAmazon VPCの特徴と接続構成」をご参照ください。

2.VPC作成

2.1.VPCの作成

VPCのマネジメントコンソールを開きます。左側のメニューバーから「VPC」を選択します。

「VPCの作成」ボタンを押下します。
「VPCの作成」画面で以下を設定し「作成」ボタンを押下します。

「名前タグ」にVPCの名称を設定（ここでは「FileServer-VPC」と設定）
「IPv4 CIDRブロック」に作成するIPv4アドレス範囲を設定（ここでは10.11.0.0/16と設定）

2.2.サブネットの作成

VPCのマネジメントコンソールの左側のメニューバーから「サブネット」を選択します。

「サブネットの作成」ボタンを押下します。
「名前タグ」にサブネットの名称を設定します（ここでは「fileserver-subnet-public-a」と設定）
「VPC」にドロップダウンリストから今回作成した「FileServer-VPC」と表示されたVPC IDを選択します。

「アベイラビリティーゾーン」に「ap-northeast-1a(Tokyo Region)」を選択します。
「IPv4CIDRブロック」に「10.11.0.0/24」を設定します。
最後に画面右下の「作成」ボタンを押下します。

同様に以下を設定したサブネットを作成します。

「名前タグ」に「fileserver-subnet-public-c」を設定
「VPC」にドロップダウンリストから「FileServer-VPC」のVPC IDを選択
「アベイラビリティーゾーン」に「ap-northeast-1c(Tokyo Region)」を選択
(※fileserver-subnet-public-aとは異なるアベイラビリティーゾーンを選択)
「IPv4CIDRブロック」に「10.11.1.0/24」を設定

2.3.インターネットゲートウェイの作成とVPCのアタッチ

VPCのマネジメントコンソールの左側のメニューバーから「インターネットゲートウェイ」を選択し、「インターネットゲートウェイの作成」ボタンを押下します。
「インターネットゲートウェイの作成」画面で以下を設定し「作成」ボタンを押下します。

「名前タグ」にインターネットゲートウェイの名称を設定（ここでは「fileserver-igw」と設定）

インターネットゲートウェイが正常に作成されると以下の画面が表示されます。
「閉じる」ボタンを押下します。

インターネットゲートウェイ一覧から作成したインターネットゲートウェイを選択し「アクション」のドロップダウンリストから「VPCにアタッチ」を選択します。

「VPCにアタッチ」画面で以下を設定し「アタッチ」ボタンを押下します。

「VPC」に今回作成した「FileServer-VPC」のVPC IDを設定（入力欄にキーワード「FileServer」と入力、表示された選択候補から「FileServer-VPC」と表示されたVPC IDを選択）

2.4.ルートテーブルの作成

VPCのマネジメントコンソールの左側のメニューバーから「ルートテーブル」を選択します。

「ルートテーブルの作成」ボタンを押下します。

「ルートテーブルの作成」画面で以下を設定し「作成」ボタンを押下します。

「名前タグ」にルートテーブルの名称を設定（ここでは「FileServer-rtbl」と設定）
「VPC」に今回作成した「FileServer-VPC」のVPC IDを設定（入力欄にキーワード「FileServer」と入力、表示された選択候補から「FileServer-VPC」と表示されたVPC IDを選択）

ルートテーブルが正常に作成されると以下の画面が表示されます。「閉じる」ボタンを押下します

ルートテーブル一覧から作成したルートテーブルを選択し「アクション」のドロップダウンリストから「ルートの編集」を選択します。

「ルートの編集」画面で「ルートの追加」ボタンを押下します。

「ルートテーブルの編集」画面で以下を設定し「ルートの保存」ボタンを押下します

「送信先」のCIDRを設定。ここではデフォルトの「0.0.0.0/0」のままとします。
「ターゲット」に作成したインターネットゲートウェイのIDを設定（入力欄にキーワード「igw」と入力、表示された選択候補から「fileserver-igw」と表示されたインターネットゲートウェイIDを選択）

「ルートの編集」が正常に処理されると以下の画面が表示されます。
「閉じる」ボタンを押下します。

ルートテーブル一覧から作成したルートテーブルを選択し「アクション」のドロップダウンリストから「サブネットの関連付けの編集」を選択します。

「サブネットの関連付けの編集」画面で以下を設定し「保存」ボタンを押下します

「関連付けられたサブネット」で表示される２つのサブネットを選択

以下のように２個のサブネットが関連付けられます。

2.5.セキュリティグループの作成

VPCのマネジメントコンソールの左側のメニューバーから「セキュリティグループ」を選択します。

「セキュリティグループの作成」ボタンを押下します。

「セキュリティグループ名」にセキュリティグループの名称（ここでは「FileServer-SecurityGroup」と設定）を設定します
「VPC」に今回作成した「FileServer-VPC」のVPC IDを設定（入力欄にキーワード「FileServer」と入力、表示された選択候補から「FileServer-VPC」と表示されたVPC IDを選択）

「インバウンドルール」に以下を設定し、「セキュリティグループを作成」ボタンを押下します。

「タイプ」に「SSH」を選択、「ソース」に「0.0.0.0/0」を選択

「セキュリティグループ」の「FileServer-SecurityGroup」の詳細画面から「インバウンドルールを編集」ボタンを押下します。

「インバウンドルールを編集」画面が開くので、RDP (Remote Desktop Protocol)ポート(3389)、CIFSポート(139)、SMB ポート(445)を開放します。以下を設定し「ルールを保存」ボタンを押下します。

「タイプ」に「RDP」を選択、「ソース」に「FileServer-SecurityGroup」のIDを選択
「タイプ」に「SMB」を選択、「ソース」に「FileServer-SecurityGroup」のIDを選択
「タイプ」に「カスタムTCP」、「ポート範囲」に「139」、「ソース」に「FileServer-SecurityGroup」のIDを選択

3.EC2インスタンス作成

FSxをマウントするWindows Server OSのEC2インスタンスを作成します。
WindowsのEC2インスタンスへはリモートデスクトップ接続で行います。しかし、接続環境によってはファイアウォールなどでリモートデスクトップ接続がブロックされている場合があります。
この場合、踏み台サーバを経由してリモートデスクトップ接続を実施します。
ここでは、追加で踏み台サーバ用EC2インスタンスも作成し、プロキシ環境からのリモートデスクトップ接続環境の構築方法を解説します。
接続イメージを以下に示します。

3.1.Windowsインスタンス作成

AWSのマネジメントコンソールより、EC2のメニューを選択します。
EC2コンソールの左側のメニューバーより「インスタンス」を選択します。

インスタンスメニュー画面から「インスタンスの作成」ボタンを押下します。

「ステップ1：Amazon マシンイメージ(以下AMI)」選択画面が開きます。
デフォルトのクイックスタート画面ではWindows Serverは英語版しか表示されません。

今回は日本語版のWindows Serverを選択する方法を解説します。
検索文字入力欄に「Japanese」と入力し、左サイトマップから「コミュニティAMI」を選択します。

Windows Server 日本語版 AMIの一覧が表示されます。

今回は「Windows_Server-2016-Japanese-Full-Base-2020.-4.15」を選択します。

一覧の中からm5a.largeを選択します。
「次のステップ：インスタンスの詳細の設定」ボタンを押下します。

「ステップ３：インスタンスの詳細の設定」画面が開きます。以下を設定し「次のステップ：ストレージの追加」ボタンを押下します。

「ネットワーク」のドロップダウンリストから「FileServer-VPC」のVPC IDを選択
「サブネット」のドロップダウンリストから「fileserver-subnet-public-a」を選択
「自動割り当てパブリックIP」のドロップダウンリストから「有効」を選択

「ステップ４：ストレージの追加」画面が開きます。
ここでは何も設定せず「次のステップ：タグの追加」ボタンを押下します。

「ステップ５：タグの追加」画面が開きます。
「タグの追加」ボタンを押下して以下を設定し「次のステップ：セキュリティグループの設定」ボタンを押下します。

「キー」に「Name」と設定
「値」にEC2インスタンスの名称（ここではWindowsFileServerInstance）を設定

「ステップ６：セキュリティグループの設定」画面が開きます。
表示される選択候補から名前が「FileServer-SecurityGroup」であるセキュリティグループを選択、「確認と作成」ボタンを押下します。

「ステップ７：インスタンス作成の確認」画面が開きます。
設定内容に問題ないことを確認し「起動」ボタンを押下します。

「起動」ボタンを押下すると「既存のキーペアを選択するか、新しいキーペアを作成します。」のポップアップ画面が表示されます。
ドロップダウンリストから「新しいキーペアの作成」を選択します。
「キーペア名」に作成するプライベートキーファイル名を入力（ここでは「fileserver-key」と入力）し「キーペアのダウンロード」ボタンを押下します。
プライベートキーファイルのダウンロードを済ませたら最後に「インスタンスの作成」ボタンを押下します。

「作成ステータス」画面が開きます。
インスタンス作成が完了するまである程度の時間を要します。
「インスタンスの表示」ボタンを押下してインスタンスの一覧画面を開きます。

「ステータスチェック」欄の表示が「初期化しています」から「2/2のチェックに合格しました」に変化すればインスタンスの起動は完了です。

3.2.RDPパスワード生成

インスタンスの起動完了後、インスタンス一覧から「WindowsFileServerInstance」にチェックを入れ、「接続」ボタンを押下します。

「インスタンスに接続」の画面が表示されます。
「リモートデスクトップのダウンロード」ボタンの押下は踏み台サーバを使用する場合、不要です(※1)
「パスワードの取得」ボタンを押下します。

(※1)踏み台サーバを使わずに直接リモートデスクトップ接続可能な場合「リモートデスクトップのダウンロード」ボタンを下し、モートデスクトップ用のアクセスファイルをダウンロードします

「スタンドアロンRDPクライアント」を選択します。
「キーペアのパス」の「ファイルを選択」ボタンを押下し、EC2インスタンス生成時、「既存のキーペアを選択するか、新しいキーペアを作成します。」の操作でダウンロードしたプライベートキーファイル「fileserver-key.pem」を選択します。最後に「パスワードの復号」ボタンを押下します。

発行されたパスワードをメモして保存します。
最後に「閉じる」ボタンを押下して画面を閉じます。

(補足)踏み台サーバを使用せず直接リモートデスクトップ接続可能な場合は、ダウンロードしたリモートデスクトップ用のアクセスファイルをダブルクリックします
リモートデスクトップのログイン画面が表示されるのでユーザ名に「Administrator」、パスワードにメモしたパスワードを入力し「OK」ボタンを押下します
Windowsインスタンスへのリモートデスクトップ接続に成功すると、以下のようなWindowsインスタンスのリモートデスクトップ画面が表示されます

3.3.踏み台サーバ用EC2インスタンス生成

Windowsインスタンスに直接リモートデスクトップ接続できない場合、踏み台サーバを使ってリモートデスクトップ接続を実施します。
踏み台サーバ用のインスタンスを生成します。
インスタンスメニュー画面から「インスタンスの作成」ボタンを押下して「ステップ1：Amazon マシンイメージ(以下AMI)」選択画面を開きます。
「Amazon Linux 2 AMI (HVM), SSD Volume Type」を選択します。

「ステップ２：インスタンスタイプの選択」画面が開きます。
踏み台サーバとして使用するだけなので、最も小規模な「t2.micro」を選択します。
「次のステップ：インスタンスの詳細の設定」ボタンを押下します。

「ステップ３：インスタンスの詳細の設定」画面が開きます。
Windowsインスタンス生成時と同じ設定を行います。
「ステップ４：ストレージの追加」でもWindowsインスタンス生成時と同様に何も設定せず「次のステップ：タグの追加」ボタンを押下します。
「ステップ５：タグの追加」では「タグの追加」ボタンを押下して以下を設定し「次のステップ：セキュリティグループの設定」ボタンを押下します。

「キー」に「Name」を設定
「値」にEC2インスタンスの名称（ここでは「Win-EC2-bastion」）を設定

「ステップ６：セキュリティグループの設定」画面が開きます。
Windowsインスタンス生成時と同じ設定を行います。

「ステップ７：インスタンス作成の確認」で設定内容に問題ないことを確認し「起動」ボタンを押下します。

「起動」ボタンを押下すると「既存のキーペアを選択するか、新しいキーペアを作成します。」のポップアップ画面が表示されるので、「既存のキーペア」を選択し、「キーペアの選択」のドロップダウンリストから「fileserver-key」を選択します。
最後に「インスタンスの作成」ボタンを押下します。

「作成ステータス」画面が開きます。
「インスタンスの表示」ボタンを押下してインスタンスの一覧画面を開きます。

「ステータスチェック」欄の表示が「初期化しています」から「2/2のチェックに合格しました」に変化すればインスタンスの起動は完了です。

3.4.踏み台サーバへのSSH接続

踏み台サーバとの接続にはTeraTermやPuTTYなどを使用します。
今回はPuTTYを使用した接続手順を解説します。
「PuTTYセッションの基本設定」で「ホスト名（またはIPアドレス）」に”ユーザ名@Win-EC2-bastionホスト名”(※1)を設定します。

(※1) Amazon Linuxのユーザ名は「ec2-user」

「Win-EC2-bastion」ホスト名はインスタンス「Win-EC2-bastion」の「説明」タブを選択。「パブリックDNS(IPv4)(※2)」または「IPv4パブリックIP」をコピーします。

(※2) EC2インスタンス生成直後はDNSホスト名が割り当てられていない（空欄）状態になっています。

EC2インスタンスを作成したVPCのコンソール画面を開き、「アクション」のドロップダウンリストから「DNSホスト名の編集」を選択します。

「DNSホスト名の編集」画面が開くので「DNSホスト名」のチェックボックスにチェックを入れ、「保存」ボタンを押下します。

これによりEC2インスタンスにDNSホスト名が割り当てられます。

カテゴリから「接続」-「プロキシ」を選択します
「プロキシの設定」でプロキシサーバの情報を入力します。

カテゴリから「接続」-「SSH」-「認証」を選択します
「SSH認証の設定」でEC2インスタンス生成時、「既存のキーペアを選択するか、新しいキーペアを作成します。」の操作でダウンロードしたプライベートキーファイル「fileserver-key.pem」をPuTTY用に変換した秘密鍵ファイル(※3)を入力します。

(※3) “puttygen.exe”を使用して「fileserver-key.pem」をPuTTY形式に変換します。
ここでは変換後のファイル名を「fileserver-key.ppk」として保存します。

「SSHポート転送のオプション」でポートフォワーディングの設定を行います。
カテゴリから「接続」-「SSH」-「トンネル」を選択します。
「受け側ポート」にリモートデスクトップを行うクライアントPCのポートを設定します。未使用の任意のポート番号を使用します（ここでは「13389」と設定）
「送り先」に「WindowsインスタンスのプライベートIP:RDPのポート番号(3389)」を設定します。
最後に「追加」ボタンを押下してSSHポート転送の設定を保存します。

(※4)WindowsインスタンスのプライベートIPはインスタンス「WindowsFileServerInstance」の「説明」タブを選択し、「プライベートIP」から取得します。

カテゴリから「セッション」を選択します。
「保存済みセッション一覧」の入力欄に保存セッション名を設定（ここでは「EC2-FileServer」と入力）し、「保存」ボタンを押下します。

セッションの保存後、「開く」ボタンを押下して踏み台サーバ役のEC2インスタンス「Win-EC2-bastion」にSSH接続します。

下記のような画面が表示されていれば踏み台サーバとのSSH接続は成功です。
このままSSH接続を切断せずに置いておきます。

3.5.Windowsインスタンスへのリモートデスクトップ接続

「Windowsアクセサリ」から「リモートデスクトップ接続」を選択し、リモートデスクトップ・クライアントを起動します。
「コンピューター」に「127.0.0.1:13389」と入力し、「接続」ボタンを押下します。

クライアントPCが別のユーザアカウントでログインしている場合は「別のアカウントを使用する」ボタンを押下して、ログインアカウントを変更します。
ユーザ名に「Administrator」、パスワードに「3.2. RDPパスワード生成」でメモしたパスワードを入力します。
「OK」ボタンを押下しリモートデスクトップ接続を実行します。

以下の警告画面が表示されますが、「はい」ボタンを押下します。

Windowsインスタンスへのリモートデスクトップ接続に成功すると、以下のようなWindowsインスタンスのリモートデスクトップ画面が表示されます。

4.FSx作成

4.1.AWS Managed Microsoft AD作成

Amazon FSx for Windowsには既存のActive DirectoryドメインまたはAWS Managed Microsoft AD(MSAD)の利用が必須となっております。
今回はAWS Managed Microsoft ADの構築手順について解説します。
Directory Serviceコンソールより「ディレクトリのセットアップ」ボタンを押下します。

「ディレクトリタイプの選択」画面で「AWS Managed Microsoft AD」を選択し「次へ」ボタンを押下します。

「ディレクトリ情報の入力」ページが開きます。
「エディション」の選択候補から「Standard Edition」を選択します。

「ディレクトリのDNS名」をFQDNで設定します（ここでは「fileserver.local」と設定）
「ディレクトリのNetBIOS名」は任意なので空欄のままにします。
「ディレクトリの説明」は任意なので空欄のままにします。
「Adminパスワード」と「パスワードの確認」にパスワードを設定します。
最後に「次へ」ボタンを押下します。

「VPCとサブネットの選択」のページが開きます。
「VPC」にドロップダウンリストから「FileServer-VPC」を選択します。
「サブネット」にドロップダウンリストから「fileserver-subnet-public-a」と「fileserver-subnet-public-c」を選択します。
最後に「次へ」ボタンを押下します。

「確認と作成」ページが開きます。設定内容を確認の上、「ディレクトリの作成」ボタンを押下します。

「ディレクトリ」一覧が表示されます。
ステータスの表示が「アクティブ」に遷移するまで待機します。
所要時間は約20～40分になります。

4.2.Amazon FSx for Windowsの生成

(注意)

Amazon FSxのコンソールページは2020年6月現在、まだ日本語化されていません。FSx作成までに20～30分要します。また、作成後は容量とスループット以外の変更ができません。作成を誤ると一から作り直しの上に、作り直しにより多くの時間をロスしてしまいます。作成時は設定内容を間違えないよう注意してください。

Amazon FSxコンソールより「Create file system」ボタンを押下します。

「Select file system type(ファイルシステムタイプの選択)」ページが開きます。
「File system options」から「Amazon FSx for Windows File Server」を選択し「Next」ボタンを押下します。

「Create file system(ファイルシステム作成)」のページが開きます。
「File system details」の設定で以下を設定します。

「File system Name(ファイルシステム名 ※省略可)」にFSxファイルシステム名を設定（ここでは「exFileStorage」と設定）
「Deployment type」を選択（ここではデフォルトの「Multi-AZ」を選択）
「Storage type」を選択（ここではデフォルトの「SSD」を選択）
「Storage capacity(容量)」を設定（ここでは最小の32(GiB)を設定）
「Throughput capacity(スループット性能)」を選択（ここではデフォルトの「Recommended throughput capacity(最適値)」を選択）

「Network & security」の設定で以下を設定します。

「Virtual Private Cloud(VPC)」にドロップダウンリストから「FileServer-VPC」を選択
「VPC Security Groups」にドロップダウンリストから「FileServer-SecurityGroup」を選択
「Preferred subnet」にドロップダウンリストから「fileserver-subnet-public-a」を選択
「Standby subnet」にドロップダウンリストから「fileserver-subnet-public-c」を選択

「Windows authentication (Windows認証)」の設定で以下を設定します。

・「AWS Managed Microsoft Active Directory」を選択、入力欄にドロップダウンリストから「4.1. AWS Managed Microsoft AD作成」で作成した「fileserver.local」を選択

「Encryption (暗号化)」の設定はデフォルトのままとします。
「Maintenance preferences(メンテナンス設定)」の設定はスキップします。
「Tags (タグ設定)」の設定はスキップします。
最後に「Next」ボタンを押下します。

確認画面が開きます。
設定に誤りがないことを確認して「Create file system」ボタンを押下します。

「File systems(ファイルシステム一覧)」のページが表示されます。
「Status」の表示が「Creating」から「Available」に遷移するまで待機します。
所要時間は約15~30分になります。

4.3.Amazon FSx for Windowsのマウント

作成したFSx for WindowsをWindowsインスタンスからマウントします。
マウント方法は以下の手順で確認できます。
「File systems(ファイルシステム一覧)」のページから作成した「exFileStorage」を選択します。
「Attach」ボタンを押下します。

ファイルシステムのアタッチ手順が表示されます。
上から順にWindowsインスタンスからのアタッチ手順、Linuxインスタンスからのアタッチ手順、Amazon AppStream2.0からのアタッチ手順が示されています。

Windowsインスタンスからのアタッチ手順に従いFSx for Windowsのマウントを実施します。
リモートデスクトップ接続したWindowsインスタンスでコマンドプロンプトを起動します。
手順に従いnet useコマンドでFSx for Windowsをマウントします。
“DriveLetter”には“D:”，”Z:”などの空きドライブを指定します。
ワイルドカード”*”を使用すると空きドライブから任意のドライブが割り当てられます。

C:\Users\Administrator>net use * \\amznfsxn5jtty1l.fileserver.local\share

FSx for WindowsのDNS名を使用した場合、以下のようなエラーが発生し、マウントに失敗する場合があります。

システム エラー 53 が発生しました。
ネットワーク パスが見つかりません。

その場合、FSx for WindowsのDNS名の代わりにIPアドレスを使用します。
IPアドレスは以下の手順で取得できます。
「File systems(ファイルシステム一覧)」のページから作成した「exFileStorage」を選択します。
「Actions」ボタンを押下します。ドロップダウンリストから「View details」を選択します。

「exFileStorage」の詳細情報が表示されます。
「Preferred File Server IP Address」にIPアドレスが記述されています。

取得したIPアドレスを使用してFSx for Windowsをマウントします。

C:\Users\Administrator>net use * \\10.11.0.147\share

net useコマンドが正常に動作した場合、以下のようにユーザ名の入力を求められます。
ユーザ名@ドメインの書式で入力します。
(補足)ユーザ名：Admin、ドメイン：fileserver.local

'10.11.0.147' のユーザー名を入力してください: Admin@fileserver.local

パスワードの入力を求められるので、「4.1.AWS Managed Microsoft AD作成」で設定したパスワードを入力します。

10.11.0.147 のパスワードを入力してください:

アタッチに成功すると以下のメッセージが表示されます。

ドライブ Z: は現在 \\10.11.0.147\share に接続されています。

コマンドは正常に終了しました。


C:\Users\Administrator>

割り当てられたネットワークドライブZ:の内容を確認します。

C:\Users\Administrator>z:

Z:\>dir
ドライブ Z のボリューム ラベルは DATA01 です
ボリューム シリアル番号は 9812-1D7B です

Z:\ のディレクトリ

2020/06/02  03:32    <DIR>          .
2020/06/02  03:32    <DIR>          ..
               0 個のファイル                   0 バイト
               2 個のディレクトリ  34,258,829,312 バイトの空き領域

Z:\>

割り当てられたネットワークドライブZ:の内容をエクスプローラーで確認します。

4.4.（参考）LinuxインスタンスからのAmazon FSx for Windowsのマウント

ファイルシステムのアタッチ手順が示すようにAmazon FSx for WindowsはLinuxインスタンスからもマウント可能です。
以下に、Linuxインスタンスからのマウント方法について解説します。

「4.3.Amazon FSx for Windowsのマウント」で取得したファイルシステムのアタッチ手順から「From Linux instance(Amazon EC2, Amazon WorkSpaces,VMware Cloud on AWS)」を選択し、折り畳まれている内容を表示します。

手順に従いcifs-utilsをインストールします。
Amazon Linuxでのインストール手順を下記に示します。

[ec2-user@ip-10-11-0-71 ~]$ sudo yum install cifs-utils
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
amzn2-core
Resolving Dependencies
--> Running transaction check
---> Package cifs-utils.x86_64 0:6.2-10.amzn2.0.2 will be installed
・・・・・・・・・
--> Finished Dependency Resolution

Dependencies Resolved
・・・・・・・・・
Is this ok [y/d/N]: y
Downloading packages:
(1/11): avahi-libs-0.6.31-19.amzn2.0.1.x86_64.rpm
・・・・・・・・・
Complete!
[ec2-user@ip-10-11-0-71 ~]$

マウント用のフォルダを作成します。ここでは/mnt上にfsxフォルダを作成します。

[ec2-user@ip-10-11-0-71 ~]$ sudo mkdir /mnt/fsx

手順に従い、ｍountコマンドのcifsオプションを使用してFSxの共有フォルダをマウントします。
(補足)”user@DOMAIN”は以下のように設定します
user : Admin、DOMAIN : fileserver.local

ec2-user@ip-10-11-0-71 ~]$ sudo mount -t cifs -o vers=3.0,sec=ntlmsspi,user=Admin@fileserver.local //10.11.0.147/share /mnt/fsx

FSx共有フォルダのマウントが正常に受け付けられた場合、パスワードの入力を要求されます。
「4.1.AWS Managed Microsoft AD作成」で設定したパスワードを入力します。

Password for Admin@fileserver.local@//10.11.0.147/share:

dfコマンドでFSxの共有フォルダがマウント出来ているか、確認します。

[ec2-user@ip-10-11-0-71 ~]$  df -h
Filesystem           Size  Used Avail Use% Mounted on
devtmpfs             474M     0  474M   0% /dev
tmpfs                492M     0  492M   0% /dev/shm
tmpfs                492M  404K  492M   1% /run
tmpfs                492M     0  492M   0% /sys/fs/cgroup
/dev/xvda1           8.0G  1.3G  6.8G  16% /
tmpfs                 99M     0   99M   0% /run/user/1000
//10.11.0.147/share   32G   97M   32G   1% /mnt/fsx

5.あとがき

AWSを活用した4つのファイルサーバー構成の内、Amazon EC2(Windows Server)とAmazon FSx for Windows構成されたファイルサーバーの構築手順について解説しました。

今回はWindowsインスタンスということでクライアントPCからの接続が、Linuxの場合のようなSSH接続ではなくリモートデスクトップ接続になります。
リモートデスクトップ接続では、ファイアウォールの設定などで直接接続できない場合にはSSH接続と異なり踏み台サーバが必要となります。
そこで踏み台サーバを使用したWindowsインスタンスへのリモートデスクトップ接続手順についても解説しました。

また、2020年6月現在、Amazon FSx コンソールはまだ日本語対応しておらず、Amazon FSx for Windowsファイルシステム構築手順を詳細に解説したサイトもまだまだ少ない状況でしたので、AWS Managed Microsoft AD(MSAD)を含めた構築手順とマウント手順を出来る限り詳細に解説しました。

Amazon FSx for Windows自体がまだ発展途上であり、東京リージョンに適用されて間もないこともあり、まだまだ使い辛い面もありますが、日を重ねていく毎にこの問題は解消されていくものと思います。ひとまずは現状の利用の参考になれば幸いです。

次回はAmazon EC2とAmazon S3で構成されたファイルサーバーの構築手順についてを解説する予定です。