Вопросы и ответы по Amazon CloudFront

Amazon CloudFront – это веб‑сервис, предоставляющий компаниям и разработчикам интернет‑приложений простой и экономичный способ распространения контента с высокой скоростью передачи данных и низкими задержками. Подобно другим сервисам AWS, Amazon CloudFront основан на принципах самообслуживания с оплатой по факту использования без каких‑либо долгосрочных обязательств или минимальных платежей. При использовании CloudFront файлы доставляются конечным пользователям через глобальную сеть периферийных местоположений.

Amazon CloudFront предоставляет простой API, позволяющий вам:

• распространять контент с низкими задержками и высокой скоростью передачи данных путем обслуживания запросов с использованием сети периферийных местоположений по всему миру;
• начать работу без заключения контрактов и минимальных обязательств.

Нажмите «Создать бесплатный аккаунт» на странице сведений об Amazon CloudFront. При выборе в качестве источника файлов для Amazon CloudFront другого сервиса AWS следует зарегистрироваться в этом сервисе до создания дистрибутивов CloudFront.

Для использования Amazon CloudFront требуется предпринять следующие шаги.

• Для статических файлов: сохраните их окончательные версии на одном или нескольких серверах источников. Можно использовать для этого корзины Amazon S3. Для динамически создаваемого и индивидуально настраиваемого контента можно использовать в качестве сервера источника Amazon EC2 или любой другой веб‑сервер. Серверы источника хранят или генерируют контент для последующего распространения с помощью Amazon CloudFront.
• Зарегистрируйте серверы источника в Amazon CloudFront, используя простой вызов API. Этот вызов вернет доменное имя CloudFront.net, которое можно использовать для распространения контента с серверов источника с помощью сервиса Amazon CloudFront. Например, можно зарегистрировать корзину Amazon S3 с именем bucketname.s3.amazonaws.com в качестве источника статического контента и инстанс Amazon EC2 с именем dynamic.myoriginserver.com в качестве источника динамического контента. После этого с помощью API или Консоли управления AWS можно создать базу раздачи Amazon CloudFront, которая вернет имя вида abc123.cloudfront.net в качестве доменного имени базы раздачи.
• Доменное имя cloudfront.net либо созданный на его основе псевдоним CNAME можно использовать в интернет‑приложениях, проигрывателях мультимедиа или на веб‑сайтах. Все запросы, включающие доменное имя cloudfront.net или имя CNAME, перенаправляются к ближайшему периферийному местоположению для обеспечения максимальной производительности при доставке контента. При выполнении запроса периферийное местоположение пытается найти локальную копию файла. Если такой копии нет, Amazon CloudFront получает ее с сервера источника. Полученная копия сохраняется в этом периферийном местоположении для обслуживания дальнейших запросов.

Amazon CloudFront использует глобальную сеть периферийных местоположений и периферийные серверы кэширования в регионах, чтобы обеспечить хранение копий объектов как можно ближе к конечным пользователям. Amazon CloudFront следит, чтобы запрос конечного пользователя обслуживался ближайшим к нему периферийным местоположением. В результате такого подхода запросы пользователя проходят минимальное расстояние, что положительно сказывается на производительности. Amazon CloudFront поддерживает постоянное соединение с серверами‑источниками, чтобы как можно быстрее получать файлы, копий которых нет в периферийных местоположениях или на периферийных серверах кэширования в регионах. Наконец, Amazon CloudFront использует для ускорения доставки контента пользователям дополнительную оптимизацию, например расширенное исходное окно перегрузки протокола TCP.

Как и другие сервисы AWS, Amazon CloudFront не требует минимальных обязательств и оплачивается только по факту использования. В отличие от самостоятельного хостинга Amazon CloudFront избавляет от расходов и сложностей, связанных с поддержкой сети кэширующих серверов, распределенных по всему Интернету, и не требует избыточных ресурсов для обслуживания пиковых нагрузок. Amazon CloudFront использует принцип объединения одновременных клиентских запросов одного и того же файла в пределах периферийного местоположения, выполняя единственный запрос на сервер источника для получения копии этого файла. Это снижает нагрузку на сервер источника, уменьшая потребность в масштабировании инфраструктуры источника, что обеспечивает дополнительную экономию.

Кроме того, при использовании источников AWS (Amazon S3, Amazon EC2 и т. п.) с 1 декабря 2014 года не взимается плата за исходящую передачу данных AWS в Amazon CloudFront. Это касается передачи данных из всех регионов AWS в любые периферийные местоположения CloudFront по всему миру.

Amazon CloudFront использует стандартные заголовки управления кэшированием, установленные клиентами для файлов с целью разделения статического и динамического контента. Доставка всего контента с использованием единой базы раздачи Amazon CloudFront обеспечивает оптимизацию производительности для сайта или интернет‑приложения в целом. При использовании источников AWS вы получаете ряд преимуществ: это интеграция Amazon CloudFront с другими сервисами AWS, а также удобство использования и повышение производительности и надежности, поскольку AWS получает возможность отслеживать и корректировать маршруты до источников, проводить мониторинг работоспособности системы и быстро реагировать на любые проблемы. Еще одним преимуществом является возможность использования разных источников для разных типов контента, например Amazon S3 для статических объектов, Amazon EC2 для динамического контента и собственных источников для стороннего контента. Оплата при этом будет начисляться только за использованные ресурсы.

Amazon CloudFront предпочтителен для распространения часто запрашиваемого статического контента, например популярных изображений на веб‑сайтах, видеоматериалов, медиафайлов или программного обеспечения для загрузки. В этом случае доставка с использованием периферийных местоположений имеет очевидные преимущества.

Amazon CloudFront позволяет быстро начать использовать преимущества высокопроизводительной доставки контента без предварительного заключения контрактов и высоких расходов. Amazon CloudFront предоставляет разработчикам доступ на основе модели самообслуживания с низкими ценами и оплатой ресурсов по факту использования. Дополнительные преимущества разработчикам обеспечивает тесная интеграция с другими сервисами AWS. Предлагаемое решение просто интегрируется с серверами источника сервисов Amazon S3, Amazon EC2 и Elastic Load Balancing, предоставляя разработчикам мощное сочетание надежного хранения с высокопроизводительной доставкой. Amazon CloudFront также интегрирован с сервисами Amazon Route 53 и AWS CloudFormation для дополнительной оптимизации производительности и упрощения настройки.

Amazon CloudFront поддерживает контент, который можно отправлять по протоколам HTTP или WebSocket. Сюда относятся динамические веб‑страницы и приложения (HTML, PHP или приложения на основе WebSocket), а также распространенные форматы статических файлов, входящих в интернет‑приложение, например изображения для веб‑сайта, аудио‑, видео‑ и другие медиафайлы или программное обеспечение для загрузки. Amazon CloudFront также поддерживает прямые трансляции или потоковую передачу мультимедийных материалов по требованию через HTTP.

Да. Amazon CloudFront работает с любыми серверами‑источниками, хранящими окончательные оригинальные версии контента, как статического, так и динамического. За использование собственных источников дополнительная плата не взимается.

Для каждого источника, добавляемого к базе раздачи CloudFront, можно назначить резервный, который может быть использован для автоматического обслуживания трафика, когда основной источник недоступен. Можно выбрать комбинацию кодов состояния HTTP 4xx/5xx, которые при возврате из основного источника инициируют переключение на резервный источник. Это может быть любое сочетание двух источников AWS и не AWS.

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

Да. Консоль управления AWS можно использовать для настройки сервиса Amazon CloudFront и управления им с помощью простого интерактивного веб‑интерфейса. Консоль управления AWS поддерживает большинство функций Amazon CloudFront, что позволяет использовать Amazon CloudFront с низкими задержками без разработки кода или установки специального ПО. Доступ к Консоли управления AWS бесплатно предоставляется по адресу https://console.aws.amazon.com.

Для управления базами раздачи Amazon CloudFront предлагаются различные инструменты и библиотеки для разных языков программирования, доступные в нашем центре ресурсов.

Да. Вы можете указать начало зоны (example.com) на свой дистрибутив Amazon CloudFront двумя способами.

Используя Amazon Route 53, авторизованный DNS‑сервис AWS, можно настроить псевдоним, связывающий начало зоны, или корневой домен (example.com), соответствующего имени DNS с дистрибутивом Amazon CloudFront. После этого Amazon Route 53 будет возвращать по имени псевдонима соответствующий IP‑адрес (или адреса) дистрибутива CloudFront. В Route 53 плата за обслуживание запросов псевдонимов, привязанных к дистрибутиву CloudFront, не взимается.

Кроме того, используя статические IP-адреса для передачи по произвольному пути CloudFront, вы можете указать свой апекс-домен для дистрибутива CloudFront с помощью любого поставщика DNS. Просто создайте стандартные записи A, используя 3 статических IP-адреса, предоставленных CloudFront. Эта функция расширяет поддержку апекс-доменов за пределы Route 53, при этом ваш трафик по-прежнему автоматически перенаправляется в ближайшие периферийные местоположения, что обеспечивает высокопроизводительную доставку контента по всему миру.

CloudFront доставляет контент через всемирную сеть центров обработки данных, называемых периферийными местоположениями. Периферийные серверы кэширования в регионах являются связующими звеньями между серверами‑источниками и периферийными местоположениями, которые обеспечивают передачу контента конечным пользователям по всему миру. Это помогает повысить производительность для конечных пользователей, одновременно снижая операционные нагрузки и стоимость масштабирования серверов‑источников.

Amazon CloudFront имеет множество распределенных по миру периферийных серверов кэширования в регионах (или REC), обеспечивающих дополнительный уровень кэширования для конечных пользователей. Каждый из них является связующим звеном между сервером‑источником и периферийными местоположениями AWS, которые обеспечивают передачу контента конечным пользователям. По мере угасания интереса пользователей к тому или иному кэшированному объекту он удаляется из отдельных периферийных местоположений, освобождая место для более часто запрашиваемого контента. Периферийные серверы кэширования в регионах обладают более объемным кэшем, чем любой отдельный периферийный сервер, поэтому объекты сохраняются дольше. Это позволяет хранить большую часть контента в непосредственной близости от конечных пользователей, сокращает количество вынужденных повторных обращений CloudFront к серверам‑источникам и повышает общее качество обслуживания. Например, периферийные местоположения CloudFront в Европе при поиске объектов теперь обращаются к периферийному серверу кэширования во Франкфурте и только потом отправляют запрос к серверу‑источнику. Периферийные серверы кэширования в регионах могут использоваться с любыми источниками, такими как S3, EC2 или пользовательские источники. REC пропускаются в регионах, в которых в настоящее время находится источник вашего приложения.

Да. Для использования этой возможности не требуется дополнительная настройка раздач CloudFront, она включена по умолчанию для всех новых и ранее созданных баз раздачи. Дополнительная плата за использование этой функции не взимается.

Для доставки контента Amazon CloudFront использует глобальную сеть периферийных местоположений и периферийных серверов кэширования в регионах. Полный список местоположений Amazon CloudFront см. здесь.

Да, возможность географического ограничения позволяет задать список стран, из которых будет доступен определенный контент. Как вариант, можно задать список стран, пользователи из которых не будут иметь доступа к контенту. В обоих случаях на запрос из страны, для которой действует ограничение, CloudFront возвращает ответ с кодом HTTP 403 (Forbidden).

Точность отнесения IP‑адреса к какой‑либо стране зависит от региона. По последним данным, общая точность соответствия нашей базы IP‑адресов странам составляет 99,8 %.

Да, вы можете создать собственные сообщения об ошибках (например, файлы HTML или изображения .jpg) с логотипами и контентом для ответов HTTP с кодами 4xx и 5xx. После этого можно настроить Amazon CloudFront на возврат пользователям таких сообщений, когда источник возвращает CloudFront заданные коды ошибок.

По умолчанию (при отсутствии заголовка управления кэшированием) каждое периферийное местоположение при получении запроса проверяет наличие обновленной версии файла, если с момента предыдущей проверки прошло более 24 часов. Это время называется сроком действия объекта. С помощью заголовков управления кэшированием для файлов источника срок действия можно устанавливать от нуля секунд до любого нужного значения. Amazon CloudFront использует эти заголовки для определения, как часто следует проверять источник на наличие обновленной версии файла. Если срок действия ноль секунд, Amazon CloudFront будет проверять файл на сервере источника при каждом запросе. Если файлы изменяются не слишком часто, рекомендуется установить больший срок действия, а для управления обновлениями таких файлов реализовать систему управления версиями.

