概要

AWS上で Amazon FSx for OpenZFS を利用する前提で、Linux クライアント、オンプレミスの Windows 11 パソコン、S3 エンドポイントを含めた検証環境を作り、接続経路と UID / GID の整合性を確認した内容をまとめます。

今回の前提として、インターネットへ接続する経路は S3 Endpoint 関連のみ とし、それ以外のクライアントやストレージは閉域寄りの構成で扱いました。

この記事では、特に以下を整理します。

検証用 VPC / サブネット構成
各クライアント / エンドポイントの接続位置
Windows 11 側の AnonymousUid / AnonymousGid 設定
S3 エンドポイント側でそろえた POSIX 属性
実際に検証時に意識した設定ポイント

FSx for OpenZFS は NFS ベースのファイル共有を前提にするため、クライアントごとの UID / GID の扱いを最初にそろえておくと、後から権限差分でハマりにくくなります。

検証の目的

今回の検証で確認したかったのは、次の 3 点です。

protected サブネット上の Linux から FSx for OpenZFS に問題なくアクセスできるか
オンプレミスの Windows 11 から NFS クライアントとしてアクセスしたときに、所有者のズレを防げるか
S3 エンドポイント側で扱う POSIX 属性を uid=1000 / gid=1000 にそろえた場合、運用上の整合性を保てるか

検証環境の全体像

検証用の VPC を新規に作成し、サブネットは public、private、protected の 3 つを用意しました。

ただし、外部向けの通信は常時広く許可せず、インターネットからの接続先は S3 Endpoint のみ という前提で構成しています。

サブネットの役割

サブネット	主な役割	想定配置
public	将来の拡張や管理用途を見越したセグメント	今回は常用なし
private	将来の内部向けリソース拡張用	今回は常用なし
protected	クライアント検証用の内部セグメント	FSx for OpenZFS、Linux クライアント

protected サブネットは、インターネットへ直接さらさず、Linux クライアントや FSx for OpenZFS を内部通信で扱うイメージです。今回の検証では、インターネットからの接続先は S3 Endpoint のみとし、S3 Endpoint から FSx for OpenZFS へ連携する構成にしました。

検証クライアント

今回アクセス元として用意したのは以下の 3 つです。

クライアント	配置	用途
Linux	VPC の protected サブネット	FSx for OpenZFS への主たる NFS マウント確認
Windows 11	オンプレミス（VPN 経由で VPC 接続）	NFS クライアント利用時の UID / GID 整合性確認
S3 エンドポイント	VPC 内	インターネットからの受け口と FSx for OpenZFS への連携確認

Windows 11 からの疎通については、オンプレミスと VPC の間にインターネット VPN を構成し、その経路で VPC 側へ到達できる前提で検証しています。

FSx for OpenZFS 側で意識したこと

FSx for OpenZFS 自体の細かなパラメータは環境要件に依存しますが、今回の検証では最低限次の点を意識しました。

FSx for OpenZFS は protected サブネット側に配置する
Linux クライアントと Windows 11 から到達できるルーティングを用意する
セキュリティグループ / ファイアウォールで NFS 通信を許可する
オンプレミスからの接続は VPN 経由に限定する
インターネットからの接続は S3 Endpoint のみに限定する
S3 Endpoint から FSx for OpenZFS への連携経路を明確にする
ファイル所有者の基準となる UID / GID を 1000:1000 に寄せる

特に、Linux と Windows の間でファイル所有者が食い違うと、書き込み可否の切り分けが面倒になるため、今回は UID / GID を明示的にそろえました。

Linux クライアントの設定

protected サブネット上の Linux では、同じ protected サブネットに配置した FSx for OpenZFS を通常の NFS クライアントとしてマウントします。

確認ポイント

NFS クライアントパッケージが入っていること
マウント先ディレクトリを作成していること
アプリケーション実行ユーザー、または作業ユーザーが uid=1000 / gid=1000 を利用すること

設定例

sudo mkdir -p /mnt/fsx-openzfs

id

sudo mount -t nfs -o nfsvers=4.1 \
  <fsx_dns_name>:/fsx /mnt/fsx-openzfs

必要に応じて、Linux 側の作業ユーザーを uid=1000 / gid=1000 にそろえておくと、Windows や S3 Endpoint 経由で FSx を参照したときの所有者差異を減らしやすくなります。

Windows 11 クライアントの設定

Windows 11 から NFS マウントする場合、所有者マッピングでハマりやすいため、今回は AnonymousUid = 1000、AnonymousGid = 1000 を設定しました。

設定方針

Windows の「NFS クライアント」機能を有効化する
Windows 標準の NFS クライアントを利用する
匿名アクセス時の UID / GID を 1000 に固定する
Linux 側と同じ所有者として扱えるようにする

レジストリ設定例

PowerShell を管理者権限で開いて設定します。

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default" -Name "AnonymousUid" -PropertyType DWord -Value 1000 -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default" -Name "AnonymousGid" -PropertyType DWord -Value 1000 -Force

設定後は、NFS クライアント関連サービスの再起動、または OS 再起動を行ってからマウント確認するのが安全です。

Windows 側で AnonymousUid / AnonymousGid を設定しないまま検証すると、Linux 側で見た所有者が意図しない値になり、書き込み権限の切り分けが難しくなります。

Windows 11 からの接続でハマった点（セキュリティグループ）

Windows 11 からの接続確認時に一番ハマったのは、セキュリティグループのポート開放条件でした。

NFS ポートだけを許可した状態では接続できなかった
特に NFSv3 利用時は追加ポートが必要だった

今回の検証では、以下を許可して接続できるようになりました。

