Принудительное использование CloudFront для передачи последнего HTML-файла из S3

Фон

Я размещаю статический сайт на S3, с CloudFront сверху. У меня проблема с моими файлами HTML.

Согласно FAQ CloudFront :

Amazon CloudFront использует эти заголовки элементов управления кэшем, чтобы определить, как часто необходимо проверять источник обновленной версии этого файла.

Что я сделал до сих пор

Имея это в виду, я установил HTML-файлы в моем S3 Bucket, чтобы добавить следующие заголовки:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Expires: Fri, 01 Jan 1990 00:00:00 GMT

При моем первом обращении к my samplefile.htmя вижу следующие заголовки ответа (я исключил очевидные заголовки (например Content-Type), чтобы не потерять смысл:

Cache-Control:no-cache, no-store, max-age=0, must-revalidate
Date:Sat, 10 Dec 2011 14:16:51 GMT
ETag:"a5890ace30a3e84d9118196c161aeec2"
Expires:Fri, 01 Jan 1990 00:00:00 GMT
Last-Modified:Sat, 10 Dec 2011 14:16:43 GMT
Server:AmazonS3
X-Cache:Miss from cloudfront

Как видите, мой Cache-Controlзаголовок там. Проблема в том, что если я обновляю этот файл и обновляю его, я получаю кэшированное содержимое (а не последний файл) и вижу, что CloudFront обслуживает свою кэшированную версию, просматривая заголовки ответа:

X-Cache:Hit from cloudfront

Резюме / вопрос

Имея в виду вышеизложенное, как я могу добиться автоматического получения последней версии HTML при использовании CloudFront?

Согласно FAQ, я должен быть в состоянии сделать это с заголовками Cache-Control, но я не могу заставить это работать.

Следуя ответам ниже

В конце концов я решил изменить свой www CNAME, чтобы он указывал на мое ведро S3 напрямую. Затем добавлен новый CNAME под названием «static», который указывает на CloudFront.

Это означает, что HTML является прямым из S3, который затем имеет все свои ссылки CSS / JS / IMG, указывающие на static.mydomain.com

Во-первых, цель Cloudfront состоит в том, чтобы обслуживать кэшированный контент - если вы пытаетесь обслуживать некэшированный контент из Cloudfront, то это происходит медленнее, чем подача его напрямую из S3, почти во всех случаях (что-то вроде потокового контента будет исключением). Подумайте на мгновение о том, что должно произойти для обслуживания контента из Cloudfront - его нужно извлечь с исходного сервера в местоположение, географически близкое к пользователю, - это означает, что для запроса, когда Cloudfront должен получить контент с исходного сервера Вы добавляете дополнительную задержку в запрос, и пользователь получает контент медленнее. Только после того, как контент становится доступным на периферии, последующие запросы выполняются быстрее.

Лучший подход к этой проблеме - изменить имена файлов при обновлении страницы - это заставит Cloudfront получить новый контент. Опять же, имейте в виду, что Cloudfront обычно используется для медиа-файлов (включая изображения) и style / javascript - и не так много для html. В сущности, ваш HTML-код должен быть на S3, а ваши изображения - в Cloudfront - с любыми внесенными вами изменениями вы можете изменить имя файла в Cloudfront (например, file-v1.jpg, file-v2.jpg и т. Д.). Другой распространенный способ - включение строки запроса с информацией о версии.

Кроме того, имейте в виду, что Cloudfront не обслуживает gzip-контент - что может привести к более медленному ответу, чем от обычного сервера (хотя, в вашем случае, S3 также не идентифицирует gzip-совместимые браузеры).

Наконец, если вы хотите, вы можете использовать аннулирование, чтобы заставить Cloudfront отказаться от существующей копии и извлечь новую с исходного сервера. Однако обратите внимание, что Cloudfront предоставляет вам только 1000 бесплатных аннулирований в месяц, после чего стоимость составляет $ 0,005 / недействительность.

Самое низкое время, в течение которого Cloudfront будет хранить контент, составляет 1 час , хотя по умолчанию это 24 часа . Поэтому я бы попытался установить максимальный возраст как минимум 3600. Рассмотрим также заголовок s-maxage (для общего - т.е. прокси-контента). Amazon рекомендует это руководство по кэшированию.

Была недавняя проблема с этим, исправленная несколько дней назад

Я полагаю, что ответы, хотя и правильные в то время, теперь устарели, поскольку Cloudfront теперь поддерживает минимальный TTL 0, и первоначальная попытка OP использовать cache-age = 0 теперь должна работать.

Возможно, вы захотите выяснить, использовать ли эти другие заголовки управления кэшем с точки зрения того, будут ли они давать результат, который вы ищете - вам может понадобиться только максимальный возраст. Вероятно, вы хотите, чтобы Cloudfront проверил S3, чтобы увидеть, изменился ли HTML-файл. Если это так, Cloudfront может получить и вернуть новый файл. Если нет, он может обслуживать клиента из его существующего кэша (сохраняя пропускную способность S3 и обслуживая клиента быстрее и более локально).

Цель Cloudfront - обслуживать кэшированный контент, да, но теперь это включает контент, который иногда изменяется, но может быть кэширован, если он не изменился.

Строки запроса Ps теперь также работают с Cloudfront (если вы настраиваете «поведение» для соответствующего источника - еще одна новая функция), однако некоторые прокси-серверы могут все еще не кэшировать любые файлы со строками запроса.

Руководство разработчика Amazon: срок действия 1

Не уверен, как CloudFront обрабатывает заголовок так же, как у вас, но если вы не укажете заголовки, по умолчанию время обновления объектов составляет 24 часа.

Одна из вещей, которую вы можете сделать, чтобы обновить объекты, - сделать содержимое недействительным. Проверьте ссылку ниже для получения дополнительной информации. http://blog.cloudberrylab.com/2010/08/how-to-manage-cloudfront-object.html