Amazon CloudFrontレイテンシー
開発中のウェブアプリケーションについて、AWS S3とCloudFrontを実験しています。
アプリでは、ユーザーがファイルをS3バケットに（AWS SDKを使用して）アップロードし、CloudFront CDNを介して利用できるようにしていますが、問題はファイルがS3バケットにアップロードされて準備ができている場合でも約1分または2はCloudFront CDN urlで利用可能になりますが、これは正常ですか？
CloudFrontは、キャッシュされていないコンテンツをOriginサーバーからリアルタイムでフェッチしようとします。 CloudFrontはプルスルーCDNであるため、「レプリケーションの遅延」などの問題はありません。 CloudFront Edgeの各ロケーションは、サイトの存在と構成のみを認識しています。コンテンツのリクエストを受け取るまで、コンテンツはわかりません。これが発生すると、CloudFront Edgeは要求されたコンテンツをオリジンサーバーからフェッチし、後続の要求を処理するために適切にキャッシュします。
ここで発生している問題は、「ネガティブキャッシング」と呼ばれることもある概念に関連しています。つまり、リクエストが機能しない機能しないことをキャッシュすることです。とにかく失敗する可能性が高いリクエストでキャッシュされているものの起源。
デフォルトでは、OriginがHTTP 4xxまたは5xxステータスコードを返すと、CloudFrontはこれらのエラー応答を5分間キャッシュし、オブジェクトの次のリクエストをOriginに送信して、エラーの原因となった問題が解決され、リクエストされたかどうかを確認しますオブジェクトが利用可能になりました。
— http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html
S3へのアップロードが完了する前に、ブラウザーなどが特定のCloudFront Edgeからファイルをダウンロードしようとすると、S3はエラーを返し、そのEdgeの場所にあるCloudFrontはそのエラーをキャッシュして覚えます。次の5分間、わざわざ再試行する必要はありません。
ただし、心配する必要はありません。このタイマーは構成可能であるため、ブラウザーが内部で制御外でこれを実行している場合でも、それを修正することができます。
CloudFrontがキャッシュする4xxおよび5xxステータスコードごとに、エラーキャッシュ期間（Error Caching Minimum TTL）を指定できます。手順については、「 エラー応答動作の構成 」を参照してください。
— http://docs.aws.Amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html
これをコンソールで構成するには：
配布構成を表示しているときに、[_
Error Pages_]タブをクリックします。タイミングをカスタマイズするエラーごとに、まず_
Create Custom Error Response_をクリックします。_
403_（禁止）や_404_（見つかりません）など、変更するエラーコードをドロップダウンリストから選択します-バケット構成により、不足しているオブジェクトに対してS3が返すコードが決まるため、不明な場合は、403を変更してから、プロセスを繰り返して404を変更します。Error Caching Minimum TTL (seconds)を_0_に設定します_
Customize Error Response_をNoに設定したままにします（Yesに設定した場合、このオプションはエラーに対するカスタム応答コンテンツを有効にしますが、これは望ましくありません。このオプションのアクティブ化はこのスコープの範囲外です質問。）Createをクリックします。これにより、前のビューに戻り、定義したコードの_Error Caching Minimum TTL_が表示されます。
デフォルトの動作（前述の300秒の保持時間）から変更するHTTP応答コードごとに、これらの手順を繰り返します。
必要な変更をすべて行ったら、ディストリビューションがリストされているメインのCloudFrontコンソール画面に戻ります。配布状態が_In Progress_からDeployedに変化するのを待ち（通常、変更がすべてのエッジにプッシュされるまで約20分）、テストします。
これらの新しいファイルは初めてS3に書き込まれますか、それとも既存のファイルを更新しますか？ S3は、新しいオブジェクトに読み取り後の整合性を提供します。CloudFrontのプルモデルを考えると、S3に書き込まれる新しいファイルでこの問題が発生することはありません。もしそうなら、私はAWSでチケットをオープンします。
これらが既存のファイルの更新である場合は、S3結果整合性とCloudFrontキャッシュの有効期限の両方を処理する必要があります。どちらもこの種の動作を引き起こす可能性があります。
あなたのコメントで観察されたように、google chromeがアップロード/プレビュー戦略をめちゃくちゃにしているようです：
- Chromeは、現在コンテンツがないURLをリクエストしています。
- リクエストはcloudfrontによってキャッシュされ、無効なレスポンスが返されます
- ファイルをS3にアップロードします
- アップロードされたファイルをプレビューすると、Cloudfrontはキャッシュされた応答で応答します（ステップ2）。
- cloudfrontキャッシュの有効期限が切れると、cloudfrontがOriginにヒットし、問題は再現できなくなります。