architecture
A
信頼度ランク
| S | 公式ソース確認済み |
| A | 成功実績多数・失敗例少数 |
| B | 賛否両論 |
| C | 動作未確認・セキュリティリスク高 |
| Z | 個人所感 |
EBS vs EFS vs S3 — AWSストレージサービス完全比較
Amazon EBS(ブロックストレージ)、EFS(ファイルシステム)、S3(オブジェクトストレージ)の特性、ユースケース、パフォーマンス、コスト、マルチAZ対応の違いを解説。
一言結論
EBSはEC2への低レイテンシなブロックストレージ、EFSは複数インスタンスから同時アクセスできるNFSファイルシステム、S3はAPIアクセスで無限スケールのオブジェクトストレージという3つの根本的な違いを理解して選択することがストレージ設計の出発点だ。
3種類のストレージの基本概念
EBS(Elastic Block Store):
タイプ: ブロックストレージ
マウント: 1つのEC2インスタンスに接続(io1/io2は複数接続可)
プロトコル: ブロックデバイス(OS直接マウント)
永続性: EC2とは独立して永続
AZ: 同一AZ内のみ
EFS(Elastic File System):
タイプ: NFS(Network File System)
マウント: 複数のEC2インスタンスから同時アクセス可
プロトコル: NFS v4.1/v4.2
永続性: 独立して永続、マルチAZ
AZ: リージョン全体(マルチAZ)
S3(Simple Storage Service):
タイプ: オブジェクトストレージ
アクセス: HTTP/HTTPSのAPI(Put/Get)
永続性: 99.999999999%(11ナイン)
AZ: 最低3AZに複製
比較表
| 特徴 | EBS | EFS | S3 |
|---|---|---|---|
| ストレージタイプ | ブロック | ファイル(NFS) | オブジェクト |
| 接続数 | 1(Multi-Attach対応は例外) | 複数EC2から同時 | API経由で無制限 |
| レイテンシー | 1ms以下 | 数ms | 数十ms |
| スループット | 最大16,000MB/s(io2 BE) | 最大3GB/s | 高い(マルチパート並列) |
| マルチAZ | ❌(1AZ) | ✅ | ✅ |
| 自動スケーリング | ❌(サイズ変更必要) | ✅(自動) | ✅(無制限) |
| コスト(/GB/月) | $0.10〜0.25 | $0.30(標準) | $0.023(標準) |
| ファイルシステム | OS側がフォーマット | NFS標準 | なし(フラット) |
EBS の詳細
EBSボリュームタイプ:
gp3(汎用SSD): 16,000 IOPS, 1,000 MB/s - デフォルト推奨
gp2(汎用SSD): 16,000 IOPS(サイズ依存) - レガシー
io2 Block Express: 256,000 IOPS, 4,000 MB/s - 高性能DB
io1(プロビジョンド IOPS): 64,000 IOPS - 高性能DB
st1(スループット最適化HDD): 500 MB/s - ビッグデータ・ログ
sc1(コールドHDD): 250 MB/s - アーカイブ
Multi-Attach(io1/io2のみ):
→ 最大16台のEC2インスタンスに同時接続
→ 各インスタンスが同時書き込み可能
→ クラスター型ファイルシステムが必要(GFSv2等)
→ 同一AZのみ
EFS の詳細
EFSのパフォーマンスモード:
汎用モード(General Purpose): レイテンシー優先、デフォルト
最大I/Oモード(Max I/O): 超並列処理向け(大規模Hadoop等)
EFSのスループットモード:
バースト: ファイルシステムサイズに応じた基本スループット(バースト可)
プロビジョニング: 固定のスループットを保証
Elastic(推奨): 使用量に応じて自動スケール
EFSストレージクラス:
スタンダード: 頻繁にアクセスするデータ
IA(Infrequent Access): アクセス頻度の低いデータ(75%コスト削減)
→ ライフサイクルポリシーで自動移行
ユースケース別選択
EBSを使うべきケース:
✅ OSのルートボリューム(/dev/xvda)
✅ データベース(RDS, MySQL, PostgreSQL等)
✅ 低レイテンシーが必要なアプリ
✅ EC2との1対1の接続
EFSを使うべきケース:
✅ 複数EC2から共有ファイルアクセス(Webサーバーのコンテンツ共有)
✅ コンテナ間の共有ストレージ(ECS, EKS)
✅ ホームディレクトリ(Lambda, WorkSpaces)
✅ CMSのメディアファイル共有(WordPressの wp-content等)
S3を使うべきケース:
✅ 静的ウェブサイト
✅ 画像・動画のバックアップ・アーカイブ
✅ ビッグデータ(Athena, EMR等の入力)
✅ CloudFrontオリジン
✅ 99.999999999%の耐久性が必要なデータ
Lambda のストレージ
Lambda で使えるストレージ:
/tmp(一時ストレージ): 最大10GB(エフェメラル)
EFS マウント: 永続的なファイルアクセス
S3: API経由のオブジェクトアクセス
EFSをLambdaにマウント:
→ 機械学習モデルなど大きなファイルを永続的に保存
→ Lambda実行間でデータを共有
→ Lambda VPC設定が必要
試験頻出ポイント
| シナリオ | 回答 |
|---|---|
| 複数EC2から同時に読み書き | EFS |
| EC2のブートボリューム | EBS |
| 最高の耐久性と可用性 | S3(11ナイン) |
| データベースのストレージ | EBS(io2等) |
| 大量のWebコンテンツ保存 | S3 |
| サーバーレスでファイル共有 | EFS(Lambda VPCマウント) |
まとめ
EBSはEC2インスタンスに直接接続するブロックストレージ、EFSは複数インスタンスから共有できるNFSファイルシステム、S3はAPIアクセスのオブジェクトストレージだ。それぞれのレイテンシー、コスト、スケーラビリティの特性を理解して使い分ける。