AWS外でのElastic File System（EFS）マウント
AWSの外部にあるサーバーがあります。 EFSボリュームをマウントできるようにしたいのですが、それが可能かどうかはわかりません。
おそらく、VPCを作成し、VPNを介してトンネルを作成する場合はどうでしょうか。
これが可能かどうか誰かが知っていますか？
重要な更新：
AWSは2018年10月に、EFSを支えるネットワークテクノロジーの機能を拡張し、以下で説明するプロキシの回避策に頼ることなく、管理されたVPN接続とリージョン間VPCピアリング全体でネイティブに機能するようになりました
EFSは、2016年後半にAWS Direct Connect回線を介した接続のサポートを追加しました。
https://aws.Amazon.com/blogs/aws/Amazon-efs-update-on-mise-access-via-direct-connect-vpc/
私が質問を最初に読んだとき、私はあなたが持っているよりもEFSに精通していると思っていたので、コメントはいくつかの興味深い問題を引き起こしました。
したがって、最初に、背景について少し説明します。
Elastic File Systemの「Elastic」とは、主にストレージスペースとスループットの自動スケーリングを指します。外部アクセスの柔軟性ではありません。
EFSでは、保存できるデータ量に意味のある制限はないようです。 EFSボリューム上の単一ファイルの文書化された最大サイズは 52,673,613,135,872バイト（52 TiB） です。他の制限のほとんどは、同様に寛大です。
EFSは、請求方法が特に「柔軟」です。 EBSボリューム上のファイルシステムとは異なり、EFSではスペースは事前に割り当てられず、保存するものに対して時間平均で支払うだけです。保管量に基づいて、料金は増減します（「弾力的」です）。ファイルを削除すると、1時間以内にファイルが占有したスペースに対する支払いが停止します。 1 GBを750時間（≅1か月）保存してから削除した場合、または375 GBを2時間保存してから削除した場合、毎月の請求額は同じです... $ 0.30。これはもちろん、EBSとはかなり異なります。EBSは、残りの時間に375 GBの0x00を保存するために$ 37.50を喜んで請求します。
S3のストレージ料金モデルはEFSとほぼ同じです。オブジェクトを削除するとストレージの請求が停止し、コストはEFSのコストの約1/10ですが、私や他の人が何度も言及しているように、S3はファイルシステム。 s3fs-Fuseのようなユーティリティは「インピーダンスブリッジ」を提供しようとしますが、実際にファイルシステムではないものを処理しようとすることには本質的な困難があります（上書きの最終的な一貫性は、少なくともそれらの少なくともではありません）。したがって、実際の「ファイルシステム」が必要であり、アクセスを共有する必要があるアプリケーションの場合、または必要なストレージに必要なスペースが決定しにくい場合、またはオンデマンドで拡張する場合は、EFSが役立ちます。
また、8.0 EiBの空き容量がある場合は見栄えがします。
$ df -h | egrep '^Filesystem|efs'
Filesystem Size Used Avail Use% Mounted on
us-west-2a.fs-5ca1ab1e.efs.us-west-2.amazonaws.com:/ 8.0E 121G 8.0E 1% /srv/efs/fs-5ca1ab1e
us-west-2a.fs-acce55ed.efs.us-west-2.amazonaws.com:/ 8.0E 7.2G 8.0E 1% /srv/efs/fs-acce55ed
ただし、アプリケーションに最も適したストレージサービスを使用することはもちろん重要です。各オプションには、有効な使用例があります。 EFSはおそらくAWSが提供するストレージソリューションの中で最も専門的なものであり、EBSやS3よりもユースケースの範囲が狭くなっています。
しかし、VPCの外部から使用できますか？
公式の答えはノーです：
VPN接続、VPCピアリング、AWS Direct ConnectなどのVPCプライベート接続メカニズムを介したファイルシステムのマウントはサポートされていません。
— http://docs.aws.Amazon.com/efs/latest/ug/limits.html
EFSは現在、EC2 Linuxアクセスのみに制限されています。これもVPC内です。より多くの機能がすぐに追加されます。リリースされた新機能に関するAWSの発表にご注目ください。
— https://forums.aws.Amazon.com/thread.jspa?messageID=732749
ただし、これは公式にサポートされている構成ではありませんが、実用的な答えは「はい」です。これを機能させるには、いくつかの特別な手順が必要です。
各EFSファイルシステムには、エラスティックネットワークインターフェース（ENI）を使用してVPCでエンドポイントIPアドレスが割り当てられます。通常、アベイラビリティーゾーンごとに1つあります。パフォーマンス上の理由だけでなく、インスタンスと一致するアベイラビリティーゾーンにマウントするようにしてください。また、アベイラビリティーゾーンの境界を越えてデータを転送するときに帯域幅料金が適用されるためです。
これらのENIの興味深い点は、接続されているサブネットのルートテーブルを使用していないように見えることです。セキュリティグループの設定に関係なく、VPC内のインスタンスにのみ応答できるようです（各EFSファイルシステムには、アクセスを制御するための独自のセキュリティグループがあります）。
外部ルートにアクセスできないため、ハードウェアVPNを介してEFSエンドポイントに直接アクセスすることはできません...それで、私は古いパルHAProxyに頼りました。 EFSはTCPポート2049のみを使用するため、これは簡単な構成です。
T2.nanoでHAProxyを使用しています（HAProxyは非常に効率的です）。構成は次のようになります。
listen fs-8d06f00d-us-east-1
bind :2049
mode tcp
option tcplog
timeout tunnel 300000
server fs-8d06f00d-us-east-1b us-east-1b.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000
server fs-8d06f00d-us-east-1c us-east-1c.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000 backup
server fs-8d06f00d-us-east-1d us-east-1d.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000 backup
このサーバーはus-east-1bにあるため、us-east-1bエンドポイントをプライマリとして使用し、他の2つは1bのエンドポイントがヘルスチェックに失敗した場合のバックアップとして使用します。
VPCにVPNがある場合は、（EFSエンドポイントを直接使用する代わりに）このプロキシインスタンスのIPアドレスをターゲットとして使用してボリュームをマウントし、voilàyou VPCの外部からEFSファイルシステムをマウントした。
私はそれを外部のUbuntuマシンとSolarisサーバーに正常にマウントしました（EFSは、サービスを他のマシンから簡単に移行できるようにすることで、廃止を迅速化するのに非常に便利であることが証明されています）。
AWSにデータを移動する場合や、移行中に特定のデータでレガシーシステムとクラウドシステムを並行して実行する場合など、特定の状況では、EFSが勝者のようです。
もちろん、ラウンドトリップ時間が長いレガシーシステムはEC2インスタンスと同じように機能しませんが、これは予想されることです。物理法則の例外はありません。それにもかかわらず、EFSとHAProxyゲートウェイは、外部で動作させるための安定したソリューションのようです。
VPNがない場合、AWSに1つとデータセンターに1つあるHAProxyマシンのペアも、TLSを介してEFSをトンネルし、ペイロードとの個別のTCP接続を確立します。 TLSでラップされており、個々のEFS接続をインターネット経由で転送します。厳密にはVPNではなく、接続の暗号化されたトンネリングです。これも非常にうまく機能しているようです。
¹Solaris10は（当然のことながら）デフォルトでいくらか壊れています-最初は、rootには特別な特権がないようでした-rootによって作成されたEFSボリューム上のファイルはrootが所有していますが、chownedすることはできませんすべてがUbuntuクライアントから期待どおりに機能しているにもかかわらず、Solarisマシン（Operation not permitted）から別のユーザーへ。この場合の解決策は、svcadm disable svc:/network/nfs/mapid:defaultを使用して、Solarisマシン上のNFS IDマッピングデーモンを無効にすることです。このサービスを停止すると、すべてが期待どおりに機能します。さらに、各ログインでの/usr/sbin/quotaの呼び出しは、/etc/profileで無効にする必要があります。より良い、またはより正しい解決策があるかもしれませんが、それはSolarisなので、調査するほど好奇心が強くありません。
2016年12月20日の時点で、AmazonはEFSファイルシステムをオンプレミスサーバーにマウントするために使用できるAWS Direct Connectを発表しました。したがって、基本的には、VPCの外部でAWS EFSを使用できるようにするネイティブ機能があります。
前提条件として、AWS Direct Connect接続を有効にして確立し、EC2インスタンス内にEFSをマウントするときに使用する必要があるnfs-utilsを使用する必要があります。
詳細については、f 以下のURL を参照してください。この未来も探していたので、これを投稿しました。VPCの外部のEFS接続にはネイティブソリューションがあることを他の人に知ってもらうためです。