東京リージョンの EFS をバージニア北部リージョンの EC2 インスタンスから VPC ピアリング経由でマウントしてみた

はじめに

テクニカルサポートの 片方 です。

今回は、異なる VPC に存在する EFS を、VPC ピアリング経由で EC2 インスタンスからマウントできるか検証しました。

EFS は、複数の EC2 インスタンスから利用できるフルマネージドな NFS ファイルシステムです。通常は EFS ファイルシステムと同じ VPC 内の EC2 インスタンスから利用することが多いですが、構成によっては別 VPC の EC2 インスタンスから利用したいケースもあります。
AWS 公式ドキュメントでは、VPC ピアリング接続または AWS Transit Gateway で VPC 間を接続することで、別 VPC の EC2 インスタンスから EFS にアクセスできることが説明されています。
なお、別 VPC から EFS をマウントする際の名前解決には、Route 53 プライベートホストゾーンを利用する方法もあります。本記事では検証をシンプルにするため、EC2 インスタンスの /etc/hosts に EFS マウントターゲットの IP アドレスを登録する方法で検証しました。

https://docs.aws.amazon.com/efs/latest/ug/efs-different-vpc.html

構成

今回の検証環境は以下のとおりです。

本ブログでは、東京リージョンの EFS を、バージニア北部リージョンの EC2 インスタンスからマウントする構成で検証します。

構成イメージは以下です。

us-east-1
N. Virginia-vpc（192.168.0.0/24）
  └─ EC2（Amazon Linux 2023）
        |
        | VPC Peering
        |
ap-northeast-1
test-vpc（10.0.0.0/16）
  └─ EFS Mount Target（例: 10.0.xxx.xxx）
      └─ Amazon EFS

前提条件

本記事では、以下を前提とします。

• 検証に必要な AWS リソースを作成・変更できる権限があること
• test-vpc と N. Virginia-vpc の CIDR ブロックが重複していないこと
• EC2 インスタンスへ接続できること
• 検証後に作成したリソースを削除できること

異なる VPC から EFS をマウントする場合、主に以下を設定します。

• VPC ピアリング接続
• 双方の VPC のルートテーブル
• EFS マウントターゲットのセキュリティグループ
• EFS マウントターゲットの名前解決
• 異なるリージョンの場合は /etc/amazon/efs/efs-utils.conf の region 設定

やってみた

異なる VPC から EFS をマウントする場合の考慮事項については、以下の AWS 公式ドキュメントを参考にします。

https://docs.aws.amazon.com/efs/latest/ug/mount-fs-different-vpc.html

VPC ピアリング接続については、以下を参考にします。

https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html

EC2 インスタンスを起動する

EFS をマウントするための EC2 インスタンスを、バージニア北部リージョンの N. Virginia-vpc に起動します。

今回は、以下の設定で作成しました。

プライベートサブネットに起動するため、今回は EC2 インスタンスにパブリック IP アドレスを割り当てません。インスタンスへの接続には AWS Systems Manager Session Manager を利用します。今回は、検証用に必要な設定を事前に用意しています。
起動後、EC2 インスタンスの状態が running になっていることを確認します。
あわせて、EC2 インスタンスが配置されたサブネットと、関連付けられているセキュリティグループを控えておきます。後続のルートテーブル設定とセキュリティグループ設定で使用します。

EFS を作成する

東京リージョンの test-vpc に Amazon EFS を作成します。
今回は、以下の設定で作成しました。

本記事では、リージョンタイプの EFS ファイルシステムを利用します。One Zone タイプを利用する場合は、可用性や配置先アベイラビリティーゾーンの考慮が異なるため、要件に応じて選択してください。
EFS のマネジメントコンソールで、東京リージョンを選択し、test-vpc に EFS ファイルシステムを作成します。
ネットワークアクセスの設定では、マウントターゲットを test-vpc のプライベートサブネットに作成します。

今回は、マウントターゲットを test-vpc のプライベートサブネットに作成します。後続の手順で、VPC ピアリング経由でマウントターゲットへ通信できるように、ルートテーブルとセキュリティグループを設定します。
作成後、EFS ファイルシステムの状態が 使用可能 になっていることを確認します。

後続の手順で使用するため、以下を控えておきます。

