複数EC2インスタンス間でフォルダを共有する：EBSとEFSの使い分け完全ガイド

5台のEC2インスタンスで同じディレクトリをマウントしたい——この要件を受けて、まずEBSのマルチアタッチを試みたエンジニアは少なくない。結論から言うと、EBSは原則として複数インスタンスへの同時共有には向いておらず、EC2間でフォルダを共有するにはAmazon EFS（Elastic File System）が正しい選択肢になる。

TL;DR：EBS vs EFS、複数インスタンス共有の判断基準

観点EBSEFS
複数インスタンスへの同時マウント原則不可（Multi-Attachは限定的）可能（同一リージョン内）
対応ストレージプロトコルブロックストレージNFSv4.1 / NFSv4.0
ファイルシステム共有不可（Multi-Attach時もファイルシステム層は非共有）可能（POSIX準拠）
対応インスタンス数Multi-Attachは最大16インスタンス（io1/io2のみ）数千インスタンスまでスケール
AZ制約同一AZのみリージョン内複数AZに対応
ユースケース単一インスタンスのOSディスク、DB共有コンテンツ、ログ集約、CMS

EBSとEFSの仕組み：なぜEBSでは共有できないのか

EBSはブロックストレージデバイスとして動作する。EC2インスタンスにアタッチされると、インスタンス側でext4やxfsなどのファイルシステムをフォーマットして使う構造になっている。ファイルシステムのメタデータ（inode、ジャーナル）はEBSボリューム上に書き込まれるため、複数のインスタンスが同じボリュームを同時にマウントすると、メタデータが競合してファイルシステムが破損する。

EBSにはio1/io2ボリュームタイプ限定でMulti-Attachという機能があり、最大16インスタンスへの同時アタッチが可能だ。ただし、これはブロックデバイスレベルの共有であり、ファイルシステムの同時書き込みを安全に扱うにはクラスタ対応ファイルシステム（例：GFS2）をアプリケーション側で実装する必要がある。通常のext4/xfsでMulti-Attachを使うことは、データ破損のリスクを伴うため推奨されない。

EBSのMulti-Attachは『同じ物理ディスクを複数のサーバーに差し込む』イメージに近い。ケーブルは繋がっていても、ファイルシステムの調停機構がなければ書き込みが衝突する。

一方、EFSはNFSv4プロトコルをベースにしたマネージドファイルサービスだ。各EC2インスタンスはNFSクライアントとしてEFSのマウントターゲットに接続し、POSIX準拠のファイル操作を行う。ファイルシステムのメタデータ管理はEFS側が担うため、複数インスタンスからの同時読み書きが安全に機能する。