Для удаления файла из периферийного местоположения имеется несколько возможностей. Можно просто удалить файл из источника, и когда в периферийных местоположениях истечет срок действия, заданный в HTTP‑заголовке каждого объекта, он будет удален. Для удаления из всех периферийных местоположений Amazon CloudFront оскорбительных или потенциально вредоносных материалов, удалить которые требуется до истечения срока действия, можно использовать API Invalidation. Стоимость запросов удаления можно посмотреть здесь.

При удалении отдельных объектов можно создавать запросы удаления одновременно не более чем для 3000 объектов для каждого дистрибутива. Это может быть один запрос на удаление до 3000 объектов, или до 3000 запросов по одному объекту на каждый, или любая комбинация запросов и объектов, суммарно не превышающая 3000 объектов.

При использовании знака подстановки (*) можно отправить запросы для одновременного аннулирования до 15 путей. Параллельно с этим можно выполнять запросы на удаление до 3000 отдельных объектов на базу раздачи, т. е. ограничение на использование API Invalidation со знаками подстановки не влияет на ограничение по удалению отдельных объектов. При превышении этих лимитов запросы API Invalidation будут возвращать ошибку, пока не завершится какой‑либо из уже выполняющихся запросов.

Удаление следует использовать только при непредвиденных обстоятельствах. Если заранее известно, что файлы потребуется часто удалять из кэша, рекомендуется реализовать систему управления версиями файлов либо установить для файлов непродолжительный срок действия.

Встроенные точки присутствия (POP) CloudFront – это тип инфраструктуры CloudFront, развернутый ближе всего к конечным зрителям в сетях интернет-провайдеров (ISP) и операторов мобильной сети (MNO). Встроенные POP специально разработаны для трансляции крупномасштабных событий в прямом эфире, просмотра видео по требованию (VOD) и загрузки игр. Такими встроенными POP владеет и управляет Amazon. Они развертываются на последней миле сетей ISP и MNO, чтобы избежать узких мест в перегруженных сетях, соединяющих конечных зрителей с источниками контента, и повысить производительность.

Встроенные POP CloudFront отличаются от обычных местом их развертывания и контентом, который они доставляют. Встроенные POP CloudFront развертываются непосредственно в сетях ISP и MNO, в отличие от POP CloudFront, которые развертываются в сети AWS. Встроенные POP специально созданы для доставки крупномасштабного кэшируемого трафика, такого как видеопотоки и загрузки игр, в то время как POP CloudFront предназначены для выполнения различных рабочих нагрузок, включая работу с кэшируемым и динамическим контентом.

Встроенные POP CloudFront предназначены для предоставления кэшируемого контента, доступного для нескольких конечных зрителей одновременно, такого как широкомасштабная потоковая передача видео в реальном времени, или по требованию, или загрузка игр.

Нет. Дополнительная плата за использование встроенных POP CloudFront не взимается.

Встроенные POP – это дополнительная возможность, предназначенная для предоставления крупномасштабного кэшируемого трафика. Обратитесь к представителю отдела продаж AWS, чтобы узнать, подходят ли встроенные POP для ваших рабочих нагрузок.

Нет. Вам не нужно создавать новый дистрибутив специально для встроенных POP. Если ваша рабочая нагрузка соответствует требованиям, CloudFront по запросу активирует встроенные POP для существующего дистрибутива.

Для предоставления контента вам не нужно выбирать между встроенными POP CloudFront и обычными. После активации встроенных POP для дистрибутива система маршрутизации CloudFront динамически использует как POP CloudFront, так и встроенные POP для доставки контента, обеспечивая оптимальную производительность для конечных пользователей.

Свяжитесь с нами, чтобы начать развертывание встроенных POP в своей сети.

Портал встроенных POP можно использовать для управления встроенными POP, развернутыми в вашей сети. Он интегрирован с порталом AWS Interconnect и предоставляет унифицированный интерфейс для простого самообслуживания различных задач, связанных со всем жизненным циклом этих POP. Сюда входит запрос новых устройств, отслеживание хода выполнения запросов, мониторинг статистики производительности и обращение за поддержкой. Вы можете получить доступ к порталу, выполнив аутентификацию с помощью единого входа (SSO) со своего аккаунта PeeringDB.

Amazon CloudFront (за исключением доставки контента через встроенные точки присутствия CloudFront) включен в перечень сервисов, которые соответствуют требованиям стандарта безопасности данных индустрии платежных карт (PCI DSS) уровня 1 для торгово‑сервисных предприятий (самого высокого уровня для поставщиков услуг). Подробности см. в руководстве для разработчиков.

AWS расширила свою программу соответствия требованиям HIPAA. Теперь сервис Amazon CloudFront (за исключением доставки контента через встроенные точки присутствия CloudFront) тоже соответствует требованиям HIPAA. Если вы заключили с AWS договор делового партнерства (BAA), можно использовать Amazon CloudFront (за исключением доставки контента через встроенные точки присутствия CloudFront) для ускорения доставки закрытой медицинской информации (PHI). Подробную информацию см. на странице Соответствие требованиям HIPAA и в нашем руководстве для разработчиков.

Amazon CloudFront (за исключением доставки контента через встроенные точки присутствия CloudFront) соответствует требованиям SOC (System & Organization Control). Отчеты SOC представляют собой отчеты независимых сторонних экспертов, которые показывают, как AWS реализует ключевые механизмы управления и решает задачи соответствия требованиям. Подробную информацию см. на странице Соответствие AWS требованиям SOC и в нашем руководстве для разработчиков.

Отчеты AWS SOC 1 и SOC 2 можно получить с помощью AWS Artifact, портала самообслуживания для доступа к отчетам по соответствию AWS требованиям. Войдите в раздел AWS Artifact в Консоли управления AWS или см. подробности на странице Начало работы с AWS Artifact. Последняя версия отчета AWS SOC 3 находится в открытом доступе на веб‑сайте AWS.

В настоящее время Amazon CloudFront поддерживает запросы GET, HEAD, POST, PUT, PATCH, DELETE и OPTIONS.

Amazon CloudFront не кэширует ответы на запросы POST, PUT, DELETE и PATCH. Эти запросы перенаправляются обратно на сервер источника. При этом можно разрешить кэширование ответов на запросы OPTIONS.

При наличии готового дистрибутива Amazon CloudFront можно перейти к использованию HTTP/2 с помощью API или Консоли управления. В Консоли управления нужно перейти на страницу «Distribution Configuration» (Конфигурация базы раздачи) и найти раздел «Supported HTTP Versions» (Поддерживаемые версии HTTP). В этом разделе можно выбрать между HTTP/2, HTTP/1.1 и HTTP/1.0. Для новых дистрибутивов Amazon CloudFront использование HTTP/2 активировано по умолчанию.

В настоящий момент Amazon CloudFront поддерживает HTTP/2 для доставки контента в браузеры и клиентские приложения пользователей. Для взаимодействия периферийных местоположений и серверов‑источников Amazon CloudFront продолжает использовать HTTP/1.1.

В данный момент это невозможно. Однако большинство современных браузеров поддерживают HTTP/2 только с использованием зашифрованного подключения. Подробнее об использовании SSL в Amazon CloudFront см. здесь.

HTTP/3 – это третья основная версия протокола передачи гипертекста. HTTP/3 использует QUIC, протокол пользовательских дейтаграмм (UDP), основанный на потоковом мультиплексировании и безопасном транспортном протоколе, который объединяет и улучшает возможности существующих протоколов управления передачей (TCP), TLS и HTTP/2. HTTP/3 обладает рядом преимуществ по сравнению с предыдущими версиями HTTP, включая более быстрое время отклика и повышенную безопасность.

HTTP/3 работает на базе QUIC, нового высокопроизводительного, отказоустойчивого и безопасного транспортного протокола Интернета. Поддержка HTTP/3 в CloudFront построена на базе s2n-quic, новой реализации протокола QUIC с открытым исходным кодом на языке Rust. Чтобы узнать больше о QUIC, ознакомьтесь с блогом Представляем s2n-quic. 

Клиенты постоянно ищут более быстрые и безопасные приложения для своих конечных пользователей. По мере роста проникновения Интернета во всем мире и увеличения числа пользователей, выходящих в сеть через мобильные и удаленные сети, потребность в повышении производительности и надежности становится как никогда высокой. Протокол HTTP/3 позволяет это сделать, поскольку он предлагает несколько улучшений производительности по сравнению с предыдущими версиями HTTP:

1. Более быстрые и надежные соединения: CloudFront использует 1-RTT для квитирования TLS для HTTP/3, сокращая время установления соединения и соответственно уменьшая количество отказов квитирования по сравнению с предыдущими версиями HTTP.
2. Повышение производительности веб-сайта: реализация HTTP/3 в CloudFront поддерживает миграцию соединений на стороне клиента, позволяя клиентским приложениям восстанавливаться после плохого соединения с минимальными перерывами. В отличие от TCP, QUIC не работает без потерь, благодаря чему эта технология лучше подходит для перегруженных сетей с высокой степенью потери пакетов. Кроме того, QUIC обеспечивает более быстрое повторное подключение во время переключения с Wi-Fi или сотовой связи.
3. Безопасность: HTTP/3 лучше обеспечивает безопасность по сравнению с предыдущими версиями HTTP за счет шифрования пакетов, обмениваемых во время сеансов согласования TLS. Это затрудняет проверку промежуточными устройствами, обеспечивая дополнительную конфиденциальность и уменьшая количество атак типа «человек посередине». Поддержка HTTP/3 в CloudFront построена на базе s2n-quic и Rust, где особое внимание уделяется эффективности и производительности.
    

Вы можете включить HTTP/3 для новых и существующих дистрибутивов Amazon CloudFront с помощью консоли CloudFront, действия UpdateDistribution API или шаблона Cloudformation. В Консоли управления нужно перейти на страницу «Distribution Configuration» (Конфигурация базы раздачи) и найти раздел «Supported HTTP Versions» (Поддерживаемые версии HTTP). В этом разделе можно выбрать между HTTP/3, HTTP/2, HTTP/1.1 и HTTP/1.0.

Когда вы включаете HTTP/3 на вашем дистрибутиве CloudFront, CloudFront автоматически добавляет заголовок Alt-Svc, который используется для оповещения о том, что поддержка HTTP/3 доступна, и вам не нужно вручную добавлять заголовок Alt-Svc. Мы ожидаем, что вы включите поддержку нескольких протоколов в своих приложениях, так что если приложение не сможет установить соединение HTTP/3, оно вернется к HTTP /1.1 или HTTP/2. Иными словами, клиенты, не имеющие поддержки HTTP/3, смогут взаимодействовать с дистрибутивами CloudFront с поддержкой HTTP/3, используя HTTP/1.1 или HTTP/2. Поддержка Fallback является обязательной частью спецификации HTTP/3 и реализована всеми основными браузерами, поддерживающими HTTP/3.

В настоящее время CloudFront поддерживает HTTP/3 для связи между клиентами/браузерами и периферийными местоположениями CloudFront. Для взаимодействия периферийных местоположений и серверов‑источников CloudFront продолжает использовать HTTP/1.1.

HTTP/3 использует QUIC, что требует TLSv1.3. Поэтому независимо от выбранной вами политики безопасности, для установления соединений HTTP/3 можно использовать только TLSv1.3 и поддерживаемые наборы шифров TLSv1.3. Подробности см. в разделе «Поддерживаемые протоколы и шифры, используемые между зрителями и CloudFront» руководства для разработчиков CloudFront.

Нет, за включение HTTP/3 на дистрибутивах Amazon CloudFront отдельная плата не взимается. Запросы HTTP/3 оплачиваются по тарифам на запросы в соответствии с вашим тарифным планом.

CloudFront SaaS Manager — новая функция Amazon CloudFront, которая помогает поставщикам программного обеспечения как услуги (SaaS) и платформ веб-разработки эффективно управлять доставкой контента на нескольких веб-сайтах. CloudFront SaaS Manager упрощает организациям развертывание и защиту многопользовательских приложений в любом масштабе. Внедряя повторно используемые конфигурации и параметры, CloudFront SaaS Manager снижает эксплуатационные издержки. Это исключает избыточную настройку и позволяет клиентам поддерживать согласованные настройки на своих веб-сайтах. Кроме того, CloudFront SaaS Manager предоставляет дополнительную гибкость для настройки параметров безопасности и автоматизации продления сертификатов для каждого веб-сайта при необходимости.

