Найти ближайший регион AWS со сценария на стороне клиента

Question

Я работаю над проектом, где мне нужно выбрать ближайшую область S3 из браузера. В регионе Франкфурта есть только один API, который может раздавать токены для всех регионов S3. Я больше не могу использовать маршруты с задержкой (Route53), потому что он всегда будет в одном экземпляре EC2.

Я думал о следующих вариантах:

1. Ping всех соответствующие регионы (Pinging конечной точки DynamoDB довольно быстро) и выбрать самый быстрый ответ. Чтобы избежать взлома, я мог бы пинговать конечную точку 3 раза. Проблема заключается в том, что временный щелчок выбирает точку S3, которая может быть далеко.

2. Установите сервер t1.micro, который отвечает своей областью во всех применимых регионах. Маршрут с задержкой используется для доступа к самому быстрому экземпляру EC2. Хотя это должно работать (оно работало в прошлом), мне нужен экземпляр ECC 24/7, который обеспечивает только самый быстрый регион. Это слишком дорого для этой цели.

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

4. Используйте один экземпляр t1.micro и добавьте эластичный IP для каждой области. NGINX можно настроить для прослушивания по IP-адресам и возврата другого региона для каждого адреса. Route53 должен быть настроен таким образом, чтобы он имел маршрут на основе задержки, который разрешает каждый IP-адрес. Таким образом, я могу использовать только один экземпляр, но с некоторыми эластичными IP-адресами, чтобы получить тот результат, который мне нужен.

5. К сожалению, я не могу разрешить DNS для IP-адреса из браузера. В противном случае я мог бы создать несколько маршрутов на основе задержки, которые будут маршрутизироваться к вымышленному IP-адресу. Простое решение имени хоста даст мне IP-адрес и скажет, в какой области он представляет.

Было бы здорово, если бы AWS предоставила конечную точку, которую клиенты могли бы использовать для определения самой быстрой области. У кого-нибудь есть еще одно умное решение, которое работает в масштабе и не стоит слишком дорого?

Answer 1

Некоторые другие варианты:

• Используйте один Amazon S3 область, но использование Amazon CloudFront - это будет кэшировать контент ближе к пользователям
• Используйте Route 53 Задержка на основе маршрутизации к разрешить DNS-имя, отличающееся в зависимости от местоположения. У вас есть разрешение на различные записи CNAME, все из которых возвращаются во Франкфурт, но когда вы получаете запросы, вы можете определить ближайший регион по доменному имени, которое использовалось для его получения (запутанное, eh!)
• Подпишитесь на услугу, MaxMind, чтобы определить географическое положение пользователя.

Answer 2

Это решение работает только работает для не-HTTPS сайтов

Я имею установку другое решение, которое использует задержки на основе маршрутизации для различных DynamoDB конечных точек. Все DynamoDB конечные точки отвечают следующим ответ

healthy: dynamodb.<region>.amazonaws.com 

Предположим, что веб-сайт размещен на example.com, и я хочу, чтобы быть в состоянии найти ближайший регион от нас-восток, ес-центрально-1, ар -southeast-1 и са-восток-1, а затем создать четыре задержку на основе маршрутов:

region.example.com CNAME dynamodb.us-east-1.amazonaws.com 
region.example.com CNAME dynamodb.eu-central-1.amazonaws.com 
region.example.com CNAME dynamodb.ap-southeast-1.amazonaws.com 
region.example.com CNAME dynamodb.sa-east-1.amazonaws.com 

Когда клиент вызывает запрос HTTP GET на http://region.example.com то он получает обратно здоровую реакцию с ближайшим регионом. Это довольно тривиально, чтобы извлечь регион из этой строки.

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

Более серьезным недостатком является то, что вы не можете использовать этот метод с помощью https, потому что DynamoDB отвечает сертификатом Amazon AWS. Выдача HTTP-запросов с загруженной страницы https не допускается (смешанный контент).