簡単に言えば、断定的な「いいえ」です。他の人はそれを上に言った。
「はい」と答えた人は質問には答えませんでしたが、別の質問に答えました。EFSが単なるNFSサービスである場合、最初に述べたような質問への回答ではありません。また、EFSが「すべてのゾーンにロールアウト」されているかどうかは関係ありません。独自のNFSインスタンスを作成して、複数のサーバーにNFSをマウントさせることができるからです。それは新しいことではなく、1992年にすでにそれを行っています。SMBとsshfs、これらはすべて、ドライブをリモートファイルシステムとしてマウントする方法にすぎません。
「なぜそんなことをしたいのか」「結局涙が出る」と言った人は間違っている。私たちは何十年もの間、複数のディスクを複数のサーバーにマウントしてきました。SAN（ストレージエリアネットワーク）を使用したことがある場合、通常はFibreChannel SANを介して同じデバイスを複数のノードに接続する機能は完全に正常です。そのため、仮想化/クラウドサーバーがユビキタスになる10年前にサーバーを実行したことがある人は、それをある程度知っています。
すぐに、2つのシステムがまったく同じボリュームを読み書きできるクラスター化ファイルシステムが登場しました。これはVAXとAlpha VMSの歴史の始まりから始まったと思います。クラスター化されたファイルシステムは、分散相互排除スキームを使用して、ブロックを直接操作できるようにします。
同じディスクを複数のノードにマウントする利点は、速度と単一障害点の減少です。
現在、クラスター化されたファイルシステムは、「コンシューマー」ホスティングビジネスでそれほど普及していません。そして、それらは複雑であり、いくつかの落とし穴があります。ただし、複数の計算ノードに接続されたディスクを利用するために、クラスター化されたファイルシステムは必要ありません。読み取り専用ドライブが必要な場合はどうなりますか？クラスター化されたファイルシステムも必要ありません。読み取り専用（ro）と同じ物理デバイスを/ etc / fstabに入れるだけです。次に、2台または10台のEC2サーバーにマウントすると、それらすべてがそのデバイスから直接読み取ることができます。
クラウドサーバーの世界では、急速にスケーリングするファームを構築する際に、これの明らかな使用例があります。メインシステムディスクをすべて準備し、各サーバーに非常に小さなブートおよび構成ディスクを使用することができます。すべてを同じブートディスクからブートすることもできます。/の再マウントの直前に、読み取り/書き込みモードで、3つのレイヤーのUnion-FSを挿入できます。
- メインの読み取り専用システムディスク、ブート、カーネル、およびユーザーランドインストール
- 個々のサーバーに固有のいくつかのファイル（主に/ etc内）のみを含む構成ファイルシステム。このディスクは、新しいインスタンスを起動する準備をするために、別のサーバーによって書き出すことができます。ここでのサンプルファイルは/ etc / hostnameであり、ノードごとに異なるままにする必要がある構成ファイルはごくわずかです。
- まったく必要ない書き込み可能なディスクは、メモリファイルシステムとしての/ tmpだけです。
ですから、はい、その質問は非常に理にかなっており、残念ながら答えは（まだ）「いいえ」です。また、NFSはシステムディスクからのすべての読み取りアクティビティにペナルティを課すため、そのユースケースの優れた代替品にはなりません。ただし、NFSシステムディスクからのネットワークブートは、上記のユースケースを実装する唯一の方法です。残念ながら、ネットワークブートエージェントとNFSのセットアップは、同じ物理ブロックデバイスにアクセスするよりもはるかにトリッキーです。
PS：これの短いバージョンをコメントとして提出したかったのですが、51クレジットポイントの愚かなしきい値のため、私はできません。そのため、同じ本質的な「いいえ」で回答を書く必要がありますが、これがなぜかという点を含める必要があります。当然の答えを受けていない関連質問。
PPS：StackExchangeで誰かがiSCSIについて言及しているのを見つけました。iSCSIは多少NFSに似ていますが、論理的にはFibreChannel SANに似ています。物理ブロックデバイスにアクセス（および共有）します。起動ディスクの共有が簡単になるので、厄介なbootdネットワーク起動を設定する必要はありません。しかし、AWSでは、ネットワークブートも利用できません。