WindowsのEC2でEFSがマウント出来たらなあと思うことってたまにあると思います。
例えば、既存アプリをFargateで運用しており、データをEFSに保存しているケースです。

FargateとEFSは相性がよく、快適に運用をしていると、新規アプリがWindowsであり、EFSのデータを活用したいという場合です。それ以外にも、顧客端末をWorkspacesで運用しており、EFSのデータが見たいというケースもあるかもしれません。

以下に、EC2(Windows)でEFSのデータを取得する方法をまとめてみました。

VPC、EFSを作成
Windows NFS Clientでマウント (未サポート)
ベアメタルEC2のWindowsにWSL2をインストールしてマウント (サポート？)
Samba(Fargate)経由でマウント (非推奨)
AWS Transfer Familyを使ってEFSのデータにアクセス (サポート)
DataSyncを使ってEFSからFSx for Windows File Serverへコピー (サポート)
まとめ

※ WindowsでEFSをマウントすることは未サポート

Windowsのみの環境であれば、ECS on EC2(Windows)でFSx for Windows File Serverを使うことや

Windows/Linux混在環境の場合は、FSx for NetApp ONTAPをECS on EC2で使うことも考えられます。

ですが、FSx for Windows File Serverの場合はActive Directoryの構築が必要となりますし、Fargate + EFSで楽に運用したいということも多いと思います。そこで、EC2(Windows)でEFSをマウントすることができないか検討しましたが、以下の通り、公式な情報はありません。

Amazon EFS を Windows EC2 インスタンスで使用しないでください。これはサポートされていません。

https://docs.aws.amazon.com/ja_jp/efs/latest/ug/troubleshooting-efs-mounting.html

新規で環境を作る場合は、FSx for Windows File ServerやFSx for NetApp ONTAPを検討してください。

FargateがFSx for NetApp ONTAPに対応することを強く望みます！！

1. VPC、EFSを作成

今回の検証を行うために、以下のVPCとEFSを作成します。

VPCを作成

VPCは以下の通り、ウィザードでサクッと作りました。
※ enableDnsHostnames および enableDnsSupport は有効にします。

セキュリティグループを作成

EFS用のセキュリティグループを作成します。インバウンドにNFS(TCP/2049)を許可します。インバウンド/アウトバウンドともに、VPC内に制限しています。

EFSを作成

推奨設定で作成します。
※本番環境で利用する場合は、カスタマイズで詳細設定してください。

作成したtest-EFSを選択し、ネットワークタブから管理をクリックします。
※利用可能となっていない場合は、利用可能になるまで待ちます。

サブネットIDがプライベートであることを確認します。セキュリティグループには、先ほど作成したEFS用のセキュリティグループを割り当てます。
※プライベートではない場合、カスタマイズで再作成してください。

IAMポリシーを作成（EFSマウント用）

IAMサービスから、アクセス管理-ポリシー→ポリシーの作成から、以下のポリシーを作成します。
JSON形式で直接入力しました。
※以下の説明でアクセスポイントやマウントを使うため、以下の4つの権限を付与しています。

EFSMountPolicy

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": [
			    "elasticfilesystem:DescribeAccessPoints",
                "elasticfilesystem:DescribeMountTargets",
				"elasticfilesystem:ClientMount",
				"elasticfilesystem:ClientWrite"
			],
			"Resource": "*"
		}
	]
}

2. Windows NFS Clientでマウント (未サポート)

試しに、Windows Server 2025のEC2にNFSクライアントをインストールし、

Install-WindowsFeature NFS-Client

マウントしてみたところ、以下のエラーになりました。
Web検索をしたところ、マウントできそうな記述もありましたが、具体的な手順はわかりませんでした。

PS C:\Users\Administrator> mount.exe -o anon \\<EFSのエンドポイント>:\ X:
Network Error - 53

Type 'NET HELPMSG 53' for more information.

Windows Server 2025になっても、NFS Clientは、NFS v2, v3しかサポートされないようです。

3. ベアメタルEC2のWindowsにWSL2をインストールしてEFSをマウント (サポート？)