CloudFront SaaS Manager разработан для организаций, которые сталкиваются с проблемой эффективного управления несколькими веб-сайтами. Поставщики программного обеспечения как услуги (SaaS) и платформ веб-разработки сочтут это особенно ценным, поскольку оно позволяет им поддерживать одинаковые настройки на веб-сайтах своих арендаторов. Аналогичным образом, компании, управляющие несколькими корпоративными веб-сайтами, могут использовать его для стандартизации своего присутствия в Интернете при сохранении гибкости настройки отдельных сайтов. Если у вас всего несколько веб-сайтов или каждый веб-сайт содержит разные конфигурации CloudFront, то, скорее всего, лучше подойдет дистрибутив с одним арендатором (традиционное).

CloudFront доступен в качестве опции через Консоль AWS и API для клиентов, которые хотят управлять общими настройками в группах доменов. Для начала выполните следующие действия: 1/Определение общих настроек: создайте многопользовательский дистрибутив, содержащий общие настройки, которые будут служить шаблоном для групп доменов. 2/Создание клиентов для рассылки: создайте распределительных клиентов, позволяющих связывать домены и их сертификат TLS с многопользовательским дистрибутивом. 3/Точная настройка управления: при желании можно настроить параметры клиентов дистрибутива, применив переопределения.

Многопользовательский дистрибутив определяет базовую конфигурацию, которая будет распределена между доменами. Он содержит общие параметры конфигурации, такие как исходные конфигурации, поведение кэша и настройки безопасности. В отличие от стандартного дистрибутива, мультитенантный дистрибутив не может обслуживать трафик напрямую. Он предлагает настраиваемые параметризованные поля для удовлетворения уникальных потребностей каждого домена. Например: пути происхождения, зависящие от домена, или исходные доменные имена.

Арендатор дистрибутива представляет собой определенный домен, использующий мультитенантный дистрибутив. Он наследует базовую конфигурацию многопользовательского дистрибутива и должен иметь по крайней мере один домен или субдомен с действительным сертификатом TLS.
Каждый арендатор дистрибутора может включать следующие настройки:

• Уникальные исходные пути и/или доменные имена источников (определяемые значениями параметров в многопользовательском дистрибутиве)
• Настраиваемые сертификаты TLS
• Переопределения веб-списков ACL
• Переопределения географических ограничений
  

Да. Однако CloudFront работает с Менеджером сертификатов AWS (ACM), чтобы обеспечить удобную проверку управления доменом. Интеграция с ACM устраняет бремя выдачи сертификатов и управления ими и обеспечивает автоматическое управление жизненным циклом ваших сертификатов SSL/TLS, выпущенных Amazon. В случае выдачи сертификатов другим центром сертификации ACM поддерживает сертификаты, выпущенные сторонними центрами сертификации. В таких случаях вы будете нести ответственность за жизненный цикл сертификата (первоначальная загрузка, продление, последующая загрузка), а ACM будет отправлять владельцу аккаунта AWS уведомления об истечении срока действия сертификатов через CloudWatch и по электронной почте. Для получения дополнительной информации можете посетить https://aws.amazon.com/certificate-manager/faqs/.

Да, CloudFront поддерживает домены верхнего уровня или корневые домены (например, example.com или www.example.com). Клиенты могут использовать Route 53 для управления DNS и добавить запись ALIAS к своему апекс-домену, указывающую на домен, предоставленный CloudFront. Для клиентов, которые не могут использовать Route53 для управления собственными доменами, Anycast Static IP может предоставить выделенный набор IP-адресов, которые можно использовать вместо записей CNAME/ALIAS. Подробнее см. здесь.

Да. Плата за CloudFront зависит от количества созданных вами ресурсов клиента дистрибутива. Клиенты дистрибутива – это новые ресурсы, унаследовавшие настройки конфигурации многопользовательского дистрибутива CloudFront. Дополнительные сведения см. на странице цен CloudFront.

WebSocket – это протокол связи в режиме реального времени, обеспечивающих двунаправленную связь между клиентом и сервером по установленному на длительное время TCP-соединению. Используя постоянное открытое подключение, клиент и сервер могут обмениваться данными в режиме реального времени, при этом клиенту не нужно постоянно устанавливать новые подключения с целью проверить наличие новых данных для обмена. Подключения WebSocket часто используются в приложениях чата, многопользовательских играх, на платформах для совместной работы и трейдинговых платформах. Подробнее об использовании протокола WebSocket с Amazon CloudFront см. в нашей документации. 

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

Amazon CloudFront устанавливает соединения по протоколу WebSocket только в тех случаях, когда клиент включает заголовок «Upgrade: websocket», а сервер отвечает кодом состояния HTTP 101, который подтверждает возможность переключения на протокол WebSocket.

Да. Amazon CloudFront поддерживает зашифрованные подключения WebSocket (WSS) с помощью протокола SSL/TLS.

gRPC – это современная платформа удаленного вызова процедур (RPC) с открытым исходным кодом, которая обеспечивает двунаправленную связь между клиентом и сервером через длительное соединение HTTP/2. Используя постоянное открытое соединение, клиент и сервер могут отправлять друг другу данные в режиме реального времени без необходимости часто возобновлять соединения в поисках новых данных для обмена. gRPC хорошо подходит для случаев использования, где важны низкие задержки и высокая скорость передачи данных, таких как приложения для связи в режиме реального времени и онлайн-игры.

Протокол gRPC включен при каждом поведении кэша в ваших дистрибутивах CloudFront. Включение gRPC гарантирует, что в вашем дистрибутиве также будут включены HTTP/2 и поддержка запросов POST. Протокол gRPC поддерживает метод POST только через HTTP/2.

Amazon CloudFront обменивается данными через gRPC при соблюдении следующих условий:

1. в вашем дистрибутиве включен протокол HTTP/2;
2. в поведении кэша включены запросы POST и gRPC;
3. клиент отправляет заголовок content-type со значением application/grpc через соединение HTTP/2.

1. Безопасность. gRPC применяет протокол HTTP/2, который обеспечивает сквозное шифрование трафика от клиента до ваших исходных серверов. Кроме того, при использовании gRPC вы получаете AWS Shield стандартный без дополнительной оплаты, а AWS WAF можно настроить для защиты трафика gRPC от атак.
2. Более высокая производительность. gRPC использует двоичный формат сообщений, называемый буферами протоколов, который меньше традиционных полезных данных, таких как JSON, используемый в RESTful API. Обработка буферов протоколов требует меньше ресурсов процессора, поскольку данные представлены в двоичном формате, что означает более быстрый обмен сообщениями. Это приводит к повышению общей производительности.
3. Встроенная поддержка потоковой передачи. Потоковая передача является встроенной частью платформы gRPC. Она поддерживает семантику потоковой передачи как на стороне клиента, так и на стороне сервера. Это значительно упрощает создание потоковых сервисов или клиентов. gRPC на CloudFront поддерживает следующие комбинации потоковой передачи:
   • односторонняя (без потоковой);
   • передача между клиентом и сервером;
   • передача между сервером и клиентом;
   • двусторонняя передача.

В данный момент это невозможно. CloudFront поддерживает gRPC только через HTTP/2.

По умолчанию доставка контента конечным пользователям по HTTPS происходит с использованием в URL‑адресах доменного имени дистрибутива CloudFront, например https://dxxxxx.cloudfront.net/image.jpg. Если необходимо доставить контент по протоколу HTTPS с использованием собственного доменного имени и собственного сертификата SSL, можно применить одну из возможностей поддержки собственных сертификатов SSL. Подробнее.

Шифрование на уровне поля – это возможность CloudFront, которая позволяет безопасно загружать данные, предоставленные пользователем, например номера кредитных карт, на серверы источника. Используя эту возможность, можно дополнительно зашифровать конфиденциальные данные в форме HTTPS с использованием собственных специальных ключей шифрования для каждого поля, прежде чем запрос PUT/POST будет перенаправлен на источник. Это гарантирует, что конфиденциальные данные могут быть дешифрованы и просмотрены только определенными компонентами или сервисами в стеке приложений. Подробнее о шифровании на уровне поля см. в разделе Шифрование на уровне поля.

Многие интернет‑приложения собирают конфиденциальные данные пользователей, такие как номера кредитных карт, которые затем обрабатываются сервисами приложений, запущенными на инфраструктуре сервера‑источника. Все эти интернет‑приложения используют SSL/TLS‑шифрование между конечным пользователем и CloudFront, а также между CloudFront и источником. На сервере‑источнике можно запустить несколько микросервисов, которые выполняют критические операции на основании вводимых пользователем данных. Однако обычно конфиденциальная информация должна использоваться только небольшой группой этих микросервисов, и это означает, что большинство компонентов могут без всякой надобности получить прямой доступ к этим данным. Простая ошибка программирования, например запись не той переменной, может привести к тому, что номер кредитной карты клиента будет записан в файл.

При шифровании на уровне поля периферийные местоположения CloudFront могут шифровать данные кредитной карты. С этого момента такие конфиденциальные поля могут дешифровать только приложения, которые имеют соответствующие закрытые ключи. В результате сервис выполнения заказов может просматривать только зашифрованные номера кредитных карт, а платежные сервисы могут расшифровывать данные кредитной карты. Это обеспечивает более высокий уровень безопасности, так как даже если один из сервисов приложения допускает утечку зашифрованного текста, данные остаются криптографически защищенными.

Собственный сертификат SSL с выделенным IP‑адресом назначает в каждом периферийном местоположении CloudFront выделенный IP‑адрес для передачи защищенного контента SSL. Поскольку между IP‑адресами и сертификатами SSL существует взаимно‑однозначное соответствие, собственный сертификат SSL с выделенным IP‑адресом работает с браузерами и другими клиентами, не поддерживающими SNI. В соответствии с текущей стоимостью IP‑адресов, стоимость собственного сертификата SSL с выделенным IP‑адресом составляет 600 USD в месяц с пропорциональным почасовым распределением.

Собственный сертификат SSL с использованием SNI основан на SNI‑расширении протокола безопасности транспортного уровня (TLS) и позволяет нескольким доменам передавать SSL‑трафик через один IP‑адрес путем указания имени хостинга, к которому подключается пользователь. Как и при использовании собственных сертификатов SSL с выделенными IP‑адресами, в этом случае CloudFront доставляет контент из каждого периферийного местоположения Amazon CloudFront с таким же уровнем безопасности. Собственный сертификат SSL с SNI работает с последними версиями современных браузеров, включая Chrome версии 6 и новее (при запуске под Windows XP либо OS X 10.5.7 и новее), Safari версии 3 и новее (при запуске под Windows Vista либо Mac OS X 10.5.6 и новее), Firefox 2.0 и новее либо Internet Explorer 7 и новее (при запуске под Windows Vista или более новой ОС). Более старые браузеры не поддерживают SNI и не смогут установить соединение с CloudFront для загрузки контента по HTTPS. Собственный сертификат SSL с индикацией имени сервера не требует дополнительной оплаты, кроме стандартных расценок на запросы и передачу данных через CloudFront.

Server Name Indication (SNI) – это расширение протокола TLS (безопасность транспортного уровня). Оно позволяет связать домен (имя сервера) в запросе SSL с подходящим сертификатом для SSL‑соединения. В результате для нескольких серверов можно использовать один IP‑адрес. SNI требует, чтобы браузер поддерживал добавление имени сервера; эта возможность имеется в большинстве современных браузеров, но отсутствует в ряде устаревших. Подробности см. в разделе о SNI руководства по CloudFront для разработчиков или в статье Википедии, посвященной SNI.

Да, можно получить сертификаты SSL/TLS и связать их с дистрибутивами CloudFront за считаные минуты. Просто создайте сертификат, используя новый сервис AWS Certificate Manager (ACM), затем с помощью пары щелчков мышью выполните его развертывание в базе раздачи CloudFront и позвольте ACM автоматически управлять обновлением сертификата. ACM предоставляет возможности получения и развертывания сертификатов, а также управления ими без дополнительной платы.

При этом CloudFront продолжает поддерживать сертификаты, полученные от сторонних центров сертификации и загруженные в хранилище сертификатов сервиса IAM.

Да, Amazon CloudFront имеет дополнительную функцию поддержки частного контента. Если такая возможность активирована, Amazon CloudFront доставляет файлы только при получении запроса с соответствующей подписью безопасности. Подробнее об этой функции см. в руководстве по CloudFront для разработчиков.

