AWSでストレージを選ぶとき、「とりあえずS3」で済ませてしまうケースは多いですが、複数のEC2インスタンスやコンテナから同じファイルに同時アクセスしたい場合、S3だけでは要件を満たせないことがあります。そこで候補に挙がるのが EFS（Elastic File System） です。
この記事では、S3とEFSの違いを「データの種類」「アクセス方法」「料金」「ユースケース」の観点から整理します。
EFS(Elastic File System)とは
EFSは、AWSが提供するフルマネージドのNFS(Network File System)ファイルストレージサービスです。複数のEC2インスタンスやLambda、コンテナ(ECS/Fargate、EKS)から、同じファイルシステムを同時にマウントして共有できるのが最大の特徴です。
オンプレミスで言うところのNAS(ネットワーク接続ストレージ)に近く、/mnt/data のようなパスとしてマウントすれば、あとは普段どおり open() や fwrite() といった標準的なファイルシステムAPIで読み書きできます。容量は事前確保が不要で、書き込んだ分だけ自動的にペタバイト級まで拡張されるため、「サーバーを増やしたらディスク容量が足りなくなった」といった心配がありません。
主なユースケースは以下のようなものです。
- 複数のWebサーバー間で共有するアップロードファイル・設定ファイル
- CMS(WordPressなど)のコンテンツディレクトリの共有
- 機械学習の学習/推論で複数インスタンスから同じデータセットやモデルを参照する用途
- 解析パイプラインにおける一時的な共有作業領域
要するに、「複数のコンピュートリソースから、まるでローカルディスクのように同じファイルへ同時アクセスしたい」というニーズに応えるのがEFSです。この性質がS3(オブジェクトストレージ)との一番の違いになります。
そもそも何が違うのか
| 項目 | Amazon S3 | Amazon EFS |
|---|---|---|
| ストレージの種類 | オブジェクトストレージ | ファイルストレージ（NFS） |
| アクセス方法 | REST API（HTTP経由） | 標準のファイルシステムAPI（マウントして利用） |
| 同時書き込み | 弱い整合性（部分書き込み不可） | 複数インスタンスから同時読み書き可能、強い整合性 |
| スケール | 実質無制限、事前プロビジョニング不要 | ペタバイト級まで自動スケール |
| 主な用途 | 画像・ログ・バックアップ・静的コンテンツ・データレイク | 複数サーバーで共有する設定ファイル、CMS、解析ワークロードの共有領域 |
一番大きな違いは「マウントできるかどうか」です。<cite index=”7-1″>EFSはファイルレベルでの標準的なファイルシステムAPIによるアクセスを提供する一方、S3はREST APIを通じてオブジェクト単位でアクセスする仕組みになっています</cite>。また<cite index=”7-1″>EFSでは複数インスタンス・複数AZにまたがってデータの一貫性が保たれ、あるファイルへの変更は他のインスタンスから即座に見える一方、S3では書き込み後の反映に多少のタイムラグが生じることがあります</cite>。
料金感
概算の目安として、<cite index=”5-1″>S3は$0.023/GB、EFS Standardは$0.30/GBとなっており、単純比較ではS3の方が圧倒的に安価です</cite>。ただしこれは「同じ土俵で比べられるものではない」点に注意が必要です。EFSの料金には複数クライアントからの同時アクセスやPOSIX準拠のロック機構といった、S3にはない機能へのコストが含まれています。
通信速度(レイテンシ・スループット)の違い
体感速度に直結する部分なので、ここは実際の数値で見ておくと分かりやすいです。<cite index=”11-1″>EFSのGeneral Purposeモードはファイル操作あたり2〜5ミリ秒程度のレイテンシで動作するのに対し、S3はHTTPベースのアクセスモデルと分散アーキテクチャが理由で、最初の1バイトが返るまでに50〜100ミリ秒程度かかるのが一般的です</cite>。1リクエストあたりの応答速度で言えば、EFSの方が一桁以上速いイメージです。
一方で「どれだけ大量のデータを流せるか」というスループットの土俵では話が変わってきます。<cite index=”10-1″>EFSと比べるとS3はレイテンシは高いものの、はるかに高いスループットを叩き出せます</cite>。つまり、
- 少量のファイルに素早くアクセスしたい(小さいリクエストを大量にさばく) → EFSが有利(低レイテンシ)
- 大きなファイルをまとめて高速に転送したい(大容量のシーケンシャル転送) → S3が有利(高スループット)
という棲み分けです。<cite index=”13-1″>実際、EFSは小さいファイルに対してサブミリ秒レベルのレイテンシを発揮する一方、S3は大きなオブジェクトを高スループットで転送することに最適化されているという傾向が2025年時点のベンチマークでも確認されています</cite>。
なお、EFSのスループットモードにも選択肢があります。<cite index=”9-1″>推奨されるElasticモードはワークロードに応じて自動でスループットをスケールし、使った分だけ課金される仕組みで、最大20GB/sまで対応します</cite>。安定した負荷が予測できる場合はProvisionedモードで固定スループットを確保することも可能です。
つまり「通信速度が違う」というのはその通りで、単純に「どちらが速いか」ではなく、リクエスト単位の応答速度(レイテンシ)ならEFS、大容量データの転送速度(スループット)ならS3が得意、というのが実態に近い理解です。
2026年の新展開:S3 Files
2026年に入り、状況を少し変える動きがありました。<cite index=”4-1″>2026年4月にGA(一般提供開始)となった「S3 Files」は、S3バケットをNFSv4.0のファイルシステムとしてEC2インスタンスに直接マウントできるサービスで、料金体系もEFSのスループット課金ではなくS3の料金モデルに基づいています</cite>。
コスト面のインパクトは大きく、<cite index=”4-1″>100TBを使用した場合の月額はS3 Filesが約200ユーロ程度なのに対し、EFS General Purposeは約2,702ユーロ程度と、10倍以上の差が出るという試算もあります(データ転送費用は含まず)</cite>。
ただし万能ではありません。<cite index=”4-1″>S3 FilesはPOSIXロック(アドバイザリロックのみで、バイト範囲の強制ロックはなし)や複数クライアントからの並行書き込みに対する強い整合性保証を提供しないため、POSIXロックに依存するWebサーバーやデータベースなどの用途には向いていません</cite>。逆に言えば、<cite index=”4-1″>EFSがプレミアム料金を正当化しているのは、まさにこの強い整合性というS3 Filesにはない機能です</cite>。
どう使い分けるか
- S3を選ぶべきケース:画像・動画・ログ・バックアップ・静的サイト・データレイクなど、オブジェクト単位で読み書きが完結するデータ
- EFSを選ぶべきケース:複数のEC2/コンテナから同じファイルへ同時に読み書きし、強い整合性やPOSIXロックが必須の共有ストレージ(CMSのアップロード領域、解析パイプラインの共有作業領域など)
- S3 Filesを検討すべきケース:読み取り中心で、多少の整合性の緩さは許容できるが、EFSほどのコストはかけたくないバッチ処理・分析用途
まとめ
S3とEFSは「安いか高いか」で比べるものではなく、そもそも解決している問題が違います。オブジェクトストレージが欲しいのか、複数インスタンスから同時にマウントして使えるファイルシステムが欲しいのかを最初に決めることが、結局は一番のコスト最適化につながります。2026年に登場したS3 Filesのように、この境界線をまたぐ新しい選択肢も増えてきているため、ワークロードのアクセスパターン(読み取り中心か、細かい書き込みが多いか)を軸に定期的に見直す価値がありそうです。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
