Справочная информация:
У меня есть Javascript, размещенный в корзине S3 со статическим веб-сайтом + Распределение Cloudfront + Настройка маршрута 53.Мне нужен Cloudfront, потому что мне нужен собственный домен с поддержкой SSL.Это отлично работает.Например, к сценарию можно получить доступ по адресу https://app.example.org/myscript.js. Этот URL-адрес предоставляется клиентам для размещения на их веб-страницах, и я не могу его изменить.
Настройка в Route 53 выглядит следующим образом:
app.example.org => Cloudfont Distribution (s3://app.example.org)
Что я хочу:
Я хочу настроить промежуточную среду для новых функций.Я бы хотел направить 10% производственного запроса на другую версию скрипта.
То, что я пытался
Я пытался настроить еще одно ведро S3 со статическим webiste + облачный фронт с другим альтернативным доменным именем (например, app-beta.example.org),
Мне нужно использовать другой альтернативный поддомен, потому что Cloudfront не допускает одно и то же альтернативное имя домена с несколькими дистрибутивами.
В Route 53 я установил записи псевдонима A следующим образом:
app-beta.example.org => Alias Cloudfont Distribution (s3://app-beta.example.org)
app.example.org => Alias app-beta.example.org (weighted 10)
app.example.org => Alias Cloudfont Distribution (s3://app.example.org) (weighted 100)
Почему это не сработало
Оказалось, что это не будет работать:
Поскольку запрашиваемые домены одинаковы app.example.org, дистрибутив облачного фронта (s3: //app.example.org) будет принимать запрос независимо от записиapp.example.org => Alias app-beta.example.org.
Я думаю, что здесь Route 53 пытается перенаправить трафик в облачный фронт в соответствии с правилами веса, но в конце концов, когда запросы достигают облачного фронта, облачный фронт учитывает «альтернативное имя домена» и использует его с (app.example.org)независимо.
Как насчет того, чтобы не использовать cloudfront?
Я думал об использовании EC2 или EBS для сервера nginx, обслуживающего статические файлы javascript.Это может сработать.Но:
файл javascript будет запрошен во всем мире.Использование EC2 или EBS означает для некоторых пользователей более высокую задержку.Это не идеально.
это означает дополнительные ресурсы для управления и стоимости.
Как насчет lambda @ Edge?
Технически lambda @ Edge - идеальное решение, если оно дешевле.Да, это уже дешево ($ 0,0000006 за запрос), но в нашем случае мы заплатим за это более 10 тысяч долларов США.(скрипт запрашивается> 10 миллиардов раз в месяц, и для настройки требуется 2 лямбда-функции)
Вопрос
Есть ли другой способ, которым я могу достичьчто я хочу ?(т.е. постепенно выкатывать новую версию без изменения URL)