Amazon S3 vs EBS vs EFS 徹底比較｜AWSストレージサービスの違いと使い分けガイド

「S3、EBS、EFS。AWSのストレージサービスが3つもあるけど、結局どれを使えばいいんだろう？」

オンプレの世界では、ストレージといえばサーバー内蔵のローカルディスクか、SANやNASの共有ストレージか、という2択がほとんどでした。ところがAWSに来ると、Amazon S3、Amazon EBS、Amazon EFSという3つのストレージサービスが並んでいて、それぞれ用途も料金体系もまったく異なります。選択を間違えると、パフォーマンスが足りなくて障害が起きたり、逆に月額コストが想定の数倍に膨れ上がったりします。

この記事では、S3・EBS・EFSの違いを「ストレージの種類」「アクセス方式」「料金」「ユースケース」の4軸で徹底比較し、オンプレ経験者が迷わず選べる判断基準を解説します。

なぜAWSにストレージが3種類あるのか？

オンプレ時代を思い出してみてください。サーバーの内蔵ディスク（DAS）はOSやアプリケーションのインストール先として使い、NASはチーム間でファイルを共有するために使い、バックアップテープやオブジェクトストレージは長期保管用に使っていたはずです。

AWSの3つのストレージサービスは、まさにこの役割分担をクラウド上で再現したものです。

・Amazon EBS（Elastic Block Store）: サーバー内蔵ディスク（DAS/SAN）に相当。EC2インスタンスに直接アタッチして使うブロックストレージ
・Amazon EFS（Elastic File System）: NASに相当。複数のEC2インスタンスから同時にマウントして使える共有ファイルストレージ
・Amazon S3（Simple Storage Service）: テープライブラリやオブジェクトストレージに相当。HTTP/HTTPS経由でアクセスする大容量データの保管庫

それぞれがカバーする領域が違うからこそ、3種類存在するわけです。問題は「自分のワークロードにどれが合うか」の判断が、オンプレの経験だけでは難しいこと。次のセクションから、1つずつ掘り下げていきます。

Amazon S3の特徴と得意領域

1. オブジェクトストレージという考え方

S3は「オブジェクトストレージ」というカテゴリに属します。オンプレのファイルシステムのようにディレクトリ階層を持つのではなく、「バケット」というコンテナの中に「オブジェクト」（ファイル＋メタデータ）をフラットに格納する仕組みです。

ファイルシステムとの最大の違いは、オブジェクトの一部だけを書き換えるといった操作ができないこと。更新するときはオブジェクト全体を上書きします。そのため、データベースのデータファイルやログのように頻繁に追記されるファイルの置き場所には向きません。

一方で、1つのオブジェクトで最大5TBまで格納でき、バケット全体の容量に上限はありません。99.999999999%（イレブンナイン）の耐久性を持ち、データ消失リスクはほぼゼロです。

2. S3が活きるユースケース

・静的ファイル配信: Webサイトの画像・CSS・JSファイルのホスティング（CloudFrontと組み合わせてCDN配信）
・バックアップ・アーカイブ: データベースダンプ、ログファイルの長期保管
・データレイク: ビッグデータ分析用の生データ集約先（Athena・Redshift Spectrumと連携）
・アプリケーション間のデータ受け渡し: ETLパイプラインの中間ファイル置き場

3. S3の料金体系

S3の料金は「保存容量」「リクエスト数」「データ転送量」の3要素で決まります。東京リージョン（ap-northeast-1）のS3 Standardの場合、保存料金は1GBあたり月額約$0.025です（2026年4月時点）。

保存しているだけなら非常に安価ですが、GETリクエストが大量に発生するワークロードでは、リクエスト料金が無視できない額になることがあります。料金見積もりでは保存容量だけでなく、アクセス頻度も必ず考慮してください。

Amazon EBSの特徴と得意領域

1. ブロックストレージとは何か

EBSは「ブロックストレージ」です。オンプレのサーバーに搭載するSSDやHDDと同じ感覚で、EC2インスタンスにアタッチしてファイルシステム（ext4やxfs）をフォーマットし、マウントして使います。

