EFS vs FSx vs EBS ファイル共有を要件から決める早見表と判断フロー

この記事でわかること
まず結論の早見表
1. ざっくり早見表
最初に押さえる選定の判断フロー
1. ディスクか共有かを最初に決める
2. 共有なら次にプロトコルと互換性で決める
EBSを選ぶべき要件と落とし穴
1. EBSが向いている典型パターン
2. 試験でも混乱しやすいポイント
EFSを選ぶべき要件と設計のコツ
FSxを選ぶべき要件とタイプ別の選び方
要件別の具体例で選び方を固める
SAA-C03の観点で押さえる整理ポイント
1. 迷いを減らすキーワードの対応表
体系的に学ぶなら Udemy講座も選択肢になる
まとめ

この記事でわかること

EFS・FSx・EBSは、どれも「EC2のデータ置き場」として登場しますが、設計の前提がまったく違います。ここでは暗記ではなく、要件から自然に選べる考え方に落として整理します。SAA-C03でサービス名が出てきても、設計意図がつながっていれば迷いにくくなります。

SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇

SAA-C03対策｜Udemyのおすすめ講座を見る

まず結論の早見表

最初に、試験でも実務でも迷いがちな「何を軸に決めるか」を1枚にまとめます。

ざっくり早見表

軸	EBS	EFS	FSx
形	ブロックストレージ	NFSのマネージド共有ファイル	用途別のマネージドファイルシステム
典型用途	OS領域、DB、アプリの永続ディスク	Linux系の共有ディレクトリ、複数AZからの共有	Windows共有、HPC、高機能NAS互換など
共有	基本は1台にアタッチ（条件付きで複数も可）	複数から同時マウントが前提	複数から同時アクセスが前提
AZの考え方	特定AZに属する	Regionalなら複数AZ冗長、One Zoneも選べる	サービスごとの構成に従う
プロトコル	OSから見るとディスク	NFS	SMB、Lustre、NFSなどタイプで変わる
ざっくり判断	「サーバーの内蔵ディスク枠」	「Linuxで使う共有フォルダ」	「Windows共有や高性能やNAS機能が必要」

EBSは作成時に特定のAvailability Zoneに置かれ、同一AZのEC2にアタッチして使う、という前提が強いです。
EFSはファイルシステムとして複数クライアントからの同時アクセスが前提で、Regionalタイプは複数AZに冗長化して保存できます。
FSxは「ファイルシステムの種類ごとに最適化されたマネージドサービス」で、Windows互換のSMBや、HPC向けLustreなど、目的で選べるのが特徴です。

最初に押さえる選定の判断フロー

ここは考え方の芯になります。選択肢を増やすより、切り分けの順番を固定すると速くなります。

ディスクか共有かを最初に決める

単一サーバーのディスクとして使いたい
まずEBSを疑います。OSやミドルウェア、DBのデータ領域など「インスタンスにぶら下がる永続ディスク」の文脈はEBSが素直です。
複数サーバーから同じファイルを同時に触りたい
ファイル共有の領域です。EFSかFSxが基本線になります。

共有なら次にプロトコルと互換性で決める

Linux中心でNFSの共有がほしい → まずEFS
Windowsのファイル共有がほしい、SMBが必要 → FSx for Windows File Server
FSx for WindowsはSMBをネイティブにサポートし、Active Directory連携などWindows前提の要件を素直に満たせます。
HPCや機械学習など、並列アクセスでとにかく速い共有がほしい → FSx for Lustre
Lustreは高性能ファイルシステムとして設計されており、FSx for LustreはS3と連携して「S3のオブジェクトをファイルのように見せる」構成も取りやすいです。
NASの高度な機能がほしい、スナップショットやクローン、階層化など運用込みで楽にしたい → FSx for NetApp ONTAP / FSx for OpenZFS
ONTAPはスナップショット・クローン・レプリケーションのような運用機能が整理されていて、OpenZFSもスナップショットやクローンといったZFSの強みをマネージドで使えます。

EBSを選ぶべき要件と落とし穴

EBSは「永続ブロックストレージ」です。設計上は“サーバーのディスク”として考えるとブレにくいです。

EBSが向いている典型パターン

EC2のルートボリュームやアプリのデータ領域
RDBやNoSQLをEC2上で運用していて、低レイテンシーのディスクI/Oが重要
スナップショットでバックアップを取り、必要なら復元する運用を組みたい

EBSはボリューム作成時にAvailability Zoneに配置され、そのAZ内で自動的に複製される設計です。つまり「AZをまたいで1つのEBSをそのまま共有する」は基本的にできません。

試験でも混乱しやすいポイント

EBSはファイル共有ではなくブロック

EBSはOSから見るとブロックデバイスです。複数台で同じ“ディスク”を雑に共有し始めると、ファイルシステムが壊れる方向に進みがちです。
「複数インスタンスで同じデータを共有したい」という要件が出た時点で、まずEFSやFSxに思考を切り替える方が安全です。

HDD系ボリュームは順次I/Oが得意

EBSのボリュームタイプは、SSD系とHDD系で得意分野が違います。HDDのst1やsc1は「大きな順次I/O」で性能が出る前提があるので、用途がズレると期待した性能になりません。

gp3は容量と性能を分けて考えられる

設計の現場では、gp3を基準に「IOPSとスループットを要件として明示し、容量とは切り離して決める」方が説明しやすいです。gp3はベース性能と拡張上限が整理されています。

EFSを選ぶべき要件と設計のコツ

EFSは「マネージドなNFS共有フォルダ」として捉えるとイメージしやすいです。Linux系ワークロードで、複数のEC2やコンテナから同じファイルを触る構成に強いです。

EFSが向いている典型パターン

複数のEC2から同じコンテンツを参照するWebサーバー群
ECS/EKSで共有の永続ボリュームがほしい
バッチ処理やジョブで共通の作業ディレクトリを持ちたい
アプリがNFSを前提にしている

RegionalとOne Zoneの考え方

EFSにはファイルシステムタイプとしてRegionalとOne Zoneがあります。Regionalは複数AZに冗長化してデータを保存する設計で、可用性を重視する一般的な構成で選ばれやすいです。
One Zoneは単一AZに置くタイプで、マウントターゲットの制約など“AZを意識した設計”になります。

パフォーマンス設計で迷ったら

EFSにはパフォーマンスモードとスループットモードがあります。

パフォーマンスモードは汎用と最大I/O
汎用は低レイテンシーでデフォルト、最大I/Oは高い並列性向けですがレイテンシーが上がる傾向があるため、まず汎用を基準に考えるのが安全です。
スループットモードはBursting、Provisioned、Elastic
ワークロードの特性に合わせて選べます。高スループット・高IOPSが必要な場合、Regional＋汎用＋Elasticが推奨されるケースがある、という指針が公式にもあります。

ここでのコツは「数値暗記」ではなく、EFSは容量やクレジット、モードで挙動が変わるという構造を理解しておくことです。問題文に「急にアクセスが増える」「読取りが多い」「安定したスループットが必要」などが出てきたら、モードの話だと気づけます。

アクセス制御はAccess Pointが便利

EFSはLinuxのパーミッション設計が絡むので、アプリごとにルートディレクトリやPOSIXユーザーを固定して見せたい時にAccess Pointが効きます。IAMポリシーと組み合わせて「このアプリはこのアクセスポイント経由だけ」と縛る発想も取りやすいです。

FSxを選ぶべき要件とタイプ別の選び方

FSxは一言でいうと「目的に合わせてファイルシステムそのものを選ぶ」サービスです。EFSが“汎用NFS共有”だとすると、FSxは“用途特化のファイル共有”です。

FSx for Windows File Serverが向く要件

WindowsクライアントやWindowsサーバーからの共有を素直に作りたいならこれです。SMBをネイティブにサポートし、運用もマネージドで寄せられます。

よくある設計例は次のとおりです。

社内ファイルサーバーをAWSに寄せたい
WindowsアプリがSMB共有パス前提で動く
Active Directory連携やWindows ACLを活かしたい

FSx for Lustreが向く要件

「共有ストレージがボトルネックで計算が回らない」系はLustreが候補に上がります。特にS3との統合が強く、S3上のデータセットをファイルとして扱いながら高速に処理し、結果をS3へ戻すような構成と相性が良いです。

機械学習の学習データ読み込みが重い
大規模解析、シミュレーションなど並列アクセスが前提
“一時的に超高速な作業領域”を作って、成果物はS3へ、のパターン

FSx for NetApp ONTAPが向く要件