• EFS ファイルシステム ID
• マウントターゲットを作成したサブネット
• マウントターゲットに関連付けたセキュリティグループ

次に、EC2 インスタンスを起動した N. Virginia-vpc と、EFS を配置した test-vpc の間に VPC ピアリング接続を作成します。

VPC ピアリング接続を作成する

東京リージョンの test-vpc と、バージニア北部リージョンの N. Virginia-vpc の間に VPC ピアリング接続を作成します。
今回は、EFS を配置する東京リージョン側の VPC をリクエスタ、EC2 インスタンスを配置するバージニア北部リージョン側の VPC をアクセプタとして作成しました。

AWS マネジメントコンソールで、東京リージョンの VPC コンソールを開き、ピアリング接続を作成 します。

設定項目は以下のとおりです。

作成直後の VPC ピアリング接続は、アクセプタ側での承諾待ち状態になります。
次に、バージニア北部リージョンの VPC コンソールを開き、作成された VPC ピアリング接続リクエストを承諾します。
承諾後、VPC ピアリング接続のステータスが アクティブ になっていることを確認します。

これで、test-vpc と N. Virginia-vpc の間に VPC ピアリング接続を作成できました。
なお、この時点では VPC 間の通信はまだできません。次に、双方のルートテーブルに相手 VPC 宛てのルートを追加します。

ルートテーブルを設定する

VPC ピアリング接続を作成しただけでは、VPC 間の通信はルーティングされません。
双方の VPC で、相手 VPC の CIDR ブロック宛てのルートを VPC ピアリング接続に向けます。
今回は、以下のルートを追加します。

まず、東京リージョンの VPC コンソールで、EFS のマウントターゲットが配置されているサブネットに関連付けられたルートテーブルを編集します。
送信先に 192.168.0.0/24、ターゲットに作成した VPC ピアリング接続を指定して保存します。

次に、バージニア北部リージョンの VPC コンソールで、EC2 インスタンスが配置されているサブネットに関連付けられたルートテーブルを編集します。
送信先に 10.0.0.0/16、ターゲットに作成した VPC ピアリング接続を指定して保存します。

追加後、それぞれのルートテーブルに以下のルートが存在することを確認します。
これで、双方の VPC で VPC ピアリング接続を経由するルートを追加できました。

次に、EFS と EC2 インスタンスのセキュリティグループを設定します。

セキュリティグループを設定する

EFS のマウントターゲットに関連付けるセキュリティグループを設定します。
EFS マウントターゲットには、作成時点で default セキュリティグループが関連付いている場合があります。
今回は検証内容を分かりやすくするため、EFS マウントターゲット用のセキュリティグループを新規作成し、マウントターゲットに付け替えます。
まず、東京リージョンの test-vpc に、EFS マウントターゲット用のセキュリティグループを作成します。

インバウンドルールでは、EC2 インスタンスを配置している N. Virginia-vpc の CIDR ブロックである 192.168.0.0/24 から、NFS の TCP 2049 を許可します。

今回は検証のため EC2 インスタンス側 VPC の CIDR ブロックを許可しています。本番環境では、要件に応じて許可範囲を必要最小限にしてください。
次に、EFS コンソールで対象のファイルシステムを開き、ネットワークタブからマウントターゲットのセキュリティグループを変更します。
既存の default セキュリティグループを外し、先ほど作成した efs-mount-target-sg を関連付けます。

変更後、マウントターゲットに efs-mount-target-sg が関連付いていることを確認します。

なお、EC2 インスタンス側のセキュリティグループでアウトバウンド通信を制限している場合は、EFS マウントターゲット宛ての TCP 2049 を許可してください。今回は、アウトバウンドルールはデフォルトのままとしています。
これで、EC2 インスタンスから EFS マウントターゲットへ NFS 通信するためのセキュリティグループ設定が完了しました。

次に、EFS のマウントターゲットを確認します。

EFS のマウントターゲットを確認する

念のため、EC2 インスタンスからマウントするために EFS のマウントターゲット情報を確認します。
このセクションは確認作業なので、省略しても問題ないです。必要に応じてご参考ください。
EFS のマネジメントコンソールで対象のファイルシステムを開き、ネットワーク タブを確認します。

今回は、以下の情報を確認しました。

