mtr, traceroute

Маршруты они там у себя приоритеты сами крутят, поэтому нужно чтобы трафик проверялся оттуда

Оке, спасибо, буду гуглить пока в этом направлении

Я бы начал с поднятия в тех регионах небольшого инстанса и проверки скорости оттуда. Может и не в провайдере дело

В смысле проверить быстрее ли будет когда там инстанс поднимется? Я просто это и хотела сделать, но не уверенна в выборе инструмента для перенаправления юзеров с тех регионов

Потому что у меня ведь так тогда будет 2 с3 бакета и 2 клаудфронта и я так понимаю что нужно будет сверху их Лямбду накидывать или что-то подобное чтобы перенаправлять

14 секунд не похоже на cloudfront. Опишите что значит «s3+coudfrond для фронта»? Вы через эту связку статику отдаёте или ещё какую-то динамику через CF отдаёте?

Как вы замеряете это время? Если вы используете метрику из GA или подобного инструмента, то возможно вы смотрите на метрику полной загрузки, те включая данные которые уже сам webapp загружает из вашего API и если он далеко и медленный, то и время большое.

Для CF верно оценивать метрики типа First byte recived, тк CF не ждёт полной загрузки объекта, а сразу же отдаёт поток пользователям (как прокси) и одновременно кэширует.

На с3 у нас файлы фронта, которые кэшируются и хостятся через клаудфронт и при деплое соответственно обновляются.  Смотрю через GA Page Lad Speed, а конкретно через карту https://images-ext-1.discordapp.net/external/0lJjUVVh63ZL7PbAhEgyJ6uGn8vk9wCsgEMBM7Csdtw/https/image.prntscr.com/image/Z6csHQ1EQliX6z_1Y_XOOw.png?width=1068&height=543

Для этого есть geo based или latency based routing. Если домен в Route53, то точно такое есть. Если домен где-то ещё, то уже нужно смотреть возможности того инструмента.

Получается если юзер с Азии даже получает кешированный фронт, но апи далеко (в Лондоне), загрузка данных будет выше? Потому что тогда проблема скорее всего в этом

Да, домен в роут53

Сори, за элементарные вопросы)

Да. Ведь CF вам быстро отдаёт статику с s3 и все. Дальше уже ваше веб приложение делает что-то и если это что-то далеко, то вы до него идёте обычным медленным интернетом пользователя.

Ну понятно теперь! Спасибо большое, в первую очередь будем это править. Подскажите еще пожалуйста, для EC2 по регонам распределение делать через Load Balancer? У нас стандартный EC2 Load Balancer

С API есть два варианта:
1. Если нет возможности сделать локальные точки в разных регионах, например когда база пользователей должна быть единая общая и нет желания использовать что-то типа AWS Aurora global tables. Вы можете ускорить за счёт AWS Global Accelerator - это когда через те же CF edge по всему миру будет раздаваться ваш load balancer или ec2. В этом случае пакеты будут доходить от пользователя до ближайшего CF Edge и потом уже по AWS backbone сетям идти к API. Будет быстрее, но от Азии до Лондона все равно есть расстояние и скорость света в оптике не обмануть.
2. В каждом нужном регионе поднимать отдельную сборку API и через Route53 geo или latency based routing отправлять пользователей в ближайший API. Самый лучший вариант по скорости, но придётся думать над репликацией и синхронизацией (если это нужно, например что будет если пользователь поехал в отпуск и его из другой страны отпарили уже в другой API)

Как то так )

А может ли cloudfront кешировать апишку?

Вот если второй вариант использовать, но при этом сохранить единную базу, нужно будет через Aurora Global Tables работать? Просто как раз таки недавно перешли на Aurora, так что с этим я думаю проблем не будет

Может, но тогда это уже не стандартная API. Вы можете и /api раздавать через CF выключив при этом кэш для именно этого origin

Так например делают когда не хотят делать отдельный поддомен для api и делают что /content летит на статику, а /api куда то ещё