Общие вопросы

Вопрос: Что такое Amazon CloudFront?

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

Вопрос: В каких целях можно использовать Amazon CloudFront?

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

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

Вопрос: Как начать работу с Amazon CloudFront?

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

Вопрос: Как можно использовать Amazon 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 поддерживает постоянное соединение с серверами‑источниками, чтобы как можно быстрее получать файлы, копий которых нет в периферийных местоположениях или на периферийных серверах кэширования в регионах. Наконец, Amazon CloudFront использует для ускорения доставки контента пользователям дополнительную оптимизацию, например расширенное исходное окно перегрузки протокола TCP.

Вопрос: Как Amazon CloudFront помогает сократить расходы при распространении контента через Интернет?

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

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

Вопрос: За счет чего Amazon CloudFront может ускорить веб‑сайт в целом?

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

Вопрос: В чем отличие Amazon CloudFront от Amazon S3?

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

Вопрос: В чем отличие Amazon CloudFront от традиционных решений для доставки контента?

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

Вопрос: Какие типы контента поддерживает Amazon CloudFront?

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

Вопрос: Работает ли Amazon CloudFront с серверами источника вне AWS?

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

Вопрос: Как Amazon CloudFront обеспечивает избыточность источника?

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

Вопрос: Предлагает ли Amazon CloudFront Соглашение об уровне обслуживания (SLA)?

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

Вопрос: Можно ли использовать Консоль управления AWS с сервисом Amazon CloudFront?

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

Вопрос: Какие инструменты и библиотеки работают с Amazon CloudFront?

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

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

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

Периферийные местоположения

Вопрос: Что представляет собой периферийный сервер кэширования CloudFront в регионе?

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

Вопрос: Как работают периферийные серверы кэширования в регионах?

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

Вопрос: Периферийные серверы кэширования в регионах используются сервисом по умолчанию?

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

Вопрос: Где находятся периферийные сетевые местоположения Amazon CloudFront?

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

Вопрос: Можно ли ограничить доставку контента только некоторыми странами (или наоборот, отключить доставку контента в некоторые страны)?

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

Вопрос: Насколько точна ваша база данных географического распределения IP‑адресов?

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

Вопрос: Можно ли возвращать конечным пользователям собственные сообщения об ошибках?

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

Вопрос: Сколько времени Amazon CloudFront хранит файлы в периферийных местоположениях?

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

Вопрос: Как удалить какой‑либо элемент из периферийного местоположения Amazon CloudFront?

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

Вопрос: Имеются ли ограничения на количество создаваемых запросов API Invalidation?

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

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

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

Соответствие требованиям

Вопрос: Соответствует ли Amazon CloudFront стандарту PCI?

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

Вопрос: Соответствует ли Amazon CloudFront требованиям HIPAA?

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

Вопрос: Соответствует ли Amazon CloudFront требованиям SOC?

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

Вопрос: Как можно запросить отчет AWS SOC 1, SOC 2 или SOC 3?

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

HTTP и HTTP/2

Вопрос: Какие типы HTTP‑запросов поддерживает Amazon CloudFront?

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

Вопрос: Кэширует ли Amazon CloudFront ответы на запросы POST?

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

Вопрос: Как начать использовать HTTP/2?

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

Вопрос: Как быть, если источник не поддерживает HTTP/2?

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

Вопрос: Обеспечивает ли Amazon CloudFront поддержку HTTP/2 без использования TLS?

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

WebSocket

Вопрос: Что такое протоколы WebSocket?

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

Вопрос: Как сделать так, чтобы база раздачи Amazon CloudFront поддерживала протокол WebSocket?

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

Вопрос: Когда соединение по протоколу WebSocket устанавливается через Amazon CloudFront?

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

Вопрос: Поддерживает ли Amazon CloudFront защищенные протоколы WebSocket через TLS?

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

Безопасность

Вопрос: Можно ли настроить базу раздачи CloudFront для доставки контента по протоколу HTTPS с использованием собственного доменного имени?

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

Вопрос: Что такое шифрование на уровне поля?

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

Вопрос: Если SSL/TLS‑шифрование с CloudFront уже используется, требуется ли дополнительное шифрование на уровне поля?

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

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