WindowsでNFSマウントする手段として、Windows Subsystem for Linux (WSL)を使う方法があります。WSL1とWSL2があり、WSL2はベアメタルインスタンスでのみ利用可能です。詳細は以下に記載があります。
※通常のEC2インスタンスでも、WSL2のインストールを試すことはできますが、通常のEC2では、Nested Virtualizationがサポートされておらず、断念した記憶があります。

WSL1のインストールは以下の通りです。詳細はドキュメントを参照してください。
Windows Server 2022のEC2(t3.medium)で実行しました。

wsl --install --enable-wsl1 --no-launch
shutdown -r -t 20
wsl --set-default-version 1
wsl --install

Windows Server 2025環境で、WSL1を有効化すると、再起動後にシステムの起動が失敗する可能性がありますと記載されていますが、試しにやってみたところ、EC2が起動しなくなりました。
現時点、ベアメタルインスタンスで、Windows Server 2025はサポートされていないようなので、WSLを試す場合は、いずれにしても、Windows Server 2019 or 2022となりそうです。

スタートメニューから、Ubuntuの初期設定をした後、以下のコマンドでefs-utilsをインストールします。

$ sudo apt-get update
$ sudo apt-get -y install git binutils rustc cargo pkg-config libssl-dev gettext
$ git clone https://github.com/aws/efs-utils
$ cd efs-utils
$ ./build-deb.sh
$ sudo apt-get -y install ./build/amazon-efs-utils*deb

amazon-efs-utilsのインストールのところで、以下のようなエラーがでて失敗しました。

Errors were encountered while processing:
 stunnel4
 amazon-efs-utils
N: Download is performed unsandboxed as root as file '/home/dministrator/efs-utils/build/amazon-efs-utils-2.2.0-1_amd64.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
E: Sub-process /usr/bin/dpkg returned an error code (1)

通常のnfs-commonをインストールしてみましたが、同様のエラー？で失敗します。

~/efs-utils$ sudo apt install nfs-common
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
nfs-common is already the newest version (1:2.6.4-3ubuntu5.1).
nfs-common set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 24 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up stunnel4 (3:5.72-1build2) ...
Failed to take /etc/passwd lock: Invalid argument
dpkg: error processing package stunnel4 (--configure):
 installed stunnel4 package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of amazon-efs-utils:
 amazon-efs-utils depends on stunnel4 (>= 4.56); however:
  Package stunnel4 is not configured yet.

dpkg: error processing package amazon-efs-utils (--configure):
 dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          Errors were encountered while processing:
 stunnel4
 amazon-efs-utils
E: Sub-process /usr/bin/dpkg returned an error code (1)

公式情報は見つかりませんでしたが、おそらく、WSL1でEFSのマウントはできないような気がします。

ベアメタルインスタンス+WSL2であれば可能

インスタンスタイプは、z1d.metalを選択しました。
AMIは、Windows Server 2022(base)を利用します。
※Windows Server 2025は、現時点では、ベアメタルインスタンスに対応していませんでした。

EFSとは関係ないですが、インスタンスストアボリュームがついていました。
揮発領域ですが、性能がよく、追加料金が不要な領域です。

WSL2をインストールします。

wsl --install

WSL(Ubuntu)の初期セットアップをします。
efs-utilsをインストールしてみましたが、以下のエラーが出たため、いったん諦めます。
性能が良いため、重たい処理ですがすぐに終わりました。

 N: Download is performed unsandboxed as root as file '/home/dministrator/efs-utils/build/amazon-efs-utils-2.2.0-1_amd64.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

nfsクライアントをインストールします。

$ sudo apt install nfs-common
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
nfs-common is already the newest version (1:2.6.4-3ubuntu5.1).
nfs-common set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 24 not upgraded.

EFSをnfs4としてマウントします。

$ mkdir efs
$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-07d21a23ea629c3f7.efs.ap-northeast-1.amazonaws.com:/ efs

正常にマウントできました。

$ df -h

