CloudFrontのTTL 0は何に役立ちますか？
数週間前に、Amazonはコンテンツの有効期限を短縮したことを発表しました。
Amazon CloudFrontはコンテンツの最小有効期限を引き下げます
CloudFrontで実際にTTLを0に設定できるようになりました。だから、私の質問は、TTL set 0に。これは、キャッシュがまったくないことを意味するため、CloudFrontに到達するすべてのリクエストは、オリジンに到達することになります。
私は何が欠けていますか？
Amazon CloudFront のこの新機能は、多くのユースケースで実際に非常に便利です。これは、[Origin the Originそれどころか、必ずしも問題ではありません。この機能は既に以前にリリースされていますが、すべて最新の Amazon CloudFront-Dynamic Contentのサポート に付属しています。手元の質問：
可変存続時間（TTL）-多くの場合、動的コンテンツは非常に短い期間キャッシュできないか、キャッシュ可能です。数秒。以前は、CloudFrontの最小TTLはすべてのコンテンツが静的であると見なされていたため60分でした。新しい最小TTL値は0秒です。特定のオリジンのTTLを0に設定した場合、CloudFrontはそのオリジンのコンテンツを引き続きキャッシュします。その後、If-Modified-Sinceヘッダーを使用してGETリクエストを行い、それにより、オリジンにCloudFrontが引き続き使用できる信号を送信する機会を与えますキャッシュされたコンテンツがOriginで変更されていない場合。[emphasis mine]
つまり、TTL 0を使用することは、主に、CloudFrontがキャッシュ制御の権限をオリジンに委任することを意味します。つまり、オリジンサーバーは、CloudFrontがキャッシュするかどうか、オブジェクト; If-Modified-Sinceヘッダー付きのGETリクエストは、オブジェクト自体がOriginから取得されることを必ずしも意味しないことに注意してください。むしろ、Originは HTTPステータスコード304-変更なし 該当する場合：
リソースが最後に要求されてから変更されていないことを示します。 [...]これを使用すると、サーバーとクライアントの両方で帯域幅と再処理が節約されます。ヘッダーデータのみを送受信する必要があるためですサーバーによって再処理されているページ全体が、サーバーとクライアントの帯域幅を使用して再度送信されます。 [emphasis mine]
HTTPアーキテクチャの本当に重要で効果的な部分であるHTTPキャッシュ制御のメカニズムと利点の詳細については、Mark Nottinghamの優れた Caching Tutorial を参照してください。
これらすべての部分がどのように連携するかを理解することは、実際には少し難しい場合があります。したがって、セクションダウンロード配信用のCloudFrontキャッシュオブジェクトの最小時間の指定内 CloudFront Edge Cache（Object Expiration） では、TTL = 0の有無にかかわらず、CloudFrontのコンテキストで適用した場合の効果を具体的に要約しようとします。
Amazonは「TTLは0」と言っているのではなく、「Minimum TTL is 0」と言っていることに注意してください。これは非常に異なります。上記の説明は非常に望ましいですが、Cloudfrontの保証はありません実際にそれを行います。
今の経験では、Originが既に変更している間、キャッシュされた画像がEdgeに数分間留まるのを見ることができます。
したがって、「最小TTL is 0」」は「Amazonにはこれをキャッシュに保持する厳密な意図がない」と思われ、「そして頻繁に再取得する」と思われます。
Webユーザーが新しいコンテンツを投稿しているCMSなどのアプリケーションの場合、TTL-0ではまだ十分ではないと思います。 CMSから無効化を呼び出すか、バージョン番号ごとに異なるパスを使用する必要があります。
CloudFrontを証明書マネージャーと組み合わせて使用して、S3 WebサイトにHTTPSサポートを追加できます。これが必要な場合もありますが、キャッシュはありません。