Вопрос: В чем разница между собственными сертификатами SSL с индикацией имени сервера (SNI) и собственными сертификатами SSL с выделенными IP‑адресами в Amazon CloudFront?

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

Собственный сертификат SSL с использованием Server Name Indication (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?

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

Вопрос: Интегрирован ли CloudFront с AWS Certificate Manager?

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

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

Вопрос: Поддерживает ли Amazon CloudFront управление доступом для платного или частного контента?

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

Вопрос: Как можно защитить свои интернет-приложения, доставляемые через CloudFront, от DDoS‑атак?

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

AWS Shield Advanced – это дополнительный платный сервис, доступный клиентам с уровнями поддержки AWS Support «Корпоративный» и «Для бизнеса». AWS Shield Advanced обеспечивает дополнительную защиту от более масштабных и сложных атак, нацеленных на интернет‑приложения на базе сервисов Elastic Load Balancing (ELB), Amazon CloudFront и Amazon Route 53.

Вопрос: Как защитить интернет‑приложения при доставке с помощью CloudFront?

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

Кэширование

Вопрос: Можно ли добавлять или изменять заголовки запросов, перенаправляемых к источнику?

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

Вопрос: Как Amazon CloudFront обрабатывает значения HTTP cookie?

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

Вопрос: Как Amazon CloudFront обрабатывает параметры строки запроса в URL?

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

Вопрос: Можно ли указать, какие параметры запроса допустимо использовать в ключе кэширования?

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

Вопрос: Есть ли ограничение на количество параметров запроса, которое можно включить в белый список?

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

Вопрос: Какие типы параметров поддерживаются?

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

Вопрос: Поддерживает ли CloudFront сжатие gzip?

Да, 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 протоколы потоковой передачи видео по требованию (VOD)?

Да, 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 потоковое вещание на различные платформы?

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

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

Лимиты

Вопрос: Можно ли работать с Amazon CloudFront, если ожидается пиковое использование в объеме более 150 ГБ/с или 250 000 запросов в секунду?

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

Вопрос: Имеется ли ограничение на количество баз раздачи Amazon CloudFront для одного аккаунта?

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

Вопрос: Каков максимальный размер файла для доставки с помощью Amazon CloudFront?

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

Ведение журналов и отчеты

Вопрос: Какие возможности ведения журналов доступны в Amazon CloudFront?

При создании или изменении базы раздачи CloudFront можно активировать ведение журналов доступа. В CloudFront доступно два способа ведения журналов запросов от баз раздачи: стандартные журналы и журналы в реальном времени.

Стандартные журналы CloudFront доставляются в выбранную корзину Amazon S3 (записи журналов доставляются за считаные минуты после запроса пользователя). После активации CloudFront публикует подробные данные журнала в расширенном формате W3C в указанную корзину Amazon S3. Журналы доступа содержат подробные сведения о каждом запросе контента, включая название объекта, дату и время запроса, периферийное местоположение, обслужившее запрос, IP‑адрес клиента, источник ссылки, пользовательский агент, заголовок cookie и тип результата (например, для кэша: hit, miss или error). За стандартные журналы CloudFront не взимается плата, но хранение файлов журналов и доступ к ним оплачиваются по тарифам Amazon S3.

Журналы CloudFront в реальном времени записываются в выбранный поток данных в сервисе Amazon Kinesis Data Streams (запись журналов осуществляется за считаные секунды после запроса пользователя). Вы можете выбрать частоту дискретизации журналов в реальном времени, то есть процент запросов, для которых в журнал добавляются записи. Вы также можете выбрать конкретные поля, в которые будут вноситься записи. Журналы CloudFront в реальном времени содержат те же точки данных, что и стандартные журналы, а также дополнительную информацию о каждом запросе, например заголовки запросов пользователей и код страны в расширенном формате W3C. За использование журналов CloudFront в реальном времени взимается плата дополнительно к стоимости использования Kinesis Data Streams.

Вопрос: Как определить подходящие журналы CloudFront для моего варианта использования сервиса?

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

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

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

Вопрос: Сколько сегментов Kinesis нужно иметь в Kinesis Data Stream?
Чтобы узнать необходимое число сегментов, выполните следующие действия:

  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 сегментов.

Вопрос: Предлагает ли Amazon CloudFront готовые отчеты, с помощью которых можно изучать данные об использовании сервиса, аудиторию и передаваемый контент?

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

Вопрос: Можно ли пометить базы раздачи тегами?

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

Вопрос: Можно ли получить историю всех вызовов API 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 и выберите «Мониторинг и предупреждения» на навигационной панели.

Lambda@Edge

Вопрос: Что представляет собой Lambda@Edge?

Сервис Lambda@Edge позволяет запускать код в глобальных периферийных местоположениях AWS без выделения серверов и управления ими и обеспечивать ответ на запросы конечных пользователей с минимальной сетевой задержкой. Сервис позволяет загрузить код Node.js или Python в AWS Lambda и настроить вызов конкретной функции в ответ на запросы сервиса Amazon CloudFront (т. е. при получении запроса пользователя, перенаправлении запроса на сервер‑источник или его получении обратно, а также непосредственно перед отправкой ответа конечному пользователю). Код будет готов к исполнению в каждом периферийном местоположении AWS при получении запроса на контент. В зависимости от объема запросов в периферийных местоположениях CloudFront будут масштабироваться ресурсы для исполнения кода. Подробнее см. в нашей документации.

Вопрос: Как выполнять настройку контента с помощью Lambda@Edge?

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

Вопрос: Какие события в Amazon CloudFront могут использоваться как триггеры?

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

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

IPv6

Вопрос: Что такое IPv6?

Каждый сервер и устройство, подключенное к Интернету, имеют определенный числовой адрес протокола сети интернет (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

Вопрос: Как можно использовать протокол IPv6?

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

Вопрос: Меняется ли производительность Amazon CloudFront при использовании протокола IPv6?

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

Вопрос: Все ли возможности Amazon CloudFront будут доступны при использовании протокола 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, следует использовать две разных базы раздачи. На одной из баз раздачи следует отключить IPv6 и выделить ее исключительно для работы с URL заверителей по белым спискам IP. Вторую базу раздачи можно будет использовать для всего остального контента, как с IPv4, так и с IPv6.

Вопрос: Если включить IPv6, будет ли адрес IPv6 отображаться в журнале Access Logs?

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

Вопрос: Можно ли отключить IPv6 на всех новых базах раздачи?

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

Вопрос: В каких ситуациях может быть полезно отключить IPv6?

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

Вопрос: На базе раздачи включен IPv6, но поиск DNS не возвращает адресов IPv6. В чем дело?

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

Вопрос: Если я использую Route 53 в качестве DNS‑сервера, и создал псевдоним, указывающий на мою базу раздачи Amazon CloudFront, нужно ли обновлять запись псевдонима для использования IPv6?

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

Оплата

Вопрос: Как начисляется плата за использование Amazon CloudFront?

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

Уровень бесплатного пользования AWS позволяет начать работу с Amazon CloudFront бесплатно. При регистрации новым клиентам AWS предоставляется возможность выполнять исходящую передачу в объеме 50 ГБ данных и 2 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
    Плата начисляется за каждый путь в запросах на удаление. Путь, указанный в запросе API Invalidation, представляет собой URL‑адрес (или несколько URL‑адресов, если путь содержит знак подстановки) объекта, который необходимо удалить из кэша CloudFront. Без дополнительной платы можно запрашивать в Amazon CloudFront удаление до 1000 путей в месяц. Сверх этого плата начисляется за каждый путь, указанный в ваших запросах на удаление. Тарифы на запросы API Invalidation можно посмотреть здесь.
  • Запросы журналов в реальном времени

Плата за использование журналов в реальном времени начисляется на основании количества созданных строк журнала. За каждый 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 Data Stream в регионе Восток США (Огайо) с двумя сегментами:

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

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

Вопрос: Как оплачиваются ответы с кодом 304?

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

Вопрос: Можно ли выбрать доставку контента только из недорогих регионов Amazon CloudFront?

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

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

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

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

Узнайте, как начать работу с Amazon CloudFront бесплатно

Перейти на страницу начала работы
Готовы приступить к разработке?
Начните разработку с помощью Amazon CloudFront в консоли AWS
Возникли дополнительные вопросы?
Свяжитесь с нами