Cloud Service
Amazon EFS
複数のEC2から同時にマウントできるフルマネージドの共有ファイルストレージ(NFS)。容量は自動で伸縮。
中級SAA-C03SOA-C02SAP-C02信頼性パフォーマンス効率コスト最適化
最終更新: 2026-05-31公式ドキュメント ↗
TL;DR要点だけ先に
- 1.複数サーバーから同時に使える共有フォルダ(NFS)。複数AZで冗長。
- 2.容量は使った分だけ自動で伸縮。プロビジョニング不要で見積り不要。
- 3.共有が要るならEFS、単一の高速ディスクはEBS。マウント不可は2049番。

解決する課題
- 複数サーバーで同じファイルを共有したい(Webコンテンツ・アップロード等)
- 容量の見積り・拡張を気にしたくない
- AZをまたいで冗長に共有したい
主要概念と用語
- マウントターゲット: 各AZでマウントする入口
- パフォーマンスモード / スループットモード
- ストレージクラス: 標準 / 低頻度(IA)(ライフサイクルで自動移行)
- EFS Access Point: アプリ別のアクセス制御
仕様・制限・クォータ
- NFSv4で複数同時マウント
- 複数AZへ冗長化(リージョン内)
- 自動で伸縮(プロビジョニング不要)
内部の仕組み
EFSは複数AZに分散したマネージドなNFSで、各AZのマウントターゲット経由でEC2/コンテナ/Lambdaが同時アクセスします。EBSが1インスタンスのブロックディスクなのに対し、EFSは多数から同時利用できる共有ファイル。容量は書き込みに応じて自動的に増減します。
使い分け
共有が要る=EFS、単一インスタンスの高速ディスク=EBS、静的配信やオブジェクト=S3。
設計パターン / ベストプラクティス
- Web/CMSの共有コンテンツ、コンテナの共有ボリューム
- ライフサイクルで低頻度クラスへ自動移行しコスト削減
- Access Pointでアプリごとに権限/ルートを分離
運用・監視・トラブルシュート
- メトリクス:
PercentIOLimitBurstCreditBalance - マウント不可時はSG(NFS 2049番)・サブネット・マウントターゲットを確認
コスト
- 使用量課金(標準/IA)。ライフサイクル移行でコスト最適化
- EBSより単価は高めだが共有・自動伸縮の価値
セキュリティ
- 保存時暗号化(KMS)、転送時TLS
- SG(2049)・IAM・Access Pointでアクセス制御
Well-Architected の観点
- 信頼性: 複数AZ冗長
- パフォーマンス効率: 自動スケール・並列アクセス
- コスト最適化: IAクラスへの自動移行
試験で問われるポイント
頻出
- 複数EC2から同時マウント=EFS(EBSは原則単一アタッチ)
- 容量は自動伸縮、複数AZ冗長
- マウント不可は**SGの2049番(NFS)**を疑う
📝 EFS ミニ確認テスト第 1 問 / 全 3 問
複数のEC2から同時にマウントして共有したいファイルストレージは?
関連サービス・比較
| 観点 | EFS(ファイル) | EBS(ブロック) | S3(オブジェクト) |
|---|---|---|---|
| アクセス | 複数同時マウント(NFS) | 1インスタンスにアタッチ | HTTP API |
| 容量 | 自動伸縮 | ボリューム単位 | 無制限 |
| 用途 | 共有ファイル | OS/DBディスク | 配信/バックアップ/レイク |
ハンズオン / CLI例
# ファイルシステム作成(暗号化)
aws efs create-file-system --encrypted --tags Key=Name,Value=shared
# EC2 でマウント(amazon-efs-utils)
sudo mount -t efs -o tls fs-0123456789abcdef0:/ /mnt/efs
AWS Service
Amazon EFSを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
ストレージ
比較で見る軸
クラウド: AWS / カテゴリ: ストレージ / 難易度: intermediate
導入後に効く点
容量は使った分だけ自動で伸縮。プロビジョニング不要で見積り不要。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
数字・仕様の読み方
- クラウド
- AWS
- カテゴリ
- ストレージ
- 難易度
- intermediate
- 関連資格
- SAA-C03 / SOA-C02 / SAP-C02
- 設計柱
- reliability / performance / cost
判断チェックリスト
- 自社の用途が「ストレージ / reliability」に近いか確認する。
- 強みである「複数サーバーから同時に使える共有フォルダ(NFS)。複数AZで冗長。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
他クラウドの同等サービス
役割が近いサービスです。設計の置き換えや比較検討の参考に。