私はAmazonS3に膨大な数のオブジェクトを持っていますが、そのうちの小さなサブセットだけが定期的にアクセスされています。したがって、Ehcacheのような分散キャッシングシステムを実際に利用したいと思います。（注：Cloudfrontを使用しますが、データにはエンドユーザーからではなくAPIサーバーからアクセスする必要があり、前回チェックしたときのCloudfrontは認証をサポートしていません。）
これが実行可能で実用的かどうか、またはEhcacheを使用してAmazon S3からオブジェクトをキャッシュするライブラリまたは例が存在するかどうかを誰かに教えてもらえますか？
当然、私のアプリサーバーはJavaで実装され、Linux環境で実行されています。
どうもありがとう。
興味深いアイデア-しかし、最終的にそれに飛び込む前に、 2009年9月からAmazon CloudFrontで認証が利用可能になっていることを強調したいと思います。ただし、想像どおりではない可能性があります。つまり、署名付きURLを使用してプライベートコンテンツを提供できます。
静的な署名付きURLまたは動的な署名付きURLを使用してプライベートコンテンツを配布できます。既知のエンドユーザーにプライベートコンテンツを配布する場合は、静的に署名されたURLを使用します[...]。この場合、署名付きURLを作成し、必要に応じてエンドユーザーがそのURLを利用できるようにします。動的な署名付きURLを使用して、限られた目的でエンドユーザーにコンテンツをオンザフライで配布します[...]この場合、アプリケーションは署名付きURLを生成します。
これについては、プライベートコンテンツの概要で詳しく説明しています。
CloudFrontプライベートディストリビューションは、次の制約のいずれかまたはすべてを指定するポリシーステートメントに基づいています。
- 署名されたURLが有効になる日時を指定する開始日
- 署名されたURLが無効になるまでの終了日時
- 署名付きURLを使用できるIPアドレスまたはIPアドレスの範囲
[強調鉱山]
このアプローチがユースケースで実行可能かどうかは、ソリューションのアーキテクチャによって異なります。ただし、何らかの方法でこれらの署名付きURLを生成し、APIサーバーからのURLを順番に使用する必要があります。「エンドユーザー」がAPIサーバーである場合、提案されているように静的URLを事前に生成することができますが、最も明白なアプローチは、APIサーバー自体で署名付きURL生成プロセスを動的に実行し、生成されたURLをキャッシュすることです<- >最終的に再利用するための署名付きURLマップ（つまり、MemcachedまたはEhcacheを介して）。
この認証スキームは、単純なHTTP認証よりも明らかに面倒です。たとえば、柔軟性も高くなります。たとえば、高度なユースケースについては、チュートリアル「地理的位置に基づくCloudFrontディストリビューション内のファイルへのアクセスの制限（ジオブロッキング）」を参照してください。これは、AWSブログのゲスト投稿：AmazonCloudFrontを使用したコンテンツのジオブロッキングにも要約されています。
最終的にJetS3tを使用してS3からファイルを読み取り、分散ehcacheクラスターに保存しました。このアプローチはこれまでのところ非常にうまく機能していますが、JetS3tは処理する必要のある一時ファイルを多数作成することがわかりました。