fs-07d21a23ea629c3f7.efs.ap-northeast-1.amazonaws.com:/  8.0E  3.3G  8.0E   1% /home/dministrator/efs

適当にEFSに格納していたファイルも見えています。

$ tree -L 2 efs
efs
└── shared
    ├── New Text Document.txt
    ├── New folder
    ├── New folder.zip
    └── Program Files (x86)

4 directories, 2 files

書き込み性能です。

$ sudo dd if=/dev/zero of=efs/test.img bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.07046 s, 350 MB/s

読み込み性能です。キャッシュのせいか、かなり高速になっていますが、
コピーなどの操作を試したところ、相当快適に使えそうでした。

$ sudo dd if=efs/test.img of=test-local.img bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.831043 s, 1.3 GB/s

ベアメタルのEC2インスタンスであれば、WSL2を利用することができ、かなり安定したパフォーマンスに見えます。ですが、Windowsから直接見られない点と、ベアメタルインスタンスがかなり高額なため、現実的ではないように思います。
あと、WSL2経由のEFSマウントについて、サポートされるかどうかの言及はありません。

おまけ

以下の通り、インスタンスストアがついていました。せっかくなので検証してみました。

フォーマットをして、Dドライブに割り当てました。
以下のコマンドでWSLからも利用可能になります。

$ sudo mkdir /mnt/d
$ sudo mount -t drvfs D: /mnt/d

書き込み性能です。

$ dd if=/dev/zero of=/mnt/d/test-d.img bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.34816 s, 321 MB/s

読み込み性能です。

$ dd if=/mnt/d/test-d.img of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.61906 s, 410 MB/s

インスタンスによって性能が異なると思いますので、カタログスペックの確認や性能評価をしてから使う必要があります。

4. Samba(Fargate)経由でマウント (非推奨)

現行アプリであるFargate(app)でEFSを使っています。
EC2(Windows)を使ってEFSがマウントできるかどうかという検証です。
直接は難しそうなため、Sambaを使いました。ただし、初期パラメータでマウントしたところ、エラーが頻発して使い物にならなかったため、チューニングをしたところ、安定したパフォーマンスが出るようになりました。

EC2(Windows)をPublic subnetに配置しているのは、RDPで接続しているためです。最初は、Private SubnetでFleet Managerを使っていましたが、すぐに固まるので、RDPに切り替えました。

Sambaで再共有がサポートされるかどうかも怪しいため、顧客がWorkspacesで参照する、夜間バッチなど、リトライ可能な処理で利用するなど、ミッションクリティカルな個所への導入は避けた方がよいと思います。
EFSサポートチームからすると、Samba経由でのWindowsマウントであればサポートされますかと質問されると、されますとは答えづらいと思います。

システム概要

EFSのアクセスポイント設定

ルートディレクトリ: /shared
POSIXユーザー設定:
- ユーザーID: 1002
- グループID: 1001
ディレクトリのアクセス許可:
- 所有者ユーザー: 1002
- 所有者グループ: 1001
- アクセス許可: 0775

AWS Fargate

NFS接続:
- FargateからEFSへは、NFS（TCP/2049）を使用して接続。
マウントポイント:
- EFSアクセスポイントの /shared を Fargate側で /mnt/efs/shared にマウントする

EC2 (Windows) と Samba

Sambaサーバ設定:
- Fargate内の /mnt/efs/shared を、Sambaで共有フォルダ /shared として公開する。
SMB接続:
- EC2 (Windows) からは、SMB（TCP/445）を利用して /shared にアクセスする

ややこしいですが、EFSのアクセスポイントの/sharedとFargateのマウントディレクトリの/mnt/efs/sharedとSambaの共有名sharedはそれぞれ別物です。

Sambaコンテナの作成

CloudShellでの操作を想定しています。
ecs-sambaのようなディレクトリを作り、そこに移動して作業をします。

Sambaのconfファイルを作成します。
※nanoエディターの場合は、そのまま貼り付けられますが、viの場合は、:set pasteを使うときれいに貼り付けられます。

smb.conf

##############################################
# Samba Server 設定ファイル (smb.conf)
# この設定は、Fargate上で動作するSambaサーバとして、
# /mnt/efs/shared を group1 に所属するユーザ向けに共有します。
##############################################

[global]
   # ワークグループ名（Windowsネットワーク内でのグループ分け）
   workgroup = WORKGROUP

   # サーバの説明（ネットワークブラウザに表示される名称）
   server string = Samba Server on Fargate

   # ユーザ認証方式をユーザベースに設定
   security = user

   # 認証に失敗した場合、ゲストとして扱うか否かの設定（ここではゲストを使用しない）
   map to guest = Bad User

   # プリンタ機能を無効化（本サーバはファイル共有専用）
   load printers = no
   disable spoolss = yes

   # ログを標準出力へ出力する設定
   log file = /proc/self/fd/1
   max log size = 0
   log level = 2

##############################################
# 共有設定：group1 に所属するユーザに対して /mnt/efs/shared を公開
##############################################
[shared]
   # 共有の説明
   comment = Shared EFS Directory

   # 共有するディレクトリのパス（EFS上のマウント済みディレクトリ）
   path = /mnt/efs

   # 書き込み可能に設定
   writable = yes

   # ゲストアクセスは不可（必ず認証が必要）
   guest ok = no

   # 書き込み可能なユーザ（group1 に所属するユーザのみ）
   write list = @group1

   # アクセス可能なユーザの制限（group1 に所属するユーザのみ）
   valid users = @group1

   # 作成されたファイル・ディレクトリに対して group1 を強制する
   force group = group1

   # 新規作成ファイルのパーミッション設定（書き込み時にマスクとして適用）
   force create mode = 664

   # 新規作成ディレクトリのパーミッション設定
   force directory mode = 775

次に、Dockerfileを作成します。
グループおよびユーザは、今回はローカルとするため、Dockerfile内で作成しています。

Dockerfile

FROM amazonlinux:2023

# OS のアップデートと必要パッケージのインストール
RUN dnf update -y && \
    dnf install -y samba samba-client && \
    dnf clean all

# group1 の作成（GID 1001）
RUN groupadd -g 1001 group1

# user1 と user2 の作成（UID 1002, 1003; プライマリグループとして group1 を指定）
RUN useradd -m -u 1002 -g group1 user1 && \
    useradd -m -u 1003 -g group1 user2

# Samba ユーザパスワードの設定（例として両ユーザとも "password" を設定）
# ※実運用時はセキュリティ上の理由から強固なパスワードを設定してください。
RUN (echo "password"; echo "password") | smbpasswd -a -s user1 && \
    (echo "password"; echo "password") | smbpasswd -a -s user2

# ※ 共有ディレクトリの作成とパーミッションの設定は、EFSアクセスポイントにより自動管理されるため省略

# smb.conf をコンテナ内の標準パスへコピー
COPY smb.conf /etc/samba/smb.conf

# ポート445のみを公開
EXPOSE 445

# Samba サービス (smbd) をフォアグラウンドで起動
CMD ["/usr/sbin/smbd", "--foreground", "--no-process-group", "-s", "/etc/samba/smb.conf"]

コンテナをビルドします。

docker build -t ecs-samba:latest .

ECRにPush

サービスで「Elastic Container Registry」を検索し、Private registry→Repositoriesからレポジトリの作成をクリックします。

ECRのプライベートレポジトリを作成します。

CloudShellに戻り、ECRにログインします。

aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin <your-account-id>.dkr.ecr.<your-region>.amazonaws.com

DockerイメージにECRリポジトリのURIをタグ付けします。

docker tag ecs-samba:latest <your-account-id>.dkr.ecr.<your-region>.amazonaws.com/ecs-samba:latest

ECRにPushします。

docker push <your-account-id>.dkr.ecr.<your-region>.amazonaws.com/ecs-samba:latest

EFSのアクセスポイントを作成

EFSのアクセスポイントを作成します。
EFSマウント後に、OSコマンドでディレクトリの作成やパーミッションを設定することもできますが、トラブルのもとになりやすいため、今回はEFS側でディレクトリの作成およびパーミッションを設定します。