Всем клиентам AWS бесплатно предоставляется сервис AWS Shield стандартный. AWS Shield – это управляемый сервис для защиты от атак типа «распределенный отказ в обслуживании» (DDoS). Сервис защищает интернет-приложения, работающие на AWS. AWS Shield Standard защищает всех клиентов AWS от типичных и частых атак на третий и четвертый уровни инфраструктуры, включая SYN/UDP‑флуд, атаки отражения и прочие, что помогает обеспечить высокую доступность клиентских приложений на AWS.

AWS Shield расширенный – это дополнительный платный сервис, доступный клиентам с Поддержкой бизнеса AWS и Корпоративной поддержкой AWS. AWS Shield расширенный обеспечивает дополнительную защиту от более масштабных и сложных атак, нацеленных на интернет‑приложения на базе сервисов Эластичная балансировка нагрузки (ELB), Amazon CloudFront и Amazon Route 53.

Дистрибутив CloudFront можно интегрировать с брандмауэром интернет‑приложений AWS WAF, который обеспечивает защиту от атак, позволяя задавать различные правила на основе IP‑адресов, заголовков HTTP и собственных строк URI. На основании созданных правил AWS WAF выполняет блокировку, разрешение или отслеживание (подсчет) сетевых запросов, направленных в адрес интернет‑приложения. См. подробности в руководстве разработчика AWS WAF.

CloudFront предлагает два полностью управляемых способа защиты ваших источников.

1. Контроль доступа к источникам (OAC). Контроль доступа к источникам CloudFront (OAC) – это функция безопасности, которая ограничивает доступ к вашим источникам Amazon Simple Storage Service (S3), источникам AWS Elemental и URL-адресам функций Lambda, гарантируя доступ к контенту только CloudFront.
2. Источники VPC. Источники виртуального частного облака CloudFront (VPC) позволяют использовать Amazon CloudFront для доставки контента из приложений, размещенных в частной подсети VPC. Балансировщики нагрузки приложений (ALB), балансировщики сетевой нагрузки (NLB) и инстансы EC2 в частных подсетях можно использовать в качестве источников VPC в CloudFront

Если управляемые решения CloudFront не соответствуют вашим требованиям к вариантам использования, ниже приведены некоторые из доступных альтернативных подходов.

1. Настраиваемые заголовки источников. С помощью CloudFront вы можете добавлять собственные заголовки к входящим запросам, а затем настроить источник для проверки конкретных значений заголовков, фактически ограничивая доступ только к тем запросам, которые маршрутизируются через CloudFront. Этот метод создает дополнительный уровень аутентификации, значительно снижая риск несанкционированного прямого доступа к вашему источнику.
2. Список разрешенных IP-адресов. Вы можете настроить группу безопасности или брандмауэр источника, чтобы разрешить входящий трафик только из диапазонов IP-адресов CloudFront. Для вашего удобства AWS поддерживает и регулярно обновляет эти диапазоны IP-адресов. Для получения подробной информации о внедрении списка разрешенных IP-адресов ознакомьтесь с нашей подробной документацией по адресу: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list. В этом ресурсе содержится пошаговое руководство по использованию управляемых списков префиксов AWS для оптимальной конфигурации безопасности.
3. Шифрование сертификатов SSL/TLS. Вы можете настроить CloudFront на использование исключительно HTTPS-подключений к источнику для обеспечения комплексной защиты данных благодаря зашифрованной связи между вашим дистрибутивом CloudFront и источником.

Источники виртуального частного облака (VPC) CloudFront – это новая функция, которая позволяет применять CloudFront для доставки контента из приложений, размещенных в частной подсети VPC. При использовании источников VPC приложения можно размещать в частной подсети VPC, доступной только через дистрибутив CloudFront. Это отменяет требование о наличии в источнике имени службы доменных имен (DNS), разрешаемого извне. Источники VPC можно настроить с помощью приложений, которые работают на инстансах Балансировщика нагрузки приложений (ALB), Балансировщика сетевой нагрузки (NLB) и инстансов EC2. Источники VPC доступны только в коммерческих регионах AWS. С полным списком поддерживаемых регионов AWS можно ознакомиться здесь.

Если вы хотите повысить безопасность своих веб-приложений при сохранении высокой производительности и глобальной масштабируемости, вам следует использовать источники VPC вместе с CloudFront. Применяя источники VPC, вы можете ограничить доступ к своим источникам в VPC только своим дистрибутивам CloudFront без сложных конфигураций, таких как секретные заголовки или списки управления доступом. Источники VPC также позволяют оптимизировать затраты на IPv4, предоставляя бесплатную маршрутизацию к источникам в частной подсети с внутренними IP-адресами IPv4. Источники VPC идеально подходят, если вы хотите упростить управление безопасностью, что позволяет вам сосредоточиться на развитии основного бизнеса, а не на управлении сложными мерами безопасности.

1. Безопасность. При использовании источников VPC вы можете повысить уровень безопасности приложения, размещая балансировщики нагрузки и инстансов EC2 в частных подсетях, превратив CloudFront в единственную точку входа. Запросы пользователей передаются из CloudFront в источники VPC по частному безопасному соединению, что обеспечивает дополнительную безопасность ваших приложений.
2. Управление. Источники VPC сокращают эксплуатационные издержки, необходимые для безопасного подключения источника CloudFront, позволяя перемещать источники в частные подсети без публичного доступа и необходимости внедрения списков контроля доступа, общих секретных заголовков или других механизмов ограничения доступа к источникам. Это упрощает защиту их веб-приложений с помощью CloudFront без необходимости вкладывать средства в недифференцированную разработку.
3. Масштабируемость и производительность. Благодаря источникам VPC клиенты могут использовать периферийные местоположения CloudFront по всему миру и магистральные сети AWS, обеспечивая такие же масштабы и производительность, как и другие существующие методы доставки контента, и при этом улучшая безопасность. Решение упрощает управление безопасностью и доставку приложений клиентам по всему миру, делая использование CloudFront более легким в качестве единого входа для ваших приложений.

Источники виртуального частного облака (VPC) CloudFront позволяют использовать CloudFront для доставки контента из приложений, размещенных в частной подсети VPC, с помощью Балансировщиков нагрузки приложений и Балансировщиков сетевой нагрузки, а также инстансов EC2. Блокирование публичного доступа Amazon VPC (VPC BPA) – это простой декларативный элемент управления, который официально блокирует входящий и исходящий трафик VPC по предоставленным AWS интернет-путям. Когда решение Блокирования публичного доступа VPC BPA включено в подсети с источником VPC, активные подключения CloudFront к этой подсети прерываются. Новые подключения к подсети не отправляются либо направляются в другую подсеть, где находится источник VPC, а BPA не включен, либо отключаются, если во всех подсетях, где находится источник VPC, включен BPA.

Источники VPC поддерживают Балансировщики нагрузки приложений и Балансировщики сетевой нагрузки, а также инстансы EC2.

Нет, IPv6 не поддерживается частными источниками VPC. При использовании источников VPC вам нужны частные адреса IPv4, которые являются бесплатными и не взимают сборов за использование IPv4.

Да, Amazon CloudFront можно настроить на добавление собственных заголовков к запросам, перенаправляемым к источнику, или замену значений существующих заголовков этих запросов. Заголовки также помогают подтвердить, что запросы, направленные к источнику, были отправлены из CloudFront. Можно настроить источник так, чтобы он принимал только запросы с указанными собственными заголовками. Кроме того, если используется несколько баз раздачи CloudFront с одним источником, можно использовать собственные заголовки для обозначения запросов, отправленных различными базами раздачи к источнику. Наконец, собственные заголовки можно использовать для определения правильных заголовков CORS, возвращаемых для запросов. Собственные заголовки можно настроить через API CloudFront или Консоль управления AWS. Дополнительная плата за эту возможность не взимается. Подробнее о том, как настраивать собственные заголовки, см. здесь.

Amazon CloudFront поддерживает доставку динамического контента, индивидуально настраиваемого с помощью значений HTTP cookie. Для использования этой возможности необходимо настроить перенаправление сервисом Amazon CloudFront всех или некоторых значений cookie на пользовательский сервер источника. В дальнейшем Amazon CloudFront учитывает перенаправленные значения cookie при нахождении уникального объекта в своем кэше. В результате конечные пользователи могут одновременно воспользоваться преимуществами индивидуальной настройки контента с помощью cookie и высокой производительностью, которую обеспечивает сервис Amazon CloudFront. Можно дополнительно указать, требуется ли записывать значения cookie в журналы доступа Amazon CloudFront.

Строка запроса может быть дополнительно настроена как часть ключа кэширования для идентификации объектов в кэше Amazon CloudFront. Это позволяет создавать динамические веб‑страницы (например, результаты поиска) с использованием определенного времени кэширования на периферийных серверах.

Да. Функция создания белых списков строк запроса позволяет без труда настроить Amazon CloudFront для использования в ключе кэширования только определенных параметров. При этом источнику будут по‑прежнему пересылаться все параметры.

Да. Amazon CloudFront можно настроить на включение в белый список до 10 параметров запроса.

Amazon CloudFront поддерживает параметры запроса в формате URI, как это определено в разделе 3.4 стандарта RFC3986. Это подразумевает поддержку параметров запроса, включенных в строку HTTP GET после знака «?» и разделенных символом «&».

Да, CloudFront может автоматически сжимать текст и бинарные данные. Чтобы использовать эту возможность, укажите в настройках режима кэширования автоматическое сжатие объектов с помощью CloudFront и убедитесь, что ваш клиент добавляет условие Accept‑Encoding: gzip в заголовок запроса (в последних версиях большинства браузеров это настроено по умолчанию). Дополнительную информацию об этой функции см. в руководстве для разработчиков.

В общем смысле потоковая передача означает доставку конечным пользователям аудио‑ и видеоматериалов для воспроизведения без необходимости предварительно загружать медиафайлы из Интернета. В число протоколов, используемых для потоковой передачи, входят несколько вариантов доставки посредством HTTP, например Apple HTTP Live Streaming (HLS), MPEG Dynamic Adaptive Streaming over HTTP (MPEG‑DASH), Adobe HTTP Dynamic Streaming (HDS) и Microsoft Smooth Streaming. Такие протоколы отличаются от протоколов доставки веб‑страниц и другого онлайн‑контента, поскольку доставляют мультимедийный контент в режиме реального времени: данные воспроизводятся на устройствах конечных пользователей по мере доставки. Потоковая передача имеет ряд потенциальных преимуществ как для поставщика контента, так и для конечных пользователей.

• Она является более удобной с точки зрения управления просмотром. Например, при потоковой передаче зрителю проще заглянуть вперед или назад, чем при обычной загрузке видео.
• Потоковая передача предоставляет больше контроля над контентом, поскольку после завершения просмотра файлы не остаются на стороне клиента или на локальном диске пользователя.
• Потоковая передача может уменьшить издержки, поскольку доставляется только та часть медиафайла, которую зритель просматривает. При традиционной загрузке, напротив, зрителям чаще всего доставляется весь мультимедийный файл, даже если они просматривают только его часть.

Да, Amazon CloudFront предоставляет несколько возможностей доставки видео по требованию. Если имеются медиафайлы, которые перед сохранением в Amazon S3 (или на пользовательском сервере источника) были преобразованы в HLS, MPEG‑DASH или Microsoft Smooth Streaming, например, с помощью AWS Elemental MediaConvert, можно использовать дистрибутив веб‑контента Amazon CloudFront для потоковой передачи в этом формате без необходимости запуска каких‑либо мультимедийных серверов.

Альтернативный вариант – запустить на Amazon EC2 сторонний потоковый сервер (например, Wowza Media Server, доступный на AWS Marketplace), который может выполнять преобразование медиафайлов в формат, требуемый для потоковой передачи по HTTP. Такой сервер можно назначить в качестве источника для дистрибутива веб‑контента Amazon CloudFront.

Подробнее см. на странице Видео по требованию (VOD) на AWS.

Да. Возможности потокового вещания Amazon CloudFront можно использовать с любым сервисом подготовки видеотрансляций, который дает на выходе видеопотоки на базе HTTP, например AWS Elemental MediaPackage или AWS Elemental MediaStore. MediaPackage – это сервис подготовки и своевременного сжатия видео, который позволяет поставщикам видеоконтента безопасно и надежно доставлять потоковое видео в нужном масштабе с использованием различных стандартов доставки и защиты контента. MediaStore – это работающий по HTTP сервис подготовки и хранения видео, который обеспечивает необходимую для прямых трансляций высокую производительность, мгновенную непротиворечивость и предсказуемую низкую задержку в сочетании с безопасностью и надежностью хранилища Amazon.

