Amazon FSx for NetApp ONTAP(FSx for ONTAP/FSxN)のMulti-AZファイルシステムを設計するときは、1ファイルシステムあたり最大50ルートという制限に注意が必要です。
特にVPC Sharingでシステムごとにサブネットやルートテーブルを分離していると、システム数ではなくFSxに関連付けるルートテーブル数が増え、想定より早く上限に達する可能性があります。
確認日:2026年9月14日。AWS公式のクォータ表にあるルート数の式をもとに、Multi-AZ環境の設計例を示します。
FSx for ONTAPのルート数の計算式
ルート数は次の式で計算できます。
ルート数 =(1 + ファイルシステム内のSVM数)
× FSxファイルシステムに関連付けたルートテーブル数
ここでいうルートテーブル数は、単にVPC内に存在する全ルートテーブル数ではありません。FSxクライアントが存在するサブネットで使用され、FSxファイルシステムに関連付ける必要があるルートテーブルが対象です。
計算例
| SVM数 | 関連ルートテーブル数 | 計算 | ルート数 |
|---|---|---|---|
| 1 | 10 | (1+1)×10 | 20 |
| 2 | 10 | (1+2)×10 | 30 |
| 4 | 10 | (1+4)×10 | 50 |
| 1 | 25 | (1+1)×25 | 50 |
SVMが1つでも、ルートテーブルが25個あれば上限に到達します。逆にクライアントサブネットが100個あっても、同じルートテーブルを共用していれば、ルートテーブル数は1として扱われます。
サブネット数ではなくルートテーブルの実体数を数える
VPC SharingでSubnet A、B、Cを各アカウントへ共有するケースを考えます。
パターン1:3サブネットで同じルートテーブルを共用
Subnet A ─┐
Subnet B ─┼─ Route Table 1
Subnet C ─┘
この場合、FSxに関連付けるルートテーブルは1つです。SVMが1つなら、ルート数は(1+1)×1=2です。
パターン2:サブネットごとに別のルートテーブルを使用
Subnet A ─ Route Table 1
Subnet B ─ Route Table 2
Subnet C ─ Route Table 3
この場合、FSxに関連付けるルートテーブルは3つです。同じ宛先・同じ内容のルートが設定されていても、ルートテーブルの実体が異なるため別々に数えます。SVMが1つなら、ルート数は(1+1)×3=6です。
なぜFSxがルートテーブルへルートを追加するのか
Multi-AZのFSx for ONTAPでは、管理およびSVMのデータアクセス用のフローティングIPアドレスへ通信するため、Amazon FSxが関連付けられたVPCルートテーブルへ必要なルートを自動的に追加・更新します。
フェイルオーバー時には適切なファイルサーバーへ向くように経路が更新されます。そのため、FSxを利用するクライアントサブネットのルートテーブルをファイルシステムへ関連付ける必要があります。
50ルート制限への対策
1. 複数サブネットでルートテーブルを共用する
最も直接的な対策です。システム単位でサブネットを分離したままでも、FSxへの経路要件が同じサブネット群でルートテーブルを共通化すれば、FSxに関連付けるルートテーブル数を減らせます。
ただし、ルートテーブルの共用によってシステム間の分離要件を損なわないか、他の宛先ルートやTGW経路も含めて確認してください。
2. SVM数を必要最小限にする
SVMを増やすほど、ルートテーブル1つあたりに必要なルート数も増えます。テナント分離、管理境界、プロトコル要件を整理し、不要にSVMを細分化しない設計が有効です。
3. FSxファイルシステムを分割する
ルートテーブルの共用が難しい場合は、システム群や業務単位でFSxファイルシステム自体を分ける方法があります。ただし、コスト、容量効率、運用負荷、バックアップ、監視対象が増えるため、最後の選択肢として比較します。
4. 設計段階で将来分を試算する
現在値だけでなく、将来のSVM数とルートテーブル数を式に入れます。上限50ちょうどまで使い切る設計ではなく、新規システム追加や一時的な構成変更を考慮して余裕を持たせるのが安全です。
VPC Sharing環境での設計ポイント
- サブネットをシステム単位で分けても、ルートテーブルまで必ず分ける必要があるか再検討する
- FSxを利用するサブネットと利用しないサブネットを明確にする
- VPC所有者と参加アカウントの責任分界を決める
- ルートテーブルの追加時にFSxの関連付け変更も行う運用手順を用意する
- SVM追加時に50ルート制限を再計算する
設計レビューで使う試算例
現在SVMが2つ、関連ルートテーブルが12個なら、ルート数は36です。この構成にルートテーブルを3個追加すると45ですが、その後にSVMを1つ追加すると60となり、50を超えます。増設を別々の担当者が判断すると、組み合わせた結果を見落としやすくなります。
設計書には「現在のSVM数」「将来のSVM数」「現在の関連ルートテーブル数」「追加予定数」を並べて記載し、変更申請のたびに組み合わせを再計算してください。上記の数値は計算例であり、性能や接続数の実測値ではありません。
接続できない場合はタグと関連付けも確認する
数が上限内でも、クライアントのサブネットが想定したルートテーブルを使用していなければアクセスできないことがあります。またMulti-AZでは、FSxがルートを管理するためのAmazonFSx=ManagedByAmazonFSxタグの欠落にも注意します。
上限対策として、利用中のSVMやFSx管理ルートをその場で削除するのは避けてください。接続先と影響範囲を整理し、変更後の通信・フェイルオーバー確認まで含めて実施計画を作ります。
まとめ
FSx for ONTAPの最大50ルート制限は、サブネット数やシステム数をそのまま数えるものではありません。計算に使うのは、SVM数と、FSxに関連付けたルートテーブルの実体数です。
VPC Sharingで多数のサブネットを払い出す場合でも、要件が共通するサブネットでルートテーブルを共用すれば、制限への到達を抑えられます。将来のシステム数とSVM数を先に置き、ルートテーブル設計へ反映することが重要です。
参考資料
関連記事
移行ネットワーク全体はAWS MGNの閉域構成、S3のアクセス経路はS3 VPCエンドポイントの併用を参照してください。