異なる VPC から EFS をマウントする場合、EFS マウントターゲットの DNS 名をそのまま名前解決できません。そのため、今回はマウントターゲットの IPv4 アドレスを確認し、後続の手順で /etc/hosts に EFS の DNS 名との対応を登録します。
今回の環境では、マウントターゲットの IPv4 アドレスは以下でした。

10.0.135.171

また、マウントターゲットに efs-mount-target-sg が関連付いていることも確認します。
このセキュリティグループでは前述で設定した通り、EC2 側 VPC の CIDR ブロック 192.168.0.0/24 から NFS の TCP 2049 を許可しています。

これで、EFS マウントターゲットの IP アドレスとセキュリティグループを確認できました。
同一リージョン内の別 VPC からマウントする場合は、可能であれば NFS クライアントと同じアベイラビリティーゾーンにある EFS マウントターゲットの IP アドレスを利用することが推奨されています。今回はリージョン間の検証のため、東京リージョン側のマウントターゲット IP アドレスを指定しています。

次に、EC2 インスタンスへ接続し EFS をマウントします。

EC2 インスタンスから EFS をマウントする

バージニア北部リージョンの EC2 インスタンスへ Session Manager で接続し、東京リージョンの EFS をマウントします。
今回は、EFS マウントターゲットの IPv4 アドレスと EFS の DNS 名を /etc/hosts に登録し、EFS マウントヘルパーを利用してマウントします。
なお、Route 53 プライベートホストゾーンを利用して、別 VPC から EFS マウントターゲットの IP アドレスを名前解決させる方法もあります。今回は検証のため、/etc/hosts を利用します。

まず、EC2 インスタンスに接続します。
EC2 インスタンスに amazon-efs-utils をインストールします。

sudo dnf install -y amazon-efs-utils

インストール後、amazon-efs-utils がインストールされていることを確認します。

rpm -q amazon-efs-utils

今回、EC2 インスタンスはバージニア北部リージョン、Amazon EFS は東京リージョンにあります。異なるリージョンの EFS をマウントするため、/etc/amazon/efs/efs-utils.conf の region を EFS ファイルシステムが存在する東京リージョン（ap-northeast-1）に設定します。
まず、設定ファイルのバックアップを取得します。
次に、region を ap-northeast-1 に変更します。

sudo cp /etc/amazon/efs/efs-utils.conf /etc/amazon/efs/efs-utils.conf.bak
sudo sed -i 's/^#region = us-east-1/region = ap-northeast-1/' /etc/amazon/efs/efs-utils.conf

設定後、region が ap-northeast-1 になっていることを確認します。

grep '^region' /etc/amazon/efs/efs-utils.conf

環境によっては region 行の内容が異なる場合があります。その場合は、/etc/amazon/efs/efs-utils.conf を開き、region = ap-northeast-1 となるように編集してください。

次に、EFS マウントターゲットの IPv4 アドレスを /etc/hosts に登録します。
以下の値は、環境に合わせて置き換えてください。

EFS_FILE_SYSTEM_ID="fs-xxxxxxxxxxxxxxxxx"
EFS_MOUNT_TARGET_IP="10.0.135.171"
EFS_REGION="ap-northeast-1"

echo "${EFS_MOUNT_TARGET_IP} ${EFS_FILE_SYSTEM_ID}.efs.${EFS_REGION}.amazonaws.com" | sudo tee -a /etc/hosts

/etc/hosts に登録されたことを確認します。

grep "${EFS_FILE_SYSTEM_ID}" /etc/hosts

ここからは、マウント先ディレクトリを作成します。

sudo mkdir -p /mnt/efs

EFS マウントヘルパーを利用して、Amazon EFS をマウントします。

sudo mount -t efs -o tls ${EFS_FILE_SYSTEM_ID}:/ /mnt/efs

マウントできたことを確認します。

df -hT /mnt/efs

/mnt/efs が nfs4 としてマウントされているため、EC2 インスタンスから EFS へのマウントは成功しています。
127.0.0.1:/ と表示されるのは、amazon-efs-utils の EFS マウントヘルパーで -o tls を指定しているためです。TLS 利用時は、ローカルの TLS トンネル経由で NFS マウントされるため、df 上では 127.0.0.1:/ のように見えることがあります。これは異常ではありません。
これで、バージニア北部リージョンの EC2 インスタンスから、東京リージョンの EFS を VPC ピアリング経由でマウントできました。

