Правила перенаправления S3 для исключения одной папки

Question

Я пытаюсь разместить статический веб-сайт на S3 и Cloudfront, как и многие другие передо мной. У меня это в основном все настроено, и я создал сертификаты LetsEncrypt для моего голого домена (назовите его example.com) и www.example.com.

У меня есть два ведра S3, называемые www.example.com и example.com, и два соответствующих распределения Cloudfront, которые просто указывают на их соответствующие ведра S3, а Route 53 настроен с двумя ALIAS A-records.

В примере.com S3 ведро содержит мой сайт, а ведро www.example.com настроено на перенаправление на https://example.com.

Это прекрасно работает. Однако досадно, что когда мне нужно обновить сертификаты LetsEncrypt для обоих доменов, мне нужно отключить перенаправление HTTP-HTTPS в Cloudfront, а затем отключить перенаправление для ведра www.example.com S3, чтобы . Известный вызов можно получить из CA LetsEncrypt. Это раздражает, так как это означает, что пользователи, попавшие на веб-сайт www, не будут перенаправлены в голый домен во время продления сертификата.

Я думал об определении правила перенаправления S3 на обоих ведрах, которые всегда будут перенаправляться на https://example.com, но исключают известную папку для LE CA. Таким образом, я мог позволить Cloudfront обслуживать как HTTP, так и HTTPS, обрабатывать перенаправление в S3, а обновление LetsEncrypt будет полностью прозрачным. Но это не представляется возможным выразить с помощью грамматики маршрутизации S3: https://docs.aws.amazon.com/AmazonS3/latest/dev/HowDoIWebsiteConfiguration.html

Невозможно выразить условие «если префикс ключа не равно» или какой-либо способ выразить «if условие не соответствует, ничего не делать ", поэтому любая попытка исключить папку, казалось бы, обязательно приведет к циклу перенаправления.

Может кто-нибудь сказать мне, что мне не хватает, или если это невозможно с S3? Кажется, слишком простая функция, которую нужно упустить!

Answer 1

Ну, эта функция действительно не хватает, но это должно быть возможным все то же самое, потому что для объектов, которые are't общедоступными или не присутствуют на всех, веб-сайт конечной точки нужно будет возвращать 403 Forbidden ответ. .. но вы можете переопределить это поведение с помощью правила маршрутизации и перенаправить вместо возврата этой ошибки.

<RoutingRules> 
    <RoutingRule> 
     <Condition> 
      <HttpErrorCodeReturnedEquals>403</HttpErrorCodeReturnedEquals> 
     </Condition> 
     <Redirect> 
      <Protocol>https</Protocol> 
      <HostName>www.example.com</HostName> 
     </Redirect> 
    </RoutingRule> 
</RoutingRules> 

Используя это, любой объект, который не присутствует и считываемые результаты в редиректа, в то время как объекты, которые присутствуют и публично-читаемый подаются обычно ..., который является поведение, которое вы ищете. Убедитесь, что у вас нет вашего набора ковша, чтобы разрешить «Каждому» привилегию «Список».

---

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

Установите Path Pattern в этом поведении /.well-known/acme-challenge* (или что-то еще, что у него есть) и установите Viewer Protocol Policy в HTTP and HTTPS. Затем запросы будут перенаправляться на S3 без принудительной переадресации для изменения протокола, но только для запросов, соответствующих этому шаблону пути.