Подробнее см. страницу о прямых видеотрансляциях на AWS.

Отказоустойчивость с учетом требований к качеству мультимедиа (MQAR) — это встроенная функция Amazon CloudFront и мультимедийных сервисов AWS, которая обеспечивает автоматический выбор источника и экстренное переключение между регионами в зависимости от динамически генерируемой оценки качества видео. С помощью MQAR можно развернуть резервный рабочий процесс медиасервисов AWS в двух разных регионах AWS для надежной доставки данных о событиях в реальном времени. При включении в системе функции MQAR вы разрешаете CloudFront автоматически выбирать источник с наивысшим показателем качества. Показатель качества отражает предполагаемые проблемы с качеством потокового мультимедиа в ваших источниках, такие как пустые, замороженные, пропущенные или повторяющиеся кадры. Например, если источники AWS Elemental MediaPackage v2 развернуты в двух разных регионах AWS, и в одном из них показатель качества мультимедиа выше, чем в другом, CloudFront автоматически переключится на источник с более высоким показателем. Эта функция обеспечивает непрерывный мониторинг для трансляции событий в прямом эфире и каналов с круглосуточными программами и призвана обеспечить зрителям высокое качество оказываемых услуг. Более подробные сведения о MQAR можно найти в Руководстве для разработчиков CloudFront.

Origin Shield – это централизованный слой кэширования, помогающий увеличить коэффициент попадания в кэш для снижения нагрузки на источник. Origin Shield также снижает стоимость эксплуатации источника, объединяя запросы по всем регионам, в результате чего к источнику поступает всего один запрос на каждый объект. После активации этой возможности CloudFront направляет все запросы к источнику через Origin Shield и обращается к источнику лишь в том случае, если контент еще не сохранен в кэше Origin Shield.

Origin Shield идеально подходит для рабочих нагрузок, при которых аудитория распределена по разным географическим регионам или в которых используется своевременное сжатие видео при потоковой передаче, динамическая обработка изображений или аналогичные процессы. Использование Origin Shield перед источником снижает количество избыточных обращений к нему, проверяя сначала центральный кэш и выполняя запрос к источнику по консолидированным запросам только для контента, которого еще нет в кэше Origin Shield. Аналогичным образом Origin Shield можно применять в архитектуре с несколькими CDN, чтобы уменьшать количество дублирующих вызовов источника в сетях CDN за счет использования Amazon CloudFront как источника для остальных CDN. Подробнее об этих и других примерах использования Origin Shield см. в руководстве по Amazon CloudFront для разработчиков.

Amazon CloudFront предлагает Origin Shield в регионах AWS, где есть периферийные серверы кэширования в регионах. При включении Origin Shield для него следует выбрать регион AWS с наименьшей задержкой для используемого источника. Origin Shield можно использовать как с источниками, расположенными в пределах региона AWS, так и с источниками вне AWS. Дополнительную информацию см. в разделе Выбор региона AWS для Origin Shield в руководстве по Amazon CloudFront для разработчиков.

Да. Все регионы Origin Shield используют архитектуру высокой доступности, которая охватывает несколько зон доступности с группами автоматически масштабируемых инстансов Amazon EC2. При подключении к Origin Shield из местоположений CloudFront также активно отслеживаются ошибки для каждого запроса, чтобы в случае недоступности основного местоположения Origin Shield автоматически направлять запрос во вторичное местоположение.

Статические IP-адреса передачи по произвольному пути от Amazon CloudFront – это набор статических IP-адресов, которые позволяют подключаться ко всем периферийным местоположениям CloudFront по всему миру. Они предоставляют небольшой статический список IP-адресов, который можно использовать в таких случаях, как выставление счетов с нулевой ставкой, когда сетевые провайдеры отменяют плату за передачу данных по определенным IP-адресам при наличии соответствующих соглашений, а также в списках разрешений на стороне клиента для повышения уровня безопасности. Используя статические IP-адреса передачи по произвольному пути, вы избавляетесь от эксплуатационных проблем, связанных с постоянным обновлением списков разрешений или сопоставлений IP-адресов, поскольку один и тот же набор IP-адресов работает во всей глобальной сети CloudFront и при этом использует все функции CloudFront.

Чтобы включить статические IP-адреса передачи по произвольному пути, сначала запросите их список и создайте его в своем аккаунте AWS. После создания списка вы можете связать свои дистрибутивы CloudFront со списком статических IP-адресов передачи по произвольному пути. Это можно сделать либо в разделе статических IP-адресов, которые передаются по произвольному пути, в консоли AWS, либо с помощью редактирования каждого дистрибутива и выбора нужного списка статических IP-адресов передачи по произвольному пути в раскрывающемся меню. После сохранения этих изменений определенный набор статических IP-адресов, связанных с вашими дистрибутивами, будет доступен для копирования или загрузки из списка, отображаемого в консоли AWS, либо через API

При включении статических IP-адресов передачи по произвольному пути CloudFront вы получите 21 IP-адрес для IPv4. Вам нужно будет добавить все эти IP-адреса в любые соответствующие списки разрешений.

Нет, передача по произвольному пути CloudFront будет доступна только для IP-адресов, распределенных по географическим регионам.

По мере добавления CloudFront новых периферийных местоположений ваш список статических IP-адресов передачи по произвольному пути останется действительным. При необходимости мы сообщим ваши IP-адреса из новых периферийных местоположений.

Все функции CloudFront работают с передачей по произвольному пути с тремя заметными исключениями: 1) статические IP-адреса передачи по произвольному пути не будут поддерживать устаревшие клиенты, которые не поддерживают SNI; 2) при использовании статических IP-адресов передачи по произвольному пути необходимо применять ценовую категорию «Все»; и 3) при использовании статических IP-адресов передачи по произвольному пути необходимо отключить IPv6. Статические IP-адреса передачи по произвольному пути работают на этапе разрешения DNS, и как только запрос поступит на хост, все существующие функции и интеграции с другими сервисами AWS будут по-прежнему доступны вашим дистрибутивам.

Вы можете использовать статистические IP-адреса передачи по произвольному пути с несколькими дистрибутивами, но они должны находиться в одном аккаунте. Статические IP-адреса передачи по произвольному пути CloudFront можно связать между несколькими дистрибутивами в аккаунте. Статический IP-адрес передачи по произвольному пути CloudFront будет поддерживать индикацию имени сервера (SNI), поэтому из любого количества дистрибутивов, связанных с политикой статического IP-адреса, который передается по произвольному пути, будет возвращен правильный сертификат. Если вы хотите иметь разные статические IP-адреса для нескольких дистрибутивов в своем аккаунте, то можете создать дополнительный список статических IP-адресов передачи по произвольному пути и связать его с определенными дистрибутивами.

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

Да. Заполните форму запроса на повышение лимитов здесь, и в течение двух рабочих дней мы предоставим вашему аккаунту дополнительные ресурсы.

Чтобы узнать текущее ограничение на количество дистрибутивов, которые можно создать для каждого аккаунта AWS, см. раздел Лимиты Amazon CloudFront в общих справочных материалах по Amazon Web Services. Чтобы повысить лимит, заполните форму запроса на повышение лимитов CloudFront.

Максимальный размер одного файла, доставляемого с помощью Amazon CloudFront, составляет 30 ГБ. Этот лимит действует для всех дистрибутивов Amazon CloudFront.

1. Стандартные журналы (журналы доступа). Стандартные журналы CloudFront содержат подробные записи о каждом запросе, направленном в дистрибутив. Они полезны для многих сценариев, включая аудит безопасности и доступа.
2. Журналы в режиме реального времени. Журналы в режиме реального времени CloudFront мгновенно предоставляют информацию о запросах, отправленных для распределения (записи журналов доставляются в течение нескольких секунд после получения запросов). Вы можете выбрать частоту дискретизации журналов в режиме реального времени, то есть процент запросов, для которых в журнал добавляются записи.
3. Ведение журналов периферийных функций. Журналы Amazon CloudWatch можно использовать для получения журналов периферийных функций, таких как Lambda@Edge и CloudFront. Доступ к журналам можно получить с помощью консоли CloudWatch или API Журналов CloudWatch. Дополнительные сведения см. в разделе Журналы периферийных функций.
4. Ведение журнала активности в сервисе. AWS CloudTrail можно использовать для регистрации активности сервиса CloudFront (активности API) в своем аккаунте AWS. CloudTrail предоставляет запись действий API, предпринятых пользователем, ролью или сервисом AWS в CloudFront. Используя информацию, собранную CloudTrail, вы можете определить, какой запрос API был отправлен в CloudFront, IP-адрес, с которого был сделан запрос, кто и когда его отправил, а также дополнительные сведения. Подробнее см. в разделе Ведение журнала вызовов API Amazon CloudFront с помощью AWS CloudTrail.

• Стандартные журналы CloudFront доставляются в выбранную вами корзину Amazon S3, Журналы Amazon CloudWatch и Amazon Data Firehose. Дополнительные сведения см. в разделе Использование стандартных журналов (журналов доступа).
• Журналы CloudFront доставляются в выбранный вами Поток данных Amazon Kinesis в режиме реального времени. За использование журналов CloudFront в реальном времени взимается плата дополнительно к стоимости использования потоков данных Kinesis. Дополнительные сведения см. в разделе Использование журналов в режиме реального времени.
• Журналы периферийных функций CloudFront (Lambda@Edge и CloudFront) доставляются в Журналы Amazon CloudWatch

Стандартные журналы доступа CloudFront можно доставлять в Amazon S3, Amazon CloudWatch и Amazon Data Firehose. Вы можете выбрать формат выходного журнала (plain, w3c, JSON, csv и parquet). А также – какие поля хотите регистрировать и в каком порядке они должны быть включены в журналы. Для журналов, доставляемых в S3, можно также включить секционирование, т. е. настроить автоматическое их разбиение на почасовой или ежедневной основе. Кроме того, вы можете доставлять журналы стандартного доступа в корзины S3 в регионах AWS, которые необходимо предварительно включить (Opt-in). Дополнительные сведения см. в разделе Журналы стандартного доступа руководства для разработчиков CloudFront.

CloudFront не взимает плату за включение стандартных журналов, но вы оплачиваете доставку, хранение и доступ к журналам в зависимости от места их назначения. Подробную информацию см. в разделе «Дополнительные функции» на странице цен CloudFront.

Да. Amazon CloudFront предлагает различные решения для создания отчетов, например для получения подробных сведений по статистике кэша, отслеживания использования CloudFront или определения, откуда пользователи просматривают контент, а также для настройки предупреждений в режиме реального времени на основании рабочих метрик. Доступ ко всем возможностям создания отчетов предоставляется в панели управления Amazon CloudFront «Reporting & Analytics», доступной в Консоли управления AWS. Подробнее о возможностях создания отчетов см. на странице отчетов и аналитики Amazon CloudFront.

Да. Amazon CloudFront поддерживает теги для распределения расходов. Теги упрощают распределение расходов и оптимизацию затрат путем классификации и группировки ресурсов AWS. Например, можно использовать теги, чтобы сгруппировать ресурсы по администратору, по имени приложения, по центру затрат или по конкретному проекту. Подробную информацию о тегах для распределения расходов см. на странице Использование тегов для распределения расходов. Чтобы при желании добавить теги для своих дистрибутивов CloudFront, см. страницу «Добавление тегов в Amazon CloudFront».

Да. Для сохранения истории всех вызовов API Amazon CloudFront своего аккаунта включите сервис AWS CloudTrail в соответствующем разделе Консоли управления AWS. Дополнительные сведения см. на главной странице AWS CloudTrail.

Осуществлять мониторинг, отправлять предупреждения и получать оповещения о текущей производительности дистрибутивов Amazon CloudFront уже через несколько минут после запроса пользователя можно с помощью сервиса Amazon CloudWatch. CloudFront автоматически публикует в Amazon CloudWatch шесть рабочих метрик, каждая из которых имеет детализацию в 1 минуту. С помощью CloudWatch можно установить предупреждения для любых нетипичных параметров трафика в CloudFront. Для начала работы по отслеживанию активности CloudFront и установки предупреждений в CloudWatch см. пошаговые инструкции в руководстве по Amazon CloudFront для разработчиков или просто перейдите в Консоль управления Amazon CloudFront и выберите «Мониторинг и предупреждения» на навигационной панели.

Вы можете выбрать место назначения в зависимости от вашего варианта использования сервиса. Если вам требуется получать доступ к данным журнала вашего решения в течение нескольких секунд, выберите журналы данных, которые доступны в режиме реального времени. Если нужно удешевить конвейер журналов реального времени, можно использовать фильтрацию данных журнала, включив журналы только для определенных режимов кэширования или выбрав более низкую частоту дискретизации. Конвейер журнала в реальном времени создан для быстрой доставки данных. Следовательно, в случае задержки данных записи журнала могут быть удалены. С другой стороны, если вам нужно недорогое решение для обработки журнала, не требующее обмена данными в режиме реального времени, то текущий стандартный вариант журнала вам подойдет идеально. Стандартные журналы в S3 созданы для обеспечения полноты записей и обычно доступны в течение нескольких минут. Эти журналы можно включить для всей базы раздачи, а не для определенных режимов кэширования. Следовательно, если вам нужны журналы для специального исследования, аудита и анализа, вы можете включить только стандартные журналы в S3. При необходимости можно сочетать оба типа журналов. Используйте отфильтрованный список журналов в реальном времени для операционной наглядности, а затем используйте стандартные журналы для аудита.
 

Стандартные журналы CloudFront доставляются в вашу корзину S3. Также можно использовать интеграционную сборку сторонних решений, например DataDog и Sumologic, для создания информационных панелей из этих журналов.

Журналы в реальном времени записываются в вашем сервисе Kinesis Data Streams. Из потоков данных Kinesis журналы можно опубликовать в Amazon Kinesis Data Firehose. Amazon Kinesis Data Firehose поддерживает простую доставку данных в Amazon S3, Amazon Redshift, Сервис Amazon OpenSearch, а также таким поставщикам сервисов, как Datadog, New Relic и Splunk. Kinesis Firehose также поддерживает доставку данных на обычный адрес HTTP.

Чтобы узнать необходимое число сегментов, выполните следующие действия:

1. Рассчитайте (или примерно оцените) количество запросов в секунду, которые получает ваша база раздачи CloudFront. Для расчета количества запросов в секунду можно использовать отчеты об использовании CloudFront или метрики CloudFront.
2. Определите типичный размер одной записи журнала в реальном времени. Размер типичной записи, включающей все доступные поля, составляет около 1 КБ. Если вы не знаете размер записи вашего журнала, то можете включить журналы в реальном времени с низкой частотой дискретизации (например, 1 %), а затем рассчитать средний размер записи, используя данные мониторинга в Kinesis Data Streams (общее количество записей деленное на общее количество входящих байтов).
3. Умножьте количество запросов в секунду (шаг 1) на размер типичной записи журнала в реальном времени (шаг 2) и определите объем данных в секунду, который ваша конфигурация журнала в реальном времени может отправить в Kinesis Data Stream.
4. С помощью полученного значения объема данных в секунду, вычислите необходимое количество сегментов. Один сегмент может обрабатывать не более 1 МБ в секунду и не более 1000 запросов (записей журнала) в секунду. Рекомендуется при расчете количества необходимых сегментов добавить до 25 % в качестве буфера.

Предположим, что ваша база раздачи получает 10 000 запросов в секунду, а размер ваших записей журнала в реальном времени обычно составляет 1 КБ. Это означает, что ваша конфигурация журнала в реальном времени может генерировать 10 000 000 байт (10 000, умноженные на 1000), или 9,53 МБ в секунду. В этом случае вам понадобится всего 10 сегментов Kinesis. Однако, чтобы иметь некий буфер, желательно создать как минимум 12 сегментов.

Функции CloudFront – это функция бессерверных периферийных вычислений, которая позволяет запускать код JavaScript в периферийных местоположениях CloudFront для упрощенных преобразований и манипуляций с применением HTTP(s). С этим сервисом клиенты получают гибкость, производительность и безопасность полноценной среды программирования для работы с современными веб-приложениями. За небольшую часть стоимости AWS Lambda@Edge клиенты могут мгновенно выполнять масштабирование для поддержки миллионов запросов в секунду.

Функции CloudFront встроены в CloudFront, поэтому клиенты могут легко создавать, тестировать и развертывать функции в рамках одного сервиса. Можно также использовать хранилище «ключ-значение» CloudFront с функциями CloudFront для хранения и извлечения данных поиска в дополнение к функциональной логике. Наш репозиторий GitHub облегчает разработчикам начало работы, предлагая большую коллекцию примеров кода, которые можно использовать в качестве отправной точки для создания функций. Для создания функций можно использовать интегрированную среду разработки консоли CloudFront или прикладной программный интерфейс / интерфейс командной строки CloudFront. Можно проверить правильность готового кода, протестировав функцию в производственном дистрибутиве CloudFront. Так вы убедитесь, что функция будет работать надлежащим образом после развертывания. Консоль оснащена визуальным редактором для быстрого создания тестовых событий и проверки функций. С помощью дистрибутива CloudFront код развертывается в глобальной сети периферийных местоположений AWS с распределенными параметрами для выполнения запросов CloudFront.

CloudFront Functions идеально подходит для выполнения краткосрочных упрощенных функций, приведенных ниже:

• Нормализация ключа кэширования: пользователь может преобразовывать атрибуты HTTP-запросов (заголовки, строки запроса, файлы cookie, относительный путь запроса URL-адреса) с целью создания оптимального ключа кэша для увеличения коэффициента попадания в кэш.
• Управление заголовками: пользователь может вставлять, изменять или удалять заголовки HTTP в запросе и ответе. Например, можно добавить в каждый ответ заголовки строгой безопасность передачи информации по протоколу HTTP (HSTS) или совместного использования ресурсов между разными источниками (CORS).
• Перенаправление или перезапись URL-адресов: пользователь может перенаправить посетителей на другие страницы на основе данных запроса либо изменить путь для запроса.
• Авторизация запросов: пользователь может подтвердить валидность токенов авторизации, таких как веб-токены JSON (JWT), проверив аутентификационные заголовки или другие метаданные запроса.

CloudFront KeyValueStore – это глобальное полностью управляемое хранилище данных типа «ключ-значение» с малой задержкой. Хранилище «ключ-значение» позволяет извлекать данные типа «ключ-значение» из функций CloudFront, делая функции более настраиваемыми за счет независимого обновления данных. Данные типа «ключ-значение» доступны во всех периферийных местоположениях CloudFront, что обеспечивает высокоэффективное хранилище «ключ-значение» в памяти, позволяющее быстро считывать данные из функций CloudFront.

CloudFront KeyValueStore идеально подходит для частых операций чтения в периферийных местоположениях и нечастых обновлений, таких как:

• Поддержка перезаписи и перенаправления URL-адресов: перенаправление пользователей на сайт определенной страны в зависимости от географического местоположения. Хранение и обновление этих URL-адресов на основе геоданных в KeyValueStore упрощает управление URL-адресами.
• A/B-тестирование и флаги функций: проводите эксперименты, направляя определенный процент трафика на версию вашего веб-сайта. Экспериментальные весовые коэффициенты можно обновлять без обновления функционального кода или дистрибутива CloudFront.
• Авторизация доступа: реализуйте контроль и авторизацию доступа для контента, доставляемого через CloudFront, путем создания и проверки пользовательских токенов, таких как токены HMAC или веб-токены JSON (JWT), для разрешения или отклонения запросов. 

Нет. CloudFront Functions дополняет Lambda@Edge. Пользователь получает необходимые инструменты в результате комбинирования функциональных возможностей Lambda@Edge и CloudFront Functions. В рамках одного режима кэширования для разных триггеров событий дистрибутивов CloudFront можно использовать как CloudFront Functions, так и Lambda@Edge. Например, для управления файлами манифеста потоковой передачи «на лету» и внедрения пользовательских токенов с целью защиты потоковой передачи в реальном времени можно использовать Lambda@Edge. Функции CloudFront выполняют проверку валидности таких токенов, когда пользователь запрашивает сегмент манифеста.

В случае с комбинацией функций CloudFront и Lambda@Edge пользователь может выбирать один из двух гибких и безопасных вариантов запуска кода в полнофункциональном режиме в ответ на события CloudFront. Выполнение кода в ответ на события CloudFront не требует управления инфраструктурой. CloudFront Functions специально разработана для упрощенных, высокомасштабируемых преобразований и манипуляций запросов / ответов, чувствительных к задержкам. Lambda@Edge использует стандартные среды выполнения кода, поддерживающие широкий спектр вычислительных потребностей и настроек. Lambda@Edge лучше всего подходит для операций с высокими вычислительными нагрузками. К таким операциям относятся вычисления, которые занимают больше времени (от нескольких миллисекунд до секунд), зависят от внешних сторонних библиотек, требуют интеграции с другими сервисами AWS (например, S3, DynamoDB) либо сетевых вызовов для обработки данных. Некоторые популярные примеры усложненного использования Lambda@Edge включают манипуляции с файлами манифеста потоковой передачи HLS, интеграцию со сторонними службами авторизации и обнаружения ботов, рендеринг на стороне сервера одностраничных приложений на периферии и т. д. Дополнительную информацию см. на странице примеров использования Lambda@Edge.

Функции CloudFront обеспечивают ожидаемую производительность, масштабируемость и экономическую эффективность с помощью уникальной модели механизма защиты, которая предполагает полную изоляцию кода Функций. В случае запуска пользовательского кода в многопользовательской вычислительной среде необходимо обеспечить надежную защиту среды выполнения. Злоумышленник может попытаться использовать дефекты программного кода в среде выполнения, библиотеках или ЦП, чтобы спровоцировать утечку конфиденциальных данных с сервера или других функций клиента. Если код функции не будет надежно изолирован, такие попытки могут увенчаться успехом. В AWS Lambda и AWS Lambda@Edge для изоляции с целью обеспечения безопасности используется виртуальная машина Firecracker. С помощью Функций CloudFront мы разработали модель изоляции на основе процессов, которая обеспечивает такой же уровень безопасности против атак по сторонним каналам, таких как Spectre и Meltdown, согласованных по времени атак и других уязвимостей кода. CloudFront Functions не может получить доступ к данным других клиентов либо изменить их: запуск функций происходит в виде целевого процесса в специализированном ЦП. Для выполнения задания определенного клиента CloudFront Functions использует отдельные выполнимые модули, и все данные, связанные с этим клиентом, очищаются (сбрасываются) между выполнениями.

CloudFront Functions не использует V8 в качестве движка JavaScript. Модель механизма защиты Функций является иной и считается более безопасной, чем модель v8 с применением изоляции, которую предлагают другие поставщики.

Вы можете проверить работу любой функции с помощью встроенного тестирования. При тестировании дистрибутив CloudFront запустит код, чтобы убедиться, что функция возвращает ожидаемый результат. Помимо проверки выполнения кода, пользователь также узнает коэффициент использования вычислений. Этот коэффициент показывает, насколько ваша функция близка к пределу времени выполнения. Например, коэффициент использования вычислений 30 означает, что ваша функция использует 30 % общего допустимого времени выполнения. Для создания объектов тестирования можно использовать визуальный редактор, с помощью которого можно легко добавлять строки запроса, заголовки, URL-адреса и методы HTTP для каждого объекта, либо JSON-представление запросов и ответов. После запуска тестирования результаты и коэффициент использования вычислений можно увидеть либо в том же визуальном редакторе, либо путем просмотра ответа в формате JSON. Если функция выполняется успешно и коэффициент использования вычислений не приближается к 100, пользователь знает, что функция будет работать с дистрибутивом CloudFront.

Отслеживать использование и производительность Функций CloudFront можно по метрикам и журналу выполнения. Метрики генерируются для каждого вызова функции. На консоли CloudFront или CloudWatch можно просматривать метрики для каждой функции. Доступные метрики: количество вызовов, использование вычислений, ошибки проверки и ошибки выполнения. В случае ошибки проверки или выполнения, сообщение об ошибке также отобразится в журналах доступа к CloudFront, что позволит вам понять, как функция влияет на трафик CloudFront. Помимо метрик также можно создавать журналы выполнения, включив оператор console.log () в код функции. Согласно каждой записи регистрации создается запись в журнале CloudWatch, которая затем отправляется в CloudWatch. Журналы и метрики включены в стоимость Функций CloudFront. 

