Api Gateway и региональный пользовательский домен как CloudFront Origin - PullRequest
Новая
       29

Api Gateway и региональный пользовательский домен как CloudFront Origin

0 голосов
/ 29 мая 2019

Я хочу создать шлюз API с региональным пользовательским доменом и использовать его в качестве источника распространения CloudFront. Моя основная мотивация - управлять MinimumProtocolVersion / TLS1.2

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

Моя команда испытала 403 ошибки от CF при несоответствии, я просто дважды проверяю, выполнимо ли это вообще

Пример: 

ApiGW: 
  - Custom Domain Name (REGIONAL). For example www.sample.com (
  - matching ACM certificate in eu-west-1
  - No R53 records referencing this domain name

Cloudfront:
  -  ACM certificate in us-east-1
  -  Alias www.example.com
  -  Origin; www.sample.com
  -  R53 recrod for www.example.com, in hosted zone example.com mapped to the CF disitribution domain name

1 Ответ

1 голос
/ 30 мая 2019

Когда CloudFront устанавливает соединение с источником, он всегда использует имя домена источника для поиска IP-адреса источника ... но когда он отрицает TLS с источником, он устанавливает SNI на то же значение, что и HTTP * Заголовок 1001 *, который будет отправлен отправителю.

Эти два значения могут быть одинаковыми или могут отличаться, но Host / SNI всегда одинаковы и всегда одно из двух значений:

  • это имя домена происхождения (потенциально измененное в пользовательских параметрах источника триггером Lambda @ Edge Origin Request), когда настройки поведения кэша не включают , включая белый список Host заголовок (или все заголовки) для пересылки к источнику или
  • это заголовок HTTP Host , отправляемый в CloudFront браузером (возможно, измененный в заголовках запроса триггером Lambda @ Edge Request), когда настройки поведения кэша do включите в белый список заголовок Host для пересылки к источнику.

Таким образом, по сути, имя должно совпадать, если заголовок Host переадресован, и должно отличаться, если это не так.

Кроме того, если оно отличается, это имя хоста должно быть действительно настроено в DNS и указывать на назначенную конечную точку регионального API - вы не можете просто указать на назначенную цель псевдонима DNS в качестве исходного доменного имени.

К сожалению, в некоторых случаях CloudFront несколько сбивает с толку использование 403 ошибок. Иногда этот код используется для ошибок, которые более правильно будут рассматриваться как ошибки 400 или 421, поэтому тело ответа важно при проверке определенных проблем с 403. Если вы указываете доменное имя на CloudFront, не устанавливая этот домен в качестве альтернативного имени домена для распространения вы получите 403 с телом, в котором написано «Плохой запрос», и событие не будет зарегистрировано в ваших журналах CloudFront, поскольку отсутствующий параметр альтернативного имени домена не позволяет CloudFront отображать этот запрос в конкретный дистрибутив.

...