Мы обслуживаем видео из контейнера S3 (в Мумбаи) для пользователей в одном регионе (Индия). Мы ожидаем, что тысячи пользователей будут получать доступ к этим файлам только из Индии. Стоит ли использовать распределение CloudFront? Будет ли уменьшена задержка, если мы используем CloudFront? Сможет ли S3 справиться с пропускной способностью, если мы не используем CloudFront?
Спасибо за помощь.
решение1
С точки зрения производительности, да, это, скорее всего, полезно.
В настоящее время CloudFront имеет 5 периферийных местоположений в Индии (Ченнаи (2), Нью-Дели (1) и Мумбаи (2)), поэтому это говорит о том, что с помощью CloudFront можно достичь меньших задержек просто потому, что ваш контент, скорее всего, будет находиться ближе к пользователям (в зависимости от их географического распределения)...
Однако при загрузке из периферийных местоположений в Индии на CloudFront взимается дополнительная плата в размере 0,17 долл. США за ГБ по сравнению с 0,1093 долл. США за ГБ при загрузке напрямую из S3 в Мумбаи. (При использовании CloudFront + S3 плата за полосу пропускания S3 не применяется).
Итак, да, «полезно», но невозможно сказать, достаточно ли это полезно, чтобы оправдать затраты в данном конкретном географическом регионе.
S3 имеетруководства по передовой практикедля сегментов, которые ожидают частоту запросов свыше 800 (пиковая) или 300 (устойчивая) GETзапросов в секунду, когда CloudFront также не используется. Служба будет масштабироваться за пределами этих значений, но следование рекомендациям помогает ей масштабироваться более эффективно. (Горячие ключи и горячие точки индекса не так легко масштабируются, как хорошо распределенные ключи). Для частот запросов ниже 100 запросов/с никаких особых соображений не требуется.
Дополнительная опция -S3 Ускорение передачи, который выборочно направляет запросы через AWS "Edge Network" (другими словами, CloudFrontтранспортная сеть) без какого-либо фактического кэширования. В Мумбаи это $0,04/ГБ + $0,1093/ГБ за загрузки. Преимущество здесь в том, что браузер потенциально подключается к серверу в пограничном местоположении, который проксирует соединение оттуда обратно в S3. Это заставляет трафик проходить по сети AWS как можно большее расстояние, прежде чем будет передан в общедоступный Интернет, что может значительно сократить время передачи за счет оптимизации передачи и обработки потери пакетов в промежуточном месте ближе к зрителю. Когда используется ускорение передачи S3, логика DNS, которую CloudFront использует для отправки запросов на ближайший периферийный сервер, вместо этого используется для определения наилучшего способа подключения данного зрителя обратно в регион S3 — поэтому он может подключить пользователя напрямую к S3 (в этом случае с вас не будет взиматься плата за пропускную способность в размере $0,04/ГБ за функцию ускорения для этого запроса), или он может направить его через пограничную сеть (в этом случае с вас будет взиматься плата). Идея здесь в том, что функция автоматически обходит себя для запросов, где она, скорее всего, не поможет, на основе геолокации запрашивающего относительно бакета. Когда вы включаете это в бакете, вы также меняете конечную точку бакета на bucket-name.s3-accelerate.amazonaws.com. Он поддерживает только интерфейс REST, а не функцию хостинга веб-сайта, но это нормально, если вы не используете такие функции, как перенаправления и индексирование документов. Учитывая вашу географию и особенности ценообразования на полосу пропускания там, это может быть хорошим местом для начала.