Lambda@Edge – это расширение AWS Lambda для запуска кода в глобальных периферийных местоположениях без выделения серверов и управления ими. Lambda@Edge предлагает инструменты для выполнения высокопроизводительных и гибких вычислений для сложных функций и полную логику приложения, понятную вашим пользователям. Функции Lambda @ Edge выполняются в среде Node.js или Python. После публикации функции в определенном регионе AWS и ее дальнейшего связывания с дистрибутивом CloudFront, Lambda@Edge автоматически дублирует ваш код в других регионах по всему миру. Lambda автоматически масштабируется в зависимости от нагрузки, изменяя свою результативность от нескольких запросов в день до тысяч запросов в секунду.

Функции Lambda@Edge выполняются путем связывания с определенным режимом кэширования в CloudFront. Вы также можете указать, в какой момент во время обработки запроса или ответа CloudFront функция должна выполняться (т. е. при получении запроса от зрителя, когда запрос пересылается источнику либо возвращается от источника либо непосредственно перед ответом конечному зрителю). Для написания кода следует использовать Node.js или Python в консоли Lambda, API либо базовые средства разработки, такие как приложение бессерверной обработки данных (SAM). После тестирования функции ее следует связать с выбранным режимом кэширования CloudFront и триггером события. Когда настройки будут сохранены, следующий запрос соответствующего уровня к дистрибутиву CloudFront активирует выполнение функции в периферийном местоположении CloudFront, а также, при необходимости, масштабирование ресурсов. Подробнее см. в нашей документации.

Функции Lambda@Edge могут быть автоматически запущены в ответ на следующие события Amazon CloudFront:

• Запрос пользователя. Это событие возникает, когда конечный пользователь или устройство в Интернете отправляет в CloudFront запрос HTTP(S), который поступает в ближайшее к пользователю периферийное местоположение.
• Ответ пользователю. Это событие возникает, когда сервер CloudFront в периферийном местоположении готов ответить конечному пользователю или устройству, сделавшему запрос.
• Запрос источника. Это событие возникает, когда в кэше периферийного сервера CloudFront отсутствует запрошенный объект и запрос посетителя перенаправляется на веб‑сервер источника (например, Amazon EC2, Балансировщик нагрузки приложений или Amazon S3).
• Ответ источника. Это событие возникает, когда сервер CloudFront в периферийном местоположении получает ответ от веб‑сервера источника.

Непрерывное развертывание на CloudFront обеспечивает возможность тестирования и проверки изменений конфигурации с помощью части живого трафика перед развертыванием изменений для всех зрителей.

Непрерывное развертывание с помощью CloudFront обеспечивает высокий уровень безопасности. Теперь вы можете развернуть две отдельные, но при этом абсолютно идентичные среды – синюю и зеленую, а также обеспечить простую интеграцию в конвейеры непрерывной интеграции и доставки (CI/CD) с возможностью постепенного развертывания ресурсов без каких-либо изменений в системе доменных имен (DNS). Это обеспечивает согласованность при просмотре благодаря привязке сеанса пользователя к одной среде. Кроме того, вы можете оценить эффективность внесенных изменений, отслеживая стандартные журналы и журналы в реальном времени, а также быстро вернуться к предыдущей конфигурации, если такие изменения отрицательно повлияют на работу системы. 

Вы можете настроить непрерывное развертывание, связав временное распределение с основным распределением с помощью консоли CloudFront, SDK, интерфейса командной строки (CLI) или шаблона CloudFormation. Затем вы можете определить правила для разделения трафика, настроив заголовок клиента или набрав определенный процент трафика для тестирования с помощью временного распределения. После настройки вы можете обновить временную конфигурацию, внеся в нее необходимые изменения. CloudFront будет управлять распределением трафика между пользователями и предоставлять соответствующую аналитику, чтобы помочь вам решить, продолжать ли развертывание или откатиться назад. После того как тестирование с использованием промежуточных дистрибутивов будет завершено, можно объединить изменения с основным дистрибутивом.

Подробнее о функции см. в документации.

Непрерывное развертывание позволяет осуществлять мониторинг реальных пользователей с помощью реального веб-трафика. Вы можете использовать любой из существующих методов мониторинга – консоль CloudFront, API CloudFront, CLI или CloudWatch – для индивидуального измерения операционных показателей основного и промежуточного распределения. Вы можете измерить критерии успеха вашего конкретного приложения, измеряя и сравнивая показатели пропускной способности, задержки и доступности между двумя дистрибутивами.

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

При непрерывном развертывании вы можете связать различные функции с основным и промежуточным дистрибутивами. Вы также можете использовать одну и ту же функцию для обоих распределений. Если вы обновляете функцию, которая используется обоими дистрибутивами, они оба получают обновление.

Каждый ресурс в вашем стеке CloudFormation сопоставляется с определенным ресурсом AWS. Промежуточный дистрибутив будет иметь свой собственный идентификатор ресурса и работать как любой другой ресурс AWS. Вы можете использовать CloudFormation для создания или обновления этого ресурса.

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

Функция непрерывного развертывания доступна во всех периферийных местоположениях CloudFront без дополнительной платы.

Каждый сервер и устройство, подключенное к Интернету, имеют определенный числовой адрес протокола сети интернет (IP). Интернет развивается, количество пользователей растет, и появляется необходимость в новых IP‑адресах. IPv6 – это новая версия протокола сети Интернет, в которой используется большее пространство адресов по сравнению с ее предшественником, IPv4. В IPv4 длина каждого IP‑адреса составляла 32 бита; этого хватало для существования 4,3 миллиарда уникальных адресов. Пример адреса IPv4: 192.0.2.1. В IPv6 длина IP‑адреса составляет 128 бит, и этого достаточно для существования более чем 340 ундециллионов (10Е36) уникальных адресов. Пример адреса IPv6: 2001:0db8:85a3:0:0:8a2e:0370:7334

Amazon CloudFront поддерживает использование протокола IPv6. Приложения могут подключаться к периферийным местоположениям Amazon CloudFront без необходимости использования программного обеспечения или систем для преобразования адресов IPv4 в адреса IPv6. Это позволяет соблюдать государственные требования по переходу на IPv6, включая требования федерального правительства США, а также пользоваться расширяемостью, простотой управления сетью и дополнительными встроенными функциями поддержки обеспечения безопасности протокола IPv6.

Нет, производительность Amazon CloudFront не зависит от использования протоколов IPv4 или IPv6.

Все существующие на данный момент возможности Amazon CloudFront поддерживают работу с IPv6, но перед переходом дистрибутивов на использование IPv6 следует внести два изменения во внутренние процессы обработки адресов IPv6.

1. Если включена функция ведения журналов Amazon CloudFront Access Logs, адреса пользователей IPv6 будут отображаться в поле «c‑ip», и мы рекомендуем проверить, правильно ли системы обработки журналов работают с адресами IPv6.
2. При переносе дистрибутивов Amazon CloudFront на IPv6 адреса IPv6 будут отображаться в отправляемом источнику заголовке «X‑Forwarded‑For». Если система‑источник настроена на обработку только адресов IPv4, рекомендуем проверить, насколько корректно она будет обрабатывать адреса IPv6.

Помимо этого, при использовании белых списков IP заверителей следует использовать для URL заверителей базы раздачи IPv4, а для остального контента – базы раздачи IPv4/IPv6. Данная модель позволяет избежать проблемы, когда запрос на подпись приходит с адреса IPv4 и подписан соответствующим образом, а запрос на контент приходит с адреса IPv6, не входящего в белый список.

Подробная информация о поддержке IPv6 в Amazon CloudFront приведена в разделе Поддержка IPv6 в Amazon CloudFront Руководства по Amazon CloudFront для разработчиков.

Нет. Чтобы пользоваться IPv6 и URL заверителей по белым спискам IP, следует использовать два разных дистрибутива. На одной из баз раздачи следует отключить IPv6 и выделить ее исключительно для работы с URL заверителей по белым спискам IP. Второй дистрибутив можно будет использовать для всего остального контента, как с IPv4, так и с IPv6.

Да, если журналы доступа Amazon CloudFront активированы, адрес IPv6 пользователя будет указан в поле «c‑ip». Перед переходом баз раздачи к использованию IPv6 следует убедиться, что системы обработки журналов поддерживают работу с адресами IPv6. В случае проблем из‑за влияния трафика IPv6 на способность инструментов или программного обеспечения обрабатывать IPv6 адреса в журналах доступа свяжитесь со службой поддержки разработчиков. Подробная информация приведена в документации журналов доступа Amazon CloudFront.

Да, вы можете включить или отключить использование IPv6 на новых и существующих базах дистрибутивах с помощью консоли Amazon CloudFront или API.

По итогам обсуждений с клиентами мы пришли к выводу, что это может пригодиться лишь в случае проблем при внутренней обработке IP‑адресов. При включении IPv6 на дистрибутиве Amazon CloudFront адреса IPv6 будут отображаться не только в детализированных журналах доступа, но и в отправляемом источнику заголовке X‑Forwarded‑For. Если ваши исходные системы могут обрабатывать только адреса IPv4, то необходимо узнать, могут ли они работать с адресами IPv6, перед переходом на IPv6 для ваших дистрибутивов.

Сети Amazon CloudFront по всему миру обладают очень широкими возможностями подключения, но в некоторых из них доступ по протоколу IPv6 из любой точки еще не реализован. В долгосрочной перспективе очевидно, что весь Интернет перейдет на IPv6, однако в ближайшем будущем все оконечные устройства будут поддерживать подключения по IPv4. В тех частях Интернета, где возможности подключения для IPv4 шире, чем для IPv6, мы будем использовать IPv4.

Да, вы можете создать псевдонимы Route 53 для своего дистрибутива Amazon CloudFront, которые будут поддерживать как IPv4, так и IPv6. Для этого необходимо создать псевдонимы с использованием записей типа «A» и «AAAA» соответственно. Чтобы использовать только IPv4, достаточно только записи псевдонима типа «A». Подробная информация о наборах записей псевдонимов ресурса приведена в Руководстве по Amazon Route 53 для разработчиков.

С 1 декабря 2021 года все клиенты AWS смогут ежемесячно бесплатно передавать 1 ТБ исходящих данных, отправлять 10 000 000 запросов HTTP/HTTPS и выполнять 2 000 000 вызовов Функций CloudFront. Все другие типы пользования (например, запросы на аннулирование, запросы прокси, Lambda@Edge, Origin Shield, передача данных к источнику) исключены из Уровня бесплатного пользования.  

Нет. Клиенты, которые используют консолидированную оплату для нескольких аккаунтов, имеют право использовать Уровень бесплатного пользования AWS только на одном аккаунте в рамках одной организации.

Ограничение Уровня бесплатного пользования в размере 1 ТБ для передачи данных и 10 миллионов запросов GET применяется ко всем периферийным местоположениям. Если вы превысите ограничения для месячного Уровня бесплатного пользования, то просто оплатите по стандартным тарифам за сервис AWS по требованию для каждого региона. Подробная информация о ценах приведена на странице цен на AWS CloudFront.

Просмотреть текущие и прошлые данные об использовании по конкретным регионам можно на панели управления счетами и затратами после входа в свой аккаунт. Там же можно управлять расходами и использованием с помощью сервиса Бюджеты AWS, графически представлять составляющие расходов и тенденции использования с помощью Обозревателя затрат и еще глубже изучить структуру расходов с помощью отчетов о затратах и использовании. Подробнее узнать о том, как контролировать расходы на AWS, можно из 10‑минутного учебного пособия «Управление расходами на AWS».

Клиенты, подписанные на Пакет скидок на CloudFront и обеспечение безопасности, также извлекут выгоду из Уровня бесплатного пользования. Если вы захотите снизить объем своих обязательств по пакету экономии для охраны безопасности в CloudFront благодаря Уровню бесплатного пользования, обратитесь в службу поддержки клиентов, и мы проведем оценку вашего запроса на изменения. В ближайшие дни мы предоставим дополнительные сведения по этому вопросу. Следите за новостями. 

Ответы на другие вопросы см. по ссылке https://aws.amazon.com/free/free-tier-faqs/.

Плата за Amazon CloudFront начисляется по факту использования на основании пяти параметров: объема исходящих данных, количества запросов HTTP/HTTPS, запросов на аннулирование, запросов к журналу в режиме реального времени и собственных сертификатов SSL с выделенными IP‑адресами, связанных с дистрибутивом CloudFront.

