AWSのストレージ選定ミスは、こうした形で後から表面化します。EBS・EFS・S3はどれも「データを保存する」サービスですが、内部のアーキテクチャが根本的に異なり、用途を誤るとコスト超過や性能不足を招きます。
この記事では、EBS・EFS・S3それぞれの仕組み・料金・性能特性を整理し、実務での選定判断フローを解説します。AWS初学者から「なんとなく使っているが根拠に自信がない」という設計入門層まで、ストレージ選定の判断基準を体系的に身につけていただけます。
この記事のポイント
・EBS=ブロックストレージ（EC2に直接アタッチ）、EFS=共有NFS、S3=オブジェクトストレージが3者の基本的な違い
・EC2のOSやDBにはEBS、複数インスタンスでファイル共有するならEFS、APIアクセスでよいならS3を選ぶのが基本判断軸
・コスト比は概算でS3＜EBS＜EFSの順。高機能になるほど割高になる
・AZをまたぐ冗長化要件はEFSとS3が自動対応。EBSは単一AZ内にとどまる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
AWSの3大ストレージサービスとは（EBS・EFS・S3の基本概念）
AWSには用途の異なる3種類のストレージサービスが存在します。それぞれ「どういう形でデータを保存・アクセスするか」という設計思想がまったく違います。EBS（Elastic Block Store）はブロックストレージです。物理サーバーに直接接続されたハードディスクと同じ概念で、EC2インスタンスにアタッチして使います。Linuxからは や といったデバイスとして認識され、ext4やxfsでフォーマットしてマウントして使います。
EFS（Elastic File System）はNFSベースの共有ファイルシステムです。複数のEC2インスタンスから同時にマウントできる点がEBSとの大きな違いです。NFSv4.1プロトコルを使い、Linuxの sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=3865232k,nr_inodes=966308,mode=755,inode64) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=812376k,mode=755,inode64) /dev/mmcblk0p2 on / type ext4 (rw,relatime) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64) cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=32,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=634) hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime) configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime) /var/lib/snapd/snaps/snapd_26869.snap on /snap/snapd/26869 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide,x-gvfs-hide) /dev/mmcblk0p1 on /boot/firmware type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime) /dev/sda1 on /mnt/hdd type ext4 (rw,relatime) tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=812372k,nr_inodes=203093,mode=700,uid=1000,gid=1003,inode64) /var/lib/snapd/snaps/snapd_27407.snap on /snap/snapd/27407 type squashfs (ro,nodev,relatime,errors=continue,threads=single,x-gdu.hide,x-gvfs-hide) コマンドでネットワーク越しにマウントします。容量は自動でスケールするため、事前のプロビジョニングが不要です。
S3（Simple Storage Service）はオブジェクトストレージです。ファイルシステムとしてOSにマウントするものではなく、APIやSDKを通じてオブジェクト（ファイル）を PUT/GET/DELETE する設計です。容量は実質無制限で、可用性99.999999999%（11 nines）という極めて高い耐久性を持ちます。
EBS（Elastic Block Store）の特徴・料金・適切なユースケース
EBSはEC2インスタンスのストレージとして最も基本的なサービスです。LinuxサーバーのOSボリュームやデータベースのデータ領域として使われます。1. EBSのボリュームタイプと料金比較
EBSには用途別にいくつかのボリュームタイプがあります（東京リージョン・2026年7月時点の概算）。| ボリュームタイプ | 種別 | 料金（概算） | IOPS | 主な用途 |
|---|---|---|---|---|
| gp3 | 汎用SSD | 約0.096 USD/GB/月 | 3,000～16,000 | OSボリューム・一般的なアプリ |
| io2 Block Express | 高性能SSD | 約0.138 USD/GB/月＋IOPS課金 | 最大64,000以上 | 高負荷DB（Oracle・SQL Server） |
| st1 | スループット最適化HDD | 約0.048 USD/GB/月 | HDD（低IOPS） | ビッグデータ・ログストレージ |
| sc1 | コールドHDD | 約0.018 USD/GB/月 | HDD（最低IOPS） | アクセス頻度が低いアーカイブ |
gp3 を選んでください。前世代の gp2 と比べてIOPSを独立してプロビジョニングできるため、コストを最適化しやすくなっています。2. EBSの制約とアタッチ操作
EBSには重要な制約があります。原則として同一AZ内の1つのEC2インスタンスにしかアタッチできません（io1/io2のMulti-Attachは例外ですが、同一AZ内に限られます）。以下はAWS CLIでEBSボリュームの状態を確認する例です。
# EBSボリュームの詳細を確認する $ aws ec2 describe-volumes --volume-ids vol-0a1b2c3d4e5f67890 { "Volumes": [ { "VolumeId": "vol-0a1b2c3d4e5f67890", "VolumeType": "gp3", "Size": 50, "State": "in-use", "Iops": 3000, "Throughput": 125, "AvailabilityZone": "ap-northeast-1a", "Attachments": [ { "InstanceId": "i-0987654321abcdef0", "Device": "/dev/xvda", "State": "attached" } ] } ] }
3. EBSに適したユースケース
・EC2のOSルートボリューム: ほぼすべてのEC2インスタンスでEBSが起動ボリュームとして使われます・RDS・MySQL・PostgreSQL等のデータベース: 高IOPS・低レイテンシが必要なDBはEBSが最適
・単一インスタンスが使うアプリケーションデータ: Webサーバーのログ、一時ファイルなど
・スナップショットによるバックアップ: EBSスナップショットはS3に増分保存される
EFS（Elastic File System）の特徴・料金・適切なユースケース
EFSは複数のEC2インスタンスから同時にアクセスできる共有ファイルシステムです。NFSv4.1プロトコルを使うため、Linuxの標準的なファイル操作コマンドがそのまま使えます。1. EFSのパフォーマンスモードとスループットモード
EFSには性能に関する2軸の設定があります。パフォーマンスモード:
・General Purpose（汎用）: ほとんどのワークロードに適する。レイテンシが低い（推奨）
・Max I/O: 並列アクセスが極めて多い場合（ビッグデータ解析など）。レイテンシはやや高くなる
スループットモード:
・Elastic（推奨）: 負荷に応じてスループットが自動調整される。2022年以降の新規構築ではこれを選ぶ
・Bursting: 使用量に応じてバーストクレジットが溜まる。アクセスが少ない時間帯が多い場合はコスト有利
・Provisioned: 一定のスループットを事前に確保する。高負荷が常時続く場合に使う
EFSの料金は東京リージョンで概算 約0.36 USD/GB/月（Standard ストレージクラス）です。EBSのgp3（約0.096 USD/GB/月）と比べて約3.75倍高くなるため、「とりあえずEFS」は避けてください。
以下はEFSをEC2にマウントするコマンドです。
# EFSマウントヘルパーを使ったマウント（推奨） # amazon-efs-utils パッケージが必要 $ sudo mount -t efs -o tls fs-0a1b2c3d4e5f67890:/ /mnt/efs # または標準NFSで直接マウント $ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-0a1b2c3d4e5f67890.efs.ap-northeast-1.amazonaws.com:/ /mnt/efs # マウント確認 $ df -h /mnt/efs Filesystem Size Used Avail Use% Mounted on fs-0a1b2c3d4e5f67890.efs.ap-northeast-1.amazonaws.com:/ 8.0E 0 8.0E 0% /mnt/efs
2. EFSに適したユースケース
・WordPress等のCMSコンテンツ共有: 複数のWebサーバーインスタンスからアップロードファイルを共有したい場合・コンテナのデータ永続化（ECS・EKS）: 複数コンテナから同じファイルにアクセスが必要な場合
・機械学習のデータセット共有: 複数のGPUインスタンスが同一データセットを参照するケース
・ホームディレクトリの集中管理: 複数のEC2インスタンスにNFSでホームディレクトリを提供する
S3（Simple Storage Service）の特徴・料金・適切なユースケース
S3はAWSで最も広く使われるストレージサービスです。ファイルシステムではなくオブジェクトストレージであるため、OSからファイルパスでアクセスするのではなく、AWS CLIやSDK・HTTPSのAPIを通じて操作します。1. S3のストレージクラスと料金比較
| ストレージクラス | 料金（概算） | アクセス頻度 | 取り出し料金 |
|---|---|---|---|
| S3 Standard | 約0.025 USD/GB/月 | 高頻度 | なし |
| S3 Intelligent-Tiering | 約0.025 USD/GB/月＋監視料金 | アクセス頻度が変動する | なし |
| S3 Standard-IA | 約0.013 USD/GB/月 | 低頻度 | あり |
| S3 Glacier Instant Retrieval | 約0.005 USD/GB/月 | 極めて低頻度 | あり（即時取り出し可） |
| S3 Glacier Deep Archive | 約0.002 USD/GB/月 | ほぼアクセスなし | あり（取り出しに時間） |
以下はAWS CLIでS3を操作する基本例です。
# バケット内のオブジェクト一覧を表示 $ aws s3 ls s3://my-project-backup/ 2026-07-01 10:23:45 524288 db-backup-20260701.tar.gz 2026-07-08 10:24:12 531456 db-backup-20260708.tar.gz 2026-07-15 10:21:33 528000 db-backup-20260715.tar.gz # ファイルをS3にアップロード $ aws s3 cp /var/backup/db-backup-20260715.tar.gz s3://my-project-backup/ upload: ../var/backup/db-backup-20260715.tar.gz to s3://my-project-backup/db-backup-20260715.tar.gz # バケットの使用量を確認 $ aws s3api list-objects-v2 --bucket my-project-backup --query "sum(Contents[].Size)" 1583744
2. S3に適したユースケース
・静的ウェブサイトのホスティング: HTML・CSS・画像ファイルの配信。CloudFrontと組み合わせてCDN配信が可能・バックアップ・アーカイブ: EBSスナップショット、データベースダンプ、ログファイルの長期保存
・データレイクの基盤: AthenaやGlueでS3上の大量データを直接クエリする構成
・ALBアクセスログ・CloudTrailログ: AWSサービスのログを自動的に保存する宛先
・メディアファイルの保存・配信: 動画・画像・音声ファイルの原本保存
EBS・EFS・S3の使い分け判断フロー（比較表）
3サービスの特性をまとめると以下の通りです。| 比較項目 | EBS | EFS | S3 |
|---|---|---|---|
| ストレージ種別 | ブロック | ファイル（NFS） | オブジェクト |
| アクセス方式 | EC2に直接アタッチ | NFS v4.1 マウント | API / SDK / HTTPS |
| 同時アクセス | 原則1台（同一AZ内） | 複数EC2から同時 | 無制限 |
| AZ制約 | 同一AZのみ | 複数AZ対応（Regional） | リージョン全体 |
| 容量管理 | 手動でサイズ変更 | 自動スケール | 無制限・自動 |
| コスト（概算） | gp3: 0.096 USD/GB/月 | Standard: 0.36 USD/GB/月 | Standard: 0.025 USD/GB/月 |
| レイテンシ | 最低（サブミリ秒） | 低（数ミリ秒） | やや高い（HTTP往復） |
・Q1: OSのブートボリュームやデータベースとして使いたい？ → YES の場合は EBS 一択
・Q2: 複数のEC2インスタンスやコンテナから同時にファイルアクセスが必要？ → YES の場合は EFS
・Q3: APIやCLIでのアクセスで問題ない（ファイルシステムマウント不要）？ → YES の場合は S3
・Q4: AZをまたいで複数インスタンスからファイルを共有しつつ、コストを抑えたい？ → EFS ではなく S3 ＋ アプリ側でのAPI対応を検討
AWSのストレージ選定に迷ったとき、まずこのフローで判断すると選択肢を絞り込めます。AWS全般のアーキテクチャ設計については AWS（Amazon Linux）学習ガイド も参照してください。
料金と性能の観点から見た選定基準
「安いから」という理由でS3を選んでも、アプリケーションがNFSマウントを前提にしていればそのままでは動きません。逆に「パフォーマンスが必要だから」とEBSにしても、複数インスタンスからの同時アクセスが必要な要件には対応できません。以下に実務でよく出る組み合わせパターンを示します。
1. Webアプリ＋DB構成（最も一般的）
・Webサーバー（EC2）の起動ボリューム → EBS gp3（30GB程度）・DBサーバー（EC2またはRDS）のデータボリューム → EBS gp3またはio2
・ユーザーアップロードファイルの保存 → S3（コスト最適）
・バックアップ先 → S3（EBSスナップショット＋mysqldump/pgdumpのアップロード先）
2. マイクロサービス・コンテナ構成
・ECSタスクの一時ファイル → タスク定義のEphemeral Storage（ECSのローカルストレージ）・コンテナ間で共有するファイル → EFS（ECS/EKSのEFSボリュームサポートを使う）
・画像・動画等のメディア → S3
3. ビッグデータ・機械学習構成
・データレイク（原本データ保管） → S3・学習データの高速アクセス → EFS（複数GPUインスタンスから同時アクセス）
・モデルチェックポイントの保存 → S3 または EFS（頻繁にアクセスする場合）
マルチAZ構成とストレージの冗長化設計
AWSでは障害対策のために複数のAZ（アベイラビリティゾーン）にリソースを分散させることが推奨されています。ストレージの冗長化という観点では、3サービスの扱いが大きく異なります。1. EBSのAZ制約と冗長化
EBSは単一AZに紐づくサービスです。ap-northeast-1aのEC2インスタンスにアタッチしたEBSボリュームは、同じap-northeast-1aにしか存在しません。そのAZで障害が発生した場合、EBSごとEC2が使えなくなります。EBSの冗長化は次のように対応します。
・EBSスナップショット: スナップショットはS3に保存されるためリージョン全体で耐久性を持つ
・マルチAZにEC2を配置してALBで負荷分散: 各EC2が独立したEBSを持つ構成
・RDSのマルチAZ配置: RDSを使う場合はマルチAZオプションで自動的に別AZにスタンバイを持てる
2. EFSの自動マルチAZ対応
EFS（Regional）は最初からリージョン内の複数AZにデータを冗長化します。1つのAZで障害が発生しても、他のAZからEFSへのアクセスは継続されます。# EFSのマウントターゲットを確認（複数AZに存在することを確認） $ aws efs describe-mount-targets --file-system-id fs-0a1b2c3d4e5f67890 { "MountTargets": [ { "MountTargetId": "fsmt-01234abc", "AvailabilityZoneName": "ap-northeast-1a", "LifeCycleState": "available" }, { "MountTargetId": "fsmt-05678def", "AvailabilityZoneName": "ap-northeast-1c", "LifeCycleState": "available" }, { "MountTargetId": "fsmt-09012ghi", "AvailabilityZoneName": "ap-northeast-1d", "LifeCycleState": "available" } ] }
3. S3の高可用性
S3 StandardはAWS内部で3つ以上の施設にデータを自動複製します。耐久性99.999999999%（11 nines）は業界最高水準で、冗長化のために追加の設定は基本的に不要です。ただし、誤削除や意図しない上書きへの対策としてはS3のバージョニング機能を有効にすることを検討してください。
よくある失敗パターンと回避策
実際のAWS設計でよく見かける失敗パターンを紹介します。1. 「とりあえずEFS」でコストが膨らむ
複数インスタンスからのファイル共有が必要と思っていたが、実際はS3でAPIアクセスすれば解決できた、というケースです。EFSはEBSの約3.75倍のコストがかかります。アプリケーションがS3 SDKに対応しているなら、S3を選ぶほうが圧倒的に安上がりです。回避策: 「ファイルパスでのアクセスが本当に必要かどうか」を設計初期に確認する。WordPressのようなCMSや、レガシーアプリでどうしてもNFSマウントが必要な場合のみEFSを選ぶ。
2. EBSのサイズが足りなくなる
データベースのディスク使用量が想定を超え、EBSのサイズが不足するケースです。EBSはオンラインでのサイズ拡張（extend）はできますが、縮小はできません。また、gp2時代はサイズとIOPSが連動していたため、パフォーマンス目的で過剰なサイズのボリュームを作るケースもありました。回避策: gp3では容量とIOPSを独立して設定できます。モニタリング（CloudWatchのEBSメトリクス）でディスク使用量のアラートを設定し、早めに拡張対応する。
3. S3をDBの代わりに使おうとする
コストが安いからとS3を多目的に使おうとして、「S3に頻繁にファイルを更新しながら読み込む」用途に使うケースです。S3は結果整合性モデルを基本としており（現在はstrong read-after-writeが保証されていますが）、高頻度の更新・読み取りが絡む処理にはEBSかEFSを使うほうが適しています。回避策: S3は「書いたら基本的に変えない」オブジェクト（バックアップ、メディアファイル、ログなど）に最適です。頻繁に更新されるアプリケーションデータはEBSまたはDynamoDB等のデータベースサービスを選ぶ。
4. EBSのAZ固定を忘れてAuto Scalingが失敗する
Auto Scalingグループで新しいEC2インスタンスが別のAZに起動しようとしたとき、既存のEBSボリュームがアタッチできないケースです。EBSは同一AZ内にしかアタッチできないため、マルチAZ構成のAuto Scalingでは「共有ストレージ＝EFS」か「アプリケーション状態はS3で管理」という設計が必要です。回避策: ステートフルなデータをEC2のローカルEBSに持たせないステートレス設計を基本にする。共有データはEFSかS3に外出しする。
AWSストレージ選定の基礎をマスターしたら、AWS（Amazon Linux）の実践コース で体系的にAWSインフラ設計を学ぶことをおすすめします。
本記事のまとめ
EBS・EFS・S3の特性と使い分けを整理します。| サービス | 一言での説明 | コスト感 | 使うべきケース |
|---|---|---|---|
| EBS | EC2専用のブロックストレージ | 中 | OSボリューム、DB、高IOPS要求 |
| EFS | 複数EC2から共有できるNFSファイルシステム | 高 | CMS、コンテナ共有、機械学習データセット |
| S3 | APIアクセス型のオブジェクトストレージ | 低 | バックアップ、静的コンテンツ、データレイク |
選定に迷ったときは「ファイルシステムとしてマウントしたいか（Yes=EBSかEFS）」→「複数インスタンスから同時アクセスしたいか（Yes=EFS）」の順に問いを立てると、大抵の場合は正解に辿り着けます。
AWSストレージ設計を「実務の型」として身につけませんか？
EBS・EFS・S3の使い分けは調べれば分かります。でも「なぜそのストレージを選んだのか」「コストと性能のバランスをどう判断したか」を設計レビューで説明できますか？
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます