ラボ概要
本ラボは、同一 VPC 内の複数 EC2 インスタンスから共有できる Amazon EFS ファイルシステムを構築し、その挙動を検証することを目的としています。
環境構成
– **EKS**: 2 台の Amazon Linux 2023 EC2（EC2‑1、EC2‑2）
– **EFS**: ファイルシステム ID `fs-083c15edb9f9076c7`（名前は EFS_LAB）
– **セキュリティグループ**
– `ec2-sg`: 自分の IP からの SSH(22) を許可
– `efs-sg`: `ec2-sg` からの NFS(2049) を許可
手順と検証
1. 両インスタンスに同一 EFS をマウントし、EC2‑1 が書き込んだファイルが EC2‑2 でも閲覧できることを確認。
2. NFS ポート 2049 の受信ルールを一時的に削除し、書き込みが失敗することを確認。その後ルールを復元し、再度書き込みが成功することを確認。
3. EFS のライフサイクル管理を設定し、最終アクセスから 7 日で IA（低頻度アクセス）へ自動移行するポリシーを作成。実際の移行は 7 日経過まで観測しない。
4. `/etc/fstab` に EFS エントリを追加し、インスタンス再起動後も自動的にマウントされる永続マウントをテスト。EC2‑1 は手動マウントのみで再起動後に消失、EC2‑2 は fstab により再起動後もマウントが保持された。
EBS ↔ EFS コピー実験
– ルート EBS の容量は約 8 GB（使用 1.8 GB）。
– `/tmp` は tmpfs だったため、テストファイルを `/home/ec2-user` に移動。
– 1 GiB のテストファイルを EBS 上で作成し、EBS→EBS のコピーは瞬時に完了。
– 同ファイルを sudo 権限で EFS にコピーし、正常に転送できたことを確認。
– ベンチマーク結果は、EBS→EBS が約 0.005 秒、EBS→EFS が約 7.5 秒となり、キャッシュ効果などに留意すべき旨を記載。
トラブルシューティングと重要ポイント
– NFS アクセスはセキュリティグループで限定し、ポート 2049 を広く公開しない。
– `/etc/fstab` の変更は `mount -a` で事前検証し、永続マウントには `_netdev` オプションを使用。
– ネットワーク障害とファイルシステムの権限は別々に切り分けて診断。
– ライフサイクル管理は実際のアクセスパターンに合わせて設定し、不要な課金を防止。
– ベンチマークはキャッシュやインスタンスタイプ、ストレージモードの影響を受けるため、単純比較は避ける。
クリーンアップ
ラボ終了後は、作成した EFS、EC2 インスタンス、セキュリティグループ、およびテストファイルを削除し、無駄な費用が発生しないようにする。
まとめ
本ラボは、EFS のマルチインスタンス共有、障害時の挙動、ライフサイクル管理、永続マウント、そして EBS との性能比較を通じて、EFS がネットワークファイルシステムとして、EBS がブロックストレージとしてそれぞれ適したユースケースを体感できる構成となっています。
元記事: https://dev.to/tejas_shinkar/amazon-efs-hands-on-lab-1l2l