対象のEFSファイルシステムを選択し、アクセスポイント→アクセスポイントの作成をクリックします。

名前とルートディレクトリは以下のようにしました。
※/sharedをEFSのルートディレクトリとして、Fargateの/mnt/efs/sharedにマウントします。

ユーザIDとグループIDを指定します。今回は、user1のUID、group1のGIDを指定しています。

ルートディレクトリ作成のアクセス許可にも、上記と同様にuser1のUID、group1のGIDを指定します。
group1に対して許可を与えるため、パーミッションは0775としています。

IAMポリシーを作成（ECS Exec用）

IAMサービスから、アクセス管理-ポリシー→ポリシーの作成から、以下のポリシーを作成します。
JSON形式で直接入力しました。

EFSMountPolicy

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": [
			    "elasticfilesystem:DescribeAccessPoints",
                "elasticfilesystem:DescribeMountTargets",
				"elasticfilesystem:ClientMount",
				"elasticfilesystem:ClientWrite"
			],
			"Resource": "*"
		}
	]
}

ECSExecPolicy

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": [
				"ssmmessages:CreateControlChannel",
				"ssmmessages:CreateDataChannel",
				"ssmmessages:OpenControlChannel",
				"ssmmessages:OpenDataChannel"
			],
			"Resource": "*"
		}
	]
}

タスク実行ロールを作成

ECSで使用するタスク実行ロールを作成します。
IAMサービスから、アクセス管理-ロール→ロールを作成をクリックします。

信頼されたエンティティタイプにAWSのサービスを選択します。

ユースケースには、Elastic Container Service Taskを選択します。

許可ポリシーに、AmazonECSTaskExectionRolePolicyと先ほど作成したEFSMountPolicyを選択します。

ロール名に、ecsSambaTaskExectionRoleと入力しました。

タスクロールを作成

タスク実行ロールと同様の内容で、EFSMountPolicyとECSExecPolicyを割り当てます。

ECSのタスク定義を作成

Amazon Elastic Container Serviceを選択し、タスク定義→新しいタスクの作成をクリックします。

Fargateを選択し、先ほど作成したタスクロールおよびタスク実行ロールを割り当てます。

ECRにプッシュしたイメージURIを指定します。
コンテナポートは、445/TCPを公開します。

ログ収集の設定をします。CloudWatch logsに出力します。

先ほど作成したEFSのファイルシステムIDとアクセスポイントIDを指定します。

転送暗号化およびIAM認証を有効にします。

マウントポイントは、/mnt/efs/sharedにします。

ECSクラスターを作成

Amazon Elastic Container Serviceのクラスター→クラスターを作成をクリックします。

クラスター名を入力し、AWS Fargateを選択します。

ターゲットグループを作成

EC2サービスを選択し、ロードバランシング-ターゲットグループ→ターゲットグループを作成をクリックします。

インスタンスタイプはIPアドレスを選択します。

ターゲットグループ名、プロトコル、VPCを設定して次へをクリックします。

ターゲットは削除し、ターゲットグループを作成します。

セキュリティグループを作成（NLB用）

SMB(445)のインバウンドを許可するセキュリティグループを作成します。

NLBを作成

EC2サービスを選択し、ロードバランシング-ロードバランサー→ロードバランサーの作成をクリックします。
ロードバランサータイプは、Network Load Balancerを選択します。

内部向けとします。

VPCを割り当て、プライベートサブネットを指定します。

先ほど作成したセキュリティグループを割り当てます。

リスナーにTCP/445を指定し、先ほど作成したターゲットグループを割り当てます。ロードバランサーを作成します。

ECSサービスを作成

先ほど作成したタスク定義を選択し、デプロイ→サービスの作成をクリックします。

クラスタ名を入力します。

サービス名を入力します。

VPCおよびプライベートサブネットを割り当てます。セキュリティグループは先ほどNLBに割り当てたものを使用します。
パブリックIPは忘れずにオフにしてください。

先ほど作成したロードバランサーを割り当てます。サービスを作成します。