オンプレとの最大の違いは、EBSボリュームはネットワーク経由でEC2インスタンスに接続されるという点です。物理的に同じ筐体に入っているわけではないため、インスタンスを停止・終了してもデータは残ります。逆に、ネットワーク越しのアクセスなので、インスタンスストアと比較するとわずかにレイテンシが大きくなります。

2. ボリュームタイプの選択

EBSには用途に応じた複数のボリュームタイプがあります。

オンプレでSANのLUNを切り出すときに「IOPS要件はどれくらいか」を検討していたのと同じように、EBSでもボリュームタイプの選定がパフォーマンスとコストに直結します。迷ったらgp3から始めるのが定石です。

3. EBSが活きるユースケース

・OSのブートボリューム: EC2のルートデバイスとして使用
・データベース: MySQL、PostgreSQL、Oracleなどのデータファイル格納先
・トランザクション処理: ランダムI/Oが多いアプリケーション
・単一インスタンスのデータ保存: アプリのローカルデータやキャッシュファイル

4. EBSの制約

EBSボリュームは、原則として1つのEC2インスタンスにしかアタッチできません（io2のマルチアタッチ機能を除く）。また、同一アベイラビリティゾーン（AZ）内のEC2インスタンスにしかアタッチできないため、AZをまたいだ利用はできません。この制約は、オンプレのDAS（Direct Attached Storage）に似ています。

Amazon EFSの特徴と得意領域

1. マネージドNFSという位置づけ

EFSは、AWSが提供するフルマネージドのNFSv4ファイルシステムです。オンプレで使っていたNetAppやEMCのNASと同じ感覚で、複数のEC2インスタンスから同時にマウントしてファイルを読み書きできます。

オンプレのNASとの違いは、容量のプロビジョニングが不要なこと。EFSはファイルを追加すれば自動的に拡張し、削除すれば自動的に縮小します。容量設計のための見積もりや、ボリュームの拡張作業は必要ありません。

2. EFSが活きるユースケース

・Webサーバーのコンテンツ共有: 複数のEC2インスタンスで同じドキュメントルートを参照する
・コンテナのデータ共有: Amazon ECSやEKSのタスク間で永続データを共有する
・開発環境のホームディレクトリ: 複数の開発者が同じファイルにアクセスする
・機械学習のトレーニングデータ: 複数のGPUインスタンスから同じデータセットを読み込む

3. EFSの料金体系

EFSの料金はストレージクラスによって異なります。東京リージョン（ap-northeast-1）の場合、EFS Standardは1GBあたり月額約$0.36です（2026年4月時点）。EBS gp3（$0.096/GB/月）やS3 Standard（$0.025/GB/月）と比較すると、GB単価はかなり割高です。

ただし、EFS Infrequent Access（EFS IA）を活用すれば、アクセス頻度の低いファイルを自動的に低価格のストレージ層に移動でき、コストを大幅に削減できます。EFS IAの保存料金は1GBあたり月額約$0.020で、S3 Standardよりも安くなります。ライフサイクルポリシーを設定して、一定期間アクセスのないファイルを自動でIAに移すのが定番の運用です。

3サービス比較表で整理する

ここまでの内容を表で一覧にまとめます。

この表を見ると、「コストならS3」「パフォーマンスならEBS」「共有ならEFS」という大まかな傾向が見えてきます。

判断フロー：どのストレージを選ぶか

選定で迷ったときは、以下の3つの質問に順番に答えてください。

質問1: 複数のインスタンスから同時にアクセスする必要があるか？

→ Yesなら、ファイルシステムとしてマウントしたいならEFS、APIアクセスで十分ならS3。

質問2: ブロックデバイスとしてマウントする必要があるか？

→ Yesなら、EBS一択。データベースのデータファイルやOSのブートボリュームがこれに該当します。

質問3: データの読み書き頻度はどれくらいか？