Уровень бесплатного пользования AWS позволяет начать работу с Amazon CloudFront бесплатно, а при более активной работе тарифы останутся низкими. Все клиенты CloudFront смогут бесплатно передавать 1 ТБ исходящих данных и отправлять 10 000 000 запросов HTTP/HTTPS для Amazon CloudFront, даже если эти ограничения будут превышены. Если 

• Передача исходящих данных в Интернет
  Плата начисляется на основании объема данных (в гигабайтах), переданных из периферийных местоположений Amazon CloudFront. Тарифы на передачу данных в Интернет для Amazon CloudFront можно посмотреть здесь. Обратите внимание, что объем переданных данных для определенных географических регионов подытоживается отдельно, а затем на основе ценовых уровней рассчитывается стоимость для каждой области. Если в качестве источника используются другие сервисы AWS, они оплачиваются отдельно, включая хранилище и вычислительное время. С 1 декабря 2014 года при использовании источников AWS (например, Amazon S3, Amazon EC2 и т. д.) плата за передачу данных из этих сервисов в Amazon CloudFront не взимается. Это касается передачи данных из всех регионов AWS в любые периферийные местоположения CloudFront по всему миру.
• Исходящая передача данных к источнику
  Плата начисляется за объем данных (в гигабайтах), переданных из периферийных местоположений Amazon CloudFront к источнику (включая источники AWS и другие серверы источника). Тарифы на передачу данных к источнику для Amazon CloudFront можно посмотреть здесь.
• Запросы HTTP/HTTPS
  Плата начисляется за количество запросов контента по HTTP/HTTPS, полученных Amazon CloudFront. Тарифы на запросы HTTP/HTTPS можно посмотреть здесь.
• Запросы на аннулирование
  Плата начисляется за каждый путь в запросах на удаление. Путь, указанный в запросе API Invalidation, представляет собой URL‑адрес (или несколько URL‑адресов, если путь содержит знак подстановки) объекта, который необходимо удалить из кэша CloudFront. Без дополнительной платы можно запрашивать в Amazon CloudFront удаление до 1000 путей в месяц. Сверх этого плата начисляется за каждый путь, указанный в запросе на удаление. Тарифы на запросы на аннулирование можно посмотреть здесь.
• Запросы на получение журналов в реальном времени
  Плата за использование журналов в реальном времени начисляется на основании количества созданных строк журнала. За каждый 1 000 000 строк, опубликованных сервисом CloudFront в вашем журнале, взимается плата в размере 0,01 USD.
• Собственные сертификаты SSL с выделенными IP-адресами
  Вы платите 600 USD в месяц за каждый собственный сертификат SSL, связанный с одной или более базой раздачи CloudFront, поддерживающей версию собственных сертификатов SSL для выделенных IP-адресов. Данная ежемесячная плата пропорционально разделяется по часам. Например, если собственный сертификат SSL связан хотя бы с одной базой раздачи CloudFront всего на 24 часа (т. е. 1 сутки) в июне, суммарная стоимость использования сертификата SSL в июне составит (1 день/30 дней) * 600 USD = 20 USD. Чтобы воспользоваться поддержкой собственных сертификатов SSL с выделенными IP‑адресами, загрузите сертификат SSL и с помощью Консоли управления AWS свяжите его с дистрибутивами CloudFront. Если с дистрибутивами CloudFront требуется связать более двух собственных сертификатов SSL, опишите свой пример использования сервиса с указанием требуемого количества собственных сертификатов SSL в форме запроса на повышение лимитов CloudFront.

Уровни пользования для передачи данных рассчитываются отдельно для каждого географического региона. Если не указано иначе, приведенные выше цены не включают налоги, пошлины или аналогичные государственные сборы (если таковые применимы).

Если не указано иное, представленные здесь цены не включают применимые налоги и сборы, в том числе НДС и применимый налог с продаж. Для клиентов с платежным адресом в Японии использование сервисов AWS облагается потребительским налогом Японии. Подробнее.

Если у вас есть дистрибутив, обслуживающий 1000 запросов в секунду с размером журнала 1 КБ, и вы создаете поток данных Kinesis в регионе Восток США (Огайо) с 2 сегментами:

Ежемесячная стоимость потока данных Kinesis: 47,74 USD в месяц согласно расчетам с помощью калькулятора Kinesis, который доступен здесь.

Ежемесячная стоимость журналов CloudFront в реальном времени: число запросов в месяц X стоимость журналов в реальном времени = 1000 * (60 сек * 60 мин * 24 ч * 30 дней) X (0,01 USD / 1 000 000) = 25,92 USD /месяц

Код 304 – это ответ на условный запрос GET, соответственно, плата начисляется за запрос HTTP/HTTPS и исходящую передачу данных в Интернет. Хотя ответ 304 не содержит тела сообщения, его заголовок HTTP имеет некоторый размер, за передачу которого будет начислена плата по стандартным тарифам CloudFront на передачу данных. Объем передаваемых данных зависит от размера заголовка, связанного с передаваемым объектом.

Да, различные ценовые категории позволяют снизить цены на доставку контента из Amazon CloudFront. По умолчанию Amazon CloudFront сводит задержку для конечного пользователя до минимума, доставляя контент через всемирную сеть периферийных местоположений. Однако, так как мы взимаем большую оплату за услуги, когда наши собственные расходы повышаются, за доставку контента конечным пользователям в некоторые местоположения с низкой задержкой придется платить больше. Ценовые категории позволяют снизить расходы на доставку, исключая более дорогостоящие периферийные местоположения Amazon CloudFront из баз раздачи Amazon CloudFront. В этих случаях Amazon CloudFront будет доставлять контент из периферийных местоположений в пределах местоположений из выбранной ценовой категории и взимать плату за передачу данных и запросы применимо к точке присутствия, из которой осуществлена доставка.

Если производительность – ваш основной приоритет, используйте настройки по умолчанию, и ваш контент будет доставляться всей нашей сетью местоположений. Однако для того, чтобы воспользоваться иной ценовой категорией, можно дополнительно настроить базу раздачи через Консоль управления AWS либо через API Amazon CloudFront. Если выбрана ценовая категория, не включающая все местоположения, некоторые пользователи, особенно в местоположениях за пределами этой ценовой категории, могут испытывать большие задержки, чем при доставке через все местоположения Amazon CloudFront.

Заметьте, что Amazon CloudFront может изредка отвечать на запросы на контент из периферийных местоположений за пределами вашей ценовой категории. Когда такое происходит, плата начисляется по тарифам местоположений выбранной ценовой категории.

Список местоположений для каждой ценовой категории см. здесь.

Пакет скидок на CloudFront и обеспечение безопасности – это гибкий план тарификации самообслуживания, который поможет сэкономить до 30 % на CloudFront в обмен на обязательство по ежемесячным затратам (напр., 100 USD в месяц) в течение одного года.  Дополнительное преимущество заключается в бесплатном использовании AWS WAF (брандмауэра веб-приложений) в размере 10 % от суммы обязательства для защиты ресурсов CloudFront.  Например, сумма обязательства в размере 100 USD в месяц за использование CloudFront покроет использование CloudFront на сумму 142,86 USD, что позволит сэкономить 30 % по сравнению со стандартными тарифами. Кроме того, для защиты ваших ресурсов CloudFront выделено до 10 USD на бесплатное использование AWS WAF каждый месяц (до 10 % от суммы обязательства в отношении CloudFront).  Стандартная плата за CloudFront и AWS WAF взимается за все возможности использования, которые не покрываются ежемесячным обязательством по расходам.  По мере роста использования вы можете покупать дополнительные пакеты скидок на дополнительное использование. 

Приобретая Пакет скидок на CloudFront и обеспечение безопасности, вы сможете экономить 30 %, что отразится на ежемесячной плате за обслуживание CloudFront, включая все типы использования CloudFront: передачу исходящих данных, передачу данных к источнику, плату за запросы HTTP/S, запросы на шифрование на уровне поля, Origin Shield, аннулирование, специальный SSL для выделенного IP-адреса, статические IP для передачи по произвольному пути, Lambda@Edge, Функции CloudFront, журналы в режиме реального времени, использование периферийных серверов кэширования в регионах (REC), gRPC, поддержка WebSocket и другие функции CloudFront. Вы также получите дополнительные выгодные предложения, включающие варианты использования AWS WAF, связанные с дистрибутивами CloudFront.

Начать работу с Пакетом скидок на CloudFront и обеспечение безопасности можно в консоли CloudFront, где вы получите рекомендации в отношении суммы обязательств с учетом статистики использования CloudFront и AWS WAF, или после ввода индивидуального примерного объема использования. Сравнительный анализ ежемесячных сборов за использование пакета экономии для защиты безопасности в CloudFront и затрат по требованию позволяет рассчитать приблизительное значение экономии и выбрать подходящий план с учетом ваших потребностей.  После оформления подписки на пакет экономии для защиты безопасности в CloudFront будет взиматься ежемесячная плата. При этом вы получите сведения о кредитах, компенсирующих сборы за использование CloudFront и WAF.  Стандартная плата за использование взимается за все возможности использования, которые не покрываются ежемесячным обязательством по расходам. 

По истечении срока действия пакета экономии для защиты безопасности в CloudFront за использование CloudFront и AWS WAF будет взиматься стандартная плата.   Ежемесячная сумма обязательства в отношении пакета экономии, а также преимущества пакета экономии будут неприменимы.  Вы можете выбрать автоматическое продление периода использования пакета экономии для защиты безопасности в CloudFront на один год в любое время до истечения срока действия пакета.

Пакет экономии для защиты безопасности в CloudFront можно приобрести в любом аккаунте группы AWS Organization и консолидированной оплаты.   Преимущества пакета экономии для защиты безопасности в CloudFront зачисляются на счет в качестве кредита. Преимущества пакета экономии доступны к использованию во всех аккаунтах группы AWS Organization и консолидированной оплаты по умолчанию (совместное использование кредита включено) и зависят от того, когда подписывающийся аккаунт присоединяется к организации или покидает ее.  Чтобы получить дополнительную информацию о применении кредитов AWS к одному или нескольким аккаунтам, см. страницу кредитов AWS.

Да, дополнительные пакеты экономии для защиты безопасности в CloudFront можно приобрести по мере роста использования, чтобы получить скидки на дополнительное использование.   Все активированные пакеты экономии для защиты безопасности в CloudFront учитываются при выставлении счета за использование ресурсов AWS.

Суммы ежемесячных сборов за обязательство будут отображаться в счете в отдельном разделе Пакета скидок на CloudFront и обеспечение безопасности.  Сумма, сэкономленная на использовании Пакета скидок на CloudFront и обеспечение безопасности, будет отображаться в частях затрат за использование CloudFront и WAF, указанных в счете, как кредиты для компенсации ваших стандартных расходов на использование.  

Да, благодаря Бюджетам AWS можно устанавливать пороговые значения затрат и использования, а также получать сообщения электронной почты или уведомления Amazon SNS о превышении порогового значения фактических или запланированных расходов.  Вы можете установить настраиваемый бюджет AWS, применить фильтр затрат на использование CloudFront и установить пороговое значение бюджета для вариантов использования CloudFront по требованию, покрываемых пакетом экономии для защиты безопасности в CloudFront, для получения уведомлений о превышении такого значения.   Чтобы получить дополнительную информацию о бюджете, см. раздел об управлении затратами с помощью Бюджетов AWS и создании бюджета в руководстве пользователя по Выставлению счетов и управлению расходов AWS. 

Дополнительное преимущество Пакета скидок на CloudFront и обеспечение безопасности заключается в бесплатном использовании AWS WAF в размере 10 % от суммы обязательства для защиты ресурсов CloudFront. Стандартная плата за CloudFront и AWS WAF взимается за все возможности использования, которые не покрываются пакетом экономии для охраны безопасности в CloudFront.  Пакет скидок на CloudFront и обеспечение безопасности не покрывает настраиваемые правила WAF, заданные посредством AWS Marketplace. 

Подписаться можно только на один из этих ресурсов.  В случае возникновения вопросов о соглашении об индивидуальном расчете цен обратитесь к персональному менеджеру AWS.

Подписаться на Пакет скидок на CloudFront и обеспечение безопасности можно только в консоли CloudFront.  Мы рассмотрим возможность оформления подписки по API при разработке новых возможностей.