私たちはクラウドフロントにいくつかのスクリプトとコンテンツをホストしています。これらは、ウェブサイトの一部としてさまざまな消費者によって一般に公開されています。スクリプトがもはや関連性がなくなると、私たちはファイル/コンテンツを無効にし、もはや利用できなくなります。自分のページでスクリプト/コンテンツを使用している人には通知されますが、現在ではステータスコードが403のスクリプト/コンテンツを削除するように強制することはできません。この費用を回避または削減する方法は？Amazon Cloudfrontと403のコスト
ここには1つの戦略があります。
ドメイン名はexample.comとします。
代替ドメイン名*.example.comでCloudFrontディストリビューションを作成します。
各サイト、スクリプト、またはサイト+スクリプトコンボでは、カスタムの「ダミー」ホスト名を割り当てます。 jozxyqkrd52169.example.com。これを1つのサイトに限定してください。
ルート53では、現在有効であると考えられるホスト名のDNSエントリだけを維持します。エントリが不要になったら削除してください。これは自動化することができます。
技術的には、CloudFrontはいずれの*.example.comホスト名にも応答しますが、DNSレコードが指し示されていないため、使用していないホスト名の要求はありません。
削除されたエントリを持つホスト名のクエリを処理するためにRoute 53を支払うことになりますが、それはCloudFronrとS3リクエストの価格のほんの一部です。
ルート53に作業したいレコードをプロビジョニングする代わりに、CloudFrontを指すワイルドカードレコードでプロビジョニングし、ブロックするホスト名の特定のエントリを作成することもできます。 invalid.invalid（.invalidは、レコードが実際に無効であることを示すために実際に予約されているトップレベルのドメイン名です）などのターゲット名を指すCNAMEレコードは、特定のサブドメインを上書きし、それらの名前の要求がCloudFront 。限り、あなたは複数のホスト名のために答える単一分布で、原点にHostヘッダを転送するCloudFrontのキャッシュの動作を設定していないとして、foo.example.com/cat.jsとbar.example.com/cat.jsはそう複数のホスト名、同じオブジェクトとみなされるであろうことを
注意このようにキャッシュヒット率に悪影響を及ぼすべきではありません。