EFS vs EBS vs S3 — AWS ストレージの選択基準
AWS のストレージのドキュメントを開くと EBS、EFS、S3 が並んでいますが、3 つは同じ役割を取り合うサービスではありません。1 台のインスタンスに接続するディスクは EBS、複数のインスタンスが同時にマウントする共有ファイルシステムは EFS、アプリケーションの外でファイルを保存して取り出すオブジェクトストレージは S3 です。 アクセスモデルが違うので、ほとんどのシステムは 3 つを併用します。悩ましいのは境界にまたがるワークロードで、この記事はその境界を料金と合わせて整理します。料金は us-east-1 基準です。
ひと目でわかる比較 #
| 区分 | EBS (gp3) | EFS (Standard) | S3 (Standard) |
|---|---|---|---|
| タイプ | ブロックストレージ | ファイルストレージ (NFS) | オブジェクトストレージ (HTTP API) |
| アクセス | インスタンス 1 台に接続 | 数百〜数千台が同時マウント | どこからでも API 呼び出し |
| 範囲 | 単一 AZ | リージョン (マルチ AZ) | リージョン (マルチ AZ) |
| 遅延 | ミリ秒未満 | ミリ秒台 | 数十ミリ秒 (最初のバイト) |
| 容量 | プロビジョニング (最大 64TiB) | 自動拡張 | 事実上無制限 |
| GB・月あたり単価 | 約 $0.08 | 約 $0.30 | 約 $0.023 |
アクセスモデル — ディスクか、共有フォルダーか、API か #
EBS はインスタンスに接続するディスクです。OS からはブロックデバイスとして見えるので、ファイルシステムを載せてブートボリュームやデータベースのデータディレクトリとして使います。遅延はミリ秒未満と 3 つの中で最も低く、IOPS をスペックとして保証できるため、ランダム I/O の多いデータベースには事実上 EBS 以外の選択肢がありません。制約は接続範囲です。ボリュームは単一 AZ にあり、基本的にインスタンス 1 台にしか接続できません(io1・io2 の Multi-Attach が例外ですが、クラスターファイルシステムを要求する特殊な構成です)。ボリュームタイプの選択は gp3 vs io2 で扱いました。
EFS は NFS でマウントする共有ファイルシステムです。数百〜数千台のインスタンス、コンテナ、Lambda が同じパスを同時にマウントし、容量は書いた分だけ自動で増えます。Standard クラスはマルチ AZ なので、AZ 障害でも生き残ります。複数の Web サーバーが共有するアップロードディレクトリ、複数のタスクが同じモデルファイルを読む ML サービング、リフトアンドシフトで持ち込んだ NFS 依存のレガシーが典型的な使いどころです。
S3 は HTTP API で出し入れするオブジェクトストレージです。マウントするのではなく、PUT と GET を呼び出します。ファイルの一部だけを修正することはできずオブジェクト全体を上げ直す必要があり、最初のバイトまで数十ミリ秒かかります。その代わり容量は事実上無制限で、99.999999999%(イレブンナイン)の耐久性に、静的 Web ホスティング、バージョニング、ライフサイクルポリシーまで付いています。バックアップ、ログ、画像・動画、データレイクのような「書いたら丸ごと読む」データのデフォルトです。
料金 — 単価だけ見ると間違え、課金方式まで見て正解です #
GB・月あたりの単価は S3 $0.023、EBS gp3 $0.08、EFS Standard $0.30 の順で、EFS は gp3 の約 4 倍、S3 の 13 倍です。ただし課金方式が違うため、単価の比較だけでは結論が出ません。
- EBS はプロビジョニングした分だけかかります。500GB を確保して 100GB しか使わなくても 500GB 分の料金です。gp3 は 3,000 IOPS と 125MB/s が基本料金に含まれるので、追加性能を買わなければあの単価がすべてです。
- EFS は保存した分にかかりますが、Elastic Throughput 基準で読み取り GB あたり約 $0.03、書き込み GB あたり約 $0.06 のスループット料金が別途付きます。データを頻繁に読み書きするファイルシステムなら、保存料金よりスループット料金のほうが大きくなることもあります。一方でライフサイクルポリシーで使わないファイルを IA(GB あたり約 $0.016)、Archive(約 $0.008)へ下げれば保存単価は gp3 を下回り、単一 AZ で十分なら One Zone(約 $0.16)もあります。
- S3 は保存した分 + リクエスト数にかかります。PUT 1,000 件あたり約 $0.005、GET 1,000 件あたり約 $0.0004 です。大容量の保存には圧倒的に安いのですが、小さなファイル数百万個を頻繁に触るパターンだとリクエスト料金が本体を超えます。アクセス頻度別のクラス選択は S3 ストレージクラス比較で扱いました。
ありがちな過剰設計と落とし穴 #
- 共有が不要なのに EFS: インスタンス 1 台しか使わないデータを EFS に置くと、gp3 の 4 倍の単価にスループット料金まで払うことになります。共有の要件が実際に生まれたときに移しても遅くありません。
- S3 をファイルシステムのように使うこと: Mountpoint for S3 でマウントはできますが、シーケンシャルな読み書き中心のツールで、ファイルの部分修正やロックのような POSIX の動作はサポートされません。ファイルシステムのセマンティクスが必要なら EFS が適しています。
- データベースを EFS に置くこと: ミリ秒台の遅延と NFS のセマンティクスは、データベースのランダム I/O と相性がよくありません。データディレクトリは EBS に置くのが基本です。
- スナップショットと放置ボリューム: EBS スナップショットは S3 ベースの保存(GB・月あたり約 $0.05)に積み上がり、インスタンスを消してもボリュームとスナップショットは残って課金され続けます。常時点検リストで扱った代表的な漏れの項目です。
選択の手順 #
- アクセスモデルから決めます: OS がディスクとして見る必要があれば EBS、複数のコンピューティングが同じファイルツリーをマウントする必要があれば EFS、API で出し入れすれば済むデータなら S3 です。ここでほとんど決まります。
- 共有の要件を検証します: EFS を選ぶ前に「本当に複数台が同時に同じパスを使う必要があるのか?」を問います。そうでなければ EBS か S3 に下ります。
- 遅延の要件を確認します: ミリ秒未満が必要なら EBS だけです。数十ミリ秒が許容されるなら S3 まで選択肢が広がります。
- コストは課金方式どおりに計算します: EBS はプロビジョニング容量、EFS は保存 + スループット、S3 は保存 + リクエストでそれぞれ計算して、初めて実際の請求書になります。
- ライフサイクルを設計します: EFS は IA・Archive で、S3 はクラス移行で古いデータの単価を下げます。EBS は使っていないボリューム・スナップショットの整理がライフサイクル管理のすべてです。
まとめ #
- インスタンス 1 台のディスクは EBS、複数台で共有するファイルシステムは EFS、API でアクセスするオブジェクトは S3 です。3 つは競合ではなく分業の関係です。
- 単価は S3 $0.023、gp3 $0.08、EFS $0.30 と最大 13 倍開きますが、課金方式(プロビジョニング、保存+スループット、保存+リクエスト)が違うため、単価だけでは比較になりません。
- EFS のスループット料金(読み取り $0.03、書き込み $0.06)は忘れられがちな項目です。I/O が多ければ保存料金を超えます。
- 最もありがちな過剰設計は、共有が不要なデータを EFS に置くことです。共有の要件が実際にあるのかをまず検証します。
- データベースは EBS、アップロードとモデル共有は EFS、バックアップ・ログ・静的ファイルは S3 という基本配置から出発して例外を検証する順序が早道です。