私は交通量が比較的少ないですが、データを安全に保ちたいと思います。データは単一のMongoDbインスタンスに格納されます。私は複数のレプリカを実行して管理したくありません。そこで、データディレクトリをEFSパスに変更して、レプリケーションやその他の利点を活用する予定です。定期的なスナップショットはデータの消失を引き起こす可能性があり、復旧は手動です。 追加レイテンシによってEFSにデータファイルとジャーナルファイルが格納されるという欠点はありますか？Amazon EFSのMongoDbデータ - エラスティックファイルシステム
あなたが指摘したように、EFSオブジェクトは利用可能なゾーン間でreplicatedです。対照的に、EBSボリュームは単一の可用性ゾーン内にあるreplicatedです。 EFSが現在0.30ドル/ GB、EBSが0.10ドル/ GBから始まっているため、価格の相違は重要です。一般的なEFSユースケースは、ユーザーのホームディレクトリやアプリケーションデータなどのインスタンス間で共有する必要のあるデータ用です。 EBSは最低レイテンシを提供することもできます。
これらの点を念頭に置いて、MongoDBデータにはEFSはお勧めしません。 EFSのマルチAZレプリケーションがあなたの大きな願いである場合、EBSボリュームの（S3に格納されている）定期的なスナップショットを取ってEBSで達成できます。私はEBSがあなたにより良いパフォーマンスと低コストを与えると思います。
EFSを使用することは、実際に複数のMongoDBインスタンスを実行する代わりではありません。レプリケーションとシャーディングは、EFSが達成するのに役立つものではありません。
定期的なスナップショットでは不十分です。データが失われる可能性があります。また、回復は手動です。また、私のデータサイズはまだ1ギガバイトではありませんが、近い将来5ギガバイトを超えて増加するとは思われません。私の場合、ストレージコストは大きな問題ではありません。 – JackDaniels
EBSスナップショットはポイントインタイムバックアップです。何かがうまくいかなければ、元に戻すことができます。 EFSを使用すると、何らかの理由でデータが失われた場合（カスタムスクリプトを使用しない場合）、バックアップはありません。 – jbird
EBSの障害によりEBSスナップショットが使用できない状況が発生しました。奇妙に聞こえる？はい。しかし、それは実際に起こったことです。準備して –
明確にするには、単一のEC2インスタンスで実行されている単一のMongoDBインストールでこのデータにアクセスする予定ですか？ –
はい、少なくとも数ヶ月間は。 1日あたり200件の書き込みはほとんどありません。これはセットアップの簡素化に役立ちますか？ – JackDaniels
はい。私は@jbirdが私がやったのと同じ印象を受けたと思います.MongoDBコンポーネントを実行している複数のEC2マシンを想像していて、EFSに住んでいるバッキングストアを共有しているとしたら、まったく正しいです。しかし、ストレージの弾力性の面を探しているのであれば、これはちょっと変わったユースケースですが、「試してみてください」と言っています。それは何を傷つけるでしょうか？サービスを停止し、ファイルをコピーし、パスを設定して、再起動します。私はあなたのようなトラフィック量が少ないと合理的にうまく動作しないという本質的な理由は見当たりません。 –