→ 頻繁に読み書きする → EBSまたはEFS
→ 書き込みは少なく読み取り中心 → S3（+ CloudFrontで高速化）
→ 保管がメインでほとんどアクセスしない → S3（Glacier系ストレージクラスで大幅コスト削減）

現場では、1つのシステムで3サービスを併用するのが普通です。「EBSにデータベース、EFSにアプリケーションの設定ファイル共有、S3にバックアップとログ保管」という組み合わせは、多くのWebアプリケーションで見られる典型パターンです。

よくあるトラブルと対処法

1. EBSのIOPS不足によるパフォーマンス低下

データベースサーバーで「ディスクI/Oが遅い」という報告があったら、まずCloudWatchのVolumeQueueLengthメトリクスを確認してください。この値が常に1以上になっているなら、I/Oリクエストが待ち行列に溜まっている＝IOPSが足りていないサインです。

対処法は、gp3のIOPSプロビジョニングを増やすか、io2に変更すること。EBSはオンラインでボリュームタイプを変更できるので、サーバーを停止する必要はありません。

# gp3ボリュームのIOPSを変更する例（AWS CLI）
aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --iops 10000 \
  --throughput 400 \
  --region ap-northeast-1

2. S3の「403 Access Denied」で原因が特定できない

S3のアクセス制御は、IAMポリシー・バケットポリシー・ACL・VPCエンドポイントポリシー・S3 Block Public Accessの5つが絡み合っています。どれか1つでも「Deny」になっていればアクセスは拒否されます。

トラブルシューティングの手順は以下のとおりです。

・Step 1: IAM Access Analyzerでポリシー評価を確認する
・Step 2: CloudTrailのログでエラーの詳細（ErrorCode, ErrorMessage）を確認する
・Step 3: S3 Block Public Accessの設定が想定どおりか確認する
・Step 4: VPCエンドポイントを経由している場合、エンドポイントポリシーを確認する

オンプレのNASで「アクセス権が足りない」と言われたら、ファイルのパーミッションとACLを見れば済みましたが、S3ではチェックすべきレイヤーが多い分、ハマりやすいポイントです。

3. EFSのコストが想定以上に高い

EFS Standardはギガバイト単価がEBSの約4倍です。「とりあえずEFSにデータを入れておいたら、月末の請求が跳ね上がった」というのはよくある話です。

対処法は2つあります。

・ライフサイクルポリシーの設定: 一定期間（7日・14日・30日・60日・90日から選択）アクセスのないファイルを自動でEFS IAに移動させる
・スループットモードの見直し: Bursting（バースト）モードからElastic（弾力性）モードに変更して、使った分だけ課金に切り替える

# EFSライフサイクルポリシーの設定例（AWS CLI）
aws efs put-lifecycle-configuration \
  --file-system-id fs-0123456789abcdef0 \
  --lifecycle-policies TransitionToIA=AFTER_30_DAYS \
  --region ap-northeast-1

料金の実例で比較する

「100GBのデータを1か月間保存した場合」の料金を、東京リージョンで比較してみます（2026年4月時点の料金）。

EFS StandardがEBSの約4倍、S3の約14倍という価格差がはっきり見えます。EFSの利便性（自動拡張・複数インスタンス共有）には相応のコストがかかるということです。「NASが必要な場面でだけEFSを使い、それ以外はEBSかS3に寄せる」のがコスト最適化の基本方針になります。

本記事のまとめ

AWSの3つのストレージサービスを、オンプレの対応物と紐づけて整理すると以下のようになります。

「ブロックストレージが必要ならEBS、ファイル共有が必要ならEFS、それ以外はS3」。この判断軸を持っておけば、AWSのストレージ選定で大きく外すことはありません。

ただし、コスト差は無視できません。EFS Standardの料金はS3の14倍です。EFS IAやS3 Glacierなどの低頻度アクセス層を活用し、使わないデータには安い保管場所を用意しましょう。ストレージの選定とコスト最適化はセットで考えるのが、クラウドインフラ設計の基本です。