各ページに多くの画像 (数十または数百) がある多くのページを持つ Web サイトがあります。
イメージのホットリンクを回避しようとしていますが、AWS のコストをあまり上げないようにしています。
これまでのところ、3つのオプションが見つかりました:
オプション 1: リファラー ヘッダーに基づいてブロックするルールを作成することにより、WAF を使用してホットリンクを防止します。
このソリューションの問題点は、各ページに多くの画像が読み込まれている場合、S3 と CloudFront を支払うだけでなく、画像リクエストごとに WAF も支払う必要があるため、コストが非常に高くなることです (100 個の画像がある場合を想像してください)。たとえば、各ページで)。
オプション 2: CloudFront を構成して Lambda@Edge ビューアー リクエスト トリガーを起動します。このトリガーは、フロント ドアに到着した各リクエストを検査し、リファラー ヘッダーに基づいてリクエストをブロックします。
https://stackoverflow.com/a/46044606/2444386
これは、上記のオプションに似ています。問題は、イメージが既に CloudFront キャッシュにある場合でも、すべてのリクエストにオーバーヘッドが追加されることです。Lambda@Edge は常に呼び出され、Web サイトの各ページに多くの画像がある場合、コストも大幅に増加します。
オプション 3: リファラー ヘッダーに基づいてリクエストをブロックするように S3 バケット ポリシーを構成し、CloudFront でリファラー ヘッダーをホワイトリストに登録します。
これまでのところ、これが最高のコスト メリットを持つオプションのように思えます。なぜなら、画像が既に CloudFront キャッシュにある場合、オーバーヘッドはまったくなく、WAF やキャッシュを支払う必要がないため、コストも最も安いからです。ラムダ@エッジ。
問題は、受信リクエストの Referer ヘッダーがすでにキャッシュされているリクエストと正確に一致しない限り、CloudFront がキャッシュからのレスポンスを提供しないため、キャッシュ ヒット率がはるかに小さくなることです。
この問題を回避するために「origin」リクエスト ヘッダーを使用しようとしましたが、ブラウザは画像 GET リクエストに対してこのヘッダーを送信しないようです。
より良いオプションはありますか?