Amazon EFS(Amazon Elastic File System、通称AWS EFS)は、AWSが提供するフルマネージド型の共有ファイルストレージです。NFSで複数のEC2インスタンスやコンテナから同時にマウントでき、容量は使った分だけ自動で伸縮します。この記事では「Amazon EFSとは何か」を起点に、S3・EBS・FSxとの違い、東京リージョンの単価と月額の見積もり方、スループットモードの性能上限、CLIでの作成からfstabでの永続マウント、ECS・EKS・Lambdaからの接続までを、2026年9月時点の公式ドキュメントに沿って整理します。
本記事が扱うのはAWSの「EFS」です。キヤノンの一眼レフ用レンズ規格「EF-Sマウント」や、Windowsの暗号化機能「EFS(Encrypting File System)」とは別物なので、検索結果で混ざったときは読み分けてください。
まとめ:Amazon EFSの正体と選ぶ条件・料金・性能設定の要点5つ
先に結論を並べます。根拠と手順は本文で順に示します。
- 正体:複数のEC2・コンテナ・Lambdaから同時にマウントできる、NFSベースのフルマネージド共有ファイルストレージ。容量設計は不要です。
- S3・EBSとの違い:S3は「オブジェクト」、EBSは単一インスタンス向けの「ブロック」、EFSは複数台で共有できる「ファイル」。Linuxで共有ファイルシステムが要るならEFSが第一候補になります。
- FSxとの違い:Windows(SMB)ならFSx for Windows、HPCの並列I/OならFSx for Lustre、NFSとSMBの併用やONTAP資産の移行ならFSx for NetApp ONTAP。EFSはLinux/NFS特化で手離れが良い側です。
- 料金:東京のStandardは1GB・月あたり約0.36ドル。ライフサイクル管理でIA・Archiveへ移すと保管単価は9割以上下がる一方、Elasticの転送料が別にかかります。
- 性能設定:スループットは既定のElastic、パフォーマンスモードはGeneral Purposeで始めるのが公式の推奨です。Max I/Oは旧世代です。
採用を見送るべき場面(データベースの格納先、Windows共有、極端に小さいファイルの大量処理)は、判断の章で条件つきで示します。
Amazon EFSとは:複数のEC2やコンテナから同時に使える共有ファイルストレージ
Amazon EFSは、サーバーやOSの管理が要らないサーバーレス型のファイルストレージです。利用者はファイルシステムを作るだけで、NFSクライアントとしてEC2インスタンスやコンテナからマウントして使えます。ファイルの増減に合わせて容量が自動で拡張・縮小するため、あらかじめストレージサイズを決めてプロビジョニングする必要がありません。
最大の特徴は、複数のサーバーから同じファイルシステムへ同時にアクセスできる点です。Webサーバーを複数台に増やしたとき、アップロード画像や設定ファイルを全台で共有したいケースで効きます。自前でNFSサーバーを構築・運用する負荷をAWSが肩代わりする、という位置づけです。ファイル・オブジェクト・ブロックという3種類のクラウドストレージ全体の整理は、クラウドストレージの仕組みと3つの種類の解説を先に読むと位置関係がつかめます。
マウントターゲット・NFS v4.1・ポート2049で成り立つ接続の仕組み
EFSはVPC内に「マウントターゲット」を作り、そこを経由してクライアントがアクセスします。マウントターゲットはAZごとに1つ作成し、そのAZ内のEC2はマウントターゲット経由でファイルシステムへ接続します。通信はNFS v4.1/v4.0で、TCPポート2049を許可したセキュリティグループが必要です。
ファイル名や所有者、ディレクトリ構造といったメタデータは、どのストレージクラスを使っていても常にStandard側に置かれます(EFSユーザーガイドのライフサイクル管理)。ディレクトリ一覧の表示が低頻度クラスのせいで遅くなることはありません。
close-to-open整合性とファイルロックの上限512個という制約
EFSが保証する整合性は、NFSで一般的な「close-to-open」です。Regionalのファイルシステムでは、アプリがファイルを閉じたとき、またはfsyncなどの同期書き込みを行ったときに、書き込みが複数AZへ永続化されます(EFSの機能一覧)。
ファイルロックはNFS v4の勧告ロック(advisory lock)で、1ファイルあたり全クライアント合計で512個までです。読み書き自体はロックの衝突を確認しません。複数台から同じファイルを追記するアプリは、ロックを取る実装になっているかを移行前に確かめます。
EFSとS3・EBSの違い:ファイル・オブジェクト・ブロックの使い分け
AWSの主要ストレージは、データの持ち方とアクセス方法で性格が分かれます。EFSは「ファイルストレージ」、S3は「オブジェクトストレージ」、EBSは「ブロックストレージ」です。
| 項目 | Amazon EFS | Amazon S3 | Amazon EBS |
|---|---|---|---|
| ストレージ種別 | ファイル | オブジェクト | ブロック |
| アクセス方式 | NFSでマウント | HTTP/S API | EC2にアタッチ |
| 同時共有 | 複数EC2から同時 | 多数から同時 | 原則1インスタンス |
| 容量 | 自動で伸縮 | 実質無制限 | 事前指定・拡張可 |
| 代表用途 | 共有ファイル・コンテナ | バックアップ・静的配信 | OSやDBのディスク |
| 可用性 | 複数AZ(Regional) | 複数AZ | 単一AZ |
共有するならEFS・占有ならEBS・大量保管ならS3という判断の軸
ファイルストレージ(EFS)は、PCの共有フォルダのように階層構造でファイルを扱い、ドライブとしてマウントしてそのまま読み書きできる方式です。オブジェクトストレージ(S3)はファイルを「オブジェクト」として保管し、API経由で出し入れする方式で、バックアップやログ、静的Webコンテンツ、データレイクに向きます。S3のストレージクラスや料金の全体像はAmazon S3の仕組みとストレージクラス・料金の解説で扱っています。
ブロックストレージ(EBS)はEC2に直結する仮想ディスクで、OS本体やデータベースのように低レイテンシで占有したい場面に向きます。ボリュームタイプの選び方はAmazon EBSのボリュームタイプと料金モデルの解説が詳しいです。共有ファイルシステムが必要ならEFS、単一サーバーの高速ディスクならEBS、大量データの保管・配信ならS3、と覚えると迷いません。
S3のデータを動かさずにNFSでマウントしたい場合は、2026年4月に提供が始まったS3 Filesのマウント手順とEFS・Mountpointとの使い分けも候補になります。S3側をブラウザから操作する仕組みはStorage Browser for Amazon S3の解説を参照してください。
EFSとFSxの違い:Windows・Lustre・ONTAP・OpenZFSの選び分け
共有ファイルストレージが欲しいとき、EFSと迷いやすいのがAmazon FSxファミリーです。EFSがLinux/NFS向けのフルマネージドサービスなのに対し、FSxは用途特化のファイルシステムを束ねたサービス群で、Windows(SMB)やHPC、既存ストレージ資産の移行に強みがあります。
| サービス | プロトコル | 主なOS/用途 | 選ぶ場面 |
|---|---|---|---|
| Amazon EFS | NFS | Linux共有・コンテナ | 手離れ良く共有したい |
| FSx for Windows | SMB | Windows・AD統合 | Windowsファイルサーバー移行 |
| FSx for Lustre | Lustre | HPC・機械学習 | 高速並列I/O・S3連携 |
| FSx for NetApp ONTAP | NFS/SMB/iSCSI | マルチプロトコル | ONTAP資産の移行・多機能 |
| FSx for OpenZFS | NFS | ZFS互換ワークロード | スナップショット重視のNFS |
判断の軸はまずプロトコルです。WindowsサーバーがSMBで共有フォルダを参照するならFSx for Windows File Serverが本命で、Active Directoryと統合した権限管理ができます。ゲノム解析や機械学習の学習データのように、大きなスループットと低いレイテンシを要するHPC用途はFSx for Lustreが適し、S3のデータセットを直接リンクして扱えます。
オンプレミスのNetApp ONTAPを使っていて、NFSとSMBを同一ボリュームで併用したい、重複排除やスナップショットといったONTAP機能を残したい場合はFSx for NetApp ONTAPが選択肢です。ONTAPそのものの仕組みはNetApp ONTAPとSVMの解説にまとめています。4つのFSxの料金と採用判断はAmazon FSxの選び分けと料金の解説で比較しました。逆に、LinuxのNFS共有を容量設計なしで始めたいならEFSが最短です。
ストレージクラス3種とライフサイクル管理で保管単価を下げる仕組み
EFSはアクセス頻度に応じてStandard・IA(Infrequent Access)・Archiveの3つのストレージクラスを持ち、ライフサイクル管理でクラス間を自動移動させます。これが保管料金を下げる中心の仕組みです。ストレージクラスとは別軸で、データを複数AZに置くか単一AZに置くかという「ファイルシステムの種別(Regional/One Zone)」の選択もあります(可用性の章で後述)。
| クラス | 想定アクセス頻度 | 初回読み取りの遅延 | 最低保管期間 |
|---|---|---|---|
| EFS Standard | 頻繁 | 1ミリ秒未満 | なし |
| EFS IA | 四半期に数回 | 数十ミリ秒 | なし |
| EFS Archive | 年に数回以下 | 数十ミリ秒 | 90日 |
IAとArchiveは読み書き時にデータアクセス料金がかかり、1ファイルあたり128KiBの最小課金もあります(EFSストレージクラスの比較表)。Archiveはさらに最低90日の保管期間があり、早期に削除すると残り期間分が課金されます。ArchiveはElasticスループットのファイルシステムでしか使えず、Archiveへ移すポリシーを入れた後はBursting・Provisionedへ切り替えられません。
30日でIA・90日でArchiveという既定値と初回アクセス時のStandard復帰
ライフサイクルポリシーは3種類あります。既定では、Standardで30日アクセスされなかったファイルがIAへ、90日アクセスされなかったファイルがArchiveへ移ります。IA・Archiveのファイルにアクセスしたとき、Standardへ戻すかどうかは既定でオフです(ライフサイクル管理の公式説明)。
小さなファイルを大量に読むアプリでは「初回アクセス時にStandardへ戻す」を選ぶと、読み返しのたびにアクセス料金とレイテンシを払う状態を避けられます。CLIでは次のように設定します。
aws efs put-lifecycle-configuration \
--file-system-id fs-0123456789abcdef0 \
--lifecycle-policies \
'[{"TransitionToIA":"AFTER_30_DAYS"},{"TransitionToArchive":"AFTER_90_DAYS"},{"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'
aws efs describe-lifecycle-configuration --file-system-id fs-0123456789abcdef0
IA・Archiveにあるファイルへの書き込みは、いったんStandardに書かれ、24時間後に再び移動対象になります。更新が頻繁なディレクトリを低頻度クラスに置いても、実際にはStandard料金が続く点に注意します。
EFSの料金:東京リージョンの単価と課金要素3つを実額で見積もる手順
EFSは使った分だけ支払う従量課金です。コストは次の3要素で決まります。
- ストレージ料金:保存しているデータ量に、ストレージクラスごとの単価を掛けたもの。
- データアクセス料金:IA・Archiveのデータを読み書きしたとき、またはライフサイクルでクラス間を移したときに発生。
- スループット料金:Elasticは読み書きしたデータ量に、Provisionedは指定したスループットに応じて発生。
東京リージョン(ap-northeast-1)の単価は次のとおりです。AWSのPrice List APIで2026年9月11日公開のデータを2026年9月30日に取得した値で、改定されることがあるため、見積もりの前にAmazon EFSの公式料金ページで取り直してください。
| 課金項目(東京) | 単価(USD) |
|---|---|
| Standard(Regional) | 0.36/GB・月 |
| One Zone(Standard相当) | 0.192/GB・月 |
| IA(Regional) | 0.0272/GB・月 |
| IA(One Zone) | 0.0145/GB・月 |
| Archive | 0.01/GB・月 |
| IAの読み書き | 0.012/GB |
| Archiveの読み書き | 0.036/GB |
| Elastic読み取り | 0.04/GB |
| Elastic書き込み | 0.07/GB |
| Provisioned | 7.20/MiBps・月 |
IAの単価はElasticスループットのファイルシステムでは0.02ドルと別表記になっています。One ZoneはStandard比で約47%安く、IAはStandard比で9割以上安く、ArchiveはIAのさらに半額程度です。
1TBを置いた場合の月額試算とElasticの転送料が膨らむ条件
Regional・Elasticで1,000GBを保管し、月に500GBを読み、100GBを書く構成で比べます。全量をStandardに置くと保管だけで360ドルです。ライフサイクルで200GBをStandard、500GBをIA(Elastic時0.02ドル)、300GBをArchiveに分けると、保管は72+10+3=85ドルまで下がります。
ここにElasticの転送料が乗ります。読み取り500GB×0.04=20ドル、書き込み100GB×0.07=7ドルで27ドルです。IA上のデータを50GB読んだ分のアクセス料0.6ドルを足すと、月額はおよそ113ドルになります。
転送料が保管料を上回るのは、同じファイルを何度も読み書きするバッチや、ログを常時追記する構成です。平均スループットがピークの5%を超えて一定に流れる負荷なら、Provisionedで固定したほうが安くなることがあります。CloudWatchのMeteredIOBytesを1〜2週間見てから決めると外しません。
パフォーマンスモードとスループットモード:Elastic既定の性能上限
EFSの性能は「パフォーマンスモード」と「スループットモード」の二軸で決まります。どちらも、現行の既定値がそのまま公式の推奨です。
| スループットモード | 概要 | 向いている用途 |
|---|---|---|
| Elastic(既定) | 自動でスケール・使った分だけ課金 | 変動的で読めない負荷 |
| Provisioned | スループットを固定で指定 | 常時高く一定の要求 |
| Bursting | 容量に比例+一時的バースト | 保管量が大きく負荷が穏やか |
EFSの性能仕様によると、Regional+Elasticのファイルシステム単位の上限は、読み取り20〜60GiBps・書き込み1〜5GiBps(リージョンで異なる)です。レイテンシは読み取り約1ミリ秒・書き込み約2.7ミリ秒で、既定のIOPS上限は高頻度データの読み取り250,000・書き込み50,000、申請で最大10倍まで引き上げられます。
見落としやすいのはクライアント1台あたりの上限です。Elasticで、EFSクライアント(amazon-efs-utils)2.0以降かEFS CSIドライバでマウントした場合は読み書き合計1,500MiBps、それ以外は500MiBpsに留まります。素のmount -t nfs4でつないでいる古い構成は、クライアントを入れ替えるだけで上限が3倍になります。
BurstingはStandardに置いた容量1GiBあたり50KiBpsが基準で、100GiBなら基準は5MiBpsしかありません。容量が小さいのに負荷が高いファイルシステムでBurstingを選ぶと、クレジットを使い切って遅くなります。迷ったらElasticです。
パフォーマンスモードはGeneral PurposeとMax I/Oの2種類で、General Purposeが既定かつ推奨です。Max I/Oは旧世代のモードで操作ごとのレイテンシが高く、ElasticスループットとOne Zoneでは選べません。新規構築でMax I/Oを選ぶ理由は通常ありません。
可用性・耐久性とアクセス制御:Regional・One Zoneと暗号化の設計
共有ストレージを本番で使うなら、壊れにくさ(耐久性)、止まりにくさ(可用性)、誰がアクセスできるか(アクセス制御)を分けて設計します。
種別は、3つ以上のAZにデータを冗長化する「Regional(推奨)」と、単一AZに保存して単価を約47%下げる「One Zone」の2つです。設計上の耐久性はどちらも99.999999999%(イレブンナイン)ですが、可用性SLAはRegionalが99.99%、One Zoneが99.9%です。One ZoneはそのAZ自体が失われるとデータを失う可能性があるため、再生成できる中間ファイルや開発用途に絞ります。
アクセス制御は多層です。ネットワークではセキュリティグループでポート2049を許可したホストだけに絞り、アプリ側ではIAMポリシーやEFSアクセスポイントでディレクトリ単位・ユーザー単位の権限を設定します。データは保存時・転送時の双方を暗号化でき、鍵はAWS KMSで管理します。VPC内の通信に閉じたい場合のネットワーク設計は、VPCエンドポイントの2種類とNATゲートウェイとの料金比較もあわせて検討してください。
レプリケーションとAWS Backupで別リージョンへ退避する構成の考え方
EFSのレプリケーションは、指定した別リージョン(または同一リージョン)に複製先のファイルシステムを作り、データとメタデータを継続的に同期します。公式の設計目標は、RPO・RTOとも分単位です(EFSレプリケーションの公式説明)。
レプリケーションは「誤削除も複製される」仕組みです。消したファイルを戻したいならAWS Backupで世代を取ります。One Zoneのファイルシステムは、作成時にAWS Backupの自動バックアップが有効になります。障害対策はレプリケーション、誤操作対策はバックアップ、と役割を分けて両方入れるのが本番の基本形です。オンプレミスのNASからEFSへ初回移行する場面では、AWS DataSyncの転送の仕組みと料金で扱った転送サービスを使うと、差分同期で切り替え時間を短くできます。
EFSの使い方:CLIでファイルシステム作成からEC2マウントまでの手順
EFSは「ファイルシステムを作り、マウントターゲットを用意し、EC2からマウントする」流れで使い始めます。以下はAWS CLIでの基本操作です。サブネットIDやセキュリティグループIDは環境に合わせて読み替えてください。
1. ElasticスループットでEFSファイルシステムを暗号化付きで作成
aws efs create-file-system \
--creation-token my-efs-demo \
--performance-mode generalPurpose \
--throughput-mode elastic \
--encrypted \
--tags Key=Name,Value=my-efs-demo
aws efs describe-file-systems --creation-token my-efs-demo \
--query "FileSystems[0].[FileSystemId,LifeCycleState]"
作成後に表示されるファイルシステムID(fs-から始まるID)を控えます。LifeCycleStateがavailableになれば次へ進めます。マネジメントコンソールからウィザード形式で作ることも可能です。
2. AZごとにマウントターゲットを作りポート2049を許可する設定
EC2と同じVPCのサブネットに、使うAZの数だけマウントターゲットを作ります。NFSのポート(TCP 2049)への通信を許可したセキュリティグループの指定が必須です。
aws efs create-mount-target \
--file-system-id fs-0123456789abcdef0 \
--subnet-id subnet-0aaa1111bbbb2222c \
--security-groups sg-0123456789abcdef0
aws ec2 authorize-security-group-ingress \
--group-id sg-0123456789abcdef0 \
--protocol tcp --port 2049 \
--source-group sg-0fedcba9876543210
2つ目のコマンドは、EC2側のセキュリティグループ(sg-0fedcba…)からの2049番だけを許可する例です。CIDRで0.0.0.0/0を開ける必要はありません。
3. efs-utilsでEC2にTLSマウントしfstabで再起動後も維持
EC2側では、AWS推奨のEFSマウントヘルパー(amazon-efs-utilsのGitHubリポジトリ)を使うと、TLS暗号化込みでマウントできます。以下はAmazon Linux 2023の例です(Amazon Linux 2ではdnfの代わりにyumを使います)。
sudo dnf install -y amazon-efs-utils
sudo mkdir -p /mnt/efs
sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/efs
df -h /mnt/efs
# 再起動後も自動でマウントする(/etc/fstab に1行追加)
echo "fs-0123456789abcdef0:/ /mnt/efs efs _netdev,noresvport,tls,iam 0 0" | sudo tee -a /etc/fstab
sudo mount -a
fstabには_netdevを必ず付けます。fstabによる自動マウントの公式手順は、これが無いとネットワーク初期化前にマウントしようとしてインスタンスが応答しなくなる恐れがあると警告しています。EFSが落ちていても起動を優先したいサーバーではnofailも足しておくと安全です。
マウントできないときは、セキュリティグループで2049番が開いているか、EC2と同じAZにマウントターゲットがあるか、iamオプション使用時にインスタンスプロファイルへelasticfilesystem:ClientMount権限があるかの順に確認します。
ECS・EKS・LambdaからEFSをマウントする設定とアクセスポイント
EFSがEBSと決定的に違うのは、コンテナやサーバーレスからも同じファイルシステムを共有できる点です。ECSではタスク定義のvolumesにefsVolumeConfigurationを書けば、Fargateのタスクからでもマウントできます。ECSの起動タイプの違いはAWS ECSの仕組みと起動タイプの解説、簡易デプロイの仕組みはECS Express Modeの使い方を参照してください。
EKSではEFS CSIドライバとStorageClassで動的プロビジョニング
EKSではAmazon EFS CSIドライバを入れ、StorageClassで「PVCごとにアクセスポイントを払い出す」動的プロビジョニングを使うのが定番です。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: efs-sc
provisioner: efs.csi.aws.com
parameters:
provisioningMode: efs-ap
fileSystemId: fs-0123456789abcdef0
directoryPerms: "700"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: shared-data
spec:
accessModes:
- ReadWriteMany
storageClassName: efs-sc
resources:
requests:
storage: 5Gi
EFSは容量が自動で伸びるため、storage: 5Giは形式上の値で、実際の上限にはなりません。ReadWriteManyで複数Podから同時に書けるのがEBSとの差です。EKSのノード提供形態の選び方はAmazon EKSの仕組みとECSとの使い分けで比較しています。
Lambdaはアクセスポイント経由で/mnt配下にマウントする前提条件
Lambdaから使う場合は、関数をEFSと同じVPCに接続し、アクセスポイントを指定して、ローカルのマウントパスを/mnt/で始まる場所にします(LambdaのEFS接続設定の公式説明)。実行ロールにはelasticfilesystem:ClientMountと、書き込むならelasticfilesystem:ClientWriteが要ります。
1つの関数でEFSとS3 Filesを同時には使えません。機械学習モデルや大きな依存ライブラリを関数間で共有したいならEFS、S3にあるデータをそのままファイルとして読みたいならS3 Files、と使い分けます。
EFSの主なユースケースと採用する条件・他サービスへ回す場面
EFSは「複数の実行環境からファイルを共有したい」場面で広く使われます。代表的な用途は次のとおりです。
- Webコンテンツの共有:複数台のWebサーバーで画像やプラグイン、設定ファイルを共有する。
- コンテナの永続ストレージ:ECSやEKS上のコンテナ間で状態やデータを共有する。
- 開発・ビルド環境:チームでソースや中間生成物を共有し、作業を並行して進める。
- データ分析・メディア処理:解析の中間ファイルや映像素材を複数ノードで扱う。集計の格納先としてはAmazon Redshiftのアーキテクチャと組み合わせる構成もあります。
- バックアップ・移行:オンプレミスのNASやファイルサーバー(Linux系)の移行先にする。
EFSを採用する条件:Linuxの複数台が同じファイルを読み書きする構成
採用してよいのは、次の3つがそろうときです。クライアントがLinux(またはLinuxベースのコンテナ・Lambda)であること。2台以上から同じディレクトリを読み書きする必要があること。容量の伸びを事前に読めない、または読みたくないこと。
この3つがそろうなら、自前のNFSサーバーをEC2に立てる選択はまず勝てません。冗長化・パッチ適用・容量拡張の手間がすべて消えるからです。
EFSを見送る場面:DBの格納先・Windows共有・大量の小ファイル処理
逆に、次の場面ではEFSを選びません。1つ目はデータベースのデータファイル置き場です。書き込み約2.7ミリ秒のレイテンシはEBSのgp3やio2に比べて大きく、1台で占有するならEBSが適します。2つ目はWindowsのSMB共有で、これはFSx for Windows File Serverの領分です。
3つ目は、数KBのファイルを数百万個単位で頻繁に作って消す処理です。NFSはリクエストごとに最低4KB分のスループットとして計上され、メタデータ操作の往復も重なるため、ローカルのEBSで処理してから結果だけをEFSやS3へ置くほうが速く安く済みます。
要件がこの境界にかかり、EFS・FSx・EBSのどれを組み合わせるか決めきれない場合は、AWS・Google Cloud・Azureのインフラ構築支援で、既存環境の棚卸しから構成設計・移行まで相談を受け付けています。
よくある質問
Amazon EFSについて、検索でよく調べられている疑問に答えます。
Q. Amazon EFSとAWS EFSは同じものですか?
同じサービスです。正式名称はAmazon Elastic File System(Amazon EFS)で、AWSのサービスであることから「AWS EFS」とも呼ばれます。中身は、複数のEC2やコンテナからNFSで同時にマウントできるフルマネージドの共有ファイルストレージです。容量は自動で伸縮し、使った量と転送量に応じて課金されます。
Q. EFSとS3はどちらを使うべきですか?
OSにマウントしてファイルとして直接読み書きしたい、複数サーバーで共有したいならEFSです。APIで大量データを保管・配信したい、バックアップやデータレイクに使いたいならS3が適します。保管単価はS3のほうが安いため、S3のデータをファイルとして読みたいだけなら、S3 Filesでマウントする方法も比べてください。
Q. EFSの料金は高いと聞きますが、抑える方法は?
東京のStandardは1GB・月あたり約0.36ドルで、S3やEBSより高めです。抑える基本は、ライフサイクル管理でアクセスの少ないデータをIA・Archiveへ自動移動させることです。マルチAZが不要ならOne Zoneで約47%下がります。頻繁に読み書きするデータはStandardに残し、転送量が一定ならProvisionedとの比較も試算します。
Q. WindowsサーバーからEFSは使えますか?
EFSはNFSベースで、Linux系からの利用を前提にしています。Windowsファイルサーバー(SMB)を移行したい場合は、Amazon FSx for Windows File Serverが適した選択肢です。WindowsとLinuxの両方から同じデータを使いたいなら、NFSとSMBを併用できるFSx for NetApp ONTAPを検討します。
Q. 「EFS」で検索するとカメラのレンズが出てきますが?
「EF-S」はキヤノンの一眼レフ用レンズマウント規格で、AWSのEFSとは無関係です。Windowsのファイル暗号化機能「EFS(Encrypting File System)」も別物です。AWSのファイルストレージを調べるときは「Amazon EFS」「AWS EFS」と書くと区別しやすくなります。
Q. パフォーマンスモードとスループットモードはどれを選べばよいですか?
パフォーマンスモードはGeneral Purpose、スループットモードはElasticが既定で、公式もこの組み合わせを推奨しています。Max I/Oは旧世代でレイテンシが高く、Elasticとも併用できません。平均の転送量がピークの5%を超えて安定しているとわかった段階で、Provisionedへの切り替えを検討します。
関連記事
- Amazon FSxとは?4つのファイルシステムの選び分けと料金・採用判断を実装者目線で解説:EFSで足りない場合の選択肢を比較
- S3 Filesとは:S3バケットをNFSでマウントする手順とEFS・Mountpointとの使い分け:S3をファイルとして使う別解
- Amazon EBSとは?仕組み・ボリュームタイプと料金モデル・採用判断を実装者目線で解説:単一インスタンス向けブロックストレージ
- Amazon S3とは?オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説:大量保管・配信の基盤
- VPCエンドポイントとは|2種類の違いとNATゲートウェイとの料金比較・損益分岐点:EFSを置くVPCのネットワーク設計