Поскольку перенаправление - это инструкция для браузера, в которой указывается искать запрашиваемый ресурс в другом месте, CloudFront не предназначен для самостоятельного перенаправления - он возвращает перенаправление в браузер.
Вместо этого вам нужно новое поведение CloudFront Cache Behavior и новое объявление сервера CloudFront Origin, настроенное в существующем дистрибутиве CloudFront, который обрабатывает ваш сайт.
В CloudFront добавьте новый Origin, установка Имени исходного домена в качестве имени хоста, указывающего на экземпляр EC2 (или на балансировщик нагрузки перед экземпляром, если таковой имеется). Вы заметите поле с именем «Путь к источнику», для которого вы можете указать «/ blog /» или что-то подобное, но это неверно. Оставьте "Путь происхождения" пустым.
Затем добавьте новое поведение кэша, соответствующее шаблону пути /blog/* и указав его на новом источнике.
В двух словах, это то, что вы ищете, но есть несколько другие факторы, которые потребуют соответствующих настроек и конфигурации.
Вам понадобится сертификат TLS на исходном сервере, если только вы не задали для политики протокола происхождения значение «Только HTTP», и в этом случае вы используете незашифрованный трафик c между CloudFront и EC2. CloudFront имеет специфицированные c требования для правильной настройки TLS на исходном сервере, и большинство неверных настроек, связанных с TLS, приведут к ошибке 502 Bad Gateway , хотя, конечно, могут быть и другие причины этот код ошибки.
Вашему программному обеспечению блога могут потребоваться параметры строки запроса и / или файлы cookie, которые CloudFront по умолчанию удаляет из всех запросов (поскольку они мешают кэшированию). Это две из настроек поведения кэша , которые обычно требуют настройки, поскольку значения по умолчанию основаны на соответствующих настройках для типичного содержимого stati c.
Вам также потребуется настроить программное обеспечение блога. ожидать, что входящие запросы будут включать префикс пути "/ blog /", потому что CloudFront не удаляет компоненты пути. Единственный способ представить путь к исходному серверу с удаленным из него одним или несколькими элементами - использовать Lambda@Edge для перезаписи пути - , как я объяснил здесь .
Если вы В настоящее время мысленно протестуют против установки пути "/ blog /" вместо "/ blog", проблема в том, что этот путь требует правильной привязки - семантика HTTP предполагает, что уровни каталогов заканчиваются на "/", в то время как файлы и другие ресурсов нет, поэтому вы, скорее всего, столкнетесь с трудностями, если попытаетесь указать блог, который не заканчивается на / ... но для пользователей, которые не должны печатать трейлинг /, вам все равно нужно настроить перенаправление в S3 - но только для того, чтобы отправлять запросы на /blog обратно на /blog/.
<RoutingRules>
<RoutingRule>
<Condition>
<KeyEquals>blog</KeyEquals>
</Condition>
<Redirect>
<ReplaceKeyWith>blog/</ReplaceKeyWith>
<HostName>${main_site_hostname}</HostName>
<Protocol>https</Protocol>
</Redirect>
</RoutingRule>
</RoutingRules>
При тестировании вы также можете хотите установить Error Caching Minimum TTL равным 0 , чтобы вы не исправляли проблему и продолжали видеть возвращенные в кеширование ошибки в течение следующих 5 минут, даже если ошибка была устранена путем изменения ты сделал. CloudFront делает это, чтобы избежать перегрузки исходного сервера, который, возможно, уже испытывает проблемы (о чем свидетельствует тот факт, что он возвращает ошибки), но застает некоторых пользователей врасплох.