graph TD subgraph EBS_Case["EBS：単一インスタンス構成"] EBS_Vol["EBSボリューム
（単一AZ）"] EC2_A["EC2 Instance A
ext4マウント"] EC2_B["EC2 Instance B
（マウント不可）"] EBS_Vol -->|"アタッチ"| EC2_A EBS_Vol -.->|"同時マウント→破損リスク"| EC2_B end subgraph EFS_Case["EFS：複数インスタンス共有構成"] EFS_FS["EFSファイルシステム"] MT_1A["マウントターゲット
us-east-1a"] MT_1B["マウントターゲット
us-east-1b"] EC2_1["EC2 Instance 1"] EC2_2["EC2 Instance 2"] EC2_3["EC2 Instance 3"] EC2_4["EC2 Instance 4"] EC2_5["EC2 Instance 5"] EFS_FS --> MT_1A EFS_FS --> MT_1B MT_1A -->|"NFS v4"| EC2_1 MT_1A -->|"NFS v4"| EC2_2 MT_1A -->|"NFS v4"| EC2_3 MT_1B -->|"NFS v4"| EC2_4 MT_1B -->|"NFS v4"| EC2_5 end
  1. EBSの場合：ボリュームは単一AZ内に存在し、通常は1インスタンスにアタッチ。ファイルシステム（ext4等）はインスタンス側で管理される。
  2. EFSの場合：各AZにマウントターゲットが配置され、複数インスタンスがNFSクライアントとして同時接続できる。ファイルシステム管理はEFS側が担う。
  3. Multi-Attach EBS：ブロックデバイスは共有されるが、ファイルシステム層の競合制御はアプリケーション責任。通常構成では使用しない。

EFSで複数EC2インスタンス間のフォルダ共有を設定する

以下の手順で、5台のEC2インスタンスから同一のEFSファイルシステムをマウントする構成を構築する。前提として、EC2インスタンスとEFSは同一VPC内に存在することが必要だ。

ステップ1：EFSファイルシステムを作成する

まずEFSファイルシステムを作成する。ここでスループットモードやパフォーマンスモードを決定する。後から変更できる設定もあるが、ワークロードに合わせて最初から適切に選択しておくことで、予期しないコスト増を防げる。

aws efs create-file-system \
  --performance-mode generalPurpose \
  --throughput-mode bursting \
  --encrypted \
  --region us-east-1 \
  --tags Key=Name,Value=shared-efs

コマンド実行後、出力に含まれる FileSystemId（例：fs-0123456789abcdef0）を控えておく。以降のステップで使用する。

ステップ2：マウントターゲット用セキュリティグループを作成する

EFSのマウントターゲットはNFSポート（2049/TCP）でトラフィックを受け付ける。EC2インスタンスのセキュリティグループからのインバウンドのみを許可するセキュリティグループを作成する。これにより、VPC内の意図しないリソースからのアクセスを遮断できる。

# EFS用セキュリティグループを作成
aws ec2 create-security-group \
  --group-name efs-mount-sg \
  --description "Security group for EFS mount targets" \
  --vpc-id vpc-0abcdef1234567890 \
  --region us-east-1
# EC2インスタンスのセキュリティグループからNFS(2049)を許可
aws ec2 authorize-security-group-ingress \
  --group-id sg-0efs1234567890abc \
  --protocol tcp \
  --port 2049 \
  --source-group sg-0ec21234567890abc \
  --region us-east-1

ステップ3：各AZにマウントターゲットを作成する

EC2インスタンスが複数のAZに分散している場合、各AZのサブネットにマウントターゲットを作成する必要がある。マウントターゲットはAZごとに1つ作成する。同一AZ内の複数サブネットに対して複数のマウントターゲットを作成することはできない。

# AZ: us-east-1a のサブネットにマウントターゲットを作成
aws efs create-mount-target \
  --file-system-id fs-0123456789abcdef0 \
  --subnet-id subnet-0abc1234567890001 \
  --security-groups sg-0efs1234567890abc \
  --region us-east-1
# AZ: us-east-1b のサブネットにマウントターゲットを作成
aws efs create-mount-target \
  --file-system-id fs-0123456789abcdef0 \
  --subnet-id subnet-0abc1234567890002 \
  --security-groups sg-0efs1234567890abc \
  --region us-east-1

ステップ4：EC2インスタンスにEFSマウントヘルパーをインストールしてマウントする

AWSはEFSマウント用のヘルパーツール（amazon-efs-utils）を提供している。このヘルパーを使うことで、TLS暗号化マウントや自動再接続が簡単に設定できる。手動でNFSマウントオプションを管理するよりも、本番環境ではこちらを使うべきだ。

# Amazon Linux 2 / Amazon Linux 2023の場合
sudo yum install -y amazon-efs-utils

# Ubuntuの場合
sudo apt-get install -y amazon-efs-utils
# マウントポイントを作成
sudo mkdir -p /mnt/shared

# EFSをTLS付きでマウント（amazon-efs-utilsを使用）
sudo mount -t efs -o tls fs-0123456789abcdef0:/ /mnt/shared

5台すべてのEC2インスタンスで同じコマンドを実行すれば、/mnt/sharedディレクトリが共有される。

ステップ5：再起動後も自動マウントされるよう/etc/fstabに追記する

インスタンス再起動後もマウントが維持されるよう、/etc/fstabに設定を追加する。_netdevオプションを必ず付けること——これがないと、ネットワーク初期化前にマウントを試みてブート失敗につながる。

echo "fs-0123456789abcdef0:/ /mnt/shared efs _netdev,tls 0 0" | sudo tee -a /etc/fstab

ステップ6：EC2インスタンスのIAMロールにEFSアクセス権限を付与する（EFS Access Points使用時）

EFS Access Pointsを使用してアクセス制御を行う場合、EC2インスタンスにアタッチされたIAMロールに適切なポリシーが必要になる。IAM認証を使わない基本構成ではセキュリティグループのみで制御されるが、本番環境ではIAM認証の併用を検討すること。

🔽 EFSアクセス用IAMポリシー例（クリックして展開） 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:ClientMount",
        "elasticfilesystem:ClientWrite",
        "elasticfilesystem:ClientRootAccess"
      ],
      "Resource": "arn:aws:elasticfilesystem:us-east-1:123456789012:file-system/fs-0123456789abcdef0"
    }
  ]
}