次に、EFS 上でファイルを作成し、読み書きできることを確認します。

動作確認

最後に、EC2 インスタンスから EFS に対して読み書きできることを確認します。
EFS 上にテストファイルを作成します。

echo "hello efs over vpc peering" | sudo tee /mnt/efs/test.txt

作成したファイルを読み取れることを確認します。

cat /mnt/efs/test.txt

実行結果は以下のとおりです。

hello efs over vpc peering

ファイルが作成されていることも確認します。

ls -l /mnt/efs

最後に、動作確認用のファイルを削除します。

sudo rm /mnt/efs/test.txt

これで、バージニア北部リージョンの EC2 インスタンスから、東京リージョンの EFS を VPC ピアリング経由でマウントし、読み書きできることを確認できました。

補足: 再起動後も自動マウントする場合

EC2 インスタンス起動時に自動マウントする場合は、/etc/fstab に EFS のエントリを追加します。
今回の検証環境では、すでに以下を設定済みなので、その状態を前提にします。

• amazon-efs-utils をインストール済み
• /etc/amazon/efs/efs-utils.conf の region を ap-northeast-1 に変更済み
• /etc/hosts に EFS マウントターゲット IP と EFS DNS 名を登録済み
• 手動マウントに成功済み

AWS 公式ドキュメントでも、EC2 Linux インスタンスで EFS を自動マウントするには、EFS マウントヘルパーを使って /etc/fstab を更新する方法が案内されています。また、ネットワークファイルシステムのため、_netdev オプションを指定することが推奨されています。

https://docs.aws.amazon.com/efs/latest/ug/mount-fs-auto-mount-update-fstab.html

手順

まず、現在の値を確認します。

echo "${EFS_FILE_SYSTEM_ID}"
echo "${EFS_REGION}"

次に、/etc/fstab のバックアップを取得します。

sudo cp /etc/fstab /etc/fstab.bak

/etc/fstab に EFS の自動マウント設定を追加します。

echo "${EFS_FILE_SYSTEM_ID}:/ /mnt/efs efs _netdev,noresvport,tls 0 0" | sudo tee -a /etc/fstab

追加されたことを確認します。

tail -n 1 /etc/fstab

問題なければ、以下のような出力が想定されるます。

fs-0876242d26f81c81c:/ /mnt/efs efs _netdev,noresvport,tls 0 0

/etc/fstab の設定に問題がないか確認するため、一度アンマウントしてから mount -a を実行します。

sudo umount /mnt/efs
sudo mount -a
df -hT /mnt/efs

/mnt/efs が nfs4 として表示されれば OK です。

Filesystem     Type  Size  Used Avail Use% Mounted on
127.0.0.1:/    nfs4  8.0E     0  8.0E   0% /mnt/efs

最後に、再起動後も自動マウントされることを確認します。
検証時では、マネジメントコンソール画面でも再起動しました。

sudo reboot

再起動後、再度 EC2 インスタンスに接続して以下を実行します。

df -hT /mnt/efs

/mnt/efs が表示されていれば、自動マウントできています。

まとめ

VPC ピアリング接続を利用して、バージニア北部リージョンの EC2 インスタンスから、東京リージョンの EFS をマウントできることを確認しました。
今回の検証では、主に以下を設定しました。

• VPC ピアリング接続の作成と承諾
• 双方の VPC のルートテーブル設定
• EFS マウントターゲット用セキュリティグループで NFS / TCP 2049 を許可
• EFS マウントターゲットの IP アドレスを /etc/hosts に登録
• amazon-efs-utils を利用した EFS のマウント

異なる VPC から EFS をマウントする場合は、同一 VPC 内での利用と比べて、ルーティング、セキュリティグループ、名前解決を意識する必要があります。

今回は検証としてリージョン間でマウントしましたが、本番環境で利用する場合は、レイテンシーやデータ転送料金、運用面も含めて検討するのがよさそうです。
本ブログが誰かの参考になれば幸いです。

参考資料

• Tutorial: Mount a file system from a different VPC - Amazon Elastic File System
• Mounting EFS file systems from another VPC - Amazon Elastic File System
• Enabling automatic mounting on existing EC2 Linux instances - Amazon Elastic File System

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました