Amazon EFS徹底解説：Google Cloud Filestore・Azure Files比較で学ぶ「共有ファイルストレージ設計」の実務
はじめに
Amazon EFS（Amazon Elastic File System）は、AWS が提供するフルマネージドの共有ファイルストレージです。複数の EC2 インスタンスやコンテナ、サーバーレス実行基盤から同じファイルシステムを同時にマウントでき、需要に応じてペタバイト規模まで拡張できることが公式に案内されています。AWS は EFS について、幅広いワークロードに必要なスループット、IOPS、低レイテンシを提供し、並列アクセスを前提にした設計であると説明しています。
このテーマが役に立つのは、たとえば次のような方です。まず、複数サーバーから同じファイル群を共有したいインフラ担当の方。次に、Kubernetes やコンテナ基盤で ReadWriteMany の共有ストレージを安全に扱いたいプラットフォーム担当の方。そして、AWS・GCP・Azure をまたいで「共有ファイルストレージをどう選ぶべきか」を整理したいアーキテクトの方にも向いています。Google Cloud の Filestore は、複数インスタンスから同時にアクセスできる永続ファイルストレージとして提供され、GKE PersistentVolume を複数ノードから read-write-many で利用できることが説明されています。Azure Files も SMB と NFS の両プロトコルを提供し、複数ポッドから共有マウントできることが AKS 向けドキュメントに明記されています。
最初に結論を申し上げると、Amazon EFS は AWS 上で共有ファイルシステムを素直に使いたい 場面で、とても自然な選択肢です。一方で、GCP の Filestore はティア設計とリージョナル構成が分かりやすく、Azure Files は SMB/NFS と冗長性の組み合わせで柔軟に設計しやすいです。つまり、どれが一番優れているかというより、どのクラウドで、どの共有ファイル要件を、どの運用責任で持ちたいか で選ぶのが失敗しにくいです。
1. Amazon EFSとは何か
Amazon EFS は、AWS の共有ファイルストレージサービスで、EC2 をはじめとする複数のコンピュートから同じファイルシステムへ同時にアクセスできます。AWS 公式では、EFS がサーバーレスにスケールし、ペタバイト級まで拡張でき、広範なワークロードに必要な低レイテンシと高スループットを提供すると説明しています。
ここで大切なのは、EFS を「EBS を共有化したもの」と考えないことです。EBS が基本的に単一インスタンス向けのブロックストレージであるのに対して、EFS は 最初から共有ファイルシステム として設計されています。つまり、WordPress の共有コンテンツ、アプリケーションの共通アセット、ML 学習データ、コンテナの共有ワークスペース、レンダリングや解析の中間ファイル置き場など、複数ノードからの並列アクセスが必要な用途に向いています。AWS のドキュメントでも、EFS は Amazon EC2 から VPC 内でマウントして使う前提で説明されています。
また、EFS には Regional と One Zone の2つのファイルシステムタイプがあります。Regional は複数の Availability Zone にまたがって冗長保存され、1つ以上の AZ が利用不能になってもデータへの継続アクセスを支えることが公式に説明されています。一方 One Zone は単一 AZ に保存する構成で、可用性要件よりコスト最適化を重視する場面に向きます。AWS 自身も、通常は Regional を推奨しています。
2. EFS の中核価値：共有・自動拡張・マネージド運用
Amazon EFS のいちばん大きな魅力は、共有ファイルシステムを、容量計画の細かな手作業なしで扱いやすいことです。AWS は、EFS がサーバーレスにスケールすること、そして Elastic Throughput を含む複数のスループットモードを提供することを案内しています。Elastic Throughput では、読み書き需要に応じてスループットが自動で変化し、事前に性能値を詰めなくても使い始めやすいです。
現場目線では、特に次の3つが効きます。
第一に、複数ノードから同時アクセスできることです。Web サーバーが増減しても同じファイルを参照でき、Kubernetes でも共有ストレージとして扱いやすいです。これは Google Filestore や Azure Files も同様の価値を持っていますが、AWS 上での自然さでは EFS がとても強いです。
第二に、自動拡張しやすいことです。容量が足りなくなるたびにストレージを拡張する運用を避けやすく、アプリケーション側は「どのくらい使うか」を大きく気にしすぎずに済みます。もちろん料金設計は必要ですが、物理ディスク感覚の運用からはかなり離れられます。
第三に、共有ファイルサーバーの運用そのものを持たなくてよいことです。NFS サーバーを自前で建てて HA 構成を組み、障害時に切り戻し、容量を監視し、パッチを当てる、という世界から離れやすいのは大きな利点です。EFS はこの「ファイルサーバーの面倒」をかなり減らしてくれます。
3. スループットモードと性能設計
EFS では、スループットモードとして Elastic、Provisioned、Bursting が提供されています。AWS の性能仕様ドキュメントでは、それぞれのモードで使い方が異なり、Elastic Throughput は需要に応じて自動調整される一方、Provisioned は必要なスループットを事前に確保できる、と整理されています。
実務では、次のように考えると分かりやすいです。
Elastic Throughput が向くケース
- アクセスパターンが読みづらい
- 初期構築段階で性能見積もりに自信がない
- 少人数チームで、まずは運用負荷を下げたい
Provisioned Throughput が向くケース
- 高スループットが安定して必要
- 性能要件を明示したい
- コストより性能の確実性を優先したい
Bursting Throughput を意識するケース
- 古い設計資産や既存構成を引き継いでいる
- バースト特性を理解した上で運用できる
AWS は「ほとんどのワークロードでは、General Purpose と Elastic throughput を推奨する」と案内しています。つまり、新規構築ではまず General Purpose + Elastic Throughput を第一候補にしてよいです。
また、クォータ情報では、One Zone の Elastic / Provisioned で既定の読み取り 3 GiBps、書き込み 1 GiBps が示されており、リージョンや構成によって上限が変わることもあります。さらに、2025年の更新履歴では、一部リージョンで Elastic Throughput の最大読み取り性能が 60 GiBps、その他でも 20 GiBps へ引き上げられたことが記録されています。性能は比較的動きやすいので、設計時には最新クォータ確認が大切です。
4. GCP Filestoreとの比較
Google Cloud Filestore は、Google の共有ファイルストレージサービスです。公式概要では、Filestore が複数アプリケーションインスタンスから同時にアクセスできる永続ファイルストレージであり、特に GKE で read-write-many の共有ボリュームとして使えることが説明されています。
Filestore はサービスティアで考えると分かりやすいです。Google のドキュメントでは、Basic HDD、Basic SSD、Zonal、Regional、Enterprise といったティアが案内されており、要件に応じて性能と可用性を選べます。特に Regional tier は、複数ゾーンへデータ複製してゾーン障害に耐えることが説明されており、これは EFS Regional の考え方に近いです。
比較すると、次のような印象になります。
- Amazon EFS：より“自動拡張と共有のしやすさ”が前面に出る
- Google Filestore：ティア選択で性能・可用性を明示的に選びやすい
また Filestore の料金は、ティアごとに インスタンス料金、GiB 時間、IOPS の組み合わせで表現されるものがあり、オン/オフ設定や階層によって見え方が変わります。AWS EFS が「保存量＋スループット/アクセス」に近い考え方なのに対し、Filestore はインスタンス感がやや強く残ります。
現場向けに言い換えると、AWS では「共有ファイルシステムをまず置く」感覚で EFS を使いやすく、GCP では「必要なサービス階層を選んでファイルストレージを設計する」感覚で Filestore を使いやすい、という違いがあります。
5. Azure Filesとの比較
Azure Files は、Azure の共有ファイルストレージサービスで、SMB と NFS の両方をサポートしています。公式ドキュメントでは、Azure Files が SMB と NFS の2つの標準プロトコルを提供し、1つのファイル共有自体は SMB と NFS の両方で同時利用はできないが、同じストレージアカウント内でそれぞれの共有を作成できると説明されています。
さらに、Azure Files では冗長性の選択が比較的前面に出ています。日本語ドキュメントでは、Azure Files の冗長オプションとして LRS、ZRS、GRS などを選べることが整理されており、可用性とディザスタリカバリ要件に応じた設計がしやすくなっています。
料金面では、Azure Files は複数の課金モデルを持ちます。Azure の料金ページと課金モデル解説では、HDD 向けの pay-as-you-go と provisioned v2 などがあり、コストは 課金モデル、メディア階層、冗長性、リソースモデル の4要素で決まると説明されています。
EFS と Azure Files を比べると、ざっくり次のように整理できます。
- EFS：NFS 系共有ファイルシステムとして AWS 上で自然
- Azure Files：SMB/NFS の両面を持ち、Windows 系や SMB 前提ワークロードとも相性が良い
もし要件が Linux 系ワークロード中心で、AWS ネイティブな共有ファイルストレージを求めるなら EFS は非常に分かりやすいです。一方で、SMB の互換性や Microsoft 環境との親和性が重要なら Azure Files の見通しはかなり良いです。
6. 料金の考え方
Amazon EFS の料金ページでは、Elastic Throughput での読み書きアクセス、Provisioned Throughput、そして Infrequent Access や Archive への階層化に伴う読み取り・階層化アクティビティが課金要素になると説明されています。つまり、EFS は「保存量だけ」ではなく、アクセスの仕方と階層化戦略がコストに効いてきます。
現場でコストが膨らみやすいポイントは、主に次のようなものです。
- 共有ファイルを“念のため”何でも置いてしまう
- 頻繁に読むデータと、ほとんど触らないデータを同じ扱いにする
- One Zone でよい用途まで Regional にしてしまう
- Throughput を過剰に確保する
ですので、EFS のコスト設計では、少なくとも次の3つを分けて考えるのがおすすめです。
- 常時使うホットデータ
- たまに参照するが共有が必要なデータ
- ほぼ保管目的のデータ
Google Filestore もティアごとの時間単価・容量単価が分かれており、Azure Files も課金モデルとメディア階層でコスト感が変わります。どのクラウドでも共通しているのは、共有ファイルストレージは“便利だから全部置く”と高くなりやすいことです。つまり、どこでも「本当に共有が必要なものだけを置く」のが基本です。
7. EFS が特に向いているワークロード
Amazon EFS が特に向いているのは、次のようなケースです。
まず、複数 EC2 / コンテナ / Kubernetes ノードから同じファイル群を読み書きする構成です。アプリケーションの共有コンテンツやアップロードファイル、ML 処理の中間データ、CI/CD の共有ワークスペースなどでは非常に素直です。AWS も EFS を並列アクセス前提のファイルシステムとして説明しています。
次に、NFS ベースの共有ストレージをマネージドにしたい場合です。自前 NFS サーバーを持つ運用は、冗長化、パッチ、ディスク拡張、障害対応の負担が大きいので、これを減らしたい場合に EFS はとても自然です。
さらに、データ量が伸びるが、毎回容量計画を細かくやりたくない場合にも向きます。EFS はスケーリングのしやすさが魅力なので、成長初期やアクセス変動が大きい環境では扱いやすいです。
一方で、単一インスタンスだけが使う高性能ストレージや、超低レイテンシが最優先のワークロードでは、別種のストレージのほうが適することもあります。EFS は“共有ファイルシステム”としての価値で選ぶのがコツです。
8. よくある失敗と、その避け方
8-1. 何でも EFS に置いてしまう
共有が必要ないデータまで EFS に集めると、コストも責任範囲も広がります。EFS は便利ですが、「共有が必要なもの」に絞ると設計がずっときれいになります。
8-2. Regional と One Zone を曖昧に選ぶ
可用性要件が強いなら Regional、単一 AZ でもよい用途なら One Zone と、最初に割り切ることが大切です。AWS 自身も通常は Regional を推奨しています。
8-3. スループットを性能試験なしで決め打ちする
Provisioned Throughput をいきなり固定すると、過剰確保や不足が起きやすいです。まずは Elastic Throughput を使い、実測で傾向を見るほうが安全です。
8-4. Azure Files や Filestore と同じ感覚で比較する
Filestore はティア選択、Azure Files は SMB/NFS と冗長性選択の色が強く、EFS は自動拡張型の共有 NFS としての自然さが強いです。名前が似た“共有ファイルストレージ”でも、比較の軸はかなり違います。
まとめ
Amazon EFS は、AWS のフルマネージド共有ファイルストレージとして、複数のコンピュートから同じファイルシステムへ並列アクセスでき、需要に応じてペタバイト規模までスケールできます。Regional と One Zone を選べ、Elastic / Provisioned / Bursting のスループットモードも持つため、共有ファイルストレージをかなり柔軟に設計できます。
Google Cloud Filestore は、ティアごとの性能と可用性を選びやすく、特に GKE との共有ストレージ用途で整理しやすいです。Azure Files は SMB と NFS を両方扱え、冗長性と課金モデルの選択肢が豊富で、Microsoft 環境との相性が良いです。
ですので、ざっくりまとめると、
- AWS 上で共有ファイルシステムを自然に使いたい → Amazon EFS
- GKE や Google Cloud 上でティアを選んで共有ストレージを設計したい → Filestore
- SMB/NFS 両面や Microsoft 環境との親和性を重視したい → Azure Files
という整理がいちばん実務的です。
最初の一歩としては、EFS を選ぶ場合でも、いきなり全ファイルを共有基盤へ移すのではなく、本当に複数ノードから同時アクセスが必要なデータだけを EFS に寄せるのがおすすめです。そこから性能傾向とコスト感を見て、必要なら One Zone / Regional やスループットモードを最適化していくほうが、運用としてとても穏やかですわ。