あなたが望むものに対する完璧な答えはないと思います。いくつかのランダムなアイデア/トレードオフ:
1) HTTPS に切り替えます。そうすれば、URL をスニッフィングする人を無視できます。ただし、HTTPS アイテムはブラウザに長時間キャッシュすることはできません。
2) 署名付き URL を配布する場合は、expires = "time + 10m" を設定しないでください。このように、URL は少なくとも 10 分間一定であり、ブラウザーはそれらをキャッシュできます。(ブラウザがキャッシュできることを認識できるように、S3 のファイルに expires: ヘッダーも設定してください。)
3) すべての URL をプロキシできます。ブラウザーにサーバーからの写真をリクエストさせ、S3 の写真にリクエストをプロキシする Web プロキシを作成します。途中で、ユーザー認証を確認し、S3 用の署名付き URL を生成し、写真をローカルにキャッシュすることもできます)。これは「効率が悪い」ように思えますが、ブラウザが URL を必要なだけキャッシュできるようにします。写真の URL をブックマークできるので、ユーザーにとっても便利です。いつでも機能します。別のコンピューターに移動した場合でも、サーバーにアクセスして、写真を表示する前にサインインするように求めることができます.
Python Twisted や Node.js などの「イベント化された」サーバーを必ず使用してください。そうすれば、サーバーのメモリや CPU を大量に使用することなく、同時に何千もの写真をプロキシできます。(すべてのデータがサーバーを経由するため、大量の帯域幅を使用します。ただし、複数のサーバーを実行することで簡単に「スケールアウト」できます。)
4) Cloudfront はキャッシュです。リソースが CF サーバーから初めて要求されるときは、遅くなります (数百ミリ秒)。ただし、2 番目のリクエストがキャッシュされるとは思わないでください。各 CF の場所には最大 20 の異なるサーバーがあり、毎回ランダムにヒットします。したがって、写真を 10 回リクエストすると、10 回のキャッシュ ミスが発生する可能性が高く、次のリクエストでキャッシュ ヒットが発生する可能性は 50% しかありません。CF は、何百回も要求される人気のあるコンテンツにのみ役立ちます。CF から S3 へのプライベート接続は通常のインターネットよりも優れているため、外国のユーザーにとって CF は多少便利です。
どのようにして CF にセキュリティ チェックを行わせるのか正確にはわかりません。ただし、S3 認証を通過する場合 (デフォルトではありません)、「mod 10 minutes」トリックを使用して、10 分間キャッシュできる URL を作成できます。
CF が「ブラウザのキャッシュよりも高速」であることは不可能です。ただし、ブラウザーのキャッシュを使用していない場合、CF は S3 よりも高速になる可能性がありますが、ほとんどの場合、外国の場所にあります。
他の人が何をしているか見てみましょう (つまり、smugmug は S3 を使用していると思います)。