ECS Execで動作確認

先ほど作成したサービスのECS Execを有効にします。

aws ecs update-service \
  --cluster ecs-samba-cluster \
  --service ecs-samba-service \
  --enable-execute-command

サービスを再起動します。

aws ecs update-service \
  --cluster ecs-samba-cluster \
  --service ecs-samba-service \
  --force-new-deployment

古いタスクが残ったままの場合は、以下のように停止します。

タスクIDを上記コンソールか、以下のコマンドで確認します。

aws ecs list-tasks \
  --cluster ecs-samba-cluster \
  --service-name ecs-samba-service

ECS Execで接続します。

aws ecs execute-command \
  --cluster ecs-samba-cluster \
  --task <your-task-id> \
  --container ecs-samba \
  --command "/bin/sh" \
  --interactive

sharedが正常に共有されていることを確認します。

sh-5.2# smbclient -L //localhost -U user1
Password for [WORKGROUP\user1]:

        Sharename       Type      Comment
        ---------       ----      -------
        shared          Disk      Shared EFS Directory
        IPC$            IPC       IPC Service (Samba Server on Fargate)
SMB1 disabled -- no workgroup available

ECS Execの設定に不備があり、以下のエラーが出ました。

~ $ aws ecs execute-command \
  --cluster ecs-samba-cluster \
  --task <your-task-id> \
  --container ecs-samba \
  --command "/bin/sh" \
  --interactive

The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.

An error occurred (TargetNotConnectedException) when calling the ExecuteCommand operation: The execute command failed due to an internal error. Try again later.

ECS Execの設定は、以下のツールによりチェックできるようです。

amazon-ecs-exec-checker
https://github.com/aws-containers/amazon-ecs-exec-checker