用途	許可ポート/プロトコル
NFSリモートプロシージャコール	111/tcp 111/udp
NFSサーバーデーモン	2049/tcp 2049/udp
NFSマウントステータスモニター UDP ロックデーモン	20001-20003/tcp 20001-20003/udp

2049 のような NFS の代表ポートのみを開けても、NFSv3 の場合は接続不可になるケースがあります。Windows 11 から接続する場合は、セキュリティグループで 111/tcp,111/udp と 20001-20003/tcp,20001-20003/udp の追加を先に確認しておくと切り分けが早いです。

S3 エンドポイント側の POSIX 設定

今回の検証では、S3 Endpoint から FSx for OpenZFS へ連携する際に扱う POSIX 属性も Linux / Windows とそろえて、uid=1000、gid=1000 に統一しました。

そろえた理由

ストレージ間でファイル所有者の見え方を合わせたい
検証時の比較条件を単純化したい
後続の自動処理や連携処理で権限差異を減らしたい

設定方針

項目	値
UID	1000
GID	1000
目的	Linux / Windows 11 と所有者表現をそろえる

S3 Endpoint から FSx for OpenZFS へ流れるデータに POSIX 属性を与える場合は、FSx 側・Linux 側・Windows 側で基準となる UID / GID を一致させておくと、検証ログの読み解きがかなり楽になります。

設定内容まとめ

今回の構成で、最低限そろえた設定を表にすると次のとおりです。

対象	配置 / 接続元	主な設定	備考
FSx for OpenZFS	protected サブネット	NFS アクセス許可、クライアントからの到達性確保	ストレージ本体
Linux クライアント	protected サブネット	NFS マウント、`uid=1000` / `gid=1000` を基準化	検証の主軸
Windows 11	オンプレミス	`AnonymousUid=1000`、`AnonymousGid=1000`、VPN 経由で接続	NFS 利用時の所有者合わせ
セキュリティグループ（Windows 11 / NFSv3）	FSx for OpenZFS へのインバウンド	`111/tcp`、`1024-65535/tcp` を追加許可	NFS ポートのみでは接続不可だったため追加
VPN	On-Premises - VPC 間	オンプレミスから protected サブネットへの接続経路	インターネット VPN
S3 エンドポイント	VPC 内	POSIX を `uid=1000` / `gid=1000`、Internet からの接続を受けて FSx へ連携	属性の整合性確認
VPC	検証用に新規作成	public / private / protected の 3 サブネット、Internet からの接続先は S3 Endpoint のみ	責務分離

検証で見たかった観点

今回のような構成で確認しておくとよい観点は、次のようなものです。

Linux から作成したファイルを別クライアントから見たときの所有者表示
Windows 11 から作成 / 更新したファイルが Linux 側でどう見えるか
S3 Endpoint から FSx for OpenZFS へ連携した処理で POSIX 属性が期待通りか
protected サブネット内の Linux から FSx for OpenZFS への到達性に問題がないか
S3 Endpoint 以外に不要な Internet 向け経路が存在しないか
権限エラー発生時に、ネットワーク要因か UID / GID 要因かを切り分けられるか

この構成でよかった点

サブネットの責務が分かれていて、通信経路を整理しやすい
Linux / Windows / S3 で UID / GID をそろえたことで、所有者の見え方を比較しやすい
Internet -> S3 Endpoint -> FSx for OpenZFS の流れを明示でき、外部接続点を限定しやすい
Windows 11 の匿名 UID / GID を事前設定したことで、NFS 検証時の混乱を減らせる

今後の課題

今回の検証で動作確認はできたものの、実運用に向けては以下の観点を追加で詰める必要があります。

各クライアントからの接続制限と権限設計

Linux / Windows 11 / S3 Endpoint のそれぞれについて、どの経路・どの送信元のみ許可するかを明確化し、セキュリティグループ・NACL・VPN 側の制御を最小権限で再設計する必要があります。あわせて、NFS エクスポートポリシーやディレクトリ単位のアクセス権を整理し、クライアントごとの操作可能範囲を定義することが課題です。
mount 可能な環境の制御方式

どの環境から mount を許可するかを、ネットワーク境界（サブネット / VPN / 送信元 CIDR）と端末要件（運用端末・踏み台・サーバーロール）で制御する方針を固める必要があります。運用面では、許可済みクライアント一覧の管理、変更申請フロー、定期棚卸しを含めたガバナンス設計も必要です。
その他のセキュリティ観点

監査ログ（接続元、失敗イベント、権限エラー）の収集、異常アクセスの検知、定期的な権限レビュー、バックアップ / リストア手順の検証、インシデント時の切り分け手順を整備する必要があります。特に、UID / GID を統一した構成では「誰が実行した操作か」を補完する仕組みを別途用意することが重要です。

まとめ

FSx for OpenZFS の検証では、ストレージ本体の設定だけでなく、クライアント側の UID / GID 設計 を早めに決めることがかなり重要でした。

今回の構成では、以下を統一したのがポイントです。

検証用 VPC は public / private / protected の 3 サブネットで分離
On-Premises と VPC の間は VPN で接続
Internet からの接続先は S3 Endpoint のみに限定
FSx for OpenZFS と Linux クライアントは protected サブネットに配置
Linux クライアントは protected サブネットに配置
Windows 11 は AnonymousUid = 1000、AnonymousGid = 1000
S3 エンドポイント側の POSIX も uid=1000、gid=1000

FSx for OpenZFS を複数クライアントから扱う場合は、まずネットワーク到達性、その次に UID / GID の統一という順で見ると、トラブルシュートしやすいと思います。