Cloud Service
Amazon FSx
Windows、Lustre、NetApp ONTAP、OpenZFS の各ファイルシステムをフルマネージドで提供する高性能共有ストレージサービス。
- 1.4種類のファイルシステムを選べ、用途に応じた高性能な共有ストレージをマネージドで利用できる。
- 2.プロビジョニング、パッチ適用、バックアップ、フェイルオーバーなどの運用を AWS が肩代わりする。
- 3.オンプレミスのファイルサーバや HPC ワークロードを、互換性を保ったまま AWS へ移行しやすい。
Amazon FSx は、業界標準のファイルシステムをフルマネージドで提供するサービスです。利用者はストレージインフラの構築や日常運用に煩わされることなく、共有ファイルストレージや高性能な並列ファイルシステムを必要なときに立ち上げられます。
解決する課題
オンプレミスでファイルサーバや並列ファイルシステムを運用すると、ハードウェアの調達、OS やファイルシステムのパッチ適用、バックアップ、容量拡張、冗長構成の設計と監視といった作業が継続的に発生します。これらは専門知識を要し、運用負荷とコストの両面で重荷になりがちです。
また、Windows アプリケーションが依存する SMB 共有や Active Directory 連携、HPC ワークロードが要求する数百 GB/秒級のスループット、既存の NetApp や ZFS 環境との互換性など、ワークロードごとに求められるファイルシステムの性質は大きく異なります。汎用のオブジェクトストレージやブロックストレージだけでは、これらの要件をそのまま満たせません。
Amazon FSx は、用途別に最適化された 4 種類のファイルシステムをマネージドで提供することで、こうした課題に応えます。利用者はファイルシステムの「種類」を選ぶだけでよく、その下にあるサーバ群、ストレージ、レプリケーション、フェイルオーバーの仕組みは AWS が管理します。
主要概念と用語
- FSx for Windows File Server: SMB プロトコルと Windows NTFS をネイティブに提供するファイルシステム。Active Directory 連携、アクセス制御リスト、シャドウコピーなど Windows 由来の機能を利用でき、Windows ベースのアプリケーションやファイル共有の移行先として使われる。
- FSx for Lustre: HPC、機械学習、メディア処理などで使われる高性能な並列ファイルシステム。多数のクライアントから並列に高いスループットでアクセスでき、Amazon S3 と連携してデータセットを読み書きできる。
- FSx for NetApp ONTAP: NetApp の ONTAP をベースとするファイルシステム。NFS、SMB、iSCSI に対応し、スナップショット、レプリケーション、データ圧縮や重複排除といった ONTAP の機能を AWS 上で利用できる。
- FSx for OpenZFS: OpenZFS をベースとし、主に NFS でアクセスする高性能ファイルシステム。スナップショットやクローン、圧縮など ZFS の機能を備える。
- 単一 AZ / マルチ AZ: 可用性の配置オプション。単一 AZ は 1 つのアベイラビリティゾーンに配置し、マルチ AZ は複数の AZ にまたがって冗長化し自動フェイルオーバーを提供する(対応の有無や挙動はファイルシステムの種類により異なる)。
- スループットキャパシティ: ファイルシステムが処理できる性能の指標。種類によりプロビジョニング方式や呼称が異なる。
- データリポジトリ連携: FSx for Lustre が S3 のデータをファイルシステムに紐づけ、遅延ロードや書き戻しを行う仕組み。
- バックアップ: ファイルシステムの内容を取得する増分バックアップ。多くの種類で自動・手動の両方に対応する。
仕様・制限・クォータ
FSx は対応プロトコル、性能特性、可用性オプションがファイルシステムの種類ごとに異なります。代表的な傾向は次のとおりです。
- 対応プロトコル: Windows File Server は SMB、Lustre は Lustre クライアント(POSIX 互換)、NetApp ONTAP は NFS / SMB / iSCSI、OpenZFS は主に NFS に対応する。
- 容量とスループット: 種類により、後から拡張できる範囲やスループットのプロビジョニング方法が異なる。一般に容量とスループットは独立して、あるいは段階的に変更できるが、変更の頻度や反映時間には制約がある。
- 可用性: マルチ AZ に対応する種類では、複数 AZ にまたがる冗長構成と自動フェイルオーバーが提供される。単一 AZ 構成は可用性が下がる代わりにコストを抑えられる。
- リージョンとクォータ: 利用可能なリージョンや、アカウントあたりのファイルシステム数・バックアップ数などにはサービスクォータが設定される。多くは引き上げ申請が可能。
具体的な上限値やプロビジョニング単位は変動し、種類とリージョンにも依存するため、設計時には最新の公式ドキュメントとサービスクォータ画面で確認してください。
内部の仕組み
FSx はファイルサーバやストレージのクラスタを AWS のマネージドサービスとして抽象化します。利用者は VPC 内のサブネットにファイルシステムを作成し、エンドポイント(または DNS 名)を通じてアクセスします。背後にあるサーバ群、ストレージボリューム、レプリケーション、パッチ適用は AWS が管理します。
マルチ AZ に対応する種類では、プライマリとスタンバイの構成を複数の AZ にまたがって配置し、プライマリに障害が起きると自動的にスタンバイへフェイルオーバーします。クライアントは同じ DNS 名を使い続けられるため、フェイルオーバーはアプリケーションから見て概ね透過的です。
FSx for Lustre は、メタデータを扱うコンポーネントとデータを格納するコンポーネントを分離し、多数のクライアントからの並列アクセスを高いスループットでさばく設計になっています。S3 と連携する構成では、ファイルが初めてアクセスされたときに S3 から遅延ロードされ、変更を S3 へ書き戻すこともできます。
データの耐久性は、種類ごとに増分バックアップやスナップショット、レプリケーションといった仕組みで担保されます。バックアップは内部的に Amazon S3 へ保存される設計が一般的です。
設計パターン / ベストプラクティス
- ワークロードに合った種類を選ぶ: Windows アプリと SMB 共有なら Windows File Server、HPC や機械学習の高スループット要件なら Lustre、既存 NetApp 資産や多プロトコル要件なら NetApp ONTAP、Linux 系で ZFS の機能やコスト効率を重視するなら OpenZFS を検討する。
- 可用性要件で AZ 構成を決める: 本番の共有ストレージはマルチ AZ を基本とし、開発・検証や再生成可能なデータには単一 AZ を選んでコストを抑える。
- Lustre と S3 を組み合わせる: 大規模データセットは S3 を永続層、Lustre を高速な作業層として使い分け、処理中だけ Lustre を立ち上げて結果を S3 に書き戻すパターンが有効。
オンプレミスからの移行では、現行環境のプロトコル(SMB、NFS、Lustre など)と機能要件をそのまま満たせる種類を選ぶと、アプリケーション側の改修を最小化できます。NetApp や ZFS を既に運用している場合は、対応する FSx を選ぶことで使い慣れた機能を踏襲できます。
運用・監視
FSx のメトリクスは Amazon CloudWatch に発行され、スループット、IOPS、ストレージ使用量、接続数などを監視できます。性能が頭打ちになっていないか、容量が逼迫していないかを継続的に確認し、必要に応じてスループットや容量を引き上げます。
バックアップは自動バックアップのスケジュールを設定でき、保持期間も指定できます。重要な操作の前には手動バックアップを取得し、復元手順を事前に検証しておくと安心です。Active Directory 連携を使う構成では、ディレクトリ側の可用性や認証経路の健全性も運用対象に含めます。
メンテナンスウィンドウを設定しておくと、パッチ適用などのマネージド作業がビジネス影響の小さい時間帯に行われるよう調整できます。
コスト
料金は主に、プロビジョニングしたストレージ容量、スループット(性能)キャパシティ、バックアップの保管量によって決まります。種類や可用性オプション(単一 AZ かマルチ AZ か)、ストレージの種類によっても単価が変わります。
コストを抑えるには、ワークロードに見合った容量と性能を選び、過剰なプロビジョニングを避けることが基本です。再生成可能なデータには単一 AZ を、一時的な処理には Lustre のように必要なときだけ立ち上げる使い方を検討します。バックアップの保持期間も保管コストに直結するため、要件に合わせて見直します。
スループットや容量を大きく取りすぎると、使われない性能に対して料金が発生し続けます。CloudWatch の利用状況を見ながら、実際の需要に合わせて調整してください。
正確な単価はリージョンや種類、時期によって変動するため、見積もりは公式の料金ページや料金計算ツールで確認してください。
セキュリティ
保存データはサービスが管理する仕組み、または AWS KMS の鍵で暗号化できます。転送中のデータも、プロトコルや構成に応じて暗号化に対応します。ファイルシステムは VPC 内に配置し、セキュリティグループで通信を制御することで、ネットワーク到達範囲を限定できます。
アクセス制御は種類により異なります。Windows File Server や NetApp ONTAP の SMB は Active Directory と連携し、NTFS のアクセス制御リストでファイル単位の権限を管理できます。NFS では POSIX のパーミッションやエクスポートポリシーを用います。AWS リソースとしての操作権限は IAM で制御し、最小権限の原則に従って付与します。
Well-Architected の観点
パフォーマンス効率の柱では、ワークロードの特性に合わせて種類とスループットを選ぶことが重要です。高スループットが必要な HPC や機械学習には Lustre、汎用の共有には Windows File Server や OpenZFS というように、要件に最も適した選択をすることで無駄なく性能を引き出せます。
信頼性の柱では、マルチ AZ 構成による自動フェイルオーバー、自動バックアップ、レプリケーションを活用して、障害やデータ消失に備えます。復元手順を事前に検証し、目標復旧時点と目標復旧時間を満たせるバックアップ戦略を設計します。マネージドサービスとしてパッチ適用やフェイルオーバーが自動化される点も、信頼性の確保に寄与します。
試験で問われるポイント
- 4 種類のファイルシステム(Windows File Server、Lustre、NetApp ONTAP、OpenZFS)と、それぞれの代表的な用途・対応プロトコルの対応関係。
- Windows アプリケーションの SMB 共有や Active Directory 連携が必要なら FSx for Windows File Server を選ぶ。
- HPC、機械学習、高スループットの並列処理には FSx for Lustre を選び、S3 と連携できる点を押さえる。
- 既存 NetApp 環境や多プロトコル(NFS / SMB / iSCSI)要件には FSx for NetApp ONTAP が適する。
- マルチ AZ 構成が自動フェイルオーバーによる高可用性を提供する点。
- 汎用の Linux 向け共有ファイルシステムである Amazon EFS との使い分け(用途・性能・互換性の違い)。
関連サービス・比較
汎用の共有ファイルストレージとしては Amazon EFS がよく比較対象になります。EFS は Linux 向けの NFS をフルマネージドで提供し、容量が自動拡張される手軽さが特徴です。一方 FSx は、特定のファイルシステム(Windows、Lustre、ONTAP、OpenZFS)の機能や互換性、性能を必要とするワークロード向けです。
| 観点 | Amazon FSx | Amazon EFS |
|---|---|---|
| 主な用途 | Windows共有やHPCなど特定要件のワークロード | Linux向けの汎用共有ストレージ |
| 対応プロトコル | 種類によりSMB、Lustre、NFS、iSCSI | NFS |
| 容量管理 | 種類によりプロビジョニングまたは拡張 | 使用量に応じて自動拡張 |
| 互換性 | Windows、Lustre、NetApp、ZFSの各機能を踏襲 | Linux標準のNFSに最適化 |
ハンズオン / CLI例
次の例は、AWS CLI で FSx for Windows File Server のファイルシステムを作成し、一覧を確認するものです。実際の値(サブネット、セキュリティグループ、ディレクトリ、容量、スループットなど)は環境に合わせて置き換えてください。
# FSx for Windows File Server を作成
aws fsx create-file-system \
--file-system-type WINDOWS \
--storage-capacity 300 \
--subnet-ids subnet-xxxxxxxx \
--security-group-ids sg-xxxxxxxx \
--windows-configuration '{
"ActiveDirectoryId": "d-xxxxxxxxxx",
"ThroughputCapacity": 32,
"DeploymentType": "MULTI_AZ_1",
"PreferredSubnetId": "subnet-xxxxxxxx"
}'
# 作成したファイルシステムの一覧を確認
aws fsx describe-file-systems
AWS Service
Amazon FSxを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
ストレージ
比較で見る軸
クラウド: AWS / カテゴリ: ストレージ / 難易度: intermediate
導入後に効く点
プロビジョニング、パッチ適用、バックアップ、フェイルオーバーなどの運用を AWS が肩代わりする。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- ストレージ
- 難易度
- intermediate
- 関連資格
- SAA-C03
- 設計柱
- performance / reliability
判断チェックリスト
- 自社の用途が「ストレージ / performance」に近いか確認する。
- 強みである「4種類のファイルシステムを選べ、用途に応じた高性能な共有ストレージをマネージドで利用できる。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。