実際の障害パターン：EBSを共有しようとして起きたこと

あるチームが、EBSボリュームをio2でMulti-Attachし、ext4でフォーマットしたまま2台のインスタンスに同時マウントした。最初の数時間は問題なく動作しているように見えた。しかし翌朝、ファイルシステムのジャーナルが破損し、両インスタンスでread-onlyリマウントが発生した。

原因は明確だった。ext4のジャーナルは単一ライターを前提に設計されており、2台のインスタンスが独立してジャーナルに書き込んだ結果、メタデータが矛盾した状態になった。dmesgにはEXT4-fs errorが大量に記録されており、fsckを実行するためにボリュームをデタッチする必要があった。

Multi-Attachは『複数インスタンスから同時に安全に読み書きできる』機能ではない。ブロックデバイスへの同時アクセスを可能にするだけで、ファイルシステムの整合性保証はアプリケーション側の責任になる。この区別を理解していないと、データ損失につながる。

graph LR A["Multi-Attach EBS
io2ボリューム"] -->|"同時アタッチ"| B["EC2 Instance 1
ext4マウント"] A -->|"同時アタッチ"| C["EC2 Instance 2
ext4マウント"] B -->|"ジャーナル書き込み"| D["ジャーナル競合
メタデータ破損"] C -->|"ジャーナル書き込み"| D D --> E["read-onlyリマウント
EXT4-fs error"] E --> F["fsck実行のため
デタッチ必要"] style D fill:#ff6b6b,color:#fff style E fill:#ff6b6b,color:#fff
  1. 誤った前提：Multi-Attachを有効にすれば複数インスタンスで安全に共有できると判断。
  2. 実際の動作：ext4ジャーナルが2インスタンムから独立して書き込まれ、メタデータが破損。
  3. 正しい対処：ファイル共有要件にはEFSを使用。Multi-Attachはクラスタ対応FSと組み合わせる場合のみ検討。

EFSのパフォーマンスモードとスループットモードの選択

EFSには2つのパフォーマンスモードと複数のスループットモードがある。ファイルシステム作成後にパフォーマンスモードは変更できないため、最初の選択が重要になる。

設定オプション適したユースケース
パフォーマンスモードGeneral Purpose（推奨）レイテンシ敏感なワークロード（Webサーバー、CMS）
パフォーマンスモードMax I/O高並列アクセス（ビッグデータ処理）
スループットモードBurstingアクセスパターンが断続的なワークロード
スループットモードElastic予測困難なスループット要件
スループットモードProvisioned一定の高スループットが必要なワークロード

5台程度のWebサーバーで静的コンテンツやアップロードファイルを共有する用途であれば、General Purpose + Burstingの組み合わせが出発点として適切だ。スループットが不足する場合はElasticモードへの切り替えを検討する。

マウント状態の確認とトラブルシューティング

EFSが正しくマウントされているかを確認するには、各インスタンスで以下を実行する。マウントが成功していれば、df -hの出力にEFSのマウントポイントが表示される。

# マウント状態の確認
df -h | grep efs

# マウントターゲットの状態確認（AWSコンソール代替）
aws efs describe-mount-targets \
  --file-system-id fs-0123456789abcdef0 \
  --region us-east-1
# NFS接続の確認
showmount -e fs-0123456789abcdef0.efs.us-east-1.amazonaws.com

マウントに失敗する場合、最初に確認すべきはセキュリティグループだ。EC2インスタンスのセキュリティグループからEFSマウントターゲットのセキュリティグループへ、ポート2049/TCPのアウトバウンドが許可されているかを確認する。次にVPCのルートテーブルを確認し、EC2インスタンスのサブネットからEFSマウントターゲットのサブネットへの経路が存在することを確認する。

複数EC2インスタンス間のフォルダ共有：EFSが答えになる理由まとめ

5台のEC2インスタンスでフォルダを共有したい場合、EFS（Elastic File System）を使うのが正しいアプローチだ。EBSはブロックストレージとして設計されており、ファイルシステム層の同時書き込み制御を持たないため、通常の構成では複数インスタンスへの安全な共有に使えない。EFSはNFSv4プロトコルをベースに、POSIX準拠のファイル共有をマネージドサービスとして提供する。

設定の要点は3つ：EFSファイルシステムの作成、各AZへのマウントターゲット配置、EC2インスタンスへのamazon-efs-utilsを使ったマウント設定。セキュリティグループでNFSポート（2049/TCP）の制御を忘れずに行うこと。

次のステップとして、EFS Access Pointsを使ったディレクトリ単位のアクセス制御や、EFSのライフサイクル管理（低頻度アクセスデータの自動階層化）を検討することで、セキュリティとコストの両面を最適化できる。

用語集

用語説明
EBS（Elastic Block Store）EC2インスタンス用のブロックストレージサービス。通常は単一インスタンスにアタッチして使用する。
EFS（Elastic File System）NFSv4プロトコルベースのマネージドファイルストレージ。複数インスタンスからの同時アクセスをサポートする。
マウントターゲットEFSへのネットワーク接続エンドポイント。各AZのサブネットに配置する。
Multi-AttachEBSのio1/io2ボリュームを複数インスタンスに同時アタッチする機能。ファイルシステムの同時書き込み保護は含まない。
NFS（Network File System）ネットワーク越しにファイルシステムを共有するプロトコル。EFSはNFSv4.0/4.1をサポートする。

Related Posts

コメント

コメントを投稿

このブログの人気の投稿

SQS Visibility Timeoutの完全解説：メッセージ二重処理の原因と対策

SQSキューから取得したメッセージが複数のコンシューマーに重複処理される——この問題はVisibility Timeoutの設定ミスが原因であることがほとんどだ。処理時間がタイムアウト値を超えた瞬間、SQSはそのメッセージを「未処理」と判断して再度可視化し、別のワーカーが同じメッセージを拾ってしまう。 TL;DR：Visibility Timeoutとは何か 項目 内容 定義 コンシューマーがメッセージを受信してから、他のコンシューマーに見えなくなる時間 デフォルト値 30秒 設定範囲 0秒〜43,200秒（12時間） 二重処理の原因 処理時間がVisibility Timeoutを超えるとメッセージが再可視化される 対策 処理時間に余裕を持たせた値を設定、または処理中に延長APIを呼ぶ 削除タイミング 処理完了後に明示的に DeleteMessage を呼ぶ必要がある Visibility Timeoutの仕組みを理解する SQSはメッセージを受信した時点でそのメッセージを一時的に「不可視」にする。これはキューからメッセージを削除するわけではなく、他のコンシューマーから見えなくするだけだ。コンシューマーが処理を完了して DeleteMessage を呼べばメッセージは消える。しかしVisibility Timeoutが切れる前に削除されなければ、メッセージはキューに戻り、再度取得可能になる。 この設計は意図的なものだ。コンシューマーがクラッシュしたり応答しなくなった場合に、メッセージが失われないようにするためのフェイルセーフとして機能している。問題は、正常に動作しているコンシューマーの処理時間がタイムアウトを超えたときに、同じフェイルセーフが誤発動することだ。 sequenceDiagram participant CA as コンシューマーA participant SQS as SQS キュー participant CB as コンシューマーB CA->>SQS: ReceiveMessage SQS...
続きを読む

EC2 SSH接続タイムアウトの原因と修正方法 — セキュリティグループのインバウンドルール完全ガイド

新しいEC2インスタンスを起動してSSH接続を試みたとき、 ssh: connect to host xx.xx.xx.xx port 22: Connection timed out というエラーで止まった経験は多くのエンジニアにある。アプリケーションのエラーではなく、パケットがインスタンスに届いていないことを示すタイムアウトだ。原因の大半はセキュリティグループのインバウンドルール設定にあるが、それだけで解決しないケースも存在する。 TL;DR — EC2 SSHタイムアウトの主な原因と対処 原因レイヤー 確認項目 修正方向 セキュリティグループ ポート22のインバウンドルールが存在するか TCP 22をソースIPに対して許可 ネットワークACL サブネットレベルでポート22がブロックされていないか インバウンド/アウトバウンド両方のルールを確認 パブリックIPアドレス インスタンスにパブリックIPが割り当てられているか ElasticIPの関連付けまたはパブリックIP自動割り当ての有効化 インターネットゲートウェイ VPCにIGWがアタッチされているか IGWを作成してVPCにアタッチ ルートテーブル サブネットのルートテーブルに0.0.0.0/0 → IGWのルートがあるか デフォルトルートをIGWに向ける EC2 SSH接続の仕組み — パケットが届くまでの経路 SSHタイムアウトを正確に診断するには、クライアントのパケットがEC2インスタンスに到達するまでに通過するレイヤーを理解する必要がある。セキュリティグループだけを見て終わりにすると、別のレイヤーでブロックされているケースを見逃す。 graph LR Client["クライアント ローカルマシン"] -->|"TCP SYN port 22"| IGW["インターネット ゲートウェイ (IGW)"] IGW --> RT["ルートテーブル 0.0.0.0/0 → IGW"] RT --> ...
続きを読む

S3パブリックアクセス拒否の原因と解決策：バケットレベルの「Block Public Access」が優先される仕組み

S3に画像をアップロードしてオブジェクトACLを「public-read」に設定したのに、URLにアクセスすると「Access Denied」が返ってくる。オブジェクト単体の設定は正しいはずなのに、なぜ拒否されるのか——この問題の原因はほぼ確実に、バケットレベルの「Block Public Access」設定にある。オブジェクトACLより上位のレイヤーが存在することを知らないと、何度設定を変えても解決しない。 TL;DR：S3パブリックアクセス拒否の原因まとめ 確認レイヤー 設定項目 影響範囲 アカウントレベル S3 Block Public Access（アカウント全体） 全バケットに適用 バケットレベル S3 Block Public Access（バケット個別） そのバケット内の全オブジェクト バケットポリシー Principal: * を許可するポリシーの有無 ポリシーで指定したリソース オブジェクトACL public-read ACL 個別オブジェクト 結論： オブジェクトACLを「public-read」にしても、バケットまたはアカウントレベルの「Block Public Access」が有効な場合、そのACLは無効化される。上位レイヤーの設定が下位を上書きする構造になっている。 S3パブリックアクセス制御の仕組み：なぜオブジェクトACLだけでは不十分か S3のアクセス制御は複数のレイヤーが重なって機能する。オブジェクトACLはその中で最も下位のレイヤーに位置する。AWSは2018年以降、誤ったパブリック公開によるデータ漏洩を防ぐため「Block Public Access」という上位の制御機構を導入した。この設定が有効な場合、オブジェクトACLやバケットポリシーで「public」を許可しようとしても、Block Public Accessがそれを遮断する。 Block Public Accessには4つの独立した設定項目がある。それぞれが異なるシナリオをカバーしており、全部オフにしないとパブリックアクセスが通らないケースもある。 graph TD A[...
続きを読む