~ $ bash <( curl -Ls https://raw.githubusercontent.com/aws-containers/amazon-ecs-exec-checker/main/check-ecs-exec.sh ) <YOUR_ECS_CLUSTER_NAME> <YOUR_ECS_TASK_ID>

-------------------------------------------------------------
Prerequisites for check-ecs-exec.sh v0.7
-------------------------------------------------------------
  jq      | OK (/usr/bin/jq)
  AWS CLI | OK (/usr/local/bin/aws)

-------------------------------------------------------------
Prerequisites for the AWS CLI to use ECS Exec
-------------------------------------------------------------
  AWS CLI Version        | OK (aws-cli/2.23.13 Python/3.12.6 Linux/6.1.127-135.201.amzn2023.x86_64 exec-env/CloudShell exe/x86_64.amzn.2023)
  Session Manager Plugin | OK (1.2.694.0)

-------------------------------------------------------------
Checks on ECS task and other resources
-------------------------------------------------------------
Region : ap-northeast-1
Cluster: ecs-samba-cluster
Task   : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-------------------------------------------------------------
  Cluster Configuration  | Audit Logging Not Configured
  Can I ExecuteCommand?  | arn:aws:iam::************:role/aws-reserved/sso.amazonaws.com/ap-northeast-1/AWSReservedSSO_AdministratorAccess_xxxxxxxxxxxx
     ecs:ExecuteCommand: allowed
     ssm:StartSession denied?: allowed
  Task Status            | RUNNING
  Launch Type            | Fargate
  Platform Version       | 1.4.0
  Exec Enabled for Task  | OK
  Container-Level Checks | 
    ----------
      Managed Agent Status
    ----------
         1. RUNNING for "ecs-samba"
    ----------
      Init Process Enabled (ecs-samba-task:8)
    ----------
         1. Disabled - "ecs-samba"
    ----------
      Read-Only Root Filesystem (ecs-samba-task:8)
    ----------
         1. Disabled - "ecs-samba"
  Task Role Permissions  | arn:aws:iam::************:role/ecsSambaTaskRole
     ssmmessages:CreateControlChannel: allowed
     ssmmessages:CreateDataChannel: allowed
     ssmmessages:OpenControlChannel: allowed
     ssmmessages:OpenDataChannel: allowed
  VPC Endpoints          | 
    Found existing endpoints for vpc-074e657c1a34d98d1:
      - com.amazonaws.ap-northeast-1.s3
    SSM PrivateLink "com.amazonaws.ap-northeast-1.ssmmessages" not found. You must ensure your task has proper outbound internet connectivity.
  Environment Variables  | (ecs-samba-task:8)
       1. container "ecs-samba"
       - AWS_ACCESS_KEY: not defined
       - AWS_ACCESS_KEY_ID: not defined
       - AWS_SECRET_ACCESS_KEY: not defined

チェックしましたが、不備はなく、IAMロール変更後にタスクの再起動が必要というオチでした。

動作確認 (Windows)

EC2(Windows)を作成し、エクスプローラから、\\sharedにアクセスします。ユーザ名とパスワードが聞かれるので、Dockerfile内で作成した、user1/passwordを入力します。

まずは、大量ファイル(1261ファイル)のアップロードです。それなりに安定しています。

次に、1GB以上のファイルのダウンロードです。こちらもそれなりに安定しています。

サポートされない心配はありますが、それなりに使えそうな感じです。

5. AWS Transfer Familyを使ってEFSのデータにアクセス (サポート)

AWS Transfer FamilyのTransfer for SFTPを使ってEFSにアクセスする検証を行いました。
SFTPを使うことができれば、WinSCPなどを使って、Windowsからでもアクセスすることができます。

SFTPユーザ用IAMロールを作成

IAMロールを新規作成します。ユースケースはTransferを選択します。

最初に作成したEFSMountPolicyを追加します。
※アクセスポイントやマウントをしないため、少し過剰な権限です。

名前を付けて作成します。

セキュリティグループを作成

インバウンドの22番を許可するセキュリティグループを作成します。
ソースはVPCのCIDRにしました。

Transfer Familyのサーバを作成 (SFTP)

SFTPを選択します。

IDプロバイダーはサービスマネージドを選択しました。

VPC内で利用するため、VPCでホストを選択しました。VPCの情報及びプライベートサブネットを登録します。

先ほど作成したセキュリティグループを割り当てます。

今回の検証目的であるEFSを選択します。

以下はデフォルトとしました。

その他はデフォルトで次へをクリックします。

暗号化アルゴリズムのオプションでセキュリティポリシーが表示されないことがありましたが、何度か作り直せば表示されました。

サーバーを作成をクリックします。

ユーザのSSHキーを作成

以下のドキュメントを参考に作成します。

WindowsなのでPuTTYを使いました。

PEM形式に変換する必要があったため、CloudShellで以下のように変換しました。

ssh-keygen -i -f sftp-key.putty.pub > sftp-key.pub

ユーザーを作成

ユーザーを追加をクリックします。

ユーザ情報を入力します。
※Sambaで作成したアクセスポイントの情報を入力しています。

先ほど変換した公開鍵を登録します。

Route53 プライベートホストゾーンに登録

エンドポイントが作成されなかったため、プライベートホストゾーンに登録しました。
※事前にVPCに関連付けたプライベートホストゾーンを作成していました。SFTPはIPアドレス直でも利用可能です。

動作確認

WinSCPを使って接続しました。

Route53に登録したレコードまたはIPアドレスを入力し、先ほど作成したユーザ名を入力します。

AdvancedからSSH-Authenticationで、秘密鍵を登録します。

無事、接続できました。

6. DataSyncを使ってEFSからFSx for Windows File Serverへコピー (サポート)

FSx for Windows File Serverを作成します。FSx for Windows File Serverを使うためには、Active Directoryが必要なため、AWS Managed Microsoft ADを使いました。EFSのデータをDataSyncを使ってコピーしています。リアルタイム性はありませんが、大量データを参照したいケースに適しています。

AWS Managed Microsoft Active Directoryを作成

Directory Serviceから、ディレクトリのセットアップをクリックします。

ディレクトリタイプにAWS Managed Microsoft ADを選択します。

Standard Editionを選択しました。
ディレクトリ名とadminのパスワードを入力して次へをクリックします。

Transfer for SFTPで作成したプライベートホストゾーンと同じドメイン名にしていました。同じドメインはダメということで、プライベートホストゾーンは削除しました。

DNS に Amazon Route 53 を使用する予定の場合、AWS Managed Microsoft AD のドメイン名は Route 53 のドメイン名と異なる必要があります。Route 53 と AWS Managed Microsoft AD が同じドメイン名を共有している場合、DNS 解決の問題が発生する可能性があります。

https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html

VPCとサブネットの情報を入力して次へをクリックします。

問題がなければ、ディレクトリの作成をクリックします。

AWS Managed Microsoft Active Directoryの作成は時間がかかります。ステータスがアクティブになるまで待ちます。

Windows ServerをAWS Managed Microsoft ADに統合

作成したManaged ADのDNSアドレスを確認します。

ネットワークのプロパティを開き、DNSを登録します。

次にシステムプロパティから、ドメインに参加します。

ドメイン名を入力します。管理者のユーザ名とパスワードが聞かれるので、Managed AD作成時に指定したadminとパスワードを入力します。再起動がもとめられるので再起動します。

必要に応じてAD管理ツールをインストールします。

https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html

Amazon FSx for Windows File Serverを作成

FSxからファイルシステムを作成をクリックします。

Amazon FSx for Windows File Serverを選択します。

必要な情報を入力します。Windows認証には先ほど作成したAWS Managed Microsoft Active Directoryを指定します。

内容を確認して問題がなければ、ファイルシステムを作成をクリックします。

FSx for Windows File Serverの作成にもそれなりに時間がかかります。

セキュリティグループの作成（FSx for Windows File Server用）

FSxは、インバウンド通信にTCP/445,5985が必要のようです。アウトバウンドはいろいろとありますが、VPC内ですべての通信を許可しておきます。

以下のセキュリティグループを作成しました。

FSx for Windows File Serverは、セキュリティグループの変更メニューがありません。以下のネットワークインタフェースからたどって、ENIごとにセキュリティグループを変更するようです。

以下のように変更できます。

セキュリティグループを変更後、\\shareにアクセスできます。
ユーザとパスワードが求められるので、とりあえずは、ドメイン管理者(admin)を入力しました。
※実際に運用する場合は、ADのユーザを作成してください。

EC2(Windows)からFSx for Windows File Serverをマウントしようとしたところ、アクセスできなかったので、Reachability Analyzerを使って確認しました。FSxのeniのセキュリティグループに原因があるとわかりました。クイック作成をすると、defaultセキュリティグループが割り当てられるようです。スタンダード作成の方が細かく設定できるのでよいです。

AWS DataSyncのタスクを作成

DataSyncサービスのData transfer-タスク→タスクを作成するをクリックします。

送信元のロケーションを設定します。

送信先のロケーションを設定します。

タスク情報を入力します。

続きを入力します。今回はスケジュール実行をせず、手動実行とします。

タスクを実行

タスクを手動で実行します。

正常に実行されました。

動作確認

同期したファイルがFSx for Windows File Serverで表示されました。

その後、EFSに追加したファイルも、タスクを再実行することで移行されました。

7. まとめ

Samba(Fargate)経由でマウント (非推奨)
Sambaの再共有を使っているため、本番環境ではサポートされない可能があります。ですが、最も使いやすい構成のため、開発者がファイルを確認したり、顧客参照用など、ミッションクリティカルではない場合は選択肢の一つになるかもしれません。
AWS Transfer Familyを使ってEFSのデータにアクセス (サポート)
読み書きができ、サポートされる構成のため、最も無難な構成と考えます。オンプレのユーザからVPN経由でアクセスしたり、応用範囲も広い構成です。アプリケーションに組み込む場合は、SFTPなど、Transfer Familyで利用可能なプロトコルに合わせた実装が必要となります。
DataSyncを使ってEFSからFSx for Windows File Serverへコピー (サポート)
リアルタイムな同期ができず、移行元であるEFSに書き込みができないため、用途としては限定的です。参照のみのバッチ処理などでは適した構成です。