NAS運用の「あると助かる」が詰まっているタイプです。スナップショット・クローン・レプリケーションなどの運用機能や、自動階層化のような仕組みが整理されていて、既存のNAS運用思想を持ち込みやすいです。

きめ細かいデータ管理、バックアップ運用を楽にしたい
NFSだけでなくSMBなど複数プロトコルを扱いたい要件がある
オンプレNASの移行やハイブリッド運用の延長で考えたい

FSx for OpenZFSが向く要件

ZFS系の強みであるスナップショットやクローンを、マネージドで使いたい時に候補になります。開発や検証で「本番データ相当を素早く複製して試す」など、クローン文化と相性が良いです。

要件別の具体例で選び方を固める

ここからは、問題文や要件定義で出てきそうな言い回しを、設計の言葉に翻訳する練習です。暗記よりも、読み替えができるようになるのが狙いです。

複数AZのWebサーバーで画像を共有したい

ありがちな要件
Auto Scalingで増減する複数EC2から同じ画像や静的ファイルを参照したい。片方のAZが落ちても継続したい。
まず考える答え
EFSのRegionalタイプが自然です。複数AZに冗長化して保存でき、共有ファイルとして扱えます。
設計での一言
「共有だからEFS、AZまたぎの可用性が要るからRegional」の順で説明できます。

Windowsの業務アプリが共有フォルダ前提で動く

ありがちな要件
\\server\share のようなSMBパス前提。アクセス権もADとACLで管理したい。
まず考える答え
FSx for Windows File Server。SMBネイティブで、Windowsの世界観を保ったまま寄せられます。
設計での一言
「プロトコルがSMB指定ならEFSではなくFSx Windows」と切れます。

機械学習の前処理が遅い共有ストレージが詰まっている

ありがちな要件
複数のGPUインスタンスで並列に読み書きしていて、NFS共有だと追いつかない。データはS3にある。
まず考える答え
FSx for Lustre。S3と統合し、S3のデータをファイルとして見せながら高速処理ができます。
設計での一言
「S3上のデータセット＋超高速共有」はLustreの得意分野、という理解が効きます。

DBをEC2で動かすディスクI/Oが重要

ありがちな要件
低レイテンシーで安定したI/Oが欲しい。ストレージはインスタンスと運命共同体でいい。
まず考える答え
EBS。ブロックストレージとしてEC2にアタッチし、AZ内複製で耐久性を担保する設計です。
設計での一言
「共有ではない、単一サーバーのディスク要件」ならEBSが基本線です。

アプリごとに同じEFSでも見せる場所と権限を分けたい

ありがちな要件
1つの共有基盤だが、アプリAは/appAだけ、アプリBは/appBだけ触らせたい。運用で事故を減らしたい。
まず考える答え
EFS Access Pointで“アプリごとの入口”を作る。IAMと組み合わせて縛る。

SAA-C03の観点で押さえる整理ポイント

SAA-C03では、EBS・EFS・FSxはいずれも試験範囲のストレージサービスとして扱われます。
ここで大事なのは「名前を覚える」より、「設計判断の軸がズレない」ことです。

迷いを減らすキーワードの対応表

「アタッチ」「ボリューム」「AZが同じ」 → EBSの匂いが強い
「マウント」「NFS」「共有ディレクトリ」 → EFSをまず疑う
「SMB」「Windows互換」「AD」 → FSx for Windows
「HPC」「並列」「S3のデータを高速処理」 → FSx for Lustre
「スナップショット」「クローン」「NAS機能」 → FSx ONTAP / OpenZFS

この対応が頭に入ると、長い問題文でも「まずどの世界の話か」を早めに特定できます。

体系的に学ぶなら Udemy講座も選択肢になる

独学で公式ドキュメントを読める状態が理想ですが、最初は「サービスの比較軸」を自分で作るのが難しいことがあります。そういう時は、SAA-C03向けにストレージを含む主要サービスを横断して解説するUdemy講座を1本持っておくと、知識が線でつながりやすくなります。

選ぶ基準はシンプルで、次の3点を満たすものが扱いやすいです。

EBS・EFS・FSxを「いつ使うか」の判断から説明している
ハンズオンでマウントや構成の流れが見える
問題演習で、要件文からの読み替えを練習できる

講座はたくさんありますが、最終的には「自分が混乱しやすいところを言語化してくれる説明か」で相性が決まります。レビューは点数よりも、どの章が良かったかの具体コメントを見る方が外しにくいです。